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/