idnits 2.17.1 draft-tschofenig-eap-ikev2-12.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1251. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (October 23, 2006) is 6394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'CERTREQ' on line 1150 -- Looks like a reference, but probably isn't: 'CERT' on line 1152 -- Looks like a reference, but probably isn't: 'NFID' on line 382 -- Looks like a reference, but probably isn't: 'KEi' on line 382 -- Looks like a reference, but probably isn't: 'RFC3629' on line 850 -- Looks like a reference, but probably isn't: 'IDr' on line 1125 == Unused Reference: '5' is defined on line 1095, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1099, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (ref. '1') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4307 (ref. '4') (Obsoleted by RFC 8247) ** Obsolete normative reference: RFC 4282 (ref. '6') (Obsoleted by RFC 7542) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP WG H. Tschofenig 3 Internet-Draft D. Kroeselberg 4 Intended status: Informational A. Pashalidis 5 Expires: April 26, 2007 Siemens 6 Y. Ohba 7 Toshiba 8 F. Bersani 9 France Telecom 10 October 23, 2006 12 EAP IKEv2 Method 13 draft-tschofenig-eap-ikev2-12.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 26, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document specifies EAP-IKEv2, an EAP authentication method that 47 is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2 48 provides mutual authentication and session key establishment between 49 an EAP peer and an EAP server. It supports authentication techniques 50 that are based on passwords, high-entropy shared keys, and public key 51 certificates. These techniques can be combined in a number of ways. 52 EAP-IKEv2 further provides support for cryptographic ciphersuite 53 negotiation, hash function agility, identity confidentiality (in 54 certain modes of operation), fragmentation, and an optional "fast 55 reconnect" mode. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 62 4. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . . . 11 63 5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 14 64 6. Error handling . . . . . . . . . . . . . . . . . . . . . . . . 15 65 7. Specification of Protocol Fields . . . . . . . . . . . . . . . 18 66 7.1. The Flags, Message Length, and Integrity Checksum Data 67 fields . . . . . . . . . . . . . . . . . . . . . . . . . . 19 68 7.2. EAP-IKEv2 header . . . . . . . . . . . . . . . . . . . . . 20 69 7.3. Security Association Payload . . . . . . . . . . . . . . . 21 70 7.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . . 21 71 7.5. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 21 72 7.6. Identification Payload . . . . . . . . . . . . . . . . . . 21 73 7.7. Certificate Payload . . . . . . . . . . . . . . . . . . . 21 74 7.8. Certificate Request Payload . . . . . . . . . . . . . . . 21 75 7.9. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 21 76 7.10. Authentication Payload . . . . . . . . . . . . . . . . . . 22 77 7.11. Notify Payload . . . . . . . . . . . . . . . . . . . . . . 22 78 7.12. Next Fast-ID Payload . . . . . . . . . . . . . . . . . . . 22 79 8. Payload Types and Extensibility . . . . . . . . . . . . . . . 24 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 81 9.1. Protected Ciphersuite Negotiation . . . . . . . . . . . . 25 82 9.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 25 83 9.3. Integrity Protection . . . . . . . . . . . . . . . . . . . 25 84 9.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 26 85 9.5. Confidentiality . . . . . . . . . . . . . . . . . . . . . 26 86 9.6. Key Strength . . . . . . . . . . . . . . . . . . . . . . . 26 87 9.7. Dictionary Attack Resistance . . . . . . . . . . . . . . . 27 88 9.8. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 27 89 9.9. Cryptographic Binding . . . . . . . . . . . . . . . . . . 27 90 9.10. Session Independence . . . . . . . . . . . . . . . . . . . 27 91 9.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 28 92 9.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 28 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 94 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 96 12.1. Normative References . . . . . . . . . . . . . . . . . . . 31 97 12.2. Informative References . . . . . . . . . . . . . . . . . . 31 98 Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication . 32 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 100 Intellectual Property and Copyright Statements . . . . . . . . . . 35 102 1. Introduction 104 This document specifies EAP-IKEv2, an EAP authentication method that 105 is based on the Internet Key Exchange Protocol version 2 (IKEv2) [1]. 106 It provides mutual authentication and session key establishment 107 between an EAP peer and an EAP server. It supports authentication 108 techniques that are based on the following types of credential. 110 o Asymmetric key pairs: these are public/private key pairs where the 111 public key is embedded into a digital certificate, and the 112 corresponding private key is known only to a single party. 114 o Passwords: these are low-entropy bit strings that are known to 115 both the server and the peer. 117 o Symmetric keys: these are high-entropy bit strings that known to 118 both the server and the peer. 120 It is possible to use a different authentication credential (and 121 thereby technique) in each direction, e.g. that the EAP server 122 authenticates itself based on a public/private key pair and the EAP 123 client based on a symmetric key. In particular, the following 124 combinations are expected to be used in practice. These are referred 125 to as "use cases" in the remainder of this document. 127 1. EAP server: asym. key pair, EAP peer: asym. key pair 129 2. EAP server: asym. key pair, EAP peer: symmetric key 131 3. EAP server: asym. key pair, EAP peer: password 133 4. EAP server: symmetric key, EAP peer: symmetric key 135 Note that, in use cases 2 and 4, a symmetric key is assumed to be 136 chosen uniformly at random from its key space; it is therefore 137 assumed that symmetric keys are not derived from passwords. Also 138 note that, in use case 3, the EAP server must either have access to 139 all passwords in plaintext, or, alternatively, for each password 140 store the value prf(password,"Key Pad for EAP-IKEv2") for all 141 supported pseudorandom functions (also see Section 7.10 below and 142 section 2.15 of [1]). Other conceivable use cases are not expected 143 to be used in practice due to key management issues, and have not 144 been considered in this document. 146 The remainder of this document is structured as follows. 148 o The next section provides an overview of some of the terms and 149 abbreviations used in this document. 151 o Section 3 provides an overview of the full EAP-IKEv2 exchange and 152 thereby specifies the protocol message composition. 154 o Section 4 specifies the optional EAP-IKEv2 "fast reconnect" mode 155 of operation. 157 o Section 5 specifies how exportable session keys are derived. 159 o Section 6 specifies how possible errors that may occur during 160 protocol execution are handled. 162 o Section 7 specifies the format of the EAP-IKEv2 data fields. 163 Section 7.1 describes how fragmentation is handled in EAP-IKEv2. 165 o Section 8 specifies the payload type values and describes protocol 166 extensibility. 168 o Section 9 provides a list of claimed security properties. 170 2. Terminology 172 This document makes use of terms defined in [2] and [1]. In 173 addition, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 174 SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear 175 in this document, are to be interpreted as described in [3]. 177 A list of abbreviations that are used in this document follows. 179 o AUTH: Denotes a data field containing either a MAC or a signature. 180 This field is in embedded into an Authentication payload, defined 181 in Section 7.10. 183 o CERT: Public key certificate or similar structure. 185 o CERTREQ: Certificate Request. 187 o EMSK: Extended Master Session Key, defined in [2]. 189 o HDR: EAP-IKEv2 header, defined in Section 7.2. 191 o I: Initiator, the party that sends the first message of an EAP- 192 IKEv2 protocol run. This is always the EAP server. 194 o MAC: Message Authentication Code. The result of a cryptographic 195 operation that involves a symmetric key. 197 o MSK: Master Session Key, defined in [2]. 199 o prf: Pseudorandom function: a cryptographic function whose output 200 is assumed to be indistinguishable from that of a truly random 201 function. 203 o R: Responder, the party that sends the second message of an EAP- 204 IKEv2 protocol run. This is always the EAP peer. 206 o SA: Security Association. In this document SA denotes a type of 207 payload that is used for the negotiation of the cryptographic 208 algorithms that are to be used within an EAP-IKEv2 protocol run. 209 Specifically, SAi denotes a set of choices that are accepted by an 210 initiator, and SAr denotes the choice of the responder. 212 o Signature: The result of a cryptographic operation that involves 213 an asymmetric key. In particular, it involves the private part of 214 a public/private key pair. 216 o SK: Session Key. In this document, the notation SK{x} denotes that 217 x is embedded within an Encrypted payload, i.e. that x is 218 encrypted and integrity-protected using EAP-IKEv2 internal keys. 219 These keys are different in each direction. 221 o SK_xx: EAP-IKEv2 internal key, defined in section 2.14 of [1]. 223 o SKEYSEED: Keying material, defined in section 2.14 of [1]. 225 3. Protocol Overview 227 In this section, the full EAP-IKEv2 protocol run is specified. All 228 messages are sent between two parties, namely an EAP peer and an EAP 229 server. In EAP-IKEv2, the EAP server always assumes the role of the 230 initiator (I), and the EAP peer that of the responder (R) of an 231 exchange. 233 The semantics and formats of EAP-IKEv2 messages are similar, albeit 234 not identical, to those specified in IKEv2 [1] for the establishment 235 of an IKE Security Association. The full EAP-IKEv2 protocol run 236 consists of two roundtrips that are followed by either an EAP-Success 237 or an EAP-Failure message. An optional roundtrip for exchanging EAP 238 identities may precede the two exchanges. 240 1. R<-I: EAP-Request/Identity 242 2. R->I: EAP-Response/Identity(Id) 244 3. R<-I: EAP-Req (HDR, SAi, KEi, Ni) 246 4. R->I: EAP-Res (HDR, SAr, KEr, Nr, [CERTREQ], [SK{IDr}]) 248 5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], [NFID], AUTH}) 250 6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH}) 252 7. R<-I: EAP-Success 254 Figure 1: EAP-IKEv2 full, successful protocol run 256 Figure 1 shows the full EAP-IKEv2 protocol run, including the 257 optional EAP identity exchange (messages 1 and 2). A detailed 258 specification of the message composition follows. 260 Messages 1 and 2 are a standard EAP Identity Request and Response, as 261 defined in [2]. Message 3 is the first EAP-IKEv2-specific message. 262 With this, the server starts the actual EAP authentication exchange. 263 It contains the initiator SPI in the EAP-IKEv2 header (HDR) (the 264 initiator selects this value on a per-protocol run basis), the set of 265 cryptographic algorithms the server is willing to accept for the 266 protection of EAP-IKEv2 traffic (encryption and integrity protection) 267 and the derivation of the session key. This set is encoded in the 268 Security Association payload (SAi). It also contains a Diffie- 269 Hellman payload (KEi), and a Nonce payload (Ni). 271 When the peer receives message 3, it selects a set of cryptographic 272 algorithms from the ones that are proposed in the message. In this 273 overview, it is assumed that an acceptable such set exists (and is 274 thus selected), and that the Diffie-Hellman value KEi belongs to an 275 acceptable group. The peer then generates a non-zero Responder SPI 276 value for this protocol run, its own Diffie-Hellman value (KEr) and 277 nonce (Nr), and calculates the keys SKEYSEED, SK_d, SK_ai, SK_ar, 278 SK_ei, SK_er, SK_pi, and SK_pr according to section 2.14 of [1]. The 279 peer then constructs message 4. In the context of use cases 1, 2 and 280 3, the peer's local policy MAY dictate the inclusion of the optional 281 CERTREQ payload in that message, which gives a hint to the server to 282 include a certificate for its public key in its next message. In the 283 context of use case 4, the peer MUST include the optional SK{IDr} 284 payload, which contains its EAP-IKEv2 identifier, encrypted and 285 integrity-protected within an Encrypted payload. The keys used to 286 construct this Encrypted payload are SK_er (for encryption) and SK_ar 287 (for integrity protection), in accordance with [1]. The responder's 288 EAP-IKEv2 identifier (IDr) is likely to be needed in these use cases 289 by the server in order to select the correct symmetric key or 290 password for the construction of the AUTH payload of message 5. 292 Upon reception of message 4, the server also computes SKEYSEED, SK_d, 293 SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr according to section 294 2.14 of [1]. If an SK{IDr} payload is included, the server decrypts 295 it and verifies its integrity with the corresponding keys. In this 296 overview, decryption and verification is assumed to succeed. The 297 server then constructs message 5 which contains only the EAP-IKEv2 298 header followed by a single Encrypted payload. The keys used to 299 generate the encrypted payload MUST be SK_ei (for encryption) and 300 SK_ai (for integrity protection), in accordance with [1]. The 301 initiator MUST embed at least two payloads in the Encrypted Payload, 302 as follows. An Identification payload with the initiator's EAP-IKEv2 303 identifer MUST be embedded in the Encrypted payload. The 304 Authentication payload MUST be embedded in the Encrypted payload. A 305 Certificate payload, and/or a Certificate Request payload MAY also be 306 embedded in the Encrypted payload. Moreover, a Next Fast-Reconnect 307 Identifier payload MAY also be embedded in the Encrypted payload. 308 Message 5 is sent to the responder. 310 Upon reception of message 5, the responder (EAP peer) authenticates 311 the initiator (EAP server). The checks that are performed to this 312 end depend on the use case, local policies, and are specified in [1]. 313 These checks include (but may not be limited to) decrypting the 314 Encrypted payload, verifying its integrity, and checking that the 315 Authentication payload contains the expected value. If all checks 316 succeed (which is assumed in this overview), the responder constructs 317 message 6. That message MUST contain the EAP-IKEv2 header followed 318 by a single Encrypted payload, in which at least two further payloads 319 MUST be embedded, as shown in Figure 1. 321 Upon reception of message 6, the initiator (EAP server) authenticates 322 the responder (EAP peer). As above, the checks that are performed to 323 this end depend on the use case, local policies, and MUST include 324 decryption and verification of the Encrypted payload, as well as 325 checking that the Authentication payload contains the expected value. 326 If the optional SK{IDr} payload was included in message 4, the EAP 327 server MUST also ensure that the IDr paylod in message 6 is identical 328 to that in message 4. 330 If authentication succeeds, an EAP-Success message is sent to the 331 responder as message 7. The EAP server and the EAP peer generate a 332 Master Session Key (MSK) and an Extended Master Session Key (EMSK) 333 after a successful EAP-IKEv2 protocol run, according to Section 5. 335 4. Fast Reconnect 337 This section specifies a "fast reconnect" mode of operation for EAP- 338 IKEv2. This mode is mandatory to implement, but optional to use. 339 The purpose of fast reconnect is to enable an efficient re- 340 authentication procedure that also results in a fresh MSK and EMSK. 341 The "fast reconnect" mode can only be used where an EAP-IKEv2 342 security context already exists at both the server and the peer, and 343 its usage is subject to the local policies. In other words, it can 344 only be used by an EAP server/EAP peer pair that has already been 345 mutually authenticated in a previous EAP-IKEv2 protocol run. 347 The fast reconnect mode makes use of dedicated "fast reconnect EAP 348 identifiers". The idea is that the server indicates its willingness 349 to engage in "fast reconnect" protocol runs in the future by 350 including the optional NFID payload in message 5 of a "full" protocol 351 run (Figure 1), or in message 3 of a "fast reconnect" protocol run 352 (Figure 2). This NFID payload contains a special EAP identity, 353 denoted Fast Reconnect Identity (FRID). 355 The peer uses the FRID in order to indicate to the server whether or 356 not it wishes to start a "fast reconnect" protocol run. In order for 357 this to work, the otherwise optional EAP Identity Response MUST be 358 sent at the beginning of a "fast reconnect" protocol run. If, in the 359 previous successful "full" (resp. "fast reconnect") EAP-IKEv2 360 protocol execution, the server had not included an NFID payload in 361 message 5 (resp. 3), then the peer MUST NOT indicate an FRID (which 362 it may know from previous protocol runs or otherwise) in the EAP 363 Identity Response. Otherwise, the peer MAY do so. On reception of 364 FRID, the server maps it to an existing EAP-IKEv2 context. If such a 365 context exists, and depending on local policy, the server, then, 366 either proceeds with the "fast reconnect" protocol run, or proceeds 367 with message 3 of a "full" protocol run. If the server had 368 advertised the FRID in the previous EAP-IKEv2 protocol execution, it 369 SHOULD proceed with a "fast reconnect" protocol run. The peer MUST 370 be able to correctly handle a message 3 of a "full" protocol run, 371 even if it indicated a FRID in its EAP Identity Response. 373 The EAP-IKEv2 fast reconnect exchange is similar, albeit not 374 identical, to the IKE-SA rekeying procedure as specified in section 375 2.18 of [1]. During fast reconnect, the server and the peer MAY 376 exchange fresh Diffie-Hellman values. 378 1. R<-I: EAP-Request/Identity 380 2. R->I: EAP-Response/Identity(Id) 382 3. R<-I: EAP-Req(HDR, SK{SA, Ni, [KEi], [NFID]}) 384 4. R->I: EAP-Res(HDR, SK{SA, Nr, [KEr]}) 386 5. R<-I: EAP-Success 388 Figure 2: EAP-IKEv2 successful fast reconnect protocol run 390 Figure 2 shows the message composition for the EAP-IKEv2 fast 391 reconnect mode. As in the full mode, the EAP server is the initiator 392 and the EAP peer is the responder. The first two messages constitute 393 the standard EAP identity exchange. Note that, in order to use the 394 "fast reconnect" mode, message 2 MUST be sent. This is in order to 395 enable the peer to indicate its "fast reconnect" identity FRID in 396 message 2. If the server supports "fast reconnect", if it can map 397 the FRID to an existing EAP-IKEv2 context, and if its local policy 398 permits this, it proceeds with message 3. Note that, in that 399 message, the server MAY embed a NFID payload into the encrypted 400 payload. Also note that the server MAY choose to perform a full EAP- 401 IKEv2 run, in which case it would respond with a message that 402 conforms to the format of message 3 in Figure 1. 404 Messages 3 and 4 establish a new EAP-IKEv2 security context. In 405 message 3, the initiator MUST select a new (non-zero) value for the 406 SPI field in each proposal substructure in the SA payload (see 407 section 3.3 of [1]). The value of the IKE_SA Responder's SPI field 408 in HDR MUST be the one from the previous successful EAP-IKEv2 409 protocol run. The nonce inside the Nonce payload (Ni) MUST be fresh, 410 and the Diffie-Hellman value inside the Diffie-Hellman payload (if 411 present, KEi) MUST also be fresh. If present, the Diffie-Hellman 412 value MUST be drawn from the same group as the Diffie-Hellman value 413 in the previous successful full EAP-IKEv2 protocol run. Note that 414 the algorithms and keys that are used to construct the Encrypted 415 payload in message 3, are the same as in the previous successful EAP- 416 IKEv2 protocol run. 418 Upon reception of message 3, the responder (EAP peer) decrypts and 419 verifies the Encrypted payload. If successful (as assumed in 420 Figure 2), it constructs message 4 in a fashion similar to the 421 construction of message 3. The responder MUST choose a new (non- 422 zero) value for the SPI field in each proposal subsctructure. Upon 423 reception of message 4, the initiator (EAP server) decrypts and 424 verifies the Encrypted payload. If the server does not receive 425 message 4 within a reasonable amount of time, then it MAY resend 426 message 3 up to a predetermined amount of times before deeming re- 427 authentication to have failed. If a correct message 4 is received, 428 then this protocol run is deemed successful, and the server responds 429 with an EAP-Success message (message 5). 431 After successful EAP-IKEv2 fast reconnect protocol run, both the 432 initiator and the responder generate fresh keying material, that is 433 used for the protection of subsequent EAP-IKEv2 traffic. 434 Furthermore, both the initiator and the responder MUST generate a 435 fresh MSK and EMSK and export them. 437 The new EAP-IKEv2-specific keying material is computed in the same 438 way as in the full EAP-IKEv2 protocol run, and in accordance with 439 section 2.18 of [1]. That is, SKEYSEED is computed as SKEYSEED = 440 prf(SK_d (old), [g^ir (new)] | Ni | Nr), where SK_d (old) is the key 441 SK_d from the previous successful EAP-IKEv2 protocol run, Ni and Nr 442 are the nonces (without the Nonce payload headers) that were 443 exchanged in messages 3 and 4, and g^ir (new) is the newly computed 444 Diffie-Hellman key, if both the values KEi and KEr were present in 445 messages 3 and 4. The remaining EAP-IKEv2-specific keys (SK_d, 446 SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr) are generated as in the 447 full EAP-IKEv2 protocol run. 449 The generation of a fresh MSK and EMSK follows the generation of the 450 EAP-IKEv2-specific keys and adheres to the rules in Section 5. 452 Note 1: In EAP-IKEv2, the EAP server initiates the fast reconnect 453 mode and thereby causes fresh session keys to be established. If the 454 client wishes to initiate this "fast rekeying", it needs to indicate 455 this to the network by an appropriate out-of-band means (e.g. at the 456 link layer). 458 Note 2: It is conceivable that an adversary tries to launch a replay 459 attack against the EAP-IKEv2 fast reconnect mode of operation. In 460 particular, the adversary may try to send a previously captured 461 message 3 in a subsequent fast reconnect protocol run. This replay 462 attempt will, however, fail because the keys that the responder will 463 use to verify and decrypt the Encrypted payload are changed with 464 every successful reconnect protocol run. 466 5. Key Derivation 468 This section describes how the Master Session Key (MSK) and the 469 Extended Master Session Key (EMSK) are derived in EAP-IKEv2. It is 470 expected that the MSK and the EMSK are exported by the EAP-IKEv2 471 process and be used in accordance with the EAP keying framework [7]. 473 During an EAP-IKEv2 protocol run, the initiator and the responder 474 generate a number of keys, as described above and in accordance with 475 section 2.14 of [1]. The generation of these keys is based on a 476 pseudorandom function (prf) that both parties have agreed to use and 477 which is applied in an iterative fashion. This iterative fashion is 478 specified in section 2.13 of [1] and is denoted by prf+. 480 In particular, following a successful EAP-IKEv2 protocol run, both 481 parties generate 128 octets of keying material, denoted KEYMAT, as 482 KEYMAT = prf+(SK_d, Ni | Nr), where Ni and Nr are the nonces (just 483 payload without headers) from messages 3 and 4 shown in Figure 1 (in 484 the context of a full EAP-IKEv2 protocol run) or Figure 2 (in the 485 context of a fast reconnect EAP-IKEv2 protocol run). Note that only 486 the nonces are used, i.e. not the entire Nonce payload that contains 487 them. 489 The first 64 octets of KEYMAT are exported as the EAP MSK, and the 490 second 64 octets are exported as the EMSK. 492 The MSK and EMSK MUST NOT be generated unless an EAP-IKEv2 protocol 493 run completes successfully. Note that the EAP-IKEv2 method does not 494 produce an initialisation vector. 496 6. Error handling 498 This section specifies how errors are handled within EAP-IKEv2. For 499 conveying error information from one party to the other, the Notify 500 payload is defined and used (see Section 7.11). 502 If, in a full EAP-IKEv2 protocol run, authentication fails (i.e. the 503 verification of the AUTH field fails at the server or the peer), but 504 no other errors have occurred, the message flow deviates from that 505 described in Section 3. The message flows in the presence of 506 authentication failures are specified in Appendix A. 508 If, in message 3 of a full EAP-IKEv2 protocol run (see Figure 1), the 509 responder receives a Diffie-Hellman value (KEi) that belongs to a 510 group that is not supported (and in the absence of other errors), 511 then the responder MUST send a message of the form shown in Figure 3 512 to the initiator. This effectively becomes message 4 in the protocol 513 run. 515 4. R->I: EAP-Res (HDR, N(INVALID_KE_PAYLOAD)) 517 Figure 3: Error handling in case of unsupported D-H value 519 The above message consists of the EAP-IKEv2 header and a Notification 520 payload with the value of the Notify Message Type field value set to 521 17 (INVALID_KE_PAYLOAD). There are two octets of data associated 522 with this notification: the number of the selected DH Group in big 523 endian order, as specified in section 3.10.1 of [1]. This number 524 MUST represent a DH group that is supported by both the initiator and 525 the responder. 527 If, during a full EAP-IKEv2 protocol run (see Figure 1), the 528 initiator receives a message conforming to Figure 3 instead of the 529 usual message 4, then it MUST check whether or not the indicated DH 530 group was proposed in message 3. If it was not, then the initiator 531 MUST silently discard the message. Otherwise, the protocol continues 532 with a new message 3 that the initiator sends to the peer. In this 533 new message 3 the initiator MUST use a Diffie-Hellman value that is 534 drawn from the group that is indicated in the Notify payload of 535 message 4 in Figure 3. If the error persists (e.g. no "normal" 536 message 4 is received after a predetermined number of retransmissions 537 of message 3), then the initiator MUST give up with an EAP-Failure 538 message. 540 If, in the context of use case 4 and during a full EAP-IKEv2 protocol 541 run (see Figure 1), the initiator receives, in message 4, an SK{IDr} 542 payload that decrypts to a non-existent or unauthorised EAP-IKEv2 543 responder identifier IDr*, then the server SHOULD continue the 544 protocol with a message conforming to the format of message 5. The 545 AUTH payload in that message SHOULD contain a value that is 546 computationally indistinguishable from a value that it would contain 547 if IDr* was valid and authorised. This can be accomplished, for 548 example, by generating a random key and calculate AUTH as usual 549 (however, this document does not mandate a specific mechanism). Only 550 after receiving message 6, the server SHOULD respond with an 551 authentication failure notification, i.e. a message conforming to 552 message 6 in Figure 7. The purpose of this behaviour is to prevent 553 an adversary from probing the EAP-IKEv2 peer identifier space. 555 If, in the context of use cases 1, 2, or 3 and during a full EAP- 556 IKEv2 protocol run (see Figure 1), the initiator receives, in message 557 4, an SK{IDr} payload that decrypts to an EAP-IKEv2 responder 558 identifier IDr*, then the server MUST continue the protocol as usual 559 (note that such a payload would not be required in these use cases). 560 The server MUST compare IDr* with the IDr received in message 6 and, 561 in case of a mismatch, MUST respond with an authentication failure 562 notification, i.e. a message conforming to message 6 in Figure 7. If 563 no mismatch is detected, normal processing applies. 565 Other errors do not trigger messages with Notification payloads to be 566 sent, and MUST be treated as if nothing happened (i.e. the erroneous 567 EAP-IKEv2 packet MUST be silently discarded). This includes 568 situations where at least one of the following conditions is met, 569 with respect to an incoming EAP-IKEv2 packet. 571 o The packet contains an Encrypted payload that, when decrypted with 572 the appropriate key, yields an invalid decryption. 574 o The packet contains an Encrypted payload with a Checksum field 575 that does not verify with the appropriate key. 577 o The packet contains an Integrity Checksum Data field (see 578 Figure 4) that is incorrect. 580 o The packet does not contain a compulsory field. 582 o A field in the packet contains an invalid value (e.g. an invalid 583 combination of flags, a length field that is inconsistent with the 584 real length of the field or packet, or the responder's choice of a 585 cryptographic algorithm is different to NONE and any of those that 586 were offered by the initiator). 588 o The packet contains an invalid combination of fields (e.g. it 589 contains two or more Notify payloads with the same Notify Message 590 Type value, or two or more Transform substructures with the same 591 Transform Type and Transform ID value). 593 o The packet causes a defragmentation error. 595 o The format of the packet is invalid. 597 If an incoming packet contains an error for which behaviour is 598 specified in this section, and an error that, in the absence of the 599 former error, would cause the packet to be silently discarded, then 600 the packet MUST be silently discarded. 602 7. Specification of Protocol Fields 604 In this section, the format of the EAP-IKEv2 data fields and 605 applicable processing rules are specified. Figure 4 shows the 606 general packet format of EAP-IKEv2 messages, and the embedding of 607 EAP-IKEv2 into EAP. The EAP-IKEv2 messages are embedded in the Data 608 field of the standard EAP Request/Response packets. The Code, 609 Identifier, Length and Type fields are described in [2]. The EAP 610 Type for this EAP method is TBD by IANA. 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Code | Identifier | Length | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Type | Flags | Message Length | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Message Length | HDR + payloads ~ 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Integrity Checksum Data | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Figure 4: General packet format of EAP-IKEv2 626 The Flags field is always present and is used for fragmentation 627 support, as described in Section 7.1. The Message Length field is 628 not always present; it's presence is determined by a certain flag in 629 the Flags field, as described in Section 7.1. The field denoted as 630 "HDR + payloads" in Figure 4 contains the EAP-IKEv2 header (see 631 Section 7.2), followed by a number of payloads, in accordance with 632 the composition of EAP-IKEv2 messages, as described in the previous 633 sections. Note that each payload begins with a generic payload 634 header that is specified in section 3.2 of [1]. 636 The Integrity Checksum Data field is not always present; its presence 637 is determined by a certain flag in the Flags field, as described in 638 Section 7.1. 640 In the remainder of this section, the protocol fields that are used 641 in EAP-IKEv2 are specified. This specification heavily relies on the 642 IKEv2 specification [1], and many fields are constructed, formatted 643 and processed in way that is almost identical to that in IKEv2. 644 However, certain deviations from standard IKEv2 formatting and 645 processing exist. These are also highlighted in the remainder of 646 this section. 648 7.1. The Flags, Message Length, and Integrity Checksum Data fields 650 This section describes EAP-IKEv2 fragmentation, and specifies the 651 encoding and processing rules for the Flags, Message Length, and 652 Integrity Checksum Data field shown in Figure 4. 654 Fragmentation support in EAP-IKEv2 is provided by the Flags and 655 Message Length fields shown in Figure 4. These are encoded and used 656 as follows. 658 0 1 2 3 4 5 6 7 659 +-+-+-+-+-+-+-+-+ 660 |L M I 0 0 0 0 0| 661 +-+-+-+-+-+-+-+-+ 663 L = Length included 664 M = More fragments 665 I = Integrity Checksum Data included 667 Figure 5: Flags field 669 Only the first three bits (0-2) are used; all remaining bits MUST be 670 set to zero. The L flag indicates the presence of a Message Length 671 field, and the M flag indicates whether or not the current EAP 672 message has more fragments. In particular, if the L bit is set, then 673 a Message Length field MUST be present in the EAP message, as shown 674 in Figure 4. The Message Length field is four octets long and 675 contains the length of the entire message (i.e. the length of the EAP 676 Data field.). Note that, in contrast, the Length field shown in 677 Figure 4 contains the length of only the current fragment. If the L 678 bit is not set, the Message Length field MUST NOT be present. 680 The M flag MUST be set on all fragments except the last one. In the 681 last fragment, the M flag MUST NOT be set. Reliable fragment 682 delivery is provided by the retransmission mechanism of EAP. 684 The Integrity Checksum Data field contains a cryptographic checksum 685 that covers the entire EAP message, starting with the Code field, and 686 ending at the end of the EAP Data field. This field, shown in 687 Figure 4, is present only if the I bit is set in the Flags field. 688 The Integrity Checksum Data field immediately follows the EAP Data 689 field without padding. 691 Whenever possible, the Integrity Checksum Data field MUST be present 692 (and the I bit set) for each fragment, including the case where the 693 entire EAP-IKEv2 message is carried in a single fragment. The 694 algorithm and keys that are used to compute the Integrity Checksum 695 Data field MUST be identical to those used to compute the Integrity 696 Checksum Data field of the Encrypted Payload (see Section 7.9). That 697 is, the algorithm and keys that were negotiated and established 698 during this EAP-IKEv2 protocol run are used. Note that this means 699 that different keys are used to compute the Integrity Checksum Data 700 field in each direction. Also note that, for messages where this 701 algorithm and the keys are not yet established, the Integrity 702 Checksum Data field cannot be computed and is therefore not included. 703 This applies, for example, to messages 3 and 4 in Figure 1. 705 In order to minimize the exposure to denial-of-service attacks on 706 fragmented packets, messages that are not protected with an Integrity 707 Checksum Data field SHOULD NOT be fragmented. Note, however, that 708 those packets are not likely to be fragmented anyway since they do 709 not carry certificates. 711 7.2. EAP-IKEv2 header 713 The EAP-IKEv2 header, denoted HDR in this specification, is 714 constructed and formatted according to the rules specified in section 715 3.1 of [1]. 717 In the first EAP-IKEv2 message that is sent by the initiator (message 718 3 in Figure 1), the IKE_SA Responder's SPI field is set to zero. 719 This is because, at this point in time, the initiator does not know 720 what SPI value the responder will choose for this protocol run. In 721 all other messages, both SPI fields MUST contain non-zero values that 722 reflect the initiator and responder-chosen SPI values. 724 In accordance with [1], for this version of EAP-IKEv2, the MjVer 725 (major version) and MnVer (minor version) fields in the header MUST 726 be 2 and 0 respectively. The value of the Exchange Type field MUST 727 be set to 34 (IKE_SA_INIT) in messages 3 and 4, and to 35 728 (IKE_SA_AUTH) in messages 5 and 6 in Figure 1. In messages 3 and 4 729 in Figure 2 this value MUST be set to 36 (CREATE_CHILD_SA). 731 The Flags field of the EAP-IKEv2 header is also constructed according 732 to section 3.1 of [1]. Note that this is not the same field as the 733 Flags field shown in Figure 4. 735 The Message ID field is constructed as follows. Messages 3 and 4 in 736 a full and fast reconnect protocol run (see Figure 1 and 2) MUST 737 carry Message ID value 0. Messages 5 and 6 in a full protocol run 738 (see Figure 1) MUST carry Message ID value 1. 740 7.3. Security Association Payload 742 The SA payload is used for the negotiation of cryptographic 743 algorithms between the initiator and the responder. The rules for 744 its construction adhere to [1], in particular sections 2.7 and 3.3. 746 In EAP-IKEv2, all Proposal Substructures in the SA payload MUST carry 747 Protocol ID value 1 (IKE). 749 7.4. Key Exchange Payload 751 The Key Exchange payload, denoted KEi if constructed by the initiator 752 and KEr if constructed by the responder, is formatted according to 753 the rules specified in section 3.4 of [1]. 755 7.5. Nonce Payload 757 The Nonce payload, denoted Ni if constructed by the initiator and Nr 758 if constructed by the responder, is constructed and formatted 759 according to the rules specified in section 3.9 of [1]. 761 7.6. Identification Payload 763 The Identification payload, denoted IDi if it contains an identifier 764 for the initiator and IDr if it contains an identifier for the 765 responder, is constructed and formatted according to the rules 766 specified in section 3.5 of [1]. 768 7.7. Certificate Payload 770 The Certificate payload, denoted CERT, is constructed and formatted 771 according to the rules specified in section 3.6 of [1]. Note that 772 certain certificate encodings for the EAP server certificate, e.g. 773 those that need to be resolved via another network protocol, cannot 774 be used in some typical EAP-IKEv2 deployment scenarios. A user, for 775 example, that authenticates himself by means of EAP-IKEv2 in order to 776 obtain network access, cannot resolve the server certificate at the 777 time of EAP-IKEv2 protocol execution. 779 7.8. Certificate Request Payload 781 The Certificate payload, denoted CERTREQ, is constructed and 782 formatted according to the rules specified in section 3.7 of [1]. 784 7.9. Encrypted Payload 786 The Encrypted payload, denoted SK{...}, is constructed and formatted 787 according to the rules specified in section 3.14 of [1]. 789 7.10. Authentication Payload 791 The Authentication payload, denoted AUTH, is constructed and 792 formatted according to the rules specified in sections 2.15 and 3.8 793 of [1]. 795 The contents of the Authentication payload depend on which party 796 generates this field, the use case, and the algorithm that 797 corresponds to the credential (asymmetric key, symmetric key, or 798 password) that this party uses to authenticate itself. The 799 Authentication payload contains either a MAC or a signature. 801 If the party that generates the Authentication payload authenticates 802 itself based on a shared secret (i.e. a password or a symmetric key), 803 then the Authentication payload MUST contain a MAC. This MAC is 804 calculated using a key that is derived from the shared secret, 805 according to section 2.15 of [1]. According to that section, the 806 shared secret is padded with the string "Key Pad for IKEv2" as part 807 of this key derivation. For the EAP-IKEv2 method, this rule is 808 overridden, in that the padding string is redefined as "Key Pad for 809 EAP-IKEv2". The latter padding string MUST be used for the 810 derivation of the MAC key from a shared secret in the context of EAP- 811 IKEv2. This is done in order to avoid the same MAC key to be used 812 for both IKEv2 and EAP-IKEv2 in scenarios where the same shared 813 secret is used for both. Note that using a shared secret (e.g. a 814 password) in the context EAP-IKEv2 that is identical or similar to a 815 shared secret that is used in another context (including IKEv2) is 816 nevertheless NOT RECOMMENDED. 818 7.11. Notify Payload 820 The Notify payload, denoted N(...), is constructed and formatted 821 according to the rules specified in section 3.10 of [1]. The 822 Protocol ID field of this payload MUST be set to 1 (IKE_SA). 824 7.12. Next Fast-ID Payload 826 The Next Fast-ID Payload is defined as follows. 828 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 ! Next Payload !C! RESERVED ! Payload Length ! 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 ! ! 834 ~ Fast-Reconnect-ID (FRID) ~ 835 ! ! 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 Figure 6: NFID payload format 840 The Next Fast-ID payload, denoted NFID, does not have an equivalent 841 in IKEv2. Nevertheless, the Next Payload, C, RESERVED, and Payload 842 Length fields of this payload are constructed according to section 843 3.2 of [1]. The Fast-Reconnect-ID field contains a fast reconnect 844 identifer that the peer can use in the next fast reconnect protocol 845 run, as described in Section 4. In environments where a realm 846 portion is required, Fast-Reconnect-ID includes both a username 847 portion and a realm name portion. The Fast-Reconnect-ID MUST NOT 848 include any terminating null characters. The encoding of the Fast- 849 Reconnect-ID field MUST follow the UTF-8 transformation format 850 [RFC3629]. 852 8. Payload Types and Extensibility 854 In EAP-IKEv2, each payload is identified by means of a type field 855 which, as specified in [1], is indicated in the "Next Payload" field 856 of the preceding payload. However, the identifer space from which 857 EAP-IKEv2 payload types are drawn is independent from the payload 858 type space of IKEv2. This is because EAP-IKEv2 and IKEv2 may evolve 859 in a different way and, as such, payload types that appear in one 860 protocol do not necessary appear in the other. An example of this is 861 the "Next Fast-ID" (NFID) payload which does not exist in IKEv2. 863 The values for the payload types defined in this document are as 864 follows. 866 o Security Association Payload: TBD by IANA (suggested value: 33) 868 o Key Exchange payload: TBD by IANA (suggested value: 34) 870 o Nonce payload: TBD by IANA (suggested value: ) 872 o Identification payload (when sent by initiator): TBD by IANA 873 (suggested value: 35) 875 o Identification payload (when sent by responder): TBD by IANA 876 (suggested value: 36) 878 o Certificate payload: TBD by IANA (suggested value: 37) 880 o Certificate Request payload: TBD by IANA (suggested value: 38) 882 o Encrypted payload: TBD by IANA (suggested value: 46) 884 o Authentication: TBD by IANA (suggested value: 39) 886 o Notification: TBD by IANA (suggested value: 41) 888 o Next Fast-ID payload: TBD by IANA (suggested value: 64) 890 9. Security Considerations 892 As mentioned in Section 3, in EAP-IKEv2, the EAP server always 893 assumes the role of the initiator (I), and the EAP peer takes on the 894 role of the responder (R) of an exchange. This is in order to ensure 895 that, in scenarios where the peer authenticates itself based on a 896 password (i.e. in use case 3), operations that involve this password 897 only take place after the server has been successfully authenticated. 898 In other words, this assignment of initiator and responder roles 899 results in protection against offline dictionary attacks on the 900 password that is used by the peer to authenticate itself (see 901 Section 9.7). 903 In order for two EAP-IKEv2 implementations to be interoperable, they 904 must support at least one common set of cryptographic algorithms. In 905 order to promote interoperability, EAP-IKEv2 implementations MUST 906 adhere to the same rules with regard to mandatory-to-implement 907 cryptographic algorithms as IKEv2. These rules are specified in [4]. 909 The remainder of this section describes EAP-IKEv2 in terms of 910 specific security terminology as required by [2]. The discussion 911 makes reference to the use cases defined in Section 1 above. 913 9.1. Protected Ciphersuite Negotiation 915 In message 3, the EAP server provides the set of ciphersuites it is 916 willing to accept in an EAP-IKEv2 protocol run. Hence, the server is 917 in control of the ciphersuite. An EAP peer that does not support any 918 of the indicated ciphersuites is not able to authenticate. The local 919 security policy of the peer MUST specify the set of ciphersuites that 920 the peer accepts. The server MUST verify that the ciphersuite that 921 is indicated as being chosen by the peer in message 4, belongs to the 922 set of ciphersuites that were offered in message 3. If this 923 verification fails, the server MUST silently discard the packet. 925 9.2. Mutual Authentication 927 EAP-IKEv2 supports mutual authentication. 929 9.3. Integrity Protection 931 EAP-IKEv2 provides integrity protection of EAP-IKEv2 traffic. This 932 protection is offered after authentication is completed and is 933 facilitated by inclusion of two Integrity Checksum Data fields: one 934 at the end of the EAP packet (see Figure 4), and one as part of an 935 Encrypted payload (see Section 7.9). 937 9.4. Replay Protection 939 EAP-IKEv2 provides protection against replay attacks by a variety of 940 means. This includes the requirement that the Authentication payload 941 is computed as a function of, among other things, a server-provided 942 nonce and a peer-provided nonce. These nonces are required to be 943 practically unpredictable by an adversary. Assuming that the 944 algorithm that is used to compute the Authentication payload does not 945 contain cryptographic weaknesses, the probability that an 946 Authentication payload that is valid in a particular protocol run, 947 will also be valid in a subsequent run, is therefore negligible. 949 9.5. Confidentiality 951 EAP-IKEv2 provides confidentiality of certain EAP-IKEv2 fields, 952 namely those included in Encrypted payloads. With respect to 953 identity confidentiality, the following claims are made. Note that 954 identity confidentiality refers to the EAP-IKEv2 identity of the EAP 955 peer. 957 Identity confidentiality is provided in the face of a passive 958 adversary, i.e. an adversary that does not modify traffic as it is in 959 transit. Whenever the optional SK{IDr} payload in message 4 of a 960 full EAP-IKEv2 protocol (see Figure 1) is not included, identity 961 confidentiality is also provided in the face of an active adversary. 962 This payload MUST NOT be included in use cases 1, 2, and 3. In use 963 case 4 this payload MUST be included. Therefore, in use case 4, EAP- 964 IKEv2 does not provide identity confidentiality in the face of an 965 active adversary. 967 9.6. Key Strength 969 EAP-IKEv2 supports the establishment of session keys (MSK and EMSK) 970 of a variety of key strengths, with the theoretical maximum at 512 971 bits per key (since this is the size of the MSK and the EMSK). 972 However, in practice the effective key strength is likely to be 973 significantly lower, and depends on the authentication credentials 974 used, the negotiated ciphersuite (including the output size of the 975 pseudorandom function), the Diffie-Hellman group used, and on the 976 extent to which the assumptions on which the underlying cryptographic 977 algorithms depend really hold. Of the above mechanisms, the one that 978 offers the lowest key strength can be regarded as a measure of the 979 effective key strength of the resulting session keys. Note that this 980 holds for other EAP methods, too. 982 Due to the large variety of possible combinations, no indication of a 983 practical effective key strength for MSK or EMSK is given here. 984 However, those responsible for the deployment of EAP-IKEv2 in a 985 particular environment should consider the threats this environment 986 may be exposed to, and configure the EAP-IKEv2 server and peer 987 policies and authentication credentials such that the established 988 session keys are of a sufficiently high effective key strength. 990 9.7. Dictionary Attack Resistance 992 EAP-IKEv2 can be used in a variety of use cases, as explained in 993 Section 1. In some of these uses cases, namely use case 1, 2, and 4, 994 dictionary attacks cannot be launched since no passwords are used. 995 In use case 3, EAP-IKEv2 provides protection against offline 996 dictionary attacks, since operations that involve the password are 997 executed only after the server has authenticated itself (based on a 998 credential other than a password). 1000 In order to reduce exposure against online dictionary attacks, in use 1001 case 3, the server SHOULD provide the capability to log failed peer 1002 authentication events, and SHOULD implement a suitable policy in case 1003 of consecutive failed peer authentication attempts within a short 1004 period of time (such as responding with an EAP-Failure instead of 1005 message 5 for a predetermined amount of time). 1007 9.8. Fast Reconnect 1009 EAP-IKEv2 supports a "fast reconnect" mode of operation, as described 1010 in Section 4. 1012 9.9. Cryptographic Binding 1014 EAP-IKEv2 is not a tunnel EAP method. Thus, cryptographic binding 1015 does not apply to EAP-IKEv2. 1017 9.10. Session Independence 1019 EAP-IKEv2 provides session independence in a number of ways, as 1020 follows. Firstly, knowledge of captured EAP-IKEv2 conversations 1021 (i.e. the information that a passive adversary may obtain) does not 1022 enable the adversary to compute the Master Session Key (MSK) and 1023 Extended Master Session Key (EMSK) that resulted from these 1024 conversations. This holds even in the case where the adversary later 1025 obtains access to the server and/or the peer's long-term 1026 authentication credentials that were used in these conversations. 1027 That is, EAP-IKEv2 provides support for "perfect forward secrecy". 1028 However, whether or not this support is made use of in a particular 1029 EAP-IKEv2 protocol run, depends on when the peer and the server 1030 delete the Diffie-Hellman values that they used in that run, and on 1031 whether or not they use fresh Diffie-Hellman values in each protocol 1032 run. The discussion in section 2.12 of [1] applies. 1034 Secondly, an active adversary that does not know the peer's and the 1035 server's long-term authentication credentials cannot learn the MSK 1036 and EMSK that were established in a particular protocol run of EAP- 1037 IKEv2, even if it obtains access to the MSK and EMSK that were 1038 established in other protocol runs of EAP-IKEv2. This is because the 1039 MSK and the EMSK are a function of, among other things, data items 1040 that are assumed to be generated independently at random in each 1041 protocol run. 1043 9.11. Fragmentation 1045 EAP-IKEv2 provides support for fragmentation, as described in 1046 Section 7.1. 1048 9.12. Channel Binding 1050 Channel binding is not supported in EAP-IKEv2. 1052 10. IANA Considerations 1054 IANA should allocate a value for the EAP method type indicating EAP- 1055 IKEv2. In addition, IANA should allocate values for the following 1056 types of payload: Security Association, Key Exchange, Nonce, 1057 Identification (when sent by initiator), Identification (when sent by 1058 responder), Certificate, Certificate Request, Encrypted, 1059 Authentication Notification, and Next Fast-ID payload. 1061 11. Acknowledgements 1063 The authors are grateful to Krzysztof Rzecki, Rafal Mijal, Piotr 1064 Marnik, and Pawel Matejski, who, during their implementation of EAP- 1065 IKEv2, provided invaluable feedback and identified a number of errors 1066 in previous versions of this draft. The authors also thank Pasi 1067 Eronen for his invaluable comments as expert reviewer assigned by the 1068 EAP working group chairs Jari Arkko and Bernard Aboba. The authors 1069 would also like to thank Guenther Horn, Thomas Otto, Paulo Pagliusi 1070 and John Vollbrecht for their insightful comments and suggestions. 1071 The members of the PANA design team, in particular D. Forsberg and A. 1072 Yegin, also provided comments on the initial version of this draft. 1074 Finally, the authors are grateful to the members of the EAP keying 1075 design team for their discussion in the area of the EAP Key 1076 Management Framework. 1078 12. References 1080 12.1. Normative References 1082 [1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 1083 December 2005. 1085 [2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1086 Levkowetz, "Extensible Authentication Protocol (EAP) (RFC 1087 3748)", Request For Comments 3748, June 2004. 1089 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1090 Levels", RFC 2119, March 1997. 1092 [4] Schiller, J., "Cryptographic Algorithms for Use in the Internet 1093 Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005. 1095 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1096 Extensions (MIME) Part One: Format of Internet Message Bodies", 1097 RFC 2045, November 1996. 1099 [6] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 1100 Access Identifier", RFC 4282, December 2005. 1102 12.2. Informative References 1104 [7] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz, 1105 "Extensible Authentication Protocol (EAP) Key Management 1106 Framework", Internet Draft (work in progress), January 2006. 1108 Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication 1110 This appendix illustrates how authentication failures are handled 1111 within EAP-IKEv2. Note that authentication failures only occur in 1112 full EAP-IKEv2 protocol runs. 1114 Figure 7 shows the message flow in case the EAP peer fails to 1115 authenticate the EAP server. 1117 1. R<-I: EAP-Request/Identity 1119 2. R->I: EAP-Response/Identity(Id) 1121 3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni) 1123 4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}]) 1125 5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH}) 1127 6. R->I: EAP-Res(HDR, SK {N(AUTHENTICATION_FAILED)}) 1129 7. R<-I: EAP-Failure 1131 Figure 7: EAP-IKEv2 with failed server authentication 1133 The difference to the full successful exchange described in Section 3 1134 is that, in message 6, the EAP peer MUST answer the EAP server with 1135 an Encrypted payload that contains a Notify payload with the Notify 1136 Message Type value set to 24 (AUTHENTICATION_FAILED). In message 7, 1137 an EAP-Failure message MUST be returned by the EAP server. 1139 Figure 8 shows the message flow in case the EAP server fails to 1140 authenticate the EAP peer. 1142 1. R<-I: EAP-Request/Identity 1144 2. R->I: EAP-Response/Identity(Id) 1146 3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni) 1148 4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}]) 1150 5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], AUTH}) 1152 6. R->I: EAP-Res (HDR, SK {IDr, [CERT], AUTH}) 1154 7. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)}) 1156 8. R->I: EAP-Res (HDR, SK {}) 1158 9. R<-I: EAP-Failure 1160 Figure 8: EAP-IKEv2 with failed peer authentication 1162 Compared to the full successful exchange, one additional roundtrip is 1163 required. In message 7 the EAP server MUST send an EAP request with 1164 Encrypted payload that contains a Notify payload with the Notify 1165 Message Type value set to 24 (AUTHENTICATION_FAILED), instead of 1166 sending an EAP-Success message. The EAP peer, upon receiving message 1167 7, MUST send an empty EAP-IKEv2 (informational) message in reply to 1168 the EAP server's error indication, as shown in message 8. The EAP 1169 server then answers with an EAP-Failure. 1171 Authors' Addresses 1173 Hannes Tschofenig 1174 Siemens 1175 Otto-Hahn-Ring 6 1176 Munich, Bavaria 81739 1177 Germany 1179 Email: Hannes.Tschofenig@siemens.com 1181 Dirk Kroeselberg 1182 Siemens 1183 Otto-Hahn-Ring 6 1184 Munich, Bavaria 81739 1185 Germany 1187 Email: Dirk.Kroeselberg@siemens.com 1189 Andreas Pashalidis 1190 Siemens 1191 Otto-Hahn-Ring 6 1192 Munich, Bavaria 81739 1193 Germany 1195 Email: Andreas.Pashalidis@siemens.com 1197 Yoshihiro Ohba 1198 Toshiba America Research, Inc. 1199 1 Telcordia Drive 1200 Piscataway, NJ 08854 1201 USA 1203 Email: yohba@tari.toshiba.com 1205 Florent Bersani 1206 France Telecom R&D 1207 38, rue du General Leclerc 1208 Issy-Les-Moulineaux, Cedex 92794 1209 France 1211 Email: bersani_florent@yahoo.fr 1213 Full Copyright Statement 1215 Copyright (C) The Internet Society (2006). 1217 This document is subject to the rights, licenses and restrictions 1218 contained in BCP 78, and except as set forth therein, the authors 1219 retain all their rights. 1221 This document and the information contained herein are provided on an 1222 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1223 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1224 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1225 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1226 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1227 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1229 Intellectual Property 1231 The IETF takes no position regarding the validity or scope of any 1232 Intellectual Property Rights or other rights that might be claimed to 1233 pertain to the implementation or use of the technology described in 1234 this document or the extent to which any license under such rights 1235 might or might not be available; nor does it represent that it has 1236 made any independent effort to identify any such rights. Information 1237 on the procedures with respect to rights in RFC documents can be 1238 found in BCP 78 and BCP 79. 1240 Copies of IPR disclosures made to the IETF Secretariat and any 1241 assurances of licenses to be made available, or the result of an 1242 attempt made to obtain a general license or permission for the use of 1243 such proprietary rights by implementers or users of this 1244 specification can be obtained from the IETF on-line IPR repository at 1245 http://www.ietf.org/ipr. 1247 The IETF invites any interested party to bring to its attention any 1248 copyrights, patents or patent applications, or other proprietary 1249 rights that may cover technology that may be required to implement 1250 this standard. Please address the information to the IETF at 1251 ietf-ipr@ietf.org. 1253 Acknowledgment 1255 Funding for the RFC Editor function is provided by the IETF 1256 Administrative Support Activity (IASA).