idnits 2.17.00 (12 Aug 2021) /tmp/idnits30076/draft-tschofenig-eap-ikev2-03.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: ---------------------------------------------------------------------------- == 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.) ** There are 33 instances of too long lines in the document, the longest one being 1 character 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 1047 has weird spacing: '... client is to...' == 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Since the goal of this EAP method is not to establish an IPsec SA some payloads used in IKEv2 are omitted. In particularly the following messages and payloads SHOULD not be sent: == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Consequently, mechanisms and payloads that are not supported by EAP-IKEv2 are: - ECN Notifications as specified in section 2.24 of [Kau04]. - IKE-specific port handling - NAT traversal Since the EAP server acts as the initiator of the initial IKEv2 exchange, a number of optional payloads used for realizing specific features in IKEv2 are not supported by EAP-IKEv2, as they are intended for the client side (e.g. for corporate access scenarios) in plain IKEv2. These payloads MUST not be sent by an EAP-IKEv2 entity. EAP-IKEv2 entities receiving such payloads MUST respond with the appropriate error messages as defined in [Kau04]. These payloads are: - Configuration (CFG) payloads as specified in 3.15 of [Kau04]. These payloads MUST not be sent by an EAP-IKEv2 implementation. EAP-IKEv2 entities receiving such payloads MUST ignore configuration payloads as described for minimal implementations in 3.15 of [Kau04]. - EAP payloads as specified in section 3.16 of [Kau04]. These payloads allow to run an inner EAP exchange for secure legacy authentication through an IKE SA. EAP-IKEv2 implementations acting as initiator MUST include and AUTH payload in the initial IKE_AUTH message (message 3 of the initial IKE exchange). EAP-IKEv2 implementations receiving initial IKE_AUTH messages as responders that indicate the initiator's desire to start extended authentication MUST be answered with an AUTHENTICATION_FAILED notification as the response. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: EAP-IKEv2 supports fast reconnect, i.e., a successful reconnect exchange creates a new IKE-SA by using an IKE CHILD_SA exchange. The purpose of a re-authentication exchange is to allow for efficient re-keying based on the existing IKE-SA in situations where (depending on the given security policy) no full authentication is required in case of an existing EAP-IKEv2 security context. The fast reconnect exchange uses the IKE-SA rekeying as specified in section 2.18 of [IKEv2]. However, the exchanges for EAP-IKEv2 do not use the payloads for rekeying other than IKE SAs: - The TS (traffic selector) payloads SHOULD not be sent by EAP-IKEv2 implementations. - The [N] payload (REKEY_SA notification) SHOULD not be sent by EAP-IKEv2 implementations. -- 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 (February 2004) is 6670 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 242, but not defined == Missing Reference: 'IKEv2' is mentioned on line 566, but not defined == Missing Reference: 'N' is mentioned on line 562, but not defined == Missing Reference: 'RFC2284bis' is mentioned on line 1033, but not defined ** Obsolete undefined reference: RFC 2284 (Obsoleted by RFC 3748) == Unused Reference: 'HS03' is defined on line 1154, but no explicit reference was found in the text == Unused Reference: 'AH03' is defined on line 1161, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. 'Kau04' -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 5 errors (**), 0 flaws (~~), 13 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-03.txt 9 Expires: August 2004 February 2004 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. This EAP method offers the 40 security benefits of IKEv2 authentication and key agreement without 41 the goal of establishing IPsec security associations. 43 Table of Contents 45 1. Introduction..................................................2 46 2. IKEv2 and EAP-IKEv2 Overview..................................3 47 3. Terminology...................................................4 48 4. Protocol overview.............................................4 49 5. Identities used in EAP-IKEv2..................................7 50 6. Packet Format.................................................8 51 7. Retransmission...............................................10 52 8. Key derivation...............................................10 53 9. Error Handling...............................................11 54 10. Fast Reconnect..............................................12 55 11. Channel Binding.............................................14 56 11.1 Channel Binding Procedure in Full Authentication........15 57 11.2 Channel Binding Procedure in Fast Reconnect.............16 58 11.3 Channel Binding Error Indication........................16 59 11.4 Notify Payload Types for Channel Binding................16 60 11.5 Examples................................................18 61 12. Security Considerations.....................................22 62 12.1 General Considerations..................................22 63 12.2 Security Claims.........................................22 64 13. Open Issues.................................................23 65 14. Normative References........................................24 66 15. Informative References......................................25 67 Acknowledgments.................................................25 68 Author's Addresses..............................................26 69 Full Copyright Statement........................................26 71 1. Introduction 73 This document specifies the EAP-IKEv2 authentication method. The 74 main design goal for EAP-IKEv2 is to provide a flexible and 75 efficient EAP method which makes the IKEv2 protocol's features 76 available for scenarios using EAP-based authentication. 77 The main advantage of EAP-IKEv2 is that it does not define a new 78 cryptographic protocol, but re-uses the IKEv2 authentication 79 exchanges, and thereby provides strong, well-analyzed, cryptographic 80 properties as well as broad flexibility. 82 EAP-IKEv2 provides mutual authentication between EAP peers. This may 83 be based on either symmetric methods using pre-shared keys, or on 84 asymmetric methods based on public/private key pairs, Certificates 85 and CRLs. It is possible to use different types of authentication 86 for the different directions, e.g. the server uses certificate-based 87 authentication whereas the client uses a symmetric method. 88 IKEv2 supports two-phased authentication schemes by establishing a 89 server-authenticated secure tunnel and subsequently protecting an 90 EAP authentication allowing for legacy client authentication 91 methods. EAP-IKEv2, however, does not support this optional 92 tunneling feature of IKEv2 in this version, which allows to increase 93 the EAP-IKEv2 method performance and decrease implementation 94 complexity. 96 A non-goal of EAP-IKEv2 (and basically the major difference to plain 97 IKEv2) is the establishment of IPsec security associations, as this 98 would not make much sense in the standard AAA three-party scenario, 99 consisting of an EAP peer, an authenticator (NAS) and a back-end 100 authentication server terminating EAP. IPsec SA establishment may be 101 required locally (i.e., between the EAP peer and some access 102 server). However, SA establishment within an EAP method would only 103 provide SAs between the EAP peer and the back-end authentication 104 server. Other approaches as e.g., those of the IETF PANA group are 105 considered more appropriate in this case. 107 2. IKEv2 and EAP-IKEv2 Overview 109 IKEv2 [Kau04] is a protocol which consists of two exchanges: 111 (1) an authentication and key exchange protocol which establishes an 112 IKE-SA. 114 (2) messages and payloads which focus on the negotiation of 115 parameters in order to establish IPsec security associations (i.e., 116 Child-SAs). These payloads contain algorithm parameters and traffic 117 selector fields. 119 In addition to the above-mentioned parts IKEv2 also includes some 120 payloads and messages which allow configuration parameters to be 121 exchanged primarily for remote access scenarios. 123 The EAP-IKEv2 method defined by this document uses the IKEv2 124 payloads and messages used for the initial IKEv2 exchange which 125 establishes an IKE-SA. 127 IKEv2 provides an improvement over IKEv1 [RFC2409] as described in 128 Appendix A of [Kau04]. Important for this document are the reduced 129 number of initial exchanges, decreased latency of the initial 130 exchange, and some other fixes (e.g., hash problem). IKEv2 is a 131 cryptographically sound protocol that has received a considerable 132 amount of expert review and that benefits from a long practical 133 experience with IKE. 134 The goal of EAP-IKEv2 is to inherit these properties within an 135 efficient, secure EAP method. 137 In addition, IKEv2 provides authentication and key exchange 138 capabilities which allow an entity to use symmetric as well as 139 asymmetric authentication within a single protocol. Such flexibility 140 is considered important for an EAP method and is provided by EAP- 141 IKEv2. 143 [Per03] provides a good tutorial for IKEv2 design decisions. 145 EAP-IKEv2 provides a secure fragmentation mechanism in which 146 integrity protection is performed for each fragment of an IKEv2 147 message. 149 3. Terminology 151 This document does not introduce new terms other than those defined 152 in [RFC2284] or in [Kau04]. 154 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 155 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 156 document, are to be interpreted as described in [RFC2119]. 158 4. Protocol overview 160 This section provides some overview over EAP-IKEv2 message 161 exchanges. Note that some mandatory IKEv2 payloads are omitted, or 162 profiled (such as SAi2 and SAr2), as it is not supported to 163 establish IPsec (ESP, AH) SAs in EAP-IKEv2. 165 IKEv2 uses the same protocol message exchanges for both symmetric 166 and asymmetric authentication. The difference lies only in the 167 computation of the AUTH payload. See Section 2.15 of [Kau04] for 168 more information about the details of the AUTH payload computation. 169 It is even possible to combine symmetric (e.g., from the client to 170 the server) with asymmetric authentication (e.g., from the server to 171 the client) in a single protocol exchange. Figure 1 depicts such a 172 protocol exchange. 174 Message exchanges are reused from [Kau04], and are adapted. Since 175 this document does not describe frameworks or particular 176 architectures the message exchange takes place between two parties - 177 between the Initiator (I) and the Responder (R). In the context of 178 EAP the Initiator takes the role of the EAP server and the responder 179 matches the EAP peer. 181 The first message flow shows the EAP-IKEv2 full successful exchange. 182 The core EAP-IKEv2 exchange (message (3) - (6)) consists of four 183 messages (two round trips)_only. The first two messages constitute 184 the standard EAP identity exchange and are optional; they are not 185 required in case the EAP server is known. In the exchange, the EAP 186 server (B) takes the role of the IKEv2 initiator and the EAP peer 187 (A) acts as the IKEv2 responder. 189 1) A <-- B: EAP-Request/Identity 191 2) A --> B: EAP-Response/Identity(Id) 193 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 195 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 196 HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) 198 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 199 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) 201 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 202 HDR(A,B), SK {IDr, [CERT,] AUTH}) 204 7) A <-- B: EAP-Success 206 Figure 1: EAP-IKEv2 successful message flow 208 Figure 2 shows the message flow in case the EAP peer fails to 209 authenticate the EAP server. 211 1) A <-- B: EAP-Request/Identity 213 2) A --> B: EAP-Response/Identity(Id) 215 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 217 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 218 HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) 220 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 221 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) 223 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 224 HDR(A,B), SK {N(AUTHENTICATION_FAILED)}) 226 7) A <-- B: EAP-Failure 228 Figure 2: EAP-IKEv2 with failed server authentication 230 Figure 3 shows the message flow in case the EAP server fails to 231 authenticate the EAP peer. The EAP peer MUST send an empty EAP-IKEv2 232 informational message in reply to the EAP server's error indication. 233 The EAP server answers with an EAP-Failure. 235 1) A <-- B: EAP-Request/Identity 237 2) A --> B: EAP-Response/Identity(Id) 239 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 241 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 242 HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) 244 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 245 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) 247 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 248 HDR(A,B), SK {IDr, [CERT,] AUTH}) 250 7) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 251 HDR(A,B), SK {N(AUTHENTICATION_FAILED)}) 253 8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 254 HDR(A,B), SK {}) 256 9) A <-- B: EAP-Failure 258 Figure 3: EAP-IKEv2 with failed client authentication 260 Since the goal of this EAP method is not to establish an IPsec SA 261 some payloads used in IKEv2 are omitted. In particularly the 262 following messages and payloads SHOULD not be sent: 264 - Traffic Selector (TS)payloads 265 - SA payloads that carry SA proposals for protocol IDs other than 266 1(IKE), i.e., SA payloads with protocol ID 2 (ESP) or 3 (AH) 267 - ESN (extended sequence number) transforms 269 Some of these messages and payloads are optional in IKEv2. 270 In general it does not make sense to directly negotiate IPsec SAs 271 within EAP-IKEv2, as such SAs are not required between the EAP 272 endpoints and as SAs cannot be transferred to different AAA entities 273 by standard AAA protocols. 275 Consequently, mechanisms and payloads that are not supported by EAP- 276 IKEv2 are: 277 - ECN Notifications as specified in section 2.24 of [Kau04]. 278 - IKE-specific port handling 279 - NAT traversal 280 Since the EAP server acts as the initiator of the initial IKEv2 281 exchange, a number of optional payloads used for realizing specific 282 features in IKEv2 are not supported by EAP-IKEv2, as they are 283 intended for the client side (e.g. for corporate access scenarios) 284 in plain IKEv2. These payloads MUST not be sent by an EAP-IKEv2 285 entity. EAP-IKEv2 entities receiving such payloads MUST respond with 286 the appropriate error messages as defined in [Kau04]. These payloads 287 are: 288 - Configuration (CFG) payloads as specified in 3.15 of [Kau04]. 289 These payloads MUST not be sent by an EAP-IKEv2 implementation. EAP- 290 IKEv2 entities receiving such payloads MUST ignore configuration 291 payloads as described for minimal implementations in 3.15 of 292 [Kau04]. 293 - EAP payloads as specified in section 3.16 of [Kau04]. These 294 payloads allow to run an inner EAP exchange for secure legacy 295 authentication through an IKE SA. EAP-IKEv2 implementations acting 296 as initiator MUST include and AUTH payload in the initial IKE_AUTH 297 message (message 3 of the initial IKE exchange). EAP-IKEv2 298 implementations receiving initial IKE_AUTH messages as responders 299 that indicate the initiator's desire to start extended 300 authentication MUST be answered with an AUTHENTICATION_FAILED 301 notification as the response. 303 IKEv2 provides optional functionality for additional DoS protection 304 by adding a roundtrip to the initial exchanges, see section 2.xx of 305 [Kau04]. As this is intended to protect the IKEv2 responder but in 306 EAP-IKEv2 the EAP server takes the role of the initiator, it is not 307 recommended to use this feature of IKEv2 for server protection. 309 5. Identities used in EAP-IKEv2 311 A number of different places allow to convey identity information in 312 IKEv2, when combined with EAP. This section describes their function 313 within the different exchanges of EAP-IKEv2. Note that EAP-IKEv2 314 does not introduce more identities than other non-tunneling EAP 315 methods. Figure 4 shows which identities are used during the 316 individual phases of the protocol. 318 +-------+ +-------------+ +---------+ 319 |Client | |Front-End | |AAA | 320 | | |Authenticator| |Server | 321 +-------+ +-------------+ +---------+ 323 EAP/Identity-Request 324 <--------------------- 325 (a) EAP/Identity-Response 326 ----------------------------------> 327 Tunnel-Establishment 328 (b) (Identities of IKEv2 are used) 329 Server (Network) Authentication 330 <---------------------------------- 331 ... 332 ----------------------------------> 334 Figure 4: Identities used in EAP-IKEv2 336 a) The first part of the (outer) EAP message exchange provides 337 information about the identities of the EAP endpoints. This message 338 exchange mainly is an identity request/response. This exchange is 339 optional if the EAP server is known already or can be learned by 340 other means. 342 b) Identities exchanged within EAP-IKEv2 for both the initiator and 343 the responder. The initiator identity is often associated with a 344 user identity such as a fully-qualified RFC 822 email address. The 345 identity of the responder might be a FQDN. The identity is of 346 importance for authorization. 348 For carrying identities in EAP-IKEv2, implementations MUST follow 349 the rules given in [Kau04], section 3.5, i.e., MUST be configurable 350 to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or 351 ID_KEY_ID, and MUST be configurable to accept all of these types. 352 Implementations SHOULD be capable of generating and accepting all of 353 these types. 355 6. Packet Format 357 The IKEv2 payloads, which are defined in [Kau04], are embedded into 358 the Data field of the standard EAP Request/Response packets. The 359 Code, Identifier, Length and Type field is described in [RFC2284]. 360 The Type-Data field carries a one byte Flags field following the 361 IKEv2 payloads. Each IKEv2 payload starts with a header field HDR 362 (see [Kau04]). 364 The packet format is shown in Figure 5. 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Code | Identifier | Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Type | Flags | Message Length | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Message Length | Data ... ~ 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Integrity Checksum Data | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Figure 5: Packet Format 380 No additional packet formats other than those defined in [Kau04] are 381 required for this EAP method. 383 The Flags field is used for fragmentation support. The S and F bits 384 are reserved for future use. 386 Currently five bits of the eight bit flags field are defined. The 387 remaining bits are set to zero. 389 0 1 2 3 4 5 6 7 390 +-+-+-+-+-+-+-+-+ 391 |S F L M I 0 0 0| 392 +-+-+-+-+-+-+-+-+ 394 S = (reserved) 395 F = (reserved) 396 L = Length included 397 M = More fragments 398 I = Integrity Checksum Data included 400 EAP-IKEv2 messages which have neither the S nor the F flag set 401 contain regular IKEv2 message payloads inside the Data field. 403 With regard to fragmentation we follow the suggestions and 404 descriptions given in Section 2.8 of [PS+03]: The L indicates that a 405 length field is present and the M flag indicates fragments. The L 406 flag MUST be set for the first fragment and the M flag MUST be set 407 on all fragments expect for the last one. Each fragment sent must 408 subsequently be acknowledged. 410 The Message Length field is four octets long and present only if the 411 L bit is set. This field provides the total message length that is 412 being fragmented (i.e., the length of the Data field.). 414 The Integrity Checksum Data is the cryptographic checksum of the 415 entire EAP message starting with the Code field through the Data 416 field. This field presents only if the I bit is set. The field 417 immediately follows the Data field without adding any padding octet 418 before or after itself. The checksum MUST be computed for each 419 fragment (including the case where the entire IKEv2 message is 420 carried in a single fragment) by using the same key (i.e., SK_ai or 421 SK_ar) that is used for computing the checksum for the IKEv2 422 Encrypted payload in the encapsulated IKEv2 message. The Integrity 423 Checksum Data field is omitted for other packets. To minimize DoS 424 attacks on fragmented packets, messages that are not protected 425 SHOULD NOT be fragmented. Note that IKE_SA_INIT messages are the 426 only ones that are not encrypted or integrity protected, however, 427 such messages are not likely to be fragmented since they do not 428 carry certificates. 430 The EAP Type for this EAP method is . 432 7. Retransmission 434 Since EAP authenticators support a timer-based retransmission 435 mechanism for EAP Requests and EAP peers retransmit the last valid 436 EAP Response when receiving a duplicate EAP Request message, IKEv2 437 messages MUST NOT be retransmitted based on timers, when used as EAP 438 authentication method. 440 8. Key derivation 442 The EAP-IKEv2 method described in this document generates session 443 keys. On the one hand, these session keys are used within the IKE- 444 SA, for protection of EAP-IKEv2 payloads, e.g., AUTH exchanges or 445 notifications. On the other hand, additional keys are derived to be 446 exported as part of the EAP keying framework [AS+03] (i.e., MSK, 447 EMSK and IV). It is good cryptographic security practice to use 448 different keys for different "applications". Hence we suggest 449 reusing of the key derivation function suggested in Section 2.17 of 450 [Kau04] to create keying material KEYMAT. 452 The key derivation function defined is KEYMAT = prf+(SK_d, Ni | Nr), 453 where Ni and Nr are the Nonces from the IKE_SA_INIT exchange. 455 Since the required amount of keying material is greater than the 456 size of the output of the prf algorithm the prf is used iteratively. 457 Section 2.13 of [Kau04] describes this mechanism in detail. 459 According to [AS+03] the keying material of MSK, EMSK and IV have to 460 be at minimum 64, 64 and 64 octets long. 462 The produced keying material for MSK, EMSK and IV MUST be at least 463 the minimum size (i.e., 64 octets). The keying material KEYMAT is 464 split into the MSK, EMSK and IV part. 466 Figure 6 describes the keying hierarchy of EAP-IKEv2 graphically. 467 This figure is adopted from Figure 2 of [AS+03]. 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ ---+ 470 | | ^ 471 | EAP-IKEv2 Method | | 472 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +------------------+ | | 473 | | EAP-IKEv2 Diffie-Hellmann | | EAP-IKEv2 prot. | | | 474 | | derived and authenticated key | | session specific | | | 475 | | SK_d | | state (Nonce i,j)| | | 476 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +-------------+----+ | | 477 | | | | Local | 478 | | | | to EAP | 479 | | | | Method | 480 | | | | | 481 | | | | | 482 | | | | | 483 | | | | | 484 | +---------------+-------------+ | | | 485 | | | | | | | 486 | +-+-+-+-+-++ +-+-+-+-+-++ +-+-+-+-+-++ | | 487 | | MSK | |EMSK | | IV | | | 488 | |Derivation| |Derivation| |Derivation| | | 489 | +-+-+-+-+-++ +-+-+-+-+-++ +-+-+-+-+-++ | | 490 | | | | | V 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-++-+-+-+-+-------+-+-+----+ ---+ 492 | | | ^ 493 |MSK |EMSK |IV | 494 | | | | 495 | | | Exported | 496 | | | by EAP | 497 V V V Method | 498 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | 499 | AAA Key Derivation | | Known | | 500 | Naming & Binding | |(Not Secret) | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V 503 Legend: 505 MSK = Master Session Key (512 Bit) 506 EMSK = Extended Master Session Key (512 Bit) 507 SK_d = Session key derived by EAP-IKEv2 508 IV = Initialization Vector 510 Figure 6: EAP-IKEv2 Keying Hierarchy 512 9. Error Handling 514 As described in the IKEv2 specification, there are many kinds of 515 errors that can occur during IKE processing (i.e., processing the 516 Data field of EAP-IKEv2 Request and Response messages) and detailed 517 processing rules. EAP-IKEv2 follows the error handling rules 518 specified in the IKEv2 specification for errors on the Data field of 519 EAP-IKEv2 messages, with the following additional rules: 521 For an IKEv2 error that triggers an initiation of an IKEv2 exchange 522 (i.e., an INFORMATIONAL exchange), an EAP-IKEv2 message that 523 contains the IKEv2 request that is generated for the IKEv2 exchange 524 MUST be sent to the peering entity. In this case, the EAP message 525 that caused the IKEv2 error MUST be treated as a valid EAP message. 527 For an IKEv2 error for which the IKEv2 message that caused the error 528 is discarded without triggering an initiation of an IKEv2 exchange, 529 the EAP message that carries the erroneous IKEv2 message MUST be 530 treated as an invalid EAP message and discarded as if it were not 531 received at EAP layer. 533 For an error occurred outside the Data field of EAP-IKEv2 messages, 534 including defragmentation failures, integrity check failures, errors 535 in Flag and Message Length fields, the EAP message that caused the 536 error MUST be treated as an invalid EAP message and discarded as if 537 it were not received at EAP layer. 539 When the EAP-IKEv2 method runs on a backend EAP server, an 540 outstanding EAP Request is not retransmitted based on timer and thus 541 there is a possibility of EAP conversation stall when the EAP server 542 receives an invalid EAP Response. To avoid this, the EAP server MAY 543 retransmit the outstanding EAP Request in response to an invalid EAP 544 Response. Alternatively, the EAP server MAY send a new EAP Request 545 in response to an invalid EAP Response with assigning a new 546 Identifier and putting the last transmitted IKEv2 message in the 547 Data field. 549 10. Fast Reconnect 551 EAP-IKEv2 supports fast reconnect, i.e., a successful reconnect 552 exchange creates a new IKE-SA by using an IKE CHILD_SA exchange. The 553 purpose of a re-authentication exchange is to allow for efficient 554 re-keying based on the existing IKE-SA in situations where 555 (depending on the given security policy) no full authentication is 556 required in case of an existing EAP-IKEv2 security context. 557 The fast reconnect exchange uses the IKE-SA rekeying as specified in 558 section 2.18 of [IKEv2]. However, the exchanges for EAP-IKEv2 do not 559 use the payloads for rekeying other than IKE SAs: 560 - The TS (traffic selector) payloads SHOULD not be sent by EAP-IKEv2 561 implementations. 562 - The [N] payload (REKEY_SA notification) SHOULD not be sent by EAP- 563 IKEv2 implementations. 565 During fast re-authentication, the new IKE_SA is computed as 566 specified in [IKEv2], section 2.18. The new keying material derived 567 from this IKE_SA is computed as in an initial EAP-IKEv2 568 authentication exchange. 569 Fast re-authentication allows for an optional new Diffie-Hellman 570 exchange. 572 The following exchange provides fast reconnect for EAP-IKEv2, where 573 A is the EAP peer (IKE responder) and B is the EAP server (IKE 574 initiator): 576 1) A <-- B: EAP-Request/Identity 578 2) A --> B: EAP-Response/Identity(Id) 580 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 581 HDR, SK {SA, Ni, [KEi]}) 583 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 584 HDR, SK {SA, Nr, [KEr]}) 586 5) A <-- B: EAP-Success 588 Figure 7: Fast Reconnect Message Flow 590 The first two messages constitute the standard EAP identity exchange 591 and are optional; they are not required in case the EAP server is 592 known. 594 Figure 8 shows the fast reconnect message flow in case the EAP peer 595 fails to re-authenticate the EAP server. 597 1) A <-- B: EAP-Request/Identity 599 2) A --> B: EAP-Response/Identity(Id) 601 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2 602 (HDR, SK {SA, Ni, [KEi]}) 604 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 605 HDR, SK {N(AUTHENTICATION_FAILED)}) 607 5) A <-- B: EAP-Failure 609 Figure 8: EAP-IKEv2 fast reconnect 610 (server authentication failed) 612 Figure 9 shows the fast reconnect message flow in case the EAP 613 server fails to re-authenticate the EAP peer. The EAP peer MUST send 614 an empty EAP-IKEv2 informational message in reply to the EAP 615 server's error indication. The EAP server answers with an EAP- 616 Failure. 618 1) A <-- B: EAP-Request/Identity 620 2) A --> B: EAP-Response/Identity(Id) 622 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 623 HDR, SK {SA, Ni, [KEi]}) 625 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 626 HDR, SK {SA, Nr, [KEr]}) 628 5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 629 HDR(A,B), SK {N(AUTHENTICATION_FAILED)}) 631 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 632 HDR(A,B), SK {}) 634 7) A <-- B: EAP-Failure 636 Figure 9: EAP-IKEv2 fast reconnect 637 (client authentication failed) 639 IKE_SAs do not have lifetimes. Such lifetimes are therefore set by 640 local policies of the peers. Typically the peer setting the shorter 641 lifetime will therefore trigger the reconnect procedure. 643 Note: IKEv2 supports fast rekeying to be initiated by both peers. As 644 the EAP server initiating the rekeying better fits the EAP message 645 flow, the EAP server, from an IKE perspective, is the initiator in 646 the rekeying exchange. 648 11. Channel Binding 650 EAP-IKEv2 provides a channel binding functionality [RFC2284bis] in 651 order for the EAP peer and EAP server to make sure that the both 652 entities are given the same network access attributes such as 653 Calling-Station-Id, Called-Station-Id, and NAS-Port-Type by the NAS. 654 This is achieved by using Notify payloads to exchange attribute data 655 between the EAP peer and EAP server. 657 A Notify payload that carries a null channel binding attribute is 658 referred to as a channel binding request. A Notify payload which 659 contains a non-null channel binding attribute and is sent in 660 response to a channel binding request is referred to as a channel 661 binding response. A pair of channel binding request and channel 662 binding response constitute a channel binding exchange. A distinct 663 Notify payload type is used for a particular type of channel binding 664 attribute, which is referred to as a channel binding attribute type. 665 It is allowed to carry multiple channel binding requests and/or 666 responses with different channel binding attribute types in a single 667 IKEv2 message. A set of channel binding exchanges performed in a 668 single round of EAP-IKEv2 full authentication or fast reconnect is 669 referred to as a channel binding procedure. 671 A Notify payload that is used for reporting an error occurred during 672 a channel binding exchange is referred to as a channel binding error 673 indication. 675 EAP-IKEv2 offers a protected result indication mechanism (see 676 section 12.2). To receive protected result indication, the EAP 677 server MUST initiate a channel binding exchange as specified in 678 Figure 10, message 5. As a result of this channel binding exchange, 679 the client will receive a protected result indication, because the 680 server will initiate an informational exchange as part of the 681 channel binding procedure(messages 7 and 8) through the new IKE-SA 682 that results from a successful reconnect procedure. 684 11.1 Channel Binding Procedure in Full Authentication 686 In the case of EAP-IKEv2 full authentication procedure, the channel 687 binding procedure is performed in the following way. 689 The EAP peer MAY include one or more channel binding request in an 690 IKE_SA_INIT response. The EAP server MAY include one or more channel 691 binding request in an IKE_AUTH request. When the EAP server receives 692 an IKE_SA_INIT response with one or more channel binding request, it 693 MUST include the corresponding channel binding response(s) an 694 IKE_AUTH request (in addition to its channel binding request(s) if 695 any). When the EAP peer receives an IKE_AUTH request with one or 696 more channel binding request, it MUST include the corresponding 697 channel binding response(s) in an IKE_AUTH response. 699 When the EAP server successfully validates all the channel binding 700 response(s) sent by the EAP server, it initiates an INFORMATIONAL 701 exchange, where an empty payload is used in both INFORMATIONAL 702 request and INFORMATIONAL response. This exchange serves as a 703 protected success indication. After completion of this 704 INFORMATIONAL exchange, the EAP server sends Success message. 706 11.2 Channel Binding Procedure in Fast Reconnect 708 In the case of EAP-IKEv2 fast reconnect, the channel binding 709 procedure is performed in the following way. 711 In the pair of CREATE_CHILD_SA exchange, the EAP peer and/or the EAP 712 server MAY include one or more channel binding request, one for each 713 channel binding attribute that needs validation. When the EAP peer 714 receives a CREATE_CHILD_SA request with containing one or more 715 channel binding request, it MUST contain channel binding response(s) 716 in the CREATE_CHILD_SA response, as well as its channel binding 717 request(s) if any. This piggybacking is possible because the 718 CREATE_CHILD_SA exchange is protected with the old IKE_SA. When the 719 EAP server receives a CREATE_CHILD_SA response, if it has one or 720 more channel binding response to send to the EAP peer, it initiates 721 an INFORMATIONAL exchange immediately after completion of the 722 CREATE_CHILD_SA exchange, where one or more channel binding response 723 is carried in the INFORMATIONAL request. If the EAP peer 724 successfully validates the channel binding response(s), it MUST 725 respond with an empty INFORMATIONAL response. This exchange serves 726 as a protected success indication. After completion of this 727 INFORMATIONAL exchange, the EAP server sends Success message. 729 11.3 Channel Binding Error Indication 731 A channel binding error is detected by the EAP peer or EAP server 732 when (i) a channel binding response is not contained in the expected 733 IKEv2 message or (ii) a channel binding response is contained in the 734 expected IKEv2 message but the channel binding attribute does not 735 have the expected value. Whenever a channel binding error is 736 detected, the detecting entity MUST send a channel binding error 737 indication to its peering entity. In case of (ii), the channel 738 binding error indication MUST contain the channel binding attribute 739 that caused the error. 741 When the EAP server detects a channel binding error, a channel 742 binding error indication MUST be carried in an INFORMATIONAL 743 request, and the EAP peer MUST respond with an empty INFORMATIONAL 744 response. 745 When the EAP peer detects a channel binding error, a channel binding 746 error indication MUST be carried in an IKEv2 error reporting message 747 for which the R-flag of the IKEv2 header MUST be set. The EAP server 748 MUST respond with EAP-Failure message when it receives such a 749 channel binding error indication. 751 11.4 Notify Payload Types for Channel Binding 753 The following Notify Payload types are defined for the purpose of 754 channel binding exchange. 756 CALLING_STATION_ID TBD 757 The payload data in a channel binding response of this type 758 contains octet string representation of Calling-Station-Id 759 value known to the EAP server by using an external mechanism. 761 CALLED_STATION_ID TBD 762 The payload data in a channel binding response of this type 763 contains octet string representation of Called-Station-Id 764 value known to the EAP peer by using an external mechanism. 766 NAS_PORT_TYPE TBD 767 The payload data in a channel binding response of this type 768 contains 4-octet unsigned integer value of NAS-Port-Type 769 known to the EAP peer by using an external mechanism. 771 The following Notify Payload types are defined for the purpose of 772 reporting when there is an error in a channel binding exchange. 774 INVALID_CALLING_STATION_ID TBD 776 The payload data (if non-null) contains octet string 777 representation of Calling-Station-Id value that caused the 778 error. 780 INVALID_CALLED_STATION_ID TBD 782 The payload data (if non-null) contains octet string 783 representation of Called-Station-Id value that caused the 784 error. 786 INVALID_NAS_PORT_TYPE TBD 788 The payload data (if non-null) contains 4-octet unsigned 789 integer value of NAS-Port-Type that caused the error. 791 Table 1 shows the the entity that is allowed to send a channel 792 binding request for each channel binding attribute type. 794 channel binding The entity that is allowed to send 795 attribute type channel binding request 796 ----------------------+------------------------------------------ 797 CALLING_STATION_ID EAP server 799 CALLED_STATION_ID EAP peer 801 NAS_PORT_TYPE EAP server 802 Table 1: Channel Binding Attribute Types and Requesting Entities 804 11.5 Examples 806 In the figures of this section, a Notify payload tagged with '*' 807 indicates a Notify payload with null data (i.e., a channel binding 808 request). a Notify payload no tagged with '*' indicates a Notify 809 payload with non-null data (i.e., a channel binding response). 811 Figure 10 shows an example of EAP-IKEv2 authentication sequence with 812 a successful channel binding procedure. The first two messages 813 constitute the standard EAP identity exchange and are optional. 815 1) A <-- B: EAP-Request/Identity 817 2) A --> B: EAP-Response/Identity(Id) 819 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 821 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 822 HDR(A,B), SAr1, KEr, Nr, [CERTREQ,] 823 N(CALLED_STATION_ID*)) 825 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 826 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH, 827 N(CALLED_STATION_ID), 828 N(CALLING_STATION_ID*), 829 N(NAS_PORT_TYPE*)}) 831 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 832 HDR(A,B), SK {IDr, [CERT,] AUTH, 833 N(CALLING_STATION_ID), 834 N(NAS_PORT_TYPE)}) 836 7) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 837 HDR(A,B), SK {}) 839 8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 840 HDR(A,B), SK {}) 842 9) A <-- B: EAP-Success 844 Figure 10: EAP-IKEv2 with successful channel binding 846 Figure 11 shows an example of EAP-IKEv2 authentication sequence when 847 the EAP server detects an error in a channel binding procedure. The 848 first two messages constitute the standard EAP identity exchange and 849 are optional. In this case, message 7) and 8) MUST constitute an 850 INFORMATIONAL exchange. 852 1) A <-- B: EAP-Request/Identity 854 2) A --> B: EAP-Response/Identity(Id) 856 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 858 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 859 HDR(A,B), SAr1, KEr, Nr, [CERTREQ,] 860 N(CALLED_STATION_ID*)) 862 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 863 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH, 864 N(CALLED_STATION_ID), 865 N(CALLING_STATION_ID*), 866 N(NAS_PORT_TYPE*)}) 868 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 869 HDR(A,B), SK {IDr, [CERT,] AUTH, 870 N(CALLING_STATION_ID), 871 N(NAS_PORT_TYPE)}) 873 7) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 874 HDR(A,B), SK {N(INVALID_CALLING_STATION_ID)}) 876 8) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 877 HDR(A,B), SK {}) 879 9) A <-- B: EAP-Failure 881 Figure 11: EAP-IKEv2 with channel binding error 882 (detected by EAP server) 884 Figure 12 shows an example of EAP-IKEv2 authentication sequence when 885 the EAP peer detects an error in a channel binding procedure. The 886 first two messages constitute the standard EAP identity exchange and 887 are optional. 889 1) A <-- B: EAP-Request/Identity 891 2) A --> B: EAP-Response/Identity(Id) 893 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 895 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 896 HDR(A,B), SAr1, KEr, Nr, [CERTREQ,] 897 N(CALLED_STATION_ID*)) 899 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 900 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH, 901 N(CALLED_STATION_ID), 902 N(CALLING_STATION_ID*), 903 N(NAS_PORT_TYPE*)}) 905 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 906 HDR(A,B), SK {N(INVALID_CALLED_STATION_ID)}) 908 7) A <-- B: EAP-Failure 910 Figure 12: EAP-IKEv2 with channel binding error 911 (detected by EAP peer) 913 Figure 13 shows an example of EAP-IKEv2 fast reconnection sequence 914 with a successful channel binding procedure. The first two messages 915 constitute the standard EAP identity exchange and are optional. 917 1) A <-- B: EAP-Request/Identity 919 2) A --> B: EAP-Response/Identity(Id) 921 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,] 922 N(CALLING_STATION_ID*), 923 N(NAS_PORT_TYPE*)}) 925 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {SA, Nr, [KEr,] 926 N(CALLED_STATION_ID*), 927 N(CALLING_STATION_ID), 928 N(NAS_PORT_TYPE)}) 930 5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 931 HDR(A,B), SK {N(CALLED_STATION_ID)}) 933 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,B), SK {}) 935 7) A <-- B: EAP-Success 937 Figure 13: Fast reconnect with channel binding error 938 (fast reconnect) 940 Figure 14 shows an example of EAP-IKEv2 fast reconnect sequence when 941 the EAP server detects an error in a channel binding procedure. The 942 first two messages constitute the standard EAP identity exchange and 943 are optional. In this case, message 7) and 8) MUST constitute an 944 INFORMATIONAL exchange. 946 1) A <-- B: EAP-Request/Identity 948 2) A --> B: EAP-Response/Identity(Id) 950 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,] 951 N(CALLING_STATION_ID*), 952 N(NAS_PORT_TYPE*)}) 954 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {SA, Nr, [KEr,] 955 N(CALLED_STATION_ID*), 956 N(CALLING_STATION_ID), 957 N(NAS_PORT_TYPE)}) 959 5) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2( 960 HDR(A,B), SK {N(INVALID_CALLING_STATION_ID)}) 962 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 963 HDR(A,B), SK {}) 965 7) A <-- B: EAP-Failure 967 Figure 14: Fast reconnect with channel binding error 968 (detected by EAP server) 970 Figure 15 shows an example of EAP-IKEv2 fast reconnect sequence when 971 the EAP peer detects an error in a channel binding procedure. The 972 first two messages constitute the standard EAP identity exchange and 973 are optional. 975 1) A <-- B: EAP-Request/Identity 977 2) A --> B: EAP-Response/Identity(Id) 979 3) A <-- B: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {SA, Ni, [KEi,] 980 N(CALLING_STATION_ID*), 981 N(NAS_PORT_TYPE*)}) 983 4) A --> B: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {SA, Nr, [KEr,] 984 N(CALLED_STATION_ID*), 985 N(CALLING_STATION_ID), 986 N(NAS_PORT_TYPE)}) 988 5) A <-- B: EAP-Response/EAP-Type=EAP-IKEv2( 989 HDR(A,B), SK {N(CALLED_STATION_ID)}) 991 6) A --> B: EAP-Response/EAP-Type=EAP-IKEv2( 992 HDR(A,B), SK {N(INVALID_CALLED_STATION_ID)}) 994 7) A <-- B: EAP-Failure 996 Figure 15: Fast reconnect with channel binding error 997 (detected by EAP peer) 999 12. Security Considerations 1001 12.1 General Considerations 1003 The security of the proposed EAP method is intentionally based on 1004 IKEv2 [Kau04]. Therefore, the security claims of EAP-IKEv2 are 1005 derived from the security offered by the supported features of 1006 IKEv2. 1008 12.2 Security Claims 1010 Authentication mechanism: 1011 Mutual authentication is supported based on either pre-shared 1012 symmetric keys or public/private key pairs. Besides certificates, 1013 plain public keys can be used. It is possible to use different types 1014 of authentication for the different directions within one 1015 authentication exchange. An example is the server using certificate- 1016 based authentication and the client using pre-shared secrets. 1018 Password-based authentication should only be used in IKEv2 with 1019 extended authentication (EAP tunneling), which is not supported by 1020 this version of EAP-IKEv2. Therefore, dictionary attacks are not 1021 applicable in the context of EAP-IKEv2. 1023 Man-in-the-middle attacks discovered in the context of tunneled 1024 authentication protocols (see [AN03] and [PL+03]) are not applicable 1025 to EAP-IKEv2 as the extended authentication feature of IKEv2 is not 1026 supported. Hence, the cryptographic binding claim is not applicable. 1028 Ciphersuite negotiation is supported as specified in IKEv2 for IKE- 1029 SAs. The negotiation for IPsec (Child) SAs is not supported, as such 1030 SAs are not generated by EAP-IKEv2. 1032 Protected result indication as described in section 7.16 of 1033 [RFC2284bis] is optionally provided by EAP-IKEv2. In message 5 of 1034 figure 1 (full successful authentication) the EAP server 1035 authenticates to the client. Message 6 authenticates the client to 1036 the server, and the client by authenticating the server and by 1037 sending message 6 expresses that it is willing to accept access. The 1038 client, however, does not get a protected result indication from the 1039 server in this case. An attacker could potentially forge an EAP 1040 success/failure message which could result in DoS to the client. In 1041 some situations, synchronization may be achieved by lower layer 1042 indications. 1044 Protected result indication is optionally provided as specified in 1045 section 11. 1046 If this mechanism is not used, the recommended behavior for the 1047 client is to assume the correct establishment of a new IKE-SA after 1048 sending message 6, independent of the receipt of an EAP 1049 success/failure. In case of unsuccessful authentication, the server 1050 would answer with an IKEv2 notification (which, in case of the fast 1051 reconnect exchange, would be protected by the old IKE-SA). In case 1052 of a lost message 6, the server would retransmit message 5, 1053 indicating the message loss to the client. 1054 The client implementation can minimize potential DoS risks due to 1055 missing protected result indications by assuming the correct 1056 establishment of a new IKE-SA after not receiving one of the above 1057 messages within a certain time window after sending message 6. In 1058 the fast reconnect case, the client needs to hold both the old and 1059 the new IKE-SA in parallel during this time window. 1061 Session independence is optionally provided if the fast reconnect 1062 exchange includes the KE payloads (new Diffie-Hellman) as described 1063 in section 10, Figure 7. 1065 Security claims: 1066 Ciphersuite negotiation: Yes 1067 Mutual authentication: Yes 1068 Integrity protection: Yes 1069 Replay protection: Yes 1070 Confidentiality: Yes 1071 Key derivation: Yes 1072 Key strength: N/A 1073 Dictionary attack prot.: N/A 1074 Fast reconnect: Yes 1075 Crypt. binding: N/A 1076 Protected result ind.: yes 1077 Session independence: yes 1078 Fragmentation: Yes 1079 Channel binding: Yes 1081 13. Open Issues 1083 The following issues are still under consideration: 1085 - Notifications 1086 IKEv2 provides the concept of notifications to exchange messages at 1087 any time (e.g., dead peer detection). It remains for further study 1088 which of these messages are required for this EAP method. 1090 - supported identities 1092 Can the NAI be carried by the RFC822 ID type of IKEv2? Are there 1093 other formats to be supported? Additional profiling may be required 1094 in section 5. 1096 - protected result indication 1098 This method provides protected result indications as an optional 1099 feature by running a channel binding exchange. It is ffs whether 1100 this feature should be mandated for all message flows (which would 1101 require to add an additional informational exchange to the message 1102 flows without channel binding. 1104 - tunneled method 1106 To reduce the method's complexity, EAP tunneling through EAP-IKEv2 1107 that is in principal possible with IKEv2 is not supported. If 1108 tunneling support is, however, required (e.g. for sequencing), it is 1109 possible to develop an EAP-IKEv2-tunneled method from the present 1110 one. The major change would be to reverse the roles of IKEv2 1111 initiator and responder, as the initiator is EAP-authenticated in 1112 the tunneled case. 1113 It is not considered a good approach by the authors to have both the 1114 tunneled and the non-tunneled method in a single specification, as 1115 this would result in a rather complex method description. The 1116 tunneled-method EAP-IKEv2 specification, if required, will therefore 1117 come with a separate document. 1119 14. Normative References 1121 [RFC2284] L. Blunk and J. Vollbrecht: "PPP Extensible Authentication 1122 Protocol (EAP)", RFC 2284, March 1998. 1124 [Kau04] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol", 1125 internet draft, Internet Engineering Task Force, January 2004. Work 1126 in progress. 1128 [RFC2119] S. Bradner: "Key words for use in RFCs to Indicate 1129 Requirement Levels", RFC 2119, Internet Engineering Task Force, 1130 March 1997. 1132 15. Informative References 1134 [AN03] N. Asokan, V. Niemi, and K. Nyberg: "Man-in-the-middle in 1135 tunnelled authentication", In the Proceedings of the 11th 1136 International Workshop on Security Protocols, Cambridge, UK, April 1137 2003. To be published in the Springer-Verlag LNCS series. 1139 [PL+03] J. Puthenkulam, V. Lortz, A. Palekar, D. Simon, and B. 1140 Aboba, "The compound authentication binding problem," internet 1141 draft, Internet Engineering Task Force, 2003. Work in progress. 1143 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 1144 (IKE)", RFC 2409, November 1998. 1146 [Per03] R. Perlman: "Understanding IKEv2: Tutorial, and rationale 1147 for decisions", internet draft, Internet Engineering Task Force, 1148 2003. Work in progress. 1150 [AS+03] B. Aboba, D. Simon and J. Arkko: " EAP Key Management 1151 Framework", internet draft, Internet Engineering Task Force, 1152 October, 2003. Work in progress. 1154 [HS03] H. Haverinen, J. Salowey: "EAP SIM Authentication", internet 1155 draft, Internet Engineering Task Force, 2003. Work in progress. 1157 [PS+03] A. Palekar, D. Simon, G. Zorn and S. Josefsson: "Protected 1158 EAP Protocol (PEAP)", internet draft, Internet Engineering Task 1159 Force, March 2003. Work in progress. 1161 [AH03] J. Arkko and H. Haverinen: "EAP AKA Authentication", internet 1162 draft, Internet Engineering Task Force, June 2003. Work in 1163 progress. 1165 Acknowledgments 1167 We would like to thank Bernard Aboba, Jari Arkko, Guenther Horn, 1168 Paoulo Pagliusi and John Vollbrecht for their comments to this 1169 draft. 1171 Additionally we would like to thank members of the PANA design team 1172 (namely D. Forsberg and A. Yegin) for their comments and input to 1173 the initial version of the draft. 1175 Finally we would like to thank the members of the EAP keying design 1176 team for their discussion in the area of the EAP Key Management 1177 Framework. 1179 Author's Addresses 1181 Hannes Tschofenig 1182 Siemens AG 1183 Otto-Hahn-Ring 6 1184 81739 Munich 1185 Germany 1186 EMail: Hannes.Tschofenig@siemens.com 1188 Dirk Kroeselberg 1189 Siemens AG 1190 Otto-Hahn-Ring 6 1191 81739 Munich 1192 Germany 1193 EMail: Dirk.Kroeselberg@siemens.com 1195 Yoshihiro Ohba 1196 Toshiba America Information Systems, Inc. 1197 9740 Irvine Blvd. 1198 Irvine, CA 92619-1697 1199 USA 1200 Phone: +1 973 829 5174 1201 EMail: yohba@tari.toshiba.com 1203 Full Copyright Statement 1205 Copyright (C) The Internet Society (2003). All Rights Reserved. 1207 This document and translations of it may be copied and furnished to 1208 others, and derivative works that comment on or otherwise explain it 1209 or assist in its implementation may be prepared, copied, published 1210 and distributed, in whole or in part, without restriction of any 1211 kind, provided that the above copyright notice and this paragraph 1212 are included on all such copies and derivative works. However, this 1213 document itself may not be modified in any way, such as by removing 1214 the copyright notice or references to the Internet Society or other 1215 Internet organizations, except as needed for the purpose of 1216 developing Internet standards in which case the procedures for 1217 copyrights defined in the Internet Standards process must be 1218 followed, or as required to translate it into languages other than 1219 English. 1221 The limited permissions granted above are perpetual and will not be 1222 revoked by the Internet Society or its successors or assignees. 1224 This document and the information contained herein is provided on an 1225 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1226 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1227 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1228 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1229 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1231 Acknowledgement 1233 Funding for the RFC Editor function is currently provided by the 1234 Internet Society.