[HOKEY] FW: New I-D: draft-nir-ipsecme-erx-00

Hi Yoav,
I received a Mailman mailing list bounce action notice to
hokey-owner@ietf.org.
So I'm forwarding for you.

We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: hokey-bounces@ietf.org [mailto:hokey-bounces@ietf.org] On Behalf Of
Yoav Nir
Sent: Monday, May 02, 2011 4:31 AM
To: ipsec@ietf.org; 'hokey@ietf.org'
Subject: [HOKEY] New I-D: draft-nir-ipsecme-erx-00

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
_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
https://www.ietf.org/mailman/listinfo/hokey