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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
