idnits 2.17.1 draft-ietf-emu-tls-eap-types-05.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 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 RFC5, but the abstract doesn't seem to mention this, which it should. -- 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 mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- No information found for rfc5 - 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 (5 March 2022) is 783 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 206 == Unused Reference: 'RFC5247' is defined on line 698, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-emu-eap-tls13-18 -- 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 (~~), 4 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 5 March 2022 5 Category: Standards Track 6 Expires: September 05, 2022 8 TLS-based EAP types and TLS 1.3 9 draft-ietf-emu-tls-eap-types-05.txt 11 Abstract 13 EAP-TLS (RFC 5216) has been updated for TLS 1.3 in RFC 9190. Many 14 other EAP types also depend on TLS, such as FAST (RFC 4851), TTLS 15 (RFC 5281), TEAP (RFC 7170), and possibly many vendor specific EAP 16 methods. This document updates those methods in order to use the new 17 key derivation methods available in TLS 1.3. Additional changes 18 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.4.1. Client Certificates ............................ 8 68 2.5. PEAP ................................................ 9 69 2.5.1. Client Certificates ............................ 9 70 3. Application Data ......................................... 9 71 3.1. Identities .......................................... 11 72 4. Resumption ............................................... 13 73 5. Implementation Status .................................... 14 74 6. Security Considerations .................................. 14 75 6.1. Protected Success and Failure indicators ............ 15 76 7. IANA Considerations ...................................... 16 77 8. References ............................................... 17 78 8.1. Normative References ................................ 17 79 8.2. Informative References .............................. 18 81 1. Introduction 83 EAP-TLS has been updated for TLS 1.3 in [RFC9190]. Many other EAP 84 types also depend on TLS, such as FAST [RFC4851], TTLS [RFC5281], 85 TEAP [RFC7170], and possibly many vendor specific EAP methods such as 86 PEAP [PEAP]. All of these methods use key derivation functions which 87 are no longer applicable to TLS 1.3. As such, all of those methods 88 are incompatible with TLS 1.3. 90 This document updates those methods in order to be used with TLS 1.3. 91 These changes involve defining new key derivation functions. We also 92 discuss implementation issues in order to highlight differences 93 between TLS 1.3 and earlier versions of TLS. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2. Using TLS-based EAP methods with TLS 1.3 105 In general, all of the requirements of [RFC9190] apply to other EAP 106 methods that wish to use TLS 1.3. Unless otherwise required herein, 107 implementations of EAP methods that wish to use TLS 1.3 MUST follow 108 the guidelines in [RFC9190]. 110 There remain some differences between EAP-TLS and other TLS-based EAP 111 methods which necessitates this document. The main difference is 112 that [RFC9190] uses the EAP-TLS Type (value 0x0D) in a number of 113 calculations, whereas other method types will use their own Type 114 value instead of the EAP-TLS Type value. This topic is discussed 115 further below in Section 2. 117 An additional difference is that [RFC9190] Section 2.5 requires that 118 once the EAP-TLS handshake has completed, the EAP server sends a 119 protected success result indication. This indication is composed of 120 one octet (0x00) of application data. Other TLS-based EAP methods 121 also use this indicator, but only during resumption. When other TLS- 122 based EAP methods use full authentication, the indicator is not 123 needed, and is not used. This topic is explained in more detail 124 below, in Section 3 and Section 4. 126 Finally, the document includes clarifications on how various TLS- 127 based parameters are calculated when using TLS 1.3. These parameters 128 are different for each EAP method, so they are discussed separately. 130 2.1. Key Derivation 132 The key derivation for TLS-based EAP methods depends on the value of 133 the EAP Type as defined by [IANA] in the Extensible Authentication 134 Protocol (EAP) Registry. The most important definition is of the 135 Type field, as first defined in [RFC3748] Section 2: 137 Type = value of the EAP Method type 139 For the purposes of this specification, when we refer to logical 140 Type, we mean that the logical Type is defined to be 1 octet for 141 values smaller than 254 (the value for the Expanded Type), and when 142 Expanded EAP Types are used, the logical Type is defined to be the 143 concatenation of the fields required to define the Expanded Type, 144 including the Type with value 0xfe, Vendor-Id (in network byte order) 145 and Vendor-Type fields (in network byte order) defined in [RFC3748] 146 Section 5.7, as given below: 148 Type = 0xFE || Vendor-Id || Vendor-Type 150 This definition does not alter the meaning of Type in [RFC3748], or 151 change the structure of EAP packets. Instead, this definition allows 152 us to simplify references to EAP Types, by just using a logical 153 "Type" instead of referring to "the Type field or the Type field with 154 value 0xfe, plus the Vendor-ID and Vendor-Type". For example, the 155 value of Type for PEAP is simply 0x19. 157 Unless otherwise discussed below, the key derivation functions for 158 all TLS-based EAP Types are defined in [RFC9190] Section 2.3, and 159 reproduced here for clarity: 161 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 162 Type, 128) 163 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 164 Type, 64) 165 Session-Id = Type || Method-Id 166 MSK = Key_Material(0, 63) 167 EMSK = Key_Material(64, 127) 169 We note that these definitions re-use the EAP-TLS exporter labels, 170 and change the derivation only by adding a dependency on the logical 171 Type. The reason for this change is simplicity. There does not 172 appear to be compelling reasons to make the labels method-specific, 173 when they can just include the logical Type in the key derivation. 175 These definitions apply in their entirety to TTLS [RFC5281] and PEAP 176 as defined in [PEAP] and [MSPEAP]. Some definitions apply to FAST 177 and TEAP, with exceptions as noted below. 179 It is RECOMMENDED that vendor-defined TLS-based EAP methods use the 180 above definitions for TLS 1.3. There is no compelling reason to use 181 different definitions. 183 2.2. TEAP 185 [RFC7170] Section 5.2 gives a definition for the Inner Method Session 186 Key (IMSK), which depends on the TLS-PRF. When the inner methods 187 generates an EMSK, we update that definition for TLS 1.3 as: 189 IMSK = TLS-Exporter("TEAPbindkey@ietf.org", EMSK, 32) 191 If an inner method does not support export of an Extended Master 192 Session Key (EMSK), then IMSK is the MSK of the inner method as per 193 [RFC7170] Section 5.2. 195 For MSK and EMSK, TEAP [RFC7170] uses an inner tunnel EMSK to 196 calculate the outer EMSK. As such, those key derivations cannot use 197 the above derivation. 199 The other key derivations for TEAP are given here. All derivations 200 not given here are the same as given above in the previous section. 201 These derivations are also used for FAST, but using the FAST Type. 203 session_key_seed = TLS-Exporter("EXPORTER: session key seed", 204 Type, 40) 206 S-IMCK[0] = session_key_seed 207 For j = 1 to n-1 do 208 IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys", 209 S-IMCK[j-1] | IMSK[j], 60) 210 S-IMCK[j] = first 40 octets of IMCK[j] 211 CMK[j] = last 20 octets of IMCK[j] 213 Where | denotes concatenation. The outer MSK and EMSK are then 214 derived from the above definitions, as: 216 MSK = TLS-Exporter("EXPORTER: Session Key Generating Function", 217 S-IMCK[j], 64) 219 EMSK = TLS-Exporter("EXPORTER: Extended Session Key Generating Function", 220 S-IMCK[j], 64) 222 The TEAP Compound MAC defined in [RFC7170] Section 5.3 is updated to 223 use the definition of CMK[j] given above, which then leads to the 224 following definition 226 CMK = CMK[j] 228 Compound-MAC = MAC( CMK, BUFFER ) 230 where j is the number of the last successfully executed inner EAP 231 method. For TLS 1.3, the message authentication code (MAC) is 232 computed with the HMAC algorithm negotiated for HKDF in the key 233 schedule, as per section 7.1 of RFC 8446. The definition of BUFFER 234 is unchanged from [RFC7170] Section 5.3 236 2.3. FAST 238 For FAST, the session_key_seed is also part of the key_block, as 239 defined in [RFC4851] Section 5.1. 241 The definition of S-IMCK[n], MSK, and EMSK are the same as given 242 above for TEAP. We reiterate that the EAP-FAST Type must be used 243 when deriving the session_key_seed, and not the TEAP Type. 245 Unlike [RFC4851] Section 5.2, the definition of IMCK[j] places the 246 reference to S-IMCK after the textual label, and the concatenates the 247 IMSK instead of MSK. 249 EAP-FAST previously used a PAC, which is a session ticket that 250 contains a pre-shared key (PSK) along with other data. As TLS 1.3 251 allows session resumptuion using a PSK, the use of a PAC is 252 deprecated for EAP-FAST in TLS 1.3. PAC provisioning [RFC5422] is 253 also no longer part of EAP-FAST when TLS 1.3 is used. 255 The T-PRF given in [RFC4851] Section 5.5 is not used for TLS 1.3. 256 Instead, it is replaced with the TLS 1.3 TLS-Exporter function. 258 2.4. TTLS 260 [RFC5281] Section 11.1 defines an implicit challenge when the inner 261 methods of CHAP [RFC1994], MS-CHAP [RFC2433], or MS-CHAPv2 [RFC2759] 262 are used. The derivation for TLS 1.3 is instead given as 264 EAP-TTLS_challenge = TLS-Exporter("ttls challenge",, n) 266 There is no "context_value" ([RFC8446] Section 7.5) passed to the 267 TLS-Exporter function. The value "n" given here is the length of the 268 data required, which [RFC5281] requires it to be 17 octets for CHAP 269 (Section 11.2.2) and MS-CHAP-V2 (Section 11.2.4), and to be 9 octets 270 for Ms-CHAP (Section 11.2.3). 272 Note that unlike TLS 1.2 and earlier, the calculation of TLS-Exporter 273 depends on the length passed to it. Implementations therefore MUST 274 pass the correct length instead of passing a large length and 275 truncating the output. Any output calculated using a larger length 276 value, and which is then truncated, will be different from the output 277 which was calculated using the correct length. 279 2.4.1. Client Certificates 281 [RFC5281] Section 7.6 permits "Authentication of the client via 282 client certificate during phase 1, with no additional authentication 283 or information exchange required.". This practice is forbidden when 284 TTLS is used with TLS 1.3. If there is a requirement to use client 285 certificates with no inner tunnel methods, then EAP-TLS should be 286 used instead of TTLS. 288 The use of client certificates is still permitted when using TTLS 289 with TLS 1.3. However, if the client certificate is accepted, then 290 the EAP peer MUST proceed with additional authentication of Phase 2, 291 as per [RFC5281] Section 7.2 and following. If there is no Phase 2 292 data, then the EAP server MUST reject the session. 294 2.5. PEAP 296 When PEAP uses crypto binding, it uses a different key calculation 297 defined in [PEAP-MPPE] which consumes inner method keying material. 298 The pseudo-random function (PRF+) used here is not taken from the TLS 299 exporter, but is instead calculated via a different method which is 300 given in [PEAP-PRF]. That derivation remains unchanged in this 301 specification. 303 However, the key calculation uses a PEAP Tunnel Key [PEAP-TK] which 304 is defined as: 306 ... the TK is the first 60 octets of the Key_Material, as 307 specified in [RFC5216]: TLS-PRF-128 (master secret, "client EAP 308 encryption", client.random || server.random). 310 We note that this text does not define Key_Material. Instead, it 311 defines TK as the first octets of Key_Material, and gives a 312 definition of Key_Material which is appropriate for TLS versions 313 before TLS 1.3. 315 For TLS 1.3, the TK should be derived from the Key_Material defined 316 above in Section 2.1, instead of using the TLS-PRF-128 derivation 317 given above. 319 2.5.1. Client Certificates 321 As with TTLS, [PEAP] permits the use of client certificates in 322 addition to inner tunnel methods. 324 The use of client certificates is still permitted when using PEAP 325 with TLS 1.3. However, if the client certificate is accepted, then 326 the EAP peer MUST proceed with additional authentication of the inner 327 tunnel. If there is no inner tunnel authentication data, then the 328 EAP server MUST reject the session. 330 3. Application Data 332 Unlike previous TLS versions, TLS 1.3 can continue negotiation after 333 the initial TLS handshake has been completed, which TLS 1.3 calls the 334 "CONNECTED" state. Some implementations use a "TLS finished" 335 determination as an indication that TLS negotiation has completed, 336 and that an "inner tunnel" session can now be negotiated. This 337 assumption is not always correct with TLS 1.3. 339 Earlier TLS versions did not always send application data along with 340 the "TLS finished" method. It was then possible for implementations 341 to assume that a transition to "TLS finished" also meant that there 342 was no application data available, and that another round trip was 343 required. This assumption is not true with TLS 1.3, and applications 344 relying on that behavior will not operate correctly with TLS 1.3. 346 As a result, implementations MUST check for application data once the 347 TLS session has been established. This check MUST be performed 348 before proceeding with another round trip of TLS negotiation. If 349 application data is available, it MUST be processed according to the 350 relevant resumption and/or EAP type. 352 TLS 1.3 also permits NewSessionTicket messages to be sent before the 353 TLS "Finished", and after application data is sent. This change can 354 cause many implementations to fail in a number of different ways, due 355 to a reliance on implicit behavior seen in earlier TLS versions. 357 In order to correct this failure, we require that if the underlying 358 TLS connection is still performing negotiation, then implementations 359 MUST NOT send, or expect to receive application data in the TLS 360 session. Implementations MUST delay processing of application data 361 until such time as the TLS negotiation has finished. If the TLS 362 negotiation is successful, then the application data can be examined. 363 If the TLS negotiation is unsuccessful, then the application data is 364 untrusted, and therefore MUST be discarded without being examined. 366 The default for many TLS library implementations is to send a 367 NewSessionTicket message immediately after, or along with, the TLS 368 Finished message. This ticket could be used for resumption, even if 369 the "inner tunnel" authentication has not been completed. If the 370 ticket could be used, then it could allow a malicious EAP peer to 371 completely bypass the "inner tunnel" authentication. 373 Therefore, the EAP server MUST NOT permit any session ticket to 374 successfully resume authentication, unless the inner tunnel 375 authentication has completed successfully. The alternative would 376 allow an attacker to bypass authentication by obtaining a session 377 ticket, and then immediately closing the current session, and 378 "resuming" using the session ticket. 380 To protect against that attack, implementations SHOULD NOT send 381 NewSessionTicket messages until the "inner tunnel" authentication has 382 completed. There is no reason to send session tickets which will 383 later be invalidated or ignored. However, we recognize that this 384 suggestion may not always be possible to implement with some 385 available TLS libraries. As such, EAP servers MUST take care to 386 either invalidate or discard session tickets which are associated 387 with sessions that terminate in EAP Failure. 389 The NewSessionTicket message SHOULD also be sent along with other 390 application data, if possible. Sending that message alone prolongs 391 the packet exchange to no benefit. 393 [RFC9190] Section 2.5 requires a protected result indicator which 394 indicates that TLS negotiation has finished. Methods which use 395 "inner tunnel" methods MUST instead begin their "inner tunnel" 396 negotiation by sending Type-specific application data. 398 3.1. Identities 400 [RFC9190] Sections 2.1.3 and 2.1.7 recommend the use of anonymous 401 Network Access Identifiers (NAIs) [RFC7542] in the EAP Identity 402 Response packet. However, as EAP-TLS does not send application data 403 inside of the TLS tunnel, that specification does not address the 404 subject of "inner" identities in tunneled EAP methods. This subject 405 must, however, be addressed for the tunneled methods. 407 Using an anonymous NAI as per [RFC7542] Section 2.4 has two benefits. 408 First, an anonymous identity makes it more difficult to track users. 409 Second, an NAI allows the EAP session to be routed in an AAA 410 framework as described in [RFC7542] Section 3. 412 For the purposes of tunneled EAP methods, we can therefore view the 413 outer TLS layer as being mainly a secure transport layer. That 414 transport layer is responsible for getting the actual (inner) 415 authentication credentials securely from the EAP peer to the EAP 416 server. As the outer identity is often used as an anonymous routing 417 identifier for AAA ([RFC7542] Section 3), there is little reason for 418 it to be the same as the inner identity. We therefore have a few 419 recommendations on the inner identity, and its relationship to the 420 outer identity. 422 For the purpose of this section, we define the inner identity as the 423 identification information carried inside of the TLS tunnel. For 424 PEAP, that identity may be an EAP Response Identity. For TTLS, it 425 may be the User-Name attribute. Vendor-specific EAP methods which 426 use TLS will generally also have an inner identity. 428 Implementations MUST NOT use anonymous identities for the inner 429 identity. If anonymous network access is desired, eap peers MUST use 430 EAP-TLS without peer authentication, as per [RFC9190] section 2.1.5. 431 EAP servers MUST cause authentication to fail if an EAP peer uses an 432 anonymous "inner" identity for any TLS-based EAP method. 434 Implementations SHOULD NOT use inner identities which contain an NAI 435 realm. The outer identity contains an NAI realm, which ensures that 436 the inner authentication method is routed to the correct destination. 437 As such, any NAI realm in the inner identity is almost always 438 redundant. 440 However, if the inner identity does contain an NAI realm, the inner 441 realm SHOULD be either an exact copy of the outer realm, or be a 442 subdomain of the outer realm. The inner realm SHOULD NOT be from a 443 different realm than the outer realm. There are very few reasons for 444 those realms to be different. 446 In general, routing identifiers should be associated with with the 447 authentication data that they are routing. For example, if a user 448 has an inner identity of "user@example.com", then it generally makes 449 no sense to have an outer identity of "@example.org". The 450 authentication request would then be routed to the "example.org" 451 domain, which may have no idea what to do with the credentials for 452 "user@example.com". At best, the authentication request would be 453 discarded. At worst, the "example.org" domain could harvest user 454 credentials for later use in attacks on "example.com". 456 In addition, associating disparate inner/outer identities in the same 457 EAP authentication session means that otherwise unrelated realms are 458 tied together, which can make networks more fragile. 460 For example, an organization which uses a "hosted" AAA provider may 461 choose to use the realm of the AAA provider as the outer identity. 462 The inner identity can then be fully qualified: user name plus realm 463 of the organization. This practice can result in successful 464 authentications, but it has difficulties. 466 Other organizations may host their own AAA servers, but use a "cloud" 467 identity provider to hold user accounts. In that situation, the 468 organizations may use their own realm as the outer (routing) 469 identity, then use an identity from the "cloud" provider as the inner 470 identity. This practice is NOT RECOMMENDED. User accounts for an 471 organization should be qualified as belonging to that organization, 472 and not to an unrelated third party. 474 Both of these practices mean that changing "cloud" providers is 475 difficult. When such a change happens, each individual supplicant 476 must be updated with a different outer identity which points to the 477 new "cloud" provider. This process can be expensive, and some 478 supplicants may not be online when this changeover happens. The 479 result could be devices or users who are unable to obtain network 480 access, even if all relevant network systems are online and 481 functional. 483 Further, standards such as [RFC7585] allow for dynamic discovery of 484 home servers for authentication. That specification has been widely 485 deployed, and means that there is minimal cost to routing 486 authentication to a particular domain. The authentication can also 487 be routed to a particular identity provider, and changed at will, 488 with no loss of functionality. That specification is also scalable, 489 in that it does not require changes to many systems when a domain 490 updates its configuration. Instead, only one thing has to change: 491 the configuration of that domain. Everything else is discovered 492 dynamically. 494 That is, changing the configuration for one domain is significantly 495 simpler and more scalable than changing the configuration for 496 potentially millions of end-user devices. 498 We recognize that there may be existing use-cases where the inner and 499 outer identities use different realms. As such, we cannot forbid 500 that practice. We hope that the discussion above shows not only why 501 such practices are problematic, but also that it shows how 502 alternative methods are more flexible, more scalable, and are easier 503 to manage. 505 4. Resumption 507 [RFC9190] Section 2.1.3 defines the process for resumption. This 508 process is the same for all TLS-based EAP types. The only practical 509 difference is that the value of the Type field is different. 511 Note that if resumption is performed, then the EAP server MUST send 512 the protected success result indicator (one octet of 0x00) inside the 513 TLS tunnel as per [RFC9190]. If either peer or server instead 514 initiates an inner tunnel method, then that method MUST be followed, 515 and resumption MUST NOT be used. The EAP peer MUST in turn check for 516 the existence the protected success result indicator (one octet of 517 0x00), and cause authentication to fail if that octet is not 518 received. 520 All TLS-based EAP methods support resumption, as it is a property of 521 the underlying TLS protocol. All EAP servers and peers MUST support 522 resumption for all TLS-based EAP methods. We note that EAP servers 523 and peers can still choose to not resume any particular session. For 524 example, EAP servers may forbid resumption for administrative, or 525 other policy reasons. 527 It is RECOMMENDED that EAP servers and peers enable resumption, and 528 use it where possible. The use of resumption decreases the number of 529 round trips used for authentication. This decrease leads to lower 530 latency for authentications, and less load on the EAP server. 531 Resumption can also lower load on external systems, such as databases 532 which contain user credentials. 534 As the packet flows for resumption are essentially identical across 535 all TLS-based EAP types, it is technically possible to authenticate 536 using EAP-TLS (Type 13), and then perform resumption using another 537 EAP type, just as EAP-TTLS (Type 21). However, there is no practical 538 benefit to doing so. It is also not clear what this behavior would 539 mean, or what (if any) security issues there may be with it. As a 540 result, this behavior is forbidden. 542 EAP servers therefore MUST NOT resume sessions across different EAP 543 Types, and EAP servers MUST reject resumptions in which the EAP Type 544 value is different from the original authentication. 546 5. Implementation Status 548 TTLS and PEAP are implemented and tested to be inter-operable with 549 wpa_supplicant 2.10 and Windows 11 as clients, and FreeRADIUS 3.0.26 550 and Radiator as RADIUS servers. 552 The wpa_supplicant implementation requires that a configuration flag 553 be set "tls_disable_tlsv1_3=0", and describes the flag as "enable 554 TLSv1.3 (experimental - disabled by default)". However, 555 interoperability testing shows that PEAP and TTLS both work with 556 Radiator and FreeRADIUS. 558 Implementors have demonstrated significant interest in getting PEAP 559 and TTLS working for TLS 1.3, but less interest in EAP-FAST and TEAP. 560 As such, there is no implementation experience with EAP-FAST or TEAP. 561 However, we believe that the definitions described above are correct, 562 and are workable. 564 6. Security Considerations 566 [RFC9190] Section 5 is included here by reference. 568 Updating the above EAP methods to use TLS 1.3 is of high importance 569 for the Internet Community. Using the most recent security protocols 570 can significantly improve security and privacy of a network. 572 In some cases, client certificates are not used for TLS-based EAP 573 methods. In those cases, the user is authenticated only after 574 successful completion of the inner tunnel authentication. However, 575 the TLS protocol may send one or more NewSessionTicket after 576 receiving the TLS Finished message from the client, and therefore 577 before the user is authenticated. 579 This separation of data allows for a "time of use, time of check" 580 security issue. Malicious clients can begin a session and receive a 581 NewSessionTicket. The malicious client can then abort the 582 authentication session, and the obtained NewSessionTicket to "resume" 583 the previous session. 585 As a result, EAP servers MUST NOT permit sessions to be resumed until 586 after authentication has successfully completed. This requirement 587 may be met in a number of ways. For example, by not caching the 588 session ticket until after authentication has completed, or by 589 marking up the cached session ticket with a flag stating whether or 590 not authentication has completed. 592 For PEAP, some derivations use HMAC-SHA1 [PEAP-MPPE]. In the 593 interests of interoperability and minimal changes, we do not change 594 that derivation, as there are no known security issues with HMAC- 595 SHA1. Further, the data derived from the HMAC-SHA1 calculations is 596 exchanged inside of the TLS tunnel, and is visible only to users who 597 have already successfully authenticated. As such, the security risks 598 are minimal. 600 6.1. Protected Success and Failure indicators 602 [RFC9190] provides for protected success and failure indicators as 603 discussed in Section 4.1.1 of [RFC4137]. These indicators are 604 provided for both full authentication, and for resumption. 606 Other TLS-based EAP methods provide these indicators only for 607 resumption. 609 For full authentication, the other TLS-based EAP methods do not 610 provide for protected success and failure indicators as part of the 611 outer TLS exchange. That is, the protected result indicator is not 612 used, and there is no TLS-layer alert sent when the inner 613 authentication fails. Instead, there is simply either an EAP-Success 614 or EAP-Failure sent. This behavior is the same as for previous TLS 615 versions, and therefore introduces no new security issues. 617 We note that most TLS-based EAP methods provide for success and 618 failure indicators as part of the authentication exchange performed 619 inside of the TLS tunnel. These indicators are therefore protected, 620 as they cannot be modified or forged. 622 However, some inner methods do not provide for success or failure 623 indicators. For example, the use of TTLS with inner PAP or CHAP. 624 Those methods send authentication credentials to the server via the 625 inner tunnel, with no method to signal success or failure inside of 626 the tunnel. 628 There are functionally equivalent authentication methods which can be 629 used to provide protected indicators. PAP can often be replaced with 630 EAP-GTC, and CHAP with EAP-MD5. Both replacement methods provide for 631 similar functionality, and have protected success and failure 632 indicator. The main cost to this change is additional round trips. 634 It is RECOMMENDED that implementations deprecate inner tunnel methods 635 which do not provided protected success and failure indicators. 636 Implementations SHOULD use EAP-GTC instead of PAP, and EAP-MD5 637 instead of CHAP. New TLS-based EAP methods MUST provide protected 638 success and failure indicators inside of the TLS tunnel. 640 When the inner authentication protocol indicates that authentication 641 has failed, then implementations MUST fail authentication for the 642 entire session. There MAY be additional protocol exchanges in order 643 to exchange more detailed failure indicators, but the final result 644 MUST be a failed authentication. As noted earlier, any session 645 tickets for this failed authentication MUST be either invalidated or 646 discarded. 648 Similarly, when the inner authentication protocol indicates that 649 authentication has succeed, then implementations SHOULD cause 650 authentication to succeed for the entire session. There MAY be 651 additional protocol exchanges in order which could cause other 652 failures, so success is not required here. 654 In both of these cases, the EAP server MUST send an EAP-Failure or 655 EAP-Success message, as indicated by Section 2, item 4 of [RFC3748]. 656 Even though both parties have already determined the final 657 authentication status, the full EAP state machine must still be 658 followed. 660 7. IANA Considerations 662 This section provides guidance to the Internet Assigned Numbers 663 Authority (IANA) regarding registration of values related to the TLS- 664 based EAP methods for TLS 1.3 protocol in accordance with [RFC8126]. 666 This memo requires IANA to add the following labels to the TLS 667 Exporter Label Registry defined by [RFC5705]. These labels are used 668 in the derivation of Key_Material and Method-Id as defined above in 669 Section 2. 671 The labels below need to be added to the "TLS Exporter Labels" 672 registry. These labels are used only for TEAP. 674 * EXPORTER: session key seed 675 * EXPORTER: Inner Methods Compound Keys 676 * EXPORTER: Session Key Generating Function 677 * EXPORTER: Extended Session Key Generating Function 678 * TEAPbindkey@ietf.org 680 8. References 682 8.1. Normative References 684 [RFC2119] 685 Bradner, S., "Key words for use in RFCs to Indicate Requirement 686 Levels", RFC 2119, March, 1997, . 689 [RFC3748] 690 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 691 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 692 June 2004. 694 [RFC5216] 695 Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication 696 Protocol", RFC 5216, March 2008 698 [RFC5247] 699 Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication 700 Protocol (EAP) Key Management Framework", RFC 5247, August 2008, 702 [RFC5705] 703 Rescorla, E., "Keying Material Exporters for Transport Layer 704 Security (TLS)", RFC 5705, March 2010 706 [RFC7170] 707 Zhou, H., et al., "Tunnel Extensible Authentication Protocol (TEAP) 708 Version 1", RFC 7170, May 2014. 710 [RFC8126] 711 Cotton, M., et al, "Guidelines for Writing an IANA Considerations 712 Section in RFCs", RC 8126, June 2017. 714 [RFC8174] 715 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 716 Words", RFC 8174, May 2017, . 719 [RFC8446] 720 Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 721 1.3", RFC 8446, August 2018. 723 [RFC9190] 724 Mattsson, J., and Sethi, M., "Using EAP-TLS with TLS 1.3", draft- 725 ietf-emu-eap-tls13-18, July 2021. 727 [IANA] 728 https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap- 729 numbers-4 731 8.2. Informative References 733 [MSPEAP] 734 https://msdn.microsoft.com/en-us/library/cc238354.aspx 736 [PEAP] 737 Palekar, A. et al, "Protected EAP Protocol (PEAP)", draft- 738 josefsson-pppext-eap-tls-eap-06.txt, May 2003. 740 [PEAP-MPPE] 741 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 742 PEAP/e75b0385-915a-4fc3-a549-fd3d06b995b0 744 [PEAP-PRF] 745 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 746 PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df 748 [PEAP-TK] 749 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 750 PEAP/41288c09-3d7d-482f-a57f-e83691d4d246 752 [RFC1994] 753 Simpson, W., "PPP Challenge Handshake Authentication Protocol 754 (CHAP)", RFC 1994, August 1996. 756 [RFC2433] 757 Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC 2433, 758 October 1998. 760 [RFC2759] 761 Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, 762 January 2000. 764 [RFC4137] 765 Vollbrecht, J., et al, "State Machines for Extensible 766 Authentication Protocol (EAP) Peer and Authenticator ", RFC 4137, 767 August 2005. 769 [RFC4851] 770 Cam-Winget, N., et al, "The Flexible Authentication via Secure 771 Tunneling Extensible Authentication Protocol Method (EAP-FAST)", 772 RFC 4851, May 2007. 774 [RFC5281] 775 Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol 776 Tunneled Transport Layer Security Authenticated Protocol Version 0 777 (EAP-TTLSv0)", RFC 5281, August 2008. 779 [RFC5422] 780 Cam-Winget, N., et al, "Dynamic Provisioning Using Flexible 781 Authentication via Secure Tunneling Extensible Authentication 782 Protocol (EAP-FAST)", RFC 5422, March 2009. 784 [RFC7542] 785 DeKoK, A, "The Network Access Identifier", RFC 7542, May 2015. 787 [RFC7585] 788 Winter, S, and McCauley, M., "Dynamic Peer Discovery for RADIUS/TLS 789 and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC 790 7585, October 2015. 792 Acknowledgments 794 Thanks to Jorge Vergara for a detailed review of the requirements for 795 various EAP types. 797 Thanks to Jorge Vergara, Bruno Periera Vidal, Alexander Clouter, 798 Karri Huhtanen, and Heikki Vatiainen for reviews of this document, 799 and for assistance with interoperability testing. 801 Authors' Addresses 803 Alan DeKok 804 The FreeRADIUS Server Project 806 Email: aland@freeradius.org