Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication

[Frederic Detienne <[e-mail]>]

On 13 Nov 2009, at 10:10, Murthy N Srinivas-B22237 wrote:

> Amjad,
> 
> AAA Server (Radius server) is configured with
> 1.domain/realm part of the EAP Identity as the "user name".
> 2.Along with this we can configure a radius attribue with a unique
> identifier.This identifier is sent by AAA server to Authenticator along
> with Authention success packet.
> 3.This identifier is known to the Authenticator which controls
> policies.Multiple users can be configured at AAA server with the same
> identifier.
> 4.This way,Authenticator is not required to know the EAP-identity.

the problem is that the RADIUS ACCESS-ACCEPT and the ID would be sent at the end of the EAP exchange -- at this point, it is too late for some operations.

Some characteristics like for instance allowing the use of EAP for a given identity have to be known BEFORE EAP is complete. We do not want to waste time failing the EAP exchange if we can know from the beginning that EAP can't be used for a given identity. An other example is if the domain portion of an RFC822 ID should be used to pick a AAA server from a list of possible servers.

It is reasonable to recommend passing "a sensible" identity from the beginning.

thanks,

	fred

> Thanks
> -nsmurthy
> 
> 
> -----Original Message-----
> From: Amjad Inamdar (amjads) [mailto:[e-mail]] 
> Sent: Friday, November 13, 2009 12:31 PM
> To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir
> Cc: [e-mail]
> Subject: RE: [IPsec] Clarification on identities involved in
> IKEv2EAPauthentication
> 
> Hi Murthy,
> 
> IKEv2 gatway even when acting as a pass-through would need the
> authenticated EAP identity for local policy decisions. For instance,
> gateway can group remote users based on the authenticated EAP-id (e.g.
> based on the domain/realm part of the ID). Further, with PSK and PKI
> auth methods, it is the authenticated ID that is used for policy
> decisions and that should be same even with EAP auth.
> 
> Thanks,
> -Amjad 
> 
> -----Original Message-----
> From: Murthy N Srinivas-B22237 [mailto:[e-mail]]
> Sent: Thursday, November 12, 2009 6:35 PM
> To: Amjad Inamdar (amjads); Tero Kivinen; Yoav Nir
> Cc: [e-mail]
> Subject: RE: [IPsec] Clarification on identities involved in
> IKEv2EAPauthentication
> 
> 
> Amjad,
> 
> If the Authenticator includes the AAA server implementation,it should no
> the EAP identity to enforce policies.If AAA server is separate,we can
> add an attribute to AAA server for this purpose and in which case
> Authenticator does not have to know the EAP identity.It will use the
> attribute to select the policies.
> 
> Thanks
> -ns murthy 
> 
> -----Original Message-----
> From: Amjad Inamdar (amjads) [mailto:[e-mail]]
> Sent: Thursday, November 12, 2009 4:09 PM
> To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir
> Cc: [e-mail]
> Subject: RE: [IPsec] Clarification on identities involved in
> IKEv2EAPauthentication
> 
> Hi Murthy,
> 
> As per the RFC, with EAP authentication, policy lookups and access
> control decisions should be based on EAP identity, so the gatway needs
> to know the EAP identity.
> 
> The source of EAP identity for gateway is either IDi (when IDi is same
> as EAP identity) or AAA server providing authenticated EAP identity
> neither of which is mandated by RFC, and in case client(via IDi) and AAA
> server do not provide EAP identity, the only way gateway can get EAP
> identity is via EAP identity request to the client.
> 
> ----- Ikev2-bis-05 section 2.16, last paragraph -----
>   When the initiator authentication uses EAP, it is possible that the
>   contents of the IDi payload is used only for AAA routing purposes and
>   selecting which EAP method to use.  This value may be different from
>   the identity authenticated by the EAP method.  It is important that
>   policy lookups and access control decisions use the actual
>   authenticated identity.  Often the EAP server is implemented in a
>   separate AAA server that communicates with the IKEv2 responder.  In
>   this case, the authenticated identity has to be sent from the AAA
>   server to the IKEv2 responder.
> ----------------------------------------------------------
> 
> Thanks,
> -Amjad
> 
> 
> 
> -----Original Message-----
> From: Murthy N Srinivas-B22237 [mailto:[e-mail]]
> Sent: Thursday, November 12, 2009 7:30 AM
> To: Tero Kivinen; Yoav Nir
> Cc: [e-mail]; Amjad Inamdar (amjads)
> Subject: RE: [IPsec] Clarification on identities involved in
> IKEv2EAPauthentication
> 
> 
> Policy lookups are selected by Authenticator based on Authorization
> information received from AAA server after successful Authentication.
> The AAA sever uses an attribute(radius) to send a reference to the
> Authorization information specific for the specific client.The
> Authenticator need not know the EAP identitity of the client, if it is
> different from IKE identity.  
> 
> The Authenticator requires to know the EAP identity only if it
> implements the AAA server functionality.
> 
> ns murthy
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Tero Kivinen
> Sent: Thursday, November 12, 2009 5:01 AM
> To: Yoav Nir
> Cc: [e-mail]; Amjad Inamdar (amjads)
> Subject: Re: [IPsec] Clarification on identities involved in
> IKEv2EAPauthentication
> 
> Yoav Nir writes:
>> Since the gateway acts as a pass-through, the requirement here is more
> 
>> for the client, which is typically more integrated. The client should 
>> be prepared to give an identity hint both in IKE and later in the EAP 
>> session.
> 
> And in that case the identities should really be same, and if they
> differ then the authenticated identity needs to be used for policy
> lookups, meaning that the EAP identity needs to be used. So the gateway
> needs to get that authenticated identity from the AAA server so it can
> do policy lookups based on it. 
> --
> [e-mail]
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec