idnits 2.17.1 draft-tschofenig-eap-ikev2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 (October 2003) is 7500 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 258, but not defined ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. 'Kau03' -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP 3 Internet Draft H. Tschofenig 4 D. Kroeselberg 5 Siemens 6 Y. Ohba 7 Toshiba 8 Document: draft-tschofenig-eap-ikev2-02.txt 9 Expires: April 2002 October 2003 11 EAP IKEv2 Method 12 (EAP-IKEv2) 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 EAP-IKEv2 is an EAP method which reuses the cryptography and the 38 payloads of IKEv2, creating a flexible EAP method that supports both 39 symmetric and asymmetric authentication. Furthermore protection of 40 legacy authentication mechanisms is supported. This EAP method 41 offers the security benefits of IKEv2 without the goal of 42 establishing IPsec security associations. 44 Table of Contents 46 1. Introduction..................................................2 47 2. IKEv2 and EAP-IKEv2 Overview..................................3 48 3. Terminology...................................................4 49 4. Protocol overview.............................................4 50 5. Identities used in EAP-IKEv2..................................7 51 6. Packet Format.................................................9 52 7. Retransmission...............................................10 53 8. Key derivation...............................................10 54 9. Error Handling...............................................11 55 10. Security Considerations.....................................13 56 11. Open Issues.................................................13 57 12. Normative References........................................13 58 13. Informative References......................................14 59 Acknowledgments.................................................14 60 Author's Addresses..............................................15 61 Full Copyright Statement........................................15 63 1. Introduction 65 This document specifies the EAP-IKEv2 authentication method. EAP- 66 IKEv2 is a flexible EAP method which makes the IKEv2 protocol�s 67 features available for scenarios using EAP-based authentication. 68 The main advantage of EAP-IKEv2 is that it does not define a new 69 cryptographic protocol, but re-uses the IKEv2 authentication 70 protocol, and thereby provides strong, well-analyzed, cryptographic 71 properties as well as broad flexibility. This includes the support 72 of authentication methods and configuration payloads for remote 73 access scenarios. 75 EAP-IKEv2 can be used directly to mutually authenticate EAP peers. 76 This may be based on either symmetric methods using pre-shared keys, 77 or on asymmetric methods based on public/private key pairs, 78 Certificates and CRLs. In addition, EAP-IKEv2 supports two-phased 79 authentication schemes by establishing a server-authenticated secure 80 tunnel, and by subsequently protecting an EAP authentication 81 allowing for legacy client authentication methods. Hence, EAP-IKEv2 82 provides a secure EAP tunneling method. 84 A non-goal of EAP-IKEv2 (and basically the major difference to plain 85 IKEv2) is the establishment of IPsec security associations, as this 86 would not make much sense in the standard AAA three-party scenario, 87 consisting of an EAP peer, an authenticator (NAS) and a back-end 88 authentication server terminating EAP. IPsec SA establishment may be 89 required locally (i.e., between the EAP peer and some access 90 server). However, SA establishment within an EAP method would only 91 provide SAs between the EAP peer and the back-end authentication 92 server. Other approaches as e.g., those of the IETF PANA group are 93 considered more appropriate in this case. 95 2. IKEv2 and EAP-IKEv2 Overview 97 IKEv2 [Kau03] is a protocol which consists of two exchanges: 99 (1) an authentication and key exchange protocol which establishes an 100 IKE-SA. 102 (2) messages and payloads which focus on the negotiation of 103 parameters in order to establish IPsec security associations (i.e., 104 Child-SAs). These payloads contain algorithm parameters and traffic 105 selector fields. 107 In addition to the above-mentioned parts IKEv2 also includes some 108 payloads and messages which allow configuration parameters to be 109 exchanged primarily for remote access scenarios. 111 The EAP-IKEv2 method defined by this document uses the IKEv2 112 payloads and messages used for the initial IKEv2 exchange which 113 establishes an IKE-SA. 115 IKEv2 provides an improvement over IKEv1 [RFC2409] as described in 116 Appendix A of [Kau03]. Important for this document are the reduced 117 number of initial exchanges, support of legacy authentication, 118 decreased latency of the initial exchange, optional Denial-of- 119 Service (DoS) protection capability and some other fixes (e.g., hash 120 problem). IKEv2 is a cryptographically sound protocol that has 121 received a considerable amount of expert review and that benefits 122 from a long practical experience with IKE. 123 The goal of EAP-IKEv2 is to inherit these properties within an 124 efficient, secure EAP method. 126 In addition, IKEv2 provides authentication and key exchange 127 capabilities which allow an entity to use symmetric as well as 128 asymmetric authentication within a single protocol. Such flexibility 129 is considered important for an EAP method and is provided by EAP- 130 IKEv2. 132 [Per03] provides a good tutorial for IKEv2 design decisions. 134 EAP-IKEv2 therefore provides 136 a) well-known IKEv2 symmetric/asymmetric authentication and 137 b) a new EAP tunneling method. 139 EAP-IKEv2 provides a secure fragmentation mechanism in which 140 integrity protection is performed for each fragment of an IKEv2 141 message. 143 3. Terminology 145 This document does not introduce new terms other than those defined 146 in [RFC2284] or in [Kau03]. 148 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 149 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 150 document, are to be interpreted as described in [RFC2119]. 152 4. Protocol overview 154 This section provides some overview over EAP-IKEv2 message 155 exchanges. Note that some payloads are omitted (such as SAi2 and 156 SAr2) which are mandatory for IKEv2 but are not required in EAP- 157 IKEv2 since they are used to establish an IPsec SA. 159 IKEv2 uses the same protocol message exchanges for both symmetric 160 and asymmetric authentication. The difference lies only in the 161 computation of the AUTH payload. See Section 2.15 of [Kau03] for 162 more information about the details of the AUTH payload computation. 163 It is even possible to combine symmetric (e.g., from the client to 164 the server) with asymmetric authentication (e.g., from the server to 165 the client) in a single protocol exchange. Figure 1 depicts such a 166 protocol exchange. 168 Message exchanges are reused from [Kau03], and are adapted. Since 169 this document does not describe frameworks or particular 170 architectures the message exchange takes place between two parties - 171 between the Initiator (I) and the Responder (R). In context of EAP 172 the Initiator is often called Authenticating Peer whereas the 173 Responder is referred as Authenticator. 175 The first message flow shows EAP-IKEv2 without the optional DoS 176 protection exchanges. The core EAP-IKEv2 exchange (message (4) - 177 (7)) consists of four messages (two round trips)_only. The first two 178 messages constitute the standard EAP identity exchange and are not 179 mandatory if the EAP server is known. 181 1) I <-- R: EAP-Request/Identity 183 2) I --> R: EAP-Response/Identity(Id) 185 3) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start) 186 4) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 188 5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 189 HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) 191 6) I --> R: EAP-Response/EAP-Type=EAP-IKEv2( 192 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) 194 7) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 195 HDR(A,B), SK {IDr, [CERT,] AUTH}) 197 8) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish) 199 9) I <-- R: EAP-Success 201 Figure 1: EAP-IKEv2 message flow 203 The subsequent message flow shows EAP-IKEv2 with DoS protection 204 enabled. The IKEv2 DoS protection mechanism uses cookies and keeps 205 the responder stateless when it receives the first IKEv2 message, 206 preventing it from performing heavy cryptographic operations based 207 on this first incoming message. As a consequence of DoS protection 208 an additional round trip (message (5) and (6)) is required. 210 1) I <-- R: EAP-Request/Identity 212 2) I --> R: EAP-Response/Identity(Id) 214 3) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start) 216 4) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 218 5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 219 HDR(A,0), N(COOKIE-REQUIRED), N(COOKIE)) 221 6) I --> R: EAP-Response/EAP-Type=EAP-IKEv2( 222 HDR(A,0), N(COOKIE), SAi1, KEi, Ni) 224 7) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 225 HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) 227 8) I --> R: EAP-Response/EAP-Type=EAP-IKEv2( 228 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) 230 9) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 231 HDR(A,B), SK {IDr, [CERT,] AUTH}) 233 10) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish) 235 11) I <-- R: EAP-Success 237 Figure 2: EAP-IKEv2 with Cookies 239 The Secure Legacy Authentication (SLA) EAP message exchange shown in 240 Figure 3 is taken from Section 2.16 of [Kau03] and adapted. It 241 provides an example of a successful inner EAP exchange using the 242 EAP-SIM Authentication method [HS03], which is secured by the IKE- 243 SA. 245 Implementations MUST ensure that infinite recursions of EAP and EAP- 246 IKEv2 exchanges are not allowed. (TBD: some limit necessary) 248 I <-- R: EAP-Request/Identity 250 I --> R: EAP-Response/Identity(Id) 252 I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start) 254 I --> R: EAP-Response/EAP-Type=EAP-IKEv2( 255 HDR, SAi1, KEi, Ni) 257 I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( 258 HDR, SAr1, KEr, Nr, [CERTREQ]) 260 I --> R: EAP-Response/EAP-Type=EAP-IKEv2( 261 HDR, SK {IDi, [CERTREQ,] [IDr,]}) 263 I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR, 264 SK {IDr, [CERT,] AUTH, EAP(EAP-Request /SIM 265 /Start(AT_VERSION_LIST))}) 267 I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP- 268 Response/SIM/Start(AT_NONCE_MT, AT_SELECTED_VERSION)), 269 [AUTH]}) 271 I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP- 272 Request/SIM/Challenge(AT_RAND, AT_MAC)), [AUTH]}) 274 I --> R: EAP-Response/EAP-Type=EAP-IKEv2( 275 HDR, SK {EAP(EAP-Response/SIM/Challenge(AT_MAC) ), [AUTH]}) 277 I <-- R: EAP-Success 279 Figure 3: EAP-IKEv2 SLA with EAP-SIM Authentication 281 Please note that the message flow in Figure 3 does not include an 282 EAP-Request/Identity and the corresponding EAP-Response/Identity 283 message inside the EAP-IKEv2 tunnel. Although it would be possible 284 to perform such an exchange IKEv2 suggests using the IDi payload for 285 this purpose. As a consequence the initiators identity is not 286 protected against active attacks. 288 Since the goal of this EAP method is not to establish an IPsec SA 289 some payloads used in IKEv2 are omitted. In particularly the 290 following messages and payloads are not required: 292 - Traffic Selectors 293 - IPsec SA negotiation payloads 294 (e.g., CREATE_CHILD_SA exchange or SAx2 payloads) 295 - ECN Notification 296 - Port handling 297 - NAT traversal 299 Some of these messages and payloads are optional in IKEv2. 300 In general it does not make sense to directly negotiate IPsec SAs 301 with EAP-IKEv2, as such SAs were unlikely to be used between the EAP 302 endpoints. 304 IKEv2 also provides functionality for the initiator to request 305 address information from the responder as described in Section 2.19 306 of [Kau03]. Using this functionality it is possible for an end host 307 to securely request address configuration information from the local 308 network. 310 5. Identities used in EAP-IKEv2 312 A number of different places allow to convey identity information in 313 IKEv2, when combined with EAP. This section describes their function 314 within the different exchanges of EAP-IKEv2. Note that EAP-IKEv2 315 does not introduce more identities than any other tunneling 316 approach. Figure 4 shows which identities are used during the 317 individual phases of the protocol. 319 +-------+ +-------------+ +---------+ +--------+ 320 |Client | |Front-End | |Local AAA| |Home AAA| 321 | | |Authenticator| |Server | |Server | 322 +-------+ +-------------+ +---------+ +--------+ 324 EAP/Identity-Request 325 <--------------------- 326 (a) EAP/Identity-Response 327 ----------------------------------> 328 Tunnel-Establishment 329 (b) (Identities of IKEv2 are used) 330 Server (Network) Authentication 331 <---------------------------------- 332 ... 333 ----------------------------------> 335 +---------------------------------+ 336 | Secure Tunnel | 337 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 338 | Secure Legacy Authentication | 339 | protected with the IKE-SA | 340 (c) | (Identities of the tunneled | 341 | EAP method are used) | 342 | Client Authentication | 343 |---------------------------------+----------------> 344 |<--------------------------------+----------------- 345 +---------------------------------+ 347 Figure 4: Identities used in EAP-IKEv2 349 a) The first part of the (outer) EAP message exchange provides 350 information about the identities of the EAP endpoints. This message 351 exchange mainly is an identity request/response. This exchange is 352 optional if the EAP server is known already or can be learned by 353 other means. 355 b) The identities used within EAP-IKEv2 for both the initiator and 356 the responder. The initiator identity is often associated with a 357 user identity such as a fully-qualified RFC 822 email address. The 358 identity of the responder might be a FQDN. The identity is of 359 importance for authorization. 361 c) For secure legacy authentication an EAP message exchange is 362 protected with the established IKE-SA as shown in Figure 3. This 363 exchange again adds EAP identities. 365 This inner EAP message exchange serves the purpose of client 366 authentication. The two identities used thereby are the EAP identity 367 (i.e., a NAI) and possibly a separate identity for the selected EAP 368 method. 370 The large number of identities is required due to nesting of 371 authentication methods and due to overloaded function of the 372 identity for routing (i.e., authentication end point indication). 373 The number of recursions of EAP and IKEv2 is limited, see Section 4. 375 Hence with this additional (nested) EAP exchange the end point of 376 the EAP-IKEv2 exchange might not be the same as the end point of the 377 inner EAP exchange which is protected by the IKE-SA (which in this 378 case is not protected by the IKE-SA any more between the EAP-IKEv2 379 endpoint and the endpoint of the inner EAP exchange, but might be 380 protected by other means that are not considered in this document). 382 6. Packet Format 384 The IKEv2 payloads, which are defined in [Kau03], are embedded into 385 the Data field of the standard EAP Request/Response packets. The 386 Code, Identifier, Length and Type field is described in [RFC2284]. 387 The Type-Data field carries a one byte Flags field following the 388 IKEv2 payloads. Each IKEv2 payload starts with a header field HDR 389 (see [Kau03]). 391 The packet format is shown in Figure 5. 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Code | Identifier | Length | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type | Flags | Message Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Message Length | Data ... ~ 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Integrity Checksum Data | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 5: Packet Format 407 No additional packet formats other than those defined in [Kau03] are 408 required for this EAP method. 410 The Flags field is required to indicate Start and Finish messages 411 which are required due to the asymmetric nature of IKEv2 and the 412 Request/Response message handling of EAP. 414 Currently five bits of the eight bit flags field are defined. The 415 remaining bits are set to zero. 417 0 1 2 3 4 5 6 7 418 +-+-+-+-+-+-+-+-+ 419 |S F L M 0 0 0 0| 420 +-+-+-+-+-+-+-+-+ 422 S = EAP-IKEv2 start message 423 F = EAP-IKEv2 finish message 424 L = Length included 425 M = More fragments 426 I = Integrity Checksum Data included 428 EAP-IKEv2 messages which have neither the S nor the F flag set 429 contain regular IKEv2 message payloads inside the Data field. 431 With regard to fragmentation we follow the suggestions and 432 descriptions given in Section 2.8 of [PS+03]: The L indicates that a 433 length field is present and the M flag indicates fragments. The L 434 flag MUST be set for the first fragment and the M flag MUST be set 435 on all fragments expect for the last one. Each fragment sent must 436 subsequently be acknowledged. 438 The Message Length field is four octets long and present only if the 439 L bit is set. This field provides the total message length that is 440 being fragmented (i.e., the length of the Data field.). 442 The Integrity Checksum Data is the cryptographic checksum of the 443 entire EAP message starting with the Code field through the Data 444 field. This field presents only if the I bit is set. The field 445 immediately follows the Data field without adding any padding octet 446 before or after itself. The checksum MUST be computed for each 447 fragment (including the case where the entire IKEv2 message is 448 carried in a single fragment) by using the same key (i.e., SK_ai or 449 SK_ar) that is used for computing the checksum for the IKEv2 450 Encrypted payload in the encapsulated IKEv2 message. The Integrity 451 Checksum Data field is omitted for other packets. To minimize DoS 452 attacks on fragmented packets, messages that are not protected 453 SHOULD NOT be fragmented. Note that IKE_SA_INIT messages are the 454 only ones that are not encrypted or integrity protected, however, 455 such messages are not likely to be fragmented since they do not 456 carry certificates. 458 The EAP Type for this EAP method is . 460 7. Retransmission 462 Since EAP authenticators support a timer-based retransmission 463 mechanism for EAP Requests and EAP peers retransmit the last valid 464 EAP Response when receiving a duplicate EAP Request message, IKEv2 465 messages MUST NOT be retransmitted based on timers, when used as EAP 466 authentication method. 468 8. Key derivation 469 The EAP-IKEv2 method described in this document generates session 470 keys. These session keys are used to establish an IKE-SA which 471 provides protection of subsequent EAP-IKEv2 payloads. To export a 472 session key as part of the EAP keying framework [AS+03] it is 473 required to derive additional session keys for usage with EAP (i.e., 474 MSK, EMSK and IV). It is good cryptographic security practice to use 475 different keys for different "applications". Hence we suggest 476 reusing the key derivation function suggested in Section 2.17 of 477 [Kau03] to create keying material KEYMAT. 479 The key derivation function defined is KEYMAT = prf+(SK_d, Ni | Nr), 480 where Ni and Nr are the Nonces from the IKE_SA_INIT exchange. 482 According to [AS+03] the keying material of MSK, EMSK and IV have to 483 be at minimum 64, 64 and 64 octets long. 485 The produced keying material for MSK, EMSK and IV MUST be twice the 486 minimum size (i.e., 128 octets). 488 9. Error Handling 490 As described in the IKEv2 specification, there are many kinds of 491 errors that can occur during IKE processing (i.e., processing the 492 Data field of EAP-IKEv2 Request and Response messages) and detailed 493 processing rules. EAP-IKEv2 follows the error handling rules 494 specified in the IKEv2 specification for errors on the Data field of 495 EAP-IKEv2 messages, with the following additional rules: 497 o For an IKEv2 error that triggers an initiation of an IKEv2 498 exchange (i.e., an INFORMATIONAL exchange), an EAP-IKEv2 message 499 that contains the IKEv2 request that is generated for the IKEv2 500 exchange MUST be sent to the peering entity. In this case, the 501 EAP message that caused the IKEv2 error MUST be treated as a 502 valid EAP message. 504 o For an IKEv2 error for which the IKEv2 message that caused the 505 error is discarded without triggering an initiation of an IKEv2 506 exchange, the EAP message that carries the the erroneous IKEv2 507 message MUST be treated as an invalid EAP message and discarded 508 as if it were not received at EAP layer. 510 For an error occurred outside the Data field of EAP-IKEv2 messages, 511 including defragmentation failures, integrity check failures, errors 512 in Flag and Message Length fields, the EAP message that caused the 513 error MUST be treated as an invalid EAP message and discarded as if 514 it were not received at EAP layer. 516 When the EAP-IKEv2 method runs on a backend EAP server, an 517 outstanding EAP Request is not retransmitted based on timer and thus 518 there is a possibility of EAP conversation stall when the EAP server 519 receives an invalid EAP Response. To avoid this, the EAP server MAY 520 retransmit the outstanding EAP Request in response to an invalid EAP 521 Response. Alternatively, the EAP server MAY send a new EAP Request 522 in response to an invalid EAP Response with assigning a new 523 Identifier and putting the last transmitted IKEv2 message in the 524 Data field. 526 10. Fast Resume 528 TLS provides the capability of resuming a session. This offers 529 primarily performance improvement for a new authentication and key 530 exchange protocol run. In order to resume a session two approaches 531 can be taken: 533 a) Generic approach 534 b) Method-specific approach 536 The idea of approach (a) is to 537 - force each EAP method to create an EAP SA. This SA is kept at the 538 EAP peer and the EAP server and is used for subsequent exchanges. 539 - built this functionality into EAP itself. 541 Approach (b) is already used by existing methods using TLS. Choosing 542 (b) does not require any changes to EAP itself since each EAP method 543 has to implement its own mechanism. 545 So far it has not been decided which approach should be suggested 546 for EAP. In any case it seems that a generic approach contains some 547 difficulties since EAP methods need to negotiate the necessary 548 parameters with are required to build the EAP SA (lifetime, 549 algorithms, identifiers, etc.). Furthermore, it is necessary to 550 cover error cases which happen if the wrong AAA server is selected 551 (due to failover or load balancing) and the EAP SA is not found. 553 For both cases it is necessary to establish to keep some state 554 information. An additional motivation for establishing state is the 555 ability to provide passive user identity confidentiality as 556 exercised in [AH03]. Subsequent protocol exchanges use a pseudonym 557 instead of the long-term user identity. 559 Additionally it is necessary to list some requirements for 560 establishing an EAP SA and for running a fast resume. For example, 561 does the fast resume exchange need to provide key agreement or key 562 transport functionality? 563 Once the above-raised issues have been addressed in the EAP working 564 group a solution will be added to EAP-IKEv2. 566 11. Security Considerations 568 The security of the proposed EAP method is intentionally based on 569 IKEv2 [Kau03]. Man-in-the-middle attacks discovered in the context 570 of tunneled authentication protocols (see [AN03] and [PL+03]) are 571 applicable to IKEv2 if legacy authentication with EAP [RFC2284] is 572 used. To counter this threat IKEv2 provides a compound 573 authentication by including the EAP provided session key inside the 574 AUTH payload. 576 12. Open Issues 578 The following issues are still under consideration: 580 - Reducing the number of messages 582 The message flows given in this document finish with an EAP-Success 583 message. In some cases it might be possible to skip these messages. 584 Furthermore it is possible to omit the first exchange if the 585 identity can be learned by other means. 587 - Notifications 589 IKEv2 provides the concept of notifications to exchange messages at 590 any time (e.g., dead peer detection). It remains for further study 591 which of these messages are required for this EAP method. 593 - Roles of initiator and responder 595 Figure 4 shows the initiator starting the EAP-IKEv2 exchange. 596 However, there is also the possibility to have the EAP server to 597 start the exchange which saves roundtrips. It remains for further 598 study to analyze the resulting security properties. 600 13. Normative References 602 [RFC2284] L. Blunk and J. Vollbrecht: "PPP Extensible Authentication 603 Protocol (EAP)", RFC 2284, March 1998. 605 [Kau03] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol", 606 internet draft, Internet Engineering Task Force, October 2003. Work 607 in progress. 609 [RFC2119] S. Bradner: "Key words for use in RFCs to Indicate 610 Requirement Levels", RFC 2119, Internet Engineering Task Force, 611 March 1997. 613 14. Informative References 615 [AN03] N. Asokan, V. Niemi, and K. Nyberg: "Man-in-the-middle in 616 tunnelled authentication", In the Proceedings of the 11th 617 International Workshop on Security Protocols, Cambridge, UK, April 618 2003. To be published in the Springer-Verlag LNCS series. 620 [PL+03] J. Puthenkulam, V. Lortz, A. Palekar, D. Simon, and B. 621 Aboba, "The compound authentication binding problem," internet 622 draft, Internet Engineering Task Force, 2003. Work in progress. 624 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 625 (IKE)", RFC 2409, November 1998. 627 [Per03] R. Perlman: "Understanding IKEv2: Tutorial, and rationale 628 for decisions", internet draft, Internet Engineering Task Force, 629 2003. Work in progress. 631 [AS+03] B. Aboba, D. Simon and J. Arkko: " EAP Key Management 632 Framework", internet draft, Internet Engineering Task Force, 633 October, 2003. Work in progress. 635 [HS03] H. Haverinen, J. Salowey: "EAP SIM Authentication", internet 636 draft, Internet Engineering Task Force, 2003. Work in progress. 638 [PS+03] A. Palekar, D. Simon, G. Zorn and S. Josefsson: "Protected 639 EAP Protocol (PEAP)", internet draft, Internet Engineering Task 640 Force, March 2003. Work in progress. 642 [AH03] J. Arkko and H. Haverinen: "EAP AKA Authentication", internet 643 draft, Internet Engineering Task Force, June 2003. Work in 644 progress. 646 Acknowledgments 648 We would like to thank Bernard Aboba, Jari Arkko, Paoulo Pagliusi 649 and John Vollbrecht for their comments to this draft. 651 Additionally we would like to thank members of the PANA design team 652 (namely D. Forsberg and A. Yegin) for their comments and input to 653 the initial version of the draft. 655 Finally we would like to thank the members of the EAP keying design 656 team for their discussion in the area of the EAP Key Management 657 Framework. 659 Author's Addresses 661 Hannes Tschofenig 662 Siemens AG 663 Otto-Hahn-Ring 6 664 81739 Munich 665 Germany 666 EMail: Hannes.Tschofenig@siemens.com 668 Dirk Kroeselberg 669 Siemens AG 670 Otto-Hahn-Ring 6 671 81739 Munich 672 Germany 673 EMail: Dirk.Kroeselberg@siemens.com 675 Yoshihiro Ohba 676 Toshiba America Research, Inc. 677 P.O. Box 136 678 Convent Station, NJ, 07961-0136 679 USA 680 Phone: +1 973 829 5174 681 Email: yohba@tari.toshiba.com 683 Full Copyright Statement 685 Copyright (C) The Internet Society (2003). All Rights Reserved. 687 This document and translations of it may be copied and furnished to 688 others, and derivative works that comment on or otherwise explain it 689 or assist in its implementation may be prepared, copied, published 690 and distributed, in whole or in part, without restriction of any 691 kind, provided that the above copyright notice and this paragraph 692 are included on all such copies and derivative works. However, this 693 document itself may not be modified in any way, such as by removing 694 the copyright notice or references to the Internet Society or other 695 Internet organizations, except as needed for the purpose of 696 developing Internet standards in which case the procedures for 697 copyrights defined in the Internet Standards process must be 698 followed, or as required to translate it into languages other than 699 English. 701 The limited permissions granted above are perpetual and will not be 702 revoked by the Internet Society or its successors or assignees. 704 This document and the information contained herein is provided on an 705 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 706 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 707 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 708 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 709 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 711 Acknowledgement 713 Funding for the RFC Editor function is currently provided by the 714 Internet Society.