idnits 2.17.1 draft-tschofenig-eap-ikev2-11.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 1213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1203. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (June 23, 2006) is 6515 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'CERTREQ' on line 1073 -- Looks like a reference, but probably isn't: 'CERT' on line 1075 -- Looks like a reference, but probably isn't: 'IDr' on line 1048 ** 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. '6') (Obsoleted by RFC 8247) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 10 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 Expires: December 25, 2006 A. Pashalidis 5 Siemens 6 Y. Ohba 7 Toshiba 8 F. Bersani 9 France Telecom 10 June 23, 2006 12 EAP IKEv2 Method 13 draft-tschofenig-eap-ikev2-11.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 December 25, 2006. 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 . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . 21 77 7.11. Notify Payload . . . . . . . . . . . . . . . . . . . . . . 22 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 79 8.1. Protected Ciphersuite Negotiation . . . . . . . . . . . . 23 80 8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 23 81 8.3. Integrity Protection . . . . . . . . . . . . . . . . . . . 23 82 8.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 24 83 8.5. Confidentiality . . . . . . . . . . . . . . . . . . . . . 24 84 8.6. Key Strength . . . . . . . . . . . . . . . . . . . . . . . 24 85 8.7. Dictionary Attack Resistance . . . . . . . . . . . . . . . 25 86 8.8. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 25 87 8.9. Cryptographic Binding . . . . . . . . . . . . . . . . . . 25 88 8.10. Session Independence . . . . . . . . . . . . . . . . . . . 25 89 8.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 26 90 8.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 26 91 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 27 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 95 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 96 Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication . 30 97 A.1. Full EAP-IKEv2 . . . . . . . . . . . . . . . . . . . . . . 30 98 A.2. EAP-IKEv2 Fast Reconnect . . . . . . . . . . . . . . . . . 31 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 100 Intellectual Property and Copyright Statements . . . . . . . . . . 34 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 Other conceivable use cases are not expected to be used in practice 136 due to key management issues, and have not been considered in this 137 document. 139 The remainder of this document is structured as follows. 141 o The next section provides an overview of some of the terms and 142 abbreviations used in this document. 144 o Section 3 provides an overview of the full EAP-IKEv2 exchange and 145 thereby specifies the protocol message composition. 147 o Section 4 specifies the optional EAP-IKEv2 "fast reconnect" mode 148 of operation. 150 o Section 5 specifies how exportable session keys are derived. 152 o Section 6 specifies how possible errors that may occur during 153 protocol execution are handled. 155 o Section 7 specifies the format of the EAP-IKEv2 data fields. 156 Section 7.1 describes how fragmentation is handled in EAP-IKEv2. 158 o Section 8 provides a list of claimed security properties. 160 2. Terminology 162 This document makes use of terms defined in [2] and [1]. In 163 addition, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 164 SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear 165 in this document, are to be interpreted as described in [3]. 167 A list of abbreviations that are used in this document follows. 169 o AUTH: Denotes a data field containing either a MAC or a signature. 170 This field is in embedded into an Authentication payload, defined 171 in Section 7.10. 173 o CERT: Public key certificate or similar structure. 175 o CERTREQ: Certificate Request. 177 o EMSK: Extended Master Session Key, defined in [2]. 179 o HDR: EAP-IKEv2 header, defined in Section 7.2. 181 o I: Initiator, the party that sends the first message of an EAP- 182 IKEv2 protocol run. This is always the EAP server. 184 o MAC: Message Authentication Code. The result of a cryptographic 185 operation that involves a symmetric key. 187 o MSK: Master Session Key, defined in [2]. 189 o prf: Pseudorandom function: a cryptographic function whose output 190 is assumed to be indistinguishable from that of a truly random 191 function. 193 o R: Responder, the party that sends the second message of an EAP- 194 IKEv2 protocol run. This is always the EAP peer. 196 o SA: Security Association. In this document SA denotes a type of 197 payload that is used for the negotiation of the cryptographic 198 algorithms that are to be used within an EAP-IKEv2 protocol run. 199 Specifically, SAi denotes a set of choices that are accepted by an 200 initiator, and SAr denotes the choice of the responder. 202 o Signature: The result of a cryptographic operation that involves 203 an asymmetric key. In particular, it involves the private part of 204 a public/private key pair. 206 o SK: Session Key. In this document, the notation SK{x} denotes that 207 x is embedded within an Encrypted payload, i.e. that x is 208 encrypted and integrity-protected using EAP-IKEv2 internal keys. 209 These keys are different in each direction. 211 o SK_xx: EAP-IKEv2 internal key, defined in section 2.14 of [1]. 213 o SKEYSEED: Keying material, defined in section 2.14 of [1]. 215 3. Protocol Overview 217 In this section, the full EAP-IKEv2 protocol run is specified. All 218 messages are sent between two parties, namely an EAP peer and an EAP 219 server. In EAP-IKEv2, the EAP server always assumes the role of the 220 initiator (I), and the EAP peer that of the responder (R) of an 221 exchange. 223 The semantics and formats of EAP-IKEv2 messages are similar, albeit 224 not identical, to those specified in IKEv2 [1] for the establishment 225 of an IKE Security Association. The full EAP-IKEv2 protocol run 226 consists of two roundtrips that are followed by either an EAP-Success 227 or an EAP-Failure message. An optional roundtrip for exchanging EAP 228 identities may precede the two exchanges. 230 1. R<-I: EAP-Request/Identity 232 2. R->I: EAP-Response/Identity(Id) 234 3. R<-I: EAP-Req (HDR, SAi, KEi, Ni) 236 4. R->I: EAP-Res (HDR, SAr, KEr, Nr, [CERTREQ], [SK{IDr}]) 238 5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], AUTH}) 240 6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH}) 242 7. R<-I: EAP-Success 244 Figure 1: EAP-IKEv2 full, successful protocol run 246 Figure 1 shows the full EAP-IKEv2 protocol run, including the 247 optional EAP identity exchange (messages 1 and 2). A detailed 248 specification of the message composition follows. 250 Messages 1 and 2 are a standard EAP Identity Request and Response, as 251 defined in [2]. Message 3 is the first EAP-IKEv2-specific message. 252 With this, the server starts the actual EAP authentication exchange. 253 It contains the initiator SPI in the EAP-IKEv2 header (HDR) (the 254 initiator selects this value on a per-protocol run basis), the set of 255 cryptographic algorithms the server is willing to accept for the 256 protection of EAP-IKEv2 traffic (encryption and integrity protection) 257 and the derivation of the session key. This set is encoded in the 258 Security Association payload (SAi). It also contains a Diffie- 259 Hellman payload (KEi), and a Nonce payload (Ni). 261 When the peer receives message 3, it selects a set of cryptographic 262 algorithms from the ones that are proposed in the message. In this 263 overview, it is assumed that an acceptable such set exists (and is 264 thus selected), and that the Diffie-Hellman value KEi belongs to an 265 acceptable group. The peer then generates a non-zero Responder SPI 266 value for this protocol run, its own Diffie-Hellman value (KEr) and 267 nonce (Nr), and calculates the keys SKEYSEED, SK_d, SK_ai, SK_ar, 268 SK_ei, SK_er, SK_pi, and SK_pr according to section 2.14 of [1]. The 269 peer then constructs message 4. In the context of use cases 1, 2 and 270 3, the peer's local policy MAY dictate the inclusion of the optional 271 CERTREQ payload in that message, which gives a hint to the server to 272 include a certificate for its public key in its next message. In the 273 context of use case 4, the peer MUST include the optional SK{IDr} 274 payload, which contains its EAP-IKEv2 identifier, encrypted and 275 integrity-protected within an Encrypted payload. The keys used to 276 construct this Encrypted payload are SK_er (for encryption) and SK_ar 277 (for integrity protection), in accordance with [1]. The responder's 278 EAP-IKEv2 identifier (IDr) is likely to be needed in these use cases 279 by the server in order to select the correct symmetric key or 280 password for the construction of the AUTH payload of message 5. 282 Upon reception of message 4, the server also computes SKEYSEED, SK_d, 283 SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr according to section 284 2.14 of [1]. If an SK{IDr} payload is included, the server decrypts 285 it and verifies its integrity with the corresponding keys. In this 286 overview, decryption and verification is assumed to succeed. The 287 server then constructs message 5 which contains only the EAP-IKEv2 288 header followed by a single Encrypted payload. The keys used to 289 generate the encrypted payload MUST be SK_ei (for encryption) and 290 SK_ai (for integrity protection), in accordance with [1]. The 291 initiator MUST embed at least two payloads in the Encrypted Payload, 292 as follows. An Identification payload with the initiator's EAP-IKEv2 293 identifer MUST be embedded in the Encrypted payload. The 294 Authentication payload MUST be embedded in the Encrypted payload. A 295 Certificate payload, and/or a Certificate Request payload MAY also be 296 embedded in the Encrypted payload. Message 5 is sent to the 297 responder. 299 Upon reception of message 5, the responder (EAP peer) authenticates 300 the initiator (EAP server). The checks that are performed to this 301 end depend on the use case, local policies, and are specified in [1]. 302 These checks include (but may not be limited to) decrypting the 303 Encrypted payload, verifying its integrity, and checking that the 304 Authentication payload contains the expected value. If all checks 305 succeed (which is assumed in this overview), the responder constructs 306 message 6. That message MUST contain the EAP-IKEv2 header followed 307 by a single Encrypted payload, in which at least two further payloads 308 MUST be embedded, as shown in Figure 1. 310 Upon reception of message 6, the initiator (EAP server) authenticates 311 the responder (EAP peer). As above, the checks that are performed to 312 this end depend on the use case, local policies, and MUST include 313 decryption and verification of the Encrypted payload, as well as 314 checking that the Authentication payload contains the expected value. 315 If the optional SK{IDr} payload was included in message 4, the EAP 316 server MUST also ensure that the IDr paylod in message 6 is identical 317 to that in message 4. 319 If authentication succeeds, an EAP-Success message is sent to the 320 responder as message 7. The EAP server and the EAP peer generate a 321 Master Session Key (MSK) and an Extended Master Session Key (EMSK) 322 after a successful EAP-IKEv2 protocol run, according to Section 5. 324 4. Fast Reconnect 326 This section specifies a "fast reconnect" mode of operation for EAP- 327 IKEv2. Support for this mode is optional, and can only be used by an 328 EAP server/EAP peer pair that has already been mutually authenticated 329 in a previous EAP-IKEv2 protocol run. 331 The purpose of fast reconnect is to enable an efficient re- 332 authentication procedure that also results in a fresh MSK and EMSK. 333 The "fast reconnect" mode can only be used where an EAP-IKEv2 334 security context already exists at both the server and the peer, and 335 its usage is subject to the local policies. 337 The fast reconnect mode makes use of dedicated "fast reconnect EAP 338 identities". The idea is that the peer uses such a special EAP 339 identity, denoted FASTID, in order to indicate to the server whether 340 or not it wishes to start a "fast reconnect" protocol run. In order 341 for this to work, the otherwise optional EAP Identity Response MUST 342 be sent at the beginning of a "fast reconnect" protocol run. On 343 reception of FASTID, the server maps it to an existing EAP-IKEv2 344 context. If such a context exists, and depending on local policy, 345 the server, then, either proceeds with the "fast reconnect" protocol 346 run, or proceeds with message 3 of a "full" protocol run. 348 FASTID is derived according to Section 5. Note that FASTID only 349 forms the username portion of the EAP identity. Also note that, due 350 to its length and construction, the probability that any given FASTID 351 is identical to any other EAP identity, is negligible. Therefore, it 352 is unnecessary to introduce any structure to FASTID in order to 353 separate it from other EAP identities (including those that are 354 possibly not used for "fast reconnect"). 356 The EAP-IKEv2 fast reconnect exchange is similar, albeit not 357 identical, to the IKE-SA rekeying procedure as specified in section 358 2.18 of [1]. During fast reconnect, the server and the peer MAY 359 exchange fresh Diffie-Hellman values. 361 1. R<-I: EAP-Request/Identity 363 2. R->I: EAP-Response/Identity(Id) 365 3. R<-I: EAP-Req(HDR, SK{SA, Ni, [KEi]}) 367 4. R->I: EAP-Res(HDR, SK{SA, Nr, [KEr]}) 368 5. R<-I: EAP-Success 370 Figure 2: EAP-IKEv2 successful fast reconnect protocol run 372 Figure 2 shows the message composition for the EAP-IKEv2 fast 373 reconnect mode. As in the full mode, the EAP server is the initiator 374 and the EAP peer is the responder. The first two messages constitute 375 the standard EAP identity exchange. Note that, in order to use the 376 "fast reconnect" mode, message 2 MUST be sent. This is in order to 377 enable the peer to indicate its "fast reconnect" identity FASTID in 378 message 2. If the server supports "fast reconnect", if it can map 379 the FASTID to an existing EAP-IKEv2 context, and if its local policy 380 permits this, it proceeds with message 3. Note that, otherwise, the 381 server MAY choose to perform a full authentication run, in which case 382 it would respond with a message that conforms to the format of 383 message 3 in Figure 1. 385 Messages 3 and 4 establish a new EAP-IKEv2 security context. In 386 message 3, the initiator MAY select a new (non-zero) SPI value in the 387 IKE_SA Initiator's SPI field of the EAP-IKEv2 header. The value of 388 the IKE_SA Responder's SPI field MUST be the one from the previous 389 successful EAP-IKEv2 protocol run. The nonce inside the Nonce 390 payload (Ni) MUST be fresh, and the Diffie-Hellman value inside the 391 Diffie-Hellman payload (if present, KEi) MUST also be fresh. Note 392 that the algorithms and keys that are used to construct the Encrypted 393 payload in message 3, are the same as in the previous successful EAP- 394 IKEv2 protocol run. 396 Upon reception of message 3, the responder (EAP peer) decrypts and 397 verifies the Encrypted payload. If successful (as assumed in 398 Figure 2), it constructs message 4 in a fashion similar to the 399 construction of message 3. Note that the IKE_SA Responder's SPI 400 field in the EAP-IKEv2 header of message 4 MUST contain the same 401 value as in message 3. The responder MAY choose a new (non-zero) 402 value for the IKE_SA Initiator's SPI in message 4. Upon reception of 403 message 4, the initiator (EAP server) decrypts and verifies the 404 Encrypted payload. If successful, this protocol run is deemed 405 successful, and the server responds with an EAP-Success message 406 (message 5). 408 After successful EAP-IKEv2 fast reconnect protocol run, both the 409 initiator and the responder generate fresh keying material, that is 410 used for the protection of subsequent EAP-IKEv2 traffic. 411 Furthermore, both the initiator and the responder MAY generate a 412 fresh MSK and EMSK and export them. 414 The new EAP-IKEv2-specific keying material is computed in the same 415 way as in the full EAP-IKEv2 protocol run, and in accordance with 416 section 2.18 of [1]. That is, SKEYSEED is computed as SKEYSEED = 417 prf(SK_d (old), [g^ir (new)] | Ni | Nr), where SK_d (old) is the key 418 SK_d from the previous successful EAP-IKEv2 protocol run, Ni and Nr 419 are the nonces (without the Nonce payload headers) that were 420 exchanged in messages 3 and 4, and g^ir (new) is the newly computed 421 Diffie-Hellman key, if both the values KEi and KEr were present in 422 messages 3 and 4. The remaining EAP-IKEv2-specific keys (SK_d, 423 SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr) are generated as in the 424 full EAP-IKEv2 protocol run. 426 The generation of a fresh MSK, EMSK, and FASTID follows the 427 generation of the EAP-IKEv2-specific keys and adheres to the rules in 428 Section 5. 430 Note: In EAP-IKEv2, the EAP server initiates the fast reconnect mode 431 and thereby causes fresh session keys to be established. If the 432 client wishes to initiate this "fast rekeying", it needs to indicate 433 this to the network by an appropriate out-of-band means (e.g. at the 434 link-layer). 436 5. Key Derivation 438 This section describes how the Master Session Key (MSK), the Extended 439 Master Session Key (EMSK), and the "fast reconnect EAP identity" 440 (FASTID) are derived in EAP-IKEv2. It is expected that the MSK and 441 the EMSK are exported by the EAP-IKEv2 process and be used in 442 accordance with the EAP keying framework [7]. 444 During an EAP-IKEv2 protocol run, the initiator and the responder 445 generate a number of keys, as described above and in accordance with 446 section 2.14 of [1]. The generation of these keys is based on a 447 pseudorandom function (prf) that both parties have agreed to use and 448 which is applied in an iterative fashion. This iterative fashion is 449 specified in section 2.13 of [1]. The same prf is used in the same 450 fashion in order to generate the MSK and the EMSK. 452 In particular, following a successful EAP-IKEv2 protocol run, both 453 parties generate 128 octets of keying material, denoted KEYMAT, as 454 KEYMAT = prf+(SK_d, Ni | Nr), where Ni and Nr are the nonces (just 455 payload without headers) from messages 3 and 4 shown in Figure 1 (in 456 the context of a full EAP-IKEv2 protocol run) or Figure 2 (in the 457 context of a fast reconnect EAP-IKEv2 protocol run). Note that only 458 the nonces are used, i.e. not the entire Nonce payload that contains 459 them. If the output size of the prf is less than 128 octets, then 460 the prf is used iteratively, as specified in section 2.13 of [1], 461 until 128 octets are generated. 463 The first 64 octets of KEYMAT are exported as the EAP MSK, and the 464 second 64 octets are exported as the EMSK. 466 EAP-IKEv2 hosts that support the optional "fast reconnect" mode, MUST 467 also derive further 160 bits (20 octets) for the "fast reconnect EAP 468 identity" FASTID, as above. That is, hosts that support "fast 469 reconnect" generate 148 octets in total, where the last 20 octets 470 form the FASTID. The FASTID forms the username portion of a NAI that 471 is used as an EAP identifier. In order to conform with the 472 requirements of [4], the FASTID MUST be base-64 encoded according to 473 [5]. 475 The MSK, EMSK and FASTID MUST NOT be generated unless an EAP-IKEv2 476 protocol run completes successfully. Hosts that do not support the 477 "fast reconnect" mode MUST NOT generate the FASTID. Note that the 478 EAP-IKEv2 method does not produce an initialisation vector. 480 6. Error handling 482 This section specifies how errors are handled within EAP-IKEv2. For 483 conveying error information from one party to the other, the Notify 484 payload is defined and used (see Section 7.11). 486 If authentication fails (i.e. the verification of the AUTH field 487 fails at the server or the peer), but no other errors have occurred, 488 the message flow of the full and "fast reconnect" EAP-IKEv2 protocol 489 run deviates from that described in Section 3 and Section 4. The 490 message flows in the presence of authentication failures are 491 specified in Appendix A. 493 If, in message 3 of a full or "fast reconnect" EAP-IKEv2 protocol run 494 (see Figure 1 and Figure 2), the responder receives a Diffie-Hellman 495 value (KEi) that belongs to a group that is not supported (and in the 496 absence of other errors), then the responder MUST send a message of 497 the form shown in Figure 3 to the initiator. This effectively 498 becomes message 4 in the protocol run. 500 4. R->I: EAP-Res (HDR, N(INVALID_KE_PAYLOAD)) 502 Figure 3: Error handling in case of unsupported D-H value 504 The above message consists of the EAP-IKEv2 header and a Notification 505 payload with the value of the Notify Message Type field value set to 506 17 (INVALID_KE_PAYLOAD). There are two octets of data associated 507 with this notification: the number of the accepted DH Group in big 508 endian order, as specified in section 3.10.1 of [1]. 510 If, during a full EAP-IKEv2 protocol run (see Figure 1), the 511 initiator receives a message conforming to Figure 3 instead of the 512 usual message 4, then the protocol continues with a new message 3 513 that the initiator sends to the peer. In this new message 3 the 514 initiator SHOULD use a Diffie-Hellman value that is drawn from the 515 group that is indicated in the Notify payload of message 4 in 516 Figure 3. If local policy does not allow this, or if the initiator 517 does not support the indicated group, then it MUST resend the 518 original message 3 (or a "usual" message 3 with fresh values), up to 519 a predetermined number of times. If the error persists (i.e. if the 520 initiator keeps receiving a message conforming to Figure 3) beyond 521 that, then the initiator MUST give up with an EAP-Failure message. 523 If, during a fast reconnect EAP-IKEv2 protocol run (see Figure 2), 524 the initiator receives a message conforming to Figure 3 instead of 525 the usual message 4, then the protocol continues with a new message 3 526 that the initiator sends to the peer. In this new message 3 the 527 initiator MUST use a Diffie-Hellman value that is drawn from the same 528 group as the one from which the Diffie-Hellman value in message 3 of 529 the initial full EAP-IKEv2 protocol run with this peer was drawn. If 530 the error persists (i.e. if the initiator receives another message 531 conforming to Figure 3), then the initiator MUST give up with an EAP- 532 Failure message. 534 If, in the context of use case 4 and during a full EAP-IKEv2 protocol 535 run (see Figure 1), the initiator receives, in message 4, an SK{IDr} 536 payload that decrypts to a non-existent or unauthorised EAP-IKEv2 537 responder identifier IDr*, then the server SHOULD continue the 538 protocol with a message conforming to the format of message 5. The 539 AUTH payload in that message SHOULD contain a value that is 540 computationally indistinguishable from a value that it would contain 541 if IDr* was valid and authorised. This can be accomplished, for 542 example, by generating a random key and calculate AUTH as usual 543 (however, this document does not mandate a specific mechanism). Only 544 after receiving message 6, the server SHOULD respond with an 545 authentication failure notification, i.e. a message conforming to 546 message 6 in Figure 6. The purpose of this behaviour is to prevent 547 an adversary from probing the EAP-IKEv2 peer identifier space. 549 If, in the context of use cases 1, 2, or 3 and during a full EAP- 550 IKEv2 protocol run (see Figure 1), the initiator receives, in message 551 4, an SK{IDr} payload that decrypts to an EAP-IKEv2 responder 552 identifier IDr*, then the server MUST continue the protocol as usual 553 (note that such a payload would not be required in these use cases). 554 The server MUST compare IDr* with the IDr received in message 6 and, 555 in case of a mismatch, MUST respond with an authentication failure 556 notifcation, i.e. a message conforming to message 6 in Figure 6. If 557 no mismatch is detected, normal processing applies. 559 Other errors do not trigger messages with Notification payloads to be 560 sent, and MUST be treated as if nothing happened (i.e. the erroneous 561 EAP-IKEv2 packet MUST be silently discarded). This includes 562 situations where at least one of the following conditions is met, 563 with respect to an incoming EAP-IKEv2 packet. 565 o The packet contains an Encrypted payload that, when decrypted with 566 the appropriate key, yields an invalid decryption. 568 o The packet contains an Encrypted payload with a Checksum field 569 that does not verify with the appropriate key. 571 o The packet contains an Integrity Checksum Data field (see 572 Figure 4) that is incorrect. 574 o The packet does not contain a compulsory field. 576 o A field in the packet contains an invalid value (e.g. an invalid 577 combination of flags, a length field that is inconsistent with the 578 real length of the field or packet, or the responder's choice of a 579 cryptographic algorithm is different to NONE and any of those that 580 were offered by the initiator). 582 o The packet contains an invalid combination of fields (e.g. it 583 contains two or more Notify payloads with the same Notify Message 584 Type value, or two or more Transform substructures with the same 585 Transform Type and Transform ID value). 587 o The packet causes a defragmentation error. 589 o The format of the packet is invalid. 591 If an incoming packet causes both an authentication failure and a 592 channel binding error (and no other errors), then the packet MUST be 593 treated as if it only caused the authentication failure. 595 If an incoming packet contains an error for which behaviour is 596 specified in this section, and an error that, in the absence of the 597 former error, would cause the packet to be silently discarded, then 598 the packet MUST be silently discarded. 600 7. Specification of Protocol Fields 602 In this section, the format of the EAP-IKEv2 data fields and 603 applicable processing rules are specified. Figure 4 shows the 604 general packet format of EAP-IKEv2 messages, and the embedding of 605 EAP-IKEv2 into EAP. The EAP-IKEv2 messages are embedded in the Data 606 field of the standard EAP Request/Response packets. The Code, 607 Identifier, Length and Type fields are described in [2]. The EAP 608 Type for this EAP method is TBD. 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Code | Identifier | Length | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Type | Flags | Message Length | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Message Length | HDR + payloads ~ 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Integrity Checksum Data | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Figure 4: General packet format of EAP-IKEv2 624 The Flags field is always present and is used for fragmentation 625 support, as described in Section 7.1. The Message Length field is 626 not always present; it's presence is determined by a certain flag in 627 the Flags field, as described in Section 7.1. The field denoted as 628 "HDR + payloads" in Figure 4 contains the EAP-IKEv2 header (see 629 Section 7.2), followed by a number of payloads, in accordance with 630 the composition of EAP-IKEv2 messages, as described in the previous 631 sections. Note that each payload begins with a generic payload 632 header that is specified in section 3.2 of [1]. 634 The Integrity Checksum Data field is not always present; its presence 635 is determined by a certain flag in the Flags field, as described in 636 Section 7.1. 638 In the remainder of this section, the protocol fields that are used 639 in EAP-IKEv2 are specified. This specification heavily relies on the 640 IKEv2 specification [1], and many fields are constructed, formatted 641 and processed in way that is almost identical to that in IKEv2. 642 However, certain deviations from standard IKEv2 formatting and 643 processing exist. These are also highlighted in the remainder of 644 this section. 646 7.1. The Flags, Message Length, and Integrity Checksum Data fields 648 This section describes EAP-IKEv2 fragmentation, and specifies the 649 encoding and processing rules for the Flags, Message Length, and 650 Integrity Checksum Data field shown in Figure 4. 652 Fragmentation support in EAP-IKEv2 is provided by the Flags and 653 Message Length fields shown in Figure 4. These are encoded and used 654 as follows. 656 0 1 2 3 4 5 6 7 657 +-+-+-+-+-+-+-+-+ 658 |L M I 0 0 0 0 0| 659 +-+-+-+-+-+-+-+-+ 661 L = Length included 662 M = More fragments 663 I = Integrity Checksum Data included 665 Figure 5: Flags field 667 Only the first three bits (0-2) are used; all remaining bits MUST be 668 set to zero. The L flag indicates the presence of a Message Length 669 field, and the M flag indicates whether or not the current EAP 670 message has more fragments. In particular, if the L bit is set, then 671 a Message Length field MUST be present in the EAP message, as shown 672 in Figure 4. The Message Length field is four octets long and 673 contains the length of the entire message (i.e. the length of the EAP 674 Data field.). Note that, in contrast, the Length field shown in 675 Figure 4 contains the length of only the current fragment. If the L 676 bit is not set, the Message Length field MUST NOT be present. 678 The M flag MUST be set on all fragments except the last one. In the 679 last fragment, the M flag MUST NOT be set. Reliable fragment 680 delivery is provided by the retransmission mechanism of EAP. 682 The Integrity Checksum Data field contains a cryptographic checksum 683 that covers the entire EAP message, starting with the Code field, and 684 ending at the end of the EAP Data field. This field, shown in 685 Figure 4, is present only if the I bit is set in the Flags field. 686 The Integrity Checksum Data field immediately follows the EAP Data 687 field without padding. 689 Whenever possible, the Integrity Checksum Data field MUST be present 690 (and the I bit set) for each fragment, including the case where the 691 entire EAP-IKEv2 message is carried in a single fragment. The 692 algorithm and keys that are used to compute the Integrity Checksum 693 Data field MUST be identical to those used to compute the Integrity 694 Checksum Data field of the Encrypted Payload (see Section 7.9). That 695 is, the algorithm and keys that were negotiated and established 696 during this EAP-IKEv2 protocol run are used. Note that this means 697 that different keys are used to compute the Integrity Checksum Data 698 field in each direction. Also note that, for messages where this 699 algorithm and the keys are not yet established, the Integrity 700 Checksum Data field cannot be computed and is therefore not included. 701 This applies, for example, to messages 3 and 4 in Figure 1. 703 In order to minimize the exposure to denial-of-service attacks on 704 fragmented packets, messages that are not protected with an Integrity 705 Checksum Data field SHOULD NOT be fragmented. Note, however, that 706 those packets are not likely to be fragmented anyway since they do 707 not carry certificates. 709 7.2. EAP-IKEv2 header 711 The EAP-IKEv2 header, denoted HDR in this specification, is 712 constructed and formatted according to the rules specified in section 713 3.1 of [1]. 715 In the first EAP-IKEv2 message that is sent by the initiator (message 716 3 in Figure 1), the IKE_SA Responder's SPI field is set to zero. 717 This is because, at this point in time, the initiator does not know 718 what SPI value the responder will choose for this protocol run. In 719 all other messages, both SPI fields MUST contain non-zero values that 720 reflect the initiator and responder-chosen SPI values. 722 In accordance with [1], for this version of EAP-IKEv2, the MjVer 723 (major version) and MnVer (minor version) fields in the header MUST 724 be 2 and 0 respectively. The value of the Exchange Type field MUST 725 be set to 34 (IKE_SA_INIT) in messages 3 and 4, and to 35 726 (IKE_SA_AUTH) in messages 5 and 6 in Figure 1. In messages 3 and 4 727 in Figure 2 this value MUST be set to 36 (CREATE_CHILD_SA). 729 The Flags field of the EAP-IKEv2 header is also constructed according 730 to section 3.1 of [1]. Note that this is not the same field as the 731 Flags field shown in Figure 4. 733 7.3. Security Association Payload 735 The SA payload is used for the negotiation of cryptographic 736 algorithms between the initiator and the responder. The rules for 737 its construction adhere to [1], in particular section 2.7 and 3.3. 739 In EAP-IKEv2 the SA payload MUST contain a single Proposal 740 Substructure where the Protocol ID value is 1 (IKE). 742 7.4. Key Exchange Payload 744 The Key Exchange payload, denoted KEi if constructed by the initiator 745 and KEr if constructed by the responder, is formatted according to 746 the rules specified in section 3.4 of [1]. 748 7.5. Nonce Payload 750 The Nonce payload, denoted Ni if constructed by the initiator and Nr 751 if constructed by the responder, is constructed and formatted 752 according to the rules specified in section 3.9 of [1]. 754 7.6. Identification Payload 756 The Identification payload, denoted IDi if it contains an identifier 757 for the initiator and IDr if it contains an identifier for the 758 responder, is constructed and formatted according to the rules 759 specified in section 3.5 of [1]. 761 7.7. Certificate Payload 763 The Certificate payload, denoted CERT, is constructed and formatted 764 according to the rules specified in section 3.6 of [1]. Note that 765 certain certificate encodings for the EAP server certificate, e.g. 766 those that need to be resolved via another network protocol, cannot 767 be used in some typical EAP-IKEv2 deployment scenarios. A user, for 768 example, that authenticates himself by means of EAP-IKEv2 in order to 769 obtain network access, cannot resolve the server certificate at the 770 time of EAP-IKEv2 protocol execution. 772 7.8. Certificate Request Payload 774 The Certificate payload, denoted CERTREQ, is constructed and 775 formatted according to the rules specified in section 3.7 of [1]. 777 7.9. Encrypted Payload 779 The Encrypted payload, denoted SK{...}, is constructed and formatted 780 according to the rules specified in section 3.14 of [1]. 782 7.10. Authentication Payload 784 The Authentication payload, denoted AUTH, is constructed and 785 formatted according to the rules specified in sections 2.15 and 3.8 786 of [1]. 788 The contents of the Authentication payload depend on which party 789 generates this field, the use case, and the algorithm that 790 corresponds to the credential (asymmetric key, symmetric key, or 791 password) that this party uses to authenticate itself. The 792 Authentication payload contains either a MAC or a signature. 794 If the party that generates the Authentication payload authenticates 795 itself based on a shared secret (i.e. a password or a symmetric key), 796 then the Authentication payload MUST contain a MAC. This MAC is 797 calculated using a key that is derived from the shared secret, 798 according to section 2.15 of [1]. According to that section, the 799 shared secret is padded with the string "Key Pad for IKEv2" as part 800 of this key derivation. For the EAP-IKEv2 method, this rule is 801 overridden, in that the padding string is redefined as "Key Pad for 802 EAP-IKEv2". The latter padding string MUST be used for the 803 derivation of the MAC key from a shared secret in the context of EAP- 804 IKEv2. This is done in order to avoid the same MAC key to be used 805 for both IKEv2 and EAP-IKEv2 in scenarios where the same shared 806 secret is used for both. Note that using a shared secret (e.g. a 807 password) in the context EAP-IKEv2 that is identical or similar to a 808 shared secret that is used in another context (including IKEv2) is 809 nevertheless NOT RECOMMENDED. 811 7.11. Notify Payload 813 The Notify payload, denoted N(...), is constructed and formatted 814 according to the rules specified in section 3.10 of [1]. The 815 Protocol ID field of this payload MUST be set to 1 (IKE_SA). 817 8. Security Considerations 819 As mentioned in Section 3, in EAP-IKEv2, the EAP server always 820 assumes the role of the initiator (I), and the EAP peer takes on the 821 role of the responder (R) of an exchange. This is in order to ensure 822 that, in scenarios where the peer authenticates itself based on a 823 password (i.e. in use case 3), operations that involve this password 824 only take place after the server has been successfully authenticated. 825 In other words, this assignment of initiator and responder roles 826 results in protection against offline dictionary attacks on the 827 password that is used by the peer to authenticate itself (see 828 Section 8.7). 830 In order for two EAP-IKEv2 implementations to be interoperable, they 831 must support at least one common set of cryptographic algorithms. In 832 order to promote interoperability, EAP-IKEv2 implementations MUST 833 adhere to the same rules with regard to mandatory-to-implement 834 cryptographic algorithms as IKEv2. These rules are specified in [6]. 836 The remainder of this section describes EAP-IKEv2 in terms of 837 specific security terminology as required by [2]. The discussion 838 makes reference to the use cases defined in Section 1 above. 840 8.1. Protected Ciphersuite Negotiation 842 In message 3, the EAP server provides the set of ciphersuites it is 843 willing to accept in an EAP-IKEv2 protocol run. Hence, the server is 844 in control of the ciphersuite. An EAP peer that does not support any 845 of the indicated ciphersuites is not able to authenticate. The local 846 security policy of the peer MUST specify the set of ciphersuites that 847 the peer accepts. The server MUST verify that the ciphersuite that 848 is indicated as being chosen by the peer in message 4, belongs to the 849 set of ciphersuites that were offered in message 3. If this 850 verification fails, the server MUST silently discard the packet. 852 8.2. Mutual Authentication 854 EAP-IKEv2 supports mutual authentication. 856 8.3. Integrity Protection 858 EAP-IKEv2 provides integrity protection of EAP-IKEv2 traffic. This 859 protection is offered after authentication is completed and is 860 facilitated by inclusion of two Integrity Checksum Data fields: one 861 at the end of the EAP packet (see Figure 4), and one as part of an 862 Encrypted payload (see Section 7.9). 864 8.4. Replay Protection 866 EAP-IKEv2 provides protection against replay attacks by a variety of 867 means. This includes the requirement that the Authentication payload 868 is computed as a function of, among other things, a server-provided 869 nonce and a peer-provided nonce. These nonces are required to be 870 practically unpredictable by an adversary. Assuming that the 871 algorithm that is used to compute the Authentication payload does not 872 contain cryptographic weaknesses, the probability that an 873 Authentication payload that is valid in a particular protocol run, 874 will also be valid in a subsequent run, is therefore negligible. 876 8.5. Confidentiality 878 EAP-IKEv2 provides confidentiality of certain EAP-IKEv2 fields, 879 namely those included in Encrypted payloads. With respect to 880 identity confidentiality, the following claims are made. Note that 881 identity confidentiality refers to the EAP-IKEv2 identity of the EAP 882 peer. 884 Identity confidentiality is provided in the face of a passive 885 adversary, i.e. an adversary that does not modify traffic as it is in 886 transit. Whenever the optional SK{IDr} payload in message 4 of a 887 full EAP-IKEv2 protocol (see Figure 1) is not included, identity 888 confidentiality is also provided in the face of an active adversary. 889 This payload MUST NOT be included in use cases 1, 2, and 3. In use 890 case 4 this payload MUST be included. Therefore, in use case 4, EAP- 891 IKEv2 does not provide identity confidentiality in the face of an 892 active adversary. 894 8.6. Key Strength 896 EAP-IKEv2 supports the establishment of session keys (MSK and EMSK) 897 of a variety of key strengths, with the theoretical maximum at 512 898 bits per key (since this is the size of the MSK and the EMSK). 899 However, in practice the effective key strength is likely to be 900 significantly lower, and depends on the authentication credentials 901 used, the negotiated ciphersuite (including the output size of the 902 pseudorandom function), the Diffie-Hellman group used, and on the 903 extent to which the assumptions on which the underlying cryptographic 904 algorithms depend really hold. Of the above mechanisms, the one that 905 offers the lowest key strength can be regarded as a measure of the 906 effective key strength of the resulting session keys. Note that this 907 holds for other EAP methods, too. 909 Due to the large variety of possible combinations, no indication of a 910 practical effective key strength for MSK or EMSK is given here. 911 However, those responsible for the deployment of EAP-IKEv2 in a 912 particular environment should consider the threats this environment 913 may be exposed to, and configure the EAP-IKEv2 server and peer 914 policies and authentication credentials such that the established 915 session keys are of a sufficiently high effective key strength. 917 8.7. Dictionary Attack Resistance 919 EAP-IKEv2 can be used in a variety of use cases, as explained in 920 Section 1. In some of these uses cases, namely use case 1, 2, and 4, 921 dictionary attacks cannot be launched since no passwords are used. 922 In use case 3, EAP-IKEv2 provides protection against offline 923 dictionary attacks, since operations that involve the password are 924 executed only after the server has authenticated itself (based on a 925 credential other than a password). 927 In order to reduce exposure against online dictionary attacks, in use 928 case 3, the server SHOULD provide the capability to log failed peer 929 authentication events, and SHOULD implement a suitable policy in case 930 of consecutive failed peer authentication attempts within a short 931 period of time (such as responding with an EAP-Failure instead of 932 message 5 for a predetermined amount of time). 934 8.8. Fast Reconnect 936 EAP-IKEv2 supports a "fast reconnect" mode of operation, as described 937 in Section 4. 939 8.9. Cryptographic Binding 941 EAP-IKEv2 is not a tunnel EAP method. Thus, cryptographic binding 942 does not apply to EAP-IKEv2. 944 8.10. Session Independence 946 EAP-IKEv2 provides session independence in a number of ways, as 947 follows. Firstly, knowledge of captured EAP-IKEv2 conversations 948 (i.e. the information that a passive adversary may obtain) does not 949 enable the adversary to compute the Master Session Key (MSK) and 950 Extended Master Session Key (EMSK) that resulted from these 951 conversations. This holds even in the case where the adversary later 952 obtains access to the server and/or the peer's long-term 953 authentication credentials that were used in these conversations. 954 That is, EAP-IKEv2 provides support for "perfect forward secrecy". 955 However, whether or not this support is made use of in a particular 956 EAP-IKEv2 protocol run, depends on when the peer and the server 957 delete the Diffie-Hellman values that they used in that run, and on 958 whether or not they use fresh Diffie-Hellman values in each protocol 959 run. The discussion in section 2.12 of [1] applies. 961 Secondly, an active adversary that does not know the peer's and the 962 server's long-term authentication credentials cannot learn the MSK 963 and EMSK that were established in a particular protocol run of EAP- 964 IKEv2, even if it obtains access to the MSK and EMSK that were 965 established in other protocol runs of EAP-IKEv2. This is because the 966 MSK and the EMSK are a function of, among other things, data items 967 that are assumed to be generated independently at random in each 968 protocol run. 970 8.11. Fragmentation 972 EAP-IKEv2 provides support for fragmentation, as described in 973 Section 7.1. 975 8.12. Channel Binding 977 Channel binding support in EAP-IKEv2 is TBD. 979 9. IAB Considerations 981 IANA should allocate a value for the EAP method type indicating EAP- 982 IKEv2. 984 10. Acknowledgements 986 The authors are grateful to Krzysztof Rzecki, Rafal Mijal, Piotr 987 Marnik, and Pawel Matejski, who, during their implementation of EAP- 988 IKEv2, provided invaluable feedback and identified a number of errors 989 in previous versions of this draft. The authors would also like to 990 thank Bernard Aboba, Jari Arkko, Guenther Horn, Thomas Otto, Paulo 991 Pagliusi and John Vollbrecht for their insightful comments and 992 suggestions. The members of the PANA design team, in particular D. 993 Forsberg and A. Yegin, also provided comments on the initial version 994 of this draft. 996 Finally, the authors are grateful to the members of the EAP keying 997 design team for their discussion in the area of the EAP Key 998 Management Framework. 1000 11. References 1002 11.1. Normative References 1004 [1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 1005 December 2005. 1007 [2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1008 Levkowetz, "Extensible Authentication Protocol (EAP) (RFC 1009 3748)", Request For Comments 3748, June 2004. 1011 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1012 Levels", RFC 2119, March 1997. 1014 [4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network 1015 Access Identifier", RFC 4282, December 2005. 1017 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1018 Extensions (MIME) Part One: Format of Internet Message Bodies", 1019 RFC 2045, November 1996. 1021 [6] Schiller, J., "Cryptographic Algorithms for Use in the Internet 1022 Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005. 1024 11.2. Informative References 1026 [7] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz, 1027 "Extensible Authentication Protocol (EAP) Key Management 1028 Framework", Internet Draft (work in progress), January 2006. 1030 Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication 1032 This appendix illustrates how authentication failures are handled 1033 within EAP-IKEv2. 1035 A.1. Full EAP-IKEv2 1037 Figure 6 shows the message flow in case the EAP peer fails to 1038 authenticate the EAP server. 1040 1. R<-I: EAP-Request/Identity 1042 2. R->I: EAP-Response/Identity(Id) 1044 3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni) 1046 4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}]) 1048 5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH}) 1050 6. R->I: EAP-Res(HDR, SK {N(AUTHENTICATION_FAILED)}) 1052 7. R<-I: EAP-Failure 1054 Figure 6: EAP-IKEv2 with failed server authentication 1056 The difference to the full successful exchange described in Section 3 1057 is that, in message 6, the EAP peer MUST answer the EAP server with 1058 an Encrypted payload that contains a Notify payload with the Notify 1059 Message Type value set to 24 (AUTHENTICATION_FAILED). In message 7, 1060 an EAP-Failure message MUST be returned by the EAP server. 1062 Figure 7 shows the message flow in case the EAP server fails to 1063 authenticate the EAP peer. 1065 1. R<-I: EAP-Request/Identity 1067 2. R->I: EAP-Response/Identity(Id) 1069 3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni) 1071 4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}]) 1073 5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], AUTH}) 1075 6. R->I: EAP-Res (HDR, SK {IDr, [CERT], AUTH}) 1077 7. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)}) 1079 8. R->I: EAP-Res (HDR, SK {}) 1081 9. R<-I: EAP-Failure 1083 Figure 7: EAP-IKEv2 with failed peer authentication 1085 Compared to the full successful exchange, one additional roundtrip is 1086 required. In message 7 the EAP server MUST send an EAP request with 1087 Encrypted payload that contains a Notify payload with the Notify 1088 Message Type value set to 24 (AUTHENTICATION_FAILED), instead of 1089 sending an EAP-Success message. The EAP peer, upon receiving message 1090 7, MUST send an empty EAP-IKEv2 (informational) message in reply to 1091 the EAP server's error indication, as shown in message 8. The EAP 1092 server then answers with an EAP-Failure. 1094 A.2. EAP-IKEv2 Fast Reconnect 1096 Figure 8 shows the message flow in case the EAP peer fails to 1097 authenticate the EAP server. in a fast reconnect protocol run. 1099 1. R<-I: EAP-Request/Identity 1101 2. R->I: EAP-Response/Identity(Id) 1103 3. R<-I: EAP-Req (HDR, SK {SA, Ni, [KEi]}) 1105 4. R->I: EAP-Res (HDR, SK {N(AUTHENTICATION_FAILED)}) 1107 5. R <-- I: EAP-Failure 1108 Figure 8: EAP-IKEv2 fast reconnect with failed server authentication 1110 The message format of message 3 is identical to that of message 6 in 1111 Figure 6. The message processing is analogous to the case of failed 1112 server authentication in a full EAP-IKEv2 protocol run. 1114 Figure 9 shows the message flow in case the EAP server fails to 1115 authenticate the EAP peer. in a fast reconnect protocol run 1117 1. R<-I: EAP-Request/Identity 1119 2. R->I: EAP-Response/Identity(Id) 1121 3. R<-I: EAP-Req (HDR, SK {SA, Ni, [KEi]}) 1123 4. R->I: EAP-Res (HDR, SK {SA, Nr, [KEr]}) 1125 5. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)}) 1127 6. R->I: EAP-Res (HDR, SK {}) 1129 7. R<-I: EAP-Failure 1131 Figure 9: EAP-IKEv2 fast reconnect with failed peer authentication 1133 This case is analogous to the case of peer authentication failure in 1134 a full EAP-IKEv2 protocol run. The EAP peer MUST send an empty EAP- 1135 IKEv2 informational message (empty Encrypted payload, message 6) in 1136 reply to the error indication message of the EAP server (message 5). 1137 The EAP server answers with an EAP-Failure. 1139 Authors' Addresses 1141 Hannes Tschofenig 1142 Siemens 1143 Otto-Hahn-Ring 6 1144 Munich, Bavaria 81739 1145 Germany 1147 Email: Hannes.Tschofenig@siemens.com 1149 Dirk Kroeselberg 1150 Siemens 1151 Otto-Hahn-Ring 6 1152 Munich, Bavaria 81739 1153 Germany 1155 Email: Dirk.Kroeselberg@siemens.com 1157 Andreas Pashalidis 1158 Siemens 1159 Otto-Hahn-Ring 6 1160 Munich, Bavaria 81739 1161 Germany 1163 Email: Andreas.Pashalidis@siemens.com 1165 Yoshihiro Ohba 1166 Toshiba America Research, Inc. 1167 1 Telcordia Drive 1168 Piscataway, NJ 08854 1169 USA 1171 Email: yohba@tari.toshiba.com 1173 Florent Bersani 1174 France Telecom R&D 1175 38, rue du General Leclerc 1176 Issy-Les-Moulineaux, Cedex 92794 1177 France 1179 Email: bersani_florent@yahoo.fr 1181 Intellectual Property Statement 1183 The IETF takes no position regarding the validity or scope of any 1184 Intellectual Property Rights or other rights that might be claimed to 1185 pertain to the implementation or use of the technology described in 1186 this document or the extent to which any license under such rights 1187 might or might not be available; nor does it represent that it has 1188 made any independent effort to identify any such rights. Information 1189 on the procedures with respect to rights in RFC documents can be 1190 found in BCP 78 and BCP 79. 1192 Copies of IPR disclosures made to the IETF Secretariat and any 1193 assurances of licenses to be made available, or the result of an 1194 attempt made to obtain a general license or permission for the use of 1195 such proprietary rights by implementers or users of this 1196 specification can be obtained from the IETF on-line IPR repository at 1197 http://www.ietf.org/ipr. 1199 The IETF invites any interested party to bring to its attention any 1200 copyrights, patents or patent applications, or other proprietary 1201 rights that may cover technology that may be required to implement 1202 this standard. Please address the information to the IETF at 1203 ietf-ipr@ietf.org. 1205 Disclaimer of Validity 1207 This document and the information contained herein are provided on an 1208 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1209 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1210 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1211 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1212 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1213 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1215 Copyright Statement 1217 Copyright (C) The Internet Society (2006). This document is subject 1218 to the rights, licenses and restrictions contained in BCP 78, and 1219 except as set forth therein, the authors retain all their rights. 1221 Acknowledgment 1223 Funding for the RFC Editor function is currently provided by the 1224 Internet Society.