< draft-tschofenig-eap-ikev2-06.txt   draft-tschofenig-eap-ikev2-07.txt >
EAP WG EAP WG
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
D. Kroeselberg D. Kroeselberg
Siemens Siemens
Y. Ohba Y. Ohba
Toshiba Toshiba
F. Bersani F. Bersani
France Telecom R&D France Telecom R&D
Document: draft-tschofenig-eap-ikev2-06.txt Document: draft-tschofenig-eap-ikev2-07.txt
Expires: November 18, 2005 May 2005 Expires: January 18, 2006 July 2005
EAP IKEv2 Method EAP IKEv2 Method
(EAP-IKEv2) (EAP-IKEv2)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 18, 2005. This Internet-Draft will expire on November 18, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
EAP-IKEv2 is an EAP method which reuses the cryptography and the EAP-IKEv2 is an EAP authentication method with cryptographic
payloads of IKEv2, creating a flexible EAP method that supports properties and basic exchanges similar to the Internet Key
both symmetric and asymmetric authentication, as well as a Exchange (IKEv2) protocol. It provides a flexible EAP method with
combination of both. This EAP method offers the security benefits support for both symmetric and asymmetric authentication, as well
of IKEv2 authentication and key agreement without the goal of as a combination of both.
establishing IPsec security associations. EAP-IKEv2 thereby offers the security benefits of the exchanges
for authentication and key agreement of IKEv2 within the AAA
framework defined by the IETF.
Table of Contents Table of Contents
1. Introduction..................................................3 1. Introduction..................................................3
2. IKEv2 and EAP-IKEv2 Overview..................................4 2. EAP-IKEv2 Overview............................................4
3. Terminology...................................................5 3. Terminology...................................................5
4. Protocol overview.............................................5 4. Protocol overview.............................................6
5. Identities used in EAP-IKEv2..................................8 5. Identities used in EAP-IKEv2..................................9
6. Packet Format.................................................9 6. Packet Format.................................................9
7. Retransmission...............................................11 7. Fragmentation support........................................11
8. Key derivation...............................................11 8. Retransmission...............................................12
9. Error Handling...............................................13 9. Key derivation...............................................12
10. Fast Reconnect..............................................14 10. Error Handling..............................................14
11. Channel Binding.............................................16 11. Fast Reconnect..............................................14
11.1 Channel Binding Procedure in Full Authentication........16 12. Channel Binding.............................................17
11.2 Channel Binding Procedure in Fast Reconnect.............17 12.1 Channel Binding Procedure in Full Authentication........17
11.3 Channel Binding Error Indication........................17 12.2 Channel Binding Procedure in Fast Reconnect.............18
11.4 Notify Payload Types for Channel Binding................18 12.3 Channel Binding Error Indication........................18
11.5 Examples................................................19 12.4 Notify Payload Types for Channel Binding................19
12. Security Considerations.....................................23 12.5 Examples................................................20
12.1 General Considerations..................................23 13. Security Considerations.....................................24
12.2 Security Claims.........................................23 13.1 General Considerations..................................24
13. Open Issues.................................................25 13.2 Security Claims.........................................25
14. Normative References........................................26 14. IANA Considerations.........................................26
15. Informative References......................................26 15. Normative References........................................27
Acknowledgments.................................................27 16. Informative References......................................27
Author's Addresses..............................................27 Acknowledgments.................................................28
Intellectual Property Statement.................................28 Author's Addresses..............................................28
Disclaimer of Validity..........................................28 Intellectual Property Statement.................................29
Copyright Statement.............................................29 Disclaimer of Validity..........................................29
Acknowledgment..................................................29 Copyright Statement.............................................30
Acknowledgment..................................................30
1. Introduction 1. Introduction
This document specifies the EAP-IKEv2 authentication method. The This document specifies the EAP authentication method EAP-IKEv2.
main design goal for EAP-IKEv2 is to provide a flexible and The main design goal for EAP-IKEv2 is to provide a flexible and
efficient EAP method which makes the IKEv2 protocol's features efficient EAP method which makes security properties and exchanges
available for scenarios using EAP-based authentication. similar to these of the IKEv2 protocol available for all scenarios
using EAP-based authentication.
The main advantage of EAP-IKEv2 is that it does not define a new The main advantage of EAP-IKEv2 is that it does not define a new
cryptographic protocol, but re-uses the IKEv2 authentication cryptographic protocol, but re-uses the well-analyzed IKEv2
exchanges, and thereby provides strong, well-analyzed, authentication exchanges within the EAP framework. Thereby, it
cryptographic properties as well as broad flexibility. provides strong cryptographic properties as well as good
flexibility to support a large number of use cases.
EAP-IKEv2 especially provides an efficient shared-secret method EAP-IKEv2 especially provides an efficient shared-secret based
offering a high security level, and allows for password-derived authentication method offering a high security level, and allows
shared secrets while protecting from password-guessing attacks. for password-derived shared secrets while protecting from
password-guessing attacks.
EAP-IKEv2 provides mutual authentication between EAP peers. This It provides mutual authentication between EAP peers. This may be
may be based on either symmetric methods using pre-shared keys, based on either symmetric-key methods using pre-shared keys, or
or on asymmetric methods based on public/private key pairs, on asymmetric methods based on public/private key pairs,
Certificates and CRLs. It is possible to use different types of Certificates and CRLs. It is possible to use different types of
authentication for the different directions, e.g. the server uses authentication for the different directions, e.g. the server uses
certificate-based authentication whereas the client uses a certificate-based authentication whereas the client uses a
symmetric-key method. symmetric-key method.
IKEv2 supports two-phased authentication schemes by establishing By this, both AAA scenarios where public-key EAP-based
a server-authenticated secure tunnel and subsequently protecting authentication as well as scenarios requiring symmetric-key
an EAP authentication allowing for legacy client authentication EAP-based authentication are flexibly supported.
methods. EAP-IKEv2, however, does not support this optional
tunneling feature of IKEv2 in this version, which allows to
increase the EAP-IKEv2 method performance and to decrease
implementation complexity.
A non-goal of EAP-IKEv2 (and basically the major difference to 2. EAP-IKEv2 Overview
plain IKEv2) is the establishment of IPsec security associations,
as this would not make much sense in the standard AAA three-party
scenario, consisting of an EAP peer, an authenticator (NAS) and
a back-end authentication server terminating EAP. IPsec SA
establishment may be required locally (i.e., between the EAP peer
and some access server). However, SA establishment within an EAP
method would only provide SAs between the EAP peer and the back-end
authentication server. Other approaches as, e.g., the IETF PANA
framework are considered more appropriate in this case.
2. IKEv2 and EAP-IKEv2 Overview EAP-IKEv2 is an EAP authentication method that offers security
features similar to those offered by the IKEv2 protocol defined
for Internet key exchange. It defines exchanges and message
formats similar to exchanges and payloads specified by IKEv2 for
establishment of an IKE-SA.
IKEv2 [Kau04] is a protocol which consists of two exchanges: The basic successful EAP-IKEv2 exchange as specified in section
4 requires two roundtrips for authenticating EAP peer and server
that are followed by an EAP-Success message. An optional roundtrip
for exchanging EAP identities may precede the authentication
exchange.
In addition to the basic exchange, a fast reconnect method is
specified in section 11 to allow fast session resumption with
increased efficiency compared to an EAP-IKEv2 standard exchange.
(1) an authentication and key exchange protocol which establishes Section 5 details the handling of identities for EAP-IKEv2, since
an IKE-SA. identities occur in both the basic EAP exchange as well as the
specific EAP-IKEv2 authentication exchange.
(2) messages and payloads which focus on the negotiation of In section 6, the packet format for EAP-IKEv2 messages is
parameters in order to establish IPsec security associations specified, which is composed of the standard EAP request/response
(i.e., Child-SAs). These payloads contain algorithm parameters message and the EAP method specific formats that are derived from
and traffic selector fields. the original IKEv2 protocol specification.
In addition to the above-mentioned parts IKEv2 also includes some EAP-IKEv2 provides a secure fragmentation mechanism that is
payloads and messages which allow configuration parameters to be detailed in section 7 and details retransmission aspects in
exchanged primarily for remote access scenarios. section 8.
The EAP-IKEv2 method defined by this document uses the IKEv2 Key derivation as an important part of any EAP authentication
payloads and messages used for the initial IKEv2 exchange which method is specified in section 9 that details the method-specific
establishes an IKE-SA. behavior according to the overall EAP keying framework.
IKEv2 provides an improvement over IKEv1 [RFC2409] as described For security aspects, in section 12 a detailed discussion on
in Appendix A of [Kau04]. Important for this document are the channel binding to avoid security issues related to misbehaving
reduced number of initial exchanges, decreased latency of the EAP authenticators can be found. The general security
initial exchange, and some other fixes (e.g., hash problem). IKEv2 considerations for this EAP method are subsequently given in
is a cryptographically sound protocol that has received a section 13.
considerable amount of expert review and that benefits from a long
practical experience with IKE.
The goal of EAP-IKEv2 is to inherit these properties within an
efficient, secure EAP method.
In addition, IKEv2 provides authentication and key exchange In general, although EAP-IKEv2 reuses parts of the original IKEv2
capabilities which allow an entity to use symmetric as well as specification, it must be noted that the scenarios EAP-IKEv2 is
asymmetric authentication within a single protocol. Such intended for are clearly different from the scenarios covered by
flexibility is considered important for an EAP method and is IKEv2. Therefore, a number of mechanisms available in IKEv2 are
provided by EAP-IKEv2. not required, nor are they available, in EAP-IKEv2. For example,
the optional tunneling of IKEv2 (inner authentication method as
defined in [Kau04], section 3.16) is not supported by this version
of EAP-IKEv2.
[Per03] provides a good tutorial for IKEv2 design decisions. EAP-IKEv2 provides authentication between an EAP server and an EAP
peer in a single authentication exchange, or phase. In contrast,
IKEv2 [Kau04] itself is a protocol which consists of two phases
that can be run (but are not necessarily run) subsequently:
EAP-IKEv2 provides a secure fragmentation mechanism in which (1) an authentication and key exchange phase which establishes an
integrity protection is performed for each fragment of an IKEv2 IKE-SA.
message.
(2) a phase for the negotiation of parameters in order to establish
IPsec security associations. Such exchanges contain e.g.
algorithm parameters and traffic selector fields, and are
protected by the security established in the first phase.
The EAP-IKEv2 method does not include any exchange similar to the
above phase (2), since such functionality is not a requirement in
the context of common AAA scenarios, consisting of an EAP peer,
an authenticator (NAS) and a back-end authentication server.
There, IPsec SA establishment may be required locally (i.e.,
between the EAP peer and some access server). However, SA
establishment within an EAP method could only provide SAs between
the EAP peer and the back-end authentication server. Other
approaches as, e.g., the IETF PANA framework are considered more
appropriate in this case.
3. Terminology 3. Terminology
This document does not introduce new terms other than those defined This document does not introduce new terms other than those defined
in [RFC3748] or in [Kau04]. in [RFC3748] or in [Kau04].
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
this document, are to be interpreted as described in [RFC2119]. this document, are to be interpreted as described in [RFC2119].
4. Protocol overview 4. Protocol overview
This section provides some overview over EAP-IKEv2 message This section defines the basic EAP-IKEv2 message exchanges.
exchanges. Note that some mandatory IKEv2 payloads are omitted,
or profiled (such as SAi2 and SAr2), as it is not supported to
establish IPsec (ESP, AH) SAs in EAP-IKEv2.
IKEv2 uses the same protocol message exchanges for both symmetric The given exchanges are based on IKEv2 [Kau04].
and asymmetric authentication. The difference lies only in the
computation of the AUTH payload. See Section 2.15 of [Kau04] for
more information about the details of the AUTH payload
computation. It is even possible to combine symmetric (e.g., from
the client to the server) with asymmetric authentication (e.g.,
from the server to the client) in a single protocol exchange.
Figure 1 depicts such a protocol exchange.
Message exchanges are reused from [Kau04], and are adapted. Since All message exchanges take place between two parties - between the
this document does not describe frameworks or particular Initiator (I) and the Responder (R) of an exchange. In the context
architectures the message exchange takes place between two parties
- between the Initiator (I) and the Responder (R). In the context
of EAP the Initiator takes the role of the EAP server and the of EAP the Initiator takes the role of the EAP server and the
responder matches the EAP peer. responder matches the EAP peer.
The first message flow shows the EAP-IKEv2 full successful The first message flow shows the EAP-IKEv2 full successful
exchange. The core EAP-IKEv2 exchange (message (3) - (6)) consists authentication exchange. The core EAP-IKEv2 exchange (message (3)
of four messages (two round trips)_only. The first two messages to (6)) consists of four messages (two round trips)_only:
constitute the standard EAP identity exchange and are optional;
they are not required in case the EAP server is known. In the - Messages (3) and (4) negotiate cryptographic algorithms,
exchange, the EAP server (B) takes the role of the IKEv2 initiator exchange nonces, and perform a Diffie-Hellman exchange. This
and the EAP peer (A) acts as the IKEv2 responder. step is called EAP-IKE_SA_INIT exchange.
- Messages (5) and (6) authenticate the EAP-IKE_SA_INIT exchange,
and exchange the identities of Initiator and Responder (i.e.
the EAP server and peer) and certificates. This step is called
EAP-IKE_SA_AUTH exchange.
The first two messages (1) and (2) constitute the standard EAP
identity exchange and are optional; they are not required in case
the EAP server is known. The exchange is concluded with an
EAP-Success message (7) sent by the EAP server to the EAP peer.
In the exchange, the EAP server (B) takes the role of the Initiator
and the EAP peer (A) acts as the Responder.
1) A <-- B: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) HDR(A,B), SAr1, KEr, Nr, [CERTREQ])
5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDr, [CERT,] AUTH}) HDR(A,B), SK {IDr, [CERT,] AUTH})
7) A <-- B: EAP-Success 7) A <-- B: EAP-Success
Figure 1: EAP-IKEv2 successful message flow Figure 1: EAP-IKEv2 successful message flow
Descriptions of the EAP-IKEv2 message format, headers and payloads
are given in section 6.
Figure 2 shows the message flow in case the EAP peer fails to Figure 2 shows the message flow in case the EAP peer fails to
authenticate the EAP server. authenticate the EAP server. The difference to the above
successful exchange is that in message (6) the EAP peer answers
to the EAP server with an AUTHENTICATION_FAILED error. In message
(7), EAP-Failure is returned from the EAP server.
1) A <-- B: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) HDR(A,B), SAr1, KEr, Nr, [CERTREQ])
skipping to change at page 7, line 11 skipping to change at page 7, line 41
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(AUTHENTICATION_FAILED)}) HDR(A,B), SK {N(AUTHENTICATION_FAILED)})
7) A <-- B: EAP-Failure 7) A <-- B: EAP-Failure
Figure 2: EAP-IKEv2 with failed server authentication Figure 2: EAP-IKEv2 with failed server authentication
Figure 3 shows the message flow in case the EAP server fails to Figure 3 shows the message flow in case the EAP server fails to
authenticate the EAP peer. The EAP peer MUST send an empty authenticate the EAP peer. Compared to the successful exchange,
EAP-IKEv2 informational message in reply to the EAP server's error one additional roundtrip is required. In message (7) the EAP server
indication. The EAP server answers with an EAP-Failure. answers with an AUTHENTICATION_FAILED error instead of sending
EAP-Successs. The EAP peer, after receiving message (7), MUST send
an empty EAP-IKEv2 (informational) message in reply to the EAP
server's error indication, as shown in (8). The EAP server answers
with an EAP-Failure.
1) A <-- B: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) HDR(A,B), SAr1, KEr, Nr, [CERTREQ])
5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDr, [CERT,] AUTH}) HDR(A,B), SK {IDr, [CERT,] AUTH})
skipping to change at page 7, line 40 skipping to change at page 8, line 25
7) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 7) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(AUTHENTICATION_FAILED)}) HDR(A,B), SK {N(AUTHENTICATION_FAILED)})
8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {}) HDR(A,B), SK {})
9) A <-- B: EAP-Failure 9) A <-- B: EAP-Failure
Figure 3: EAP-IKEv2 with failed client authentication Figure 3: EAP-IKEv2 with failed client authentication
Since the goal of this EAP method is not to establish an IPsec SA Since the goal of this EAP method is not the goal of the original
some payloads used in IKEv2 are omitted. In particularly the IKEv2 protocol to establish IPsec security associations, some
following messages and payloads SHOULD not be sent: payloads that are specified in IKEv2 are not specified for
EAP-IKEv2 (as they do not occur in the message exchanges specified
- Traffic Selector (TS) payloads in this document). For example, the following messages and
- SA payloads that carry SA proposals for protocol IDs other than payloads are not specified for EAP-IKEv2::
1(IKE), i.e., SA payloads with protocol ID 2 (ESP) or 3 (AH)
- ESN (extended sequence number) transforms
Some of these messages and payloads are optional in IKEv2.
In general it does not make sense to directly negotiate IPsec SAs - Traffic Selector (TS) payloads ([Kau04], section 3.13).
within EAP-IKEv2, as such SAs are not required between the EAP - SA payloads ([Kau04], section 3.3) that carry SA proposals for
endpoints and as SAs cannot be transferred to different AAA protocol IDs other than 1(IKE), i.e., SA payloads with protocol
entities by standard AAA protocols. ID 2 (ESP) or 3 (AH)
- Configuration payloads ([Kau04], section 3.15).
- EAP payloads ([Kau04], section 3.16), since EAP tunnelling
within EAP-IKEv2 is not supported in this version of EAP-IKEv2.
Consequently, mechanisms and payloads that are not supported by Consequently, mechanisms that are part of IKEv2 but are not
EAP-IKEv2 are: required nor specified within EAP-IKEv2 are:
- ECN Notifications as specified in section 2.24 of [Kau04]. - ECN Notifications as specified in section 2.24 of [Kau04].
- IKE-specific port handling - IKE-specific port handling
- NAT traversal - NAT traversal
Since the EAP server acts as the initiator of the initial IKEv2
exchange, a number of optional payloads used for realizing
specific features in IKEv2 are not supported by EAP-IKEv2, as they
are intended for the client side (e.g. for corporate access
scenarios) in plain IKEv2. These payloads MUST not be sent by an
EAP-IKEv2 entity. EAP-IKEv2 entities receiving such payloads MUST
respond with the appropriate error messages as defined in [Kau04].
These payloads are:
- Configuration (CFG) payloads as specified in 3.15 of [Kau04].
These payloads MUST not be sent by an EAP-IKEv2 implementation.
EAP-IKEv2 entities receiving such payloads MUST ignore
configuration payloads as described for minimal implementations
in 3.15 of [Kau04].
- EAP payloads as specified in section 3.16 of [Kau04]. These
payloads allow to run an inner EAP exchange for secure legacy
authentication through an IKE SA. EAP-IKEv2 implementations
acting as initiator MUST include and AUTH payload in the initial
IKE_AUTH message (message 3 of the initial IKE exchange).
EAP-IKEv2 implementations receiving initial IKE_AUTH messages as
responders that indicate the initiator's desire to start extended
authentication MUST be answered with an AUTHENTICATION_FAILED
notification as the response.
IKEv2 provides optional functionality for additional DoS IKEv2 provides optional functionality for additional DoS
protection by adding a roundtrip to the initial exchanges, see protection by adding a roundtrip to the initial exchanges, see
section 2.xx of [Kau04]. As this is intended to protect the IKEv2 section 2.6 of [Kau04]. This is intended to protect the IKEv2
responder but in EAP-IKEv2 the EAP server takes the role of the responder. Because in EAP-IKEv2 the EAP server takes the role of
initiator, it is not recommended to use this feature of IKEv2 for the initiator, no similar feature is specified for EAP-IKEv2.
server protection.
5. Identities used in EAP-IKEv2 5. Identities used in EAP-IKEv2
A number of different places allow to convey identity information A number of different places allow to convey identity information
in IKEv2, when combined with EAP. This section describes their in IKEv2 as well as in EAP. This section describes identities and
function within the different exchanges of EAP-IKEv2. Note that their role within the different exchanges of EAP-IKEv2. Note that
EAP-IKEv2 does not introduce more identities than other EAP-IKEv2 does not introduce more identities than other
non-tunneling EAP methods. Figure 4 shows which identities are non-tunneling EAP methods. Figure 4 shows which identities are
used during the individual phases of the protocol. used during the individual phases of the protocol.
+-------+ +-------------+ +---------+ +-------+ +-------------+ +---------+
|Client | |Front-End | |AAA | |Client | |Front-End | |AAA |
| | |Authenticator| |Server | | | |Authenticator| |Server |
+-------+ +-------------+ +---------+ +-------+ +-------------+ +---------+
EAP/Identity-Request EAP/Identity-Request
<--------------------- <---------------------
(a) EAP/Identity-Response (a) EAP/Identity-Response
----------------------------------> ---------------------------------->
Tunnel-Establishment EAP-IKE_SA_INIT and AUTH exchange
(b) (Identities of IKEv2 are used) (b) (Identities of IKEv2 are used)
Server (Network) Authentication Server (Network) Authentication
<---------------------------------- <----------------------------------
... ...
----------------------------------> ---------------------------------->
Figure 4: Identities used in EAP-IKEv2 Figure 4: Identities used in EAP-IKEv2
a) The first part of the (outer) EAP message exchange provides a) The first part of the EAP message exchange provides information
information about the identities of the EAP endpoints. This about the identities of the EAP endpoints. This message exchange
message exchange mainly is an identity request/response. This mainly is an identity request/response. It is optional if the EAP
exchange is optional if the EAP server is known already or can be server is known already or can be learned by other means.
learned by other means.
b) Identities exchanged within EAP-IKEv2 for both the initiator b) Identities IDi and IDr are exchanged within the EAP-IKE_SA_INIT
and the responder. The initiator identity is often associated with and AUTH exchanges for both the initiator and the responder (EAP
a user identity such as a fully-qualified RFC 822 email address. server and peer).
The identity of the responder might be a FQDN. The identity is of
importance for authorization.
For carrying identities in EAP-IKEv2, implementations MUST follow For carrying identities in EAP-IKEv2, implementations MUST follow
the rules given in [Kau04], section 3.5, i.e., MUST be configurable the rules given in [Kau04], section 3.5, i.e., MUST be configurable
to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or
ID_KEY_ID, and MUST be configurable to accept all of these types. ID_KEY_ID, and MUST be configurable to accept all of these types.
Implementations SHOULD be capable of generating and accepting all Implementations SHOULD be capable of generating and accepting all
of these types. of these types.
6. Packet Format 6. Packet Format
The EAP-IKEv2 messages are EAP messages carrying the
authentication exchange embedded in the Data field of the standard
EAP Request/Response packets. The Code, Identifier, Length and
Type fields are described in [RFC3748]. These are followed by a
Type-Data field that carries one octet with method-specific Flags
as specified in section 7.
This EAP header is, embedded in the Data field, followed by the
method-specific header HDR and by one or more payloads of the
EAP-IKEv2 authentication data.
The IKEv2 payloads, which are defined in [Kau04], are embedded into The EAP Type for this EAP method is <TBD>.
the Data field of the standard EAP Request/Response packets. The
Code, Identifier, Length and Type field is described in [RFC3748].
The Type-Data field carries a one byte Flags field following the
IKEv2 payloads. Each IKEv2 payload starts with a header field HDR
(see [Kau04]).
The packet format is shown in Figure 5. The general packet format is shown in Figure 5.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Message Length | | Type | Flags | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | Data ... ~ | Message Length | HDR ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Checksum Data | | Integrity Checksum Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Packet Format Figure 5: EAP-IKEv2 general packet format
No additional packet formats other than those defined in [Kau04] The HDR payload that heads the Data field is as shown in Figure
5Figure 6 below. The HDR fields given in Figure 6 are used according
to [Kau04], section 3.1, where the EAP server acts as the initiator
and the EAP peer acts as the responder.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IKE_SA Initiator's SPI !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IKE_SA Responder's SPI !
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: HDR format
In contrast to the original IKEv2 protocol specified in [Kau04],
the HDR (IKE header data) is not carried within a UDP message, but
is directly embedded into the EAP message as shown above. However,
no additional packet formats other than those defined in [Kau04]
are required for this EAP method. are required for this EAP method.
The Flags field is used for fragmentation support. The S and F bits Following the header HDR are one or more payloads where each of
are reserved for future use. them is identified by a "Next Payload" field in the preceding
payload. Processing these payloads follows the rules specified by
[Kau04] section 3.2.
Each payload begins with a generic payload header as given in
Figure 7 followed by the payload data itself.
Currently five bits of the eight bit flags field are defined. The 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: generic payload header format
All payloads used within the EAP-IKEv2 messages defined by this
document are specified in [Kau04], sections 3.3. to 3.12 and 3.14.
7. Fragmentation support
The Flags field in HDR (see section 6) is used for fragmentation
support. The S and F bits are reserved for future use.
Currently three bits of the eight bit flags field are defined. The
remaining bits are set to zero. remaining bits are set to zero.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|S F L M I 0 0 0| |L M I 0 0 0 0 0|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
S = (reserved)
F = (reserved)
L = Length included L = Length included
M = More fragments M = More fragments
I = Integrity Checksum Data included I = Integrity Checksum Data included
EAP-IKEv2 messages which have neither the S nor the F flag set With regard to fragmentation we adopt the mechanism given in
contain regular IKEv2 message payloads inside the Data field. Section 2.8 of [PS+03]: The L indicates that a length field is
present and the M flag indicates fragments. The L flag MUST be set
With regard to fragmentation we follow the suggestions and for the first fragment and the M flag MUST be set on all fragments
descriptions given in Section 2.8 of [PS+03]: The L indicates that expect for the last one.
a length field is present and the M flag indicates fragments. The Reliable fragment delivery is provided by the retransmission
L flag MUST be set for the first fragment and the M flag MUST be mechanism of EAP.
set on all fragments expect for the last one. Each fragment sent
must subsequently be acknowledged.
The Message Length field is four octets long and present only if The Message Length field is four octets long and present only if
the L bit is set. This field provides the total message length that the L bit is set. This field provides the total message length that
is being fragmented (i.e., the length of the Data field.). is being fragmented (i.e., the length of the Data field.).
The Integrity Checksum Data is the cryptographic checksum of the The Integrity Checksum Data is the cryptographic checksum of the
entire EAP message starting with the Code field through the Data entire EAP message starting with the Code field through the Data
field. This field presents only if the I bit is set. The field field. This field presents only if the I bit is set. The field
immediately follows the Data field without adding any padding immediately follows the Data field without adding any padding
octet before or after itself. The checksum MUST be computed for octet before or after itself. The checksum MUST be computed for
each fragment (including the case where the entire IKEv2 message each fragment (including the case where the entire IKEv2 message
is carried in a single fragment) by using the same key (i.e., SK_ai is carried in a single fragment) by using the same key (i.e., SK_ai
or SK_ar) that is used for computing the checksum for the IKEv2 or SK_ar) that is used for computing the checksum for the IKEv2
Encrypted payload in the encapsulated IKEv2 message. The Encrypted payload in the encapsulated IKEv2 message. The
Integrity Checksum Data field is omitted for other packets. To Integrity Checksum Data field is omitted for other packets. To
minimize DoS attacks on fragmented packets, messages that are minimize DoS attacks on fragmented packets, messages that are not
not protected SHOULD NOT be fragmented. Note that IKE_SA_INIT protected SHOULD NOT be fragmented.
messages are the only ones that are not encrypted or integrity Note that EAP-IKE_SA_INIT messages are not encrypted or integrity
protected, however, such messages are not likely to be fragmented protected. However, they are not likely to be fragmented since they
since they do not carry certificates. do not carry certificates.
The EAP Type for this EAP method is <TBD>.
7. Retransmission 8. Retransmission
Since EAP authenticators support a timer-based retransmission Since EAP authenticators support a timer-based retransmission
mechanism for EAP Requests and EAP peers retransmit the last valid mechanism for EAP Requests and EAP peers retransmit the last valid
EAP Response when receiving a duplicate EAP Request message, IKEv2 EAP Response when receiving a duplicate EAP Request message, IKEv2
messages MUST NOT be retransmitted based on timers, when used as messages MUST NOT be retransmitted based on timers, when used as
EAP authentication method. EAP authentication method.
8. Key derivation 9. Key derivation
The EAP-IKEv2 method described in this document generates session The EAP-IKEv2 method described in this document generates session
keys. On the one hand, these session keys are used within the keys. On the one hand, these session keys are used within the
IKE-SA, for protection of EAP-IKEv2 payloads, e.g., AUTH exchanges IKE-SA, for protection of EAP-IKEv2 payloads, e.g., AUTH exchanges
or notifications. On the other hand, additional keys are derived or notifications. On the other hand, additional keys are derived
to be exported as part of the EAP keying framework [AS+05] (i.e., to be exported as part of the EAP keying framework [AS+05] (i.e.,
MSK, EMSK and IV). It is good cryptographic security practice to MSK, EMSK and IV).
use different keys for different "applications". Hence we suggest For key derivation, EAP-IKEv2 reuses the key derivation function
reusing of the key derivation function suggested in Section 2.17 as specified in Section 2.17 of [Kau04] to create keying material
of [Kau04] to create keying material KEYMAT. KEYMAT.
The key derivation function defined is KEYMAT = prf+(SK_d, Ni | The key derivation function defined is KEYMAT = prf+(SK_d, Ni |
Nr), where Ni and Nr are the Nonces from the IKE_SA_INIT exchange. Nr), where Ni and Nr are the Nonces from the EAP-IKE_SA_INIT
exchange.
Since the required amount of keying material is greater than the Since the required amount of keying material is greater than the
size of the output of the prf algorithm the prf is used iteratively. size of the output of the prf algorithm the prf is used iteratively.
Section 2.13 of [Kau04] describes this mechanism in detail. Iteration is applied as specified in section 2.13 of [Kau04].
According to [AS+05] the keying material of MSK, EMSK and IV have
to be at minimum 64, 64 and 64 octets long.
The produced keying material for MSK, EMSK and IV MUST be at least The produced keying material for MSK, EMSK and IV MUST be 64 octets
the minimum size (i.e., 64 octets). The keying material KEYMAT long for each MSK, EMSK and IV.
is split into the MSK, EMSK and IV part.
Figure 6 describes the keying hierarchy of EAP-IKEv2 graphically. Figure 8 describes the keying hierarchy of EAP-IKEv2 graphically.
This figure is adopted from Figure 2 of [AS+05]. This figure is adopted from Figure 2 of [AS+05].
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+
| | ^ | | ^
| EAP-IKEv2 Method | | | EAP-IKEv2 Method | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +------------------+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +------------------+ | |
| | EAP-IKEv2 Diffie-Hellmann | | EAP-IKEv2 prot. | | | | | EAP-IKEv2 Diffie-Hellmann | | EAP-IKEv2 prot. | | |
| | derived and authenticated key | | session specific | | | | | derived and authenticated key | | session specific | | |
| | SK_d | | state (Nonce i,j)| | | | | SK_d | | state (Nonce i,j)| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +-------------+----+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +-------------+----+ | |
skipping to change at page 13, line 12 skipping to change at page 14, line 12
| Naming & Binding | |(Not Secret) | | | Naming & Binding | |(Not Secret) | |
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V
Legend: Legend:
MSK = Master Session Key (512 Bit) MSK = Master Session Key (512 Bit)
EMSK = Extended Master Session Key (512 Bit) EMSK = Extended Master Session Key (512 Bit)
SK_d = Session key derived by EAP-IKEv2 SK_d = Session key derived by EAP-IKEv2
IV = Initialization Vector IV = Initialization Vector
Figure 6: EAP-IKEv2 Keying Hierarchy Figure 8: EAP-IKEv2 Keying Hierarchy
9. Error Handling 10. Error Handling
As described in the IKEv2 specification, there are many kinds of As described in the IKEv2 specification, there are many kinds of
errors that can occur during IKE processing (i.e., processing the errors that can occur during IKE processing (i.e., processing the
Data field of EAP-IKEv2 Request and Response messages) and Data field of EAP-IKEv2 Request and Response messages) and
detailed processing rules. EAP-IKEv2 follows the error handling detailed processing rules. EAP-IKEv2 follows the error handling
rules specified in the IKEv2 specification for errors on the Data rules specified in the IKEv2 specification for errors on the Data
field of EAP-IKEv2 messages, with the following additional rules: field of EAP-IKEv2 messages, with the following additional rules:
For an IKEv2 error that triggers an initiation of an IKEv2 exchange For an IKEv2 error that triggers an initiation of an IKEv2 exchange
(i.e., an INFORMATIONAL exchange), an EAP-IKEv2 message that (i.e., an INFORMATIONAL exchange), an EAP-IKEv2 message that
skipping to change at page 13, line 41 skipping to change at page 14, line 41
exchange, the EAP message that carries the erroneous IKEv2 message exchange, the EAP message that carries the erroneous IKEv2 message
MUST be treated as an invalid EAP message and discarded as if it MUST be treated as an invalid EAP message and discarded as if it
were not received at EAP layer. were not received at EAP layer.
For an error occurred outside the Data field of EAP-IKEv2 messages, For an error occurred outside the Data field of EAP-IKEv2 messages,
including defragmentation failures, integrity check failures, including defragmentation failures, integrity check failures,
errors in Flag and Message Length fields, the EAP message that errors in Flag and Message Length fields, the EAP message that
caused the error MUST be treated as an invalid EAP message and caused the error MUST be treated as an invalid EAP message and
discarded as if it were not received at EAP layer. discarded as if it were not received at EAP layer.
When the EAP-IKEv2 method runs on a backend EAP server, an When the EAP-IKEv2 method runs on a backend EAP server, the error
outstanding EAP Request is not retransmitted based on timer and handling rules defined in Section 2.2 of [RFC3579] are applied for
thus there is a possibility of EAP conversation stall when the EAP invalid EAP-IKEv2 messages.
server receives an invalid EAP Response. To avoid this, the EAP
server MAY retransmit the outstanding EAP Request in response to
an invalid EAP Response. Alternatively, the EAP server MAY send
a new EAP Request in response to an invalid EAP Response with
assigning a new Identifier and putting the last transmitted IKEv2
message in the Data field.
10. Fast Reconnect 11. Fast Reconnect
EAP-IKEv2 supports fast reconnect, i.e., a successful reconnect EAP-IKEv2 supports fast reconnect, i.e., a successful reconnect
exchange creates a new IKE-SA by using an IKE CHILD_SA exchange. exchange creates a new IKE-SA by using a method similar to the IKE
The purpose of a re-authentication exchange is to allow for CHILD_SA exchange defined in [KAU04]. The purpose of a
efficient re-keying based on the existing IKE-SA in situations re-authentication exchange is to allow for efficient re-keying
where (depending on the given security policy) no full based on the existing IKE-SA in situations where (depending on the
authentication is required in case of an existing EAP-IKEv2 given security policy) no full authentication is required in case
security context. of an existing EAP-IKEv2 security context.
The fast reconnect exchange uses the IKE-SA rekeying as specified
in section 2.18 of [Kau04]. However, the exchanges for EAP-IKEv2 The fast reconnect exchange is similar to the IKE-SA rekeying
do not use rekeying payloads other than IKE SAs: procedure as specified in section 2.18 of [Kau04]. However, the
- The TS (traffic selector) payloads SHOULD not be sent by exchanges for EAP-IKEv2 that are specified below do not use
EAP-IKEv2 implementations. rekeying payloads other than IKE SAs:
- The [N] payload (REKEY_SA notification) SHOULD not be sent by
EAP-IKEv2 implementations. - The TS (traffic selector) payloads are not used in EAP-IKEv2.
- The [N] payload (REKEY_SA notification) is not sent by EAP-IKEv2.
During fast re-authentication, the new IKE_SA is computed as During fast re-authentication, the new IKE_SA is computed as
specified in [Kau04], section 2.18. The new keying material specified in [Kau04], section 2.18. The new keying material
derived from this IKE_SA is computed as in an initial EAP-IKEv2 derived from this IKE_SA is computed in the same way as in an
authentication exchange. initial EAP-IKEv2 authentication exchange.
Fast re-authentication allows for an optional new Diffie-Hellman Fast re-authentication allows for an optional fresh
exchange. Diffie-Hellman exchange in case the payloads Kei and KEr are
included.
The following exchange provides fast reconnect for EAP-IKEv2, The following exchanges specify fast reconnect for EAP-IKEv2,
where A is the EAP peer (IKE responder) and B is the EAP server where A is the EAP peer (responder) and B is the EAP server
(IKE initiator): (initiator):
1) A <-- B: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
HDR, SK {SA, Ni, [KEi]}) HDR, SK {SA, Ni, [KEi]})
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR, SK {SA, Nr, [KEr]}) HDR, SK {SA, Nr, [KEr]})
5) A <-- B: EAP-Success 5) A <-- B: EAP-Success
Figure 7: Fast Reconnect Message Flow Figure 9: Fast Reconnect exchange
The first two messages constitute the standard EAP identity The first two messages constitute the standard EAP identity
exchange and are optional; they are not required in case the EAP exchange and are optional; they are not required in case the EAP
server is known. server is known. Messages (3) and (4) establish the new IKE SA.
The successful fast reconnect is concluded by an EAP-Success sent
by the EAP server.
Figure 8 shows the fast reconnect message flow in case the EAP peer Figure 10 shows the fast reconnect message flow in case the EAP
fails to re-authenticate the EAP server. peer fails to re-authenticate the EAP server.
1) A <-- B: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2
(HDR, SK {SA, Ni, [KEi]}) (HDR, SK {SA, Ni, [KEi]})
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR, SK {N(AUTHENTICATION_FAILED)}) HDR, SK {N(AUTHENTICATION_FAILED)})
5) A <-- B: EAP-Failure 5) A <-- B: EAP-Failure
Figure 8: EAP-IKEv2 fast reconnect Figure 10: EAP-IKEv2 fast reconnect
(server authentication failed) (server authentication failed)
Figure 9 shows the fast reconnect message flow in case the EAP Figure 11 shows the fast reconnect message flow in case the EAP
server fails to re-authenticate the EAP peer. The EAP peer MUST server fails to re-authenticate the EAP peer. The EAP peer MUST
send an empty EAP-IKEv2 informational message in reply to the EAP send an empty EAP-IKEv2 informational message (empty encrypted
server's error indication. The EAP server answers with an payload) in reply to the EAP server's error indication, as shown
EAP-Failure. in (6) below. The EAP server answers with an EAP-Failure.
1) A <-- B: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
HDR, SK {SA, Ni, [KEi]}) HDR, SK {SA, Ni, [KEi]})
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR, SK {SA, Nr, [KEr]}) HDR, SK {SA, Nr, [KEr]})
5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(AUTHENTICATION_FAILED)}) HDR(A,B), SK {N(AUTHENTICATION_FAILED)})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {}) HDR(A,B), SK {})
7) A <-- B: EAP-Failure 7) A <-- B: EAP-Failure
Figure 9: EAP-IKEv2 fast reconnect Figure 11: EAP-IKEv2 fast reconnect
(client authentication failed) (client authentication failed)
IKE_SAs do not have lifetimes. Such lifetimes are therefore set Note: The original IKEv2 protocol supports fast rekeying to be
by local policies of the peers. Typically the peer setting the initiated by both peers. IKE_SAs do not have lifetimes. Such
shorter lifetime will therefore trigger the reconnect procedure. lifetimes are therefore set by local policies. Typically the peer
setting the shorter lifetime will therefore trigger the reconnect
Note: IKEv2 supports fast rekeying to be initiated by both peers. procedure in IKEv2.
In EAP-IKEv2, the EAP server initiates the rekeying as this results In EAP-IKEv2, the EAP authenticator or server initiate the
in the most efficient message flow. If the client initiates fast rekeying as this results in the most efficient message flow. If
rekeying, it needs to indicate this to the network by appropriate the client initiates fast rekeying, it needs to indicate this to
out-of-band (e.g. link-layer) means. the network by appropriate out-of-band (e.g. link-layer) means.
11. Channel Binding 12. Channel Binding
EAP-IKEv2 provides a channel binding functionality [RFC3784] in EAP-IKEv2 provides a channel binding functionality [RFC3784] in
order for the EAP peer and EAP server to make sure that the both order for the EAP peer and EAP server to make sure that the both
entities are given the same network access attributes such as entities are given the same network access attributes such as
Calling-Station-Id, Called-Station-Id, and NAS-Port-Type by the Calling-Station-Id, Called-Station-Id, and NAS-Port-Type by the
NAS. This is achieved by using Notify payloads to exchange NAS. This is achieved by using Notify payloads to exchange
attribute data between the EAP peer and EAP server. attribute data between the EAP peer and EAP server.
A Notify payload that carries a null channel binding attribute is A Notify payload that carries a null channel binding attribute is
referred to as a channel binding request. A Notify payload which referred to as a channel binding request. A Notify payload which
skipping to change at page 16, line 40 skipping to change at page 17, line 36
attribute types in a single IKEv2 message. A set of channel binding attribute types in a single IKEv2 message. A set of channel binding
exchanges performed in a single round of EAP-IKEv2 full exchanges performed in a single round of EAP-IKEv2 full
authentication or fast reconnect is referred to as a channel authentication or fast reconnect is referred to as a channel
binding procedure. binding procedure.
A Notify payload that is used for reporting an error occurred A Notify payload that is used for reporting an error occurred
during a channel binding exchange is referred to as a channel during a channel binding exchange is referred to as a channel
binding error indication. binding error indication.
EAP-IKEv2 offers a protected result indication mechanism (see EAP-IKEv2 offers a protected result indication mechanism (see
section 12.2). To receive protected result indication, the EAP section 13.2). To receive protected result indication, the EAP
server MUST initiate a channel binding exchange as specified in server MUST initiate a channel binding exchange as specified in
Figure 10, message 5. As a result of this channel binding exchange, Figure 12, message 5. As a result of this channel binding exchange,
the client will receive a protected result indication, because the the client will receive a protected result indication, because the
server will initiate an informational exchange as part of the server will initiate an informational exchange as part of the
channel binding procedure (messages 7 and 8) through the new IKE-SA channel binding procedure (messages 7 and 8) through the new IKE-SA
that results from a successful reconnect procedure. that results from a successful reconnect procedure.
11.1 Channel Binding Procedure in Full Authentication 12.1 Channel Binding Procedure in Full Authentication
In the case of EAP-IKEv2 full authentication procedure, the In the case of EAP-IKEv2 full authentication procedure, the
channel binding procedure is performed in the following way. channel binding procedure is performed in the following way.
The EAP peer MAY include one or more channel binding request in The EAP peer MAY include one or more channel binding request in
an IKE_SA_INIT response. The EAP server MAY include one or more an IKE_SA_INIT response. The EAP server MAY include one or more
channel binding request in an IKE_AUTH request. When the EAP server channel binding request in an IKE_AUTH request. When the EAP server
receives an IKE_SA_INIT response with one or more channel binding receives an IKE_SA_INIT response with one or more channel binding
request, it MUST include the corresponding channel binding request, it MUST include the corresponding channel binding
response(s) an IKE_AUTH request (in addition to its channel response(s) an IKE_AUTH request (in addition to its channel
skipping to change at page 17, line 23 skipping to change at page 18, line 19
the corresponding channel binding response(s) in an IKE_AUTH the corresponding channel binding response(s) in an IKE_AUTH
response. response.
When the EAP server successfully validates all the channel binding When the EAP server successfully validates all the channel binding
response(s) sent by the EAP server, it initiates an INFORMATIONAL response(s) sent by the EAP server, it initiates an INFORMATIONAL
exchange, where an empty payload is used in both INFORMATIONAL exchange, where an empty payload is used in both INFORMATIONAL
request and INFORMATIONAL response. This exchange serves as a request and INFORMATIONAL response. This exchange serves as a
protected success indication. After completion of this protected success indication. After completion of this
INFORMATIONAL exchange, the EAP server sends Success message. INFORMATIONAL exchange, the EAP server sends Success message.
11.2 Channel Binding Procedure in Fast Reconnect 12.2 Channel Binding Procedure in Fast Reconnect
In the case of EAP-IKEv2 fast reconnect, the channel binding In the case of EAP-IKEv2 fast reconnect, the channel binding
procedure is performed in the following way. procedure is performed in the following way.
In the pair of CREATE_CHILD_SA exchange, the EAP peer and/or the In the pair of CREATE_CHILD_SA exchange, the EAP peer and/or the
EAP server MAY include one or more channel binding request, one EAP server MAY include one or more channel binding request, one
for each channel binding attribute that needs validation. When for each channel binding attribute that needs validation. When
the EAP peer receives a CREATE_CHILD_SA request with containing the EAP peer receives a CREATE_CHILD_SA request with containing
one or more channel binding request, it MUST contain channel one or more channel binding request, it MUST contain channel
binding response(s) in the CREATE_CHILD_SA response, as well as binding response(s) in the CREATE_CHILD_SA response, as well as
skipping to change at page 17, line 47 skipping to change at page 18, line 43
response, if it has one or more channel binding response to send response, if it has one or more channel binding response to send
to the EAP peer, it initiates an INFORMATIONAL exchange to the EAP peer, it initiates an INFORMATIONAL exchange
immediately after completion of the CREATE_CHILD_SA exchange, immediately after completion of the CREATE_CHILD_SA exchange,
where one or more channel binding response is carried in the where one or more channel binding response is carried in the
INFORMATIONAL request. If the EAP peer successfully validates the INFORMATIONAL request. If the EAP peer successfully validates the
channel binding response(s), it MUST respond with an empty channel binding response(s), it MUST respond with an empty
INFORMATIONAL response. This exchange serves as a protected INFORMATIONAL response. This exchange serves as a protected
success indication. After completion of this INFORMATIONAL success indication. After completion of this INFORMATIONAL
exchange, the EAP server sends Success message. exchange, the EAP server sends Success message.
11.3 Channel Binding Error Indication 12.3 Channel Binding Error Indication
A channel binding error is detected by the EAP peer or EAP server A channel binding error is detected by the EAP peer or EAP server
when (i) a channel binding response is not contained in the when (i) a channel binding response is not contained in the
expected IKEv2 message or (ii) a channel binding response is expected IKEv2 message or (ii) a channel binding response is
contained in the expected IKEv2 message but the channel binding contained in the expected IKEv2 message but the channel binding
attribute does not have the expected value. Whenever a channel attribute does not have the expected value. Whenever a channel
binding error is detected, the detecting entity MUST send a channel binding error is detected, the detecting entity MUST send a channel
binding error indication to its peering entity. In case of (ii), binding error indication to its peering entity. In case of (ii),
the channel binding error indication MUST contain the channel the channel binding error indication MUST contain the channel
binding attribute that caused the error. binding attribute that caused the error.
skipping to change at page 18, line 19 skipping to change at page 19, line 17
When the EAP server detects a channel binding error, a channel When the EAP server detects a channel binding error, a channel
binding error indication MUST be carried in an INFORMATIONAL binding error indication MUST be carried in an INFORMATIONAL
request, and the EAP peer MUST respond with an empty INFORMATIONAL request, and the EAP peer MUST respond with an empty INFORMATIONAL
response. response.
When the EAP peer detects a channel binding error, a channel When the EAP peer detects a channel binding error, a channel
binding error indication MUST be carried in an IKEv2 error binding error indication MUST be carried in an IKEv2 error
reporting message for which the R-flag of the IKEv2 header MUST reporting message for which the R-flag of the IKEv2 header MUST
be set. The EAP server MUST respond with EAP-Failure message when be set. The EAP server MUST respond with EAP-Failure message when
it receives such a channel binding error indication. it receives such a channel binding error indication.
11.4 Notify Payload Types for Channel Binding 12.4 Notify Payload Types for Channel Binding
The following Notify Payload types are defined for the purpose of The following Notify Payload types are defined for the purpose of
channel binding exchange. channel binding exchange.
CALLING_STATION_ID TBD CALLING_STATION_ID TBD
The payload data in a channel binding response of this type The payload data in a channel binding response of this type
contains octet string representation of contains octet string representation of
Calling-Station-Id value known to the EAP server by using Calling-Station-Id value known to the EAP server by using
an external mechanism. an external mechanism.
skipping to change at page 19, line 27 skipping to change at page 20, line 25
----------------------+--------------------------------------- ----------------------+---------------------------------------
CALLING_STATION_ID EAP server CALLING_STATION_ID EAP server
CALLED_STATION_ID EAP peer CALLED_STATION_ID EAP peer
NAS_PORT_TYPE EAP server NAS_PORT_TYPE EAP server
Table 1: Channel Binding Attribute Types and Requesting Table 1: Channel Binding Attribute Types and Requesting
Entities Entities
11.5 Examples 12.5 Examples
In the figures of this section, a Notify payload tagged with '*' In the figures of this section, a Notify payload tagged with '*'
indicates a Notify payload with null data (i.e., a channel binding indicates a Notify payload with null data (i.e., a channel binding
request). a Notify payload no tagged with '*' indicates a Notify request). a Notify payload no tagged with '*' indicates a Notify
payload with non-null data (i.e., a channel binding response). payload with non-null data (i.e., a channel binding response).
Figure 10 shows an example of EAP-IKEv2 authentication sequence Figure 12 shows an example of EAP-IKEv2 authentication sequence
with a successful channel binding procedure. The first two with a successful channel binding procedure. The first two
messages constitute the standard EAP identity exchange and are messages constitute the standard EAP identity exchange and are
optional. optional.
1) A <-- B: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
skipping to change at page 20, line 21 skipping to change at page 21, line 19
N(NAS_PORT_TYPE)}) N(NAS_PORT_TYPE)})
7) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 7) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {}) HDR(A,B), SK {})
8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {}) HDR(A,B), SK {})
9) A <-- B: EAP-Success 9) A <-- B: EAP-Success
Figure 10: EAP-IKEv2 with successful channel binding Figure 12: EAP-IKEv2 with successful channel binding
Figure 11 shows an example of EAP-IKEv2 authentication sequence Figure 13 shows an example of EAP-IKEv2 authentication sequence
when the EAP server detects an error in a channel binding when the EAP server detects an error in a channel binding
procedure. The first two messages constitute the standard EAP procedure. The first two messages constitute the standard EAP
identity exchange and are optional. In this case, message 7) and identity exchange and are optional. In this case, message 7) and
8) MUST constitute an INFORMATIONAL exchange. 8) MUST constitute an INFORMATIONAL exchange.
1) A <-- B: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
skipping to change at page 21, line 10 skipping to change at page 22, line 8
N(NAS_PORT_TYPE)}) N(NAS_PORT_TYPE)})
7) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 7) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(INVALID_CALLING_STATION_ID)}) HDR(A,B), SK {N(INVALID_CALLING_STATION_ID)})
8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {}) HDR(A,B), SK {})
9) A <-- B: EAP-Failure 9) A <-- B: EAP-Failure
Figure 11: EAP-IKEv2 with channel binding error Figure 13: EAP-IKEv2 with channel binding error
(detected by EAP server) (detected by EAP server)
Figure 12 shows an example of EAP-IKEv2 authentication sequence Figure 14 shows an example of EAP-IKEv2 authentication sequence
when the EAP peer detects an error in a channel binding procedure. when the EAP peer detects an error in a channel binding procedure.
The first two messages constitute the standard EAP identity The first two messages constitute the standard EAP identity
exchange and are optional. exchange and are optional.
1) A <-- B: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
skipping to change at page 21, line 39 skipping to change at page 22, line 37
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH, HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH,
N(CALLED_STATION_ID), N(CALLED_STATION_ID),
N(CALLING_STATION_ID*), N(CALLING_STATION_ID*),
N(NAS_PORT_TYPE*)}) N(NAS_PORT_TYPE*)})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(INVALID_CALLED_STATION_ID)}) HDR(A,B), SK {N(INVALID_CALLED_STATION_ID)})
7) A <-- B: EAP-Failure 7) A <-- B: EAP-Failure
Figure 12: EAP-IKEv2 with channel binding error Figure 14: EAP-IKEv2 with channel binding error
(detected by EAP peer) (detected by EAP peer)
Figure 13 shows an example of EAP-IKEv2 fast reconnection sequence Figure 15 shows an example of EAP-IKEv2 fast reconnection sequence
with a successful channel binding procedure. The first two with a successful channel binding procedure. The first two
messages constitute the standard EAP identity exchange and are messages constitute the standard EAP identity exchange and are
optional. optional.
1) A <-- B: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,] 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,]
N(CALLING_STATION_ID*), N(CALLING_STATION_ID*),
N(NAS_PORT_TYPE*)}) N(NAS_PORT_TYPE*)})
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {SA, Nr, [KEr,] 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {SA, Nr, [KEr,]
N(CALLED_STATION_ID*), N(CALLED_STATION_ID*),
N(CALLING_STATION_ID), N(CALLING_STATION_ID),
N(NAS_PORT_TYPE)}) N(NAS_PORT_TYPE)})
5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(CALLED_STATION_ID)}) HDR(A,B), SK {N(CALLED_STATION_ID)})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,B), SK {}) 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,B), SK {})
7) A <-- B: EAP-Success 7) A <-- B: EAP-Success
Figure 13: Fast reconnect with channel binding error Figure 15: Fast reconnect with channel binding error
(fast reconnect) (fast reconnect)
Figure 14 shows an example of EAP-IKEv2 fast reconnect sequence Figure 16 shows an example of EAP-IKEv2 fast reconnect sequence
when the EAP server detects an error in a channel binding when the EAP server detects an error in a channel binding
procedure. The first two messages constitute the standard EAP procedure. The first two messages constitute the standard EAP
identity exchange and are optional. In this case, message 7) and identity exchange and are optional. In this case, message 7) and
8) MUST constitute an INFORMATIONAL exchange. 8) MUST constitute an INFORMATIONAL exchange.
1) A <-- B: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,] 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,]
skipping to change at page 22, line 50 skipping to change at page 23, line 48
N(NAS_PORT_TYPE)}) N(NAS_PORT_TYPE)})
5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(INVALID_CALLING_STATION_ID)}) HDR(A,B), SK {N(INVALID_CALLING_STATION_ID)})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {}) HDR(A,B), SK {})
7) A <-- B: EAP-Failure 7) A <-- B: EAP-Failure
Figure 14: Fast reconnect with channel binding error Figure 16: Fast reconnect with channel binding error
(detected by EAP server) (detected by EAP server)
Figure 15 shows an example of EAP-IKEv2 fast reconnect sequence Figure 17 shows an example of EAP-IKEv2 fast reconnect sequence
when the EAP peer detects an error in a channel binding procedure. when the EAP peer detects an error in a channel binding procedure.
The first two messages constitute the standard EAP identity The first two messages constitute the standard EAP identity
exchange and are optional. exchange and are optional.
1) A <-- B: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,] 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,]
N(CALLING_STATION_ID*), N(CALLING_STATION_ID*),
skipping to change at page 23, line 31 skipping to change at page 24, line 31
N(NAS_PORT_TYPE)}) N(NAS_PORT_TYPE)})
5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(CALLED_STATION_ID)}) HDR(A,B), SK {N(CALLED_STATION_ID)})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(INVALID_CALLED_STATION_ID)}) HDR(A,B), SK {N(INVALID_CALLED_STATION_ID)})
7) A <-- B: EAP-Failure 7) A <-- B: EAP-Failure
Figure 15: Fast reconnect with channel binding error Figure 17: Fast reconnect with channel binding error
(detected by EAP peer) (detected by EAP peer)
12. Security Considerations 13. Security Considerations
12.1 General Considerations 13.1 General Considerations
The security of the proposed EAP method is intentionally based on The security of EAP-IKEv2 is intentionally based on IKEv2 [Kau04].
IKEv2 [Kau04]. Therefore, the security claims of EAP-IKEv2 are Therefore, the security claims of EAP-IKEv2 are derived mainly
derived from the security offered by the supported features of from the security offered by the supported features of IKEv2.
IKEv2.
12.2 Security Claims IKEv2 provides an improvement over IKEv1 [RFC2409] as described
in Appendix A of [Kau04]. Important for this document are the
reduced number of initial exchanges, decreased latency of the
initial exchange, and some other fixes (e.g., hash problem). IKEv2
is a cryptographically sound protocol that has received a
considerable amount of expert review and that benefits from a long
practical experience with IKE.
In addition, IKEv2 provides authentication and key exchange
capabilities which allow an entity to use symmetric as well as
asymmetric authentication within a single protocol. Such
flexibility is considered important for an EAP method and is
provided by EAP-IKEv2.
[Per03] provides a good tutorial for IKEv2 design decisions.
13.2 Security Claims
Authentication mechanism: Authentication mechanism:
Mutual authentication is supported based on either pre-shared Mutual authentication is supported based on either pre-shared
symmetric keys or public/private key pairs. Besides certificates, symmetric keys or public/private key pairs. Besides certificates,
plain public keys can be used. It is possible to use different types plain public keys can be used. It is possible to use different types
of authentication for the different directions within one of authentication for the different directions within one
authentication exchange. An example is the server using authentication exchange. An example is the server using
certificate-based authentication and the client using pre-shared certificate-based authentication and the client using pre-shared
secrets. secrets.
Password-based authentication should only be used in IKEv2 with EAP-IKEv2 changes the roles regarding password usage: The EAP
extended authentication (EAP tunneling), which is not supported server acts as initiator, the remote peer as responder. This
by this version of EAP-IKEv2. Without extended authentication, the results in an exchange which protects user authentication (based
use of passwords (i.e., password-derived shared secrets) is on a shared secret derived from a user password) to the network
discouraged for IKEv2. through an already network (initiator-) authenticated, secured
In contrast, EAP-IKEv2 changes the roles regarding password usage: IKEv2 SA (see e.g. message 6 of Figure 1). This prevents an attacker
The EAP server acts as initiator, the remote peer as responder. from launching password-guessing attacks on the peer-generated
This results in an exchange which protects user authentication AUTH value.
(based on a shared secret derived from a user password) to the
network through an already network (initiator-) authenticated,
secured IKEv2 SA (see e.g. message 6 of Figure 1). This prevents
an attacker from launching password-guessing attacks on the
peer-generated AUTH value.
Therefore, dictionary attacks are not applicable in the context Therefore, dictionary attacks are not applicable in the context
of EAP-IKEv2 in the case the EAP peer uses a password-derived of EAP-IKEv2 in the case the EAP peer uses a password-derived
shared secret. shared secret.
Man-in-the-middle attacks discovered in the context of tunneled Man-in-the-middle attacks discovered in the context of tunneled
authentication protocols (see [AN03] and [PL+03]) are not authentication protocols (see [AN03] and [PL+03]) are not
applicable to EAP-IKEv2 as the extended authentication feature of applicable to EAP-IKEv2 as the extended authentication feature of
IKEv2 is not supported. Hence, the cryptographic binding claim is IKEv2 is not supported by EAP-IKEv2. Hence, the cryptographic
not applicable. binding claim is not applicable.
Ciphersuite negotiation is supported as specified in IKEv2 for Ciphersuite negotiation is supported as specified in IKEv2 for
IKE-SAs. The negotiation for IPsec (Child) SAs is not supported, IKE-SAs. The negotiation for IPsec (Child) SAs is not supported,
as such SAs are not generated by EAP-IKEv2. as such SAs are not generated by EAP-IKEv2.
Protected result indication as described in section 7.16 of Protected result indication as described in section 7.16 of
[RFC3748] is optionally provided by EAP-IKEv2. In message 5 of [RFC3748] is optionally provided by EAP-IKEv2. In message 5 of
figure 1 (full successful authentication) the EAP server figure 1 (full successful authentication) the EAP server
authenticates to the client. Message 6 authenticates the client authenticates to the client. Message 6 authenticates the client
to the server, and the client by authenticating the server and by to the server, and the client by authenticating the server and by
sending message 6 expresses that it is willing to accept access. sending message 6 expresses that it is willing to accept access.
The client, however, does not get a protected result indication The client, however, does not get a protected result indication
from the server in this case. An attacker could potentially forge from the server in this case. An attacker could potentially forge
an EAP success/failure message which could result in DoS to the an EAP success/failure message which could result in DoS to the
client. In some situations, synchronization may be achieved by client. In some situations, synchronization may be achieved by
lower layer indications. lower layer indications.
Protected result indication is optionally provided as specified Protected result indication is optionally provided as specified
in section 11. in section 12.
If this mechanism is not used, the recommended behavior for the If this mechanism is not used, the recommended behavior for the
client is to assume the correct establishment of a new IKE-SA after client is to assume the correct establishment of a new IKE-SA after
sending message 6, independent of the receipt of an EAP sending message 6, independent of the receipt of an EAP
success/failure. In case of unsuccessful authentication, the success/failure. In case of unsuccessful authentication, the
server would answer with an IKEv2 notification (which, in case of server would answer with a notification (which, in case of the fast
the fast reconnect exchange, would be protected by the old IKE-SA). reconnect exchange, would be protected by the old IKE-SA). In case
In case of a lost message 6, the server would retransmit message of a lost message 6, the server would retransmit message 5,
5, indicating the message loss to the client. indicating the message loss to the client.
The client implementation can minimize potential DoS risks due to The client implementation can minimize potential DoS risks due to
missing protected result indications by assuming the correct missing protected result indications by assuming the correct
establishment of a new IKE-SA after not receiving one of the above establishment of a new IKE-SA after not receiving one of the above
messages within a certain time window after sending message 6. In messages within a certain time window after sending message 6. In
the fast reconnect case, the client needs to hold both the old and the fast reconnect case, the client needs to hold both the old and
the new IKE-SA in parallel during this time window. the new IKE-SA in parallel during this time window.
Session independence is optionally provided if the fast reconnect Session independence is optionally provided if the fast reconnect
exchange includes the KE payloads (new Diffie-Hellman) as exchange includes the KE payloads (new Diffie-Hellman) as
described in section 10, Figure 7. described in section 11, Figure 9.
Security claims: Security claims:
Ciphersuite negotiation: Yes Ciphersuite negotiation: Yes
Mutual authentication: Yes Mutual authentication: Yes
Integrity protection: Yes Integrity protection: Yes
Replay protection: Yes Replay protection: Yes
Confidentiality: Yes Confidentiality: Yes
Key derivation: Yes Key derivation: Yes
Key strength: Variable Key strength: Variable
Dictionary attack prot.: Yes Dictionary attack prot.: Yes
Fast reconnect: Yes Fast reconnect: Yes
Crypt. binding: N/A Crypt. binding: N/A
Protected result ind.: yes Protected result ind.: yes
Session independence: yes Session independence: yes
Fragmentation: Yes Fragmentation: Yes
Channel binding: Yes Channel binding: Yes
13. Open Issues 14. IANA Considerations
The following issues are still under consideration: This section provides guidance to the IANA regarding registration
of values related to the EAP-IKEv2 protocol, in accordance with
[RFC2434].
- Notifications The following terms are used here with the meanings defined in
[RFC2434]: "name space" and "registration".
IKEv2 provides the concept of notifications to exchange messages The following policies are used here with the meanings defined in
at any time (e.g., dead peer detection). It remains for further [RFC2434]: "Expert Review" and "Specification Required".
study which of these messages are required for this EAP method.
- supported identities This document introduces one new Internet Assigned Numbers
Authority (IANA) consideration:
Can the NAI be carried by the RFC822 ID type of IKEv2? Are there - It requires IANA to allocate an EAP-Request/Response Type for
other formats to be supported? Additional profiling may be EAP-IKEv2.
required in section 5.
- tunneled method <TBD: IANA considerations for channel binding notify payloads>
To reduce the method's complexity, EAP tunneling through EAP-IKEv2
that is in principal possible with IKEv2 is not supported. If
tunneling support is, however, required (e.g. for sequencing), it
is possible to develop an EAP-IKEv2-tunneled method from the
present one. The major change would be to reverse the roles of IKEv2
initiator and responder, as the initiator is EAP-authenticated in
the tunneled case.
It is not considered a good approach by the authors to have both
the tunneled and the non-tunneled method in a single
specification, as this would result in a rather complex method
description. The tunneled-method EAP-IKEv2 specification, if
required, will therefore come with a separate document.
14. Normative References 15. Normative References
[RFC3748] Aboba, Blunk, Carlson and Levkowetz: "Extensible [RFC3748] Aboba, Blunk, Carlson and Levkowetz: "Extensible
Authentication Protocol (EAP)", RFC 3748, June 2004. Authentication Protocol (EAP)", RFC 3748, June 2004.
[Kau04] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol", [Kau04] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol",
internet draft, Internet Engineering Task Force, September 2004. internet draft, Internet Engineering Task Force, September 2004.
Work in progress. Work in progress.
[RFC2119] S. Bradner: "Key words for use in RFCs to Indicate [RFC2119] S. Bradner: "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Internet Engineering Task Force, Requirement Levels", RFC 2119, Internet Engineering Task Force,
March 1997. March 1997.
15. Informative References [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
16. Informative References
[AN03] N. Asokan, V. Niemi, and K. Nyberg: "Man-in-the-middle in [AN03] N. Asokan, V. Niemi, and K. Nyberg: "Man-in-the-middle in
tunnelled authentication", In the Proceedings of the 11th tunnelled authentication", In the Proceedings of the 11th
International Workshop on Security Protocols, Cambridge, UK, International Workshop on Security Protocols, Cambridge, UK,
April 2003. To be published in the Springer-Verlag LNCS series. April 2003. To be published in the Springer-Verlag LNCS series.
[PL+03] J. Puthenkulam, V. Lortz, A. Palekar, D. Simon, and B. [PL+03] J. Puthenkulam, V. Lortz, A. Palekar, D. Simon, and B.
Aboba, "The compound authentication binding problem," internet Aboba, "The compound authentication binding problem," internet
draft, Internet Engineering Task Force, October 2003. Expired. draft, Internet Engineering Task Force, October 2003. Expired.
skipping to change at page 27, line 36 skipping to change at page 28, line 43
Hannes Tschofenig Hannes Tschofenig
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
81739 Munich 81739 Munich
Germany Germany
EMail: Hannes.Tschofenig@siemens.com EMail: Hannes.Tschofenig@siemens.com
Dirk Kroeselberg Dirk Kroeselberg
Siemens AG Siemens AG
Haidenauplatz 1 Otto-Hahn-Ring 6
81667 Munich 81739 Munich
Germany Germany
EMail: Dirk.Kroeselberg@siemens.com EMail: Dirk.Kroeselberg@siemens.com
Yoshihiro Ohba Yoshihiro Ohba
Toshiba America Research, Inc. Toshiba America Research, Inc.
1 Telcordia Drive 1 Telcordia Drive
Piscataway, NJ 08854 Piscataway, NJ 08854
USA USA
Phone: +1 732 699 5305 Phone: +1 732 699 5305
 End of changes. 114 change blocks. 
354 lines changed or deleted 397 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/