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. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
