[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 :-) - 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? - Does this draft coexist with certificate-less mutual EAP authentication, as per RFC5998?
Thanks,
Yaron
On 05/02/2011 02:31 PM, Yoav Nir wrote:
Hi.Qin and I have just posted the subject draft. The title is "An IKEv2 Extension for Supporting ERP", although it has nothing to do with enterprise resource planning.This draft brings the ERP extension for EAP, which is developed by the Hokey group into the IKEv2 authentication exchange, allowing a client ("peer" or "initiator") to authenticate to a VPN gateway ("Authenticator" or "responder") in only three round-trips, and without user intervention, provided that this client has unexpired keys from a previous run of EAP. It doesn't matter whether the previous run was done in the context of another IKE exchange, attachment to a 802.1x LAN or over PPP.We would like this draft to be accepted as a working-group item in IPsecME, although serious review in hokey will also be needed.I'd like to use this one-time cross-posted mail message to explain some of the design decisions in this -00 version of the draft.The EAP-Initiate/Re-auth-Start message is missing from the protocol. Instead, a notification payload carries the domain name. This was done because an EAP payload in the IKE_SA_INIT response would be weird, whereas unknown Notifications are common. We are not sure whether placing the domain name is necessary, because in IKE, the client usually connects to a pre-configured gateway, rather than attaching to any network available as in 802.1x.We do not run two EAP protocols in parallel (re-auth and something else) as in RFC 5296 and the bis document, because IKEv2 ususally doesn't have identity requests (they identity protocol is replaced by the user identity in the IDi payload), and running a real EAP protocol would put us in a weird state with the backend EAP server. Instead, we send the domain name in the notification payload, and the client may either send the EAP-Initiate/Re-auth message or the IDi payload (but not both).Alternatively we could have the client indicate support in the IKE_SA_INIT request, and then have a proper EAP-Initiate/Re-auth-Start message in the IKE_SA_INIT response. I don't see much advantage in this, so in version -00 we did not do this.We would very much appreciate feedback from both groups. Qin& Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
