< draft-tschofenig-eap-ikev2-14.txt   draft-tschofenig-eap-ikev2-15.txt >
Network Working Group H. Tschofenig Network Working Group H. Tschofenig
Internet-Draft D. Kroeselberg Internet-Draft D. Kroeselberg
Intended status: Experimental Nokia Siemens Networks Intended status: Experimental Nokia Siemens Networks
Expires: March 11, 2008 A. Pashalidis Expires: March 30, 2008 A. Pashalidis
NEC NEC
Y. Ohba Y. Ohba
Toshiba Toshiba
F. Bersani F. Bersani
France Telecom France Telecom
September 8, 2007 September 27, 2007
EAP-IKEv2 Method EAP-IKEv2 Method
draft-tschofenig-eap-ikev2-14.txt draft-tschofenig-eap-ikev2-15.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 11, 2008. This Internet-Draft will expire on March 30, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies EAP-IKEv2, an EAP method that is based on the This document specifies EAP-IKEv2, an Extensible Authentication
Internet Key Exchange (IKEv2) protocol. EAP-IKEv2 provides mutual Protocol (EAP) method that is based on the Internet Key Exchange
authentication and session key establishment between an EAP peer and (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and
an EAP server. It supports authentication techniques that are based session key establishment between an EAP peer and an EAP server. It
on passwords, high-entropy shared keys, and public key certificates. supports authentication techniques that are based on passwords, high-
These techniques can be combined in a number of ways. EAP-IKEv2 entropy shared keys, and public key certificates. EAP-IKEv2 further
further provides support for cryptographic ciphersuite negotiation, provides support for cryptographic ciphersuite negotiation, hash
hash function agility, identity confidentiality (in certain modes of function agility, identity confidentiality (in certain modes of
operation), fragmentation, and an optional "fast reconnect" mode. operation), fragmentation, and an optional "fast reconnect" mode.
EAP-IKEv2 has sucessfully passed Designated Expert Review as mandated EAP-IKEv2 has sucessfully passed Designated Expert Review as mandated
by RFC 3748. by RFC 3748.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
4. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 3, line 35 skipping to change at page 3, line 35
8.10. Authentication Payload . . . . . . . . . . . . . . . . . 24 8.10. Authentication Payload . . . . . . . . . . . . . . . . . 24
8.11. Notify Payload . . . . . . . . . . . . . . . . . . . . . 24 8.11. Notify Payload . . . . . . . . . . . . . . . . . . . . . 24
8.12. Next Fast-ID Payload . . . . . . . . . . . . . . . . . . 24 8.12. Next Fast-ID Payload . . . . . . . . . . . . . . . . . . 24
9. Payload Types and Extensibility . . . . . . . . . . . . . . . 26 9. Payload Types and Extensibility . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10.1. Protected Ciphersuite Negotiation . . . . . . . . . . . . 27 10.1. Protected Ciphersuite Negotiation . . . . . . . . . . . . 27
10.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 27 10.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 27
10.3. Integrity Protection . . . . . . . . . . . . . . . . . . 28 10.3. Integrity Protection . . . . . . . . . . . . . . . . . . 28
10.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 28 10.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 28
10.5. Confidentiality . . . . . . . . . . . . . . . . . . . . . 28 10.5. Confidentiality . . . . . . . . . . . . . . . . . . . . . 28
10.6. Key Strength . . . . . . . . . . . . . . . . . . . . . . 28 10.6. Key Strength . . . . . . . . . . . . . . . . . . . . . . 29
10.7. Dictionary Attack Resistance . . . . . . . . . . . . . . 29 10.7. Dictionary Attack Resistance . . . . . . . . . . . . . . 29
10.8. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 29 10.8. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 30
10.9. Cryptographic Binding . . . . . . . . . . . . . . . . . . 29 10.9. Cryptographic Binding . . . . . . . . . . . . . . . . . . 30
10.10. Session Independence . . . . . . . . . . . . . . . . . . 29 10.10. Session Independence . . . . . . . . . . . . . . . . . . 30
10.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 30 10.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 31
10.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30 10.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative References . . . . . . . . . . . . . . . . . . 35 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
14.2. Informative References . . . . . . . . . . . . . . . . . 35 14.1. Normative References . . . . . . . . . . . . . . . . . . 36
Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication . 36 14.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 40
1. Introduction 1. Introduction
This document specifies EAP-IKEv2, an EAP method that is based on the This document specifies EAP-IKEv2, an EAP method that is based on the
Internet Key Exchange Protocol version 2 (IKEv2) [1]. It provides Internet Key Exchange Protocol version 2 (IKEv2) [1]. The IKEv2
mutual authentication and session key establishment between an EAP protocol is also able to carry AP exchanges inside IKEv2 but this
peer and an EAP server. It supports authentication techniques that method does not inherit the capabilites to tunnel EAP methods inside
are based on the following types of credential. this EAP method. EAP-IKEv2 provides mutual authentication and
session key establishment between an EAP peer and an EAP server. It
supports authentication techniques that are based on the following
types of credential.
o Asymmetric key pairs: these are public/private key pairs where the o Asymmetric key pairs: these are public/private key pairs where the
public key is embedded into a digital certificate, and the public key is embedded into a digital certificate, and the
corresponding private key is known only to a single party. corresponding private key is known only to a single party.
o Passwords: these are low-entropy bit strings that are known to o Passwords: these are low-entropy bit strings that are known to
both the server and the peer. both the server and the peer.
o Symmetric keys: these are high-entropy bit strings that known to o Symmetric keys: these are high-entropy bit strings that known to
both the server and the peer. both the server and the peer.
It is possible to use a different authentication credential (and It is possible to use a different authentication credential (and
thereby technique) for each direction, e.g., the EAP server may thereby technique) for each direction, e.g., the EAP server may
authenticate itself using a public/private key pair and the EAP authenticate itself using a public/private key pair and the EAP
client may authenticate itself using a symmetric key. In particular, client may authenticate itself using a symmetric key. In particular,
the following combinations are expected to be used in practice. the following combinations are expected to be used in practice.
These are referred to as "use cases" in the remainder of this These are referred to as "use cases or modes" in the remainder of
document. this document.
1. EAP server: asymmetric key pair, EAP peer: asymmetric key pair 1. EAP server: asymmetric key pair, EAP peer: asymmetric key pair
2. EAP server: asymmetric key pair, EAP peer: symmetric key 2. EAP server: asymmetric key pair, EAP peer: symmetric key
3. EAP server: asymmetric key pair, EAP peer: password 3. EAP server: asymmetric key pair, EAP peer: password
4. EAP server: symmetric key, EAP peer: symmetric key 4. EAP server: symmetric key, EAP peer: symmetric key
Note that, in use cases 2 and 4, a symmetric key is assumed to be 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 chosen uniformly at random from its key space; it is therefore
assumed that symmetric keys are not derived from passwords. Also assumed that symmetric keys are not derived from passwords. Deriving
note that, in use case 3, the EAP server must either have access to a symmetric key from a password is insecure when used with mode 4
all passwords in plaintext, or, alternatively, for each password since the exchange is vulnerable to dictionary attacks, as described
store the value prf(password,"Key Pad for EAP-IKEv2") for all in more detail in Section 10.7. Also note that, in use case 3, the
supported pseudorandom functions (also see Section 8.10 below and EAP server must either have access to all passwords in plaintext, or,
Section 2.15 of [1]). Other conceivable use cases are not expected alternatively, for each password store the value prf(password,"Key
to be used in practice due to key management issues, and have not Pad for EAP-IKEv2") for all supported pseudorandom functions (also
been considered in this document. see Section 8.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. The remainder of this document is structured as follows.
o Section 2 provides an overview of the terminology and the o Section 2 provides an overview of the terminology and the
abbreviations used in this document. abbreviations used in this document.
o Section 3 provides an overview of the full EAP-IKEv2 exchange and o Section 3 provides an overview of the full EAP-IKEv2 exchange and
thereby specifies the protocol message composition. thereby specifies the protocol message composition.
o Section 4 specifies the optional EAP-IKEv2 "fast reconnect" mode o Section 4 specifies the optional EAP-IKEv2 "fast reconnect" mode
skipping to change at page 10, line 11 skipping to change at page 10, line 11
constructs message 6. That message MUST contain the EAP-IKEv2 header constructs message 6. That message MUST contain the EAP-IKEv2 header
followed by a single Encrypted payload, in which at least two further followed by a single Encrypted payload, in which at least two further
payloads MUST be embedded, as shown in Figure 1. payloads MUST be embedded, as shown in Figure 1.
Upon reception of message 6, the initiator (EAP server) authenticates Upon reception of message 6, the initiator (EAP server) authenticates
the responder (EAP peer). As above, the checks that are performed to the responder (EAP peer). As above, the checks that are performed to
this end depend on the use case, local policies, and MUST include this end depend on the use case, local policies, and MUST include
decryption and verification of the Encrypted payload, as well as decryption and verification of the Encrypted payload, as well as
checking that the Authentication payload contains the expected value. checking that the Authentication payload contains the expected value.
If the optional SK{IDr} payload was included in message 4, the EAP 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 server MUST also ensure that the IDr payload in message 6 is
to that in message 4. identical to that in message 4.
If authentication succeeds, an EAP-Success message is sent to the If authentication succeeds, an EAP-Success message is sent to the
responder as message 7. The EAP server and the EAP peer generate a responder as message 7. The EAP server and the EAP peer generate a
Master Session Key (MSK) and an Extended Master Session Key (EMSK) Master Session Key (MSK) and an Extended Master Session Key (EMSK)
after a successful EAP-IKEv2 protocol run, according to Section 5. after a successful EAP-IKEv2 protocol run, according to Section 5.
4. Fast Reconnect 4. Fast Reconnect
This section specifies a "fast reconnect" mode of operation for EAP- This section specifies a "fast reconnect" mode of operation for EAP-
IKEv2. This mode is mandatory to implement, but optional to use. IKEv2. This mode is mandatory to implement, but optional to use.
skipping to change at page 11, line 21 skipping to change at page 11, line 21
The "fast reconnect" mode can only be used where an EAP-IKEv2 The "fast reconnect" mode can only be used where an EAP-IKEv2
security context already exists at both the server and the peer, and 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 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 only be used by an EAP server/EAP peer pair that has already
performed mutual authentication in a previous EAP-IKEv2 protocol run. performed mutual authentication in a previous EAP-IKEv2 protocol run.
The fast reconnect mode makes use of dedicated "fast reconnect EAP The fast reconnect mode makes use of dedicated "fast reconnect EAP
identifiers". The idea is that the server indicates its willingness identifiers". The idea is that the server indicates its willingness
to engage in "fast reconnect" protocol runs in the future by to engage in "fast reconnect" protocol runs in the future by
including the optional "Next Fast-ID" (NFID) payload in message 5 of including the optional "Next Fast-ID" (NFID) payload in message 5 of
a "full" protocol run (Figure 1), or in message 3 of a "fast a "full" protocol run (see Figure 1), or in message 3 of a "fast
reconnect" protocol run (Figure 2). This NFID payload contains a reconnect" protocol run (see Figure 2). This NFID payload contains a
special EAP identity, denoted Fast Reconnect Identity (FRID) as the special EAP identity, denoted Fast Reconnect Identity (FRID) as the
NAI in the EAP-Response/Identity message. The FRID contains of a NAI in the EAP-Response/Identity message. The FRID contains an
username and a NAI realm part. A short discussion about the obfuscated username part and a realm part. When generating a FRID
generation of the FRID is provided below: the following aspects should be considered:
The FRID and therefore the pseudonym usernames are generated by The FRID and therefore the pseudonym usernames are generated by
the EAP server. The EAP server produces pseudonym usernames in an the EAP server. The EAP server produces pseudonym usernames in an
implementation-dependent manner. Only the EAP server needs to be implementation-dependent manner. Only the EAP server needs to be
able to map the pseudonym username to the permanent identity. able to map the pseudonym username to the permanent identity.
EAP-IKEv2 includes no provisions to ensure that the same EAP EAP-IKEv2 includes no provisions to ensure that the same EAP
server that generated a pseudonym username will be used on the server that generated a pseudonym username will be used on the
authentication exchange when the pseudonym username is used. It authentication exchange when the pseudonym username is used. It
is recommended that the EAP servers implement some centralized is recommended that the EAP servers implement some centralized
mechanism to allow all EAP servers of the home operator to map mechanism to allow all EAP servers of the home operator to map
pseudonyms generated by other severs to the permanent identity. pseudonyms generated by other severs to the permanent identity.
If no such mechanism is available, then the EAP server, failing to If no such mechanism is available, then the EAP server, failing to
understand a pseudonym issued by another server, can request the understand a pseudonym issued by another server, can request the
peer to send the permanent identity. peer to send the permanent identity.
When generating FRIDs, the server SHOULD choose a fresh, new FRID When generating FRIDs, the server SHOULD choose a fresh and unique
that is different from the previous ones that were used after the FRID that is different from the previous ones that were used after
same full authentication exchange. The FRID SHOULD include a the same full authentication exchange. The FRID SHOULD include a
random component. The random component works as a reference to random component in the username part. The random component works
the security context. Regardless of construction method, the as a reference to the security context. Regardless of the
pseudonym username MUST conform to the grammar specified for the construction method, the pseudonym username MUST conform to the
username portion of an NAI. Also, the FRID MUST conform to the grammar specified for the username portion of an NAI. Also, the
NAI grammar. The EAP servers that the subscribers of an operator FRID MUST conform to the NAI grammar [4]. The EAP servers, which
can use MUST ensure that the pseudonym usernames and the username subscribers of an operator can use, MUST ensure that the username
portions used in FRIDs that they generate are unique. part of a FRIDs that they generate are unique.
The peer MAY use the FRID to indicate to start a "fast reconnect" The peer MAY use the FRID to indicate to start a "fast reconnect"
protocol run. The EAP Identity Response MUST be sent at the protocol run. The EAP Identity Response MUST be sent at the
beginning of a "fast reconnect" protocol run. If, in the previous beginning of a "fast reconnect" protocol run. If, in the previous
successful "full" EAP-IKEv2 protocol execution, the server had not successful "full" EAP-IKEv2 protocol execution, the server had not
included an NFID payload in message 5 (resp. 3), then the peer MUST included an NFID payload in message 5 (resp. 3), then the peer MUST
NOT start a fast reconnect protocol run. On reception of FRID, the NOT start a fast reconnect protocol run. On reception of FRID, the
server maps it to an existing EAP-IKEv2 security context. Depending server maps it to an existing EAP-IKEv2 security context. Depending
on local policy, the server either proceeds with the "fast reconnect" on local policy, the server either proceeds with the "fast reconnect"
protocol run, or proceeds with message 3 of a "full" protocol run. protocol run, or proceeds with message 3 of a "full" protocol run.
skipping to change at page 12, line 29 skipping to change at page 12, line 29
Because the peer may fail to save a FRID that was sent in the NFID Because the peer may fail to save a FRID that was sent in the NFID
payload (for example, due to malfunction), the EAP server SHOULD payload (for example, due to malfunction), the EAP server SHOULD
maintain, at least, the most recently used FRID in addition to the maintain, at least, the most recently used FRID in addition to the
most recently issued FRID. If the authentication exchange is not most recently issued FRID. If the authentication exchange is not
completed successfully, then the server MUST NOT overwrite the FRID completed successfully, then the server MUST NOT overwrite the FRID
that was issued during the most recent successful authentication that was issued during the most recent successful authentication
exchange. exchange.
The EAP-IKEv2 fast reconnect exchange is similar to the IKE-SA The EAP-IKEv2 fast reconnect exchange is similar to the IKE-SA
rekeying procedure as specified in Section 2.18 of [1]. During fast rekeying procedure as specified in Section 2.18 of [1]. Thus, it
reconnect, the server and the peer MAY exchange fresh Diffie-Hellman uses a CREATE_CHILD_SA request and response. The SPIs on those two
values. messages would be the SPI's negotiated on the previous exchange.
During fast reconnect, the server and the peer MAY exchange fresh
Diffie-Hellman values.
1. R<-I: EAP-Request/Identity 1. R<-I: EAP-Request/Identity
2. R->I: EAP-Response/Identity(FRID) 2. R->I: EAP-Response/Identity(FRID)
3. R<-I: EAP-Req(HDR, SK{SA, Ni, [KEi], [NFID]}) 3. R<-I: EAP-Req(HDR, SK{SA, Ni, [KEi], [NFID]})
4. R->I: EAP-Res(HDR, SK{SA, Nr, [KEr]}) 4. R->I: EAP-Res(HDR, SK{SA, Nr, [KEr]})
5. R<-I: EAP-Success 5. R<-I: EAP-Success
Figure 2: EAP-IKEv2 successful fast reconnect protocol run Figure 2: Fast Reconnect Protocol Run
Figure 2 shows the message exchange for the EAP-IKEv2 fast reconnect Figure 2 shows the message exchange for the EAP-IKEv2 fast reconnect
mode. As in the full mode, the EAP server is the initiator and the 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 EAP peer is the responder. The first two messages constitute the
standard EAP identity exchange. Note that, in order to use the "fast 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 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. the peer to indicate its "fast reconnect" identity FRID in message 2.
If the server can map the FRID to an existing EAP-IKEv2 context it If the server can map the FRID to an existing EAP-IKEv2 context it
proceeds with message 3. Note that, in this message, the server MAY proceeds with message 3. Note that, in this message, the server MAY
embed a NFID payload into the encrypted payload to provide a new FRID embed a NFID payload into the encrypted payload to provide a new FRID
skipping to change at page 18, line 17 skipping to change at page 18, line 17
payload that decrypts to a non-existent or unauthorised EAP-IKEv2 payload that decrypts to a non-existent or unauthorised EAP-IKEv2
responder identifier IDr*, then the server SHOULD continue the responder identifier IDr*, then the server SHOULD continue the
protocol with a message conforming to the format of message 5. The protocol with a message conforming to the format of message 5. The
AUTH payload in that message SHOULD contain a value that is AUTH payload in that message SHOULD contain a value that is
computationally indistinguishable from a value that it would contain computationally indistinguishable from a value that it would contain
if IDr* was valid and authorised. This can be accomplished, for if IDr* was valid and authorised. This can be accomplished, for
example, by generating a random key and calculate AUTH as usual example, by generating a random key and calculate AUTH as usual
(however, this document does not mandate a specific mechanism). Only (however, this document does not mandate a specific mechanism). Only
after receiving message 6, the server SHOULD respond with an after receiving message 6, the server SHOULD respond with an
authentication failure notification, i.e., a message conforming to authentication failure notification, i.e., a message conforming to
message 6 in Figure 9. The purpose of this behaviour is to prevent message 6 in Figure 10. The purpose of this behaviour is to prevent
an adversary from probing the EAP-IKEv2 peer identifier space. 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- 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 IKEv2 protocol run (see Figure 1), the initiator receives, in message
4, an SK{IDr} payload that decrypts to an EAP-IKEv2 responder 4, an SK{IDr} payload that decrypts to an EAP-IKEv2 responder
identifier IDr*, then the server MUST continue the protocol as usual identifier IDr*, then the server MUST continue the protocol as usual
(note that such a payload would not be required in these use cases). (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, The server MUST compare IDr* with the IDr received in message 6 and,
in case of a mismatch, MUST respond with an authentication failure in case of a mismatch, MUST respond with an authentication failure
notification, i.e., a message conforming to message 6 in Figure 9. notification, i.e., a message conforming to message 6 in Figure 10.
If no mismatch is detected, normal processing applies. If no mismatch is detected, normal processing applies.
Other errors do not trigger messages with Notification payloads to be Other errors do not trigger messages with Notification payloads to be
sent, and MUST be treated as if nothing happened (i.e., the erroneous sent, and MUST be treated as if nothing happened (i.e., the erroneous
EAP-IKEv2 packet MUST be silently discarded). This includes EAP-IKEv2 packet MUST be silently discarded). This includes
situations where at least one of the following conditions is met, situations where at least one of the following conditions is met,
with respect to an incoming EAP-IKEv2 packet. with respect to an incoming EAP-IKEv2 packet.
o The packet contains an Encrypted payload that, when decrypted with o The packet contains an Encrypted payload that, when decrypted with
the appropriate key, yields an invalid decryption. the appropriate key, yields an invalid decryption.
skipping to change at page 25, line 27 skipping to change at page 25, line 27
The Next Fast-ID payload, denoted NFID, does not have an equivalent The Next Fast-ID payload, denoted NFID, does not have an equivalent
in IKEv2. Nevertheless, the Next Payload, C, RESERVED, and Payload in IKEv2. Nevertheless, the Next Payload, C, RESERVED, and Payload
Length fields of this payload are constructed according to Section Length fields of this payload are constructed according to Section
3.2 of [1]. The payload ID is registered in Section 11. The Fast- 3.2 of [1]. The payload ID is registered in Section 11. The Fast-
Reconnect-ID field contains a fast reconnect identifer that the peer Reconnect-ID field contains a fast reconnect identifer that the peer
can use in the next fast reconnect protocol run, as described in can use in the next fast reconnect protocol run, as described in
Section 4. In environments where a realm portion is required, Fast- Section 4. In environments where a realm portion is required, Fast-
Reconnect-ID includes both a username portion and a realm name Reconnect-ID includes both a username portion and a realm name
portion. The Fast-Reconnect-ID MUST NOT include any terminating null portion. The Fast-Reconnect-ID MUST NOT include any terminating null
characters. The encoding of the Fast-Reconnect-ID field MUST follow characters. The encoding of the Fast-Reconnect-ID field MUST follow
the UTF-8 transformation format [4] and SHOULD follow the NAI format, the NAI format [4].
too [5].
9. Payload Types and Extensibility 9. Payload Types and Extensibility
In EAP-IKEv2, each payload is identified by means of a type field 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 which, as specified in [1], is indicated in the "Next Payload" field
of the preceding payload. However, the identifer space from which of the preceding payload. However, the identifer space from which
EAP-IKEv2 payload types are drawn is independent from the payload EAP-IKEv2 payload types are drawn is independent from the payload
type space of IKEv2. This is because EAP-IKEv2 and IKEv2 may evolve 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 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 protocol do not necessary appear in the other. An example of this is
skipping to change at page 27, line 22 skipping to change at page 27, line 22
only take place after the server has been successfully authenticated. only take place after the server has been successfully authenticated.
In other words, this assignment of initiator and responder roles In other words, this assignment of initiator and responder roles
results in protection against offline dictionary attacks on the results in protection against offline dictionary attacks on the
password that is used by the peer to authenticate itself (see password that is used by the peer to authenticate itself (see
Section 10.7). Section 10.7).
In order for two EAP-IKEv2 implementations to be interoperable, they In order for two EAP-IKEv2 implementations to be interoperable, they
must support at least one common set of cryptographic algorithms. In must support at least one common set of cryptographic algorithms. In
order to promote interoperability, EAP-IKEv2 implementations MUST order to promote interoperability, EAP-IKEv2 implementations MUST
support the following algorithms based on the "MUST/MUST-" support the following algorithms based on the "MUST/MUST-"
recommendations given in [6]: recommendations given in [5]:
Diffie-Hellman Groups: 1024 MODP Group Diffie-Hellman Groups: 1024 MODP Group
IKEv2 Transform Type 1 Algorithms: ENCR_3DES IKEv2 Transform Type 1 Algorithms: ENCR_3DES
IKEv2 Transform Type 2 Algorithms: PRF_HMAC_SHA1 IKEv2 Transform Type 2 Algorithms: PRF_HMAC_SHA1
IKEv2 Transform Type 3 Algorithms: AUTH_HMAC_SHA1_96 IKEv2 Transform Type 3 Algorithms: AUTH_HMAC_SHA1_96
All other options of [6] MAY be implemented. All other options of [5] MAY be implemented.
The remainder of this section describes EAP-IKEv2 in terms of The remainder of this section describes EAP-IKEv2 in terms of
specific security terminology as required by [2]. The discussion specific security terminology as required by [2]. The discussion
makes reference to the use cases defined in Section 1. makes reference to the use cases defined in Section 1.
10.1. Protected Ciphersuite Negotiation 10.1. Protected Ciphersuite Negotiation
In message 3, the EAP server provides the set of ciphersuites it is 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 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 in control of the ciphersuite. An EAP peer that does not support any
skipping to change at page 28, line 43 skipping to change at page 28, line 43
Identity confidentiality is provided in the face of a passive Identity confidentiality is provided in the face of a passive
adversary, i.e., an adversary that does not modify traffic as it is 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 in transit. Whenever the optional SK{IDr} payload in message 4 of a
full EAP-IKEv2 protocol (see Figure 1) is not included, identity full EAP-IKEv2 protocol (see Figure 1) is not included, identity
confidentiality is also provided in the face of an active adversary. 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 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- case 4 this payload MUST be included. Therefore, in use case 4, EAP-
IKEv2 does not provide identity confidentiality in the face of an IKEv2 does not provide identity confidentiality in the face of an
active adversary. active adversary.
Note, however, that the EAP peer provides it's identity in message 2
in Figure 1 in cleartext. In order to provide identity
confidentiality as discussed in the previous paragraphs it is
necessary to obfuscated the username part of the identity (the realm
part must stay intact to allow correct message routing by the AAA
infrastructure). The EAP server then uses the identity information
in message 4. The same mechanism is also used by other EAP methods
to provide identity confidentiality, for example EAP-TTLS [8].
10.6. Key Strength 10.6. Key Strength
EAP-IKEv2 supports the establishment of session keys (MSK and EMSK) EAP-IKEv2 supports the establishment of session keys (MSK and EMSK)
of a variety of key strengths, with the theoretical maximum at 512 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). 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 However, in practice the effective key strength is likely to be
significantly lower, and depends on the authentication credentials significantly lower, and depends on the authentication credentials
used, the negotiated ciphersuite (including the output size of the used, the negotiated ciphersuite (including the output size of the
pseudorandom function), the Diffie-Hellman group used, and on the pseudorandom function), the Diffie-Hellman group used, and on the
extent to which the assumptions on which the underlying cryptographic extent to which the assumptions on which the underlying cryptographic
skipping to change at page 29, line 34 skipping to change at page 29, line 45
executed only after the server has authenticated itself (based on a executed only after the server has authenticated itself (based on a
credential other than a password). credential other than a password).
In order to reduce exposure against online dictionary attacks, in use In order to reduce exposure against online dictionary attacks, in use
case 3, the server SHOULD provide the capability to log failed peer case 3, the server SHOULD provide the capability to log failed peer
authentication events, and SHOULD implement a suitable policy in case authentication events, and SHOULD implement a suitable policy in case
of consecutive failed peer authentication attempts within a short of consecutive failed peer authentication attempts within a short
period of time (such as responding with an EAP-Failure instead of period of time (such as responding with an EAP-Failure instead of
message 5 for a predetermined amount of time). message 5 for a predetermined amount of time).
When passwords are used with method 4 (instead of using an key with
high entropy) then dictionary attacks are possible, as described in
Section 8 of [1]:
" When using pre-shared keys, a critical consideration is how to
assure the randomness of these secrets. The strongest practice is
to ensure that any pre-shared key contain as much randomness as
the strongest key being negotiated. Deriving a shared secret from
a password, name, or other low-entropy source is not secure.
These sources are subject to dictionary and social engineering
attacks, among others. "
Hence, the usage of passwords with mode 4 where the EAP peer and the
EAP server rely on a shared secret that was derived from a password
is insecure. It is strongly recommended to use mode 3 when passwords
are used by the EAP peer.
10.8. Fast Reconnect 10.8. Fast Reconnect
EAP-IKEv2 supports a "fast reconnect" mode of operation, as described EAP-IKEv2 supports a "fast reconnect" mode of operation, as described
in Section 4. in Section 4.
10.9. Cryptographic Binding 10.9. Cryptographic Binding
EAP-IKEv2 is not a tunnel EAP method. Thus, cryptographic binding EAP-IKEv2 is not a tunnel EAP method. Thus, cryptographic binding
does not apply to EAP-IKEv2. does not apply to EAP-IKEv2.
skipping to change at page 31, line 5 skipping to change at page 31, line 14
10.11. Fragmentation 10.11. Fragmentation
EAP-IKEv2 provides support for fragmentation, as described in EAP-IKEv2 provides support for fragmentation, as described in
Section 8.1. Section 8.1.
10.12. Channel Binding 10.12. Channel Binding
Channel binding is not supported in EAP-IKEv2. Channel binding is not supported in EAP-IKEv2.
10.13. Summary
EAP security claims are defined in Section 7.2.1 of [2]. The
security claims for EAP-IKEv2 are as follows:
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes; see Section 5
Key strength: Variable
Dictionary attack prot.: Yes; see Section 10.7
Fast reconnect: Yes; see Section 4
Crypt. binding: N/A
Session independence: Yes; see Section 10.10
Fragmentation: Yes; see Section 10.11
Channel binding: No
11. IANA Considerations 11. IANA Considerations
IANA should allocate a value for the EAP method type indicating EAP- IANA should allocate a value for the EAP method type indicating EAP-
IKEv2. IKEv2.
In addition, IANA is requested to create a new registry for EAP-IKEv2 In addition, IANA is requested to create a new registry for EAP-IKEv2
payloads, and populate it with the following initial entries listed payloads, and populate it with the following initial entries listed
below. below.
The following payload type values are used by this document. The following payload type values are used by this document.
skipping to change at page 31, line 43 skipping to change at page 32, line 43
RESERVED TO IANA | 13-127 RESERVED TO IANA | 13-127
PRIVATE USE | 128-255 PRIVATE USE | 128-255
Payload type values 13-127 are reserved to IANA for future assignment Payload type values 13-127 are reserved to IANA for future assignment
in EAP-IKEv2. Payload type values 128-255 are for private use among in EAP-IKEv2. Payload type values 128-255 are for private use among
mutually consenting parties. mutually consenting parties.
The semantic of the above-listed payloads is provided in this The semantic of the above-listed payloads is provided in this
document and refer to IKEv2 when necessary. document and refer to IKEv2 when necessary.
Following the policies outline in [8] new payload type values with a Following the policies outline in [9] new payload type values with a
description of their semantic will be assigned after Expert Review description of their semantic will be assigned after Expert Review
initiated by the Security Area Directors in consultation with the EMU initiated by the Security Area Directors in consultation with the EMU
working group chairs or the working group chairs of a designated working group chairs or the working group chairs of a designated
successor working group. Updates can be provided based on expert successor working group. Updates can be provided based on expert
approval only. A designated expert will be appointed by the Security approval only. A designated expert will be appointed by the Security
Area Directors. Based on expert approval it is possible to delete Area Directors. Based on expert approval it is possible to delete
entries from the registry or to mark entries as "deprecated". entries from the registry or to mark entries as "deprecated".
Each registration must include the payload type value and the Each registration must include the payload type value and the
semantic of the payload. semantic of the payload.
skipping to change at page 34, line 13 skipping to change at page 35, line 13
this draft. this draft.
13. Acknowledgements 13. Acknowledgements
The authors also thank Pasi Eronen for his invaluable comments as The authors also thank Pasi Eronen for his invaluable comments as
expert reviewer assigned by the EAP working group chairs Jari Arkko expert reviewer assigned by the EAP working group chairs Jari Arkko
and Bernard Aboba. The authors would also like to thank Guenther and Bernard Aboba. The authors would also like to thank Guenther
Horn, Thomas Otto, Paulo Pagliusi and John Vollbrecht for their Horn, Thomas Otto, Paulo Pagliusi and John Vollbrecht for their
insightful comments and suggestions. The members of the PANA design insightful comments and suggestions. The members of the PANA design
team, in particular D. Forsberg and A. Yegin, also provided comments team, in particular D. Forsberg and A. Yegin, also provided comments
on the initial version of this draft. on the initial version of this draft. We would like to thank Hugo
Krawczyk for his feedback regarding the usage of the password based
authentication.
The authors are grateful to the members of the EAP keying design team 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. for their discussion in the area of the EAP Key Management Framework.
Finally, we would like to thank Jari Arkko for his support and for We would like to thank Jari Arkko for his support and for his
his comments. comments. Finally, we would like to thank Charlie Kaufman, Bernard
Aboba, and Paul Hoffman for their comments during IETF Last Call.
14. References 14. References
14.1. Normative References 14.1. Normative References
[1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, [1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005. December 2005.
[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP) (RFC Levkowetz, "Extensible Authentication Protocol (EAP) (RFC
3748)", Request For Comments 3748, June 2004. 3748)", Request For Comments 3748, June 2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
RFC 3629.
[5] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005. Access Identifier", RFC 4282, December 2005.
[6] Schiller, J., "Cryptographic Algorithms for Use in the Internet [5] Schiller, J., "Cryptographic Algorithms for Use in the Internet
Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005. Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629.
14.2. Informative References 14.2. Informative References
[7] Aboba, B., "Extensible Authentication Protocol (EAP) Key [7] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-18 (work in Management Framework", draft-ietf-eap-keying-18 (work in
progress), February 2007. progress), February 2007.
[8] Aboba, B., "IANA Considerations for RADIUS (Remote [8] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication
Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-05 (work in
progress), July 2004.
[9] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, July 2003. Authentication Dial In User Service)", RFC 3575, July 2003.
Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication
This appendix illustrates how authentication failures are handled This appendix illustrates how authentication failures are handled
within EAP-IKEv2. Note that authentication failures only occur in within EAP-IKEv2. Note that authentication failures only occur in
full EAP-IKEv2 protocol runs. full EAP-IKEv2 protocol runs.
Figure 9 shows the message flow in case the EAP peer fails to Figure 10 shows the message flow in case the EAP peer fails to
authenticate the EAP server. authenticate the EAP server.
1. R<-I: EAP-Request/Identity 1. R<-I: EAP-Request/Identity
2. R->I: EAP-Response/Identity(Id) 2. R->I: EAP-Response/Identity(Id)
3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni) 3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)
4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}]) 4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])
5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH}) 5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH})
6. R->I: EAP-Res(HDR, SK {N(AUTHENTICATION_FAILED)}) 6. R->I: EAP-Res(HDR, SK {N(AUTHENTICATION_FAILED)})
7. R<-I: EAP-Failure 7. R<-I: EAP-Failure
Figure 9: EAP-IKEv2 with failed server authentication Figure 10: EAP-IKEv2 with failed server authentication
The difference to the full successful exchange described in Section 3 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 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 an Encrypted payload that contains a Notify payload with the Notify
Message Type value set to 24 (AUTHENTICATION_FAILED). In that Message Type value set to 24 (AUTHENTICATION_FAILED). In that
message, the Message ID field in the EAP-IKEv2 header (HDR), MUST message, the Message ID field in the EAP-IKEv2 header (HDR), MUST
carry Message ID value 2. In message 7, an EAP-Failure message MUST carry Message ID value 2. In message 7, an EAP-Failure message MUST
be returned by the EAP server. be returned by the EAP server.
Figure 10 shows the message flow in case the EAP server fails to Figure 11 shows the message flow in case the EAP server fails to
authenticate the EAP peer. authenticate the EAP peer.
1. R<-I: EAP-Request/Identity 1. R<-I: EAP-Request/Identity
2. R->I: EAP-Response/Identity(Id) 2. R->I: EAP-Response/Identity(Id)
3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni) 3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)
4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}]) 4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])
5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], AUTH}) 5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], AUTH})
6. R->I: EAP-Res (HDR, SK {IDr, [CERT], AUTH}) 6. R->I: EAP-Res (HDR, SK {IDr, [CERT], AUTH})
7. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)}) 7. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)})
8. R->I: EAP-Res (HDR, SK {}) 8. R->I: EAP-Res (HDR, SK {})
9. R<-I: EAP-Failure 9. R<-I: EAP-Failure
Figure 10: EAP-IKEv2 with failed peer authentication Figure 11: EAP-IKEv2 with failed peer authentication
Compared to the full successful exchange, one additional roundtrip is Compared to the full successful exchange, one additional roundtrip is
required. In message 7 the EAP server MUST send an EAP request with required. In message 7 the EAP server MUST send an EAP request with
Encrypted payload that contains a Notify payload with the Notify Encrypted payload that contains a Notify payload with the Notify
Message Type value set to 24 (AUTHENTICATION_FAILED), instead of Message Type value set to 24 (AUTHENTICATION_FAILED), instead of
sending an EAP-Success message. The EAP peer, upon receiving message sending an EAP-Success message. The EAP peer, upon receiving message
7, MUST send an empty EAP-IKEv2 (informational) message in reply to 7, MUST send an empty EAP-IKEv2 (informational) message in reply to
the EAP server's error indication, as shown in message 8. In both the EAP server's error indication, as shown in message 8. In both
message 7 and 8, the Message ID field in the EAP-IKEv2 header (HDR), message 7 and 8, the Message ID field in the EAP-IKEv2 header (HDR),
MUST carry Message ID value 2. Finally, by means of message 9, the MUST carry Message ID value 2. Finally, by means of message 9, the
 End of changes. 35 change blocks. 
82 lines changed or deleted 141 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/