EAP WG H. Tschofenig
Internet-Draft D. Kroeselberg
Intended status: Informational A. Pashalidis
Expires: April 26, 2007 Siemens
Y. Ohba
Toshiba
F. Bersani
France Telecom
October 23, 2006
EAP IKEv2 Method
draft-tschofenig-eap-ikev2-12.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Tschofenig, et al. Expires April 26, 2007 [Page 1]
Internet-Draft eap-ikev2 October 2006
Abstract
This document specifies EAP-IKEv2, an EAP authentication method that
is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2
provides mutual authentication and session key establishment between
an EAP peer and an EAP server. It supports authentication techniques
that are based on passwords, high-entropy shared keys, and public key
certificates. These techniques can be combined in a number of ways.
EAP-IKEv2 further provides support for cryptographic ciphersuite
negotiation, hash function agility, identity confidentiality (in
certain modes of operation), fragmentation, and an optional "fast
reconnect" mode.
Tschofenig, et al. Expires April 26, 2007 [Page 2]
Internet-Draft eap-ikev2 October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Error handling . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Specification of Protocol Fields . . . . . . . . . . . . . . . 18
7.1. The Flags, Message Length, and Integrity Checksum Data
fields . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. EAP-IKEv2 header . . . . . . . . . . . . . . . . . . . . . 20
7.3. Security Association Payload . . . . . . . . . . . . . . . 21
7.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . . 21
7.5. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 21
7.6. Identification Payload . . . . . . . . . . . . . . . . . . 21
7.7. Certificate Payload . . . . . . . . . . . . . . . . . . . 21
7.8. Certificate Request Payload . . . . . . . . . . . . . . . 21
7.9. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 21
7.10. Authentication Payload . . . . . . . . . . . . . . . . . . 22
7.11. Notify Payload . . . . . . . . . . . . . . . . . . . . . . 22
7.12. Next Fast-ID Payload . . . . . . . . . . . . . . . . . . . 22
8. Payload Types and Extensibility . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Protected Ciphersuite Negotiation . . . . . . . . . . . . 25
9.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 25
9.3. Integrity Protection . . . . . . . . . . . . . . . . . . . 25
9.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 26
9.5. Confidentiality . . . . . . . . . . . . . . . . . . . . . 26
9.6. Key Strength . . . . . . . . . . . . . . . . . . . . . . . 26
9.7. Dictionary Attack Resistance . . . . . . . . . . . . . . . 27
9.8. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 27
9.9. Cryptographic Binding . . . . . . . . . . . . . . . . . . 27
9.10. Session Independence . . . . . . . . . . . . . . . . . . . 27
9.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 28
9.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
Tschofenig, et al. Expires April 26, 2007 [Page 3]
Internet-Draft eap-ikev2 October 2006
1. Introduction
This document specifies EAP-IKEv2, an EAP authentication method that
is based on the Internet Key Exchange Protocol version 2 (IKEv2) [1].
It provides mutual authentication and session key establishment
between an EAP peer and an EAP server. It supports authentication
techniques that are based on the following types of credential.
o Asymmetric key pairs: these are public/private key pairs where the
public key is embedded into a digital certificate, and the
corresponding private key is known only to a single party.
o Passwords: these are low-entropy bit strings that are known to
both the server and the peer.
o Symmetric keys: these are high-entropy bit strings that known to
both the server and the peer.
It is possible to use a different authentication credential (and
thereby technique) in each direction, e.g. that the EAP server
authenticates itself based on a public/private key pair and the EAP
client based on a symmetric key. In particular, the following
combinations are expected to be used in practice. These are referred
to as "use cases" in the remainder of this document.
1. EAP server: asym. key pair, EAP peer: asym. key pair
2. EAP server: asym. key pair, EAP peer: symmetric key
3. EAP server: asym. key pair, EAP peer: password
4. EAP server: symmetric key, EAP peer: symmetric key
Note that, in use cases 2 and 4, a symmetric key is assumed to be
chosen uniformly at random from its key space; it is therefore
assumed that symmetric keys are not derived from passwords. Also
note that, in use case 3, the EAP server must either have access to
all passwords in plaintext, or, alternatively, for each password
store the value prf(password,"Key Pad for EAP-IKEv2") for all
supported pseudorandom functions (also see Section 7.10 below and
section 2.15 of [1]). Other conceivable use cases are not expected
to be used in practice due to key management issues, and have not
been considered in this document.
The remainder of this document is structured as follows.
Tschofenig, et al. Expires April 26, 2007 [Page 4]
Internet-Draft eap-ikev2 October 2006
o The next section provides an overview of some of the terms and
abbreviations used in this document.
o Section 3 provides an overview of the full EAP-IKEv2 exchange and
thereby specifies the protocol message composition.
o Section 4 specifies the optional EAP-IKEv2 "fast reconnect" mode
of operation.
o Section 5 specifies how exportable session keys are derived.
o Section 6 specifies how possible errors that may occur during
protocol execution are handled.
o Section 7 specifies the format of the EAP-IKEv2 data fields.
Section 7.1 describes how fragmentation is handled in EAP-IKEv2.
o Section 8 specifies the payload type values and describes protocol
extensibility.
o Section 9 provides a list of claimed security properties.
Tschofenig, et al. Expires April 26, 2007 [Page 5]
Internet-Draft eap-ikev2 October 2006
2. Terminology
This document makes use of terms defined in [2] and [1]. In
addition, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear
in this document, are to be interpreted as described in [3].
A list of abbreviations that are used in this document follows.
o AUTH: Denotes a data field containing either a MAC or a signature.
This field is in embedded into an Authentication payload, defined
in Section 7.10.
o CERT: Public key certificate or similar structure.
o CERTREQ: Certificate Request.
o EMSK: Extended Master Session Key, defined in [2].
o HDR: EAP-IKEv2 header, defined in Section 7.2.
o I: Initiator, the party that sends the first message of an EAP-
IKEv2 protocol run. This is always the EAP server.
o MAC: Message Authentication Code. The result of a cryptographic
operation that involves a symmetric key.
o MSK: Master Session Key, defined in [2].
o prf: Pseudorandom function: a cryptographic function whose output
is assumed to be indistinguishable from that of a truly random
function.
o R: Responder, the party that sends the second message of an EAP-
IKEv2 protocol run. This is always the EAP peer.
o SA: Security Association. In this document SA denotes a type of
payload that is used for the negotiation of the cryptographic
algorithms that are to be used within an EAP-IKEv2 protocol run.
Specifically, SAi denotes a set of choices that are accepted by an
initiator, and SAr denotes the choice of the responder.
o Signature: The result of a cryptographic operation that involves
an asymmetric key. In particular, it involves the private part of
a public/private key pair.
o SK: Session Key. In this document, the notation SK{x} denotes that
x is embedded within an Encrypted payload, i.e. that x is
Tschofenig, et al. Expires April 26, 2007 [Page 6]
Internet-Draft eap-ikev2 October 2006
encrypted and integrity-protected using EAP-IKEv2 internal keys.
These keys are different in each direction.
o SK_xx: EAP-IKEv2 internal key, defined in section 2.14 of [1].
o SKEYSEED: Keying material, defined in section 2.14 of [1].
Tschofenig, et al. Expires April 26, 2007 [Page 7]
Internet-Draft eap-ikev2 October 2006
3. Protocol Overview
In this section, the full EAP-IKEv2 protocol run is specified. All
messages are sent between two parties, namely an EAP peer and an EAP
server. In EAP-IKEv2, the EAP server always assumes the role of the
initiator (I), and the EAP peer that of the responder (R) of an
exchange.
The semantics and formats of EAP-IKEv2 messages are similar, albeit
not identical, to those specified in IKEv2 [1] for the establishment
of an IKE Security Association. The full EAP-IKEv2 protocol run
consists of two roundtrips that are followed by either an EAP-Success
or an EAP-Failure message. An optional roundtrip for exchanging EAP
identities may precede the two exchanges.
1. R<-I: EAP-Request/Identity
2. R->I: EAP-Response/Identity(Id)
3. R<-I: EAP-Req (HDR, SAi, KEi, Ni)
4. R->I: EAP-Res (HDR, SAr, KEr, Nr, [CERTREQ], [SK{IDr}])
5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], [NFID], AUTH})
6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH})
7. R<-I: EAP-Success
Figure 1: EAP-IKEv2 full, successful protocol run
Figure 1 shows the full EAP-IKEv2 protocol run, including the
optional EAP identity exchange (messages 1 and 2). A detailed
specification of the message composition follows.
Messages 1 and 2 are a standard EAP Identity Request and Response, as
defined in [2]. Message 3 is the first EAP-IKEv2-specific message.
With this, the server starts the actual EAP authentication exchange.
It contains the initiator SPI in the EAP-IKEv2 header (HDR) (the
initiator selects this value on a per-protocol run basis), the set of
cryptographic algorithms the server is willing to accept for the
protection of EAP-IKEv2 traffic (encryption and integrity protection)
and the derivation of the session key. This set is encoded in the
Security Association payload (SAi). It also contains a Diffie-
Hellman payload (KEi), and a Nonce payload (Ni).
When the peer receives message 3, it selects a set of cryptographic
Tschofenig, et al. Expires April 26, 2007 [Page 8]
Internet-Draft eap-ikev2 October 2006
algorithms from the ones that are proposed in the message. In this
overview, it is assumed that an acceptable such set exists (and is
thus selected), and that the Diffie-Hellman value KEi belongs to an
acceptable group. The peer then generates a non-zero Responder SPI
value for this protocol run, its own Diffie-Hellman value (KEr) and
nonce (Nr), and calculates the keys SKEYSEED, SK_d, SK_ai, SK_ar,
SK_ei, SK_er, SK_pi, and SK_pr according to section 2.14 of [1]. The
peer then constructs message 4. In the context of use cases 1, 2 and
3, the peer's local policy MAY dictate the inclusion of the optional
CERTREQ payload in that message, which gives a hint to the server to
include a certificate for its public key in its next message. In the
context of use case 4, the peer MUST include the optional SK{IDr}
payload, which contains its EAP-IKEv2 identifier, encrypted and
integrity-protected within an Encrypted payload. The keys used to
construct this Encrypted payload are SK_er (for encryption) and SK_ar
(for integrity protection), in accordance with [1]. The responder's
EAP-IKEv2 identifier (IDr) is likely to be needed in these use cases
by the server in order to select the correct symmetric key or
password for the construction of the AUTH payload of message 5.
Upon reception of message 4, the server also computes SKEYSEED, SK_d,
SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr according to section
2.14 of [1]. If an SK{IDr} payload is included, the server decrypts
it and verifies its integrity with the corresponding keys. In this
overview, decryption and verification is assumed to succeed. The
server then constructs message 5 which contains only the EAP-IKEv2
header followed by a single Encrypted payload. The keys used to
generate the encrypted payload MUST be SK_ei (for encryption) and
SK_ai (for integrity protection), in accordance with [1]. The
initiator MUST embed at least two payloads in the Encrypted Payload,
as follows. An Identification payload with the initiator's EAP-IKEv2
identifer MUST be embedded in the Encrypted payload. The
Authentication payload MUST be embedded in the Encrypted payload. A
Certificate payload, and/or a Certificate Request payload MAY also be
embedded in the Encrypted payload. Moreover, a Next Fast-Reconnect
Identifier payload MAY also be embedded in the Encrypted payload.
Message 5 is sent to the responder.
Upon reception of message 5, the responder (EAP peer) authenticates
the initiator (EAP server). The checks that are performed to this
end depend on the use case, local policies, and are specified in [1].
These checks include (but may not be limited to) decrypting the
Encrypted payload, verifying its integrity, and checking that the
Authentication payload contains the expected value. If all checks
succeed (which is assumed in this overview), the responder constructs
message 6. That message MUST contain the EAP-IKEv2 header followed
by a single Encrypted payload, in which at least two further payloads
MUST be embedded, as shown in Figure 1.
Tschofenig, et al. Expires April 26, 2007 [Page 9]
Internet-Draft eap-ikev2 October 2006
Upon reception of message 6, the initiator (EAP server) authenticates
the responder (EAP peer). As above, the checks that are performed to
this end depend on the use case, local policies, and MUST include
decryption and verification of the Encrypted payload, as well as
checking that the Authentication payload contains the expected value.
If the optional SK{IDr} payload was included in message 4, the EAP
server MUST also ensure that the IDr paylod in message 6 is identical
to that in message 4.
If authentication succeeds, an EAP-Success message is sent to the
responder as message 7. The EAP server and the EAP peer generate a
Master Session Key (MSK) and an Extended Master Session Key (EMSK)
after a successful EAP-IKEv2 protocol run, according to Section 5.
Tschofenig, et al. Expires April 26, 2007 [Page 10]
Internet-Draft eap-ikev2 October 2006
4. Fast Reconnect
This section specifies a "fast reconnect" mode of operation for EAP-
IKEv2. This mode is mandatory to implement, but optional to use.
The purpose of fast reconnect is to enable an efficient re-
authentication procedure that also results in a fresh MSK and EMSK.
The "fast reconnect" mode can only be used where an EAP-IKEv2
security context already exists at both the server and the peer, and
its usage is subject to the local policies. In other words, it can
only be used by an EAP server/EAP peer pair that has already been
mutually authenticated in a previous EAP-IKEv2 protocol run.
The fast reconnect mode makes use of dedicated "fast reconnect EAP
identifiers". The idea is that the server indicates its willingness
to engage in "fast reconnect" protocol runs in the future by
including the optional NFID payload in message 5 of a "full" protocol
run (Figure 1), or in message 3 of a "fast reconnect" protocol run
(Figure 2). This NFID payload contains a special EAP identity,
denoted Fast Reconnect Identity (FRID).
The peer uses the FRID in order to indicate to the server whether or
not it wishes to start a "fast reconnect" protocol run. In order for
this to work, the otherwise optional EAP Identity Response MUST be
sent at the beginning of a "fast reconnect" protocol run. If, in the
previous successful "full" (resp. "fast reconnect") EAP-IKEv2
protocol execution, the server had not included an NFID payload in
message 5 (resp. 3), then the peer MUST NOT indicate an FRID (which
it may know from previous protocol runs or otherwise) in the EAP
Identity Response. Otherwise, the peer MAY do so. On reception of
FRID, the server maps it to an existing EAP-IKEv2 context. If such a
context exists, and depending on local policy, the server, then,
either proceeds with the "fast reconnect" protocol run, or proceeds
with message 3 of a "full" protocol run. If the server had
advertised the FRID in the previous EAP-IKEv2 protocol execution, it
SHOULD proceed with a "fast reconnect" protocol run. The peer MUST
be able to correctly handle a message 3 of a "full" protocol run,
even if it indicated a FRID in its EAP Identity Response.
The EAP-IKEv2 fast reconnect exchange is similar, albeit not
identical, to the IKE-SA rekeying procedure as specified in section
2.18 of [1]. During fast reconnect, the server and the peer MAY
exchange fresh Diffie-Hellman values.
Tschofenig, et al. Expires April 26, 2007 [Page 11]
Internet-Draft eap-ikev2 October 2006
1. R<-I: EAP-Request/Identity
2. R->I: EAP-Response/Identity(Id)
3. R<-I: EAP-Req(HDR, SK{SA, Ni, [KEi], [NFID]})
4. R->I: EAP-Res(HDR, SK{SA, Nr, [KEr]})
5. R<-I: EAP-Success
Figure 2: EAP-IKEv2 successful fast reconnect protocol run
Figure 2 shows the message composition for the EAP-IKEv2 fast
reconnect mode. As in the full mode, the EAP server is the initiator
and the EAP peer is the responder. The first two messages constitute
the standard EAP identity exchange. Note that, in order to use the
"fast reconnect" mode, message 2 MUST be sent. This is in order to
enable the peer to indicate its "fast reconnect" identity FRID in
message 2. If the server supports "fast reconnect", if it can map
the FRID to an existing EAP-IKEv2 context, and if its local policy
permits this, it proceeds with message 3. Note that, in that
message, the server MAY embed a NFID payload into the encrypted
payload. Also note that the server MAY choose to perform a full EAP-
IKEv2 run, in which case it would respond with a message that
conforms to the format of message 3 in Figure 1.
Messages 3 and 4 establish a new EAP-IKEv2 security context. In
message 3, the initiator MUST select a new (non-zero) value for the
SPI field in each proposal substructure in the SA payload (see
section 3.3 of [1]). The value of the IKE_SA Responder's SPI field
in HDR MUST be the one from the previous successful EAP-IKEv2
protocol run. The nonce inside the Nonce payload (Ni) MUST be fresh,
and the Diffie-Hellman value inside the Diffie-Hellman payload (if
present, KEi) MUST also be fresh. If present, the Diffie-Hellman
value MUST be drawn from the same group as the Diffie-Hellman value
in the previous successful full EAP-IKEv2 protocol run. Note that
the algorithms and keys that are used to construct the Encrypted
payload in message 3, are the same as in the previous successful EAP-
IKEv2 protocol run.
Upon reception of message 3, the responder (EAP peer) decrypts and
verifies the Encrypted payload. If successful (as assumed in
Figure 2), it constructs message 4 in a fashion similar to the
construction of message 3. The responder MUST choose a new (non-
zero) value for the SPI field in each proposal subsctructure. Upon
reception of message 4, the initiator (EAP server) decrypts and
verifies the Encrypted payload. If the server does not receive
Tschofenig, et al. Expires April 26, 2007 [Page 12]
Internet-Draft eap-ikev2 October 2006
message 4 within a reasonable amount of time, then it MAY resend
message 3 up to a predetermined amount of times before deeming re-
authentication to have failed. If a correct message 4 is received,
then this protocol run is deemed successful, and the server responds
with an EAP-Success message (message 5).
After successful EAP-IKEv2 fast reconnect protocol run, both the
initiator and the responder generate fresh keying material, that is
used for the protection of subsequent EAP-IKEv2 traffic.
Furthermore, both the initiator and the responder MUST generate a
fresh MSK and EMSK and export them.
The new EAP-IKEv2-specific keying material is computed in the same
way as in the full EAP-IKEv2 protocol run, and in accordance with
section 2.18 of [1]. That is, SKEYSEED is computed as SKEYSEED =
prf(SK_d (old), [g^ir (new)] | Ni | Nr), where SK_d (old) is the key
SK_d from the previous successful EAP-IKEv2 protocol run, Ni and Nr
are the nonces (without the Nonce payload headers) that were
exchanged in messages 3 and 4, and g^ir (new) is the newly computed
Diffie-Hellman key, if both the values KEi and KEr were present in
messages 3 and 4. The remaining EAP-IKEv2-specific keys (SK_d,
SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr) are generated as in the
full EAP-IKEv2 protocol run.
The generation of a fresh MSK and EMSK follows the generation of the
EAP-IKEv2-specific keys and adheres to the rules in Section 5.
Note 1: In EAP-IKEv2, the EAP server initiates the fast reconnect
mode and thereby causes fresh session keys to be established. If the
client wishes to initiate this "fast rekeying", it needs to indicate
this to the network by an appropriate out-of-band means (e.g. at the
link layer).
Note 2: It is conceivable that an adversary tries to launch a replay
attack against the EAP-IKEv2 fast reconnect mode of operation. In
particular, the adversary may try to send a previously captured
message 3 in a subsequent fast reconnect protocol run. This replay
attempt will, however, fail because the keys that the responder will
use to verify and decrypt the Encrypted payload are changed with
every successful reconnect protocol run.
Tschofenig, et al. Expires April 26, 2007 [Page 13]
Internet-Draft eap-ikev2 October 2006
5. Key Derivation
This section describes how the Master Session Key (MSK) and the
Extended Master Session Key (EMSK) are derived in EAP-IKEv2. It is
expected that the MSK and the EMSK are exported by the EAP-IKEv2
process and be used in accordance with the EAP keying framework [7].
During an EAP-IKEv2 protocol run, the initiator and the responder
generate a number of keys, as described above and in accordance with
section 2.14 of [1]. The generation of these keys is based on a
pseudorandom function (prf) that both parties have agreed to use and
which is applied in an iterative fashion. This iterative fashion is
specified in section 2.13 of [1] and is denoted by prf+.
In particular, following a successful EAP-IKEv2 protocol run, both
parties generate 128 octets of keying material, denoted KEYMAT, as
KEYMAT = prf+(SK_d, Ni | Nr), where Ni and Nr are the nonces (just
payload without headers) from messages 3 and 4 shown in Figure 1 (in
the context of a full EAP-IKEv2 protocol run) or Figure 2 (in the
context of a fast reconnect EAP-IKEv2 protocol run). Note that only
the nonces are used, i.e. not the entire Nonce payload that contains
them.
The first 64 octets of KEYMAT are exported as the EAP MSK, and the
second 64 octets are exported as the EMSK.
The MSK and EMSK MUST NOT be generated unless an EAP-IKEv2 protocol
run completes successfully. Note that the EAP-IKEv2 method does not
produce an initialisation vector.
Tschofenig, et al. Expires April 26, 2007 [Page 14]
Internet-Draft eap-ikev2 October 2006
6. Error handling
This section specifies how errors are handled within EAP-IKEv2. For
conveying error information from one party to the other, the Notify
payload is defined and used (see Section 7.11).
If, in a full EAP-IKEv2 protocol run, authentication fails (i.e. the
verification of the AUTH field fails at the server or the peer), but
no other errors have occurred, the message flow deviates from that
described in Section 3. The message flows in the presence of
authentication failures are specified in Appendix A.
If, in message 3 of a full EAP-IKEv2 protocol run (see Figure 1), the
responder receives a Diffie-Hellman value (KEi) that belongs to a
group that is not supported (and in the absence of other errors),
then the responder MUST send a message of the form shown in Figure 3
to the initiator. This effectively becomes message 4 in the protocol
run.
4. R->I: EAP-Res (HDR, N(INVALID_KE_PAYLOAD))
Figure 3: Error handling in case of unsupported D-H value
The above message consists of the EAP-IKEv2 header and a Notification
payload with the value of the Notify Message Type field value set to
17 (INVALID_KE_PAYLOAD). There are two octets of data associated
with this notification: the number of the selected DH Group in big
endian order, as specified in section 3.10.1 of [1]. This number
MUST represent a DH group that is supported by both the initiator and
the responder.
If, during a full EAP-IKEv2 protocol run (see Figure 1), the
initiator receives a message conforming to Figure 3 instead of the
usual message 4, then it MUST check whether or not the indicated DH
group was proposed in message 3. If it was not, then the initiator
MUST silently discard the message. Otherwise, the protocol continues
with a new message 3 that the initiator sends to the peer. In this
new message 3 the initiator MUST use a Diffie-Hellman value that is
drawn from the group that is indicated in the Notify payload of
message 4 in Figure 3. If the error persists (e.g. no "normal"
message 4 is received after a predetermined number of retransmissions
of message 3), then the initiator MUST give up with an EAP-Failure
message.
If, in the context of use case 4 and during a full EAP-IKEv2 protocol
Tschofenig, et al. Expires April 26, 2007 [Page 15]
Internet-Draft eap-ikev2 October 2006
run (see Figure 1), the initiator receives, in message 4, an SK{IDr}
payload that decrypts to a non-existent or unauthorised EAP-IKEv2
responder identifier IDr*, then the server SHOULD continue the
protocol with a message conforming to the format of message 5. The
AUTH payload in that message SHOULD contain a value that is
computationally indistinguishable from a value that it would contain
if IDr* was valid and authorised. This can be accomplished, for
example, by generating a random key and calculate AUTH as usual
(however, this document does not mandate a specific mechanism). Only
after receiving message 6, the server SHOULD respond with an
authentication failure notification, i.e. a message conforming to
message 6 in Figure 7. The purpose of this behaviour is to prevent
an adversary from probing the EAP-IKEv2 peer identifier space.
If, in the context of use cases 1, 2, or 3 and during a full EAP-
IKEv2 protocol run (see Figure 1), the initiator receives, in message
4, an SK{IDr} payload that decrypts to an EAP-IKEv2 responder
identifier IDr*, then the server MUST continue the protocol as usual
(note that such a payload would not be required in these use cases).
The server MUST compare IDr* with the IDr received in message 6 and,
in case of a mismatch, MUST respond with an authentication failure
notification, i.e. a message conforming to message 6 in Figure 7. If
no mismatch is detected, normal processing applies.
Other errors do not trigger messages with Notification payloads to be
sent, and MUST be treated as if nothing happened (i.e. the erroneous
EAP-IKEv2 packet MUST be silently discarded). This includes
situations where at least one of the following conditions is met,
with respect to an incoming EAP-IKEv2 packet.
o The packet contains an Encrypted payload that, when decrypted with
the appropriate key, yields an invalid decryption.
o The packet contains an Encrypted payload with a Checksum field
that does not verify with the appropriate key.
o The packet contains an Integrity Checksum Data field (see
Figure 4) that is incorrect.
o The packet does not contain a compulsory field.
o A field in the packet contains an invalid value (e.g. an invalid
combination of flags, a length field that is inconsistent with the
real length of the field or packet, or the responder's choice of a
cryptographic algorithm is different to NONE and any of those that
were offered by the initiator).
Tschofenig, et al. Expires April 26, 2007 [Page 16]
Internet-Draft eap-ikev2 October 2006
o The packet contains an invalid combination of fields (e.g. it
contains two or more Notify payloads with the same Notify Message
Type value, or two or more Transform substructures with the same
Transform Type and Transform ID value).
o The packet causes a defragmentation error.
o The format of the packet is invalid.
If an incoming packet contains an error for which behaviour is
specified in this section, and an error that, in the absence of the
former error, would cause the packet to be silently discarded, then
the packet MUST be silently discarded.
Tschofenig, et al. Expires April 26, 2007 [Page 17]
Internet-Draft eap-ikev2 October 2006
7. Specification of Protocol Fields
In this section, the format of the EAP-IKEv2 data fields and
applicable processing rules are specified. Figure 4 shows the
general packet format of EAP-IKEv2 messages, and the embedding of
EAP-IKEv2 into EAP. The EAP-IKEv2 messages are embedded in the Data
field of the standard EAP Request/Response packets. The Code,
Identifier, Length and Type fields are described in [2]. The EAP
Type for this EAP method is TBD by IANA.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | HDR + payloads ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Checksum Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: General packet format of EAP-IKEv2
The Flags field is always present and is used for fragmentation
support, as described in Section 7.1. The Message Length field is
not always present; it's presence is determined by a certain flag in
the Flags field, as described in Section 7.1. The field denoted as
"HDR + payloads" in Figure 4 contains the EAP-IKEv2 header (see
Section 7.2), followed by a number of payloads, in accordance with
the composition of EAP-IKEv2 messages, as described in the previous
sections. Note that each payload begins with a generic payload
header that is specified in section 3.2 of [1].
The Integrity Checksum Data field is not always present; its presence
is determined by a certain flag in the Flags field, as described in
Section 7.1.
In the remainder of this section, the protocol fields that are used
in EAP-IKEv2 are specified. This specification heavily relies on the
IKEv2 specification [1], and many fields are constructed, formatted
and processed in way that is almost identical to that in IKEv2.
However, certain deviations from standard IKEv2 formatting and
processing exist. These are also highlighted in the remainder of
this section.
Tschofenig, et al. Expires April 26, 2007 [Page 18]
Internet-Draft eap-ikev2 October 2006
7.1. The Flags, Message Length, and Integrity Checksum Data fields
This section describes EAP-IKEv2 fragmentation, and specifies the
encoding and processing rules for the Flags, Message Length, and
Integrity Checksum Data field shown in Figure 4.
Fragmentation support in EAP-IKEv2 is provided by the Flags and
Message Length fields shown in Figure 4. These are encoded and used
as follows.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|L M I 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
L = Length included
M = More fragments
I = Integrity Checksum Data included
Figure 5: Flags field
Only the first three bits (0-2) are used; all remaining bits MUST be
set to zero. The L flag indicates the presence of a Message Length
field, and the M flag indicates whether or not the current EAP
message has more fragments. In particular, if the L bit is set, then
a Message Length field MUST be present in the EAP message, as shown
in Figure 4. The Message Length field is four octets long and
contains the length of the entire message (i.e. the length of the EAP
Data field.). Note that, in contrast, the Length field shown in
Figure 4 contains the length of only the current fragment. If the L
bit is not set, the Message Length field MUST NOT be present.
The M flag MUST be set on all fragments except the last one. In the
last fragment, the M flag MUST NOT be set. Reliable fragment
delivery is provided by the retransmission mechanism of EAP.
The Integrity Checksum Data field contains a cryptographic checksum
that covers the entire EAP message, starting with the Code field, and
ending at the end of the EAP Data field. This field, shown in
Figure 4, is present only if the I bit is set in the Flags field.
The Integrity Checksum Data field immediately follows the EAP Data
field without padding.
Whenever possible, the Integrity Checksum Data field MUST be present
(and the I bit set) for each fragment, including the case where the
entire EAP-IKEv2 message is carried in a single fragment. The
Tschofenig, et al. Expires April 26, 2007 [Page 19]
Internet-Draft eap-ikev2 October 2006
algorithm and keys that are used to compute the Integrity Checksum
Data field MUST be identical to those used to compute the Integrity
Checksum Data field of the Encrypted Payload (see Section 7.9). That
is, the algorithm and keys that were negotiated and established
during this EAP-IKEv2 protocol run are used. Note that this means
that different keys are used to compute the Integrity Checksum Data
field in each direction. Also note that, for messages where this
algorithm and the keys are not yet established, the Integrity
Checksum Data field cannot be computed and is therefore not included.
This applies, for example, to messages 3 and 4 in Figure 1.
In order to minimize the exposure to denial-of-service attacks on
fragmented packets, messages that are not protected with an Integrity
Checksum Data field SHOULD NOT be fragmented. Note, however, that
those packets are not likely to be fragmented anyway since they do
not carry certificates.
7.2. EAP-IKEv2 header
The EAP-IKEv2 header, denoted HDR in this specification, is
constructed and formatted according to the rules specified in section
3.1 of [1].
In the first EAP-IKEv2 message that is sent by the initiator (message
3 in Figure 1), the IKE_SA Responder's SPI field is set to zero.
This is because, at this point in time, the initiator does not know
what SPI value the responder will choose for this protocol run. In
all other messages, both SPI fields MUST contain non-zero values that
reflect the initiator and responder-chosen SPI values.
In accordance with [1], for this version of EAP-IKEv2, the MjVer
(major version) and MnVer (minor version) fields in the header MUST
be 2 and 0 respectively. The value of the Exchange Type field MUST
be set to 34 (IKE_SA_INIT) in messages 3 and 4, and to 35
(IKE_SA_AUTH) in messages 5 and 6 in Figure 1. In messages 3 and 4
in Figure 2 this value MUST be set to 36 (CREATE_CHILD_SA).
The Flags field of the EAP-IKEv2 header is also constructed according
to section 3.1 of [1]. Note that this is not the same field as the
Flags field shown in Figure 4.
The Message ID field is constructed as follows. Messages 3 and 4 in
a full and fast reconnect protocol run (see Figure 1 and 2) MUST
carry Message ID value 0. Messages 5 and 6 in a full protocol run
(see Figure 1) MUST carry Message ID value 1.
Tschofenig, et al. Expires April 26, 2007 [Page 20]
Internet-Draft eap-ikev2 October 2006
7.3. Security Association Payload
The SA payload is used for the negotiation of cryptographic
algorithms between the initiator and the responder. The rules for
its construction adhere to [1], in particular sections 2.7 and 3.3.
In EAP-IKEv2, all Proposal Substructures in the SA payload MUST carry
Protocol ID value 1 (IKE).
7.4. Key Exchange Payload
The Key Exchange payload, denoted KEi if constructed by the initiator
and KEr if constructed by the responder, is formatted according to
the rules specified in section 3.4 of [1].
7.5. Nonce Payload
The Nonce payload, denoted Ni if constructed by the initiator and Nr
if constructed by the responder, is constructed and formatted
according to the rules specified in section 3.9 of [1].
7.6. Identification Payload
The Identification payload, denoted IDi if it contains an identifier
for the initiator and IDr if it contains an identifier for the
responder, is constructed and formatted according to the rules
specified in section 3.5 of [1].
7.7. Certificate Payload
The Certificate payload, denoted CERT, is constructed and formatted
according to the rules specified in section 3.6 of [1]. Note that
certain certificate encodings for the EAP server certificate, e.g.
those that need to be resolved via another network protocol, cannot
be used in some typical EAP-IKEv2 deployment scenarios. A user, for
example, that authenticates himself by means of EAP-IKEv2 in order to
obtain network access, cannot resolve the server certificate at the
time of EAP-IKEv2 protocol execution.
7.8. Certificate Request Payload
The Certificate payload, denoted CERTREQ, is constructed and
formatted according to the rules specified in section 3.7 of [1].
7.9. Encrypted Payload
The Encrypted payload, denoted SK{...}, is constructed and formatted
according to the rules specified in section 3.14 of [1].
Tschofenig, et al. Expires April 26, 2007 [Page 21]
Internet-Draft eap-ikev2 October 2006
7.10. Authentication Payload
The Authentication payload, denoted AUTH, is constructed and
formatted according to the rules specified in sections 2.15 and 3.8
of [1].
The contents of the Authentication payload depend on which party
generates this field, the use case, and the algorithm that
corresponds to the credential (asymmetric key, symmetric key, or
password) that this party uses to authenticate itself. The
Authentication payload contains either a MAC or a signature.
If the party that generates the Authentication payload authenticates
itself based on a shared secret (i.e. a password or a symmetric key),
then the Authentication payload MUST contain a MAC. This MAC is
calculated using a key that is derived from the shared secret,
according to section 2.15 of [1]. According to that section, the
shared secret is padded with the string "Key Pad for IKEv2" as part
of this key derivation. For the EAP-IKEv2 method, this rule is
overridden, in that the padding string is redefined as "Key Pad for
EAP-IKEv2". The latter padding string MUST be used for the
derivation of the MAC key from a shared secret in the context of EAP-
IKEv2. This is done in order to avoid the same MAC key to be used
for both IKEv2 and EAP-IKEv2 in scenarios where the same shared
secret is used for both. Note that using a shared secret (e.g. a
password) in the context EAP-IKEv2 that is identical or similar to a
shared secret that is used in another context (including IKEv2) is
nevertheless NOT RECOMMENDED.
7.11. Notify Payload
The Notify payload, denoted N(...), is constructed and formatted
according to the rules specified in section 3.10 of [1]. The
Protocol ID field of this payload MUST be set to 1 (IKE_SA).
7.12. Next Fast-ID Payload
The Next Fast-ID Payload is defined as follows.
Tschofenig, et al. Expires April 26, 2007 [Page 22]
Internet-Draft eap-ikev2 October 2006
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Fast-Reconnect-ID (FRID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: NFID payload format
The Next Fast-ID payload, denoted NFID, does not have an equivalent
in IKEv2. Nevertheless, the Next Payload, C, RESERVED, and Payload
Length fields of this payload are constructed according to section
3.2 of [1]. The Fast-Reconnect-ID field contains a fast reconnect
identifer that the peer can use in the next fast reconnect protocol
run, as described in Section 4. In environments where a realm
portion is required, Fast-Reconnect-ID includes both a username
portion and a realm name portion. The Fast-Reconnect-ID MUST NOT
include any terminating null characters. The encoding of the Fast-
Reconnect-ID field MUST follow the UTF-8 transformation format
[RFC3629].
Tschofenig, et al. Expires April 26, 2007 [Page 23]
Internet-Draft eap-ikev2 October 2006
8. Payload Types and Extensibility
In EAP-IKEv2, each payload is identified by means of a type field
which, as specified in [1], is indicated in the "Next Payload" field
of the preceding payload. However, the identifer space from which
EAP-IKEv2 payload types are drawn is independent from the payload
type space of IKEv2. This is because EAP-IKEv2 and IKEv2 may evolve
in a different way and, as such, payload types that appear in one
protocol do not necessary appear in the other. An example of this is
the "Next Fast-ID" (NFID) payload which does not exist in IKEv2.
The values for the payload types defined in this document are as
follows.
o Security Association Payload: TBD by IANA (suggested value: 33)
o Key Exchange payload: TBD by IANA (suggested value: 34)
o Nonce payload: TBD by IANA (suggested value: )
o Identification payload (when sent by initiator): TBD by IANA
(suggested value: 35)
o Identification payload (when sent by responder): TBD by IANA
(suggested value: 36)
o Certificate payload: TBD by IANA (suggested value: 37)
o Certificate Request payload: TBD by IANA (suggested value: 38)
o Encrypted payload: TBD by IANA (suggested value: 46)
o Authentication: TBD by IANA (suggested value: 39)
o Notification: TBD by IANA (suggested value: 41)
o Next Fast-ID payload: TBD by IANA (suggested value: 64)
Tschofenig, et al. Expires April 26, 2007 [Page 24]
Internet-Draft eap-ikev2 October 2006
9. Security Considerations
As mentioned in Section 3, in EAP-IKEv2, the EAP server always
assumes the role of the initiator (I), and the EAP peer takes on the
role of the responder (R) of an exchange. This is in order to ensure
that, in scenarios where the peer authenticates itself based on a
password (i.e. in use case 3), operations that involve this password
only take place after the server has been successfully authenticated.
In other words, this assignment of initiator and responder roles
results in protection against offline dictionary attacks on the
password that is used by the peer to authenticate itself (see
Section 9.7).
In order for two EAP-IKEv2 implementations to be interoperable, they
must support at least one common set of cryptographic algorithms. In
order to promote interoperability, EAP-IKEv2 implementations MUST
adhere to the same rules with regard to mandatory-to-implement
cryptographic algorithms as IKEv2. These rules are specified in [4].
The remainder of this section describes EAP-IKEv2 in terms of
specific security terminology as required by [2]. The discussion
makes reference to the use cases defined in Section 1 above.
9.1. Protected Ciphersuite Negotiation
In message 3, the EAP server provides the set of ciphersuites it is
willing to accept in an EAP-IKEv2 protocol run. Hence, the server is
in control of the ciphersuite. An EAP peer that does not support any
of the indicated ciphersuites is not able to authenticate. The local
security policy of the peer MUST specify the set of ciphersuites that
the peer accepts. The server MUST verify that the ciphersuite that
is indicated as being chosen by the peer in message 4, belongs to the
set of ciphersuites that were offered in message 3. If this
verification fails, the server MUST silently discard the packet.
9.2. Mutual Authentication
EAP-IKEv2 supports mutual authentication.
9.3. Integrity Protection
EAP-IKEv2 provides integrity protection of EAP-IKEv2 traffic. This
protection is offered after authentication is completed and is
facilitated by inclusion of two Integrity Checksum Data fields: one
at the end of the EAP packet (see Figure 4), and one as part of an
Encrypted payload (see Section 7.9).
Tschofenig, et al. Expires April 26, 2007 [Page 25]
Internet-Draft eap-ikev2 October 2006
9.4. Replay Protection
EAP-IKEv2 provides protection against replay attacks by a variety of
means. This includes the requirement that the Authentication payload
is computed as a function of, among other things, a server-provided
nonce and a peer-provided nonce. These nonces are required to be
practically unpredictable by an adversary. Assuming that the
algorithm that is used to compute the Authentication payload does not
contain cryptographic weaknesses, the probability that an
Authentication payload that is valid in a particular protocol run,
will also be valid in a subsequent run, is therefore negligible.
9.5. Confidentiality
EAP-IKEv2 provides confidentiality of certain EAP-IKEv2 fields,
namely those included in Encrypted payloads. With respect to
identity confidentiality, the following claims are made. Note that
identity confidentiality refers to the EAP-IKEv2 identity of the EAP
peer.
Identity confidentiality is provided in the face of a passive
adversary, i.e. an adversary that does not modify traffic as it is in
transit. Whenever the optional SK{IDr} payload in message 4 of a
full EAP-IKEv2 protocol (see Figure 1) is not included, identity
confidentiality is also provided in the face of an active adversary.
This payload MUST NOT be included in use cases 1, 2, and 3. In use
case 4 this payload MUST be included. Therefore, in use case 4, EAP-
IKEv2 does not provide identity confidentiality in the face of an
active adversary.
9.6. Key Strength
EAP-IKEv2 supports the establishment of session keys (MSK and EMSK)
of a variety of key strengths, with the theoretical maximum at 512
bits per key (since this is the size of the MSK and the EMSK).
However, in practice the effective key strength is likely to be
significantly lower, and depends on the authentication credentials
used, the negotiated ciphersuite (including the output size of the
pseudorandom function), the Diffie-Hellman group used, and on the
extent to which the assumptions on which the underlying cryptographic
algorithms depend really hold. Of the above mechanisms, the one that
offers the lowest key strength can be regarded as a measure of the
effective key strength of the resulting session keys. Note that this
holds for other EAP methods, too.
Due to the large variety of possible combinations, no indication of a
practical effective key strength for MSK or EMSK is given here.
However, those responsible for the deployment of EAP-IKEv2 in a
Tschofenig, et al. Expires April 26, 2007 [Page 26]
Internet-Draft eap-ikev2 October 2006
particular environment should consider the threats this environment
may be exposed to, and configure the EAP-IKEv2 server and peer
policies and authentication credentials such that the established
session keys are of a sufficiently high effective key strength.
9.7. Dictionary Attack Resistance
EAP-IKEv2 can be used in a variety of use cases, as explained in
Section 1. In some of these uses cases, namely use case 1, 2, and 4,
dictionary attacks cannot be launched since no passwords are used.
In use case 3, EAP-IKEv2 provides protection against offline
dictionary attacks, since operations that involve the password are
executed only after the server has authenticated itself (based on a
credential other than a password).
In order to reduce exposure against online dictionary attacks, in use
case 3, the server SHOULD provide the capability to log failed peer
authentication events, and SHOULD implement a suitable policy in case
of consecutive failed peer authentication attempts within a short
period of time (such as responding with an EAP-Failure instead of
message 5 for a predetermined amount of time).
9.8. Fast Reconnect
EAP-IKEv2 supports a "fast reconnect" mode of operation, as described
in Section 4.
9.9. Cryptographic Binding
EAP-IKEv2 is not a tunnel EAP method. Thus, cryptographic binding
does not apply to EAP-IKEv2.
9.10. Session Independence
EAP-IKEv2 provides session independence in a number of ways, as
follows. Firstly, knowledge of captured EAP-IKEv2 conversations
(i.e. the information that a passive adversary may obtain) does not
enable the adversary to compute the Master Session Key (MSK) and
Extended Master Session Key (EMSK) that resulted from these
conversations. This holds even in the case where the adversary later
obtains access to the server and/or the peer's long-term
authentication credentials that were used in these conversations.
That is, EAP-IKEv2 provides support for "perfect forward secrecy".
However, whether or not this support is made use of in a particular
EAP-IKEv2 protocol run, depends on when the peer and the server
delete the Diffie-Hellman values that they used in that run, and on
whether or not they use fresh Diffie-Hellman values in each protocol
run. The discussion in section 2.12 of [1] applies.
Tschofenig, et al. Expires April 26, 2007 [Page 27]
Internet-Draft eap-ikev2 October 2006
Secondly, an active adversary that does not know the peer's and the
server's long-term authentication credentials cannot learn the MSK
and EMSK that were established in a particular protocol run of EAP-
IKEv2, even if it obtains access to the MSK and EMSK that were
established in other protocol runs of EAP-IKEv2. This is because the
MSK and the EMSK are a function of, among other things, data items
that are assumed to be generated independently at random in each
protocol run.
9.11. Fragmentation
EAP-IKEv2 provides support for fragmentation, as described in
Section 7.1.
9.12. Channel Binding
Channel binding is not supported in EAP-IKEv2.
Tschofenig, et al. Expires April 26, 2007 [Page 28]
Internet-Draft eap-ikev2 October 2006
10. IANA Considerations
IANA should allocate a value for the EAP method type indicating EAP-
IKEv2. In addition, IANA should allocate values for the following
types of payload: Security Association, Key Exchange, Nonce,
Identification (when sent by initiator), Identification (when sent by
responder), Certificate, Certificate Request, Encrypted,
Authentication Notification, and Next Fast-ID payload.
Tschofenig, et al. Expires April 26, 2007 [Page 29]
Internet-Draft eap-ikev2 October 2006
11. Acknowledgements
The authors are grateful to Krzysztof Rzecki, Rafal Mijal, Piotr
Marnik, and Pawel Matejski, who, during their implementation of EAP-
IKEv2, provided invaluable feedback and identified a number of errors
in previous versions of this draft. The authors also thank Pasi
Eronen for his invaluable comments as expert reviewer assigned by the
EAP working group chairs Jari Arkko and Bernard Aboba. The authors
would also like to thank Guenther Horn, Thomas Otto, Paulo Pagliusi
and John Vollbrecht for their insightful comments and suggestions.
The members of the PANA design team, in particular D. Forsberg and A.
Yegin, also provided comments on the initial version of this draft.
Finally, the authors are grateful to the members of the EAP keying
design team for their discussion in the area of the EAP Key
Management Framework.
Tschofenig, et al. Expires April 26, 2007 [Page 30]
Internet-Draft eap-ikev2 October 2006
12. References
12.1. Normative References
[1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP) (RFC
3748)", Request For Comments 3748, June 2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[4] Schiller, J., "Cryptographic Algorithms for Use in the Internet
Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[6] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005.
12.2. Informative References
[7] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz,
"Extensible Authentication Protocol (EAP) Key Management
Framework", Internet Draft (work in progress), January 2006.
Tschofenig, et al. Expires April 26, 2007 [Page 31]
Internet-Draft eap-ikev2 October 2006
Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication
This appendix illustrates how authentication failures are handled
within EAP-IKEv2. Note that authentication failures only occur in
full EAP-IKEv2 protocol runs.
Figure 7 shows the message flow in case the EAP peer fails to
authenticate the EAP server.
1. R<-I: EAP-Request/Identity
2. R->I: EAP-Response/Identity(Id)
3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)
4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])
5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH})
6. R->I: EAP-Res(HDR, SK {N(AUTHENTICATION_FAILED)})
7. R<-I: EAP-Failure
Figure 7: EAP-IKEv2 with failed server authentication
The difference to the full successful exchange described in Section 3
is that, in message 6, the EAP peer MUST answer the EAP server with
an Encrypted payload that contains a Notify payload with the Notify
Message Type value set to 24 (AUTHENTICATION_FAILED). In message 7,
an EAP-Failure message MUST be returned by the EAP server.
Figure 8 shows the message flow in case the EAP server fails to
authenticate the EAP peer.
Tschofenig, et al. Expires April 26, 2007 [Page 32]
Internet-Draft eap-ikev2 October 2006
1. R<-I: EAP-Request/Identity
2. R->I: EAP-Response/Identity(Id)
3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)
4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])
5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], AUTH})
6. R->I: EAP-Res (HDR, SK {IDr, [CERT], AUTH})
7. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)})
8. R->I: EAP-Res (HDR, SK {})
9. R<-I: EAP-Failure
Figure 8: EAP-IKEv2 with failed peer authentication
Compared to the full successful exchange, one additional roundtrip is
required. In message 7 the EAP server MUST send an EAP request with
Encrypted payload that contains a Notify payload with the Notify
Message Type value set to 24 (AUTHENTICATION_FAILED), instead of
sending an EAP-Success message. The EAP peer, upon receiving message
7, MUST send an empty EAP-IKEv2 (informational) message in reply to
the EAP server's error indication, as shown in message 8. The EAP
server then answers with an EAP-Failure.
Tschofenig, et al. Expires April 26, 2007 [Page 33]
Internet-Draft eap-ikev2 October 2006
Authors' Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Dirk Kroeselberg
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Dirk.Kroeselberg@siemens.com
Andreas Pashalidis
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Andreas.Pashalidis@siemens.com
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Email: yohba@tari.toshiba.com
Florent Bersani
France Telecom R&D
38, rue du General Leclerc
Issy-Les-Moulineaux, Cedex 92794
France
Email: bersani_florent@yahoo.fr
Tschofenig, et al. Expires April 26, 2007 [Page 34]
Internet-Draft eap-ikev2 October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Tschofenig, et al. Expires April 26, 2007 [Page 35]