Hi Martin,<br><br>Thanks for the message.<br><br><br><div class="gmail_quote">On Wed, Aug 18, 2010 at 8:49 PM, Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org">martin@strongswan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Dennis,<br>
<div class="im"><br>
> It seems that the milenage implementations in hostapd and in charon<br>
> are different<br>
<br>
</div>The eap-aka plugin for charon supports different backends. The software<br>
implementation plugin (eap-aka-3gpp2) we ship with strongSwan implements<br>
the algorithm specified by 3GPP2, S.S0055. I think this algorithm is<br>
different from what the 3GPP defines with Milenage.<br>
<div class="im"><br>
> The question is that there's no OP or OPc value in charon<br>
<br>
</div>In S.S0055, there are no OP/OPc values. The 3GPP2 standard knows the<br>
Authentication Management Field (AMF), and the Family Key (FMK). They<br>
probably serve a similar purpose, but the algorithm is different.<br>
<div class="im"><br></div></blockquote><div>OK, so I have to change at least one of the implementations, say the one of hostapd, to make the authentication work.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> I see the eap-simaka-reauth plugin, and it seems this plugin could do<br>
> the work of eap-aka reauthentication.<br>
<br>
</div>Yes. The eap-simaka-reauth/pseudonym plugins provide storage of<br>
pseudonym/reauthentication identities and keying material. But they<br>
provide in-memory storage only.<br>
<div class="im"><br>
> But at each time the permenant identity is sent to radius server, even<br>
> after a first full authentication and the reauth identity is stored on<br>
> peer (according to the log messages on peer).<br>
<br>
</div>The EAP peer stores a reauth identity only if your RADIUS server sends a<br>
reauth identity. Further, the server must request a reauth identity with<br>
the AT_ANY_ID_REQ.<br></blockquote><div><br>Ok, I see. <br>It seems at each authentication(after the first one) when hostapd receives an EAP message, it can always parse the permanent identity, then it uses full authentication. I guess I should look into the code to see what happens.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Are you sure hostapd supports AKA reauthentication?<br></blockquote><div><br> I looked some code in hostapd and it seems hostapd could process eap-aka reauthentication, however I'm not sure about this..<br><br><br>Thanks & Regards,<br>
Dennis<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Best regards<br>
Martin<br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a><br>
<a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
</blockquote></div><br>