[HOKEY] New I-D: draft-nir-ipsecme-erx-00
Yoav Nir <ynir@checkpoint.com> Mon, 02 May 2011 11:31 UTC
Return-Path: <ynir@checkpoint.com>
X-Original-To: hokey@ietfa.amsl.com
Delivered-To: hokey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id C6413E0742; Mon, 2 May 2011 04:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.47
X-Spam-Level:
X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=4.129,
BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nwlzUKi+juG;
Mon, 2 May 2011 04:31:09 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by
ietfa.amsl.com (Postfix) with ESMTP id 9CD61E0678;
Mon, 2 May 2011 04:31:06 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com
[194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id
p42BV4gr030282; Mon, 2 May 2011 14:31:05 +0300
X-CheckPoint: {4DBEA33D-A-1B221DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by
il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi;
Mon, 2 May 2011 14:31:04 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>, "'hokey@ietf.org'" <hokey@ietf.org>
Date: Mon, 2 May 2011 14:31:04 +0300
Thread-Topic: New I-D: draft-nir-ipsecme-erx-00
Thread-Index: AcwIvGxAunpC79zhQuOaCfwwzT5+Ng==
Message-ID: <006FEB08D9C6444AB014105C9AEB133F013ABE025E24@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [HOKEY] New I-D: draft-nir-ipsecme-erx-00
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hokey>,
<mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>,
<mailto:hokey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2011 11:31:10 -0000
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] New I-D: draft-nir-ipsecme-erx-00 Yoav Nir
- [HOKEY] FW: New I-D: draft-nir-ipsecme-erx-00 Tina Tsou
- [HOKEY] Fw: [IPsec] New I-D: draft-nir-ipsecme-er… Qin Wu
- Re: [HOKEY] Fw: [IPsec] New I-D: draft-nir-ipsecm… Glen Zorn
- Re: [HOKEY] Fw: [IPsec] New I-D: draft-nir-ipsecm… Qin Wu
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Qin Wu
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Yoav Nir
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Qin Wu
- Re: [HOKEY] Fw: [IPsec] New I-D: draft-nir-ipsecm… Glen Zorn
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Yoav Nir
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Dan Harkins
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Yoav Nir
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Dan Harkins
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Yoav Nir
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Yaron Sheffer
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Yoav Nir
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Qin Wu
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Yoav Nir
- Re: [HOKEY] [IPsec] New I-D: draft-nir-ipsecme-er… Qin Wu