ipsec November 2007 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: [IPsec] Fwd: Document Action: 'EAP-IKEv2 Method' to Exper

[IPsec] Fwd: Document Action: 'EAP-IKEv2 Method' to Experimental RFC

From: Paul Hoffman <paul.hoffman_at_nospam>
Date: Sat Nov 03 2007 - 12:07:57 GMT
To: IPsec WG <ipsec@ietf.org>


>The IESG has approved the following document:
>
>- 'EAP-IKEv2 Method '
> <draft-tschofenig-eap-ikev2-15.txt> as an Experimental RFC
>
>This document has been reviewed in the IETF but is not the product of an
>IETF Working Group.
>
>The IESG contact person is Jari Arkko.
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-15.txt
>
>Technical Summary
>
> This document specifies EAP-IKEv2, an EAP authentication method that
> is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2
> provides mutual authentication and session key establishment between
> an EAP peer and an EAP server. It supports authentication techniques
> that are based on passwords, high-entropy shared keys, and public key
> certificates. These techniques can be combined in a number of ways.
> EAP-IKEv2 further provides support for cryptographic ciphersuite
> negotiation, hash function agility, identity confidentiality (in
> certain modes of operation), fragmentation, and an optional "fast
> reconnect" mode.
>
>Working Group Summary
>
> There is no WG behind this proposal, but the document
> has gone through discussions in the EAP WG in the past,
> and has also passed Expert Review required for IANA
> EAP Type code allocation.
>
> Responsible AD has checked with the chairs and ADs of
> the EMU WG for possible conflict with their work. It
> was concluded that there is no conflict.
>
>Protocol Quality
>
> Jari Arkko has reviewed this specification for the IESG.
> Pasi Eronen has acted as the Expert Reviewer. There is
> a research implementation of this by the authors of the
> proposal.
>
>Note to RFC Editor
>
> Remove the sentence "EAP-IKEv2 has sucessfully passed Designated
> Expert Review as mandated by RFC 3748." from the Abstract.
>
> Replace first paragraph of Section 1 with this:
>
> This document specifies EAP-IKEv2, an EAP method that is based on the
> Internet Key Exchange Protocol version 2 (IKEv2) [1]. EAP-IKEv2
> provides mutual authentication and session key establishment between
> an EAP peer and an EAP server. It supports authentication techniques
> that are based on the following types of credential.
>
> Insert a new paragraph to Section 1 right before "The remainder
> of this document ...":
>
> Note that the IKEv2 protocol is able to carry EAP exchanges. By
> contrast, EAP-IKEv2 does not inherit this capability. That is,
> it is not possible to tunnel EAP methods inside EAP-IKEv2. Also
> note that the set of functionality provided by EAP-IKEv2 is similar,
> but not identical, to that provided by other EAP methods such as,
> for example, EAP-TLS [RFC 2716].
>
> Section 8.8 first sentence should start "The Certificate
> Request payload".
>
> Remove reference 9.
>
> Add an informational reference to RFF 2716.
>
> Replace the IANA considerations section with this:
>
> IANA should allocate a value for the EAP method type indicating EAP-
> IKEv2. EAP-IKEv2 has already earlier sucessfully passed Designated
> Expert Review as mandated by RFC 3748 for IANA allocations.
>
> In addition, IANA is requested to create a new registry for "EAP-IKEv2
>
>
> Payloads", and populate it with the following initial entries listed
> below.
>
> The following payload type values are used by this document.
>
> Next Payload Type | Value
> -----------------------------------+----------------------------------
> No Next payload | TBD by IANA (suggested value: 0)
> Security Association payload | TBD by IANA (suggested value: 33)
> Key Exchange payload | TBD by IANA (suggested value: 34)
> Identification payload |
> (when sent by initiator, IDi) | TBD by IANA (suggested value: 35)
> Identification payload |
> (when sent by responder, IDr) | TBD by IANA (suggested value: 36)
> Certificate payload | TBD by IANA (suggested value: 37)
> Certificate Request payload | TBD by IANA (suggested value: 38)
> Authentication payload | TBD by IANA (suggested value: 39)
> Nonce payload | TBD by IANA (suggested value: 40)
> Notification payload | TBD by IANA (suggested value: 41)
> Vendor ID payload | TBD by IANA (suggested value: 43)
> Encrypted payload | TBD by IANA (suggested value: 46)
> Next Fast-ID payload | TBD by IANA (suggested value: 121)
> RESERVED TO IANA | 1-32, 42, 44-45, 47-120, 121-127
> PRIVATE USE | 128-255
>
> Payload type values 1-120 are matching the identical payloads in the
> IKEv2 IANA registry, all payload numbers not needed by EAP-IKEv2
> are left for RESERVED TO IANA. Payload numbers 121-127 are used for
> EAP-IKEv2 specific payloads which are not identical to the payloads
> used by IKEv2. That range has been reserved for this purpose in
> IKEv2 IANA registry too. This means there will not be same payload
> numbers used for different things in IKEv2 and EAP-IKEv2 protocols.
>
> Payload type values 121-127 are reserved to IANA for future
> assignment in EAP-IKEv2 specific payloads. Payload type values
> 128-255 are for private use among mutually consenting parties.
>
> The semantic of the above-listed payloads is provided in this
> document (121-127) and refer to IKEv2 when necessary (1-120).
>
> New payload type values with a
> description of their semantic will be assigned after Expert Review.
> The expert is chosen by the IESG in consultation with the Security
> Area Directors and the EMU working group chairs (or the working
> group chairs of a designated successor working group). Updates
> can be provided based on expert approval only. A designated
> expert will be appointed by the Security Area Directors.
> Based on expert approval it is possible to delete entries
> from the registry or to mark entries as "deprecated".
>
> Each registration must include the payload type value and the
> semantic of the payload.
>
> Please also take note of the following editorial
> nits from Lars Eggert:
>
> INTRODUCTION, paragraph 13:
> > EAP-IKEv2 has sucessfully passed Designated Expert Review as mandated
>
>
>
>
>
> Nit: s/sucessfully/successfully/
>
> Section 1., paragraph 1:
> > method does not inherit the capabilites to tunnel EAP methods inside
>
> Nit: s/capabilites/capabilities/
>
> Section 2.14, paragraph 0:
> > identifer MUST be embedded in the Encrypted payload. The
>
> Nit: s/identifer/identifier/
>
> Section 4., paragraph 8:
> > messages would be the SPI's negotiated on the previous exchange.
>
> Nit: s/SPI's/SPIs/
>
> Section 3.2, paragraph 0:
> > Reconnect-ID field contains a fast reconnect identifer that the peer
>
> Nit: s/identifer/identifier/
>
> Section 9., paragraph 1:
> > of the preceding payload. However, the identifer space from which
>
> Nit: s/identifer/identifier/

--Paul Hoffman, Director
--VPN Consortium



IPsec mailing list
IPsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec