Hi, ----- Original Message ----- From: "Yoav Nir" <[email protected]> To: "Qin Wu" <[email protected]> Cc: <[email protected]>; <[email protected]> Sent: Wednesday, May 04, 2011 3:00 PM Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00
> > On May 4, 2011, at 9:18 AM, Qin Wu wrote: > >> Hi, >> ----- Original Message ----- >> From: "Yoav Nir" <[email protected]> >> To: "Qin Wu" <[email protected]> >> Cc: <[email protected]> >> Sent: Wednesday, May 04, 2011 1:30 PM >> Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00 >> >> >>> >>> On May 4, 2011, at 4:50 AM, Qin Wu wrote: >>> >>>>>> - I am missing the "authenticated peer identity", which I would assume >>>>>> should arrive from the AAA server. This should be the basis of RFC4301 >>>>>> policy decisions on the IKE gateway. Does ERP provide this identity? >>>>> >>>>> The EAP-Initiate/Re-auth packet carries a keyName-NAI TLV, but that is >>>>> sent from the client (or "peer") to the authentication server through the >>>>> gateway. (section 5.3.2 of the bis document) >>>>> The EAP-Finish/Re-auth packet also carries a keyName-NAI TLV, and that is >>>>> sent from the authentication server through the gateway to the client. >>>>> But these don't really help, because the username part of NAI is the >>>>> 64-bit EMSKname, which is not directly related to user name. >>>>> However, these messages come within an Access-Accept packet from the >>>>> RADIUS server, and those include a proper user name. >>>> >>>> [Qin]: If you are talking about the second identity specified in section >>>> 6.4 of RFC5998, I think, unlike EAP, ERP does not provide such identity. >>>> ERP only define two types: one is Re-auth-Start, the other is Re-Auth. >>>> >>>> KeyName-NAI TLV defined in RFC5296 and RFC5296bis more looks like the >>>> first idenity described in section 6.4 of RFC5998. >>>> As decribed in section 5.1 of RFC5296, >>>> " >>>> When an ERP-capable authenticator receives the EAP-Initiate/ >>>> Re-auth message from a peer, it copies the contents of the >>>> ^^^^^^^^^^^^^^^^^^^^ >>>> keyName-NAI into the User-Name attribute of RADIUS [13]. >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> " >>> >>> But what does the RADIUS send in the User-Name attribute of Access-Accept? >>> How does the Authenticator know who the user is? The Authenticator needs >>> the true identity to make policy decisions. >> >> [Qin]: I assume username part of KeyName-NAI will be regarded by RADIUS >> server as User-Name during authentication. > > RFC 3579 says: > "The User-Name attribute within the Access- > Accept packet need not be the same as the User-Name attribute in the > Access-Request." [Qin]: RFC5296 does not specify how UserName is copied into Access-Accept. The reason this part is about authorization which is beyond scope of ERP document. But I agree the different user name can be used. One way in my mind is Radius Server could use KeyName-NAI to look up real user name and add it into the Accss-Request. > Do current implementations copy the KeyName-NAI to the Access-Accept? [Qin]: I am not aware of it. But it could be. >> Also I think it is not necessarily to couple authorization with >> authentication. > > They may not be coupled in other EAP contexts, but IPsec requires policy > decisions based on authenticated identity. One way or another, the IKE > implementation needs to get the real user identity for policy decisions. [Qin]: Okay. the authenticated identity you mentioned is user identity, right? I think we should be careful to differentiate these identities. becos it seems there are lots of identities: e.g., EAP identity, IKEv2 identity and User identity. > Yoav > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
