RE: [Ipsec] Reauthentication in IKEv2

umas@intotoinc.com writes:

>> For policy lookups, it's very important to use the identity
>> (identifier) that was actually authenticated by the EAP
>> method, and this is not necessarily the same as IDi. Many EAP
>> methods have an internal identity exchange, and the initial
>> identity (e.g., IDi or EAP Identity Response) is used only
>> for AAA routing and selecting which method to use (see RFC
>> 3748, sections 5.1 and 7.3). "Reauthentication identities" in
>> some EAP methods are an obvious example where using IDi for
>> policy lookups fails, but that's not the main reason.

> Uma: So, initiator wants to send the new authenticated
> identity by EAP Method (Say fast re authentication ID) what
> could be the options at Responder side, so that it could
> successfully identify policy and can relay the same to EAP
> Server ---which eventually could cause Successful EAP Re
> Authentication too.

The responder (acting as EAP pass-through authenticator) does
not, in general, know the real identity that will be authenticated 
by the EAP method before the EAP method starts. 

But fortunately this is not even necessary; the identity sent by 
the client (e.g., fast reauthentication id) still contains enough 
information to select the right AAA server and EAP method; and 
other policy lookups can be done after EAP is finished.

> It seems with this, Is it that, in the re authentication of
> IKE_SA case also IDi would be the same original IDi ???? and
> with this Responder  would relay the same and can't use the Re
> Authentication facility provided by EAP Method??  Or Really is
> there any other way, so that initiator can send two ID's one
> is the original IDi for policy matching and the second is the
> Authenticated EAP Re authentication ID to have EAP
> Re-authentication facility????? (It's not correct/possible)

The real identifier that was authenticated with EAP has to
come from the AAA server, not the initiator. With RADIUS,
this means the server has to include something in the 
Access-Accept message (e.g., User-Name attribute).

(See, e.g., draft-ietf-aaa-eap-09 (section 2.8.1), or
draft-adrangi-radius-chargeable-user-identity-02.)

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec