idnits 2.17.1 draft-ietf-emu-tls-eap-types-01.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 RFC29, but the abstract doesn't seem to mention this, which it should. -- 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 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 rfc29 - 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 (29 July 2020) is 1366 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 190 == Outdated reference: A later version (-21) exists of draft-ietf-emu-eap-tls13-03 -- 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 29 July 2020 5 Category: Standards Track 6 Expires: January 29, 2021 8 TLS-based EAP types and TLS 1.3 9 draft-ietf-emu-tls-eap-types-01.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) 2020 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 ................................................ 7 67 2.5. PEAP ................................................ 8 68 3. Application Data ......................................... 8 69 4. Security Considerations .................................. 9 70 5. IANA Considerations ...................................... 9 71 6. References ............................................... 10 72 6.1. Normative References ................................ 10 73 6.2. Informative References .............................. 11 75 1. Introduction 77 EAP-TLS is being updated for TLS 1.3 in [EAPTLS]. Many other EAP 78 types also depend on TLS, such as FAST [RFC4851], TTLS [RFC5281], 79 TEAP [RFC7170], and possibly many vendor specific EAP methods. All 80 of these methods use key derivation functions that rely on the 81 information which is no longer available in TLS 1.3. As such, all of 82 those methods are incompatible with TLS 1.3. 84 We wish to enable the use of TLS 1.3 in the wider Internet community. 85 As such, it is necessary to update the above EAP types. These 86 changes involve defining new key derivation functions. We also 87 discuss implementation issues in order to highlight differences 88 between TLS 1.3 and earlier versions of TLS. 90 1.1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in BCP 95 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 2. Using TLS-based EAP methods with TLS 1.3 100 In general, all of the requirements of [EAPTLS] apply to other EAP 101 methods that wish to use TLS 1.3. Unless otherwise discusses herein, 102 implementations of EAP methods that wish to use TLS 1.3 MUST follow 103 the guidelines in [EAPTLS]. 105 There remain some differences between EAP-TLS and other TLS-based EAP 106 methods which necessitates this document. The main difference is 107 that [EAPTLS] uses the EAP-TLS type ID (0x0D) in a number of 108 calculations, whereas other method types will use their own type ID 109 instead of the EAP-TLS type ID. This topic is discussed further 110 below in Section 2. 112 An additional difference is that the [EAPTLS] Section 2.5 requires a 113 Commitment Message to be sent once the EAP-TLS handshake is done. 114 When other TLS-based EAP methods send application data, this 115 Commitment Message is not needed, and is therefore not sent. 116 However, when application data is not sent, as with fast reconnect, 117 the Commitment Message is still required. 119 Finally, the document includes clarifications on how various TLS- 120 based parameters are calculated when using TLS 1.3. These parameters 121 are different for each EAP method, so they are discussed separately. 123 2.1. Key Derivation 125 The key derivation for TLS-based EAP methods depends on the value of 126 the Type-Code as defined by [IANA]. The most important definition is 127 of the Type-Code: 129 Type-Code = EAP Method type 131 The Type-Code is defined to be 1 octet for values smaller than 255. 132 Where expanded EAP Type Codes are used, the Type-Code is defined to 133 be the Expanded Type Code (including the Type, Vendor-Id (in network 134 byte order) and Vendor-Type fields (in network byte order) defined in 135 [RFC3748] Section 5.7). 137 Type-Code = 0xFE || Vendor-Id || Vendor-Type 139 Unless otherwise discussed below, the key derivation functions for 140 all TLS-based EAP types are defined as follows: 142 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 143 Type-Code, 128) 144 IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", Type-Code, 64) 145 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 146 Type-Code, 64) 147 Session-Id = Type-Code || Method-Id 148 MSK = Key_Material(0, 63) 149 EMSK = Key_Material(64, 127) 150 Enc-RECV-Key = MSK(0, 31) 151 Enc-SEND-Key = MSK(32, 63) 152 RECV-IV = IV(0, 31) 153 SEND-IV = IV(32, 63) 155 We note that these definitions re-use the EAP-TLS exporter labels, 156 and change the derivation only by adding a dependency on Type-Code. 157 The reason for this change is simplicity. There does not appear to 158 be compelling reasons to make the labels method-specific, when we can 159 just include the Type-Code in the key derivation. 161 These definitions apply in their entirety to TTLS [RFC5281] and PEAP 162 as defined in [PEAP] and [MSPEAP]. Some definitions apply to FAST 163 and TEAP, with exceptions as noted below. 165 It is RECOMMENDED that vendor-defined TLS-based EAP methods use the 166 above definitions for TLS 1.3. There is insufficient reason to use 167 different definitions. 169 2.2. TEAP 171 [RFC7170] Section 5.2 gives a definition for the Inner Method Session 172 Key (IMSK), which depends on the TLS-PRF. We update that definition 173 for TLS 1.3 as: 175 IMSK = TLS-Exporter("TEAPbindkey@ietf.org", EMSK, 32) 177 For MSK and EMSK, TEAP [RFC7170] cannot use the derivation given 178 above in Section Those methods use an inner tunnel EMSK to calculate 179 the outer EMSK. As such, those key derivations cannot use the above 180 derivation. 182 The other key derivations for TEAP are given here. All derivations 183 not given here are the same as given above in the previous section. 184 These derivations are also used for FAST, but using the FAST Type- 185 Code. 187 session_key_seed = TLS-Exporter("EXPORTER: session key seed", 188 Type-Code, 40) 190 S-IMCK[0] = session_key_seed 191 For j = 1 to n-1 do 192 IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound 193 Keys", S-IMCK[j-1] | IMSK[j], 60) 194 S-IMCK[j] = first 40 octets of IMCK[j] 195 CMK[j] = last 20 octets of IMCK[j] 197 Where | denotes concatenation. MSK and EMSK are then derived from 198 the above definitions, as: 200 MSK = TLS-Exporter("EXPORTER: Session Key Generating Function", 201 S-IMCK[j], 64) 203 EMSK = TLS-Exporter("EXPORTER: Extended Session Key Generating 204 Function", S-IMCK[j], 64) 206 The TEAP Compound MAC defined in [RFC7170] Section 5.3 is updated to 207 use the definition of CMK[j] given above, which then leads to the 208 following definition 210 CMK = CMK[j] 212 Compound-MAC = MAC( CMK, BUFFER ) 214 where j is the number of the last successfully executed inner EAP 215 method, MAC is the MAC function negotiated in TLS 1.3. The 216 definition of BUFFER is unchanged from [RFC7170] Section 5.3 218 2.3. FAST 220 For FAST, the session_key_seed is also used as the key_block, as 221 defined in [RFC4851] Section 5.1. 223 The definition of S-IMCK[n], MSK, and EMSK are the same as given 224 above for TEAP. We reiterate that the EAP-FAST Type-Code must be 225 used when deriving the session_key_seed, and not the TEAP Type-Code. 227 Unlike [RFC4851] Section 5.2, the definition of IMCK[j] places the 228 reference to S-IMCK after the textual label, and the concatenates the 229 IMSK instead of MSK. 231 EAP-FAST previously used a PAC, which is a type of pre-shared key 232 (PSK). Such uses are deprecated in TLS 1.3. As such, PAC 233 provisioning is no longer part of EAP-FAST when TLS 1.3 is used. 235 The T-PRF given in [RFC4851] Section 5.5 is not used for TLS 1.3. 237 2.4. TTLS 239 [RFC5281] Section 11.1 defines an implicit challenge when the inner 240 methods of CHAP [RFC1994], MS-CHAP [RFC2433], or MS-CHAPv2 [RFC2759] 241 are used. The derivation for TLS 1.3 is instead given as 242 EAP-TTLS_challenge = TLS-Exporter("ttls challenge",, n) 244 There no "context_value" ([RFC8446] Section 7.5) passed to the TLS- 245 Exporter function. The value "n" given here is the length of the 246 challenge required, which varies according to the challenge. 248 Note that unlike TLS 1.2 and earlier, the calculation of TLS-Exporter 249 depends on the length passed to it. Implementations therefore MUST 250 pass the correct length, instead of passing a large length and 251 truncating the output. Any truncated output will be different from 252 the output calculated using the correct length. 254 2.5. PEAP 256 When PEAP uses crypto binding, it uses a different key calculation 257 defined in [PEAP-MPPE] which consumes inner method keying material. 258 The pseudo-random function (PRF) used here is not taken from the TLS 259 exporter, but is instead calculated via a different method which is 260 given in [PEAP-PRF]. That derivation remains unchanged in this 261 specification. 263 However, the key calculation uses a PEAP Tunnel Key [PEAP-TK] which 264 is defined as: 266 ... the TK is the first 60 octets of the Key_Material, as 267 specified in [RFC5216]: TLS-PRF-128 (master secret, "client EAP 268 encryption", client.random || server.random). 270 We note that this text does not define Key_Material. Instead, it 271 defines TK as the first octets of Key_Material, and gives a 272 definition of Key_Material which is appropriate for TLS versions 273 before TLS 1.3. 275 For TLS 1.3, the TK should instead be derived from the Key_Material 276 defined above in Section 2.1. 278 3. Application Data 280 Unlike previous TLS version, TLS 1.3 continues negotiation after the 281 TLS session has been initialized. Some implementations use the TLS 282 "Finished" state as a signal that application data is now available, 283 and an "inner tunnel" session can now be negotiated. As noted in 284 [RFC8446], TLS 1.3 may include a "NewSessionTicket" after the 285 "Finished" state. This change can cause many implementations to 286 fail. 288 In order to correct this failure, if the underlying TLS connection is 289 still performing negotiations, then implementations MUST NOT send, or 290 expect to receive application data in the TLS session. 292 [EAPTLS] Section 2.5 requires a one octet Commitment message which 293 indicates that TLS negotiation has finished. Methods which use 294 "inner tunnel" methods MUST instead begin their "inner tunnel" 295 negotiation by sending type-specific application data. However, if 296 no "inner tunnel" negotiation is performed (as with fast reconnect), 297 then a Commitment Message MUST be sent as per [EAPTLS] Section 2.5. 299 4. Security Considerations 301 [EAPTLS] Section 5 is included here by reference. 303 Updating the above EAP methods to use TLS 1.3 is of high importance 304 for the Internet Community. Using the most recent security protocols 305 can significantly improve security and privace of a network. 307 In some cases, client certificates are not used for TLS-based EAP 308 methods. In those cases, the user is authenticated only after 309 successful completion of the inner tunnel authentication. However, 310 the TLS protocol sends a NewSessionTicket after receiving the TLS 311 Finished message from the client, and therefore before the user is 312 authenticated. 314 This separation of data allows for a "time of use, time of check" 315 security issue. Malicious clients can begin a session and receive 316 the NewSessionTicket. Then prior to authentication, the malicious 317 client can abort the authentication session. The malicious client 318 can then use the obtained NewSessionTicket to "resume" the previous 319 session. 321 As a result, EAP servers MUST NOT permit sessions to be resumed until 322 after authentication has successfully completed. This requirement 323 may be met in a number of ways. For example, by not caching the 324 session ticket until after authentication has completed, or by 325 marking up the cached session ticket with a flag stating whether or 326 not authentication has completed. 328 For PEAP, some derivation use HMAC-SHA1 [PEAP-MPPE]. There are no 329 known security issues with HMAC-SHA1. In the interests of 330 interoperability and minimal changes, we do not change that 331 definition here. 333 5. IANA Considerations 335 This section provides guidance to the Internet Assigned Numbers 336 Authority (IANA) regarding registration of values related to the TLS- 337 based EAP methods for TLS 1.3 protocol in accordance with [RFC8126]. 339 This memo requires IANA to add the following labels to the TLS 340 Exporter Label Registry defined by [RFC5705]. These labels are used 341 in derivation of Key_Material, IV and Method-Id as defined above in 342 Section 2. 344 The labels above need to be added to the "TLS Exporter Labels" 345 registry. 347 * EXPORTER: session key seed * EXPORTER: Inner Methods Compound Keys 348 * EXPORTER: Session Key Generating Function * EXPORTER: Extended 349 Session Key Generating Function * TEAPbindkey@ietf.org 351 6. References 353 6.1. Normative References 355 [RFC2119] 356 Bradner, S., "Key words for use in RFCs to Indicate Requirement 357 Levels", RFC 2119, March, 1997, . 360 [RFC3748] 361 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 362 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 363 June 2004. 365 [RFC5216] 366 Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication 367 Protocol", RFC 5216, March 2008 369 [RFC5247] 370 Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication 371 Protocol (EAP) Key Management Framework", RFC 5247, August 2008, 373 [RFC5705] 374 Rescorla, E., "Keying Material Exporters for Transport Layer 375 Security (TLS)", RFC 5705, March 2010 377 [RFC7170] 378 Zhou, H., et al., "Tunnel Extensible Authentication Protocol (TEAP) 379 Version 1", RFC 7170, May 2014. 381 [RFC8126] 382 Cotton, M., et al, "Guidelines for Writing an IANA Considerations 383 Section in RFCs", RC 8126, June 2017. 385 [RFC8174] 386 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 387 Words", RFC 8174, May 2017, . 390 [RFC8446] 391 Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 392 1.3", RFC 8446, August 2018. 394 [EAPTLS] 395 Mattsson, J., and Sethi, M., "Using EAP-TLS with TLS 1.3", draft- 396 ietf-emu-eap-tls13-03, November 2018. 398 [IANA] 399 https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap- 400 numbers-4 402 6.2. Informative References 404 [MSPEAP] 405 https://msdn.microsoft.com/en-us/library/cc238354.aspx 407 [PEAP] 408 Palekar, A. et al, "Protected EAP Protocol (PEAP)", draft- 409 josefsson-pppext-eap-tls-eap-06.txt, March 2003. 411 [PEAP-MPPE] 412 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 413 PEAP/e75b0385-915a-4fc3-a549-fd3d06b995b0 415 [PEAP-PRF] 416 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 417 PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df 419 [PEAP-TK] 420 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 421 PEAP/41288c09-3d7d-482f-a57f-e83691d4d246 423 [RFC1994] 424 Simpson, W., "PPP Challenge Handshake Authentication Protocol 425 (CHAP)", RFC 1994, August 1996. 427 [RFC2433] 428 Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC 2433, 429 October 1998. 431 [RFC2759] 432 Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, 433 January 2000. 435 [RFC4851] 436 Cam-Winget, N., et al, "The Flexible Authentication via Secure 437 Tunneling Extensible Authentication Protocol Method (EAP-FAST)", 438 RFC 4851, May 2007. 440 [RFC5281] 441 Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol 442 Tunneled Transport Layer Security Authenticated Protocol Version 0 443 (EAP-TTLSv0)", RFC 5281, August 2008. 445 Acknowledgments 447 Thanks to Jorge Vergara for a detailed review of the requirements for 448 various EAP types, and for assistance with interoperability testing. 450 Authors' Addresses 452 Alan DeKok 453 The FreeRADIUS Server Project 455 Email: aland@freeradius.org