idnits 2.17.1 draft-dekok-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 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 (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 (25 March 2020) is 1491 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 180 == 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 (==), 6 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 5 Category: Standards Track 6 7 25 March 2020 9 TLS-based EAP types and TLS 1.3 10 draft-dekok-emu-tls-eap-types-01.txt 12 Abstract 14 EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS]. Many 15 other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as 16 FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], and possibly many 17 vendor specific EAP methods. This document updates those methods in 18 order to use the new key derivation methods available in TLS 1.3. 19 Additional changes necessitated by TLS 1.3 are also discussed. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on October 25, 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info/) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction ............................................. 4 62 1.1. Requirements Language ............................... 4 63 2. Using TLS-based EAP methods with TLS 1.3 ................. 5 64 2.1. Key Derivation ...................................... 5 65 2.2. FAST and TEAP ....................................... 6 66 3. Application Data ......................................... 7 67 4. Security Considerations .................................. 7 68 5. IANA Considerations ...................................... 8 69 6. References ............................................... 8 70 6.1. Normative References ................................ 8 71 6.2. Informative References .............................. 9 73 1. Introduction 75 EAP-TLS is being updated for TLS 1.3 in [EAPTLS]. Many other EAP 76 types also depend on TLS, such as FAST [RFC4851], TTLS [RFC5281], 77 TEAP [RFC7170], and possibly many vendor specific EAP methods. All 78 of these methods use key derivation functions that rely on the 79 information which is no longer available in TLS 1.3. As such, all of 80 those methods are incompatible with TLS 1.3. 82 We wish to enable the use of TLS 1.3 in the wider Internet community. 83 As such, it is necessary to update the above EAP types. These 84 changes involve defining new key derivation functions. We also 85 discuss implementation issues in order to highlight differences 86 between TLS 1.3 and earlier versions of TLS. 88 1.1. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in BCP 93 14 [RFC2119] [RFC8174] when, and only when, they appear in all 94 capitals, as shown here. 96 2. Using TLS-based EAP methods with TLS 1.3 98 In general, all of the requirements of [EAPTLS] apply to other EAP 99 methods that wish to use TLS 1.3. Implementations of other methods 100 that wish to use TLS 1.3 MUST follow the guidelines in [EAPTLS]. 102 There are, however a few key differences between EAP-TLS and other 103 TLS-based EAP methods that necessitate this document. The simplest 104 difference is that [EAPTLS] uses the EAP-TLS type ID (0x0D) in a 105 number of calculations. That value should change for other method 106 types. 108 More complex differences include derivation of additional keying 109 material, as in FAST [RFC4851]. 111 2.1. Key Derivation 113 The key derivation for TLS-based EAP methods depends on the value of 114 the Type-Code as defined by [IANA]. The most important definition is 115 of the Type-Code: 117 Type-Code = EAP Method type 119 The Type-Code is defined to be 1 octet for values smaller than 255. 120 Where expanded EAP Type Codes are used, the Type-Code is defined to 121 be the Expanded Type Code (including the Type, Vendor-Id (in network 122 byte order) and Vendor-Type fields (in network byte order) defined in 123 [RFC3748] Section 5.7). 125 Type-Code = 0xFE || Vendor-Id || Vendor-Type 127 Unless otherewise discussed below, the key derivation functions for 128 all TLS-based EAP types are defined as follows: 130 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 131 Type-Code, 128) 132 IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", Type-Code, 64) 133 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 134 Type-Code, 64) 135 Session-Id = Type-Code || Method-Id 136 MSK = Key_Material(0, 63) 137 EMSK = Key_Material(64, 127) 138 Enc-RECV-Key = MSK(0, 31) 139 Enc-SEND-Key = MSK(32, 63) 140 RECV-IV = IV(0, 31) 141 SEND-IV = IV(32, 63) 143 We note that these definitions re-use the EAP-TLS exporter labels, 144 and change the derivation only by adding a dependency on Type-Code. 145 The reason for this change is simplicity. There does not appear to 146 be compelling reasons to make the labels method-specific, when we can 147 just include the Type-Code in the key derivation. 149 These definitions apply in their entirety to TTLS [RFC5281] and PEAP 150 as defined in [PEAP] and [MSPEAP]. Some definitions apply to FAST 151 and TEAP, with exceptions as noted below. 153 It is RECOMMENDED that vendor-defined TLS-based EAP methods use the 154 above definitions for TLS 1.3. 156 2.2. FAST and TEAP 158 EAP-FAST [RFC4851] and TEAP [RFC7170] cannot use the above 159 derivation. Those methods use an inner tunnel EMSK to calculate the 160 outer EMSK. As such, those key derivations cannot use the above 161 derivation. 163 EAP-FAST previously used a PAC, which is a type of pre-shared key 164 (PSK). Such uses are deprecated in TLS 1.3. As such, PAC 165 provisioning is no longer part of EAP-FAST when TLS 1.3 is used. 167 TBD: Is this true? Comments from EAP-FAST people are useful here. 169 The key derivation for FAST and TEAP are similar enough that they 170 gave be given together here. The only difference is the Type-Code. 171 All derivations not given here are the same as given above in the 172 previous section. 174 session_key_seed = TLS-Exporter("EXPORTER: session key seed", Type- 175 Code, 40) 177 For FAST, the session_key_seed is also used as the key_block, as 178 defined in [RFC4851] Section 5.1. 180 S-IMCK[0] = session_key_seed 181 For j = 1 to n-1 do 182 IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound 183 Keys", S-IMCK[j-1] | MSK[j], 60) 184 S-IMCK[j] = first 40 octets of IMCK[j] 185 CMK[j] = last 20 octets of IMCK[j] 187 Where | denotes concatenation. 189 MSK = TLS-Exporter("EXPORTER: Session Key Generating Function", S- 190 IMCK[j], 64) EMSK = TLS-Exporter("EXPORTER: Extended Session Key 191 Generating Function", S-IMCK[j], 64) 193 3. Application Data 195 Unlike previous TLS version, TLS 1.3 continues negotiation after the 196 TLS session has been initialized. Some implementations use the TLS 197 "Finished" state as a signal that application data is now available, 198 and an "inner tunnel" session can now be negotiated. As noted in 199 [RFC8446], TLS 1.3 may include a "NewSessionTicket" after the 200 "Finished" state. This change can cause many implementations to 201 fail. 203 In order to correct this failure, implementations MUST also check if 204 "Application Data" is available for a TLS connection. If the 205 underlying TLS connection is still performing negotiations, then 206 implementations MUST NOT send, or expect to receive application data 207 in the TLS session. 209 We note that some TLS Application Programming Interfaces (APIs) 210 signal the availability of application data by returning zero octets 211 of application data, where they previously had returned an error 212 which signalled that negotiation should continue. For those APIs, 213 implementations SHOULD treat the combination of the "Finished" state 214 and the availability of zero octets of application data as a signal 215 that TLS negotiation has completed, and that the tunneled process can 216 begin. 218 [EAPTLS] uses an empty application record to indicate that 219 negotiation has finished. Methods which use "inner tunnel" methods 220 should instead begin their "inner tunnel" negotiation by sending 221 type-specific application data. 223 4. Security Considerations 225 [EAPTLS] Section 5 is included here by reference. 227 Updating the above EAP methods to use TLS 1.3 is of high importance 228 for the Internet Community. Using the most recent security protocols 229 can significantly improve security and privace of a network. 231 In some cases, client certificates are not used for TLS-based EAP 232 methods. In those cases, the user is authenticated only after 233 successful completion of the inner tunnel authentication. However, 234 the TLS protocol sends a NewSessionTicket after receiving the TLS 235 Finished message from the client, and therefore before the user is 236 authenticated. 238 This separation of data allows for a "time of use, time of check" 239 security issue. Malicious clients can begin a session and receive 240 the NewSessionTicket. Then prior to authentication, the malicious 241 client can abort the authentication session. The malicious client 242 can then use the obtained NewSessionTicket to "resume" the previous 243 session. 245 As a result, EAP servers MUST NOT permit sessions to be resumed until 246 after authentication has successfully completed. This requirement 247 may be met in a number of ways. For example, by not caching the 248 session ticket until after authentication has completed, or by 249 marking up the cached session ticket with a flag stating whether or 250 not authentication has completed. 252 5. IANA Considerations 254 This section provides guidance to the Internet Assigned Numbers 255 Authority (IANA) regarding registration of values related to the TLS- 256 based EAP methods for TLS 1.3 protocol in accordance with [RFC8126]. 258 This memo requires IANA to add the following labels to the TLS 259 Exporter Label Registry defined by [RFC5705]. These labels are used 260 in derivation of Key_Material, IV and Method-Id as defined above in 261 Section ? 263 The labels above need to be added to the "TLS Exporter Labels" 264 registry. 266 * TBD 268 6. References 270 6.1. Normative References 272 [RFC2119] 273 Bradner, S., "Key words for use in RFCs to Indicate Requirement 274 Levels", RFC 2119, March, 1997, . 277 [RFC3748] 278 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 279 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 280 June 2004. 282 [RFC5216] 283 Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication 284 Protocol", RFC 5216, March 2008 286 [RFC5247] 287 Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication 288 Protocol (EAP) Key Management Framework", RFC 5247, August 2008, 290 [RFC5705] 291 Rescorla, E., "Keying Material Exporters for Transport Layer 292 Security (TLS)", RFC 5705, March 2010 294 [RFC7170] 295 Zhou, H., et al., "Tunnel Extensible Authentication Protocol (TEAP) 296 Version 1", RFC 7170, May 2014. 298 [RFC8126] 299 Cotton, M., et al, "Guidelines for Writing an IANA Considerations 300 Section in RFCs", RC 8126, June 2017. 302 [RFC8174] 303 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 304 Words", RFC 8174, May 2017, . 307 [RFC8446] 308 Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 309 1.3", RFC 8446, August 2018. 311 [EAPTLS] 312 Mattsson, J., and Sethi, M., "Using EAP-TLS with TLS 1.3", draft- 313 ietf-emu-eap-tls13-03, November 2018. 315 [IANA] 316 https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap- 317 numbers-4 319 6.2. Informative References 321 [PEAP] 322 Palekar, A. et al, "Protected EAP Protocol (PEAP)", draft- 323 josefsson-pppext-eap-tls-eap-06.txt, March 2003. 325 [MSPEAP] 326 https://msdn.microsoft.com/en-us/library/cc238354.aspx 328 [RFC4851] 329 Cam-Winget, N., et al, "The Flexible Authentication via Secure 330 Tunneling Extensible Authentication Protocol Method (EAP-FAST)", 331 RFC 4851, May 2007. 333 [RFC5281] 334 Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol 335 Tunneled Transport Layer Security Authenticated Protocol Version 0 336 (EAP-TTLSv0)", RFC 5281, August 2008. 338 Authors' Addresses 340 Alan DeKok 341 The FreeRADIUS Server Project 343 Email: aland@freeradius.org