On May 2, 2011, at 11:54 PM, Yaron Sheffer wrote: > [Responding to IPsec only:] > > Hi Yoav, > > thanks for the new draft. I'm afraid one needs to read RFC5296bis before > commenting, but here's a few questions anyway: > > - Sending the domain in the IKE_SA_INIT response obviously contradicts > the usual IKEv2 identity protection. This is not really a question :-)
True, but identity protection for the responder never made sense for remote access gateways. I haven't gone over the archives, but I remember that someone proposed having an extra EAP-Identity round so that the server shows its certificate first. If we get feedback that this is a serious issue to some, we can always add a round-trip. > - 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. > - Does this draft coexist with certificate-less mutual EAP > authentication, as per RFC5998? I think the handed-over keying material is cryptographic proof enough and that certificates will usually be unnecessary, so I think yes. > > Thanks, > Yaron _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
