idnits 2.17.1 draft-tschofenig-eap-ikev2-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1467. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1473. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 27, 2007) is 6018 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'CERTREQ' on line 1369 -- Looks like a reference, but probably isn't: 'CERT' on line 1371 -- Looks like a reference, but probably isn't: 'NFID' on line 466 -- Looks like a reference, but probably isn't: 'KEi' on line 466 -- Looks like a reference, but probably isn't: 'IDr' on line 1342 == Unused Reference: '6' is defined on line 1309, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (ref. '1') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4282 (ref. '4') (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4307 (ref. '5') (Obsoleted by RFC 8247) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-18 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft D. Kroeselberg 4 Intended status: Experimental Nokia Siemens Networks 5 Expires: March 30, 2008 A. Pashalidis 6 NEC 7 Y. Ohba 8 Toshiba 9 F. Bersani 10 France Telecom 11 September 27, 2007 13 EAP-IKEv2 Method 14 draft-tschofenig-eap-ikev2-15.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on March 30, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document specifies EAP-IKEv2, an Extensible Authentication 48 Protocol (EAP) method that is based on the Internet Key Exchange 49 (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and 50 session key establishment between an EAP peer and an EAP server. It 51 supports authentication techniques that are based on passwords, high- 52 entropy shared keys, and public key certificates. EAP-IKEv2 further 53 provides support for cryptographic ciphersuite negotiation, hash 54 function agility, identity confidentiality (in certain modes of 55 operation), fragmentation, and an optional "fast reconnect" mode. 56 EAP-IKEv2 has sucessfully passed Designated Expert Review as mandated 57 by RFC 3748. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 64 4. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . . . 11 65 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 15 66 6. Session ID, Peer ID, and Server ID . . . . . . . . . . . . . . 16 67 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 17 68 8. Specification of Protocol Fields . . . . . . . . . . . . . . . 20 69 8.1. The Flags, Message Length, and Integrity Checksum 70 Data fields . . . . . . . . . . . . . . . . . . . . . . . 21 71 8.2. EAP-IKEv2 header . . . . . . . . . . . . . . . . . . . . 22 72 8.3. Security Association Payload . . . . . . . . . . . . . . 23 73 8.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 23 74 8.5. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 23 75 8.6. Identification Payload . . . . . . . . . . . . . . . . . 23 76 8.7. Certificate Payload . . . . . . . . . . . . . . . . . . . 23 77 8.8. Certificate Request Payload . . . . . . . . . . . . . . . 23 78 8.9. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 24 79 8.10. Authentication Payload . . . . . . . . . . . . . . . . . 24 80 8.11. Notify Payload . . . . . . . . . . . . . . . . . . . . . 24 81 8.12. Next Fast-ID Payload . . . . . . . . . . . . . . . . . . 24 82 9. Payload Types and Extensibility . . . . . . . . . . . . . . . 26 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 84 10.1. Protected Ciphersuite Negotiation . . . . . . . . . . . . 27 85 10.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 27 86 10.3. Integrity Protection . . . . . . . . . . . . . . . . . . 28 87 10.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 28 88 10.5. Confidentiality . . . . . . . . . . . . . . . . . . . . . 28 89 10.6. Key Strength . . . . . . . . . . . . . . . . . . . . . . 29 90 10.7. Dictionary Attack Resistance . . . . . . . . . . . . . . 29 91 10.8. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 30 92 10.9. Cryptographic Binding . . . . . . . . . . . . . . . . . . 30 93 10.10. Session Independence . . . . . . . . . . . . . . . . . . 30 94 10.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 31 95 10.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 31 96 10.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 31 97 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 98 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 99 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 36 102 14.2. Informative References . . . . . . . . . . . . . . . . . 36 103 Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication . 37 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 105 Intellectual Property and Copyright Statements . . . . . . . . . . 40 107 1. Introduction 109 This document specifies EAP-IKEv2, an EAP method that is based on the 110 Internet Key Exchange Protocol version 2 (IKEv2) [1]. The IKEv2 111 protocol is also able to carry AP exchanges inside IKEv2 but this 112 method does not inherit the capabilites to tunnel EAP methods inside 113 this EAP method. EAP-IKEv2 provides mutual authentication and 114 session key establishment between an EAP peer and an EAP server. It 115 supports authentication techniques that are based on the following 116 types of credential. 118 o Asymmetric key pairs: these are public/private key pairs where the 119 public key is embedded into a digital certificate, and the 120 corresponding private key is known only to a single party. 122 o Passwords: these are low-entropy bit strings that are known to 123 both the server and the peer. 125 o Symmetric keys: these are high-entropy bit strings that known to 126 both the server and the peer. 128 It is possible to use a different authentication credential (and 129 thereby technique) for each direction, e.g., the EAP server may 130 authenticate itself using a public/private key pair and the EAP 131 client may authenticate itself using a symmetric key. In particular, 132 the following combinations are expected to be used in practice. 133 These are referred to as "use cases or modes" in the remainder of 134 this document. 136 1. EAP server: asymmetric key pair, EAP peer: asymmetric key pair 138 2. EAP server: asymmetric key pair, EAP peer: symmetric key 140 3. EAP server: asymmetric key pair, EAP peer: password 142 4. EAP server: symmetric key, EAP peer: symmetric key 144 Note that, in use cases 2 and 4, a symmetric key is assumed to be 145 chosen uniformly at random from its key space; it is therefore 146 assumed that symmetric keys are not derived from passwords. Deriving 147 a symmetric key from a password is insecure when used with mode 4 148 since the exchange is vulnerable to dictionary attacks, as described 149 in more detail in Section 10.7. Also note that, in use case 3, the 150 EAP server must either have access to all passwords in plaintext, or, 151 alternatively, for each password store the value prf(password,"Key 152 Pad for EAP-IKEv2") for all supported pseudorandom functions (also 153 see Section 8.10 below and Section 2.15 of [1]). Other conceivable 154 use cases are not expected to be used in practice due to key 155 management issues, and have not been considered in this document. 157 The remainder of this document is structured as follows. 159 o Section 2 provides an overview of the terminology and the 160 abbreviations used in this document. 162 o Section 3 provides an overview of the full EAP-IKEv2 exchange and 163 thereby specifies the protocol message composition. 165 o Section 4 specifies the optional EAP-IKEv2 "fast reconnect" mode 166 of operation. 168 o Section 5 specifies how exportable session keys are derived. 170 o Section 6 specifies how the Session-ID, Peer-ID, and Server-ID 171 elements are derived. 173 o Section 7 specifies how errors that may potentially occur during 174 protocol execution are handled. 176 o Section 8 specifies the format of the EAP-IKEv2 data fields. 177 Section 8.1 describes how fragmentation is handled in EAP-IKEv2. 179 o Section 9 specifies the payload type values and describes protocol 180 extensibility. 182 o Section 10 provides a list of claimed security properties. 184 2. Terminology 186 This document makes use of terms defined in [2] and [1]. In 187 addition, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 188 SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear 189 in this document, are to be interpreted as described in [3]. 191 A list of abbreviations that are used in this document follows. 193 AUTH: 195 Denotes a data field containing either a MAC or a signature. This 196 field is in embedded into an Authentication payload, defined in 197 Section 8.10. 199 CERT: 201 Public key certificate or similar structure. 203 CERTREQ: 205 Certificate Request. 207 NFID: 209 Next Fast-ID payload (see Section 8.12 and Section 4) 211 EMSK: 213 Extended Master Session Key, defined in [2]. 215 HDR: 217 EAP-IKEv2 header, defined in Section 8.2. 219 I: 221 Initiator, the party that sends the first message of an EAP-IKEv2 222 protocol run. This is always the EAP server. 224 MAC: 226 Message Authentication Code. The result of a cryptographic 227 operation that involves a symmetric key. 229 MSK: 231 Master Session Key, defined in [2]. 233 prf: 235 Pseudorandom function: a cryptographic function whose output is 236 assumed to be indistinguishable from that of a truly random 237 function. 239 R: 241 Responder, the party that sends the second message of an EAP-IKEv2 242 protocol run. This is always the EAP peer. 244 SA: 246 Security Association. In this document SA denotes a type of 247 payload that is used for the negotiation of the cryptographic 248 algorithms that are to be used within an EAP-IKEv2 protocol run. 249 Specifically, SAi denotes a set of choices that are accepted by an 250 initiator, and SAr denotes the choice of the responder. 252 Signature: 254 The result of a cryptographic operation that involves an 255 asymmetric key. In particular, it involves the private part of a 256 public/private key pair. 258 SK: 260 Session Key. In this document, the notation SK{x} denotes that x 261 is embedded within an Encrypted payload, i.e.,, that x is 262 encrypted and integrity-protected using EAP-IKEv2 internal keys. 263 These keys are different in each direction. 265 SK_xx: 267 EAP-IKEv2 internal key, defined in Section 2.14 of [1]. 269 SKEYSEED: 271 Keying material, defined in Section 2.14 of [1]. 273 3. Protocol Overview 275 In this section, the full EAP-IKEv2 protocol run is specified. All 276 messages are sent between two parties, namely an EAP peer and an EAP 277 server. In EAP-IKEv2, the EAP server always assumes the role of the 278 initiator (I), and the EAP peer that of the responder (R) of an 279 exchange. 281 The semantics and formats of EAP-IKEv2 messages are similar, albeit 282 not identical, to those specified in IKEv2 [1] for the establishment 283 of an IKE Security Association. The full EAP-IKEv2 protocol run 284 consists of two roundtrips that are followed by either an EAP-Success 285 or an EAP-Failure message. An optional roundtrip for exchanging EAP 286 identities may precede the two exchanges. 288 1. R<-I: EAP-Request/Identity 290 2. R->I: EAP-Response/Identity(Id) 292 3. R<-I: EAP-Req (HDR, SAi, KEi, Ni) 294 4. R->I: EAP-Res (HDR, SAr, KEr, Nr, [CERTREQ], [SK{IDr}]) 296 5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], [NFID], AUTH}) 298 6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH}) 300 7. R<-I: EAP-Success 302 Figure 1: EAP-IKEv2 full, successful protocol run 304 Figure 1 shows the full EAP-IKEv2 protocol run, including the 305 optional EAP identity exchange (messages 1 and 2). A detailed 306 specification of the message composition follows. 308 Messages 1 and 2 are a standard EAP Identity Request and Response, as 309 defined in [2]. Message 3 is the first EAP-IKEv2-specific message. 310 With this, the server starts the actual EAP authentication exchange. 311 It contains the initiator SPI in the EAP-IKEv2 header (HDR) (the 312 initiator selects this value on a per-protocol run basis), the set of 313 cryptographic algorithms the server is willing to accept for the 314 protection of EAP-IKEv2 traffic (encryption and integrity protection) 315 and the derivation of the session key. This set is encoded in the 316 Security Association payload (SAi). It also contains a Diffie- 317 Hellman payload (KEi), and a Nonce payload (Ni). 319 When the peer receives message 3, it selects a set of cryptographic 320 algorithms from the ones that are proposed in the message. In this 321 overview, it is assumed that an acceptable such set exists (and is 322 thus selected), and that the Diffie-Hellman value KEi belongs to an 323 acceptable group. The peer then generates a non-zero Responder SPI 324 value for this protocol run, its own Diffie-Hellman value (KEr) and 325 nonce (Nr), and calculates the keys SKEYSEED, SK_d, SK_ai, SK_ar, 326 SK_ei, SK_er, SK_pi, and SK_pr according to Section 2.14 of [1]. The 327 peer then constructs message 4. In the context of use cases 1, 2 and 328 3, the peer's local policy MAY dictate the inclusion of the optional 329 CERTREQ payload in that message, which gives a hint to the server to 330 include a certificate for its public key in its next message. In the 331 context of use case 4, the peer MUST include the optional SK{IDr} 332 payload, which contains its EAP-IKEv2 identifier, encrypted and 333 integrity-protected within an Encrypted payload. The keys used to 334 construct this Encrypted payload are SK_er (for encryption) and SK_ar 335 (for integrity protection), in accordance with [1]. The responder's 336 EAP-IKEv2 identifier (IDr) is likely to be needed in these use cases 337 by the server in order to select the correct symmetric key or 338 password for the construction of the AUTH payload of message 5. 340 Upon reception of message 4, the server also computes SKEYSEED, SK_d, 341 SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr according to Section 342 2.14 of [1]. If an SK{IDr} payload is included, the server decrypts 343 it and verifies its integrity with the corresponding keys. In this 344 overview, decryption and verification is assumed to succeed. The 345 server then constructs message 5 which contains only the EAP-IKEv2 346 header followed by a single Encrypted payload. The keys used to 347 generate the encrypted payload MUST be SK_ei (for encryption) and 348 SK_ai (for integrity protection), in accordance with [1]. The 349 initiator MUST embed at least two payloads in the Encrypted Payload, 350 as follows. An Identification payload with the initiator's EAP-IKEv2 351 identifer MUST be embedded in the Encrypted payload. The 352 Authentication payload MUST be embedded in the Encrypted payload. A 353 Certificate payload, and/or a Certificate Request payload MAY also be 354 embedded in the Encrypted payload. Moreover, a Next Fast-Reconnect 355 Identifier payload MAY also be embedded in the Encrypted payload. 356 Message 5 is sent to the responder. 358 Upon reception of message 5, the responder (EAP peer) authenticates 359 the initiator (EAP server). The checks that are performed to this 360 end depend on the use case, local policies, and are specified in [1]. 361 These checks include (but may not be limited to) decrypting the 362 Encrypted payload, verifying its integrity, and checking that the 363 Authentication payload contains the expected value. If all checks 364 succeed (which is assumed in this overview), then the responder 365 constructs message 6. That message MUST contain the EAP-IKEv2 header 366 followed by a single Encrypted payload, in which at least two further 367 payloads MUST be embedded, as shown in Figure 1. 369 Upon reception of message 6, the initiator (EAP server) authenticates 370 the responder (EAP peer). As above, the checks that are performed to 371 this end depend on the use case, local policies, and MUST include 372 decryption and verification of the Encrypted payload, as well as 373 checking that the Authentication payload contains the expected value. 374 If the optional SK{IDr} payload was included in message 4, the EAP 375 server MUST also ensure that the IDr payload in message 6 is 376 identical to that in message 4. 378 If authentication succeeds, an EAP-Success message is sent to the 379 responder as message 7. The EAP server and the EAP peer generate a 380 Master Session Key (MSK) and an Extended Master Session Key (EMSK) 381 after a successful EAP-IKEv2 protocol run, according to Section 5. 383 4. Fast Reconnect 385 This section specifies a "fast reconnect" mode of operation for EAP- 386 IKEv2. This mode is mandatory to implement, but optional to use. 387 The purpose of fast reconnect is to enable an efficient re- 388 authentication procedure that also results in a fresh MSK and EMSK. 389 The "fast reconnect" mode can only be used where an EAP-IKEv2 390 security context already exists at both the server and the peer, and 391 its usage is subject to the local policies. In other words, it can 392 only be used by an EAP server/EAP peer pair that has already 393 performed mutual authentication in a previous EAP-IKEv2 protocol run. 395 The fast reconnect mode makes use of dedicated "fast reconnect EAP 396 identifiers". The idea is that the server indicates its willingness 397 to engage in "fast reconnect" protocol runs in the future by 398 including the optional "Next Fast-ID" (NFID) payload in message 5 of 399 a "full" protocol run (see Figure 1), or in message 3 of a "fast 400 reconnect" protocol run (see Figure 2). This NFID payload contains a 401 special EAP identity, denoted Fast Reconnect Identity (FRID) as the 402 NAI in the EAP-Response/Identity message. The FRID contains an 403 obfuscated username part and a realm part. When generating a FRID 404 the following aspects should be considered: 406 The FRID and therefore the pseudonym usernames are generated by 407 the EAP server. The EAP server produces pseudonym usernames in an 408 implementation-dependent manner. Only the EAP server needs to be 409 able to map the pseudonym username to the permanent identity. 411 EAP-IKEv2 includes no provisions to ensure that the same EAP 412 server that generated a pseudonym username will be used on the 413 authentication exchange when the pseudonym username is used. It 414 is recommended that the EAP servers implement some centralized 415 mechanism to allow all EAP servers of the home operator to map 416 pseudonyms generated by other severs to the permanent identity. 417 If no such mechanism is available, then the EAP server, failing to 418 understand a pseudonym issued by another server, can request the 419 peer to send the permanent identity. 421 When generating FRIDs, the server SHOULD choose a fresh and unique 422 FRID that is different from the previous ones that were used after 423 the same full authentication exchange. The FRID SHOULD include a 424 random component in the username part. The random component works 425 as a reference to the security context. Regardless of the 426 construction method, the pseudonym username MUST conform to the 427 grammar specified for the username portion of an NAI. Also, the 428 FRID MUST conform to the NAI grammar [4]. The EAP servers, which 429 subscribers of an operator can use, MUST ensure that the username 430 part of a FRIDs that they generate are unique. 432 The peer MAY use the FRID to indicate to start a "fast reconnect" 433 protocol run. The EAP Identity Response MUST be sent at the 434 beginning of a "fast reconnect" protocol run. If, in the previous 435 successful "full" EAP-IKEv2 protocol execution, the server had not 436 included an NFID payload in message 5 (resp. 3), then the peer MUST 437 NOT start a fast reconnect protocol run. On reception of FRID, the 438 server maps it to an existing EAP-IKEv2 security context. Depending 439 on local policy, the server either proceeds with the "fast reconnect" 440 protocol run, or proceeds with message 3 of a "full" protocol run. 441 If the server had advertised the FRID in the previous EAP-IKEv2 442 protocol execution, it SHOULD proceed with a "fast reconnect" 443 protocol run. The peer MUST be able to correctly handle a message 3 444 of a "full" protocol run, even if it indicated a FRID in its EAP 445 Identity Response. 447 Because the peer may fail to save a FRID that was sent in the NFID 448 payload (for example, due to malfunction), the EAP server SHOULD 449 maintain, at least, the most recently used FRID in addition to the 450 most recently issued FRID. If the authentication exchange is not 451 completed successfully, then the server MUST NOT overwrite the FRID 452 that was issued during the most recent successful authentication 453 exchange. 455 The EAP-IKEv2 fast reconnect exchange is similar to the IKE-SA 456 rekeying procedure as specified in Section 2.18 of [1]. Thus, it 457 uses a CREATE_CHILD_SA request and response. The SPIs on those two 458 messages would be the SPI's negotiated on the previous exchange. 459 During fast reconnect, the server and the peer MAY exchange fresh 460 Diffie-Hellman values. 462 1. R<-I: EAP-Request/Identity 464 2. R->I: EAP-Response/Identity(FRID) 466 3. R<-I: EAP-Req(HDR, SK{SA, Ni, [KEi], [NFID]}) 468 4. R->I: EAP-Res(HDR, SK{SA, Nr, [KEr]}) 470 5. R<-I: EAP-Success 472 Figure 2: Fast Reconnect Protocol Run 474 Figure 2 shows the message exchange for the EAP-IKEv2 fast reconnect 475 mode. As in the full mode, the EAP server is the initiator and the 476 EAP peer is the responder. The first two messages constitute the 477 standard EAP identity exchange. Note that, in order to use the "fast 478 reconnect" mode, message 2 MUST be sent. This is in order to enable 479 the peer to indicate its "fast reconnect" identity FRID in message 2. 480 If the server can map the FRID to an existing EAP-IKEv2 context it 481 proceeds with message 3. Note that, in this message, the server MAY 482 embed a NFID payload into the encrypted payload to provide a new FRID 483 to the peer. The server MAY choose to perform a full EAP-IKEv2 run, 484 in which case it would respond with a message that conforms to the 485 format of message 3 in Figure 1. 487 Messages 3 and 4 establish a new EAP-IKEv2 security context. In 488 message 3, the initiator MUST select a new (non-zero) value for the 489 SPI field in each proposal substructure in the SA payload (see 490 Section 3.3 of [1]). The value of the IKE_SA Responder's SPI field 491 in HDR MUST be the one from the previous successful EAP-IKEv2 492 protocol run. The nonce inside the Nonce payload (Ni) MUST be fresh, 493 and the Diffie-Hellman value inside the Diffie-Hellman payload (if 494 present, KEi) MUST also be fresh. If present, the Diffie-Hellman 495 value MUST be drawn from the same group as the Diffie-Hellman value 496 in the previous successful full EAP-IKEv2 protocol run. Note that 497 the algorithms and keys that are used to construct the Encrypted 498 payload in message 3, are the same as in the previous successful EAP- 499 IKEv2 protocol run. 501 Upon reception of message 3, the responder (EAP peer) decrypts and 502 verifies the Encrypted payload. If successful (as assumed in 503 Figure 2), it constructs message 4 in a fashion similar to the 504 construction of message 3. The responder MUST choose a new (non- 505 zero) value for the SPI field in each proposal substructure. Upon 506 reception of message 4, the initiator (EAP server) decrypts and 507 verifies the Encrypted payload. If a correct message 4 is received, 508 then this protocol run is deemed successful, and the server responds 509 with an EAP-Success message (message 5). 511 After successful EAP-IKEv2 fast reconnect protocol run, both the 512 initiator and the responder generate fresh keying material, that is 513 used for the protection of subsequent EAP-IKEv2 traffic. 514 Furthermore, both the initiator and the responder MUST generate a 515 fresh MSK and EMSK and export them. 517 The new EAP-IKEv2-specific keying material is computed in the same 518 way as in the full EAP-IKEv2 protocol run, and in accordance with 519 Section 2.18 of [1]. That is, SKEYSEED is computed as SKEYSEED = 520 prf(SK_d (old), [g^ir (new)] | Ni | Nr), where SK_d (old) is the key 521 SK_d from the previous successful EAP-IKEv2 protocol run, Ni and Nr 522 are the nonces (without the Nonce payload headers) that were 523 exchanged in messages 3 and 4, and g^ir (new) is the newly computed 524 Diffie-Hellman key, if both the values KEi and KEr were present in 525 messages 3 and 4. The remaining EAP-IKEv2-specific keys (SK_d, 526 SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr) are generated as in the 527 full EAP-IKEv2 protocol run. 529 The generation of a fresh MSK and EMSK follows the generation of the 530 EAP-IKEv2-specific keys and adheres to the rules in Section 5. 532 Note 1: In EAP-IKEv2, the EAP server initiates the fast reconnect 533 mode and thereby causes fresh session keys to be established. 535 Note 2: It is conceivable that an adversary tries to launch a replay 536 attack against the EAP-IKEv2 fast reconnect mode of operation. In 537 particular, the adversary may try to send a previously captured 538 message 3 in a subsequent fast reconnect protocol run. This replay 539 attempt will, however, fail because the keys that the responder will 540 use to verify and decrypt the Encrypted payload are changed with 541 every successful reconnect protocol run. 543 5. Key Derivation 545 This section describes how the Master Session Key (MSK) and the 546 Extended Master Session Key (EMSK) are derived in EAP-IKEv2. It is 547 expected that the MSK and the EMSK are exported by the EAP-IKEv2 548 process and be used in accordance with the EAP keying framework [7]. 550 During an EAP-IKEv2 protocol run, the initiator and the responder 551 generate a number of keys, as described above and in accordance with 552 Section 2.14 of [1]. The generation of these keys is based on a 553 pseudorandom function (prf) that both parties have agreed to use and 554 which is applied in an iterative fashion. This iterative fashion is 555 specified in Section 2.13 of [1] and is denoted by prf+. 557 In particular, following a successful EAP-IKEv2 protocol run, both 558 parties generate 128 octets of keying material, denoted KEYMAT, as 559 KEYMAT = prf+(SK_d, Ni | Nr), where Ni and Nr are the nonces (just 560 payload without headers) from messages 3 and 4 shown in Figure 1 (in 561 the context of a full EAP-IKEv2 protocol run) or Figure 2 (in the 562 context of a fast reconnect EAP-IKEv2 protocol run). Note that only 563 the nonces are used, i.e., not the entire Nonce payload that contains 564 them. 566 The first 64 octets of KEYMAT are exported as the EAP MSK, and the 567 second 64 octets are exported as the EMSK. 569 The MSK and EMSK MUST NOT be generated unless an EAP-IKEv2 protocol 570 run completes successfully. Note that the EAP-IKEv2 method does not 571 produce an initialisation vector [7]. 573 6. Session ID, Peer ID, and Server ID 575 The EAP key management framework [7] requires that EAP methods export 576 three information elements, called the Session-ID, the Peer-ID, and 577 the Server-ID. In EAP-IKEv2 these elements are derived as follows. 579 o The Session-ID is constructed and exported as the concatenation of 580 the following three elements, in this order: (a) the EAP Code Type 581 for EAP-IKEv2 (to be defined by IANA), (b) the contents of the 582 Nonce Data field of the Nonce Payload Ni from message 3, (c) the 583 contents of the Nonce Data field of the Nonce Payload Nr from 584 message 4. 586 o In case of a full EAP-IKEv2 protocol run, the Peer-ID is 587 constructed and exported as the content of the Identification Data 588 field of the Identification Payload IDr from message 6. Note that 589 only the "actual" identification data is exported, as indicated in 590 the Payload Length field; if the Identification Data field 591 contains any padding, this padding is ignored. In case of a "fast 592 reconnect" protocol run, the Peer-ID field is constructed in 593 exactly the same manner, where message 6 refers to the full EAP- 594 IKEv2 protocol run that originally established the security 595 context between the EAP peer and EAP server. 597 o In case of a full EAP-IKEv2 protocol run, the Server-ID is 598 constructed and exported as the contents of the Identification 599 Data field of the Identification Payload IDi from message 5. Note 600 that only the "actual" identification data is exported, as 601 indicated in the Payload Length field; if the Identification Data 602 field contains any padding, this padding is ignored. In case of a 603 "fast reconnect" protocol run, the Server-ID field is constructed 604 in exactly the same manner, where message 5 refers to the full 605 EAP-IKEv2 protocol run that originally established the security 606 context between the EAP peer and EAP server. 608 7. Error Handling 610 This section specifies how errors are handled within EAP-IKEv2. For 611 conveying error information from one party to the other, the Notify 612 payload is defined and used (see Section 8.11). 614 If, in a full EAP-IKEv2 protocol run, authentication fails (i.e., the 615 verification of the AUTH field fails at the server or the peer), but 616 no other errors have occurred, the message flow deviates from that 617 described in Section 3. The message flows in the presence of 618 authentication failures are specified in Appendix A. 620 If, in message 3 of a full EAP-IKEv2 protocol run (see Figure 1), the 621 responder receives a Diffie-Hellman value (KEi) that belongs to a 622 group that is not supported (and in the absence of other errors), 623 then the responder MUST send a message of the form shown in Figure 3 624 to the initiator. This effectively becomes message 4 in the full 625 protocol run. 627 1. R<-I: EAP-Request/Identity 629 2. R->I: EAP-Response/Identity(Id) 631 3. R<-I: EAP-Req (HDR, SAi, KEi, Ni) 633 4. R->I: EAP-Res (HDR, N(INVALID_KE_PAYLOAD)) 635 Figure 3: Error handling in case of unsupported D-H value 637 The above message consists of the EAP-IKEv2 header and a Notification 638 payload with the value of the Notify Message Type field value set to 639 17 (INVALID_KE_PAYLOAD). There are two octets of data associated 640 with this notification: the number of the selected DH Group in big 641 endian order, as specified in Section 3.10.1 of [1]. This number 642 MUST represent a DH group that is supported by both the initiator and 643 the responder. 645 If, during a full EAP-IKEv2 protocol run (see Figure 1), the 646 initiator receives a message conforming to Figure 3 instead of the 647 usual message 4, then it MUST check whether or not the indicated DH 648 group was proposed in message 3. If it was not, then the initiator 649 MUST silently discard the message. Otherwise, the protocol continues 650 with a new message 3 that the initiator sends to the peer. In this 651 new message 3 the initiator MUST use a Diffie-Hellman value that is 652 drawn from the group that is indicated in the Notify payload of 653 message 4 in Figure 3. 655 If, in the context of use case 4 and during a full EAP-IKEv2 protocol 656 run (see Figure 1), the initiator receives, in message 4, an SK{IDr} 657 payload that decrypts to a non-existent or unauthorised EAP-IKEv2 658 responder identifier IDr*, then the server SHOULD continue the 659 protocol with a message conforming to the format of message 5. The 660 AUTH payload in that message SHOULD contain a value that is 661 computationally indistinguishable from a value that it would contain 662 if IDr* was valid and authorised. This can be accomplished, for 663 example, by generating a random key and calculate AUTH as usual 664 (however, this document does not mandate a specific mechanism). Only 665 after receiving message 6, the server SHOULD respond with an 666 authentication failure notification, i.e., a message conforming to 667 message 6 in Figure 10. The purpose of this behaviour is to prevent 668 an adversary from probing the EAP-IKEv2 peer identifier space. 670 If, in the context of use cases 1, 2, or 3 and during a full EAP- 671 IKEv2 protocol run (see Figure 1), the initiator receives, in message 672 4, an SK{IDr} payload that decrypts to an EAP-IKEv2 responder 673 identifier IDr*, then the server MUST continue the protocol as usual 674 (note that such a payload would not be required in these use cases). 675 The server MUST compare IDr* with the IDr received in message 6 and, 676 in case of a mismatch, MUST respond with an authentication failure 677 notification, i.e., a message conforming to message 6 in Figure 10. 678 If no mismatch is detected, normal processing applies. 680 Other errors do not trigger messages with Notification payloads to be 681 sent, and MUST be treated as if nothing happened (i.e., the erroneous 682 EAP-IKEv2 packet MUST be silently discarded). This includes 683 situations where at least one of the following conditions is met, 684 with respect to an incoming EAP-IKEv2 packet. 686 o The packet contains an Encrypted payload that, when decrypted with 687 the appropriate key, yields an invalid decryption. 689 o The packet contains an Encrypted payload with a Checksum field 690 that does not verify with the appropriate key. 692 o The packet contains an Integrity Checksum Data field (see 693 Figure 4) that is incorrect. 695 o The packet does not contain a compulsory field. 697 o A field in the packet contains an invalid value (e.g., an invalid 698 combination of flags, a length field that is inconsistent with the 699 real length of the field or packet, or the responder's choice of a 700 cryptographic algorithm is different to NONE and any of those that 701 were offered by the initiator). 703 o The packet contains an invalid combination of fields (e.g., it 704 contains two or more Notify payloads with the same Notify Message 705 Type value, or two or more Transform substructures with the same 706 Transform Type and Transform ID value). 708 o The packet causes a defragmentation error. 710 o The format of the packet is invalid. 712 o The identity provided by the EAP peer in the EAP-Response/Identity 713 cannot be associated with either an established security context 714 (in case of a fast reconnect) or with a real user account (in case 715 of a full protocol exchange) then the packet is silently 716 discarded. With an outstanding message from the EAP server the 717 client may either retransmit the previous request or, in case of a 718 fast reconnect, assume that state information was deleted (e.g., 719 due to garbage collection) at the EAP server and to fall back to a 720 previously used FRID or to the full protocol exchange. 722 If an incoming packet contains an error for which behaviour is 723 specified in this section, and an error that, in the absence of the 724 former error, would cause the packet to be silently discarded, then 725 the packet MUST be silently discarded. 727 8. Specification of Protocol Fields 729 In this section, the format of the EAP-IKEv2 data fields and 730 applicable processing rules are specified. Figure 4 shows the 731 general packet format of EAP-IKEv2 messages, and the embedding of 732 EAP-IKEv2 into EAP. The EAP-IKEv2 messages are embedded in the Data 733 field of the standard EAP Request/Response packets. The Code, 734 Identifier, Length and Type fields are described in [2]. The EAP 735 Type for this EAP method is TBD by IANA. 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Code | Identifier | Length | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Type | Flags | Message Length | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Message Length | HDR + payloads ~ 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Integrity Checksum Data | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 Figure 4: General packet format of EAP-IKEv2 751 The Flags field is always present and is used for fragmentation 752 support, as described in Section 8.1. The Message Length field is 753 not always present; it's presence is determined by a certain flag in 754 the Flags field, as described in Section 8.1. The field denoted as 755 "HDR + payloads" in Figure 4 contains the EAP-IKEv2 header (see 756 Section 8.2), followed by a number of payloads, in accordance with 757 the composition of EAP-IKEv2 messages, as described in the previous 758 sections. Note that each payload begins with a generic payload 759 header that is specified in Section 3.2 of [1]. 761 The Integrity Checksum Data field is not always present; its presence 762 is determined by a certain flag in the Flags field, as described in 763 Section 8.1. 765 In the remainder of this section, the protocol fields that are used 766 in EAP-IKEv2 are specified. This specification heavily relies on the 767 IKEv2 specification [1], and many fields are constructed, formatted 768 and processed in way that is almost identical to that in IKEv2. 769 However, certain deviations from standard IKEv2 formatting and 770 processing exist. These deviations are highlighted in the remainder 771 of this section. 773 8.1. The Flags, Message Length, and Integrity Checksum Data fields 775 This section describes EAP-IKEv2 fragmentation, and specifies the 776 encoding and processing rules for the Flags, Message Length, and 777 Integrity Checksum Data field shown in Figure 4. 779 Fragmentation support in EAP-IKEv2 is provided by the Flags and 780 Message Length fields shown in Figure 4. These are encoded and used 781 as follows. 783 0 1 2 3 4 5 6 7 784 +-+-+-+-+-+-+-+-+ 785 |L M I 0 0 0 0 0| 786 +-+-+-+-+-+-+-+-+ 788 L = Length included 789 M = More fragments 790 I = Integrity Checksum Data included 792 Figure 5: Flags field 794 The Flags field is defined in Figure 5. Only the first three bits 795 (0-2) are used; all remaining bits MUST be set to zero and and 796 ignored on receipt. The L flag indicates the presence of a Message 797 Length field, and the M flag indicates whether or not the current EAP 798 message has more fragments. In particular, if the L bit is set, then 799 a Message Length field MUST be present in the EAP message, as shown 800 in Figure 4. The Message Length field is four octets long and 801 contains the length of the entire message (i.e., the length of the 802 EAP Data field.). Note that, in contrast, the Length field shown in 803 Figure 4 contains the length of only the current fragment. (Note 804 that there exist two fields that are related to length: the Length 805 field, which is a generic EAP field, and the Message Length field, 806 which is an EAP-IKEv2-specific field.) If the L bit is not set, then 807 the Message Length field MUST NOT be present. 809 The M flag MUST be set on all fragments except the last one. In the 810 last fragment, the M flag MUST NOT be set. Reliable fragment 811 delivery is provided by the retransmission mechanism of EAP. 813 The Integrity Checksum Data field contains a cryptographic checksum 814 that covers the entire EAP message, starting with the Code field, and 815 ending at the end of the EAP Data field. This field, shown in 816 Figure 4, is present only if the I bit is set in the Flags field. 817 The Integrity Checksum Data field immediately follows the EAP Data 818 field without padding. 820 Whenever possible, the Integrity Checksum Data field MUST be present 821 (and the I bit set) for each fragment, including the case where the 822 entire EAP-IKEv2 message is carried in a single fragment. The 823 algorithm and keys that are used to compute the Integrity Checksum 824 Data field MUST be identical to those used to compute the Integrity 825 Checksum Data field of the Encrypted Payload (see Section 8.9). That 826 is, the algorithm and keys that were negotiated and established 827 during this EAP-IKEv2 protocol run are used. Note that this means 828 that different keys are used to compute the Integrity Checksum Data 829 field in each direction. Also note that, for messages where this 830 algorithm and the keys are not yet established, the Integrity 831 Checksum Data field cannot be computed and is therefore not included. 832 This applies, for example, to messages 3 and 4 in Figure 1. 834 In order to minimize the exposure to denial-of-service attacks on 835 fragmented packets, messages that are not protected with an Integrity 836 Checksum Data field SHOULD NOT be fragmented. Note, however, that 837 those packets are not likely to be fragmented anyway since they do 838 not carry certificates. 840 8.2. EAP-IKEv2 header 842 The EAP-IKEv2 header, denoted HDR in this specification, is 843 constructed and formatted according to the rules specified in Section 844 3.1 of [1]. 846 In the first EAP-IKEv2 message that is sent by the initiator (message 847 3 in Figure 1), the IKE_SA Responder's SPI field is set to zero. 848 This is because, at this point in time, the initiator does not know 849 what SPI value the responder will choose for this protocol run. In 850 all other messages, both SPI fields MUST contain non-zero values that 851 reflect the initiator and responder-chosen SPI values. 853 In accordance with [1], for this version of EAP-IKEv2, the MjVer 854 (major version) and MnVer (minor version) fields in the header MUST 855 be 2 and 0 respectively. The value of the Exchange Type field MUST 856 be set to 34 (IKE_SA_INIT) in messages 3 and 4, and to 35 857 (IKE_SA_AUTH) in messages 5 and 6 in Figure 1. In messages 3 and 4 858 in Figure 2 this value MUST be set to 36 (CREATE_CHILD_SA). 860 The Flags field of the EAP-IKEv2 header is also constructed according 861 to Section 3.1 of [1]. Note that this is not the same field as the 862 Flags field shown in Figure 4. 864 The Message ID field is constructed as follows. Messages 3 and 4 in 865 a full protocol run MUST carry Message ID value 0. Messages 5 and 6 866 in a full protocol run (see Figure 1) MUST carry Message ID value 1. 867 Messages 3 and 4 in a fast reconnect protocol run MUST carry Message 868 ID value 2. 870 8.3. Security Association Payload 872 The SA payload is used for the negotiation of cryptographic 873 algorithms between the initiator and the responder. The rules for 874 its construction adhere to [1], in particular sections 2.7 and 3.3. 876 In EAP-IKEv2, all Proposal Substructures in the SA payload MUST carry 877 Protocol ID value 1 (IKE). 879 8.4. Key Exchange Payload 881 The Key Exchange payload, denoted KEi if constructed by the initiator 882 and KEr if constructed by the responder, is formatted according to 883 the rules specified in Section 3.4 of [1]. 885 8.5. Nonce Payload 887 The Nonce payload, denoted Ni if constructed by the initiator and Nr 888 if constructed by the responder, is constructed and formatted 889 according to the rules specified in Section 3.9 of [1]. 891 8.6. Identification Payload 893 The Identification payload, denoted IDi if it contains an identifier 894 for the initiator and IDr if it contains an identifier for the 895 responder, is constructed and formatted according to the rules 896 specified in Section 3.5 of [1]. 898 8.7. Certificate Payload 900 The Certificate payload, denoted CERT, is constructed and formatted 901 according to the rules specified in Section 3.6 of [1]. Note that 902 certain certificate encodings for the EAP server certificate, e.g., 903 those that need to be resolved via another network protocol, cannot 904 be used in some typical EAP-IKEv2 deployment scenarios. A user, for 905 example, that authenticates himself by means of EAP-IKEv2 in order to 906 obtain network access, cannot resolve the server certificate at the 907 time of EAP-IKEv2 protocol execution. 909 8.8. Certificate Request Payload 911 The Certificate payload, denoted CERTREQ, is constructed and 912 formatted according to the rules specified in Section 3.7 of [1]. 914 8.9. Encrypted Payload 916 The Encrypted payload, denoted SK{...}, is constructed and formatted 917 according to the rules specified in Section 3.14 of [1]. 919 8.10. Authentication Payload 921 The Authentication payload, denoted AUTH, is constructed and 922 formatted according to the rules specified in Section 2.15 and 923 Section 3.8 of [1]. 925 The contents of the Authentication payload depend on which party 926 generates this field, the use case, and the algorithm that 927 corresponds to the credential (asymmetric key, symmetric key, or 928 password) that this party uses to authenticate itself. The 929 Authentication payload contains either a MAC or a signature. 931 If the party that generates the Authentication payload authenticates 932 itself based on a shared secret (i.e., a password or a symmetric 933 key), then the Authentication payload MUST contain a MAC. This MAC 934 is calculated using a key that is derived from the shared secret, 935 according to Section 2.15 of [1]. According to that section, the 936 shared secret is padded with the string "Key Pad for IKEv2" as part 937 of this key derivation. For the EAP-IKEv2 method, this rule is 938 overridden, in that the padding string is redefined as "Key Pad for 939 EAP-IKEv2". The latter padding string MUST be used for the 940 derivation of the MAC key from a shared secret in the context of EAP- 941 IKEv2. This is done in order to avoid the same MAC key to be used 942 for both IKEv2 and EAP-IKEv2 in scenarios where the same shared 943 secret is used for both. Note that using a shared secret (e.g., a 944 password) in the context EAP-IKEv2 that is identical or similar to a 945 shared secret that is used in another context (including IKEv2) is 946 nevertheless NOT RECOMMENDED. 948 8.11. Notify Payload 950 The Notify payload, denoted N(...), is constructed and formatted 951 according to the rules specified in Section 3.10 of [1]. The 952 Protocol ID field of this payload MUST be set to 1 (IKE_SA). 954 8.12. Next Fast-ID Payload 956 The Next Fast-ID Payload is defined as follows. 958 1 2 3 959 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 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 ! Next Payload !C! RESERVED ! Payload Length ! 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 ! ! 964 ~ Fast-Reconnect-ID (FRID) ~ 965 ! ! 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 Figure 6: NFID payload format 970 The Next Fast-ID payload, denoted NFID, does not have an equivalent 971 in IKEv2. Nevertheless, the Next Payload, C, RESERVED, and Payload 972 Length fields of this payload are constructed according to Section 973 3.2 of [1]. The payload ID is registered in Section 11. The Fast- 974 Reconnect-ID field contains a fast reconnect identifer that the peer 975 can use in the next fast reconnect protocol run, as described in 976 Section 4. In environments where a realm portion is required, Fast- 977 Reconnect-ID includes both a username portion and a realm name 978 portion. The Fast-Reconnect-ID MUST NOT include any terminating null 979 characters. The encoding of the Fast-Reconnect-ID field MUST follow 980 the NAI format [4]. 982 9. Payload Types and Extensibility 984 In EAP-IKEv2, each payload is identified by means of a type field 985 which, as specified in [1], is indicated in the "Next Payload" field 986 of the preceding payload. However, the identifer space from which 987 EAP-IKEv2 payload types are drawn is independent from the payload 988 type space of IKEv2. This is because EAP-IKEv2 and IKEv2 may evolve 989 in a different way and, as such, payload types that appear in one 990 protocol do not necessary appear in the other. An example of this is 991 the "Next Fast-ID" (NFID) payload which does not exist in IKEv2. 993 The values for the payload types defined in this document are listed 994 in Section 11. Payload type values 13-127 are reserved to IANA for 995 future assignment in EAP-IKEv2. Payload type values 128-255 are for 996 private use among mutually consenting parties. 998 10. Security Considerations 1000 As mentioned in Section 3, in EAP-IKEv2, the EAP server always 1001 assumes the role of the initiator (I), and the EAP peer takes on the 1002 role of the responder (R) of an exchange. This is in order to ensure 1003 that, in scenarios where the peer authenticates itself based on a 1004 password (i.e., in use case 3), operations that involve this password 1005 only take place after the server has been successfully authenticated. 1006 In other words, this assignment of initiator and responder roles 1007 results in protection against offline dictionary attacks on the 1008 password that is used by the peer to authenticate itself (see 1009 Section 10.7). 1011 In order for two EAP-IKEv2 implementations to be interoperable, they 1012 must support at least one common set of cryptographic algorithms. In 1013 order to promote interoperability, EAP-IKEv2 implementations MUST 1014 support the following algorithms based on the "MUST/MUST-" 1015 recommendations given in [5]: 1017 Diffie-Hellman Groups: 1024 MODP Group 1018 IKEv2 Transform Type 1 Algorithms: ENCR_3DES 1019 IKEv2 Transform Type 2 Algorithms: PRF_HMAC_SHA1 1020 IKEv2 Transform Type 3 Algorithms: AUTH_HMAC_SHA1_96 1022 All other options of [5] MAY be implemented. 1024 The remainder of this section describes EAP-IKEv2 in terms of 1025 specific security terminology as required by [2]. The discussion 1026 makes reference to the use cases defined in Section 1. 1028 10.1. Protected Ciphersuite Negotiation 1030 In message 3, the EAP server provides the set of ciphersuites it is 1031 willing to accept in an EAP-IKEv2 protocol run. Hence, the server is 1032 in control of the ciphersuite. An EAP peer that does not support any 1033 of the indicated ciphersuites is not able to authenticate. The local 1034 security policy of the peer MUST specify the set of ciphersuites that 1035 the peer accepts. The server MUST verify that the ciphersuite that 1036 is indicated as being chosen by the peer in message 4, belongs to the 1037 set of ciphersuites that were offered in message 3. If this 1038 verification fails, the server MUST silently discard the packet. 1040 10.2. Mutual Authentication 1042 EAP-IKEv2 supports mutual authentication. 1044 10.3. Integrity Protection 1046 EAP-IKEv2 provides integrity protection of EAP-IKEv2 traffic. This 1047 protection is offered after authentication is completed and is 1048 facilitated by inclusion of two Integrity Checksum Data fields: one 1049 at the end of the EAP packet (see Figure 4), and one as part of an 1050 Encrypted payload (see Section 8.9). 1052 10.4. Replay Protection 1054 EAP-IKEv2 provides protection against replay attacks by a variety of 1055 means. This includes the requirement that the Authentication payload 1056 is computed as a function of, among other things, a server-provided 1057 nonce and a peer-provided nonce. These nonces are required to be 1058 practically unpredictable by an adversary. Assuming that the 1059 algorithm that is used to compute the Authentication payload does not 1060 contain cryptographic weaknesses, the probability that an 1061 Authentication payload that is valid in a particular protocol run, 1062 will also be valid in a subsequent run, is therefore negligible. 1064 10.5. Confidentiality 1066 EAP-IKEv2 provides confidentiality of certain EAP-IKEv2 fields, 1067 namely those included in Encrypted payloads. With respect to 1068 identity confidentiality, the following claims are made. Note that 1069 identity confidentiality refers to the EAP-IKEv2 identity of the EAP 1070 peer. 1072 Identity confidentiality is provided in the face of a passive 1073 adversary, i.e., an adversary that does not modify traffic as it is 1074 in transit. Whenever the optional SK{IDr} payload in message 4 of a 1075 full EAP-IKEv2 protocol (see Figure 1) is not included, identity 1076 confidentiality is also provided in the face of an active adversary. 1077 This payload MUST NOT be included in use cases 1, 2, and 3. In use 1078 case 4 this payload MUST be included. Therefore, in use case 4, EAP- 1079 IKEv2 does not provide identity confidentiality in the face of an 1080 active adversary. 1082 Note, however, that the EAP peer provides it's identity in message 2 1083 in Figure 1 in cleartext. In order to provide identity 1084 confidentiality as discussed in the previous paragraphs it is 1085 necessary to obfuscated the username part of the identity (the realm 1086 part must stay intact to allow correct message routing by the AAA 1087 infrastructure). The EAP server then uses the identity information 1088 in message 4. The same mechanism is also used by other EAP methods 1089 to provide identity confidentiality, for example EAP-TTLS [8]. 1091 10.6. Key Strength 1093 EAP-IKEv2 supports the establishment of session keys (MSK and EMSK) 1094 of a variety of key strengths, with the theoretical maximum at 512 1095 bits per key (since this is the size of the MSK and the EMSK). 1096 However, in practice the effective key strength is likely to be 1097 significantly lower, and depends on the authentication credentials 1098 used, the negotiated ciphersuite (including the output size of the 1099 pseudorandom function), the Diffie-Hellman group used, and on the 1100 extent to which the assumptions on which the underlying cryptographic 1101 algorithms depend really hold. Of the above mechanisms, the one that 1102 offers the lowest key strength can be regarded as a measure of the 1103 effective key strength of the resulting session keys. Note that this 1104 holds for other EAP methods, too. 1106 Due to the large variety of possible combinations, no indication of a 1107 practical effective key strength for MSK or EMSK is given here. 1108 However, those responsible for the deployment of EAP-IKEv2 in a 1109 particular environment should consider the threats this environment 1110 may be exposed to, and configure the EAP-IKEv2 server and peer 1111 policies and authentication credentials such that the established 1112 session keys are of a sufficiently high effective key strength. 1114 10.7. Dictionary Attack Resistance 1116 EAP-IKEv2 can be used in a variety of use cases, as explained in 1117 Section 1. In some of these uses cases, namely use case 1, 2, and 4, 1118 dictionary attacks cannot be launched since no passwords are used. 1119 In use case 3, EAP-IKEv2 provides protection against offline 1120 dictionary attacks, since operations that involve the password are 1121 executed only after the server has authenticated itself (based on a 1122 credential other than a password). 1124 In order to reduce exposure against online dictionary attacks, in use 1125 case 3, the server SHOULD provide the capability to log failed peer 1126 authentication events, and SHOULD implement a suitable policy in case 1127 of consecutive failed peer authentication attempts within a short 1128 period of time (such as responding with an EAP-Failure instead of 1129 message 5 for a predetermined amount of time). 1131 When passwords are used with method 4 (instead of using an key with 1132 high entropy) then dictionary attacks are possible, as described in 1133 Section 8 of [1]: 1135 " When using pre-shared keys, a critical consideration is how to 1136 assure the randomness of these secrets. The strongest practice is 1137 to ensure that any pre-shared key contain as much randomness as 1138 the strongest key being negotiated. Deriving a shared secret from 1139 a password, name, or other low-entropy source is not secure. 1140 These sources are subject to dictionary and social engineering 1141 attacks, among others. " 1143 Hence, the usage of passwords with mode 4 where the EAP peer and the 1144 EAP server rely on a shared secret that was derived from a password 1145 is insecure. It is strongly recommended to use mode 3 when passwords 1146 are used by the EAP peer. 1148 10.8. Fast Reconnect 1150 EAP-IKEv2 supports a "fast reconnect" mode of operation, as described 1151 in Section 4. 1153 10.9. Cryptographic Binding 1155 EAP-IKEv2 is not a tunnel EAP method. Thus, cryptographic binding 1156 does not apply to EAP-IKEv2. 1158 10.10. Session Independence 1160 EAP-IKEv2 provides session independence in a number of ways, as 1161 follows. Firstly, knowledge of captured EAP-IKEv2 conversations 1162 (i.e., the information that a passive adversary may obtain) does not 1163 enable the adversary to compute the Master Session Key (MSK) and 1164 Extended Master Session Key (EMSK) that resulted from these 1165 conversations. This holds even in the case where the adversary later 1166 obtains access to the server and/or the peer's long-term 1167 authentication credentials that were used in these conversations. 1168 That is, EAP-IKEv2 provides support for "perfect forward secrecy". 1169 However, whether or not this support is made use of in a particular 1170 EAP-IKEv2 protocol run, depends on when the peer and the server 1171 delete the Diffie-Hellman values that they used in that run, and on 1172 whether or not they use fresh Diffie-Hellman values in each protocol 1173 run. The discussion in Section 2.12 of [1] applies. 1175 Secondly, an active adversary that does not know the peer's and the 1176 server's long-term authentication credentials cannot learn the MSK 1177 and EMSK that were established in a particular protocol run of EAP- 1178 IKEv2, even if it obtains access to the MSK and EMSK that were 1179 established in other protocol runs of EAP-IKEv2. This is because the 1180 MSK and the EMSK are a function of, among other things, data items 1181 that are assumed to be generated independently at random in each 1182 protocol run. 1184 10.11. Fragmentation 1186 EAP-IKEv2 provides support for fragmentation, as described in 1187 Section 8.1. 1189 10.12. Channel Binding 1191 Channel binding is not supported in EAP-IKEv2. 1193 10.13. Summary 1195 EAP security claims are defined in Section 7.2.1 of [2]. The 1196 security claims for EAP-IKEv2 are as follows: 1198 Ciphersuite negotiation: Yes 1199 Mutual authentication: Yes 1200 Integrity protection: Yes 1201 Replay protection: Yes 1202 Confidentiality: Yes 1203 Key derivation: Yes; see Section 5 1204 Key strength: Variable 1205 Dictionary attack prot.: Yes; see Section 10.7 1206 Fast reconnect: Yes; see Section 4 1207 Crypt. binding: N/A 1208 Session independence: Yes; see Section 10.10 1209 Fragmentation: Yes; see Section 10.11 1210 Channel binding: No 1212 11. IANA Considerations 1214 IANA should allocate a value for the EAP method type indicating EAP- 1215 IKEv2. 1217 In addition, IANA is requested to create a new registry for EAP-IKEv2 1218 payloads, and populate it with the following initial entries listed 1219 below. 1221 The following payload type values are used by this document. 1223 Next Payload Type | Value 1224 -----------------------------------+---------------------------------- 1225 No Next payload | TBD by IANA (suggested value: 0) 1226 Security Association payload | TBD by IANA (suggested value: 1) 1227 Key Exchange payload | TBD by IANA (suggested value: 2) 1228 Identification payload | 1229 (when sent by initiator, IDi) | TBD by IANA (suggested value: 3) 1230 Identification payload | 1231 (when sent by responder, IDr) | TBD by IANA (suggested value: 4) 1232 Certificate payload | TBD by IANA (suggested value: 5) 1233 Certificate Request payload | TBD by IANA (suggested value: 6) 1234 Authentication payload | TBD by IANA (suggested value: 7) 1235 Nonce payload | TBD by IANA (suggested value: 8) 1236 Notification payload | TBD by IANA (suggested value: 9) 1237 Vendor ID payload | TBD by IANA (suggested value: 10) 1238 Encrypted payload | TBD by IANA (suggested value: 11) 1239 Next Fast-ID payload | TBD by IANA (suggested value: 12) 1240 RESERVED TO IANA | 13-127 1241 PRIVATE USE | 128-255 1243 Payload type values 13-127 are reserved to IANA for future assignment 1244 in EAP-IKEv2. Payload type values 128-255 are for private use among 1245 mutually consenting parties. 1247 The semantic of the above-listed payloads is provided in this 1248 document and refer to IKEv2 when necessary. 1250 Following the policies outline in [9] new payload type values with a 1251 description of their semantic will be assigned after Expert Review 1252 initiated by the Security Area Directors in consultation with the EMU 1253 working group chairs or the working group chairs of a designated 1254 successor working group. Updates can be provided based on expert 1255 approval only. A designated expert will be appointed by the Security 1256 Area Directors. Based on expert approval it is possible to delete 1257 entries from the registry or to mark entries as "deprecated". 1259 Each registration must include the payload type value and the 1260 semantic of the payload. 1262 12. Contributors 1264 The authors are grateful to Krzysztof Rzecki, Rafal Mijal, Piotr 1265 Marnik, and Pawel Matejski, who, during their implementation of EAP- 1266 IKEv2 (see http://eap-ikev2.sourceforge.net/), provided invaluable 1267 feedback and identified a number of errors in previous versions of 1268 this draft. 1270 13. Acknowledgements 1272 The authors also thank Pasi Eronen for his invaluable comments as 1273 expert reviewer assigned by the EAP working group chairs Jari Arkko 1274 and Bernard Aboba. The authors would also like to thank Guenther 1275 Horn, Thomas Otto, Paulo Pagliusi and John Vollbrecht for their 1276 insightful comments and suggestions. The members of the PANA design 1277 team, in particular D. Forsberg and A. Yegin, also provided comments 1278 on the initial version of this draft. We would like to thank Hugo 1279 Krawczyk for his feedback regarding the usage of the password based 1280 authentication. 1282 The authors are grateful to the members of the EAP keying design team 1283 for their discussion in the area of the EAP Key Management Framework. 1285 We would like to thank Jari Arkko for his support and for his 1286 comments. Finally, we would like to thank Charlie Kaufman, Bernard 1287 Aboba, and Paul Hoffman for their comments during IETF Last Call. 1289 14. References 1291 14.1. Normative References 1293 [1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 1294 December 2005. 1296 [2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1297 Levkowetz, "Extensible Authentication Protocol (EAP) (RFC 1298 3748)", Request For Comments 3748, June 2004. 1300 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1301 Levels", RFC 2119, March 1997. 1303 [4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 1304 Access Identifier", RFC 4282, December 2005. 1306 [5] Schiller, J., "Cryptographic Algorithms for Use in the Internet 1307 Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005. 1309 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1310 RFC 3629. 1312 14.2. Informative References 1314 [7] Aboba, B., "Extensible Authentication Protocol (EAP) Key 1315 Management Framework", draft-ietf-eap-keying-18 (work in 1316 progress), February 2007. 1318 [8] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication 1319 Protocol (EAP-TTLS)", draft-ietf-pppext-eap-ttls-05 (work in 1320 progress), July 2004. 1322 [9] Aboba, B., "IANA Considerations for RADIUS (Remote 1323 Authentication Dial In User Service)", RFC 3575, July 2003. 1325 Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication 1327 This appendix illustrates how authentication failures are handled 1328 within EAP-IKEv2. Note that authentication failures only occur in 1329 full EAP-IKEv2 protocol runs. 1331 Figure 10 shows the message flow in case the EAP peer fails to 1332 authenticate the EAP server. 1334 1. R<-I: EAP-Request/Identity 1336 2. R->I: EAP-Response/Identity(Id) 1338 3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni) 1340 4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}]) 1342 5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH}) 1344 6. R->I: EAP-Res(HDR, SK {N(AUTHENTICATION_FAILED)}) 1346 7. R<-I: EAP-Failure 1348 Figure 10: EAP-IKEv2 with failed server authentication 1350 The difference to the full successful exchange described in Section 3 1351 is that, in message 6, the EAP peer MUST answer the EAP server with 1352 an Encrypted payload that contains a Notify payload with the Notify 1353 Message Type value set to 24 (AUTHENTICATION_FAILED). In that 1354 message, the Message ID field in the EAP-IKEv2 header (HDR), MUST 1355 carry Message ID value 2. In message 7, an EAP-Failure message MUST 1356 be returned by the EAP server. 1358 Figure 11 shows the message flow in case the EAP server fails to 1359 authenticate the EAP peer. 1361 1. R<-I: EAP-Request/Identity 1363 2. R->I: EAP-Response/Identity(Id) 1365 3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni) 1367 4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}]) 1369 5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], AUTH}) 1371 6. R->I: EAP-Res (HDR, SK {IDr, [CERT], AUTH}) 1373 7. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)}) 1375 8. R->I: EAP-Res (HDR, SK {}) 1377 9. R<-I: EAP-Failure 1379 Figure 11: EAP-IKEv2 with failed peer authentication 1381 Compared to the full successful exchange, one additional roundtrip is 1382 required. In message 7 the EAP server MUST send an EAP request with 1383 Encrypted payload that contains a Notify payload with the Notify 1384 Message Type value set to 24 (AUTHENTICATION_FAILED), instead of 1385 sending an EAP-Success message. The EAP peer, upon receiving message 1386 7, MUST send an empty EAP-IKEv2 (informational) message in reply to 1387 the EAP server's error indication, as shown in message 8. In both 1388 message 7 and 8, the Message ID field in the EAP-IKEv2 header (HDR), 1389 MUST carry Message ID value 2. Finally, by means of message 9, the 1390 EAP server answers with an EAP-Failure. 1392 Authors' Addresses 1394 Hannes Tschofenig 1395 Nokia Siemens Networks 1396 Otto-Hahn-Ring 6 1397 Munich, Bavaria 81739 1398 Germany 1400 Email: Hannes.Tschofenig@nsn.com 1401 URI: http://www.tschofenig.com 1403 Dirk Kroeselberg 1404 Nokia Siemens Networks 1405 Otto-Hahn-Ring 6 1406 Munich, Bavaria 81739 1407 Germany 1409 Email: Dirk.Kroeselberg@nsn.com 1411 Andreas Pashalidis 1412 NEC 1413 Kurfuersten-Anlage 36 1414 Heidelberg 69115 1415 Germany 1417 Email: Andreas.Pashalidis@netlab.nec.de 1419 Yoshihiro Ohba 1420 Toshiba America Research, Inc. 1421 1 Telcordia Drive 1422 Piscataway, NJ 08854 1423 USA 1425 Email: yohba@tari.toshiba.com 1427 Florent Bersani 1428 France Telecom R&D 1429 38, rue du General Leclerc 1430 Issy-Les-Moulineaux, Cedex 92794 1431 France 1433 Email: bersani_florent@yahoo.fr 1435 Full Copyright Statement 1437 Copyright (C) The IETF Trust (2007). 1439 This document is subject to the rights, licenses and restrictions 1440 contained in BCP 78, and except as set forth therein, the authors 1441 retain all their rights. 1443 This document and the information contained herein are provided on an 1444 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1445 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1446 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1447 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1448 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1449 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1451 Intellectual Property 1453 The IETF takes no position regarding the validity or scope of any 1454 Intellectual Property Rights or other rights that might be claimed to 1455 pertain to the implementation or use of the technology described in 1456 this document or the extent to which any license under such rights 1457 might or might not be available; nor does it represent that it has 1458 made any independent effort to identify any such rights. Information 1459 on the procedures with respect to rights in RFC documents can be 1460 found in BCP 78 and BCP 79. 1462 Copies of IPR disclosures made to the IETF Secretariat and any 1463 assurances of licenses to be made available, or the result of an 1464 attempt made to obtain a general license or permission for the use of 1465 such proprietary rights by implementers or users of this 1466 specification can be obtained from the IETF on-line IPR repository at 1467 http://www.ietf.org/ipr. 1469 The IETF invites any interested party to bring to its attention any 1470 copyrights, patents or patent applications, or other proprietary 1471 rights that may cover technology that may be required to implement 1472 this standard. Please address the information to the IETF at 1473 ietf-ipr@ietf.org. 1475 Acknowledgment 1477 Funding for the RFC Editor function is provided by the IETF 1478 Administrative Support Activity (IASA).