< draft-tschofenig-eap-ikev2-02.txt   draft-tschofenig-eap-ikev2-03.txt >
EAP EAP
Internet Draft H. Tschofenig Internet Draft H. Tschofenig
D. Kroeselberg D. Kroeselberg
Siemens Siemens
Y. Ohba Y. Ohba
Toshiba Toshiba
Document: draft-tschofenig-eap-ikev2-02.txt Document: draft-tschofenig-eap-ikev2-03.txt
Expires: April 2002 October 2003 Expires: August 2004 February 2004
EAP IKEv2 Method EAP IKEv2 Method
(EAP-IKEv2) (EAP-IKEv2)
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 40 skipping to change at page 1, line 40
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
Abstract Abstract
EAP-IKEv2 is an EAP method which reuses the cryptography and the EAP-IKEv2 is an EAP method which reuses the cryptography and the
payloads of IKEv2, creating a flexible EAP method that supports both payloads of IKEv2, creating a flexible EAP method that supports both
symmetric and asymmetric authentication. Furthermore protection of symmetric and asymmetric authentication. This EAP method offers the
legacy authentication mechanisms is supported. This EAP method security benefits of IKEv2 authentication and key agreement without
offers the security benefits of IKEv2 without the goal of the goal of establishing IPsec security associations.
establishing IPsec security associations.
Table of Contents Table of Contents
1. Introduction..................................................2 1. Introduction..................................................2
2. IKEv2 and EAP-IKEv2 Overview..................................3 2. IKEv2 and EAP-IKEv2 Overview..................................3
3. Terminology...................................................4 3. Terminology...................................................4
4. Protocol overview.............................................4 4. Protocol overview.............................................4
5. Identities used in EAP-IKEv2..................................7 5. Identities used in EAP-IKEv2..................................7
6. Packet Format.................................................9 6. Packet Format.................................................8
7. Retransmission...............................................10 7. Retransmission...............................................10
8. Key derivation...............................................10 8. Key derivation...............................................10
9. Error Handling...............................................11 9. Error Handling...............................................11
10. Security Considerations.....................................13 10. Fast Reconnect..............................................12
11. Open Issues.................................................13 11. Channel Binding.............................................14
12. Normative References........................................13 11.1 Channel Binding Procedure in Full Authentication........15
13. Informative References......................................14 11.2 Channel Binding Procedure in Fast Reconnect.............16
Acknowledgments.................................................14 11.3 Channel Binding Error Indication........................16
Author's Addresses..............................................15 11.4 Notify Payload Types for Channel Binding................16
Full Copyright Statement........................................15 11.5 Examples................................................18
12. Security Considerations.....................................22
12.1 General Considerations..................................22
12.2 Security Claims.........................................22
13. Open Issues.................................................23
14. Normative References........................................24
15. Informative References......................................25
Acknowledgments.................................................25
Author's Addresses..............................................26
Full Copyright Statement........................................26
1. Introduction 1. Introduction
This document specifies the EAP-IKEv2 authentication method. EAP- This document specifies the EAP-IKEv2 authentication method. The
IKEv2 is a flexible EAP method which makes the IKEv2 protocolĘs main design goal for EAP-IKEv2 is to provide a flexible and
features available for scenarios using EAP-based authentication. efficient EAP method which makes the IKEv2 protocol's features
available for 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 IKEv2 authentication
protocol, and thereby provides strong, well-analyzed, cryptographic exchanges, and thereby provides strong, well-analyzed, cryptographic
properties as well as broad flexibility. This includes the support properties as well as broad flexibility.
of authentication methods and configuration payloads for remote
access scenarios.
EAP-IKEv2 can be used directly to mutually authenticate EAP peers. EAP-IKEv2 provides mutual authentication between EAP peers. This may
This may be based on either symmetric methods using pre-shared keys, be based on either symmetric methods using pre-shared keys, or on
or on asymmetric methods based on public/private key pairs, asymmetric methods based on public/private key pairs, Certificates
Certificates and CRLs. In addition, EAP-IKEv2 supports two-phased and CRLs. It is possible to use different types of authentication
authentication schemes by establishing a server-authenticated secure for the different directions, e.g. the server uses certificate-based
tunnel, and by subsequently protecting an EAP authentication authentication whereas the client uses a symmetric method.
allowing for legacy client authentication methods. Hence, EAP-IKEv2 IKEv2 supports two-phased authentication schemes by establishing a
provides a secure EAP tunneling method. server-authenticated secure tunnel and subsequently protecting an
EAP authentication allowing for legacy client authentication
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 decrease implementation
complexity.
A non-goal of EAP-IKEv2 (and basically the major difference to plain A non-goal of EAP-IKEv2 (and basically the major difference to plain
IKEv2) is the establishment of IPsec security associations, as this IKEv2) is the establishment of IPsec security associations, as this
would not make much sense in the standard AAA three-party scenario, would not make much sense in the standard AAA three-party scenario,
consisting of an EAP peer, an authenticator (NAS) and a back-end consisting of an EAP peer, an authenticator (NAS) and a back-end
authentication server terminating EAP. IPsec SA establishment may be authentication server terminating EAP. IPsec SA establishment may be
required locally (i.e., between the EAP peer and some access required locally (i.e., between the EAP peer and some access
server). However, SA establishment within an EAP method would only server). However, SA establishment within an EAP method would only
provide SAs between the EAP peer and the back-end authentication provide SAs between the EAP peer and the back-end authentication
server. Other approaches as e.g., those of the IETF PANA group are server. Other approaches as e.g., those of the IETF PANA group are
considered more appropriate in this case. considered more appropriate in this case.
2. IKEv2 and EAP-IKEv2 Overview 2. IKEv2 and EAP-IKEv2 Overview
IKEv2 [Kau03] is a protocol which consists of two exchanges: IKEv2 [Kau04] is a protocol which consists of two exchanges:
(1) an authentication and key exchange protocol which establishes an (1) an authentication and key exchange protocol which establishes an
IKE-SA. IKE-SA.
(2) messages and payloads which focus on the negotiation of (2) messages and payloads which focus on the negotiation of
parameters in order to establish IPsec security associations (i.e., parameters in order to establish IPsec security associations (i.e.,
Child-SAs). These payloads contain algorithm parameters and traffic Child-SAs). These payloads contain algorithm parameters and traffic
selector fields. selector fields.
In addition to the above-mentioned parts IKEv2 also includes some In addition to the above-mentioned parts IKEv2 also includes some
payloads and messages which allow configuration parameters to be payloads and messages which allow configuration parameters to be
exchanged primarily for remote access scenarios. exchanged primarily for remote access scenarios.
The EAP-IKEv2 method defined by this document uses the IKEv2 The EAP-IKEv2 method defined by this document uses the IKEv2
payloads and messages used for the initial IKEv2 exchange which payloads and messages used for the initial IKEv2 exchange which
establishes an IKE-SA. establishes an IKE-SA.
IKEv2 provides an improvement over IKEv1 [RFC2409] as described in IKEv2 provides an improvement over IKEv1 [RFC2409] as described in
Appendix A of [Kau03]. Important for this document are the reduced Appendix A of [Kau04]. Important for this document are the reduced
number of initial exchanges, support of legacy authentication, number of initial exchanges, decreased latency of the initial
decreased latency of the initial exchange, optional Denial-of- exchange, and some other fixes (e.g., hash problem). IKEv2 is a
Service (DoS) protection capability and some other fixes (e.g., hash cryptographically sound protocol that has received a considerable
problem). IKEv2 is a cryptographically sound protocol that has amount of expert review and that benefits from a long practical
received a considerable amount of expert review and that benefits experience with IKE.
from a long practical experience with IKE.
The goal of EAP-IKEv2 is to inherit these properties within an The goal of EAP-IKEv2 is to inherit these properties within an
efficient, secure EAP method. efficient, secure EAP method.
In addition, IKEv2 provides authentication and key exchange In addition, IKEv2 provides authentication and key exchange
capabilities which allow an entity to use symmetric as well as capabilities which allow an entity to use symmetric as well as
asymmetric authentication within a single protocol. Such flexibility asymmetric authentication within a single protocol. Such flexibility
is considered important for an EAP method and is provided by EAP- is considered important for an EAP method and is provided by EAP-
IKEv2. IKEv2.
[Per03] provides a good tutorial for IKEv2 design decisions. [Per03] provides a good tutorial for IKEv2 design decisions.
EAP-IKEv2 therefore provides
a) well-known IKEv2 symmetric/asymmetric authentication and
b) a new EAP tunneling method.
EAP-IKEv2 provides a secure fragmentation mechanism in which EAP-IKEv2 provides a secure fragmentation mechanism in which
integrity protection is performed for each fragment of an IKEv2 integrity protection is performed for each fragment of an IKEv2
message. message.
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 [RFC2284] or in [Kau03]. in [RFC2284] 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 this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119]. 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 provides some overview over EAP-IKEv2 message
exchanges. Note that some payloads are omitted (such as SAi2 and exchanges. Note that some mandatory IKEv2 payloads are omitted, or
SAr2) which are mandatory for IKEv2 but are not required in EAP- profiled (such as SAi2 and SAr2), as it is not supported to
IKEv2 since they are used to establish an IPsec SA. establish IPsec (ESP, AH) SAs in EAP-IKEv2.
IKEv2 uses the same protocol message exchanges for both symmetric IKEv2 uses the same protocol message exchanges for both symmetric
and asymmetric authentication. The difference lies only in the and asymmetric authentication. The difference lies only in the
computation of the AUTH payload. See Section 2.15 of [Kau03] for computation of the AUTH payload. See Section 2.15 of [Kau04] for
more information about the details of the AUTH payload computation. more information about the details of the AUTH payload computation.
It is even possible to combine symmetric (e.g., from the client to 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 server) with asymmetric authentication (e.g., from the server to
the client) in a single protocol exchange. Figure 1 depicts such a the client) in a single protocol exchange. Figure 1 depicts such a
protocol exchange. protocol exchange.
Message exchanges are reused from [Kau03], and are adapted. Since Message exchanges are reused from [Kau04], and are adapted. Since
this document does not describe frameworks or particular this document does not describe frameworks or particular
architectures the message exchange takes place between two parties - architectures the message exchange takes place between two parties -
between the Initiator (I) and the Responder (R). In context of EAP between the Initiator (I) and the Responder (R). In the context of
the Initiator is often called Authenticating Peer whereas the EAP the Initiator takes the role of the EAP server and the responder
Responder is referred as Authenticator. matches the EAP peer.
The first message flow shows EAP-IKEv2 without the optional DoS The first message flow shows the EAP-IKEv2 full successful exchange.
protection exchanges. The core EAP-IKEv2 exchange (message (4) - The core EAP-IKEv2 exchange (message (3) - (6)) consists of four
(7)) consists of four messages (two round trips)_only. The first two messages (two round trips)_only. The first two messages constitute
messages constitute the standard EAP identity exchange and are not the standard EAP identity exchange and are optional; they are not
mandatory if the EAP server is known. required in case the EAP server is known. In the exchange, the EAP
server (B) takes the role of the IKEv2 initiator and the EAP peer
(A) acts as the IKEv2 responder.
1) I <-- R: EAP-Request/Identity 1) A <-- B: EAP-Request/Identity
2) I --> R: EAP-Response/Identity(Id) 2) A --> B: EAP-Response/Identity(Id)
3) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start) 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
4) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
5) I <-- R: EAP-Request/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])
6) I --> R: EAP-Response/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})
7) I <-- R: EAP-Request/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})
8) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish) 7) A <-- B: EAP-Success
9) I <-- R: EAP-Success
Figure 1: EAP-IKEv2 message flow
The subsequent message flow shows EAP-IKEv2 with DoS protection
enabled. The IKEv2 DoS protection mechanism uses cookies and keeps
the responder stateless when it receives the first IKEv2 message,
preventing it from performing heavy cryptographic operations based
on this first incoming message. As a consequence of DoS protection
an additional round trip (message (5) and (6)) is required.
1) I <-- R: EAP-Request/Identity
2) I --> R: EAP-Response/Identity(Id) Figure 1: EAP-IKEv2 successful message flow
3) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start) Figure 2 shows the message flow in case the EAP peer fails to
authenticate the EAP server.
4) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 1) A <-- B: EAP-Request/Identity
5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 2) A --> B: EAP-Response/Identity(Id)
HDR(A,0), N(COOKIE-REQUIRED), N(COOKIE))
6) I --> R: EAP-Response/EAP-Type=EAP-IKEv2( 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni)
7) I <-- R: EAP-Request/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])
8) I --> R: EAP-Response/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})
9) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDr, [CERT,] AUTH}) HDR(A,B), SK {N(AUTHENTICATION_FAILED)})
10) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish)
11) I <-- R: EAP-Success
Figure 2: EAP-IKEv2 with Cookies
The Secure Legacy Authentication (SLA) EAP message exchange shown in
Figure 3 is taken from Section 2.16 of [Kau03] and adapted. It
provides an example of a successful inner EAP exchange using the
EAP-SIM Authentication method [HS03], which is secured by the IKE-
SA.
Implementations MUST ensure that infinite recursions of EAP and EAP-
IKEv2 exchanges are not allowed. (TBD: some limit necessary)
I <-- R: EAP-Request/Identity 7) A <-- B: EAP-Failure
I --> R: EAP-Response/Identity(Id) Figure 2: EAP-IKEv2 with failed server authentication
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start) Figure 3 shows the message flow in case the EAP server fails to
authenticate the EAP peer. The EAP peer MUST send an empty EAP-IKEv2
informational message in reply to the EAP server's error indication.
The EAP server answers with an EAP-Failure.
I --> R: EAP-Response/EAP-Type=EAP-IKEv2( 1) A <-- B: EAP-Request/Identity
HDR, SAi1, KEi, Ni)
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 2) A --> B: EAP-Response/Identity(Id)
HDR, SAr1, KEr, Nr, [CERTREQ])
I --> R: EAP-Response/EAP-Type=EAP-IKEv2( 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
HDR, SK {IDi, [CERTREQ,] [IDr,]})
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR, 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
SK {IDr, [CERT,] AUTH, EAP(EAP-Request /SIM HDR(A,B), SAr1, KEr, Nr, [CERTREQ])
/Start(AT_VERSION_LIST))})
I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP- 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
Response/SIM/Start(AT_NONCE_MT, AT_SELECTED_VERSION)), HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH})
[AUTH]})
I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP- 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
Request/SIM/Challenge(AT_RAND, AT_MAC)), [AUTH]}) HDR(A,B), SK {IDr, [CERT,] AUTH})
I --> R: EAP-Response/EAP-Type=EAP-IKEv2( 7) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR, SK {EAP(EAP-Response/SIM/Challenge(AT_MAC) ), [AUTH]}) HDR(A,B), SK {N(AUTHENTICATION_FAILED)})
I <-- R: EAP-Success 8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {})
Figure 3: EAP-IKEv2 SLA with EAP-SIM Authentication 9) A <-- B: EAP-Failure
Please note that the message flow in Figure 3 does not include an Figure 3: EAP-IKEv2 with failed client authentication
EAP-Request/Identity and the corresponding EAP-Response/Identity
message inside the EAP-IKEv2 tunnel. Although it would be possible
to perform such an exchange IKEv2 suggests using the IDi payload for
this purpose. As a consequence the initiators identity is not
protected against active attacks.
Since the goal of this EAP method is not to establish an IPsec SA Since the goal of this EAP method is not to establish an IPsec SA
some payloads used in IKEv2 are omitted. In particularly the some payloads used in IKEv2 are omitted. In particularly the
following messages and payloads are not required: following messages and payloads SHOULD not be sent:
- Traffic Selectors - Traffic Selector (TS)payloads
- IPsec SA negotiation payloads - SA payloads that carry SA proposals for protocol IDs other than
(e.g., CREATE_CHILD_SA exchange or SAx2 payloads) 1(IKE), i.e., SA payloads with protocol ID 2 (ESP) or 3 (AH)
- ECN Notification - ESN (extended sequence number) transforms
- Port handling
- NAT traversal
Some of these messages and payloads are optional in IKEv2. Some of these messages and payloads are optional in IKEv2.
In general it does not make sense to directly negotiate IPsec SAs In general it does not make sense to directly negotiate IPsec SAs
with EAP-IKEv2, as such SAs were unlikely to be used between the EAP within EAP-IKEv2, as such SAs are not required between the EAP
endpoints. endpoints and as SAs cannot be transferred to different AAA entities
by standard AAA protocols.
IKEv2 also provides functionality for the initiator to request Consequently, mechanisms and payloads that are not supported by EAP-
address information from the responder as described in Section 2.19 IKEv2 are:
of [Kau03]. Using this functionality it is possible for an end host - ECN Notifications as specified in section 2.24 of [Kau04].
to securely request address configuration information from the local - IKE-specific port handling
network. - 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 protection
by adding a roundtrip to the initial exchanges, see section 2.xx of
[Kau04]. As this is intended to protect the IKEv2 responder but in
EAP-IKEv2 the EAP server takes the role of the initiator, it is not
recommended to use this feature of IKEv2 for server protection.
5. Identities used in EAP-IKEv2 5. Identities used in EAP-IKEv2
A number of different places allow to convey identity information in A number of different places allow to convey identity information in
IKEv2, when combined with EAP. This section describes their function IKEv2, when combined with EAP. This section describes their function
within the different exchanges of EAP-IKEv2. Note that EAP-IKEv2 within the different exchanges of EAP-IKEv2. Note that EAP-IKEv2
does not introduce more identities than any other tunneling does not introduce more identities than other non-tunneling EAP
approach. Figure 4 shows which identities are used during the methods. Figure 4 shows which identities are used during the
individual phases of the protocol. individual phases of the protocol.
+-------+ +-------------+ +---------+ +--------+ +-------+ +-------------+ +---------+
|Client | |Front-End | |Local AAA| |Home AAA| |Client | |Front-End | |AAA |
| | |Authenticator| |Server | |Server | | | |Authenticator| |Server |
+-------+ +-------------+ +---------+ +--------+ +-------+ +-------------+ +---------+
EAP/Identity-Request EAP/Identity-Request
<--------------------- <---------------------
(a) EAP/Identity-Response (a) EAP/Identity-Response
----------------------------------> ---------------------------------->
Tunnel-Establishment Tunnel-Establishment
(b) (Identities of IKEv2 are used) (b) (Identities of IKEv2 are used)
Server (Network) Authentication Server (Network) Authentication
<---------------------------------- <----------------------------------
... ...
----------------------------------> ---------------------------------->
+---------------------------------+
| Secure Tunnel |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Secure Legacy Authentication |
| protected with the IKE-SA |
(c) | (Identities of the tunneled |
| EAP method are used) |
| Client 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 (outer) EAP message exchange provides
information about the identities of the EAP endpoints. This message information about the identities of the EAP endpoints. This message
exchange mainly is an identity request/response. This exchange is exchange mainly is an identity request/response. This exchange is
optional if the EAP server is known already or can be learned by optional if the EAP server is known already or can be learned by
other means. other means.
b) The identities used within EAP-IKEv2 for both the initiator and b) Identities exchanged within EAP-IKEv2 for both the initiator and
the responder. The initiator identity is often associated with a the responder. The initiator identity is often associated with a
user identity such as a fully-qualified RFC 822 email address. The user identity such as a fully-qualified RFC 822 email address. The
identity of the responder might be a FQDN. The identity is of identity of the responder might be a FQDN. The identity is of
importance for authorization. importance for authorization.
c) For secure legacy authentication an EAP message exchange is For carrying identities in EAP-IKEv2, implementations MUST follow
protected with the established IKE-SA as shown in Figure 3. This the rules given in [Kau04], section 3.5, i.e., MUST be configurable
exchange again adds EAP identities. 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.
This inner EAP message exchange serves the purpose of client Implementations SHOULD be capable of generating and accepting all of
authentication. The two identities used thereby are the EAP identity these types.
(i.e., a NAI) and possibly a separate identity for the selected EAP
method.
The large number of identities is required due to nesting of
authentication methods and due to overloaded function of the
identity for routing (i.e., authentication end point indication).
The number of recursions of EAP and IKEv2 is limited, see Section 4.
Hence with this additional (nested) EAP exchange the end point of
the EAP-IKEv2 exchange might not be the same as the end point of the
inner EAP exchange which is protected by the IKE-SA (which in this
case is not protected by the IKE-SA any more between the EAP-IKEv2
endpoint and the endpoint of the inner EAP exchange, but might be
protected by other means that are not considered in this document).
6. Packet Format 6. Packet Format
The IKEv2 payloads, which are defined in [Kau03], are embedded into The IKEv2 payloads, which are defined in [Kau04], are embedded into
the Data field of the standard EAP Request/Response packets. The the Data field of the standard EAP Request/Response packets. The
Code, Identifier, Length and Type field is described in [RFC2284]. Code, Identifier, Length and Type field is described in [RFC2284].
The Type-Data field carries a one byte Flags field following the The Type-Data field carries a one byte Flags field following the
IKEv2 payloads. Each IKEv2 payload starts with a header field HDR IKEv2 payloads. Each IKEv2 payload starts with a header field HDR
(see [Kau03]). (see [Kau04]).
The packet format is shown in Figure 5. The 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 | Data ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Checksum Data | | Integrity Checksum Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Packet Format Figure 5: Packet Format
No additional packet formats other than those defined in [Kau03] are No additional packet formats other than those defined in [Kau04] are
required for this EAP method. required for this EAP method.
The Flags field is required to indicate Start and Finish messages The Flags field is used for fragmentation support. The S and F bits
which are required due to the asymmetric nature of IKEv2 and the are reserved for future use.
Request/Response message handling of EAP.
Currently five bits of the eight bit flags field are defined. The Currently five 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 0 0 0 0| |S F L M I 0 0 0|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
S = EAP-IKEv2 start message S = (reserved)
F = EAP-IKEv2 finish message 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 EAP-IKEv2 messages which have neither the S nor the F flag set
contain regular IKEv2 message payloads inside the Data field. contain regular IKEv2 message payloads inside the Data field.
With regard to fragmentation we follow the suggestions and With regard to fragmentation we follow the suggestions and
descriptions given in Section 2.8 of [PS+03]: The L indicates that a descriptions given in Section 2.8 of [PS+03]: The L indicates that a
length field is present and the M flag indicates fragments. The L length field is present and the M flag indicates fragments. The L
skipping to change at page 11, line 4 skipping to change at page 10, line 23
7. Retransmission 7. 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 EAP messages MUST NOT be retransmitted based on timers, when used as EAP
authentication method. authentication method.
8. Key derivation 8. Key derivation
The EAP-IKEv2 method described in this document generates session The EAP-IKEv2 method described in this document generates session
keys. These session keys are used to establish an IKE-SA which keys. On the one hand, these session keys are used within the IKE-
provides protection of subsequent EAP-IKEv2 payloads. To export a SA, for protection of EAP-IKEv2 payloads, e.g., AUTH exchanges or
session key as part of the EAP keying framework [AS+03] it is notifications. On the other hand, additional keys are derived to be
required to derive additional session keys for usage with EAP (i.e., exported as part of the EAP keying framework [AS+03] (i.e., MSK,
MSK, EMSK and IV). It is good cryptographic security practice to use EMSK and IV). It is good cryptographic security practice to use
different keys for different "applications". Hence we suggest different keys for different "applications". Hence we suggest
reusing the key derivation function suggested in Section 2.17 of reusing of the key derivation function suggested in Section 2.17 of
[Kau03] to create keying material KEYMAT. [Kau04] to create keying material KEYMAT.
The key derivation function defined is KEYMAT = prf+(SK_d, Ni | Nr), 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. where Ni and Nr are the Nonces from the IKE_SA_INIT exchange.
Since the required amount of keying material is greater than the
size of the output of the prf algorithm the prf is used iteratively.
Section 2.13 of [Kau04] describes this mechanism in detail.
According to [AS+03] the keying material of MSK, EMSK and IV have to According to [AS+03] the keying material of MSK, EMSK and IV have to
be at minimum 64, 64 and 64 octets long. be at minimum 64, 64 and 64 octets long.
The produced keying material for MSK, EMSK and IV MUST be twice the The produced keying material for MSK, EMSK and IV MUST be at least
minimum size (i.e., 128 octets). the minimum size (i.e., 64 octets). The keying material KEYMAT is
split into the MSK, EMSK and IV part.
Figure 6 describes the keying hierarchy of EAP-IKEv2 graphically.
This figure is adopted from Figure 2 of [AS+03].
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+
| | ^
| EAP-IKEv2 Method | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +------------------+ | |
| | EAP-IKEv2 Diffie-Hellmann | | EAP-IKEv2 prot. | | |
| | derived and authenticated key | | session specific | | |
| | SK_d | | state (Nonce i,j)| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +-------------+----+ | |
| | | | Local |
| | | | to EAP |
| | | | Method |
| | | | |
| | | | |
| | | | |
| | | | |
| +---------------+-------------+ | | |
| | | | | | |
| +-+-+-+-+-++ +-+-+-+-+-++ +-+-+-+-+-++ | |
| | MSK | |EMSK | | IV | | |
| |Derivation| |Derivation| |Derivation| | |
| +-+-+-+-+-++ +-+-+-+-+-++ +-+-+-+-+-++ | |
| | | | | V
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-++-+-+-+-+-------+-+-+----+ ---+
| | | ^
|MSK |EMSK |IV |
| | | |
| | | Exported |
| | | by EAP |
V V V Method |
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ |
| AAA Key Derivation | | Known | |
| Naming & Binding | |(Not Secret) | |
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V
Legend:
MSK = Master Session Key (512 Bit)
EMSK = Extended Master Session Key (512 Bit)
SK_d = Session key derived by EAP-IKEv2
IV = Initialization Vector
Figure 6: EAP-IKEv2 Keying Hierarchy
9. Error Handling 9. 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 detailed Data field of EAP-IKEv2 Request and Response messages) and detailed
processing rules. EAP-IKEv2 follows the error handling rules processing rules. EAP-IKEv2 follows the error handling rules
specified in the IKEv2 specification for errors on the Data field of specified in the IKEv2 specification for errors on the Data field of
EAP-IKEv2 messages, with the following additional rules: EAP-IKEv2 messages, with the following additional rules:
o For an IKEv2 error that triggers an initiation of an IKEv2 For an IKEv2 error that triggers an initiation of an IKEv2 exchange
exchange (i.e., an INFORMATIONAL exchange), an EAP-IKEv2 message (i.e., an INFORMATIONAL exchange), an EAP-IKEv2 message that
that contains the IKEv2 request that is generated for the IKEv2 contains the IKEv2 request that is generated for the IKEv2 exchange
exchange MUST be sent to the peering entity. In this case, the MUST be sent to the peering entity. In this case, the EAP message
EAP message that caused the IKEv2 error MUST be treated as a that caused the IKEv2 error MUST be treated as a valid EAP message.
valid EAP message.
o For an IKEv2 error for which the IKEv2 message that caused the For an IKEv2 error for which the IKEv2 message that caused the error
error is discarded without triggering an initiation of an IKEv2 is discarded without triggering an initiation of an IKEv2 exchange,
exchange, the EAP message that carries the the erroneous IKEv2 the EAP message that carries the erroneous IKEv2 message MUST be
message MUST be treated as an invalid EAP message and discarded treated as an invalid EAP message and discarded as if it were not
as if it were not received at EAP layer. 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, errors including defragmentation failures, integrity check failures, errors
in Flag and Message Length fields, the EAP message that caused the in Flag and Message Length fields, the EAP message that caused the
error MUST be treated as an invalid EAP message and discarded as if error MUST be treated as an invalid EAP message and discarded as if
it were not received at EAP layer. 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, an
outstanding EAP Request is not retransmitted based on timer and thus outstanding EAP Request is not retransmitted based on timer and thus
there is a possibility of EAP conversation stall when the EAP server there is a possibility of EAP conversation stall when the EAP server
receives an invalid EAP Response. To avoid this, the EAP server MAY receives an invalid EAP Response. To avoid this, the EAP server MAY
retransmit the outstanding EAP Request in response to an invalid EAP retransmit the outstanding EAP Request in response to an invalid EAP
Response. Alternatively, the EAP server MAY send a new EAP Request Response. Alternatively, the EAP server MAY send a new EAP Request
in response to an invalid EAP Response with assigning a new in response to an invalid EAP Response with assigning a new
Identifier and putting the last transmitted IKEv2 message in the Identifier and putting the last transmitted IKEv2 message in the
Data field. Data field.
10. Fast Resume 10. Fast Reconnect
TLS provides the capability of resuming a session. This offers EAP-IKEv2 supports fast reconnect, i.e., a successful reconnect
primarily performance improvement for a new authentication and key exchange creates a new IKE-SA by using an IKE CHILD_SA exchange. The
exchange protocol run. In order to resume a session two approaches purpose of a re-authentication exchange is to allow for efficient
can be taken: re-keying based on the existing IKE-SA in situations where
(depending on the given security policy) no full authentication is
required in case of an existing EAP-IKEv2 security context.
The fast reconnect exchange uses the IKE-SA rekeying as specified in
section 2.18 of [IKEv2]. However, the exchanges for EAP-IKEv2 do not
use the payloads for rekeying other than IKE SAs:
- The TS (traffic selector) payloads SHOULD not be sent by EAP-IKEv2
implementations.
- The [N] payload (REKEY_SA notification) SHOULD not be sent by EAP-
IKEv2 implementations.
a) Generic approach During fast re-authentication, the new IKE_SA is computed as
b) Method-specific approach specified in [IKEv2], section 2.18. The new keying material derived
from this IKE_SA is computed as in an initial EAP-IKEv2
authentication exchange.
Fast re-authentication allows for an optional new Diffie-Hellman
exchange.
The idea of approach (a) is to The following exchange provides fast reconnect for EAP-IKEv2, where
- force each EAP method to create an EAP SA. This SA is kept at the A is the EAP peer (IKE responder) and B is the EAP server (IKE
EAP peer and the EAP server and is used for subsequent exchanges. initiator):
- built this functionality into EAP itself.
Approach (b) is already used by existing methods using TLS. Choosing 1) A <-- B: EAP-Request/Identity
(b) does not require any changes to EAP itself since each EAP method
has to implement its own mechanism.
So far it has not been decided which approach should be suggested 2) A --> B: EAP-Response/Identity(Id)
for EAP. In any case it seems that a generic approach contains some
difficulties since EAP methods need to negotiate the necessary
parameters with are required to build the EAP SA (lifetime,
algorithms, identifiers, etc.). Furthermore, it is necessary to
cover error cases which happen if the wrong AAA server is selected
(due to failover or load balancing) and the EAP SA is not found.
For both cases it is necessary to establish to keep some state 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
information. An additional motivation for establishing state is the HDR, SK {SA, Ni, [KEi]})
ability to provide passive user identity confidentiality as
exercised in [AH03]. Subsequent protocol exchanges use a pseudonym
instead of the long-term user identity.
Additionally it is necessary to list some requirements for 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
establishing an EAP SA and for running a fast resume. For example, HDR, SK {SA, Nr, [KEr]})
does the fast resume exchange need to provide key agreement or key
transport functionality?
Once the above-raised issues have been addressed in the EAP working
group a solution will be added to EAP-IKEv2.
11. Security Considerations 5) A <-- B: EAP-Success
Figure 7: Fast Reconnect Message Flow
The first two messages constitute the standard EAP identity exchange
and are optional; they are not required in case the EAP server is
known.
Figure 8 shows the fast reconnect message flow in case the EAP peer
fails to re-authenticate the EAP server.
1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2
(HDR, SK {SA, Ni, [KEi]})
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR, SK {N(AUTHENTICATION_FAILED)})
5) A <-- B: EAP-Failure
Figure 8: EAP-IKEv2 fast reconnect
(server authentication failed)
Figure 9 shows the fast reconnect message flow in case the EAP
server fails to re-authenticate the EAP peer. The EAP peer MUST send
an empty EAP-IKEv2 informational message in reply to the EAP
server's error indication. The EAP server answers with an EAP-
Failure.
1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
HDR, SK {SA, Ni, [KEi]})
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR, SK {SA, Nr, [KEr]})
5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(AUTHENTICATION_FAILED)})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {})
7) A <-- B: EAP-Failure
Figure 9: EAP-IKEv2 fast reconnect
(client authentication failed)
IKE_SAs do not have lifetimes. Such lifetimes are therefore set by
local policies of the peers. Typically the peer setting the shorter
lifetime will therefore trigger the reconnect procedure.
Note: IKEv2 supports fast rekeying to be initiated by both peers. As
the EAP server initiating the rekeying better fits the EAP message
flow, the EAP server, from an IKE perspective, is the initiator in
the rekeying exchange.
11. Channel Binding
EAP-IKEv2 provides a channel binding functionality [RFC2284bis] in
order for the EAP peer and EAP server to make sure that the both
entities are given the same network access attributes such as
Calling-Station-Id, Called-Station-Id, and NAS-Port-Type by the NAS.
This is achieved by using Notify payloads to exchange attribute data
between the EAP peer and EAP server.
A Notify payload that carries a null channel binding attribute is
referred to as a channel binding request. A Notify payload which
contains a non-null channel binding attribute and is sent in
response to a channel binding request is referred to as a channel
binding response. A pair of channel binding request and channel
binding response constitute a channel binding exchange. A distinct
Notify payload type is used for a particular type of channel binding
attribute, which is referred to as a channel binding attribute type.
It is allowed to carry multiple channel binding requests and/or
responses with different channel binding attribute types in a single
IKEv2 message. A set of channel binding exchanges performed in a
single round of EAP-IKEv2 full authentication or fast reconnect is
referred to as a channel binding procedure.
A Notify payload that is used for reporting an error occurred during
a channel binding exchange is referred to as a channel binding error
indication.
EAP-IKEv2 offers a protected result indication mechanism (see
section 12.2). To receive protected result indication, the EAP
server MUST initiate a channel binding exchange as specified in
Figure 10, message 5. As a result of this channel binding exchange,
the client will receive a protected result indication, because the
server will initiate an informational exchange as part of the
channel binding procedure(messages 7 and 8) through the new IKE-SA
that results from a successful reconnect procedure.
11.1 Channel Binding Procedure in Full Authentication
In the case of EAP-IKEv2 full authentication procedure, the channel
binding procedure is performed in the following way.
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 channel
binding request in an IKE_AUTH request. When the EAP server receives
an IKE_SA_INIT response with one or more channel binding request, it
MUST include the corresponding channel binding response(s) an
IKE_AUTH request (in addition to its channel binding request(s) if
any). When the EAP peer receives an IKE_AUTH request with one or
more channel binding request, it MUST include the corresponding
channel binding response(s) in an IKE_AUTH response.
When the EAP server successfully validates all the channel binding
response(s) sent by the EAP server, it initiates an INFORMATIONAL
exchange, where an empty payload is used in both INFORMATIONAL
request and INFORMATIONAL response. This exchange serves as a
protected success indication. After completion of this
INFORMATIONAL exchange, the EAP server sends Success message.
11.2 Channel Binding Procedure in Fast Reconnect
In the case of EAP-IKEv2 fast reconnect, the channel binding
procedure is performed in the following way.
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 for each
channel binding attribute that needs validation. When the EAP peer
receives a CREATE_CHILD_SA request with containing one or more
channel binding request, it MUST contain channel binding response(s)
in the CREATE_CHILD_SA response, as well as its channel binding
request(s) if any. This piggybacking is possible because the
CREATE_CHILD_SA exchange is protected with the old IKE_SA. When the
EAP server receives a CREATE_CHILD_SA response, if it has one or
more channel binding response to send to the EAP peer, it initiates
an INFORMATIONAL exchange immediately after completion of the
CREATE_CHILD_SA exchange, where one or more channel binding response
is carried in the INFORMATIONAL request. If the EAP peer
successfully validates the channel binding response(s), it MUST
respond with an empty INFORMATIONAL response. This exchange serves
as a protected success indication. After completion of this
INFORMATIONAL exchange, the EAP server sends Success message.
11.3 Channel Binding Error Indication
A channel binding error is detected by the EAP peer or EAP server
when (i) a channel binding response is not contained in the expected
IKEv2 message or (ii) a channel binding response is contained in the
expected IKEv2 message but the channel binding attribute does not
have the expected value. Whenever a channel binding error is
detected, the detecting entity MUST send a channel binding error
indication to its peering entity. In case of (ii), the channel
binding error indication MUST contain the channel binding attribute
that caused the error.
When the EAP server detects a channel binding error, a channel
binding error indication MUST be carried in an INFORMATIONAL
request, and the EAP peer MUST respond with an empty INFORMATIONAL
response.
When the EAP peer detects a channel binding error, a channel binding
error indication MUST be carried in an IKEv2 error reporting message
for which the R-flag of the IKEv2 header MUST be set. The EAP server
MUST respond with EAP-Failure message when it receives such a
channel binding error indication.
11.4 Notify Payload Types for Channel Binding
The following Notify Payload types are defined for the purpose of
channel binding exchange.
CALLING_STATION_ID TBD
The payload data in a channel binding response of this type
contains octet string representation of Calling-Station-Id
value known to the EAP server by using an external mechanism.
CALLED_STATION_ID TBD
The payload data in a channel binding response of this type
contains octet string representation of Called-Station-Id
value known to the EAP peer by using an external mechanism.
NAS_PORT_TYPE TBD
The payload data in a channel binding response of this type
contains 4-octet unsigned integer value of NAS-Port-Type
known to the EAP peer by using an external mechanism.
The following Notify Payload types are defined for the purpose of
reporting when there is an error in a channel binding exchange.
INVALID_CALLING_STATION_ID TBD
The payload data (if non-null) contains octet string
representation of Calling-Station-Id value that caused the
error.
INVALID_CALLED_STATION_ID TBD
The payload data (if non-null) contains octet string
representation of Called-Station-Id value that caused the
error.
INVALID_NAS_PORT_TYPE TBD
The payload data (if non-null) contains 4-octet unsigned
integer value of NAS-Port-Type that caused the error.
Table 1 shows the the entity that is allowed to send a channel
binding request for each channel binding attribute type.
channel binding The entity that is allowed to send
attribute type channel binding request
----------------------+------------------------------------------
CALLING_STATION_ID EAP server
CALLED_STATION_ID EAP peer
NAS_PORT_TYPE EAP server
Table 1: Channel Binding Attribute Types and Requesting Entities
11.5 Examples
In the figures of this section, a Notify payload tagged with '*'
indicates a Notify payload with null data (i.e., a channel binding
request). a Notify payload no tagged with '*' indicates a Notify
payload with non-null data (i.e., a channel binding response).
Figure 10 shows an example of EAP-IKEv2 authentication sequence with
a successful channel binding procedure. The first two messages
constitute the standard EAP identity exchange and are optional.
1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SAr1, KEr, Nr, [CERTREQ,]
N(CALLED_STATION_ID*))
5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH,
N(CALLED_STATION_ID),
N(CALLING_STATION_ID*),
N(NAS_PORT_TYPE*)})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDr, [CERT,] AUTH,
N(CALLING_STATION_ID),
N(NAS_PORT_TYPE)})
7) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {})
8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {})
9) A <-- B: EAP-Success
Figure 10: EAP-IKEv2 with successful channel binding
Figure 11 shows an example of EAP-IKEv2 authentication sequence when
the EAP server detects an error in a channel binding procedure. The
first two messages constitute the standard EAP identity exchange and
are optional. In this case, message 7) and 8) MUST constitute an
INFORMATIONAL exchange.
1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SAr1, KEr, Nr, [CERTREQ,]
N(CALLED_STATION_ID*))
5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH,
N(CALLED_STATION_ID),
N(CALLING_STATION_ID*),
N(NAS_PORT_TYPE*)})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDr, [CERT,] AUTH,
N(CALLING_STATION_ID),
N(NAS_PORT_TYPE)})
7) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(INVALID_CALLING_STATION_ID)})
8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {})
9) A <-- B: EAP-Failure
Figure 11: EAP-IKEv2 with channel binding error
(detected by EAP server)
Figure 12 shows an example of EAP-IKEv2 authentication sequence when
the EAP peer detects an error in a channel binding procedure. The
first two messages constitute the standard EAP identity exchange and
are optional.
1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SAr1, KEr, Nr, [CERTREQ,]
N(CALLED_STATION_ID*))
5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH,
N(CALLED_STATION_ID),
N(CALLING_STATION_ID*),
N(NAS_PORT_TYPE*)})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(INVALID_CALLED_STATION_ID)})
7) A <-- B: EAP-Failure
Figure 12: EAP-IKEv2 with channel binding error
(detected by EAP peer)
Figure 13 shows an example of EAP-IKEv2 fast reconnection sequence
with a successful channel binding procedure. The first two messages
constitute the standard EAP identity exchange and are optional.
1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,]
N(CALLING_STATION_ID*),
N(NAS_PORT_TYPE*)})
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {SA, Nr, [KEr,]
N(CALLED_STATION_ID*),
N(CALLING_STATION_ID),
N(NAS_PORT_TYPE)})
5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(CALLED_STATION_ID)})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,B), SK {})
7) A <-- B: EAP-Success
Figure 13: Fast reconnect with channel binding error
(fast reconnect)
Figure 14 shows an example of EAP-IKEv2 fast reconnect sequence when
the EAP server detects an error in a channel binding procedure. The
first two messages constitute the standard EAP identity exchange and
are optional. In this case, message 7) and 8) MUST constitute an
INFORMATIONAL exchange.
1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,]
N(CALLING_STATION_ID*),
N(NAS_PORT_TYPE*)})
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {SA, Nr, [KEr,]
N(CALLED_STATION_ID*),
N(CALLING_STATION_ID),
N(NAS_PORT_TYPE)})
5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(INVALID_CALLING_STATION_ID)})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {})
7) A <-- B: EAP-Failure
Figure 14: Fast reconnect with channel binding error
(detected by EAP server)
Figure 15 shows an example of EAP-IKEv2 fast reconnect sequence when
the EAP peer detects an error in a channel binding procedure. The
first two messages constitute the standard EAP identity exchange and
are optional.
1) A <-- B: EAP-Request/Identity
2) A --> B: EAP-Response/Identity(Id)
3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,]
N(CALLING_STATION_ID*),
N(NAS_PORT_TYPE*)})
4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {SA, Nr, [KEr,]
N(CALLED_STATION_ID*),
N(CALLING_STATION_ID),
N(NAS_PORT_TYPE)})
5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(CALLED_STATION_ID)})
6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(
HDR(A,B), SK {N(INVALID_CALLED_STATION_ID)})
7) A <-- B: EAP-Failure
Figure 15: Fast reconnect with channel binding error
(detected by EAP peer)
12. Security Considerations
12.1 General Considerations
The security of the proposed EAP method is intentionally based on The security of the proposed EAP method is intentionally based on
IKEv2 [Kau03]. Man-in-the-middle attacks discovered in the context IKEv2 [Kau04]. Therefore, the security claims of EAP-IKEv2 are
of tunneled authentication protocols (see [AN03] and [PL+03]) are derived from the security offered by the supported features of
applicable to IKEv2 if legacy authentication with EAP [RFC2284] is IKEv2.
used. To counter this threat IKEv2 provides a compound
authentication by including the EAP provided session key inside the
AUTH payload.
12. Open Issues 12.2 Security Claims
The following issues are still under consideration: Authentication mechanism:
Mutual authentication is supported based on either pre-shared
symmetric keys or public/private key pairs. Besides certificates,
plain public keys can be used. It is possible to use different types
of authentication for the different directions within one
authentication exchange. An example is the server using certificate-
based authentication and the client using pre-shared secrets.
- Reducing the number of messages Password-based authentication should only be used in IKEv2 with
extended authentication (EAP tunneling), which is not supported by
this version of EAP-IKEv2. Therefore, dictionary attacks are not
applicable in the context of EAP-IKEv2.
The message flows given in this document finish with an EAP-Success Man-in-the-middle attacks discovered in the context of tunneled
message. In some cases it might be possible to skip these messages. authentication protocols (see [AN03] and [PL+03]) are not applicable
Furthermore it is possible to omit the first exchange if the to EAP-IKEv2 as the extended authentication feature of IKEv2 is not
identity can be learned by other means. supported. Hence, the cryptographic binding claim is not applicable.
- Notifications Ciphersuite negotiation is supported as specified in IKEv2 for IKE-
SAs. The negotiation for IPsec (Child) SAs is not supported, as such
SAs are not generated by EAP-IKEv2.
Protected result indication as described in section 7.16 of
[RFC2284bis] is optionally provided by EAP-IKEv2. In message 5 of
figure 1 (full successful authentication) the EAP server
authenticates to the client. Message 6 authenticates the client to
the server, and the client by authenticating the server and by
sending message 6 expresses that it is willing to accept access. The
client, however, does not get a protected result indication from the
server in this case. An attacker could potentially forge an EAP
success/failure message which could result in DoS to the client. In
some situations, synchronization may be achieved by lower layer
indications.
Protected result indication is optionally provided as specified in
section 11.
If this mechanism is not used, the recommended behavior for the
client is to assume the correct establishment of a new IKE-SA after
sending message 6, independent of the receipt of an EAP
success/failure. In case of unsuccessful authentication, the server
would answer with an IKEv2 notification (which, in case of the fast
reconnect exchange, would be protected by the old IKE-SA). In case
of a lost message 6, the server would retransmit message 5,
indicating the message loss to the client.
The client implementation can minimize potential DoS risks due to
missing protected result indications by assuming the correct
establishment of a new IKE-SA after not receiving one of the above
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 new IKE-SA in parallel during this time window.
Session independence is optionally provided if the fast reconnect
exchange includes the KE payloads (new Diffie-Hellman) as described
in section 10, Figure 7.
Security claims:
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes
Key strength: N/A
Dictionary attack prot.: N/A
Fast reconnect: Yes
Crypt. binding: N/A
Protected result ind.: yes
Session independence: yes
Fragmentation: Yes
Channel binding: Yes
13. Open Issues
The following issues are still under consideration:
- Notifications
IKEv2 provides the concept of notifications to exchange messages at IKEv2 provides the concept of notifications to exchange messages at
any time (e.g., dead peer detection). It remains for further study any time (e.g., dead peer detection). It remains for further study
which of these messages are required for this EAP method. which of these messages are required for this EAP method.
- Roles of initiator and responder - supported identities
Figure 4 shows the initiator starting the EAP-IKEv2 exchange. Can the NAI be carried by the RFC822 ID type of IKEv2? Are there
However, there is also the possibility to have the EAP server to other formats to be supported? Additional profiling may be required
start the exchange which saves roundtrips. It remains for further in section 5.
study to analyze the resulting security properties.
13. Normative References - protected result indication
This method provides protected result indications as an optional
feature by running a channel binding exchange. It is ffs whether
this feature should be mandated for all message flows (which would
require to add an additional informational exchange to the message
flows without channel binding.
- tunneled method
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
[RFC2284] L. Blunk and J. Vollbrecht: "PPP Extensible Authentication [RFC2284] L. Blunk and J. Vollbrecht: "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998. Protocol (EAP)", RFC 2284, March 1998.
[Kau03] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol", [Kau04] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol",
internet draft, Internet Engineering Task Force, October 2003. Work internet draft, Internet Engineering Task Force, January 2004. Work
in progress. 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.
14. Informative References 15. 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, April International Workshop on Security Protocols, Cambridge, UK, April
2003. To be published in the Springer-Verlag LNCS series. 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, 2003. Work in progress. draft, Internet Engineering Task Force, 2003. Work in progress.
skipping to change at page 14, line 44 skipping to change at page 25, line 40
[PS+03] A. Palekar, D. Simon, G. Zorn and S. Josefsson: "Protected [PS+03] A. Palekar, D. Simon, G. Zorn and S. Josefsson: "Protected
EAP Protocol (PEAP)", internet draft, Internet Engineering Task EAP Protocol (PEAP)", internet draft, Internet Engineering Task
Force, March 2003. Work in progress. Force, March 2003. Work in progress.
[AH03] J. Arkko and H. Haverinen: "EAP AKA Authentication", internet [AH03] J. Arkko and H. Haverinen: "EAP AKA Authentication", internet
draft, Internet Engineering Task Force, June 2003. Work in draft, Internet Engineering Task Force, June 2003. Work in
progress. progress.
Acknowledgments Acknowledgments
We would like to thank Bernard Aboba, Jari Arkko, Paoulo Pagliusi We would like to thank Bernard Aboba, Jari Arkko, Guenther Horn,
and John Vollbrecht for their comments to this draft. Paoulo Pagliusi and John Vollbrecht for their comments to this
draft.
Additionally we would like to thank members of the PANA design team Additionally we would like to thank members of the PANA design team
(namely D. Forsberg and A. Yegin) for their comments and input to (namely D. Forsberg and A. Yegin) for their comments and input to
the initial version of the draft. the initial version of the draft.
Finally we would like to thank the members of the EAP keying design Finally we would like to thank the members of the EAP keying design
team for their discussion in the area of the EAP Key Management team for their discussion in the area of the EAP Key Management
Framework. Framework.
Author's Addresses Author's Addresses
skipping to change at page 15, line 26 skipping to change at page 26, line 22
EMail: Hannes.Tschofenig@siemens.com EMail: Hannes.Tschofenig@siemens.com
Dirk Kroeselberg Dirk Kroeselberg
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
81739 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 Information Systems, Inc.
P.O. Box 136 9740 Irvine Blvd.
Convent Station, NJ, 07961-0136 Irvine, CA 92619-1697
USA USA
Phone: +1 973 829 5174 Phone: +1 973 829 5174
Email: yohba@tari.toshiba.com EMail: yohba@tari.toshiba.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
 End of changes. 91 change blocks. 
275 lines changed or deleted 795 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/