idnits 2.17.00 (12 Aug 2021) /tmp/idnits16280/draft-ietf-emu-tls-eap-types-04.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** 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: ---------------------------------------------------------------------------- -- 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 January 2022) is 119 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 199 == Outdated reference: draft-ietf-emu-eap-tls13 has been published as RFC 9190 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-06 Summary: 2 errors (**), 0 flaws (~~), 2 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 January 2022 5 Category: Standards Track 6 Expires: July 21, 2022 8 TLS-based EAP types and TLS 1.3 9 draft-ietf-emu-tls-eap-types-04.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) 2022 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 ......................................... 9 69 3.1. Identities .......................................... 10 70 4. Resumption ............................................... 12 71 5. Implementation Status .................................... 12 72 6. Security Considerations .................................. 13 73 6.1. Protected Success and Failure indicators ............ 14 74 7. IANA Considerations ...................................... 15 75 8. References ............................................... 15 76 8.1. Normative References ................................ 15 77 8.2. Informative References .............................. 16 79 1. Introduction 81 EAP-TLS is being updated for TLS 1.3 in [EAPTLS]. Many other EAP 82 types also depend on TLS, such as FAST [RFC4851], TTLS [RFC5281], 83 TEAP [RFC7170], and possibly many vendor specific EAP methods such as 84 PEAP [PEAP]. All of these methods use key derivation functions which 85 are no longer applicable to TLS 1.3. As such, all of those methods 86 are incompatible with TLS 1.3. 88 We wish to enable the use of TLS 1.3 in the wider Internet community. 89 As such, it is necessary to update the above EAP Types. These 90 changes involve defining new key derivation functions. We also 91 discuss implementation issues in order to highlight differences 92 between TLS 1.3 and earlier versions of TLS. 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 2. Using TLS-based EAP methods with TLS 1.3 104 In general, all of the requirements of [EAPTLS] apply to other EAP 105 methods that wish to use TLS 1.3. Unless otherwise required herein, 106 implementations of EAP methods that wish to use TLS 1.3 MUST follow 107 the guidelines in [EAPTLS]. 109 There remain some differences between EAP-TLS and other TLS-based EAP 110 methods which necessitates this document. The main difference is 111 that [EAPTLS] uses the EAP-TLS Type (value 0x0D) in a number of 112 calculations, whereas other method types will use their own Type 113 value instead of the EAP-TLS Type value. This topic is discussed 114 further below in Section 2. 116 An additional difference is that [EAPTLS] Section 2.5 requires that 117 once the EAP-TLS handshake has completed, the EAP server sends a 118 protected success result indication. This indication is composed of 119 one octet (0x00) of application data. Other TLS-based EAP methods 120 also use this indicator, but only during resumption. When other TLS- 121 based EAP methods use full authentication, the indicator is not 122 needed, and is not used. This topic is explained in more detail 123 below, in Section 3. 125 Finally, the document includes clarifications on how various TLS- 126 based parameters are calculated when using TLS 1.3. These parameters 127 are different for each EAP method, so they are discussed separately. 129 2.1. Key Derivation 131 The key derivation for TLS-based EAP methods depends on the value of 132 the EAP Type as defined by [IANA] in the Extensible Authentication 133 Protocol (EAP) Registry. The most important definition is of the 134 Type field, as first defined in [RFC3748] Section 2: 136 Type = value of the EAP Method type 138 For the purposes of this specification, when we refer to logical 139 Type, we mean that the logical Type is defined to be 1 octet for 140 values smaller than 254 (the value for the Expanded Type), and when 141 Expanded EAP Types are used, the logical Type is defined to be the 142 concatetation of the fields required to define the Expanded Type, 143 including the Type with value 0xfe, Vendor-Id (in network byte order) 144 and Vendor-Type fields (in network byte order) defined in [RFC3748] 145 Section 5.7, as given below: 147 Type = 0xFE || Vendor-Id || Vendor-Type 149 This definition does not alter the meaning of Type in [RFC3748], or 150 change the structure of EAP packets. Instead, this definition allows 151 us to simplify references to EAP Types, by just using a logical 152 "Type" instead of referring to "the Type field or the Type field with 153 value 0xfe, plus the Vendor-ID and Vendor-Type". 155 Unless otherwise discussed below, the key derivation functions for 156 all TLS-based EAP Types are defined as follows: 158 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 159 Type, 128) 160 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 161 Type, 64) 162 Session-Id = Type || Method-Id 163 MSK = Key_Material(0, 63) 164 EMSK = Key_Material(64, 127) 166 We note that these definitions re-use the EAP-TLS exporter labels, 167 and change the derivation only by adding a dependency on the logical 168 Type. The reason for this change is simplicity. There does not 169 appear to be compelling reasons to make the labels method-specific, 170 when they can just include the logical Type in the key derivation. 172 These definitions apply in their entirety to TTLS [RFC5281] and PEAP 173 as defined in [PEAP] and [MSPEAP]. Some definitions apply to FAST 174 and TEAP, with exceptions as noted below. 176 It is RECOMMENDED that vendor-defined TLS-based EAP methods use the 177 above definitions for TLS 1.3. There is no compelling reason to use 178 different definitions. 180 2.2. TEAP 182 [RFC7170] Section 5.2 gives a definition for the Inner Method Session 183 Key (IMSK), which depends on the TLS-PRF. We update that definition 184 for TLS 1.3 as: 186 IMSK = TLS-Exporter("TEAPbindkey@ietf.org", EMSK, 32) 188 For MSK and EMSK, TEAP [RFC7170] uses an inner tunnel EMSK to 189 calculate the outer EMSK. As such, those key derivations cannot use 190 the above derivation. 192 The other key derivations for TEAP are given here. All derivations 193 not given here are the same as given above in the previous section. 194 These derivations are also used for FAST, but using the FAST Type. 196 session_key_seed = TLS-Exporter("EXPORTER: session key seed", 197 Type, 40) 199 S-IMCK[0] = session_key_seed 200 For j = 1 to n-1 do 201 IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys", 202 S-IMCK[j-1] | IMSK[j], 60) 203 S-IMCK[j] = first 40 octets of IMCK[j] 204 CMK[j] = last 20 octets of IMCK[j] 206 Where | denotes concatenation. MSK and EMSK are then derived from 207 the above definitions, as: 209 MSK = TLS-Exporter("EXPORTER: Session Key Generating Function", 210 S-IMCK[j], 64) 212 EMSK = TLS-Exporter("EXPORTER: Extended Session Key Generating Function", 213 S-IMCK[j], 64) 215 The TEAP Compound MAC defined in [RFC7170] Section 5.3 is updated to 216 use the definition of CMK[j] given above, which then leads to the 217 following definition 219 CMK = CMK[j] 221 Compound-MAC = MAC( CMK, BUFFER ) 223 where j is the number of the last successfully executed inner EAP 224 method. For TLS 1.3, the hash function used is the same as the 225 ciphersuite hash function negotiated for HKDF in the key schedule, as 226 per section 7.1 of RFC 8446. The definition of BUFFER is unchanged 227 from [RFC7170] Section 5.3 229 2.3. FAST 231 For FAST, the session_key_seed is also used as the key_block, as 232 defined in [RFC4851] Section 5.1. 234 The definition of S-IMCK[n], MSK, and EMSK are the same as given 235 above for TEAP. We reiterate that the EAP-FAST Type must be used 236 when deriving the session_key_seed, and not the TEAP Type. 238 Unlike [RFC4851] Section 5.2, the definition of IMCK[j] places the 239 reference to S-IMCK after the textual label, and the concatenates the 240 IMSK instead of MSK. 242 EAP-FAST previously used a PAC, which is a type of pre-shared key 243 (PSK). Such uses are deprecated in TLS 1.3. As such, PAC 244 provisioning is no longer part of EAP-FAST when TLS 1.3 is used. 246 The T-PRF given in [RFC4851] Section 5.5 is not used for TLS 1.3. 248 2.4. TTLS 250 [RFC5281] Section 11.1 defines an implicit challenge when the inner 251 methods of CHAP [RFC1994], MS-CHAP [RFC2433], or MS-CHAPv2 [RFC2759] 252 are used. The derivation for TLS 1.3 is instead given as 254 EAP-TTLS_challenge = TLS-Exporter("ttls challenge",, n) 256 There no "context_value" ([RFC8446] Section 7.5) passed to the TLS- 257 Exporter function. The value "n" given here is the length of the 258 data required, which [RFC5281] requires it to be 17 octets for CHAP 259 (Section 11.2.2) and MS-CHAP-V2 (Section 11.2.4), and to be 9 octets 260 for Ms-CHAP (Section 11.2.3). 262 Note that unlike TLS 1.2 and earlier, the calculation of TLS-Exporter 263 depends on the length passed to it. Implementations therefore MUST 264 pass the correct length instead of passing a large length and 265 truncating the output. Any output calculated using a larger length 266 value, and which is then truncated, will be different from the output 267 which was calculated using the correct length. 269 2.5. PEAP 271 When PEAP uses crypto binding, it uses a different key calculation 272 defined in [PEAP-MPPE] which consumes inner method keying material. 273 The pseudo-random function (PRF) used here is not taken from the TLS 274 exporter, but is instead calculated via a different method which is 275 given in [PEAP-PRF]. That derivation remains unchanged in this 276 specification. 278 However, the key calculation uses a PEAP Tunnel Key [PEAP-TK] which 279 is defined as: 281 ... the TK is the first 60 octets of the Key_Material, as 282 specified in [RFC5216]: TLS-PRF-128 (master secret, "client EAP 283 encryption", client.random || server.random). 285 We note that this text does not define Key_Material. Instead, it 286 defines TK as the first octets of Key_Material, and gives a 287 definition of Key_Material which is appropriate for TLS versions 288 before TLS 1.3. 290 For TLS 1.3, the TK should be derived from the Key_Material defined 291 above in Section 2.1, instead of using the TLS-PRF-128 derivation 292 given above. 294 3. Application Data 296 Unlike previous TLS versions, TLS 1.3 can continue negotiation after 297 the initial TLS handshake has been completed, which TLS 1.3 calls the 298 "CONNECTED" state. Some implementations use a "TLS finished" 299 determination as an indication that TLS negotiation has completed, 300 and that an "inner tunnel" session can now be negotiated. This 301 assumption is not always correct with TLS 1.3. 303 Earlier TLS versions did not always send application data along with 304 the "TLS finished" method. It was then possible for implementations 305 to assume that a transition to "TLS finished" also meant that there 306 was no application data available, and that another round trip was 307 required. This assumption is not true with TLS 1.3, and applications 308 relying on that behavior will not operate correctly with TLS 1.3. 310 As a result, implementations MUST check for application data once the 311 TLS session has been established. This check MUST be performed 312 before proceeding with another round trip of TLS negotiation. If 313 application data is available, it MUST be processed according to the 314 relevant resumption and/or EAP type. 316 TLS 1.3 also permits NewSessionTicket messages to be sent before the 317 TLS "Finished", and after application data is sent. This change can 318 cause many implementations to fail in a number of different ways, due 319 to a reliance on implicit behavior seen in earlier TLS versions/ 321 In order to correct this failure, we require that if the underlying 322 TLS connection is still performing negotiation, then implementations 323 MUST NOT send, or expect to receive application data in the TLS 324 session. Implementations MUST delay processing of application data 325 until such time as the TLS negotiation has finished. If the TLS 326 negotiation is successful, then the application data can be examined. 327 If the TLS negotiation is unsuccessful, then the application data is 328 untrusted, and therefore MUST be discarded without being examined. 330 The default for many TLS library implementations is to send a 331 NewSessionTicket message immediately after, or along with, the TLS 332 Finished message. This ticket could be used for resumption, even if 333 the "inner tunnel" authentication has not been completed. If the 334 ticket could be used, then it could allow a malicious EAP peer to 335 completely bypass the "inner tunnel" authentication 337 Therefore, the EAP server MUST NOT permit any session ticket to 338 successfully resume authentication, unless the inner tunnel 339 authentication has completed successfully. The alternative would 340 allow an attacker to bypass authentication by obtaining a session 341 ticket, and then immediately closing the current session, and 342 "resuming" using the session ticket. 344 To protect against that attack, implementations SHOULD NOT send 345 NewSessionTicket messages until the "inner tunnel" authentication has 346 completed. There is no reason to send session tickets which will 347 later be invalidated or ignored. However, we recognize that this 348 suggestion may not always be possible to implement with some 349 available TLS libraries. As such, EAP servers MUST take care to 350 either invalidate or discard session tickets which are associated 351 with sessions that terminate in EAP Failure. 353 The NewSessionTicketMessage SHOULD also be sent along with other 354 application data, if possible. Sending that message alone prolongs 355 the packet exchange to no benefit. 357 [EAPTLS] Section 2.5 requires a protected result indicator which 358 indicates that TLS negotiation has finished. Methods which use 359 "inner tunnel" methods MUST instead begin their "inner tunnel" 360 negotiation by sending Type-specific application data. 362 3.1. Identities 364 [EAPTLS] Sections 2.1.3 and 2.1.7 recommend the use of anonymous 365 Network Access Identifiers (NAIs) [RFC7542] in the EAP Identity 366 Response packet. However, as EAP-TLS does not send application data 367 inside of the TLS tunnel, that specification does not address the 368 subject of "inner" identities in tunneled EAP methods. This subject, 369 however, must be addressed for the tunneled methods. 371 Using an anonymous NAI has two benefits. First, an anonymous identity 372 makes it more difficult to track users. Second, an NAI allows the 373 EAP session to be routed in an AAA framework. 375 For the purposes of tunneled EAP methods, we can therefore view the 376 outer TLS layer as being mainly a secure transport layer. That 377 transport layer is responsible for getting the actual (inner) 378 authentication credentials securely from the EAP peer to the EAP 379 server. As the outer identity is simply an anonymous routing 380 identifier, there is little reason for it to be the same as the inner 381 identity. We therefore have a few recommendations on the inner 382 identity, and its relationship to the outer identity. 384 For the purpose of this section, we define the inner identity as the 385 identification information carried inside of the TLS tunnel. For 386 PEAP, that identity may be an EAP Response Identity. For TTLS, it 387 may be the User-Name attribute. Vendor-specific EAP methods which 388 use TLS will generally also have an "inner" identity. 390 Implementations MUST NOT use anonymous identities for the inner 391 identity. If anonymous network access is desired, eap peers MUST use 392 EAP-TLS without peer authentication, as per [EAPTLS] section 2.1.5. 393 EAP servers MUST cause authentication to fail if an EAP peer uses an 394 anonymous "inner" identity for any TLS-based EAP method. 396 Implementations SHOULD NOT use inner identies which contain an NAI 397 realm. The outer identity contains an NAI realm, which ensures that 398 the inner authentication method is routed to the correct destination. 399 As such, any NAI realm in the inner identity is almost always 400 redundant. 402 However, if the inner identity does contain an NAI realm, the inner 403 realm SHOULD be either an exact copy of the outer realm, or be a 404 subdomain of the outer realm. The inner realm SHOULD NOT be from a 405 different realm than the outer realm. There are very few reasons for 406 those realms to be different. 408 In general, routing identifiers should be strongly tied to the data 409 which they are routing. Tying disparate identities together means 410 that different processes are artificially correlated, which makes 411 networks more fragile. 413 For example, an organization which uses a "hosted" AAA provider may 414 choose to use the realm of the AAA provider as the outer identity. 415 The inner identity can then be fully qualified (user name plus realm) 416 of the organization. This practice can result in successful 417 authentications, but it has difficulties. 419 Other organizations may host their own AAA servers, but use a "cloud" 420 identity provider to hold user accounts. In that situation, the 421 organizations may use their own realm as the outer (routing) 422 identity, then use an identity from the "cloud" provider as the inner 423 identity. This practice is NOT RECOMMENDED. User accounts for an 424 organization should be qualified as belonging to that organization, 425 and not to an unrelated third party. 427 Both of these practices mean that changing "cloud" providers is 428 difficult. When such a change happens, each individual supplicant 429 must be updated with new identies pointing to the new "cloude" 430 provider. This process can be expensive, and some supplicants may 431 not be online when this changover happens. The result could be 432 devices or users who are unable to obtain network access, even if all 433 relevant network systems are online and functional. 435 Further, standards such as [RFC7585] allow for dynamic discovery of 436 home servers for authentication. That specification has been widely 437 deployed, and means that there is minimal cost to routing 438 authentication to a particular domain. The authentication can also 439 be routed to a particular identity provider, and changed at will, 440 with no loss of functionality. That specification is also scalable, 441 in that it does not require changes to many systems when one domain 442 updates its configuration. 444 We recognize that there may be existing use-cases where these 445 identities use different realms. As such, we cannot forbid that 446 practice. We hope that the discussion above shows not only why such 447 practices are problematic, but also that it shows how alternative 448 methods are more flexible, and more scalable. 450 4. Resumption 452 [EAPTLS] Section 2.1.3 defines the process for resumption. This 453 process is the same for all TLS-based EAP types. The only practical 454 difference is that the value of the Type field is different. 456 All TLS-based EAP methods support resumption, as it is a property of 457 the underlying TLS protocol. All EAP servers and peers MUST support 458 resumption for all TLS-based EAP methods. We note that EAP servers 459 and peers can still choose to not resume any particular session. For 460 example, EAP servers may forbid resumption for administrative, or 461 other policy reasons. 463 It is RECOMMENDED that EAP servers and peers enable resumption, and 464 use it where possible. The use of resumption decreases the number of 465 round trips used for authentication. This decrease leads to lower 466 latency for authentications, and less load on the EAP server. 467 Resumption can also lower load on external systems, such as databases 468 which contain user credentials. 470 As the packet flows for resumption are essentially identical across 471 all TLS-based EAP types, it is technically possible to authenticate 472 using EAP-TLS (Type 13), and then perform resumption using another 473 EAP type, just as EAP-TTLS (Type 21). However, there is no practical 474 benefit to doing so. It is also not clear what this behavior would 475 mean, or what (if any) security issues there may be with it. As a 476 result, this behavior is forbidden. 478 EAP servers therefore MUST NOT resume sessions across different EAP 479 Types, and EAP servers MUST reject resumptions in which the EAP Type 480 value is different from the original authentication. 482 5. Implementation Status 484 TTLS and PEAP are implemented and tested to be inter-operable with 485 wpa_supplicant 2.10 and Windows 11 as clients, and FreeRADIUS 3.0.26 486 and Radiator as RADIUS servers. 488 The wpa_supplicant implementation requires that a configuration flag 489 be set "tls_disable_tlsv1_3=0", and describes the flag as "enable 490 TLSv1.3 (experimental - disabled by default)". However, 491 interoperability testing shows that PEAP and TTLS both work with 492 Radiator and FreeRADIUS. 494 Implementors have demonstrated significant interest in getting PEAP 495 and TTLS working for TLS 1.3, but less interest in EAP-FAST and TTLS. 496 As such, there is no implementation experience with EAP-FAST or TEAP. 497 However, we believe that the definitions described above are correct, 498 and are workable. 500 6. Security Considerations 502 [EAPTLS] Section 5 is included here by reference. 504 Updating the above EAP methods to use TLS 1.3 is of high importance 505 for the Internet Community. Using the most recent security protocols 506 can significantly improve security and privacy of a network. 508 In some cases, client certificates are not used for TLS-based EAP 509 methods. In those cases, the user is authenticated only after 510 successful completion of the inner tunnel authentication. However, 511 the TLS protocol may send one or more NewSessionTicket after 512 receiving the TLS Finished message from the client, and therefore 513 before the user is authenticated. 515 This separation of data allows for a "time of use, time of check" 516 security issue. Malicious clients can begin a session and receive a 517 NewSessionTicket. The malicious client can then abort the 518 authentication session, and the obtained NewSessionTicket to "resume" 519 the previous session. 521 As a result, EAP servers MUST NOT permit sessions to be resumed until 522 after authentication has successfully completed. This requirement 523 may be met in a number of ways. For example, by not caching the 524 session ticket until after authentication has completed, or by 525 marking up the cached session ticket with a flag stating whether or 526 not authentication has completed. 528 For PEAP, some derivations use HMAC-SHA1 [PEAP-MPPE]. In the 529 interests of interoperability and minimal changes, we do not change 530 that deriviation, as there are no known security issues with HMAC- 531 SHA1. Further, the data derived from the HMAC-SHA1 calculations is 532 exchanged inside of the TLS tunnel, and is visible only to users who 533 have already successfully authenticated. As such, the security risks 534 are minimal. 536 6.1. Protected Success and Failure indicators 538 [EAPTLS] provides for protected success and failure indicators as 539 discussed in Section 4.1.1 of [RFC4137]. These indicators are 540 provided for both full authentication, and for resumption. 542 Other TLS-based EAP methods provide these indicators only for 543 resumption. 545 For full authenticaton, the other TLS-based EAP methods do not 546 provide for protected success and failure indicators as part of the 547 outer TLS exchange. That is, the protected result indicator is not 548 used, and there is no TLS-layer alert sent when the inner 549 authentication fails. Instead, there is simply either an EAP-Success 550 or EAP-Failure sent. This behavior is the same as for previous TLS 551 versions, and therefore introduces no new security issues. 553 We note that most TLS-based EAP methods provide for success and 554 failure indicators as part of the authentication exchange performed 555 inside of the TLS tunnel. These indicators are therefore protected, 556 as they cannot be modified or forged. 558 However, some inner methods do not provide for success or failure 559 indicators. For example, the use of TTLS with inner PAP or CHAP. 560 Those methods send authentication credentials to the server via the 561 inner tunnel, with no method to signal success or failure inside of 562 the tunnel. 564 There are functionally equivalent authentication methods which can be 565 used to provide protected indicators. PAP can often be replaced with 566 EAP-GTC, and CHAP with EAP-MD5. Both replacement methods provide for 567 similar functionality, and have protected success and failure 568 indicator. The main cost to this change is additional round trips. 570 It is RECOMMENDED that implementations deprecate inner tunnel methods 571 which do not provided protected success and failure indicators. 572 Implementations SHOULD use EAP-GTC instead of PAP, and EAP-MD5 573 instead of CHAP. New TLS-based EAP methods MUST provide protected 574 success and failure indicators inside of the TLS tunnel. 576 When the inner authentication protocol indicates that authentication 577 has failed, then implementations MUST fail authentication for the 578 entire session. There MAY be additional protocol exchanges in order 579 to exchange more detailed failure indicators, but the final result 580 MUST be a failed authentication. As noted earlier, any session 581 tickets for this failed authentication MUST be either invalidated or 582 discarded. 584 Similarly, when the inner authentication protocol indicates that 585 authentication has succeeed, then implementations SHOULD cause 586 authentication to succeed for the entire session. There MAY be 587 additional protocol exchanges in order which could cause other 588 failures, so success is not required here. 590 In both of these cases, the EAP server MUST send an EAP-Failure or 591 EAP-Success message, as indicated by Section 2, item 4 of [RFC3748]. 592 Even though both parties have already determined the final 593 authentication status, the full EAP state machine must still be 594 followed. 596 7. IANA Considerations 598 This section provides guidance to the Internet Assigned Numbers 599 Authority (IANA) regarding registration of values related to the TLS- 600 based EAP methods for TLS 1.3 protocol in accordance with [RFC8126]. 602 This memo requires IANA to add the following labels to the TLS 603 Exporter Label Registry defined by [RFC5705]. These labels are used 604 in the derivation of Key_Material and Method-Id as defined above in 605 Section 2. 607 The labels below need to be added to the "TLS Exporter Labels" 608 registry. These labels are used only for TEAP. 610 * EXPORTER: session key seed 611 * EXPORTER: Inner Methods Compound Keys 612 * EXPORTER: Session Key Generating Function 613 * EXPORTER: Extended Session Key Generating Function 614 * TEAPbindkey@ietf.org 616 8. References 618 8.1. Normative References 620 [RFC2119] 621 Bradner, S., "Key words for use in RFCs to Indicate Requirement 622 Levels", RFC 2119, March, 1997, . 625 [RFC3748] 626 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 627 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 628 June 2004. 630 [RFC5216] 631 Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication 632 Protocol", RFC 5216, March 2008 634 [RFC5247] 635 Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication 636 Protocol (EAP) Key Management Framework", RFC 5247, August 2008, 638 [RFC5705] 639 Rescorla, E., "Keying Material Exporters for Transport Layer 640 Security (TLS)", RFC 5705, March 2010 642 [RFC7170] 643 Zhou, H., et al., "Tunnel Extensible Authentication Protocol (TEAP) 644 Version 1", RFC 7170, May 2014. 646 [RFC8126] 647 Cotton, M., et al, "Guidelines for Writing an IANA Considerations 648 Section in RFCs", RC 8126, June 2017. 650 [RFC8174] 651 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 652 Words", RFC 8174, May 2017, . 655 [RFC8446] 656 Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 657 1.3", RFC 8446, August 2018. 659 [EAPTLS] 660 Mattsson, J., and Sethi, M., "Using EAP-TLS with TLS 1.3", draft- 661 ietf-emu-eap-tls13-18, July 2021. 663 [IANA] 664 https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap- 665 numbers-4 667 8.2. Informative References 669 [MSPEAP] 670 https://msdn.microsoft.com/en-us/library/cc238354.aspx 672 [PEAP] 673 Palekar, A. et al, "Protected EAP Protocol (PEAP)", draft- 674 josefsson-pppext-eap-tls-eap-06.txt, March 2003. 676 [PEAP-MPPE] 677 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 678 PEAP/e75b0385-915a-4fc3-a549-fd3d06b995b0 680 [PEAP-PRF] 681 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 682 PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df 684 [PEAP-TK] 685 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 686 PEAP/41288c09-3d7d-482f-a57f-e83691d4d246 688 [RFC1994] 689 Simpson, W., "PPP Challenge Handshake Authentication Protocol 690 (CHAP)", RFC 1994, August 1996. 692 [RFC2433] 693 Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC 2433, 694 October 1998. 696 [RFC2759] 697 Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, 698 January 2000. 700 [RFC4137] 701 Vollbrecht, J., et al, "State Machines for Extensible 702 Authentication Protocol (EAP) Peer and Authenticator ", RFC 4137, 703 August 2005. 705 [RFC4851] 706 Cam-Winget, N., et al, "The Flexible Authentication via Secure 707 Tunneling Extensible Authentication Protocol Method (EAP-FAST)", 708 RFC 4851, May 2007. 710 [RFC5281] 711 Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol 712 Tunneled Transport Layer Security Authenticated Protocol Version 0 713 (EAP-TTLSv0)", RFC 5281, August 2008. 715 [RFC7542] 716 DeKoK, A, "The Network Access Identifier", RFC 7542, May 2015. 718 [RFC7585] 719 Winter, S, and McCauley, M., "Dynamic Peer Discovery for RADIUS/TLS 720 and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC 721 7585, October 2015. 723 Acknowledgments 725 Thanks to Jorge Vergara for a detailed review of the requirements for 726 various EAP types. 728 Thanks to Jorge Vergara, Bruno Periera Vidal, Alexander Clouter, 729 Karri Huhtanen, and Heikki Vatiainen for reviews of this document, 730 and for assistance with interoperability testing. 732 Authors' Addresses 734 Alan DeKok 735 The FreeRADIUS Server Project 737 Email: aland@freeradius.org