On May 4, 2011, at 11:45 PM, Dan Harkins wrote: <snip />
> > RFC 5996 says in section 2.16: > > "When the initiator authentication uses EAP, it is possible that the > contents of the IDi payload is used only for Authentication, > Authorization, and Accounting (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, if different from that in the > IDi payload, has to be sent from the AAA server to the IKEv2 > responder." > > When sending EAP traffic over a AAA connection, the IKEv2 responder has > no guarantee that the EAP conversation will be terminating on the AAA > server he is passing the EAP traffic to. IDi might be an obfuscated > identity used solely for AAA routing purposes and that routing might send > it via a few proxies somewhere to a AAA server who has no idea what IKEv2 > is, and even if it knew what IKEv2 is it might not know if IKEv2 was > being used in this particular case. While proxies shouldn't be mucking > with the EAP identity in the forwarded packet (the obfuscated and > non-"true identity" one that isn't useful to the IKEv2 responder) they > certainly can modify the Username attribute in the RADIUS packet that > encapsulates it. That means that the identity a particular AAA > server/proxy might get to see might not be what was originally put into > the initial Access-Request by the IKEv2 responder and it might be > different than the one, ultimately, obtained by the AAA server that > actually speaks EAP. Furthermore, one or more of those proxies along the > way might not even know what EAP is! > > Even if one assumes that the AAA server that terminated EAP will > include the identity it authenticated as the Username attribute in the > Access-Accept it sends back (and that it's included in all proxied > Access-Accepts and ultimately reaches the IKEv2 responder) there is > nothing that says that identity has any relevance or significance to > the IKEv2 responder. It could be a SIM identity from EAP-SIM. It could > be "emp12876" used in EAP-MD5 (yea, I know it's not supposed to be > used, so tunnel it in PEAP and then you have a nice, compliant, key > generating EAP method for IKEv2). Which means the IKEv2 responder has > an obfuscated identity that is not useful for authentication purposes > and, maybe, just maybe, it also has some identifier that was useful for > a method it does not know in a realm/domain/whatever it also does not > know. > > To sum, while the identity "has to be sent" (note the non-normative > nature of that statement) there is no guarantee that it will. And even > if it is sent, there is no guarantee that it will be useful in the way > you need to use it. > > Therefore, if the authenticator needs to know the true identity (as you > suggest it must) then don't use try to authenticate the IKEv2 peer in a > way that might not get you what you need. OK. I see what you mean. Certificates are not necessarily better. She might have a certificate with a subject like "UID=alice,OU=people,O=intranet,DC=example,DC=com", or the AAA server might call her "emp715". Either can serve. The VPN gateway needs the identity for two thing: - For policy lookup. As long as the policy database uses the same name, we're fine. - For generating logs. There should be a way to map the name in the logs to the real person, but I guess this re-conciliation of usernames and real names can be done either in generating the logs or in viewing the logs. Any implementation using EAP has users that are either satisfied with "emp715" or use a directory to convert that in the logs to a more meaningful names. In ERP the value used in KeyName-NAI is the EMSKName (as defined in section 3.2 or RFC 5295), or actually a hex representation of this value. The value is 64-bit, so the username part of the KeyName-NAI is just 16 hex digits, and they change each time the user does a full authentication. This value is later copied to the UserName attribute in the RADIUS AccessRequest, and probably also returned in the AccessAccept, although we're not sure that's what really happens. This ephemeral value is much harder to map to either policy or to a meaningful name or to policy. Even if such a mapping can be done in real-time, it cannot be done later after the EMSK expires and is deleted. Even for real-time, it requires either the AAA server to store the policy and transmit it in the AccessAccept, or else to have the directory closely working with the RADIUS server to immediately map the EMSKName to a user record. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
