Hi Alper, On Wed, February 10, 2010 2:14 am, Alper Yegin wrote: > Dan, > >> Hi Alper, >> >> In that case there is no standard way for the AAA server to inform >> the >> IKEv2 responder of this "policy" that it needs to enforce. So that >> sounds >> unworkable. > > I guess it can be specified.
Well yes it can. But it will be much more complicated than just specifying a way to get the authenticated identity. >> The IKEv2 responder already has the mechanisms in place to enforce a >> policy based on the authenticated identity of the IKEv2 initiator. So >> if >> EAP is being used then all we need is a way to get that authenticated >> identity from the AAA server to the IKEv2 responder. > > Isn't IDi what IKE deals with? We're talking about a case where there is no linkage between the two. The initiator asserts an identity but the identity used for authentication is unknown. >> I'm not aware of a document to allows a AAA server to export the >> authenticated identity to the AAA client (maybe such an attribute >> already >> exists, I just don't know) > > > I'm not aware, either. > In other uses of AAA (such as with WiFi, WiMAX, 3GPP2, etc.) I know that > the > subscriber ID is hidden from the NAS. There are even specific methods > deployed for that purpose. So, disclosing that ID would not be acceptable > there. I'm just not sure if the same privacy concerns apply to the VPN > deployments. It's not "hidden" it's just unavailable because there is no way to get it (see above) and, in the case of WiFi (and I suspect WiMAX) it's just a binary decision anyway. The notion that there could be some privacy concerns does not sound serious. You're going to give the NAS the power to impersonate the client, inspect all the client's packets, forge packets to and from the client, tamper with all the client's packets in an undetectable manner, yet for "privacy concerns" the NAS can't be told the real identity of the client? That's sort of like someone eating 4 chocolate cakes but washing it all down with a diet soda because of "weight concerns". regards, Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
