idnits 2.17.1 draft-ietf-emu-tls-eap-types-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5247], [RFC5281], [RFC3748], [EAPTLS], [RFC7170], [RFC4851], [RFC5216]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC7170, but the abstract doesn't seem to directly say this. It does mention RFC7170 though, so this could be OK. -- The draft header indicates that this document updates RFC5281, but the abstract doesn't seem to directly say this. It does mention RFC5281 though, so this could be OK. -- The draft header indicates that this document updates RFC21, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5247, but the abstract doesn't seem to directly say this. It does mention RFC5247 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- No information found for rfc21 - is the name correct? (Using the creation date from RFC5247, updated by this document, for RFC5378 checks: 2003-10-13) -- 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 (21 February 2021) is 1158 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 192 == Outdated reference: A later version (-21) exists of draft-ietf-emu-eap-tls13-14 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group DeKok, Alan 3 INTERNET-DRAFT FreeRADIUS 4 Updates: 5247, 5281, 7170 21 February 2021 5 Category: Standards Track 6 Expires: August 21, 2021 8 TLS-based EAP types and TLS 1.3 9 draft-ietf-emu-tls-eap-types-02.txt 11 Abstract 13 EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS]. Many 14 other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as 15 FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], and possibly many 16 vendor specific EAP methods. This document updates those methods in 17 order to use the new key derivation methods available in TLS 1.3. 18 Additional changes necessitated by TLS 1.3 are also discussed. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 29, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info/) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction ............................................. 4 61 1.1. Requirements Language ............................... 4 62 2. Using TLS-based EAP methods with TLS 1.3 ................. 5 63 2.1. Key Derivation ...................................... 5 64 2.2. TEAP ................................................ 6 65 2.3. FAST ................................................ 7 66 2.4. TTLS ................................................ 8 67 2.5. PEAP ................................................ 8 68 3. Application Data ......................................... 8 69 4. Resumption ............................................... 9 70 5. Security Considerations .................................. 10 71 5.1. Protected Success and Failure indicators ............ 10 72 6. IANA Considerations ...................................... 11 73 7. References ............................................... 12 74 7.1. Normative References ................................ 12 75 7.2. Informative References .............................. 13 77 1. Introduction 79 EAP-TLS is being updated for TLS 1.3 in [EAPTLS]. Many other EAP 80 types also depend on TLS, such as FAST [RFC4851], TTLS [RFC5281], 81 TEAP [RFC7170], and possibly many vendor specific EAP methods. All 82 of these methods use key derivation functions which rely on the 83 information which is no longer available in TLS 1.3. As such, all of 84 those methods are incompatible with TLS 1.3. 86 We wish to enable the use of TLS 1.3 in the wider Internet community. 87 As such, it is necessary to update the above EAP types. These 88 changes involve defining new key derivation functions. We also 89 discuss implementation issues in order to highlight differences 90 between TLS 1.3 and earlier versions of TLS. 92 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 2. Using TLS-based EAP methods with TLS 1.3 102 In general, all of the requirements of [EAPTLS] apply to other EAP 103 methods that wish to use TLS 1.3. Unless otherwise discusses herein, 104 implementations of EAP methods that wish to use TLS 1.3 MUST follow 105 the guidelines in [EAPTLS]. 107 There remain some differences between EAP-TLS and other TLS-based EAP 108 methods which necessitates this document. The main difference is 109 that [EAPTLS] uses the EAP-TLS type ID (0x0D) in a number of 110 calculations, whereas other method types will use their own type ID 111 instead of the EAP-TLS type ID. This topic is discussed further 112 below in Section 2. 114 An additional difference is that the [EAPTLS] Section 2.5 requires a 115 Commitment Message to be sent once the EAP-TLS handshake has 116 completed. Other TLS-based EAP methods also use the Commitment 117 Message, but only during resumption. When the other TLS-based EAP 118 methods send application data inside of the TLS tunnel, the 119 Commitment Message is not used. This topic is explained in more 120 detail below, in Section 3. 122 Finally, the document includes clarifications on how various TLS- 123 based parameters are calculated when using TLS 1.3. These parameters 124 are different for each EAP method, so they are discussed separately. 126 2.1. Key Derivation 128 The key derivation for TLS-based EAP methods depends on the value of 129 the Type-Code as defined by [IANA]. The most important definition is 130 of the Type-Code: 132 Type-Code = EAP Method type 134 The Type-Code is defined to be 1 octet for values smaller than 255. 135 Where expanded EAP Type Codes are used, the Type-Code is defined to 136 be the Expanded Type Code (including the Type, Vendor-Id (in network 137 byte order) and Vendor-Type fields (in network byte order) defined in 138 [RFC3748] Section 5.7). 140 Type-Code = 0xFE || Vendor-Id || Vendor-Type 142 Unless otherwise discussed below, the key derivation functions for 143 all TLS-based EAP types are defined as follows: 145 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 146 Type-Code, 128) 147 IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", Type-Code, 64) 148 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 149 Type-Code, 64) 150 Session-Id = Type-Code || Method-Id 151 MSK = Key_Material(0, 63) 152 EMSK = Key_Material(64, 127) 153 Enc-RECV-Key = MSK(0, 31) 154 Enc-SEND-Key = MSK(32, 63) 155 RECV-IV = IV(0, 31) 156 SEND-IV = IV(32, 63) 158 We note that these definitions re-use the EAP-TLS exporter labels, 159 and change the derivation only by adding a dependency on Type-Code. 160 The reason for this change is simplicity. There does not appear to 161 be compelling reasons to make the labels method-specific, when they 162 can just include the Type-Code in the key derivation. 164 These definitions apply in their entirety to TTLS [RFC5281] and PEAP 165 as defined in [PEAP] and [MSPEAP]. Some definitions apply to FAST 166 and TEAP, with exceptions as noted below. 168 It is RECOMMENDED that vendor-defined TLS-based EAP methods use the 169 above definitions for TLS 1.3. There is insufficient reason to use 170 different definitions. 172 2.2. TEAP 174 [RFC7170] Section 5.2 gives a definition for the Inner Method Session 175 Key (IMSK), which depends on the TLS-PRF. We update that definition 176 for TLS 1.3 as: 178 IMSK = TLS-Exporter("TEAPbindkey@ietf.org", EMSK, 32) 180 For MSK and EMSK, TEAP [RFC7170] uses an inner tunnel EMSK to 181 calculate the outer EMSK. As such, those key derivations cannot use 182 the above derivation. 184 The other key derivations for TEAP are given here. All derivations 185 not given here are the same as given above in the previous section. 186 These derivations are also used for FAST, but using the FAST Type- 187 Code. 189 session_key_seed = TLS-Exporter("EXPORTER: session key seed", 190 Type-Code, 40) 192 S-IMCK[0] = session_key_seed 193 For j = 1 to n-1 do 194 IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound 195 Keys", S-IMCK[j-1] | IMSK[j], 60) 196 S-IMCK[j] = first 40 octets of IMCK[j] 197 CMK[j] = last 20 octets of IMCK[j] 199 Where | denotes concatenation. MSK and EMSK are then derived from 200 the above definitions, as: 202 MSK = TLS-Exporter("EXPORTER: Session Key Generating Function", 203 S-IMCK[j], 64) 205 EMSK = TLS-Exporter("EXPORTER: Extended Session Key Generating 206 Function", S-IMCK[j], 64) 208 The TEAP Compound MAC defined in [RFC7170] Section 5.3 is updated to 209 use the definition of CMK[j] given above, which then leads to the 210 following definition 212 CMK = CMK[j] 214 Compound-MAC = MAC( CMK, BUFFER ) 216 where j is the number of the last successfully executed inner EAP 217 method. For TLS 1.3, the hash function used is the same as the 218 ciphersuite hash function negotiated for HKDF in the key schedule, as 219 per section 7.1 of RFC 8446. The definition of BUFFER is unchanged 220 from [RFC7170] Section 5.3 222 2.3. FAST 224 For FAST, the session_key_seed is also used as the key_block, as 225 defined in [RFC4851] Section 5.1. 227 The definition of S-IMCK[n], MSK, and EMSK are the same as given 228 above for TEAP. We reiterate that the EAP-FAST Type-Code must be 229 used when deriving the session_key_seed, and not the TEAP Type-Code. 231 Unlike [RFC4851] Section 5.2, the definition of IMCK[j] places the 232 reference to S-IMCK after the textual label, and the concatenates the 233 IMSK instead of MSK. 235 EAP-FAST previously used a PAC, which is a type of pre-shared key 236 (PSK). Such uses are deprecated in TLS 1.3. As such, PAC 237 provisioning is no longer part of EAP-FAST when TLS 1.3 is used. 239 The T-PRF given in [RFC4851] Section 5.5 is not used for TLS 1.3. 241 2.4. TTLS 243 [RFC5281] Section 11.1 defines an implicit challenge when the inner 244 methods of CHAP [RFC1994], MS-CHAP [RFC2433], or MS-CHAPv2 [RFC2759] 245 are used. The derivation for TLS 1.3 is instead given as 247 EAP-TTLS_challenge = TLS-Exporter("ttls challenge",, n) 249 There no "context_value" ([RFC8446] Section 7.5) passed to the TLS- 250 Exporter function. The value "n" given here is the length of the 251 challenge required, which varies according to the challenge. 253 Note that unlike TLS 1.2 and earlier, the calculation of TLS-Exporter 254 depends on the length passed to it. Implementations therefore MUST 255 pass the correct length, instead of passing a large length and 256 truncating the output. Any truncated output will be different from 257 the output calculated using the correct length. 259 2.5. PEAP 261 When PEAP uses crypto binding, it uses a different key calculation 262 defined in [PEAP-MPPE] which consumes inner method keying material. 263 The pseudo-random function (PRF) used here is not taken from the TLS 264 exporter, but is instead calculated via a different method which is 265 given in [PEAP-PRF]. That derivation remains unchanged in this 266 specification. 268 However, the key calculation uses a PEAP Tunnel Key [PEAP-TK] which 269 is defined as: 271 ... the TK is the first 60 octets of the Key_Material, as 272 specified in [RFC5216]: TLS-PRF-128 (master secret, "client EAP 273 encryption", client.random || server.random). 275 We note that this text does not define Key_Material. Instead, it 276 defines TK as the first octets of Key_Material, and gives a 277 definition of Key_Material which is appropriate for TLS versions 278 before TLS 1.3. 280 For TLS 1.3, the TK should instead be derived from the Key_Material 281 defined above in Section 2.1. 283 3. Application Data 285 Unlike previous TLS versions, TLS 1.3 can continue negotiation after 286 the TLS session has been initialized. Some implementations use the 287 TLS "Finished" state as a signal that application data is now 288 available, and an "inner tunnel" session can now be negotiated. As 289 noted in [RFC8446], TLS 1.3 may include one or more 290 "NewSessionTicket" messages after the "Finished" state. This change 291 can cause many implementations to fail. 293 In order to correct this failure, if the underlying TLS connection is 294 still performing negotiations, then implementations MUST NOT send, or 295 expect to receive application data in the TLS session. 296 Implementations MUST delay processing of application data until such 297 time as the TLS negotiation has finished. If the TLS negotiation is 298 successful, then the application data can be examined. If the TLS 299 negotiation is unsuccessful, then the application data is untrusted, 300 and therefore MUST be discarded without being examined. 302 [EAPTLS] Section 2.5 requires a Commitment message which indicates 303 that TLS negotiation has finished. Methods which use "inner tunnel" 304 methods MUST instead begin their "inner tunnel" negotiation by 305 sending type-specific application data. 307 4. Resumption 309 [EAPTLS] Section 2.1.3 defines the process for resumption. This 310 process is the same for all TLS-based EAP types. The only practical 311 difference is that the type code is different. 313 All TLS-based EAP methods support resumption. All EAP servers and 314 peers MUST support resumption. We note that EAP servers and peers 315 can still choose to not resume any particular session. For example, 316 EAP servers may forbid resumption for administrative, or other policy 317 reasons. 319 It is RECOMMENDED that EAP servers and peers enable resumption, and 320 use it where possible. The use of resumption decreases the number of 321 round trips used for authentication. This decrease leads to faster 322 authentications, and less load on the EAP server. 324 EAP servers peers MUST NOT resume sessions across different EAP 325 types, and EAP servers MUST reject resumptions in which the EAP Type 326 code is different from the original authentication. 328 As the packet flows for resumption are essentially identical across 329 all TLS-based EAP types, it is technically possible to authenticate 330 using EAP-TLS (EAP Type code 13), and then perform resumption using 331 another EAP type, just as EAP-TTLS (EAP Type code 21). However, 332 there is no practical benefit to doing so. It is also not clear what 333 this behavior would mean, or what (if any) security issues there may 334 be with it. As a result, this behavior is forbidden. 336 5. Security Considerations 338 [EAPTLS] Section 5 is included here by reference. 340 Updating the above EAP methods to use TLS 1.3 is of high importance 341 for the Internet Community. Using the most recent security protocols 342 can significantly improve security and privace of a network. 344 In some cases, client certificates are not used for TLS-based EAP 345 methods. In those cases, the user is authenticated only after 346 successful completion of the inner tunnel authentication. However, 347 the TLS protocol may send one or more NewSessionTicket after 348 receiving the TLS Finished message from the client, and therefore 349 before the user is authenticated. 351 This separation of data allows for a "time of use, time of check" 352 security issue. Malicious clients can begin a session and receive 353 the NewSessionTicket. Then prior to authentication, the malicious 354 client can abort the authentication session. The malicious client 355 can then use the obtained NewSessionTicket to "resume" the previous 356 session. 358 As a result, EAP servers MUST NOT permit sessions to be resumed until 359 after authentication has successfully completed. This requirement 360 may be met in a number of ways. For example, by not caching the 361 session ticket until after authentication has completed, or by 362 marking up the cached session ticket with a flag stating whether or 363 not authentication has completed. 365 For PEAP, some derivation use HMAC-SHA1 [PEAP-MPPE]. There are no 366 known security issues with HMAC-SHA1. In the interests of 367 interoperability and minimal changes, we do not change that 368 definition here. 370 5.1. Protected Success and Failure indicators 372 [EAPTLS] provides for protected success and failure indicators as 373 discussed in Section 4.1.1 of [RFC4137]. These indicators are 374 provided for both full authentication, and for resumption. 376 Other TLS-based EAP methods provide these indicators only for 377 resumption. 379 For full authenticaton, the other TLS-based EAP methods do not 380 provide for protected success and failure indicators as part of the 381 outer TLS exchange. That is, the Commitment Message is not used, and 382 there is no TLS-layer alert sent when the inner authentication fails. 383 Instead, there is simple either an EAP-Success or EAP-Failure sent. 385 This behavior is the same as for previous TLS versions, and therefore 386 introduces no new security issues. 388 We note that most TLS-based EAP methods provide for success and 389 failure indicators as part of the authentication exchange performed 390 inside of the TLS tunnel. These indicators are therefore protected, 391 as they cannot be modified or forged. 393 When the inner authentication protocol indicates that authentication 394 has failed, then implementations MUST fail authentication for the 395 entire session. There MAY be additional protocol exchanges in order 396 to exchange more detailed failure indicates, but the final result 397 MUST be a failed authentication. 399 Similarly, when the inner authentication protocol indicates that 400 authentication has succeeed, then implementations SHOULD cause 401 authentication to succeed for the entire session. There MAY be 402 additional protocol exchanges in order which could cause other 403 failures, so success is not required here. 405 In both of these cases, the EAP server MUST send an EAP-Failure or 406 EAP-Success message, as indicated by Section 2 item 4 of [RFC3748]. 407 Even though both parties have already determined the final 408 authentication status, the full EAP state machine must still be 409 followed. 411 6. IANA Considerations 413 This section provides guidance to the Internet Assigned Numbers 414 Authority (IANA) regarding registration of values related to the TLS- 415 based EAP methods for TLS 1.3 protocol in accordance with [RFC8126]. 417 This memo requires IANA to add the following labels to the TLS 418 Exporter Label Registry defined by [RFC5705]. These labels are used 419 in derivation of Key_Material, IV and Method-Id as defined above in 420 Section 2. 422 The labels above need to be added to the "TLS Exporter Labels" 423 registry. 425 * EXPORTER: session key seed * EXPORTER: Inner Methods Compound Keys 426 * EXPORTER: Session Key Generating Function * EXPORTER: Extended 427 Session Key Generating Function * TEAPbindkey@ietf.org 429 7. References 431 7.1. Normative References 433 [RFC2119] 434 Bradner, S., "Key words for use in RFCs to Indicate Requirement 435 Levels", RFC 2119, March, 1997, . 438 [RFC3748] 439 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 440 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 441 June 2004. 443 [RFC5216] 444 Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication 445 Protocol", RFC 5216, March 2008 447 [RFC5247] 448 Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication 449 Protocol (EAP) Key Management Framework", RFC 5247, August 2008, 451 [RFC5705] 452 Rescorla, E., "Keying Material Exporters for Transport Layer 453 Security (TLS)", RFC 5705, March 2010 455 [RFC7170] 456 Zhou, H., et al., "Tunnel Extensible Authentication Protocol (TEAP) 457 Version 1", RFC 7170, May 2014. 459 [RFC8126] 460 Cotton, M., et al, "Guidelines for Writing an IANA Considerations 461 Section in RFCs", RC 8126, June 2017. 463 [RFC8174] 464 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 465 Words", RFC 8174, May 2017, . 468 [RFC8446] 469 Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 470 1.3", RFC 8446, August 2018. 472 [EAPTLS] 473 Mattsson, J., and Sethi, M., "Using EAP-TLS with TLS 1.3", draft- 474 ietf-emu-eap-tls13-14, February, 2021. 476 [IANA] 477 https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap- 478 numbers-4 480 7.2. Informative References 482 [MSPEAP] 483 https://msdn.microsoft.com/en-us/library/cc238354.aspx 485 [PEAP] 486 Palekar, A. et al, "Protected EAP Protocol (PEAP)", draft- 487 josefsson-pppext-eap-tls-eap-06.txt, March 2003. 489 [PEAP-MPPE] 490 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 491 PEAP/e75b0385-915a-4fc3-a549-fd3d06b995b0 493 [PEAP-PRF] 494 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 495 PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df 497 [PEAP-TK] 498 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 499 PEAP/41288c09-3d7d-482f-a57f-e83691d4d246 501 [RFC1994] 502 Simpson, W., "PPP Challenge Handshake Authentication Protocol 503 (CHAP)", RFC 1994, August 1996. 505 [RFC2433] 506 Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC 2433, 507 October 1998. 509 [RFC2759] 510 Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, 511 January 2000. 513 [RFC4137] 514 Vollbrecht, J., et al, "State Machines for Extensible 515 Authentication Protocol (EAP) Peer and Authenticator ", RFC 4137, 516 August 2005. 518 [RFC4851] 519 Cam-Winget, N., et al, "The Flexible Authentication via Secure 520 Tunneling Extensible Authentication Protocol Method (EAP-FAST)", 521 RFC 4851, May 2007. 523 [RFC5281] 524 Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol 525 Tunneled Transport Layer Security Authenticated Protocol Version 0 526 (EAP-TTLSv0)", RFC 5281, August 2008. 528 Acknowledgments 530 Thanks to Jorge Vergara for a detailed review of the requirements for 531 various EAP types, and for assistance with interoperability testing. 533 Authors' Addresses 535 Alan DeKok 536 The FreeRADIUS Server Project 538 Email: aland@freeradius.org