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
