2 May 2011 13:31
New I-D: draft-nir-ipsecme-erx-00
Yoav Nir <ynir <at> checkpoint.com>
2011-05-02 11:31:04 GMT
2011-05-02 11:31:04 GMT
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
(Continue reading)
- 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
RSS Feed