summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5106.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5106.txt')
-rw-r--r--doc/rfc/rfc5106.txt1851
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc5106.txt b/doc/rfc/rfc5106.txt
new file mode 100644
index 0000000..91558fc
--- /dev/null
+++ b/doc/rfc/rfc5106.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Network Working Group H. Tschofenig
+Request for Comments: 5106 D. Kroeselberg
+Category: Experimental Nokia Siemens Networks
+ A. Pashalidis
+ NEC
+ Y. Ohba
+ Toshiba
+ F. Bersani
+ France Telecom
+ February 2008
+
+
+ The Extensible Authentication Protocol-Internet Key Exchange Protocol
+ version 2 (EAP-IKEv2) Method
+
+Status of This Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ This document specifies EAP-IKEv2, an Extensible Authentication
+ Protocol (EAP) 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. 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. Experimental [Page 1]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................4
+ 3. Protocol Overview ...............................................6
+ 4. Fast Reconnect ..................................................9
+ 5. Key Derivation .................................................12
+ 6. Session ID, Peer ID, and Server ID .............................13
+ 7. Error Handling .................................................13
+ 8. Specification of Protocol Fields ...............................16
+ 8.1. The Flags, Message Length, and Integrity Checksum
+ Data Fields ...............................................17
+ 8.2. EAP-IKEv2 Header ..........................................19
+ 8.3. Security Association Payload ..............................19
+ 8.4. Key Exchange Payload ......................................20
+ 8.5. Nonce Payload .............................................20
+ 8.6. Identification Payload ....................................20
+ 8.7. Certificate Payload .......................................20
+ 8.8. Certificate Request Payload ...............................20
+ 8.9. Encrypted Payload .........................................20
+ 8.10. Authentication Payload ...................................20
+ 8.11. Notify Payload ...........................................21
+ 8.12. Next Fast-ID Payload .....................................21
+ 9. Payload Types and Extensibility ................................22
+ 10. Security Considerations .......................................22
+ 10.1. Protected Ciphersuite Negotiation ........................23
+ 10.2. Mutual Authentication ....................................23
+ 10.3. Integrity Protection .....................................23
+ 10.4. Replay Protection ........................................23
+ 10.5. Confidentiality ..........................................23
+ 10.6. Key Strength .............................................24
+ 10.7. Dictionary Attack Resistance .............................24
+ 10.8. Fast Reconnect ...........................................25
+ 10.9. Cryptographic Binding ....................................25
+ 10.10. Session Independence ....................................25
+ 10.11. Fragmentation ...........................................26
+ 10.12. Channel Binding .........................................26
+ 10.13. Summary .................................................26
+ 11. IANA Considerations ...........................................27
+ 12. Contributors ..................................................28
+ 13. Acknowledgements ..............................................28
+ 14. References ....................................................29
+ 14.1. Normative References .....................................29
+ 14.2. Informative References ...................................29
+ Appendix A ........................................................30
+
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 2]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+1. Introduction
+
+ This document specifies EAP-IKEv2, an EAP method that is based on the
+ Internet Key Exchange Protocol version 2 (IKEv2) [1]. EAP-IKEv2
+ provides mutual authentication and session key establishment between
+ an EAP peer and an EAP server. It supports authentication techniques
+ that are based on the following types of credentials:
+
+ 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 are known
+ to both the server and the peer.
+
+ It is possible to use a different authentication credential (and
+ thereby technique) for each direction, e.g., the EAP server may
+ authenticate itself using a public/private key pair and the EAP
+ client may authenticate itself using a symmetric key. In particular,
+ the following combinations are expected to be used in practice; these
+ are referred to as "use cases" or "modes" in the remainder of this
+ document:
+
+ 1. EAP server: asymmetric key pair, EAP peer: asymmetric key pair
+
+ 2. EAP server: asymmetric key pair, EAP peer: symmetric key
+
+ 3. EAP server: asymmetric 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. Deriving
+ a symmetric key from a password is insecure when used with mode 4
+ since the exchange is vulnerable to dictionary attacks, as described
+ in more detail in Section 10.7. 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
+
+
+
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 3]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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.
+
+ Note that the IKEv2 protocol is able to carry EAP exchanges. By
+ contrast, EAP-IKEv2 does not inherit this capability. That is, it is
+ not possible to tunnel EAP methods inside EAP-IKEv2. Also note that
+ the set of functionality provided by EAP-IKEv2 is similar, but not
+ identical, to that provided by other EAP methods such as, for
+ example, EAP-TLS [6].
+
+ The remainder of this document is structured as follows:
+
+ o Section 2 provides an overview of the terminology and the
+ 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 the Session-ID, Peer-ID, and Server-ID
+ elements are derived.
+
+ o Section 7 specifies how errors that may potentially occur during
+ protocol execution are handled.
+
+ o Section 8 specifies the format of the EAP-IKEv2 data fields.
+ Section 8.1 describes how fragmentation is handled in EAP-IKEv2.
+
+ o Section 9 specifies the payload type values and describes protocol
+ extensibility.
+
+ o Section 10 provides a list of claimed security properties.
+
+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].
+
+
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 4]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ A list of abbreviations that are used in this document follows.
+
+ AUTH:
+
+ Denotes a data field containing either a Message Authentication
+ Code (MAC) or a signature. This field is embedded into an
+ Authentication payload, defined in Section 8.10.
+
+ CERT:
+
+ Public key certificate or similar structure.
+
+ CERTREQ:
+
+ Certificate Request.
+
+ NFID:
+
+ Next Fast-ID payload (see Sections 4 and 8.12)
+
+ EMSK:
+
+ Extended Master Session Key, defined in [2].
+
+ HDR:
+
+ EAP-IKEv2 header, defined in Section 8.2.
+
+ I:
+
+ Initiator, the party that sends the first message of an EAP-IKEv2
+ protocol run. This is always the EAP server.
+
+ MAC:
+
+ Message Authentication Code. The result of a cryptographic
+ operation that involves a symmetric key.
+
+ MSK:
+
+ Master Session Key, defined in [2].
+
+ prf:
+
+ Pseudorandom function: a cryptographic function whose output is
+ assumed to be indistinguishable from that of a truly random
+ function.
+
+
+
+
+Tschofenig, et al. Experimental [Page 5]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ R:
+
+ Responder, the party that sends the second message of an EAP-IKEv2
+ protocol run. This is always the EAP peer.
+
+ 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.
+
+ 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.
+
+ SK:
+
+ Session Key. In this document, the notation SK{x} denotes that x
+ is embedded within an Encrypted payload, i.e., that x is encrypted
+ and integrity-protected using EAP-IKEv2 internal keys. These keys
+ are different in each direction.
+
+ SK_xx:
+
+ EAP-IKEv2 internal key, defined in Section 2.14 of [1].
+
+ SKEYSEED:
+
+ Keying material, defined in Section 2.14 of [1].
+
+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.
+
+
+
+Tschofenig, et al. Experimental [Page 6]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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 Security Parameter Index (SPI) in the EAP-
+ IKEv2 header (HDR) (the initiator selects a new SPI for each protocol
+ run), 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
+ 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
+
+
+
+Tschofenig, et al. Experimental [Page 7]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ [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
+ identifier 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), then 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.
+
+ 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 payload 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. Experimental [Page 8]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+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
+ performed mutual authentication 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 "Next Fast-ID" (NFID) payload in message 5 of
+ a "full" protocol run (see Figure 1), or in message 3 of a "fast
+ reconnect" protocol run (see Figure 2). This NFID payload contains a
+ special EAP identity, denoted Fast Reconnect Identity (FRID) as the
+ Network Access Identifier (NAI) in the EAP-Response/Identity message.
+ The FRID contains an obfuscated username part and a realm part. When
+ generating a FRID, the following aspects should be considered:
+
+ The FRID and therefore the pseudonym usernames are generated by
+ the EAP server. The EAP server produces pseudonym usernames in an
+ implementation-dependent manner. Only the EAP server needs to be
+ able to map the pseudonym username to the permanent identity.
+
+ EAP-IKEv2 includes no provisions to ensure that the same EAP
+ server that generated a pseudonym username will be used on the
+ authentication exchange when the pseudonym username is used. It
+ is recommended that the EAP servers implement some centralized
+ mechanism to allow all EAP servers of the home operator to map
+ pseudonyms generated by other severs to the permanent identity.
+ If no such mechanism is available, then the EAP server, failing to
+ understand a pseudonym issued by another server, can request the
+ peer to send the permanent identity.
+
+ When generating FRIDs, the server SHOULD choose a fresh and unique
+ FRID that is different from the previous ones that were used after
+ the same full authentication exchange. The FRID SHOULD include a
+ random component in the username part. The random component works
+ as a reference to the security context. Regardless of the
+ construction method, the pseudonym username MUST conform to the
+ grammar specified for the username portion of an NAI. Also, the
+ FRID MUST conform to the NAI grammar [4]. The EAP servers, which
+ subscribers of an operator can use, MUST ensure that the username
+ part of a FRIDs that they generate are unique.
+
+
+
+Tschofenig, et al. Experimental [Page 9]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ The peer MAY use the FRID to indicate to start a "fast reconnect"
+ protocol run. The 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 start a fast reconnect protocol
+ run. On reception of FRID, the server maps it to an existing EAP-
+ IKEv2 security context. Depending on local policy, the server 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.
+
+ 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
+ maintain, at least, the most recently used FRID in addition to the
+ most recently issued FRID. If the authentication exchange is not
+ completed successfully, then the server MUST NOT overwrite the FRID
+ that was issued during the most recent successful authentication
+ exchange.
+
+ The EAP-IKEv2 fast reconnect exchange is similar to the IKE-SA
+ rekeying procedure, as specified in Section 2.18 of [1]. Thus, it
+ uses a CREATE_CHILD_SA request and response. The SPIs on those two
+ messages would be the SPIs 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
+
+ 2. R->I: EAP-Response/Identity(FRID)
+
+ 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: Fast Reconnect Protocol Run
+
+ 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
+ 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.
+
+
+
+Tschofenig, et al. Experimental [Page 10]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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
+ embed an NFID payload into the encrypted payload to provide a new
+ FRID to the peer. 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 substructure. Upon reception of
+ message 4, the initiator (EAP server) decrypts and verifies the
+ Encrypted payload. 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.
+
+
+
+Tschofenig, et al. Experimental [Page 11]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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.
+
+ 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.
+
+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
+ that 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 [7].
+
+
+
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 12]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+6. Session ID, Peer ID, and Server ID
+
+ The EAP key management framework [7] requires that EAP methods export
+ three information elements, called the Session-ID, the Peer-ID, and
+ the Server-ID. In EAP-IKEv2, these elements are derived as follows:
+
+ o The Session-ID is constructed and exported as the concatenation of
+ the following three elements, in this order: (a) the EAP Code Type
+ for EAP-IKEv2 (to be defined by IANA), (b) the contents of the
+ Nonce Data field of the Nonce Payload Ni from message 3, (c) the
+ contents of the Nonce Data field of the Nonce Payload Nr from
+ message 4.
+
+ o In case of a full EAP-IKEv2 protocol run, the Peer-ID is
+ constructed and exported as the content of the Identification Data
+ field of the Identification Payload IDr from message 6. Note that
+ only the "actual" identification data is exported, as indicated in
+ the Payload Length field; if the Identification Data field
+ contains any padding, this padding is ignored. In case of a "fast
+ reconnect" protocol run, the Peer-ID field is constructed in
+ exactly the same manner, where message 6 refers to the full EAP-
+ IKEv2 protocol run that originally established the security
+ context between the EAP peer and EAP server.
+
+ o In case of a full EAP-IKEv2 protocol run, the Server-ID is
+ constructed and exported as the contents of the Identification
+ Data field of the Identification Payload IDi from message 5. Note
+ that only the "actual" identification data is exported, as
+ indicated in the Payload Length field; if the Identification Data
+ field contains any padding, this padding is ignored. In case of a
+ "fast reconnect" protocol run, the Server-ID field is constructed
+ in exactly the same manner, where message 5 refers to the full
+ EAP-IKEv2 protocol run that originally established the security
+ context between the EAP peer and EAP server.
+
+7. 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 8.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.
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 13]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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 full
+ protocol run.
+
+ 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, 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 is a two-octet value 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, in the context of use case 4 and during a full EAP-IKEv2 protocol
+ 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 calculating AUTH as usual
+ (however, this document does not mandate a specific mechanism). Only
+ after receiving message 6, the server SHOULD respond with an
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 14]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ authentication failure notification, i.e., a message conforming to
+ message 6 in Figure 10. 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 10.
+ 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).
+
+ 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.
+
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 15]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ o The identity provided by the EAP peer in the EAP-Response/Identity
+ cannot be associated with either an established security context
+ (in case of a fast reconnect) or with a real user account (in case
+ of a full protocol exchange). In that case, the packet is
+ silently discarded. With an outstanding message from the EAP
+ server, the client may either retransmit the previous request or,
+ in case of a fast reconnect, assume that state information was
+ deleted (e.g., due to garbage collection) at the EAP server and
+ fall back to a previously used FRID or to the full protocol
+ exchange.
+
+ If an incoming packet contains an error for which a 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.
+
+8. 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 49.
+
+ 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 8.1. The Message Length field is
+ not always present; its presence is determined by a certain flag in
+ the Flags field, as described in Section 8.1. The field denoted as
+ "HDR + payloads" in Figure 4 contains the EAP-IKEv2 header (see
+ Section 8.2), followed by the number of payloads, in accordance with
+ the composition of EAP-IKEv2 messages, as described in the previous
+
+
+
+
+Tschofenig, et al. Experimental [Page 16]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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 8.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 deviations are highlighted in the remainder
+ of this section.
+
+8.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
+
+ The Flags field is defined in Figure 5. Only the first three bits
+ (0-2) are used; all remaining bits MUST be set to zero and ignored on
+ receipt. 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. (Note
+ that there exist two fields that are related to length: the Length
+
+
+
+
+Tschofenig, et al. Experimental [Page 17]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ field, which is a generic EAP field, and the Message Length field,
+ which is an EAP-IKEv2-specific field.) If the L bit is not set, then
+ 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 as
+ described below.
+
+ When an EAP-IKEv2 peer receives an EAP-Request packet with the M bit
+ set, it MUST respond with an EAP-Response with EAP-Type=EAP-IKEv2 and
+ no data. This serves as a fragment ACK. The EAP server MUST wait
+ until it receives the EAP-Response before sending another fragment.
+ In order to prevent errors in processing of fragments, the EAP server
+ MUST increment the Identifier field for each fragment contained
+ within an EAP-Request, and the peer MUST include this Identifier
+ value in the fragment ACK contained within the EAP-Response.
+ Retransmitted fragments will contain the same Identifier value.
+
+ Similarly, when the EAP server receives an EAP-Response with the M
+ bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-IKEv2
+ and no data. This serves as a fragment ACK. The EAP peer MUST wait
+ until it receives the EAP-Request before sending another fragment.
+ In order to prevent errors in the processing of fragments, the EAP
+ server MUST increment the Identifier value for each fragment ACK
+ contained within an EAP-Request, and the peer MUST include this
+ Identifier value in the subsequent fragment contained within an EAP-
+ Response.
+
+ 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
+ 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 8.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
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 18]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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.
+
+8.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 protocol run MUST carry Message ID value 0. Messages 5 and 6
+ in a full protocol run (see Figure 1) MUST carry Message ID value 1.
+ Messages 3 and 4 in a fast reconnect protocol run MUST carry Message
+ ID value 2.
+
+8.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).
+
+
+
+Tschofenig, et al. Experimental [Page 19]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+8.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].
+
+8.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].
+
+8.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].
+
+8.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.
+
+8.8. Certificate Request Payload
+
+ The Certificate Request payload, denoted CERTREQ, is constructed and
+ formatted according to the rules specified in Section 3.7 of [1].
+
+8.9. Encrypted Payload
+
+ The Encrypted payload, denoted SK{...}, is constructed and formatted
+ according to the rules specified in Section 3.14 of [1].
+
+8.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
+
+
+
+Tschofenig, et al. Experimental [Page 20]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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.
+
+8.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).
+
+8.12. Next Fast-ID Payload
+
+ The Next Fast-ID Payload is defined as follows:
+
+ 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 payload ID is registered in Section 11. The Fast-
+ Reconnect-ID field contains a fast reconnect identifier that the peer
+
+
+
+Tschofenig, et al. Experimental [Page 21]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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 NAI format [4].
+
+9. 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 identifier 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 listed
+ in Section 11. 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 mutually consenting parties.
+
+10. 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
+ 10.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
+ support the following algorithms based on the "MUST/MUST-"
+ recommendations given in [5]:
+
+ Diffie-Hellman Groups: 1024 MODP Group
+ IKEv2 Transform Type 1 Algorithms: ENCR_3DES
+ IKEv2 Transform Type 2 Algorithms: PRF_HMAC_SHA1
+ IKEv2 Transform Type 3 Algorithms: AUTH_HMAC_SHA1_96
+
+ All other options of [5] MAY be implemented.
+
+
+
+Tschofenig, et al. Experimental [Page 22]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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.
+
+10.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.
+
+10.2. Mutual Authentication
+
+ EAP-IKEv2 supports mutual authentication.
+
+10.3. Integrity Protection
+
+ EAP-IKEv2 provides integrity protection of EAP-IKEv2 traffic. This
+ protection is offered after authentication is completed and it 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 8.9).
+
+10.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.
+
+10.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.
+
+
+
+
+Tschofenig, et al. Experimental [Page 23]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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.
+
+ Note, however, that the EAP peer provides its 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 obfuscate the username part of the identity (the realm
+ part must stay intact to allow correct message routing by the
+ Authentication, Authorization, and Accounting (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
+
+ 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
+ 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.
+
+10.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.
+
+
+
+Tschofenig, et al. Experimental [Page 24]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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).
+
+ When passwords are used with method 4 (instead of using a key with
+ high entropy), 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
+
+ EAP-IKEv2 supports a "fast reconnect" mode of operation, as described
+ in Section 4.
+
+10.9. Cryptographic Binding
+
+ EAP-IKEv2 is not a tunnel EAP method. Thus, cryptographic binding
+ does not apply to EAP-IKEv2.
+
+10.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
+
+
+
+Tschofenig, et al. Experimental [Page 25]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ 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.
+
+ Secondly, an active adversary that does not know the peer's and
+ 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.
+
+10.11. Fragmentation
+
+ EAP-IKEv2 provides support for fragmentation, as described in Section
+ 8.1.
+
+10.12. Channel Binding
+
+ 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
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 26]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+11. IANA Considerations
+
+ IANA has allocated value 49 for the EAP method type indicating EAP-
+ IKEv2. EAP-IKEv2 has already earlier successfully passed Designated
+ Expert Review as mandated by RFC 3748 for IANA allocations.
+
+ In addition, IANA has created a new registry for "EAP-IKEv2
+ Payloads", and populated it with the following initial entries listed
+ below.
+
+ The following payload type values are used by this document.
+
+ Next Payload Type | Value
+ ----------------------------------+----------------------------------
+ No Next payload | 0
+ Security Association payload | 33
+ Key Exchange payload | 34
+ Identification payload |
+ (when sent by initiator, IDi) | 35
+ Identification payload |
+ (when sent by responder, IDr) | 36
+ Certificate payload | 37
+ Certificate Request payload | 38
+ Authentication payload | 39
+ Nonce payload | 40
+ Notification payload | 41
+ Vendor ID payload | 43
+ Encrypted payload | 46
+ Next Fast-ID payload | 121
+ RESERVED TO IANA | 1-32, 42, 44-45, 47-120, 122-127
+ PRIVATE USE | 128-255
+
+ Payload type values 1-120 match the corresponding payloads in the
+ IKEv2 IANA registry. That is, the EAP-IKEv2 payloads that have been
+ assigned a type value in the range 1-120 have a semantically
+ equivalent payload type in IKEv2, with an identical payload type
+ value. However, there exist payloads types in IKEv2 that do not have
+ a semantically equivalent payload in EAP-IKEv2; this explains the
+ fact that the payload type values 42, 44, and 45 have not been
+ assigned in EAP-IKEv2; these values remain RESERVED TO IANA for this
+ version of EAP-IKEv2.
+
+ Payload type values 121-127 are used for EAP-IKEv2 specific payloads,
+ i.e., for payloads that do not have a semantically equivalent payload
+ in IKEv2. Note that this range has been reserved for this purpose in
+ the IKEv2 IANA registry too. This means that the same payload type
+ values will not be used for different things in IKEv2 and EAP-IKEv2
+ protocols.
+
+
+
+Tschofenig, et al. Experimental [Page 27]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ Payload type values 122-127 are reserved to IANA for future
+ assignment to EAP-IKEv2-specific payloads. Payload type values
+ 128-255 are for private use among mutually consenting parties.
+
+ The semantics of the above-listed payloads is provided in this
+ document (0-127) and refer to IKEv2 when necessary (1-120).
+
+ New payload type values with a description of their semantic will be
+ assigned after Expert Review. The expert is chosen by the IESG in
+ consultation with the Security Area Directors and the EMU working
+ group chairs (or the working group chairs of a designated successor
+ working group). Updates can be provided based on expert approval
+ only. A designated expert will be appointed by the Security Area
+ Directors. Based on expert approval it is possible to delete entries
+ from the registry or to mark entries as "deprecated".
+
+ Each registration must include the payload type value and the
+ semantic of the payload.
+
+12. Contributors
+
+ The authors are grateful to Krzysztof Rzecki, Rafal Mijal, Piotr
+ Marnik, and Pawel Matejski, who, during their implementation of EAP-
+ IKEv2 (see http://eap-ikev2.sourceforge.net/), provided invaluable
+ feedback and identified a number of errors in previous versions of
+ this document.
+
+13. Acknowledgements
+
+ 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 document. 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
+ for their discussion in the area of the EAP Key Management Framework.
+
+ We would like to thank Jari Arkko for his support and for his
+ comments. Finally, we would like to thank Charlie Kaufman, Bernard
+ Aboba, and Paul Hoffman for their comments during IETF Last Call.
+
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 28]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+14. References
+
+14.1. Normative References
+
+ [1] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
+ 4306, December 2005.
+
+ [2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+ Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC
+ 3748, June 2004.
+
+ [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+ [4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
+ Access Identifier", RFC 4282, December 2005.
+
+ [5] Schiller, J., "Cryptographic Algorithms for Use in the Internet
+ Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
+
+14.2. Informative References
+
+ [6] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
+ RFC 2716, October 1999.
+
+ [7] Aboba, B., "Extensible Authentication Protocol (EAP) Key
+ Management Framework", Work in Progress, February 2007.
+
+ [8] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication
+ Protocol (EAP-TTLS)", Work in Progress, July 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 29]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+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 10 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 10: EAP-IKEv2 with Failed Server Authentication
+
+ The difference in 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 that
+ 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
+ be returned by the EAP server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 30]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+ Figure 11 shows the message flow in case the EAP server fails to
+ authenticate the EAP peer.
+
+ 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 11: 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. In
+ messages 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
+ EAP server answers with an EAP-Failure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 31]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+Authors' Addresses
+
+ Hannes Tschofenig
+ Nokia Siemens Networks
+ Otto-Hahn-Ring 6
+ Munich, Bavaria 81739
+ Germany
+
+ EMail: Hannes.Tschofenig@nsn.com
+ URI: http://www.tschofenig.com
+
+
+ Dirk Kroeselberg
+ Nokia Siemens Networks
+ Otto-Hahn-Ring 6
+ Munich, Bavaria 81739
+ Germany
+
+ EMail: Dirk.Kroeselberg@nsn.com
+
+
+ Andreas Pashalidis
+ NEC
+ Kurfuersten-Anlage 36
+ Heidelberg 69115
+ Germany
+
+ EMail: pashalidis@nw.neclab.eu
+
+
+ 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: florent.ftrd@gmail.com
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 32]
+
+RFC 5106 EAP-IKEv2 Method February 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al. Experimental [Page 33]
+