Hello, On Wed, May 4, 2011 10:45 pm, Yoav Nir wrote: > > On May 4, 2011, at 11:45 PM, Dan Harkins wrote: >> >> 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.
Assuming the CA is trustworthy and the peer authenticated with that certificate then you know that the identity named by the subject name in the certificate is who that peer is. You can make a definitive statement about it (although I'm not sure what attributes UID or DC are). "emp715" returned in an Access-Accept means nothing because it's meaningful when used with an EAP method of X inside a realm/domain of Y and you don't know what either X or Y are. So you can't make any definitive statement about "emp715". > 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. Not to belabor the point, but a user could have an authenticated identity of "emp715" in one realm/domain (that you don't know) and a completely different user could have an authenticated identity of "emp715" in a completely different realm/domain (that you also don't know). Treating them the same is probably not a wise thing to do from a policy enforcement standpoint. (There's a guy named "Dan Harkins" that owns a chain of theaters in the state of Arizona in the US. I am not that man and I don't live in Arizona, but I have received phone calls expressing outrage over the kind of films that "I" show in "my" family theater, and asking why "I" stopped giving out free popcorn to patrons on their birthday. I receive these calls because people take a name, stripped of all context, and assume something about it. And that is a mistake). regards, Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
