Document Action: 'EAP-IKEv2 Method' to Experimental RFC

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/

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce