idnits 2.17.00 (12 Aug 2021) /tmp/idnits19862/draft-tschofenig-eap-ikev2-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1309. ** 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 : ---------------------------------------------------------------------------- ** There are 51 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 47 has weird spacing: '...od with crypt...' == Line 388 has weird spacing: '... header is, e...' == Line 515 has weird spacing: '...ses the key d...' == Line 516 has weird spacing: '...ecified in Se...' == 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 (July 2005) is 6153 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) == Missing Reference: 'CERTREQ' is mentioned on line 292, but not defined == Missing Reference: 'RFC3579' is mentioned on line 604, but not defined == Missing Reference: 'KAU04' is mentioned on line 611, but not defined == Missing Reference: 'N' is mentioned on line 623, but not defined == Missing Reference: 'RFC3784' is mentioned on line 713, but not defined ** Obsolete undefined reference: RFC 3784 (Obsoleted by RFC 5305) -- Possible downref: Non-RFC (?) normative reference: ref. 'Kau04' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP WG 3 Internet-Draft H. Tschofenig 4 D. Kroeselberg 5 Siemens 6 Y. Ohba 7 Toshiba 8 F. Bersani 9 France Telecom R&D 10 Document: draft-tschofenig-eap-ikev2-07.txt 11 Expires: January 18, 2006 July 2005 13 EAP IKEv2 Method 14 (EAP-IKEv2) 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet-Drafts 31 as reference material or to cite them other than as "work in 32 progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on November 18, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 47 EAP-IKEv2 is an EAP authentication method with cryptographic 48 properties and basic exchanges similar to the Internet Key 49 Exchange (IKEv2) protocol. It provides a flexible EAP method with 50 support for both symmetric and asymmetric authentication, as well 51 as a combination of both. 52 EAP-IKEv2 thereby offers the security benefits of the exchanges 53 for authentication and key agreement of IKEv2 within the AAA 54 framework defined by the IETF. 56 Table of Contents 58 1. Introduction..................................................3 59 2. EAP-IKEv2 Overview............................................4 60 3. Terminology...................................................5 61 4. Protocol overview.............................................6 62 5. Identities used in EAP-IKEv2..................................9 63 6. Packet Format.................................................9 64 7. Fragmentation support........................................11 65 8. Retransmission...............................................12 66 9. Key derivation...............................................12 67 10. Error Handling..............................................14 68 11. Fast Reconnect..............................................14 69 12. Channel Binding.............................................17 70 12.1 Channel Binding Procedure in Full Authentication........17 71 12.2 Channel Binding Procedure in Fast Reconnect.............18 72 12.3 Channel Binding Error Indication........................18 73 12.4 Notify Payload Types for Channel Binding................19 74 12.5 Examples................................................20 75 13. Security Considerations.....................................24 76 13.1 General Considerations..................................24 77 13.2 Security Claims.........................................25 78 14. IANA Considerations.........................................26 79 15. Normative References........................................27 80 16. Informative References......................................27 81 Acknowledgments.................................................28 82 Author's Addresses..............................................28 83 Intellectual Property Statement.................................29 84 Disclaimer of Validity..........................................29 85 Copyright Statement.............................................30 86 Acknowledgment..................................................30 88 1. Introduction 90 This document specifies the EAP authentication method EAP-IKEv2. 91 The main design goal for EAP-IKEv2 is to provide a flexible and 92 efficient EAP method which makes security properties and exchanges 93 similar to these of the IKEv2 protocol available for all scenarios 94 using EAP-based authentication. 95 The main advantage of EAP-IKEv2 is that it does not define a new 96 cryptographic protocol, but re-uses the well-analyzed IKEv2 97 authentication exchanges within the EAP framework. Thereby, it 98 provides strong cryptographic properties as well as good 99 flexibility to support a large number of use cases. 101 EAP-IKEv2 especially provides an efficient shared-secret based 102 authentication method offering a high security level, and allows 103 for password-derived shared secrets while protecting from 104 password-guessing attacks. 106 It provides mutual authentication between EAP peers. This may be 107 based on either symmetric-key methods using pre-shared keys, or 108 on asymmetric methods based on public/private key pairs, 109 Certificates and CRLs. It is possible to use different types of 110 authentication for the different directions, e.g. the server uses 111 certificate-based authentication whereas the client uses a 112 symmetric-key method. 113 By this, both AAA scenarios where public-key EAP-based 114 authentication as well as scenarios requiring symmetric-key 115 EAP-based authentication are flexibly supported. 117 2. EAP-IKEv2 Overview 119 EAP-IKEv2 is an EAP authentication method that offers security 120 features similar to those offered by the IKEv2 protocol defined 121 for Internet key exchange. It defines exchanges and message 122 formats similar to exchanges and payloads specified by IKEv2 for 123 establishment of an IKE-SA. 125 The basic successful EAP-IKEv2 exchange as specified in section 126 4 requires two roundtrips for authenticating EAP peer and server 127 that are followed by an EAP-Success message. An optional roundtrip 128 for exchanging EAP identities may precede the authentication 129 exchange. 130 In addition to the basic exchange, a fast reconnect method is 131 specified in section 11 to allow fast session resumption with 132 increased efficiency compared to an EAP-IKEv2 standard exchange. 134 Section 5 details the handling of identities for EAP-IKEv2, since 135 identities occur in both the basic EAP exchange as well as the 136 specific EAP-IKEv2 authentication exchange. 138 In section 6, the packet format for EAP-IKEv2 messages is 139 specified, which is composed of the standard EAP request/response 140 message and the EAP method specific formats that are derived from 141 the original IKEv2 protocol specification. 143 EAP-IKEv2 provides a secure fragmentation mechanism that is 144 detailed in section 7 and details retransmission aspects in 145 section 8. 147 Key derivation as an important part of any EAP authentication 148 method is specified in section 9 that details the method-specific 149 behavior according to the overall EAP keying framework. 151 For security aspects, in section 12 a detailed discussion on 152 channel binding to avoid security issues related to misbehaving 153 EAP authenticators can be found. The general security 154 considerations for this EAP method are subsequently given in 155 section 13. 157 In general, although EAP-IKEv2 reuses parts of the original IKEv2 158 specification, it must be noted that the scenarios EAP-IKEv2 is 159 intended for are clearly different from the scenarios covered by 160 IKEv2. Therefore, a number of mechanisms available in IKEv2 are 161 not required, nor are they available, in EAP-IKEv2. For example, 162 the optional tunneling of IKEv2 (inner authentication method as 163 defined in [Kau04], section 3.16) is not supported by this version 164 of EAP-IKEv2. 166 EAP-IKEv2 provides authentication between an EAP server and an EAP 167 peer in a single authentication exchange, or phase. In contrast, 168 IKEv2 [Kau04] itself is a protocol which consists of two phases 169 that can be run (but are not necessarily run) subsequently: 171 (1) an authentication and key exchange phase which establishes an 172 IKE-SA. 174 (2) a phase for the negotiation of parameters in order to establish 175 IPsec security associations. Such exchanges contain e.g. 176 algorithm parameters and traffic selector fields, and are 177 protected by the security established in the first phase. 179 The EAP-IKEv2 method does not include any exchange similar to the 180 above phase (2), since such functionality is not a requirement in 181 the context of common AAA scenarios, consisting of an EAP peer, 182 an authenticator (NAS) and a back-end authentication server. 183 There, IPsec SA establishment may be required locally (i.e., 184 between the EAP peer and some access server). However, SA 185 establishment within an EAP method could only provide SAs between 186 the EAP peer and the back-end authentication server. Other 187 approaches as, e.g., the IETF PANA framework are considered more 188 appropriate in this case. 190 3. Terminology 192 This document does not introduce new terms other than those defined 193 in [RFC3748] or in [Kau04]. 195 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 196 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in 197 this document, are to be interpreted as described in [RFC2119]. 199 4. Protocol overview 201 This section defines the basic EAP-IKEv2 message exchanges. 203 The given exchanges are based on IKEv2 [Kau04]. 205 All message exchanges take place between two parties - between the 206 Initiator (I) and the Responder (R) of an exchange. In the context 207 of EAP the Initiator takes the role of the EAP server and the 208 responder matches the EAP peer. 210 The first message flow shows the EAP-IKEv2 full successful 211 authentication exchange. The core EAP-IKEv2 exchange (message (3) 212 to (6)) consists of four messages (two round trips)_only: 214 - Messages (3) and (4) negotiate cryptographic algorithms, 215 exchange nonces, and perform a Diffie-Hellman exchange. This 216 step is called EAP-IKE_SA_INIT exchange. 217 - Messages (5) and (6) authenticate the EAP-IKE_SA_INIT exchange, 218 and exchange the identities of Initiator and Responder (i.e. 219 the EAP server and peer) and certificates. This step is called 220 EAP-IKE_SA_AUTH exchange. 222 The first two messages (1) and (2) constitute the standard EAP 223 identity exchange and are optional; they are not required in case 224 the EAP server is known. The exchange is concluded with an 225 EAP-Success message (7) sent by the EAP server to the EAP peer. 227 In the exchange, the EAP server (B) takes the role of the Initiator 228 and the EAP peer (A) acts as the Responder. 230 1) A <-- B: EAP-Request/Identity 232 2) A --> B: EAP-Response/Identity(Id) 234 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 236 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 237 HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) 239 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 240 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) 242 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 243 HDR(A,B), SK {IDr, [CERT,] AUTH}) 245 7) A <-- B: EAP-Success 247 Figure 1: EAP-IKEv2 successful message flow 249 Descriptions of the EAP-IKEv2 message format, headers and payloads 250 are given in section 6. 252 Figure 2 shows the message flow in case the EAP peer fails to 253 authenticate the EAP server. The difference to the above 254 successful exchange is that in message (6) the EAP peer answers 255 to the EAP server with an AUTHENTICATION_FAILED error. In message 256 (7), EAP-Failure is returned from the EAP server. 258 1) A <-- B: EAP-Request/Identity 260 2) A --> B: EAP-Response/Identity(Id) 262 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 264 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 265 HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) 267 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 268 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) 270 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 271 HDR(A,B), SK {N(AUTHENTICATION_FAILED)}) 273 7) A <-- B: EAP-Failure 275 Figure 2: EAP-IKEv2 with failed server authentication 277 Figure 3 shows the message flow in case the EAP server fails to 278 authenticate the EAP peer. Compared to the successful exchange, 279 one additional roundtrip is required. In message (7) the EAP server 280 answers with an AUTHENTICATION_FAILED error instead of sending 281 EAP-Successs. The EAP peer, after receiving message (7), MUST send 282 an empty EAP-IKEv2 (informational) message in reply to the EAP 283 server's error indication, as shown in (8). The EAP server answers 284 with an EAP-Failure. 286 1) A <-- B: EAP-Request/Identity 288 2) A --> B: EAP-Response/Identity(Id) 289 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 291 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 292 HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) 294 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 295 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) 297 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 298 HDR(A,B), SK {IDr, [CERT,] AUTH}) 300 7) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 301 HDR(A,B), SK {N(AUTHENTICATION_FAILED)}) 303 8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 304 HDR(A,B), SK {}) 306 9) A <-- B: EAP-Failure 308 Figure 3: EAP-IKEv2 with failed client authentication 310 Since the goal of this EAP method is not the goal of the original 311 IKEv2 protocol to establish IPsec security associations, some 312 payloads that are specified in IKEv2 are not specified for 313 EAP-IKEv2 (as they do not occur in the message exchanges specified 314 in this document). For example, the following messages and 315 payloads are not specified for EAP-IKEv2:: 317 - Traffic Selector (TS) payloads ([Kau04], section 3.13). 318 - SA payloads ([Kau04], section 3.3) that carry SA proposals for 319 protocol IDs other than 1(IKE), i.e., SA payloads with protocol 320 ID 2 (ESP) or 3 (AH) 321 - Configuration payloads ([Kau04], section 3.15). 322 - EAP payloads ([Kau04], section 3.16), since EAP tunnelling 323 within EAP-IKEv2 is not supported in this version of EAP-IKEv2. 325 Consequently, mechanisms that are part of IKEv2 but are not 326 required nor specified within EAP-IKEv2 are: 327 - ECN Notifications as specified in section 2.24 of [Kau04]. 328 - IKE-specific port handling 329 - NAT traversal 331 IKEv2 provides optional functionality for additional DoS 332 protection by adding a roundtrip to the initial exchanges, see 333 section 2.6 of [Kau04]. This is intended to protect the IKEv2 334 responder. Because in EAP-IKEv2 the EAP server takes the role of 335 the initiator, no similar feature is specified for EAP-IKEv2. 337 5. Identities used in EAP-IKEv2 339 A number of different places allow to convey identity information 340 in IKEv2 as well as in EAP. This section describes identities and 341 their role within the different exchanges of EAP-IKEv2. Note that 342 EAP-IKEv2 does not introduce more identities than other 343 non-tunneling EAP methods. Figure 4 shows which identities are 344 used during the individual phases of the protocol. 346 +-------+ +-------------+ +---------+ 347 |Client | |Front-End | |AAA | 348 | | |Authenticator| |Server | 349 +-------+ +-------------+ +---------+ 351 EAP/Identity-Request 352 <--------------------- 353 (a) EAP/Identity-Response 354 ----------------------------------> 356 EAP-IKE_SA_INIT and AUTH exchange 357 (b) (Identities of IKEv2 are used) 358 Server (Network) Authentication 359 <---------------------------------- 360 ... 361 ----------------------------------> 363 Figure 4: Identities used in EAP-IKEv2 365 a) The first part of the EAP message exchange provides information 366 about the identities of the EAP endpoints. This message exchange 367 mainly is an identity request/response. It is optional if the EAP 368 server is known already or can be learned by other means. 370 b) Identities IDi and IDr are exchanged within the EAP-IKE_SA_INIT 371 and AUTH exchanges for both the initiator and the responder (EAP 372 server and peer). 374 For carrying identities in EAP-IKEv2, implementations MUST follow 375 the rules given in [Kau04], section 3.5, i.e., MUST be configurable 376 to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or 377 ID_KEY_ID, and MUST be configurable to accept all of these types. 378 Implementations SHOULD be capable of generating and accepting all 379 of these types. 381 6. Packet Format 382 The EAP-IKEv2 messages are EAP messages carrying the 383 authentication exchange embedded in the Data field of the standard 384 EAP Request/Response packets. The Code, Identifier, Length and 385 Type fields are described in [RFC3748]. These are followed by a 386 Type-Data field that carries one octet with method-specific Flags 387 as specified in section 7. 388 This EAP header is, embedded in the Data field, followed by the 389 method-specific header HDR and by one or more payloads of the 390 EAP-IKEv2 authentication data. 392 The EAP Type for this EAP method is . 394 The general packet format is shown in Figure 5. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Code | Identifier | Length | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type | Flags | Message Length | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Message Length | HDR ... ~ 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Integrity Checksum Data | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Figure 5: EAP-IKEv2 general packet format 410 The HDR payload that heads the Data field is as shown in Figure 411 5Figure 6 below. The HDR fields given in Figure 6 are used according 412 to [Kau04], section 3.1, where the EAP server acts as the initiator 413 and the EAP peer acts as the responder. 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 ! IKE_SA Initiator's SPI ! 417 ! ! 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 ! IKE_SA Responder's SPI ! 420 ! ! 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 ! Message ID ! 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 ! Length ! 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 6: HDR format 430 In contrast to the original IKEv2 protocol specified in [Kau04], 431 the HDR (IKE header data) is not carried within a UDP message, but 432 is directly embedded into the EAP message as shown above. However, 433 no additional packet formats other than those defined in [Kau04] 434 are required for this EAP method. 436 Following the header HDR are one or more payloads where each of 437 them is identified by a "Next Payload" field in the preceding 438 payload. Processing these payloads follows the rules specified by 439 [Kau04] section 3.2. 440 Each payload begins with a generic payload header as given in 441 Figure 7 followed by the payload data itself. 443 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 ! Next Payload !C! RESERVED ! Payload Length ! 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Figure 7: generic payload header format 451 All payloads used within the EAP-IKEv2 messages defined by this 452 document are specified in [Kau04], sections 3.3. to 3.12 and 3.14. 454 7. Fragmentation support 456 The Flags field in HDR (see section 6) is used for fragmentation 457 support. The S and F bits are reserved for future use. 459 Currently three bits of the eight bit flags field are defined. The 460 remaining bits are set to zero. 462 0 1 2 3 4 5 6 7 463 +-+-+-+-+-+-+-+-+ 464 |L M I 0 0 0 0 0| 465 +-+-+-+-+-+-+-+-+ 467 L = Length included 468 M = More fragments 469 I = Integrity Checksum Data included 471 With regard to fragmentation we adopt the mechanism given in 472 Section 2.8 of [PS+03]: The L indicates that a length field is 473 present and the M flag indicates fragments. The L flag MUST be set 474 for the first fragment and the M flag MUST be set on all fragments 475 expect for the last one. 476 Reliable fragment delivery is provided by the retransmission 477 mechanism of EAP. 479 The Message Length field is four octets long and present only if 480 the L bit is set. This field provides the total message length that 481 is being fragmented (i.e., the length of the Data field.). 483 The Integrity Checksum Data is the cryptographic checksum of the 484 entire EAP message starting with the Code field through the Data 485 field. This field presents only if the I bit is set. The field 486 immediately follows the Data field without adding any padding 487 octet before or after itself. The checksum MUST be computed for 488 each fragment (including the case where the entire IKEv2 message 489 is carried in a single fragment) by using the same key (i.e., SK_ai 490 or SK_ar) that is used for computing the checksum for the IKEv2 491 Encrypted payload in the encapsulated IKEv2 message. The 492 Integrity Checksum Data field is omitted for other packets. To 493 minimize DoS attacks on fragmented packets, messages that are not 494 protected SHOULD NOT be fragmented. 495 Note that EAP-IKE_SA_INIT messages are not encrypted or integrity 496 protected. However, they are not likely to be fragmented since they 497 do not carry certificates. 499 8. Retransmission 501 Since EAP authenticators support a timer-based retransmission 502 mechanism for EAP Requests and EAP peers retransmit the last valid 503 EAP Response when receiving a duplicate EAP Request message, IKEv2 504 messages MUST NOT be retransmitted based on timers, when used as 505 EAP authentication method. 507 9. Key derivation 509 The EAP-IKEv2 method described in this document generates session 510 keys. On the one hand, these session keys are used within the 511 IKE-SA, for protection of EAP-IKEv2 payloads, e.g., AUTH exchanges 512 or notifications. On the other hand, additional keys are derived 513 to be exported as part of the EAP keying framework [AS+05] (i.e., 514 MSK, EMSK and IV). 515 For key derivation, EAP-IKEv2 reuses the key derivation function 516 as specified in Section 2.17 of [Kau04] to create keying material 517 KEYMAT. 519 The key derivation function defined is KEYMAT = prf+(SK_d, Ni | 520 Nr), where Ni and Nr are the Nonces from the EAP-IKE_SA_INIT 521 exchange. 523 Since the required amount of keying material is greater than the 524 size of the output of the prf algorithm the prf is used iteratively. 525 Iteration is applied as specified in section 2.13 of [Kau04]. 527 The produced keying material for MSK, EMSK and IV MUST be 64 octets 528 long for each MSK, EMSK and IV. 530 Figure 8 describes the keying hierarchy of EAP-IKEv2 graphically. 531 This figure is adopted from Figure 2 of [AS+05]. 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+ 534 | | ^ 535 | EAP-IKEv2 Method | | 536 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +------------------+ | | 537 | | EAP-IKEv2 Diffie-Hellmann | | EAP-IKEv2 prot. | | | 538 | | derived and authenticated key | | session specific | | | 539 | | SK_d | | state (Nonce i,j)| | | 540 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +-------------+----+ | | 541 | | | | Local | 542 | | | | to EAP | 543 | | | | Method | 544 | | | | | 545 | | | | | 546 | | | | | 547 | | | | | 548 | +---------------+-------------+ | | | 549 | | | | | | | 550 | +-+-+-+-+-++ +-+-+-+-+-++ +-+-+-+-+-++ | | 551 | | MSK | |EMSK | | IV | | | 552 | |Derivation| |Derivation| |Derivation| | | 553 | +-+-+-+-+-++ +-+-+-+-+-++ +-+-+-+-+-++ | | 554 | | | | | V 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-++-+-+-+-+-------+-+-+----+ ---+ 556 | | | ^ 557 |MSK |EMSK |IV | 558 | | | | 559 | | | Exported | 560 | | | by EAP | 561 V V V Method | 562 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 563 | AAA Key Derivation | | Known | | 564 | Naming & Binding | |(Not Secret) | | 565 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V 567 Legend: 569 MSK = Master Session Key (512 Bit) 570 EMSK = Extended Master Session Key (512 Bit) 571 SK_d = Session key derived by EAP-IKEv2 572 IV = Initialization Vector 574 Figure 8: EAP-IKEv2 Keying Hierarchy 576 10. Error Handling 578 As described in the IKEv2 specification, there are many kinds of 579 errors that can occur during IKE processing (i.e., processing the 580 Data field of EAP-IKEv2 Request and Response messages) and 581 detailed processing rules. EAP-IKEv2 follows the error handling 582 rules specified in the IKEv2 specification for errors on the Data 583 field of EAP-IKEv2 messages, with the following additional rules: 585 For an IKEv2 error that triggers an initiation of an IKEv2 exchange 586 (i.e., an INFORMATIONAL exchange), an EAP-IKEv2 message that 587 contains the IKEv2 request that is generated for the IKEv2 exchange 588 MUST be sent to the peering entity. In this case, the EAP message 589 that caused the IKEv2 error MUST be treated as a valid EAP message. 591 For an IKEv2 error for which the IKEv2 message that caused the error 592 is discarded without triggering an initiation of an IKEv2 593 exchange, the EAP message that carries the erroneous IKEv2 message 594 MUST be treated as an invalid EAP message and discarded as if it 595 were not received at EAP layer. 597 For an error occurred outside the Data field of EAP-IKEv2 messages, 598 including defragmentation failures, integrity check failures, 599 errors in Flag and Message Length fields, the EAP message that 600 caused the error MUST be treated as an invalid EAP message and 601 discarded as if it were not received at EAP layer. 603 When the EAP-IKEv2 method runs on a backend EAP server, the error 604 handling rules defined in Section 2.2 of [RFC3579] are applied for 605 invalid EAP-IKEv2 messages. 607 11. Fast Reconnect 609 EAP-IKEv2 supports fast reconnect, i.e., a successful reconnect 610 exchange creates a new IKE-SA by using a method similar to the IKE 611 CHILD_SA exchange defined in [KAU04]. The purpose of a 612 re-authentication exchange is to allow for efficient re-keying 613 based on the existing IKE-SA in situations where (depending on the 614 given security policy) no full authentication is required in case 615 of an existing EAP-IKEv2 security context. 617 The fast reconnect exchange is similar to the IKE-SA rekeying 618 procedure as specified in section 2.18 of [Kau04]. However, the 619 exchanges for EAP-IKEv2 that are specified below do not use 620 rekeying payloads other than IKE SAs: 622 - The TS (traffic selector) payloads are not used in EAP-IKEv2. 623 - The [N] payload (REKEY_SA notification) is not sent by EAP-IKEv2. 625 During fast re-authentication, the new IKE_SA is computed as 626 specified in [Kau04], section 2.18. The new keying material 627 derived from this IKE_SA is computed in the same way as in an 628 initial EAP-IKEv2 authentication exchange. 629 Fast re-authentication allows for an optional fresh 630 Diffie-Hellman exchange in case the payloads Kei and KEr are 631 included. 633 The following exchanges specify fast reconnect for EAP-IKEv2, 634 where A is the EAP peer (responder) and B is the EAP server 635 (initiator): 637 1) A <-- B: EAP-Request/Identity 639 2) A --> B: EAP-Response/Identity(Id) 641 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 642 HDR, SK {SA, Ni, [KEi]}) 644 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 645 HDR, SK {SA, Nr, [KEr]}) 647 5) A <-- B: EAP-Success 649 Figure 9: Fast Reconnect exchange 651 The first two messages constitute the standard EAP identity 652 exchange and are optional; they are not required in case the EAP 653 server is known. Messages (3) and (4) establish the new IKE SA. 654 The successful fast reconnect is concluded by an EAP-Success sent 655 by the EAP server. 657 Figure 10 shows the fast reconnect message flow in case the EAP 658 peer fails to re-authenticate the EAP server. 660 1) A <-- B: EAP-Request/Identity 662 2) A --> B: EAP-Response/Identity(Id) 663 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2 664 (HDR, SK {SA, Ni, [KEi]}) 666 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 667 HDR, SK {N(AUTHENTICATION_FAILED)}) 669 5) A <-- B: EAP-Failure 671 Figure 10: EAP-IKEv2 fast reconnect 672 (server authentication failed) 674 Figure 11 shows the fast reconnect message flow in case the EAP 675 server fails to re-authenticate the EAP peer. The EAP peer MUST 676 send an empty EAP-IKEv2 informational message (empty encrypted 677 payload) in reply to the EAP server's error indication, as shown 678 in (6) below. The EAP server answers with an EAP-Failure. 680 1) A <-- B: EAP-Request/Identity 682 2) A --> B: EAP-Response/Identity(Id) 684 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 685 HDR, SK {SA, Ni, [KEi]}) 687 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 688 HDR, SK {SA, Nr, [KEr]}) 690 5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 691 HDR(A,B), SK {N(AUTHENTICATION_FAILED)}) 693 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 694 HDR(A,B), SK {}) 696 7) A <-- B: EAP-Failure 698 Figure 11: EAP-IKEv2 fast reconnect 699 (client authentication failed) 701 Note: The original IKEv2 protocol supports fast rekeying to be 702 initiated by both peers. IKE_SAs do not have lifetimes. Such 703 lifetimes are therefore set by local policies. Typically the peer 704 setting the shorter lifetime will therefore trigger the reconnect 705 procedure in IKEv2. 706 In EAP-IKEv2, the EAP authenticator or server initiate the 707 rekeying as this results in the most efficient message flow. If 708 the client initiates fast rekeying, it needs to indicate this to 709 the network by appropriate out-of-band (e.g. link-layer) means. 711 12. Channel Binding 713 EAP-IKEv2 provides a channel binding functionality [RFC3784] in 714 order for the EAP peer and EAP server to make sure that the both 715 entities are given the same network access attributes such as 716 Calling-Station-Id, Called-Station-Id, and NAS-Port-Type by the 717 NAS. This is achieved by using Notify payloads to exchange 718 attribute data between the EAP peer and EAP server. 720 A Notify payload that carries a null channel binding attribute is 721 referred to as a channel binding request. A Notify payload which 722 contains a non-null channel binding attribute and is sent in 723 response to a channel binding request is referred to as a channel 724 binding response. A pair of channel binding request and channel 725 binding response constitutes a channel binding exchange. A 726 distinct Notify payload type is used for a particular type of 727 channel binding attribute, which is referred to as a channel 728 binding attribute type. It is allowed to carry multiple channel 729 binding requests and/or responses with different channel binding 730 attribute types in a single IKEv2 message. A set of channel binding 731 exchanges performed in a single round of EAP-IKEv2 full 732 authentication or fast reconnect is referred to as a channel 733 binding procedure. 735 A Notify payload that is used for reporting an error occurred 736 during a channel binding exchange is referred to as a channel 737 binding error indication. 739 EAP-IKEv2 offers a protected result indication mechanism (see 740 section 13.2). To receive protected result indication, the EAP 741 server MUST initiate a channel binding exchange as specified in 742 Figure 12, message 5. As a result of this channel binding exchange, 743 the client will receive a protected result indication, because the 744 server will initiate an informational exchange as part of the 745 channel binding procedure (messages 7 and 8) through the new IKE-SA 746 that results from a successful reconnect procedure. 748 12.1 Channel Binding Procedure in Full Authentication 750 In the case of EAP-IKEv2 full authentication procedure, the 751 channel binding procedure is performed in the following way. 753 The EAP peer MAY include one or more channel binding request in 754 an IKE_SA_INIT response. The EAP server MAY include one or more 755 channel binding request in an IKE_AUTH request. When the EAP server 756 receives an IKE_SA_INIT response with one or more channel binding 757 request, it MUST include the corresponding channel binding 758 response(s) an IKE_AUTH request (in addition to its channel 759 binding request(s) if any). When the EAP peer receives an IKE_AUTH 760 request with one or more channel binding request, it MUST include 761 the corresponding channel binding response(s) in an IKE_AUTH 762 response. 764 When the EAP server successfully validates all the channel binding 765 response(s) sent by the EAP server, it initiates an INFORMATIONAL 766 exchange, where an empty payload is used in both INFORMATIONAL 767 request and INFORMATIONAL response. This exchange serves as a 768 protected success indication. After completion of this 769 INFORMATIONAL exchange, the EAP server sends Success message. 771 12.2 Channel Binding Procedure in Fast Reconnect 773 In the case of EAP-IKEv2 fast reconnect, the channel binding 774 procedure is performed in the following way. 776 In the pair of CREATE_CHILD_SA exchange, the EAP peer and/or the 777 EAP server MAY include one or more channel binding request, one 778 for each channel binding attribute that needs validation. When 779 the EAP peer receives a CREATE_CHILD_SA request with containing 780 one or more channel binding request, it MUST contain channel 781 binding response(s) in the CREATE_CHILD_SA response, as well as 782 its channel binding request(s) if any. This piggybacking is 783 possible because the CREATE_CHILD_SA exchange is protected with 784 the old IKE_SA. When the EAP server receives a CREATE_CHILD_SA 785 response, if it has one or more channel binding response to send 786 to the EAP peer, it initiates an INFORMATIONAL exchange 787 immediately after completion of the CREATE_CHILD_SA exchange, 788 where one or more channel binding response is carried in the 789 INFORMATIONAL request. If the EAP peer successfully validates the 790 channel binding response(s), it MUST respond with an empty 791 INFORMATIONAL response. This exchange serves as a protected 792 success indication. After completion of this INFORMATIONAL 793 exchange, the EAP server sends Success message. 795 12.3 Channel Binding Error Indication 797 A channel binding error is detected by the EAP peer or EAP server 798 when (i) a channel binding response is not contained in the 799 expected IKEv2 message or (ii) a channel binding response is 800 contained in the expected IKEv2 message but the channel binding 801 attribute does not have the expected value. Whenever a channel 802 binding error is detected, the detecting entity MUST send a channel 803 binding error indication to its peering entity. In case of (ii), 804 the channel binding error indication MUST contain the channel 805 binding attribute that caused the error. 807 When the EAP server detects a channel binding error, a channel 808 binding error indication MUST be carried in an INFORMATIONAL 809 request, and the EAP peer MUST respond with an empty INFORMATIONAL 810 response. 811 When the EAP peer detects a channel binding error, a channel 812 binding error indication MUST be carried in an IKEv2 error 813 reporting message for which the R-flag of the IKEv2 header MUST 814 be set. The EAP server MUST respond with EAP-Failure message when 815 it receives such a channel binding error indication. 817 12.4 Notify Payload Types for Channel Binding 819 The following Notify Payload types are defined for the purpose of 820 channel binding exchange. 822 CALLING_STATION_ID TBD 823 The payload data in a channel binding response of this type 824 contains octet string representation of 825 Calling-Station-Id value known to the EAP server by using 826 an external mechanism. 828 CALLED_STATION_ID TBD 829 The payload data in a channel binding response of this type 830 contains octet string representation of Called-Station-Id 831 value known to the EAP peer by using an external mechanism. 833 NAS_PORT_TYPE TBD 834 The payload data in a channel binding response of this type 835 contains 4-octet unsigned integer value of NAS-Port-Type 836 known to the EAP peer by using an external mechanism. 838 The following Notify Payload types are defined for the purpose of 839 reporting when there is an error in a channel binding exchange. 841 INVALID_CALLING_STATION_ID TBD 843 The payload data (if non-null) contains octet string 844 representation of Calling-Station-Id value that caused the 845 error. 847 INVALID_CALLED_STATION_ID TBD 849 The payload data (if non-null) contains octet string 850 representation of Called-Station-Id value that caused the 851 error. 853 INVALID_NAS_PORT_TYPE TBD 855 The payload data (if non-null) contains 4-octet unsigned 856 integer value of NAS-Port-Type that caused the error. 858 Table 1 shows the entity that is allowed to send a channel binding 859 request for each channel binding attribute type. 861 channel binding The entity that is allowed to send 862 attribute type channel binding request 863 ----------------------+--------------------------------------- 864 CALLING_STATION_ID EAP server 866 CALLED_STATION_ID EAP peer 868 NAS_PORT_TYPE EAP server 870 Table 1: Channel Binding Attribute Types and Requesting 871 Entities 873 12.5 Examples 875 In the figures of this section, a Notify payload tagged with '*' 876 indicates a Notify payload with null data (i.e., a channel binding 877 request). a Notify payload no tagged with '*' indicates a Notify 878 payload with non-null data (i.e., a channel binding response). 880 Figure 12 shows an example of EAP-IKEv2 authentication sequence 881 with a successful channel binding procedure. The first two 882 messages constitute the standard EAP identity exchange and are 883 optional. 885 1) A <-- B: EAP-Request/Identity 887 2) A --> B: EAP-Response/Identity(Id) 889 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 891 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 892 HDR(A,B), SAr1, KEr, Nr, [CERTREQ,] 893 N(CALLED_STATION_ID*)) 895 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 896 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH, 897 N(CALLED_STATION_ID), 898 N(CALLING_STATION_ID*), 899 N(NAS_PORT_TYPE*)}) 901 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 902 HDR(A,B), SK {IDr, [CERT,] AUTH, 903 N(CALLING_STATION_ID), 904 N(NAS_PORT_TYPE)}) 906 7) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 907 HDR(A,B), SK {}) 909 8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 910 HDR(A,B), SK {}) 912 9) A <-- B: EAP-Success 914 Figure 12: EAP-IKEv2 with successful channel binding 916 Figure 13 shows an example of EAP-IKEv2 authentication sequence 917 when the EAP server detects an error in a channel binding 918 procedure. The first two messages constitute the standard EAP 919 identity exchange and are optional. In this case, message 7) and 920 8) MUST constitute an INFORMATIONAL exchange. 922 1) A <-- B: EAP-Request/Identity 924 2) A --> B: EAP-Response/Identity(Id) 926 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 928 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 929 HDR(A,B), SAr1, KEr, Nr, [CERTREQ,] 930 N(CALLED_STATION_ID*)) 932 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 933 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH, 934 N(CALLED_STATION_ID), 935 N(CALLING_STATION_ID*), 936 N(NAS_PORT_TYPE*)}) 938 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 939 HDR(A,B), SK {IDr, [CERT,] AUTH, 940 N(CALLING_STATION_ID), 941 N(NAS_PORT_TYPE)}) 943 7) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 944 HDR(A,B), SK {N(INVALID_CALLING_STATION_ID)}) 946 8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 947 HDR(A,B), SK {}) 949 9) A <-- B: EAP-Failure 951 Figure 13: EAP-IKEv2 with channel binding error 952 (detected by EAP server) 954 Figure 14 shows an example of EAP-IKEv2 authentication sequence 955 when the EAP peer detects an error in a channel binding procedure. 956 The first two messages constitute the standard EAP identity 957 exchange and are optional. 959 1) A <-- B: EAP-Request/Identity 961 2) A --> B: EAP-Response/Identity(Id) 963 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 965 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 966 HDR(A,B), SAr1, KEr, Nr, [CERTREQ,] 967 N(CALLED_STATION_ID*)) 969 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 970 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH, 971 N(CALLED_STATION_ID), 972 N(CALLING_STATION_ID*), 973 N(NAS_PORT_TYPE*)}) 975 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 976 HDR(A,B), SK {N(INVALID_CALLED_STATION_ID)}) 978 7) A <-- B: EAP-Failure 980 Figure 14: EAP-IKEv2 with channel binding error 981 (detected by EAP peer) 983 Figure 15 shows an example of EAP-IKEv2 fast reconnection sequence 984 with a successful channel binding procedure. The first two 985 messages constitute the standard EAP identity exchange and are 986 optional. 988 1) A <-- B: EAP-Request/Identity 990 2) A --> B: EAP-Response/Identity(Id) 992 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,] 993 N(CALLING_STATION_ID*), 994 N(NAS_PORT_TYPE*)}) 996 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {SA, Nr, [KEr,] 997 N(CALLED_STATION_ID*), 998 N(CALLING_STATION_ID), 999 N(NAS_PORT_TYPE)}) 1001 5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 1002 HDR(A,B), SK {N(CALLED_STATION_ID)}) 1004 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,B), SK {}) 1006 7) A <-- B: EAP-Success 1008 Figure 15: Fast reconnect with channel binding error 1009 (fast reconnect) 1011 Figure 16 shows an example of EAP-IKEv2 fast reconnect sequence 1012 when the EAP server detects an error in a channel binding 1013 procedure. The first two messages constitute the standard EAP 1014 identity exchange and are optional. In this case, message 7) and 1015 8) MUST constitute an INFORMATIONAL exchange. 1017 1) A <-- B: EAP-Request/Identity 1019 2) A --> B: EAP-Response/Identity(Id) 1021 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,] 1022 N(CALLING_STATION_ID*), 1023 N(NAS_PORT_TYPE*)}) 1025 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {SA, Nr, [KEr,] 1026 N(CALLED_STATION_ID*), 1027 N(CALLING_STATION_ID), 1028 N(NAS_PORT_TYPE)}) 1030 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 1031 HDR(A,B), SK {N(INVALID_CALLING_STATION_ID)}) 1033 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 1034 HDR(A,B), SK {}) 1036 7) A <-- B: EAP-Failure 1038 Figure 16: Fast reconnect with channel binding error 1039 (detected by EAP server) 1041 Figure 17 shows an example of EAP-IKEv2 fast reconnect sequence 1042 when the EAP peer detects an error in a channel binding procedure. 1043 The first two messages constitute the standard EAP identity 1044 exchange and are optional. 1046 1) A <-- B: EAP-Request/Identity 1048 2) A --> B: EAP-Response/Identity(Id) 1050 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,] 1051 N(CALLING_STATION_ID*), 1052 N(NAS_PORT_TYPE*)}) 1054 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {SA, Nr, [KEr,] 1055 N(CALLED_STATION_ID*), 1056 N(CALLING_STATION_ID), 1057 N(NAS_PORT_TYPE)}) 1059 5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 1060 HDR(A,B), SK {N(CALLED_STATION_ID)}) 1062 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 1063 HDR(A,B), SK {N(INVALID_CALLED_STATION_ID)}) 1065 7) A <-- B: EAP-Failure 1067 Figure 17: Fast reconnect with channel binding error 1068 (detected by EAP peer) 1070 13. Security Considerations 1072 13.1 General Considerations 1074 The security of EAP-IKEv2 is intentionally based on IKEv2 [Kau04]. 1075 Therefore, the security claims of EAP-IKEv2 are derived mainly 1076 from the security offered by the supported features of IKEv2. 1078 IKEv2 provides an improvement over IKEv1 [RFC2409] as described 1079 in Appendix A of [Kau04]. Important for this document are the 1080 reduced number of initial exchanges, decreased latency of the 1081 initial exchange, and some other fixes (e.g., hash problem). IKEv2 1082 is a cryptographically sound protocol that has received a 1083 considerable amount of expert review and that benefits from a long 1084 practical experience with IKE. 1086 In addition, IKEv2 provides authentication and key exchange 1087 capabilities which allow an entity to use symmetric as well as 1088 asymmetric authentication within a single protocol. Such 1089 flexibility is considered important for an EAP method and is 1090 provided by EAP-IKEv2. 1092 [Per03] provides a good tutorial for IKEv2 design decisions. 1094 13.2 Security Claims 1096 Authentication mechanism: 1097 Mutual authentication is supported based on either pre-shared 1098 symmetric keys or public/private key pairs. Besides certificates, 1099 plain public keys can be used. It is possible to use different types 1100 of authentication for the different directions within one 1101 authentication exchange. An example is the server using 1102 certificate-based authentication and the client using pre-shared 1103 secrets. 1105 EAP-IKEv2 changes the roles regarding password usage: The EAP 1106 server acts as initiator, the remote peer as responder. This 1107 results in an exchange which protects user authentication (based 1108 on a shared secret derived from a user password) to the network 1109 through an already network (initiator-) authenticated, secured 1110 IKEv2 SA (see e.g. message 6 of Figure 1). This prevents an attacker 1111 from launching password-guessing attacks on the peer-generated 1112 AUTH value. 1113 Therefore, dictionary attacks are not applicable in the context 1114 of EAP-IKEv2 in the case the EAP peer uses a password-derived 1115 shared secret. 1117 Man-in-the-middle attacks discovered in the context of tunneled 1118 authentication protocols (see [AN03] and [PL+03]) are not 1119 applicable to EAP-IKEv2 as the extended authentication feature of 1120 IKEv2 is not supported by EAP-IKEv2. Hence, the cryptographic 1121 binding claim is not applicable. 1123 Ciphersuite negotiation is supported as specified in IKEv2 for 1124 IKE-SAs. The negotiation for IPsec (Child) SAs is not supported, 1125 as such SAs are not generated by EAP-IKEv2. 1127 Protected result indication as described in section 7.16 of 1128 [RFC3748] is optionally provided by EAP-IKEv2. In message 5 of 1129 figure 1 (full successful authentication) the EAP server 1130 authenticates to the client. Message 6 authenticates the client 1131 to the server, and the client by authenticating the server and by 1132 sending message 6 expresses that it is willing to accept access. 1133 The client, however, does not get a protected result indication 1134 from the server in this case. An attacker could potentially forge 1135 an EAP success/failure message which could result in DoS to the 1136 client. In some situations, synchronization may be achieved by 1137 lower layer indications. 1139 Protected result indication is optionally provided as specified 1140 in section 12. 1141 If this mechanism is not used, the recommended behavior for the 1142 client is to assume the correct establishment of a new IKE-SA after 1143 sending message 6, independent of the receipt of an EAP 1144 success/failure. In case of unsuccessful authentication, the 1145 server would answer with a notification (which, in case of the fast 1146 reconnect exchange, would be protected by the old IKE-SA). In case 1147 of a lost message 6, the server would retransmit message 5, 1148 indicating the message loss to the client. 1149 The client implementation can minimize potential DoS risks due to 1150 missing protected result indications by assuming the correct 1151 establishment of a new IKE-SA after not receiving one of the above 1152 messages within a certain time window after sending message 6. In 1153 the fast reconnect case, the client needs to hold both the old and 1154 the new IKE-SA in parallel during this time window. 1156 Session independence is optionally provided if the fast reconnect 1157 exchange includes the KE payloads (new Diffie-Hellman) as 1158 described in section 11, Figure 9. 1160 Security claims: 1161 Ciphersuite negotiation: Yes 1162 Mutual authentication: Yes 1163 Integrity protection: Yes 1164 Replay protection: Yes 1165 Confidentiality: Yes 1166 Key derivation: Yes 1167 Key strength: Variable 1168 Dictionary attack prot.: Yes 1169 Fast reconnect: Yes 1170 Crypt. binding: N/A 1171 Protected result ind.: yes 1172 Session independence: yes 1173 Fragmentation: Yes 1174 Channel binding: Yes 1176 14. IANA Considerations 1178 This section provides guidance to the IANA regarding registration 1179 of values related to the EAP-IKEv2 protocol, in accordance with 1180 [RFC2434]. 1182 The following terms are used here with the meanings defined in 1183 [RFC2434]: "name space" and "registration". 1185 The following policies are used here with the meanings defined in 1186 [RFC2434]: "Expert Review" and "Specification Required". 1188 This document introduces one new Internet Assigned Numbers 1189 Authority (IANA) consideration: 1191 - It requires IANA to allocate an EAP-Request/Response Type for 1192 EAP-IKEv2. 1194 1196 15. Normative References 1198 [RFC3748] Aboba, Blunk, Carlson and Levkowetz: "Extensible 1199 Authentication Protocol (EAP)", RFC 3748, June 2004. 1201 [Kau04] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol", 1202 internet draft, Internet Engineering Task Force, September 2004. 1203 Work in progress. 1205 [RFC2119] S. Bradner: "Key words for use in RFCs to Indicate 1206 Requirement Levels", RFC 2119, Internet Engineering Task Force, 1207 March 1997. 1209 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 1210 an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1211 1998. 1213 16. Informative References 1215 [AN03] N. Asokan, V. Niemi, and K. Nyberg: "Man-in-the-middle in 1216 tunnelled authentication", In the Proceedings of the 11th 1217 International Workshop on Security Protocols, Cambridge, UK, 1218 April 2003. To be published in the Springer-Verlag LNCS series. 1220 [PL+03] J. Puthenkulam, V. Lortz, A. Palekar, D. Simon, and B. 1221 Aboba, "The compound authentication binding problem," internet 1222 draft, Internet Engineering Task Force, October 2003. Expired. 1224 [RFC2409] D. Harkins, D. Carrel: "The Internet Key Exchange 1225 (IKE)", RFC 2409, November 1998. 1227 [Per03] R. Perlman: "Understanding IKEv2: Tutorial, and rationale 1228 for decisions", internet draft, Internet Engineering Task Force, 1229 2003. Expired. 1231 [AS+05] B. Aboba, D. Simon, J. Arkko, P. Eronen and H. Levkowetz: 1232 "Extensible Authentication Protocol (EAP) Key Management 1233 Framework", internet draft, Internet Engineering Task Force, 1234 April, 2005. Work in progress. 1236 [PS+03] A. Palekar, D. Simon, G. Zorn, H. Zhou and S. Josefsson: 1237 "Protected EAP Protocol (PEAP)", internet draft, Internet 1238 Engineering Task Force, July 2004. Work in progress. 1240 Acknowledgments 1242 We would like to thank Bernard Aboba, Jari Arkko, Guenther Horn, 1243 Paoulo Pagliusi and John Vollbrecht for their comments to this 1244 draft. 1246 Additionally we would like to thank members of the PANA design team 1247 (namely D. Forsberg and A. Yegin) for their comments and input to 1248 the initial version of the draft. 1250 Finally we would like to thank the members of the EAP keying design 1251 team for their discussion in the area of the EAP Key Management 1252 Framework. 1254 Author's Addresses 1256 Hannes Tschofenig 1257 Siemens AG 1258 Otto-Hahn-Ring 6 1259 81739 Munich 1260 Germany 1261 EMail: Hannes.Tschofenig@siemens.com 1263 Dirk Kroeselberg 1264 Siemens AG 1265 Otto-Hahn-Ring 6 1266 81739 Munich 1267 Germany 1268 EMail: Dirk.Kroeselberg@siemens.com 1270 Yoshihiro Ohba 1271 Toshiba America Research, Inc. 1272 1 Telcordia Drive 1273 Piscataway, NJ 08854 1274 USA 1276 Phone: +1 732 699 5305 1277 EMail: yohba@tari.toshiba.com 1279 Florent Bersani 1280 France Telecom R&D 1281 38, rue du General Leclerc 1282 Issy-Les-Moulineaux 92794 Cedex 9 1283 FR 1285 EMail: florent.bersani@francetelecom.com 1287 Intellectual Property Statement 1289 The IETF takes no position regarding the validity or scope of any 1290 Intellectual Property Rights or other rights that might be claimed 1291 to pertain to the implementation or use of the technology described 1292 in this document or the extent to which any license under such 1293 rights might or might not be available; nor does it represent that 1294 it has made any independent effort to identify any such rights. 1295 Information on the procedures with respect to rights in RFC 1296 documents can be found in BCP 78 and BCP 79. 1298 Copies of IPR disclosures made to the IETF Secretariat and any 1299 assurances of licenses to be made available, or the result of an 1300 attempt made to obtain a general license or permission for the use 1301 of such proprietary rights by implementers or users of this 1302 specification can be obtained from the IETF on-line IPR repository 1303 at http://www.ietf.org/ipr. 1305 The IETF invites any interested party to bring to its attention 1306 any copyrights, patents or patent applications, or other 1307 proprietary rights that may cover technology that may be required 1308 to implement this standard. Please address the information to the 1309 IETF at ietf-ipr@ietf.org. 1311 Disclaimer of Validity 1313 This document and the information contained herein are provided 1314 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1315 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1316 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1317 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1318 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1319 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1320 PARTICULAR PURPOSE. 1322 Copyright Statement 1324 Copyright (C) The Internet Society (2005). This document is 1325 subject to the rights, licenses and restrictions contained in BCP 1326 78, and except as set forth therein, the authors retain all their 1327 rights. 1329 Acknowledgment 1331 Funding for the RFC Editor function is currently provided by the 1332 Internet Society.