idnits 2.17.00 (12 Aug 2021) /tmp/idnits34228/draft-ietf-emu-eap-tls13-21.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1423): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5216, updated by this document, for RFC5378 checks: 2006-02-17) -- 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 (20 October 2021) is 206 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: '1' on line 997 -- Looks like a reference, but probably isn't: '2' on line 1001 -- Looks like a reference, but probably isn't: '3' on line 1008 -- Looks like a reference, but probably isn't: '4' on line 1014 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: draft-ietf-tls-md5-sha1-deprecate has been published as RFC 9155 == Outdated reference: draft-ietf-emu-eaptlscert has been published as RFC 9191 == Outdated reference: draft-ietf-tls-ticketrequests has been published as RFC 9149 == Outdated reference: A later version (-05) exists of draft-ietf-emu-tls-eap-types-03 == Outdated reference: A later version (-04) exists of draft-ietf-tls-rfc8446bis-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Preuß Mattsson 3 Internet-Draft M. Sethi 4 Updates: 5216 (if approved) Ericsson 5 Intended status: Standards Track 20 October 2021 6 Expires: 23 April 2022 8 Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) 9 draft-ietf-emu-eap-tls13-21 11 Abstract 13 The Extensible Authentication Protocol (EAP), defined in RFC 3748, 14 provides a standard mechanism for support of multiple authentication 15 methods. This document specifies the use of EAP-Transport Layer 16 Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible 17 with existing implementations of EAP-TLS. TLS 1.3 provides 18 significantly improved security and privacy, and reduced latency when 19 compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 20 1.3) further improves security and privacy by always providing 21 forward secrecy, never disclosing the peer identity, and by mandating 22 use of revocation checking, when compared to EAP-TLS with earlier 23 versions of TLS. This document also provides guidance on 24 authentication, authorization, and resumption for EAP-TLS in general 25 (regardless of the underlying TLS version used). This document 26 updates RFC 5216. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 23 April 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements and Terminology . . . . . . . . . . . . . . 4 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 5 65 2.1.1. Authentication . . . . . . . . . . . . . . . . . . . 6 66 2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 7 67 2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 9 68 2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 11 69 2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 14 70 2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 15 71 2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 16 72 2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 17 73 2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 18 74 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 18 75 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 19 76 2.4. Parameter Negotiation and Compliance Requirements . . . . 20 77 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 21 78 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 22 79 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 22 82 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 23 83 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 23 84 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 23 85 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 24 86 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 25 87 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 26 88 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 28 89 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 29 90 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 29 91 5.11. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 30 92 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 93 6.1. Normative References . . . . . . . . . . . . . . . . . . 30 94 6.2. Informative references . . . . . . . . . . . . . . . . . 31 95 Appendix A. Updated References . . . . . . . . . . . . . . . . . 36 96 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36 97 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 36 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 100 1. Introduction 102 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 103 provides a standard mechanism for support of multiple authentication 104 methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies 105 an EAP authentication method with certificate-based mutual 106 authentication utilizing the TLS handshake protocol for cryptographic 107 algorithms and protocol version negotiation and establishment of 108 shared secret keying material. EAP-TLS is widely supported for 109 authentication and key establishment in IEEE 802.11 [IEEE-802.11] 110 (Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE] (MACsec) networks using IEEE 111 802.1X [IEEE-802.1X] and it's the default mechanism for certificate 112 based authentication in 3GPP 5G [TS.33.501] and MulteFire [MulteFire] 113 networks. Many other EAP methods such as EAP-FAST [RFC4851], EAP- 114 TTLS [RFC5281], TEAP [RFC7170], and PEAP [PEAP] depend on TLS and 115 EAP-TLS. 117 EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346], 118 but can also work with TLS 1.2 [RFC5246]. TLS 1.0 and 1.1 are 119 formally deprecated and prohibited to negotiate and use [RFC8996]. 120 Weaknesses found in TLS 1.2, as well as new requirements for 121 security, privacy, and reduced latency have led to the specification 122 of TLS 1.3 [RFC8446], which obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is 123 in large parts a complete remodeling of the TLS handshake protocol 124 including a different message flow, different handshake messages, 125 different key schedule, different cipher suites, different resumption 126 mechanism, different privacy protection, and different record 127 padding. This means that significant parts of the normative text in 128 the previous EAP-TLS specification [RFC5216] are not applicable to 129 EAP-TLS with TLS 1.3. Therefore, aspects such as resumption, privacy 130 handling, and key derivation need to be appropriately addressed for 131 EAP-TLS with TLS 1.3. 133 This document updates [RFC5216] to define how to use EAP-TLS with TLS 134 1.3. When older TLS versions are negotiated, RFC 5216 applies to 135 maintain backwards compatibility. However, this document does 136 provide additional guidance on authentication, authorization, and 137 resumption for EAP-TLS regardless of the underlying TLS version used. 138 This document only describes differences compared to [RFC5216]. When 139 EAP-TLS is used with TLS 1.3, some references are updated as 140 specified in Appendix A. All message flow are example message flows 141 specific to TLS 1.3 and do not apply to TLS 1.2. Since EAP-TLS 142 couples the TLS handshake state machine with the EAP state machine it 143 is possible that new versions of TLS will cause incompatibilities 144 that introduce failures or security issues if they are not carefully 145 integrated into the EAP-TLS protocol. Therefore, implementations 146 MUST limit the maximum TLS version they use to 1.3, unless later 147 versions are explicitly enabled by the administrator. 149 This document specifies EAP-TLS 1.3 and does not specify how other 150 TLS-based EAP methods use TLS 1.3. The specification for how other 151 TLS-based EAP methods use TLS 1.3 is left to other documents such as 152 [I-D.ietf-emu-tls-eap-types]. 154 In addition to the improved security and privacy offered by TLS 1.3, 155 there are other significant benefits of using EAP-TLS with TLS 1.3. 156 Privacy, which in EAP-TLS means that no information about the 157 underlying peer identity is disclosed, is mandatory and achieved 158 without any additional round-trips. Revocation checking is mandatory 159 and simplified with OCSP stapling, and TLS 1.3 introduces more 160 possibilities to reduce fragmentation when compared to earlier 161 versions of TLS. 163 1.1. Requirements and Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 Readers are expected to be familiar with the terms and concepts used 172 in EAP-TLS [RFC5216] and TLS [RFC8446]. The term EAP-TLS peer is 173 used for the entity acting as EAP peer and TLS client. The term EAP- 174 TLS server is used for the entity acting as EAP server and TLS 175 server. 177 This document follows the terminology from [I-D.ietf-tls-rfc8446bis] 178 where the master secret is renamed to the main secret and the 179 exporter_master_secret is renamed to the exporter_secret. 181 2. Protocol Overview 183 2.1. Overview of the EAP-TLS Conversation 185 This section updates Section 2.1 of [RFC5216] by amending it in 186 accordance with the following discussion. 188 If the TLS implementation correctly implements TLS version 189 negotiation, EAP-TLS will automatically leverage that capability. 190 The EAP-TLS implementation needs to know which version of TLS was 191 negotiated to correctly support EAP-TLS 1.3 as well as to maintain 192 backward compatibility with EAP-TLS 1.2. 194 TLS 1.3 changes both the message flow and the handshake messages 195 compared to earlier versions of TLS. Therefore, much of Section 2.1 196 of [RFC5216] does not apply for TLS 1.3. Except for Sections 2.2 and 197 5.7, this update applies only when TLS 1.3 is negotiated. When TLS 198 1.2 is negotiated, then [RFC5216] applies. 200 TLS 1.3 introduces several new handshake messages including 201 HelloRetryRequest, NewSessionTicket, and KeyUpdate. In general, 202 these messages will be handled by the underlying TLS libraries and 203 are not visible to EAP-TLS, however, there are a few things to note: 205 * The HelloRetryRequest is used by the server to reject the 206 parameters offered in the ClientHello and suggest new parameters. 207 When this message is encountered it will increase the number of 208 round trips used by the protocol. 210 * The NewSessionTicket message is used to convey resumption 211 information and is covered in Sections 2.1.2 and 2.1.3. 213 * The KeyUpdate message is used to update the traffic keys used on a 214 TLS connection. EAP-TLS does not encrypt significant amounts of 215 data so this functionality is not needed. Implementations SHOULD 216 NOT send this message, however some TLS libraries may 217 automatically generate and process this message. 219 * Early Data MUST NOT be used in EAP-TLS. EAP-TLS servers MUST NOT 220 send an early_data extension and clients MUST NOT send an 221 EndOfEarlyData message. 223 * Post-handshake authentication MUST NOT be used in EAP-TLS. 224 Clients MUST NOT send a "post_handshake_auth" extension and 225 Servers MUST NOT request post-handshake client authentication. 227 After receiving an EAP-Request packet with EAP-Type=EAP-TLS as 228 described in [RFC5216] the conversation will continue with the TLS 229 handshake protocol encapsulated in the data fields of EAP-Response 230 and EAP-Request packets. When EAP-TLS is used with TLS version 1.3, 231 the formatting and processing of the TLS handshake SHALL be done as 232 specified in version 1.3 of TLS. This update only lists additional 233 and different requirements, restrictions, and processing compared to 234 [RFC8446] and [RFC5216]. 236 2.1.1. Authentication 238 This section updates Section 2.1.1 of [RFC5216] by amending it in 239 accordance with the following discussion. 241 The EAP-TLS server MUST authenticate with a certificate and SHOULD 242 require the EAP-TLS peer to authenticate with a certificate. 243 Certificates can be of any type supported by TLS including raw public 244 keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except 245 for resumption. The full handshake in EAP-TLS with TLS 1.3 always 246 provides forward secrecy by exchange of ephemeral "key_share" 247 extensions in the ClientHello and ServerHello (e.g., containing 248 ephemeral ECDHE public keys). SessionID is deprecated in TLS 1.3, 249 see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early 250 application data which like all application data (other than the 251 protected success indication described below) is not used in EAP-TLS; 252 see Section 4.2.10 of [RFC8446] for additional information on the 253 "early_data" extension. Resumption is handled as described in 254 Section 2.1.3. As a protected success indication [RFC3748] the EAP- 255 TLS server always sends TLS application data 0x00, see Section 2.5. 256 Note that a TLS implementation MAY not allow the EAP-TLS layer to 257 control in which order things are sent and the application data MAY 258 therefore be sent before a NewSessionTicket. TLS application data 259 0x00 is therefore to be interpreted as success after the EAP-Request 260 that contains TLS application data 0x00. After the EAP-TLS server 261 has sent an EAP-Request containing the TLS application data 0x00 and 262 received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the 263 EAP-TLS server sends EAP-Success. 265 Figure 1 shows an example message flow for a successful EAP-TLS full 266 handshake with mutual authentication (and neither HelloRetryRequest 267 nor post-handshake messages are sent). 269 EAP-TLS Peer EAP-TLS Server 271 EAP-Request/ 272 <-------- Identity 273 EAP-Response/ 274 Identity (Privacy-Friendly) --------> 275 EAP-Request/ 276 EAP-Type=EAP-TLS 277 <-------- (TLS Start) 278 EAP-Response/ 279 EAP-Type=EAP-TLS 280 (TLS ClientHello) --------> 281 EAP-Request/ 282 EAP-Type=EAP-TLS 283 (TLS ServerHello, 284 TLS EncryptedExtensions, 285 TLS CertificateRequest, 286 TLS Certificate, 287 TLS CertificateVerify, 288 <-------- TLS Finished) 289 EAP-Response/ 290 EAP-Type=EAP-TLS 291 (TLS Certificate, 292 TLS CertificateVerify, 293 TLS Finished) --------> 294 EAP-Request/ 295 EAP-Type=EAP-TLS 296 <-------- (TLS Application Data 0x00) 297 EAP-Response/ 298 EAP-Type=EAP-TLS --------> 299 <-------- EAP-Success 301 Figure 1: EAP-TLS mutual authentication 303 2.1.2. Ticket Establishment 305 This is a new section when compared to [RFC5216]. 307 To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS 308 server MUST send one or more post-handshake NewSessionTicket messages 309 (each associated with a PSK, a PSK identity, a ticket lifetime, and 310 other parameters) in the initial authentication. Note that TLS 1.3 311 [RFC8446] limits the ticket lifetime to a maximum of 604800 seconds 312 (7 days) and EAP-TLS servers MUST respect this upper limit when 313 issuing tickets. The NewSessionTicket is sent after the EAP-TLS 314 server has received the client Finished message in the initial 315 authentication. The NewSessionTicket can be sent in the same flight 316 as the TLS server Finished or later. The PSK associated with the 317 ticket depends on the client Finished and cannot be pre-computed (so 318 as to be sent in the same flight as the TLS server Finished) in 319 handshakes with client authentication. The NewSessionTicket message 320 MUST NOT include an "early_data" extension. If the "early_data" 321 extension is received then it MUST be ignored. Servers should take 322 into account that fewer NewSessionTickets will likely be needed in 323 EAP-TLS than in the usual HTTPS connection scenario. In most cases a 324 single NewSessionTicket will be sufficient. A mechanism by which 325 clients can specify the desired number of tickets needed for future 326 connections is defined in [I-D.ietf-tls-ticketrequests]. 328 Figure 2 shows an example message flow for a successful EAP-TLS full 329 handshake with mutual authentication and ticket establishment of a 330 single ticket. 332 EAP-TLS Peer EAP-TLS Server 334 EAP-Request/ 335 <-------- Identity 336 EAP-Response/ 337 Identity (Privacy-Friendly) --------> 338 EAP-Request/ 339 EAP-Type=EAP-TLS 340 <-------- (TLS Start) 341 EAP-Response/ 342 EAP-Type=EAP-TLS 343 (TLS ClientHello) --------> 344 EAP-Request/ 345 EAP-Type=EAP-TLS 346 (TLS ServerHello, 347 TLS EncryptedExtensions, 348 TLS CertificateRequest, 349 TLS Certificate, 350 TLS CertificateVerify, 351 <-------- TLS Finished) 352 EAP-Response/ 353 EAP-Type=EAP-TLS 354 (TLS Certificate, 355 TLS CertificateVerify, 356 TLS Finished) --------> 357 EAP-Request/ 358 EAP-Type=EAP-TLS 359 (TLS NewSessionTicket, 360 <-------- (TLS Application Data 0x00) 361 EAP-Response/ 362 EAP-Type=EAP-TLS --------> 363 <-------- EAP-Success 365 Figure 2: EAP-TLS ticket establishment 367 2.1.3. Resumption 369 This section updates Section 2.1.2 of [RFC5216] by amending it in 370 accordance with the following discussion. 372 EAP-TLS is typically used with client authentication and typically 373 fragments the TLS flights into a large number of EAP requests and EAP 374 responses. Resumption significantly reduces the number of round- 375 trips and enables the EAP-TLS server to omit database lookups needed 376 during a full handshake with client authentication. TLS 1.3 replaces 377 the session resumption mechanisms in earlier versions of TLS with a 378 new PSK exchange. When EAP-TLS is used with TLS version 1.3, EAP-TLS 379 SHALL use a resumption mechanism compatible with version 1.3 of TLS. 381 For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If 382 the client has received a NewSessionTicket message from the EAP-TLS 383 server, the client can use the PSK identity associated with the 384 ticket to negotiate the use of the associated PSK. If the EAP-TLS 385 server accepts it, then the resumed session has been deemed to be 386 authenticated, and securely associated with the prior authentication 387 or resumption. It is up to the EAP-TLS peer to use resumption, but 388 it is RECOMMENDED that the EAP-TLS peer use resumption if it has a 389 valid ticket that has not been used before. It is left to the EAP- 390 TLS server whether to accept resumption, but it is RECOMMENDED that 391 the EAP-TLS server accept resumption if the ticket which was issued 392 is still valid. However, the EAP-TLS server MAY choose to require a 393 full handshake. In the case a full handshake is required, the 394 negotiation proceeds as if the session was a new authentication, and 395 the resumption attempt is ignored. The requirements of Sections 396 2.1.1 and 2.1.2 then apply in their entirety. As described in 397 Appendix C.4 of [RFC8446], reuse of a ticket allows passive observers 398 to correlate different connections. EAP-TLS peers and EAP-TLS 399 servers SHOULD follow the client tracking preventions in Appendix C.4 400 of [RFC8446]. 402 It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the 403 same realm during resumption and the original full handshake. This 404 requirement allows EAP packets to be routed to the same destination 405 as the original full handshake. If this recommendation is not 406 followed, resumption is likely impossible. When NAI reuse can be 407 done without privacy implications, it is RECOMMENDED to use the same 408 NAI in the resumption, as was used in the original full handshake 409 [RFC7542]. For example, the NAI @realm can safely be reused since it 410 does not provide any specific information to associate a user's 411 resumption attempt with the original full handshake. However, 412 reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path 413 attacker to associate a resumption attempt with the original full 414 handshake. The TLS PSK identity is typically derived by the TLS 415 implementation and may be an opaque blob without a routable realm. 416 The TLS PSK identity on its own is therefore unsuitable as a NAI in 417 the Identity Response. 419 Figure 3 shows an example message flow for a subsequent successful 420 EAP-TLS resumption handshake where both sides authenticate via a PSK 421 provisioned via an earlier NewSessionTicket and where the server 422 provisions a single new ticket. 424 EAP-TLS Peer EAP-TLS Server 426 EAP-Request/ 427 <-------- Identity 428 EAP-Response/ 429 Identity (Privacy-Friendly) --------> 430 EAP-Request/ 431 EAP-Type=EAP-TLS 432 <-------- (TLS Start) 433 EAP-Response/ 434 EAP-Type=EAP-TLS 435 (TLS ClientHello 436 + pre_shared_key) --------> 437 EAP-Request/ 438 EAP-Type=EAP-TLS 439 (TLS ServerHello, 440 TLS EncryptedExtensions, 441 <-------- TLS Finished, 442 TLS NewSessionTicket) 443 EAP-Response/ 444 EAP-Type=EAP-TLS 445 (TLS Finished) --------> 446 EAP-Request/ 447 EAP-Type=EAP-TLS 448 <-------- (TLS Application Data 0x00) 449 EAP-Response/ 450 EAP-Type=EAP-TLS --------> 451 <-------- EAP-Success 453 Figure 3: EAP-TLS resumption 455 As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD 456 supply a "key_share" extension when attempting resumption, which 457 allows the EAP-TLS server to potentially decline resumption and fall 458 back to a full handshake. If the EAP-TLS peer did not supply a 459 "key_share" extension when attempting resumption, the EAP-TLS server 460 needs to send HelloRetryRequest to signal that additional information 461 is needed to complete the handshake, and the EAP-TLS peer needs to 462 send a second ClientHello containing that information. Providing a 463 "key_share" and using the "psk_dhe_ke" pre-shared key exchange mode 464 is also important in order to limit the impact of a key compromise. 465 When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning 466 that compromise of the PSK used for resumption does not compromise 467 any earlier connections. The "psk_dh_ke" key-exchange mode MUST be 468 used for resumption unless the deployment has a local requirement to 469 allow configuration of other mechanisms. 471 2.1.4. Termination 473 This section updates Section 2.1.3 of [RFC5216] by amending it in 474 accordance with the following discussion. 476 TLS 1.3 changes both the message flow and the handshake messages 477 compared to earlier versions of TLS. Therefore, some normative text 478 in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3. The two 479 paragraphs below replace the corresponding paragraphs in 480 Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3. The 481 other paragraphs in Section 2.1.3 of [RFC5216] still apply with the 482 exception that SessionID is deprecated. 484 If the EAP-TLS peer authenticates successfully, the EAP-TLS server 485 MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing 486 TLS records conforming to the version of TLS used. The message 487 flow ends with a protected success indication from the EAP-TLS 488 server, followed by an EAP-Response packet of EAP-Type=EAP-TLS and 489 no data from the EAP-TLS peer, followed by EAP-Success from the 490 server. 492 If the EAP-TLS server authenticates successfully, the EAP-TLS peer 493 MUST send an EAP-Response message with EAP-Type=EAP-TLS containing 494 TLS records conforming to the version of TLS used. 496 Figures 4, 5, and 6 illustrate message flows in several cases where 497 the EAP-TLS peer or EAP-TLS server sends a TLS Error alert message. 498 In earlier versions of TLS, error alerts could be warnings or fatal. 499 In TLS 1.3, error alerts are always fatal and the only alerts sent at 500 warning level are "close_notify" and "user_canceled", both of which 501 indicate that the connection is not going to continue normally, see 502 [RFC8446]. 504 In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a 505 fatal error condition. Failure to send TLS Error alerts means that 506 the peer or server would have no way of determining what went wrong. 507 EAP-TLS 1.3 strengthens this requirement. Whenever an implementation 508 encounters a fatal error condition, it MUST send an appropriate TLS 509 Error alert. 511 Figure 4 shows an example message flow where the EAP-TLS server 512 rejects the ClientHello with an error alert. The EAP-TLS server can 513 also partly reject the ClientHello with a HelloRetryRequest, see 514 Section 2.1.6. 516 EAP-TLS Peer EAP-TLS Server 518 EAP-Request/ 519 <-------- Identity 520 EAP-Response/ 521 Identity (Privacy-Friendly) --------> 522 EAP-Request/ 523 EAP-Type=EAP-TLS 524 <-------- (TLS Start) 525 EAP-Response/ 526 EAP-Type=EAP-TLS 527 (TLS ClientHello) --------> 528 EAP-Request/ 529 EAP-Type=EAP-TLS 530 <-------- (TLS Error Alert) 531 EAP-Response/ 532 EAP-Type=EAP-TLS --------> 533 <-------- EAP-Failure 535 Figure 4: EAP-TLS server rejection of ClientHello 537 Figure 5 shows an example message flow where EAP-TLS server 538 authentication is unsuccessful and the EAP-TLS peer sends a TLS Error 539 alert. 541 EAP-TLS Peer EAP-TLS Server 543 EAP-Request/ 544 <-------- Identity 545 EAP-Response/ 546 Identity (Privacy-Friendly) --------> 547 EAP-Request/ 548 EAP-Type=EAP-TLS 549 <-------- (TLS Start) 550 EAP-Response/ 551 EAP-Type=EAP-TLS 552 (TLS ClientHello) --------> 553 EAP-Request/ 554 EAP-Type=EAP-TLS 555 (TLS ServerHello, 556 TLS EncryptedExtensions, 557 TLS CertificateRequest, 558 TLS Certificate, 559 TLS CertificateVerify, 560 <-------- TLS Finished) 561 EAP-Response/ 562 EAP-Type=EAP-TLS 563 (TLS Error Alert) 564 --------> 565 <-------- EAP-Failure 567 Figure 5: EAP-TLS unsuccessful EAP-TLS server authentication 569 Figure 6 shows an example message flow where the EAP-TLS server 570 authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer 571 fails to authenticate to the EAP-TLS server and the server sends a 572 TLS Error alert. 574 EAP-TLS Peer EAP-TLS Server 576 EAP-Request/ 577 <-------- Identity 578 EAP-Response/ 579 Identity (Privacy-Friendly) --------> 580 EAP-Request/ 581 EAP-Type=EAP-TLS 582 <-------- (TLS Start) 583 EAP-Response/ 584 EAP-Type=EAP-TLS 585 (TLS ClientHello) --------> 586 EAP-Request/ 587 EAP-Type=EAP-TLS 588 (TLS ServerHello, 589 TLS EncryptedExtensions, 590 TLS CertificateRequest, 591 TLS Certificate, 592 TLS CertificateVerify, 593 <-------- TLS Finished) 594 EAP-Response/ 595 EAP-Type=EAP-TLS 596 (TLS Certificate, 597 TLS CertificateVerify, 598 TLS Finished) --------> 599 EAP-Request/ 600 EAP-Type=EAP-TLS 601 <-------- (TLS Error Alert) 602 EAP-Response/ 603 EAP-Type=EAP-TLS --------> 604 <-------- EAP-Failure 606 Figure 6: EAP-TLS unsuccessful client authentication 608 2.1.5. No Peer Authentication 610 This is a new section when compared to [RFC5216]. 612 Figure 7 shows an example message flow for a successful EAP-TLS full 613 handshake without peer authentication (e.g., emergency services, as 614 described in [RFC7406]). 616 EAP-TLS Peer EAP-TLS Server 618 EAP-Request/ 619 <-------- Identity 620 EAP-Response/ 621 Identity (Privacy-Friendly) --------> 622 EAP-Request/ 623 EAP-Type=EAP-TLS 624 <-------- (TLS Start) 625 EAP-Response/ 626 EAP-Type=EAP-TLS 627 (TLS ClientHello) --------> 628 EAP-Request/ 629 EAP-Type=EAP-TLS 630 (TLS ServerHello, 631 TLS EncryptedExtensions, 632 TLS Certificate, 633 TLS CertificateVerify, 634 <-------- TLS Finished) 635 EAP-Response/ 636 EAP-Type=EAP-TLS 637 (TLS Finished) --------> 638 EAP-Request/ 639 EAP-Type=EAP-TLS 640 <-------- (TLS Application Data 0x00) 641 EAP-Response/ 642 EAP-Type=EAP-TLS --------> 643 <-------- EAP-Success 645 Figure 7: EAP-TLS without peer authentication 647 2.1.6. Hello Retry Request 649 This is a new section when compared to [RFC5216]. 651 As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a 652 HelloRetryRequest message in response to a ClientHello if the EAP-TLS 653 server finds an acceptable set of parameters but the initial 654 ClientHello does not contain all the needed information to continue 655 the handshake. One use case is if the EAP-TLS server does not 656 support the groups in the "key_share" extension (or there is no 657 "key_share" extension), but supports one of the groups in the 658 "supported_groups" extension. In this case the client should send a 659 new ClientHello with a "key_share" that the EAP-TLS server supports. 661 Figure 8 shows an example message flow for a successful EAP-TLS full 662 handshake with mutual authentication and HelloRetryRequest. Note the 663 extra round-trip as a result of the HelloRetryRequest. 665 EAP-TLS Peer EAP-TLS Server 667 EAP-Request/ 668 <-------- Identity 669 EAP-Response/ 670 Identity (Privacy-Friendly) --------> 671 EAP-Request/ 672 EAP-Type=EAP-TLS 673 <-------- (TLS Start) 674 EAP-Response/ 675 EAP-Type=EAP-TLS 676 (TLS ClientHello) --------> 677 EAP-Request/ 678 EAP-Type=EAP-TLS 679 (TLS HelloRetryRequest) 680 <-------- 681 EAP-Response/ 682 EAP-Type=EAP-TLS 683 (TLS ClientHello) --------> 684 EAP-Request/ 685 EAP-Type=EAP-TLS 686 (TLS ServerHello, 687 TLS EncryptedExtensions, 688 TLS CertificateRequest, 689 TLS Certificate, 690 TLS CertificateVerify, 691 TLS Finished) 692 EAP-Response/ 693 EAP-Type=EAP-TLS 694 (TLS Certificate, 695 TLS CertificateVerify, 696 TLS Finished) --------> 697 EAP-Request/ 698 EAP-Type=EAP-TLS 699 <-------- (TLS Application Data 0x00) 700 EAP-Response/ 701 EAP-Type=EAP-TLS --------> 702 <-------- EAP-Success 704 Figure 8: EAP-TLS with Hello Retry Request 706 2.1.7. Identity 708 This is a new section when compared to [RFC5216]. 710 It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity 711 Response as such identities are routable and privacy-friendly. While 712 opaque blobs are allowed by [RFC3748], such identities are NOT 713 RECOMMENDED as they are not routable and should only be considered in 714 local deployments where the EAP-TLS peer, EAP authenticator, and EAP- 715 TLS server all belong to the same network. Many client certificates 716 contain an identity such as an email address, which is already in NAI 717 format. When the client certificate contains a NAI as subject name 718 or alternative subject name, an anonymous NAI SHOULD be derived from 719 the NAI in the certificate, see Section 2.1.8. More details on 720 identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8. 722 2.1.8. Privacy 724 This section updates Section 2.1.4 of [RFC5216] by amending it in 725 accordance with the following discussion. 727 EAP-TLS 1.3 significantly improves privacy when compared to earlier 728 versions of EAP-TLS. EAP-TLS 1.3 forbids cipher suites without 729 confidentiality which means that TLS 1.3 is always encrypting large 730 parts of the TLS handshake including the certificate messages. 732 EAP-TLS peer and server implementations supporting TLS 1.3 MUST 733 support anonymous Network Access Identifiers (NAIs) (Section 2.4 in 734 [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its username 735 in cleartext in the Identity Response. Following [RFC7542], it is 736 RECOMMENDED to omit the username (i.e., the NAI is @realm), but other 737 constructions such as a fixed username (e.g., anonymous@realm) or an 738 encrypted username (e.g., 739 xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. 740 Note that the NAI MUST be a UTF-8 string as defined by the grammar in 741 Section 2.2 of [RFC7542]. 743 The HelloRequest message used for privacy in EAP-TLS 1.2 does not 744 exist in TLS 1.3 but as the certificate messages in TLS 1.3 are 745 encrypted, there is no need to send an empty certificate_list and 746 perform a second handshake for privacy (as needed by EAP-TLS with 747 earlier versions of TLS). When EAP-TLS is used with TLS version 1.3 748 the EAP-TLS peer and EAP-TLS server SHALL follow the processing 749 specified by version 1.3 of TLS. This means that the EAP-TLS peer 750 only sends an empty certificate_list if it does not have an 751 appropriate certificate to send, and the EAP-TLS server MAY treat an 752 empty certificate_list as a terminal condition. 754 EAP-TLS with TLS 1.3 is always used with privacy. This does not add 755 any extra round-trips and the message flow with privacy is just the 756 normal message flow as shown in Figure 1. 758 2.1.9. Fragmentation 760 This section updates Section 2.1.5 of [RFC5216] by amending it in 761 accordance with the following discussion. 763 Including ContentType (1 byte), ProtocolVersion (2 bytes), and length 764 (2 bytes) headers a single TLS record may be up to 16645 octets in 765 length. EAP-TLS fragmentation support is provided through addition 766 of a flags octet within the EAP-Response and EAP-Request packets, as 767 well as a (conditional) TLS Message Length field of four octets. 768 Implementations MUST NOT set the L bit in unfragmented messages, but 769 MUST accept unfragmented messages with and without the L bit set. 771 Some EAP implementations and access networks may limit the number of 772 EAP packet exchanges that can be handled. To avoid fragmentation, it 773 is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and 774 trust anchor certificates small and the length of the certificate 775 chains short. In addition, it is RECOMMENDED to use mechanisms that 776 reduce the sizes of Certificate messages. For a detailed discussion 777 on reducing message sizes to prevent fragmentation, see 778 [I-D.ietf-emu-eaptlscert]. 780 2.2. Identity Verification 782 This section updates Section 2.2 of [RFC5216] by amending it in 783 accordance with the following discussion. The guidance in this 784 section is relevant for EAP-TLS in general (regardless of the 785 underlying TLS version used). 787 The EAP peer identity provided in the EAP-Response/Identity is not 788 authenticated by EAP-TLS. Unauthenticated information MUST NOT be 789 used for accounting purposes or to give authorization. The 790 authenticator and the EAP-TLS server MAY examine the identity 791 presented in EAP-Response/Identity for purposes such as routing and 792 EAP method selection. EAP-TLS servers MAY reject conversations if 793 the identity does not match their policy. Note that this also 794 applies to resumption, see Sections 2.1.3, 5.6, and 5.7. 796 The EAP server identity in the TLS server certificate is typically a 797 fully qualified domain name (FQDN) in the SubjectAltName (SAN) 798 extension. Since EAP-TLS deployments may use more than one EAP 799 server, each with a different certificate, EAP peer implementations 800 SHOULD allow for the configuration of one or more trusted root 801 certificates (CA certificate) to authenticate the server certificate 802 and one or more server names to match against the SubjectAltName 803 (SAN) extension in the server certificate. If any of the configured 804 names match any of the names in the SAN extension then the name check 805 passes. To simplify name matching, an EAP-TLS deployment can assign 806 a name to represent an authorized EAP server and EAP Server 807 certificates can include this name in the list of SANs for each 808 certificate that represents an EAP-TLS server. If server name 809 matching is not used, then it degrades the confidence that the EAP 810 server with which it is interacting is authoritative for the given 811 network. If name matching is not used with a public root CA, then 812 effectively any server can obtain a certificate which will be trusted 813 for EAP authentication by the Peer. While this guidance to verify 814 domain names is new, and was not mentioned in [RFC5216], it has been 815 widely implemented in EAP-TLS peers. As such, it is believed that 816 this section contains minimal new interoperability or implementation 817 requirements on EAP-TLS peers and can be applied to earlier versions 818 of TLS. 820 The process of configuring a root CA certificate and a server name is 821 non-trivial and therefore automated methods of provisioning are 822 RECOMMENDED. For example, the eduroam federation [RFC7593] provides 823 a Configuration Assistant Tool (CAT) to automate the configuration 824 process. In the absence of a trusted root CA certificate (user 825 configured or system-wide), EAP peers MAY implement a trust on first 826 use (TOFU) mechanism where the peer trusts and stores the server 827 certificate during the first connection attempt. The EAP peer 828 ensures that the server presents the same stored certificate on 829 subsequent interactions. Use of a TOFU mechanism does not allow for 830 the server certificate to change without out-of-band validation of 831 the certificate and is therefore not suitable for many deployments 832 including ones where multiple EAP servers are deployed for high 833 availability. TOFU mechanisms increase the susceptibility to traffic 834 interception attacks and should only be used if there are adequate 835 controls in place to mitigate this risk. 837 2.3. Key Hierarchy 839 This section updates Section 2.3 of [RFC5216] by replacing it in 840 accordance with the following discussion. 842 TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier 843 versions of TLS with HKDF and completely changes the Key Schedule. 844 The key hierarchies shown in Section 2.3 of [RFC5216] are therefore 845 not correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3 846 the key schedule is described in Section 7.1 of [RFC8446]. 848 When EAP-TLS is used with TLS version 1.3 the Key_Material and 849 Method-Id SHALL be derived from the exporter_secret using the TLS 850 exporter interface [RFC5705] (for TLS 1.3 this is defined in 851 Section 7.5 of [RFC8446]). Type is the value of the EAP Type field 852 defined in Section 2 of [RFC3748]. For EAP-TLS the Type field has 853 value 0x0D. 855 Type = 0x0D 856 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 857 Type, 128) 858 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 859 Type, 64) 860 Session-Id = Type || Method-Id 862 The MSK and EMSK are derived from the Key_Material in the same manner 863 as with EAP-TLS [RFC5216], Section 2.3. The definitions are repeated 864 below for simplicity: 866 MSK = Key_Material(0, 63) 867 EMSK = Key_Material(64, 127) 869 Other TLS based EAP methods can use the TLS exporter in a similar 870 fashion, see [I-D.ietf-emu-tls-eap-types]. 872 [RFC5247] deprecates the use of IV. Thus, RECV-IV and SEND-IV are 873 not exported in EAP-TLS with TLS 1.3. As noted in [RFC5247], lower 874 layers use the MSK in a lower-layer-dependent manner. EAP-TLS with 875 TLS 1.3 exports the MSK and does not specify how it is used by lower 876 layers. 878 Note that the key derivation MUST use the length values given above. 879 While in TLS 1.2 and earlier it was possible to truncate the output 880 by requesting less data from the TLS-Exporter function, this practice 881 is not possible with TLS 1.3. If an implementation intends to use 882 only a part of the output of the TLS-Exporter function, then it MUST 883 ask for the full output and then only use the desired part. Failure 884 to do so will result in incorrect values being calculated for the 885 above keying material. 887 By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation 888 which provides a public API for the exporter. Note that when TLS 1.2 889 is used with the EAP-TLS exporter [RFC5705] it generates the same key 890 material as in EAP-TLS [RFC5216]. 892 2.4. Parameter Negotiation and Compliance Requirements 894 This section updates Section 2.4 of [RFC5216] by amending it in 895 accordance with the following discussion. 897 TLS 1.3 cipher suites are defined differently than in earlier 898 versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites 899 discussed in Section 2.4 of [RFC5216] can therefore not be used when 900 EAP-TLS is used with TLS version 1.3. 902 When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- 903 TLS servers MUST comply with the compliance requirements (mandatory- 904 to-implement cipher suites, signature algorithms, key exchange 905 algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. In 906 EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL 907 be supported. 909 While EAP-TLS does not protect any application data except for the 910 0x00 byte that serves as protected success indication, the negotiated 911 cipher suites and algorithms MAY be used to secure data as done in 912 other TLS-based EAP methods. 914 2.5. EAP State Machines 916 This is a new section when compared to [RFC5216] and only applies to 917 TLS 1.3. [RFC4137] offers a proposed state machine for EAP. 919 TLS 1.3 [RFC8446] introduces post-handshake messages. These post- 920 handshake messages use the handshake content type and can be sent 921 after the main handshake. Examples of post-handshake messages are 922 NewSessionTicket, which is used for resumption and KeyUpdate, which 923 is not useful and not expected in EAP-TLS. After sending TLS 924 Finished, the EAP-TLS server may send any number of post-handshake 925 messages in one or more EAP-Requests. 927 To provide a protected success result indication and to decrease the 928 uncertainty for the EAP-TLS peer, the following procedure MUST be 929 followed: 931 When an EAP-TLS server has successfully processed the TLS client 932 Finished and sent its last handshake message (Finished or a post- 933 handshake message), it sends an encrypted TLS record with application 934 data 0x00. The encrypted TLS record with application data 0x00 is a 935 protected success result indication, as defined in [RFC3748]. After 936 sending an EAP-Request that contains the protected success result 937 indication, the EAP-TLS server must not send any more EAP-Request and 938 may only send an EAP-Success. The EAP-TLS server MUST NOT send an 939 encrypted TLS record with application data 0x00 alert before it has 940 successfully processed the client finished and sent its last 941 handshake message. 943 TLS Error alerts SHOULD be considered a failure result indication, as 944 defined in [RFC3748]. Implementations following [RFC4137] set the 945 alternate indication of failure variable altReject after sending or 946 receiving an error alert. After sending or receiving a TLS Error 947 alert, the EAP-TLS server may only send an EAP-Failure. Protected 948 TLS Error alerts are protected failure result indications, 949 unprotected TLS Error alerts are not. 951 The keying material can be derived after the TLS server Finished has 952 been sent or received. Implementations following [RFC4137] can then 953 set the eapKeyData and aaaEapKeyData variables. 955 The keying material can be made available to lower layers and the 956 authenticator after the authenticated success result indication has 957 been sent or received. Implementations following [RFC4137] can set 958 the eapKeyAvailable and aaaEapKeyAvailable variables. 960 3. Detailed Description of the EAP-TLS Protocol 962 No updates to Section 3 of [RFC5216]. 964 4. IANA considerations 966 This section provides guidance to the Internet Assigned Numbers 967 Authority (IANA) regarding registration of values related to the EAP- 968 TLS 1.3 protocol in accordance with [RFC8126]. 970 This document requires IANA to add the following labels to the TLS 971 Exporter Label Registry defined by [RFC5705]. These labels are used 972 in derivation of Key_Material and Method-Id as defined in 973 Section 2.3: 975 +===============================+=========+=============+======+ 976 | Value | DTLS-OK | Recommended | Note | 977 +===============================+=========+=============+======+ 978 | EXPORTER_EAP_TLS_Key_Material | N | Y | | 979 +-------------------------------+---------+-------------+------+ 980 +-------------------------------+---------+-------------+------+ 981 | EXPORTER_EAP_TLS_Method-Id | N | Y | | 982 +-------------------------------+---------+-------------+------+ 984 Table 1: TLS Exporter Label Registry 986 5. Security Considerations 988 The security considerations of TLS 1.3 [RFC8446] apply to EAP-TLS 1.3 990 5.1. Security Claims 992 Using EAP-TLS with TLS 1.3 does not change the security claims for 993 EAP-TLS as given in Section 5.1 of [RFC5216]. However, it 994 strengthens several of the claims as described in the following 995 updates to the notes given in Section 5.1 of [RFC5216]. 997 [1] Mutual authentication: By mandating revocation checking of 998 certificates, the authentication in EAP-TLS with TLS 1.3 is stronger 999 as authentication with revoked certificates will always fail. 1001 [2] Confidentiality: The TLS 1.3 handshake offers much better 1002 confidentiality than earlier versions of TLS. EAP-TLS with TLS 1.3 1003 mandates use of cipher suites that ensure confidentiality. TLS 1.3 1004 also encrypts certificates and some of the extensions. When using 1005 EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not 1006 cause any additional round-trips. 1008 [3] Cryptographic strength: TLS 1.3 only defines strong algorithms 1009 without major weaknesses and EAP-TLS with TLS 1.3 always provides 1010 forward secrecy, see [RFC8446]. Weak algorithms such as 3DES, CBC 1011 mode, RC4, SHA-1, MD5, P-192, and RSA-1024 have not been registered 1012 for use in TLS 1.3. 1014 [4] Cryptographic Negotiation: The TLS layer handles the negotiation 1015 of cryptographic parameters. When EAP-TLS is used with TLS 1.3, EAP- 1016 TLS inherits the cryptographic negotiation of AEAD algorithm, HKDF 1017 hash algorithm, key exchange groups, and signature algorithm, see 1018 Section 4.1.1 of [RFC8446]. 1020 5.2. Peer and Server Identities 1022 No updates to section 5.2 of [RFC5216]. Note that Section 2.2 has 1023 additional discussion on identities. 1025 5.3. Certificate Validation 1027 No updates to section 5.3 of [RFC5216]. In addition to section 5.3 1028 of [RFC5216], guidance on server certificate validation can be found 1029 in [RFC6125]. 1031 5.4. Certificate Revocation 1033 This section updates Section 5.4 of [RFC5216] by amending it in 1034 accordance with the following discussion. 1036 There are a number of reasons (e.g., key compromise, CA compromise, 1037 privilege withdrawn, etc.) why EAP-TLS peer, EAP-TLS server, or sub- 1038 CA certificates have to be revoked before their expiry date. 1039 Revocation of the EAP-TLS server's certificate is complicated by the 1040 fact that the EAP-TLS peer may not have Internet connectivity until 1041 authentication completes. 1043 When EAP-TLS is used with TLS 1.3, the revocation status of all the 1044 certificates in the certificate chains MUST be checked (except the 1045 trust anchor). An implementation may use Certificate Revocation List 1046 (CRL), Online Certificate Status Protocol (OSCP), or other 1047 standardized/proprietary methods for revocation checking. Examples 1048 of proprietary methods are non-standard formats for distribution of 1049 revocation lists as well as certificates with very short lifetime. 1051 EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status 1052 Requests (OCSP stapling) as specified in [RFC6066] and 1053 Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers 1054 and EAP-TLS servers use OCSP stapling for verifying the status of the 1055 EAP-TLS server's certificate chain. When an EAP-TLS peer uses 1056 Certificate Status Requests to check the revocation status of the 1057 EAP-TLS server's certificate chain it MUST treat a CertificateEntry 1058 (except the trust anchor) without a valid CertificateStatus extension 1059 as invalid and abort the handshake with an appropriate alert. The 1060 OCSP status handling in TLS 1.3 is different from earlier versions of 1061 TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP 1062 information is carried in the CertificateEntry containing the 1063 associated certificate instead of a separate CertificateStatus 1064 message as in [RFC6066]. This enables sending OCSP information for 1065 all certificates in the certificate chain (except the trust anchor). 1067 To enable revocation checking in situations where EAP-TLS peers do 1068 not implement or use OCSP stapling, and where network connectivity is 1069 not available prior to authentication completion, EAP-TLS peer 1070 implementations MUST also support checking for certificate revocation 1071 after authentication completes and network connectivity is available. 1072 An EAP peer implementation SHOULD NOT trust the network (and any 1073 services) until it has verified the revocation status of the server 1074 certificate after receiving network connectivity. An EAP peer MUST 1075 use a secure transport to verify the revocation status of the server 1076 certificate. An EAP peer SHOULD NOT send any other traffic before 1077 revocation checking for the server certificate is complete. 1079 5.5. Packet Modification Attacks 1081 This section updates Section 5.5 of [RFC5216] by amending it in 1082 accordance with the following discussion. 1084 As described in [RFC3748] and Section 5.5 of [RFC5216], the only 1085 information that is integrity and replay protected in EAP-TLS are the 1086 parts of the TLS Data that TLS protects. All other information in 1087 the EAP-TLS message exchange including EAP-Request and EAP-Response 1088 headers, the identity in the identity response, EAP-TLS packet header 1089 fields, Type, and Flags, EAP-Success, and EAP-Failure can be 1090 modified, spoofed, or replayed. 1092 Protected TLS Error alerts are protected failure result indications 1093 and enables the EAP-TLS peer and EAP-TLS server to determine that the 1094 failure result was not spoofed by an attacker. Protected failure 1095 result indications provide integrity and replay protection but MAY be 1096 unauthenticated. Protected failure results do not significantly 1097 improve availability as TLS 1.3 treats most malformed data as a fatal 1098 error. 1100 5.6. Authorization 1102 This is a new section when compared to [RFC5216]. The guidance in 1103 this section is relevant for EAP-TLS in general (regardless of the 1104 underlying TLS version used). 1106 EAP servers will usually require the EAP peer to provide a valid 1107 certificate and will fail the connection if one is not provided. 1108 Some deployments may permit no peer authentication for some or all 1109 connections. When peer authentication is not used, EAP-TLS server 1110 implementations MUST take care to limit network access appropriately 1111 for unauthenticated peers and implementations MUST use resumption 1112 with caution to ensure that a resumed session is not granted more 1113 privilege than was intended for the original session. An example of 1114 limiting network access would be to invoke a vendor's walled garden 1115 or quarantine network functionality. 1117 EAP-TLS is typically encapsulated in other protocols, such as PPP 1118 [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. 1119 The encapsulating protocols can also provide additional, non-EAP 1120 information to an EAP-TLS server. This information can include, but 1121 is not limited to, information about the authenticator, information 1122 about the EAP-TLS peer, or information about the protocol layers 1123 above or below EAP (MAC addresses, IP addresses, port numbers, Wi-Fi 1124 SSID, etc.). EAP-TLS servers implementing EAP-TLS inside those 1125 protocols can make policy decisions and enforce authorization based 1126 on a combination of information from the EAP-TLS exchange and non-EAP 1127 information. 1129 As noted in Section 2.2, the identity presented in EAP-Response/ 1130 Identity is not authenticated by EAP-TLS and is therefore trivial for 1131 an attacker to forge, modify, or replay. Authorization and 1132 accounting MUST be based on authenticated information such as 1133 information in the certificate or the PSK identity and cached data 1134 provisioned for resumption as described in Section 5.7. Note that 1135 the requirements for Network Access Identifiers (NAIs) specified in 1136 Section 4 of [RFC7542] still apply and MUST be followed. 1138 EAP-TLS servers MAY reject conversations based on non-EAP information 1139 provided by the encapsulating protocol, for example, if the MAC 1140 address of the authenticator does not match the expected policy. 1142 In addition to allowing configuration of one or more trusted root 1143 certificates (CA certificate) to authenticate the server certificate 1144 and one or more server names to match against the SubjectAltName 1145 (SAN) extension, EAP peer implementations MAY allow binding the 1146 configured acceptable SAN to a specific CA (or CAs) that should have 1147 issued the server certificate to prevent attacks from rogue or 1148 compromised CAs. 1150 5.7. Resumption 1152 This is a new section when compared to [RFC5216]. The guidance in 1153 this section is relevant for EAP-TLS in general (regardless of the 1154 underlying TLS version used). 1156 There are a number of security issues related to resumption that are 1157 not described in [RFC5216]. The problems, guidelines, and 1158 requirements in this section therefore applies to EAP-TLS when it is 1159 used with any version of TLS. 1161 When resumption occurs, it is based on cached information at the TLS 1162 layer. To perform resumption securely, the EAP-TLS peer and EAP-TLS 1163 server need to be able to securely retrieve authorization information 1164 such as certificate chains from the initial full handshake. This 1165 document uses the term "cached data" to describe such information. 1166 Authorization during resumption MUST be based on such cached data. 1167 The EAP-TLS peer and EAP-TLS server MAY perform fresh revocation 1168 checks on the cached certificate data. Any security policies for 1169 authorization MUST be followed also for resumption. The certificates 1170 may have been revoked since the initial full handshake and the 1171 authorizations of the other party may have been reduced. If the 1172 cached revocation data is not sufficiently current, the EAP-TLS peer 1173 or EAP-TLS server MAY force a full TLS handshake. 1175 There are two ways to retrieve the cached data from the original full 1176 handshake. The first method is that the EAP-TLS server and client 1177 cache the information locally. The cached information is identified 1178 by an identifier. For TLS versions before 1.3, the identifier can be 1179 the session ID, for TLS 1.3, the identifier is the PSK identity. The 1180 second method for retrieving cached information is via [RFC5077] or 1181 [RFC8446], where the EAP-TLS server avoids storing information 1182 locally and instead encapsulates the information into a ticket which 1183 is sent to the client for storage. This ticket is encrypted using a 1184 key that only the EAP-TLS server knows. Note that the client still 1185 needs to cache the original handshake information locally and will 1186 obtain it while determining the session ID or PSK identity to use for 1187 resumption. However, the EAP-TLS server is able to decrypt the 1188 ticket or PSK to obtain the original handshake information. 1190 The EAP-TLS server or EAP client MUST cache data during the initial 1191 full handshake sufficient to allow authorization decisions to be made 1192 during resumption. If cached data cannot be retrieved securely, 1193 resumption MUST NOT be done. 1195 The above requirements also apply if the EAP-TLS server expects some 1196 system to perform accounting for the session. Since accounting must 1197 be tied to an authenticated identity, and resumption does not supply 1198 such an identity, accounting is impossible without access to cached 1199 data. Therefore, systems which expect to perform accounting for the 1200 session SHOULD cache an identifier which can be used in subsequent 1201 accounting. 1203 As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption 1204 PSKs or tickets (and associated cached data) for longer than 604800 1205 seconds (7 days), regardless of the PSK or ticket lifetime. The EAP- 1206 TLS peer MAY delete them earlier based on local policy. The cached 1207 data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any 1208 certificate in the certificate chain has been revoked or has expired. 1209 In all such cases, an attempt at resumption results in a full TLS 1210 handshake instead. 1212 Information from the EAP-TLS exchange (e.g., the identity provided in 1213 EAP-Response/Identity) as well as non-EAP information (e.g., IP 1214 addresses) may change between the initial full handshake and 1215 resumption. This change creates a "time-of-check time-of-use" 1216 (TOCTOU) security vulnerability. A malicious or compromised user 1217 could supply one set of data during the initial authentication, and a 1218 different set of data during resumption, potentially allowing them to 1219 obtain access that they should not have. 1221 If any authorization, accounting, or policy decisions were made with 1222 information that has changed between the initial full handshake and 1223 resumption, and if change may lead to a different decision, such 1224 decisions MUST be reevaluated. It is RECOMMENDED that authorization, 1225 accounting, and policy decisions are reevaluated based on the 1226 information given in the resumption. EAP-TLS servers MAY reject 1227 resumption where the information supplied during resumption does not 1228 match the information supplied during the original authentication. 1229 If a safe decision is not possible, EAP-TLS servers SHOULD reject the 1230 resumption and continue with a full handshake. 1232 Section 2.2 and 4.2.11 of [RFC8446] provides security considerations 1233 for TLS 1.3 resumption. 1235 5.8. Privacy Considerations 1237 This is a new section when compared to [RFC5216]. 1239 TLS 1.3 offers much better privacy than earlier versions of TLS as 1240 discussed in Section 2.1.8. In this section, we only discuss the 1241 privacy properties of EAP-TLS with TLS 1.3. For privacy properties 1242 of TLS 1.3 itself, see [RFC8446]. 1244 EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in 1245 EAP packets. Additionally, the EAP-TLS peer sends an identity in the 1246 first EAP-Response. The other fields in the EAP-TLS Request and the 1247 EAP-TLS Response packets do not contain any cleartext privacy- 1248 sensitive information. 1250 Tracking of users by eavesdropping on identity responses or 1251 certificates is a well-known problem in many EAP methods. When EAP- 1252 TLS is used with TLS 1.3, all certificates are encrypted, and the 1253 username part of the identity response is not revealed (e.g., using 1254 anonymous NAIs). Note that even though all certificates are 1255 encrypted, the server's identity is only protected against passive 1256 attackers while the client's identity is protected against both 1257 passive and active attackers. As with other EAP methods, even when 1258 privacy-friendly identifiers or EAP tunneling is used, the domain 1259 name (i.e., the realm) in the NAI is still typically visible. How 1260 much privacy-sensitive information the domain name leaks is highly 1261 dependent on how many other users are using the same domain name in 1262 the particular access network. If all EAP-TLS peers have the same 1263 domain, no additional information is leaked. If a domain name is 1264 used by a small subset of the EAP-TLS peers, it may aid an attacker 1265 in tracking or identifying the user. 1267 Without padding, information about the size of the client certificate 1268 is leaked from the size of the EAP-TLS packets. The EAP-TLS packets 1269 sizes may therefore leak information that can be used to track or 1270 identify the user. If all client certificates have the same length, 1271 no information is leaked. EAP-TLS peers SHOULD use record padding, 1272 see Section 5.4 of [RFC8446] to reduce information leakage of 1273 certificate sizes. 1275 If anonymous NAIs are not used, the privacy-friendly identifiers need 1276 to be generated with care. The identities MUST be generated in a 1277 cryptographically secure way so that it is computationally infeasible 1278 for an attacker to differentiate two identities belonging to the same 1279 user from two identities belonging to different users in the same 1280 realm. This can be achieved, for instance, by using random or 1281 pseudo-random usernames such as random byte strings or ciphertexts 1282 and only using the pseudo-random usernames a single time. Note that 1283 the privacy-friendly usernames also MUST NOT include substrings that 1284 can be used to relate the identity to a specific user. Similarly, 1285 privacy-friendly username MUST NOT be formed by a fixed mapping that 1286 stays the same across multiple different authentications. 1288 An EAP-TLS peer with a policy allowing communication with EAP-TLS 1289 servers supporting only TLS 1.2 without privacy and with a static RSA 1290 key exchange is vulnerable to disclosure of the EAP-TLS peer 1291 username. An active attacker can in this case make the EAP-TLS peer 1292 believe that an EAP-TLS server supporting TLS 1.3 only supports TLS 1293 1.2 without privacy. The attacker can simply impersonate the EAP-TLS 1294 server and negotiate TLS 1.2 with static RSA key exchange and send an 1295 TLS alert message when the EAP-TLS peer tries to use privacy by 1296 sending an empty certificate message. Since the attacker 1297 (impersonating the EAP-TLS server) does not provide a proof-of- 1298 possession of the private key until the Finished message when a 1299 static RSA key exchange is used, an EAP-TLS peer may inadvertently 1300 disclose its identity (username) to an attacker. Therefore, it is 1301 RECOMMENDED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and 1302 static RSA based cipher suites without privacy. This implies that an 1303 EAP-TLS peer SHOULD NOT continue the EAP authentication attempt if a 1304 TLS 1.2 EAP-TLS server sends an EAP-TLS/Request with a TLS alert 1305 message in response to an empty certificate message from the peer. 1307 5.9. Pervasive Monitoring 1309 This is a new section when compared to [RFC5216]. 1311 Pervasive monitoring refers to widespread surveillance of users. In 1312 the context of EAP-TLS, pervasive monitoring attacks can target EAP- 1313 TLS peer devices for tracking them (and their users) as and when they 1314 join a network. By encrypting more information, mandating the use of 1315 privacy, and always providing forward secrecy, EAP-TLS with TLS 1.3 1316 offers much better protection against pervasive monitoring. In 1317 addition to the privacy attacks discussed above, surveillance on a 1318 large scale may enable tracking of a user over a wide geographical 1319 area and across different access networks. Using information from 1320 EAP-TLS together with information gathered from other protocols 1321 increases the risk of identifying individual users. 1323 5.10. Discovered Vulnerabilities 1325 This is a new section when compared to [RFC5216]. 1327 Over the years, there have been several serious attacks on earlier 1328 versions of Transport Layer Security (TLS), including attacks on its 1329 most commonly used ciphers and modes of operation. [RFC7457] 1330 summarizes the attacks that were known at the time of publishing and 1331 BCP 195 [RFC7525] [RFC8996] provides recommendations and requirements 1332 for improving the security of deployed services that use TLS. 1333 However, many of the attacks are less serious for EAP-TLS as EAP-TLS 1334 only uses the TLS handshake and does not protect any application 1335 data. EAP-TLS implementations MUST mitigate known attacks. EAP-TLS 1336 implementations need to monitor and follow new EAP and TLS related 1337 security guidance and requirements such as [RFC8447] and 1338 [I-D.ietf-tls-md5-sha1-deprecate]. 1340 5.11. Cross-Protocol Attacks 1342 This is a new section when compared to [RFC5216]. 1344 Allowing the same certificate to be used in multiple protocols can 1345 potentially allow an attacker to authenticate via one protocol, and 1346 then "resume" that session in another protocol. Section 2.2 above 1347 suggests that certificates typically have one or more FQDNs in the 1348 SAN extension. However, those fields are for EAP validation only, 1349 and do not indicate that the certificates are suitable for use on WWW 1350 (or other) protocol server on the named host. 1352 Section 2.1.3 above suggests that authorization rules should be re- 1353 applied on resumption, but does not mandate this behavior. As a 1354 result, this cross-protocol resumption could allow the attacker to 1355 bypass authorization policies, and to obtain undesired access to 1356 secured systems. Along with making sure that appropriate 1357 authorization information is available and used during resumption, 1358 using different certificates and resumption caches for different 1359 protocols is RECOMMENDED to help keep different protocol usages 1360 separate. 1362 6. References 1364 6.1. Normative References 1366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1367 Requirement Levels", BCP 14, RFC 2119, 1368 DOI 10.17487/RFC2119, March 1997, 1369 . 1371 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1372 Levkowetz, Ed., "Extensible Authentication Protocol 1373 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1374 . 1376 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1377 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 1378 March 2008, . 1380 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1381 Housley, R., and W. Polk, "Internet X.509 Public Key 1382 Infrastructure Certificate and Certificate Revocation List 1383 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1384 . 1386 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1387 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1388 March 2010, . 1390 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1391 Extensions: Extension Definitions", RFC 6066, 1392 DOI 10.17487/RFC6066, January 2011, 1393 . 1395 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1396 Galperin, S., and C. Adams, "X.509 Internet Public Key 1397 Infrastructure Online Certificate Status Protocol - OCSP", 1398 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1399 . 1401 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1402 DOI 10.17487/RFC7542, May 2015, 1403 . 1405 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1406 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1407 May 2017, . 1409 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1410 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1411 . 1413 6.2. Informative references 1415 [IEEE-802.1X] 1416 Institute of Electrical and Electronics Engineers, "IEEE 1417 Standard for Local and metropolitan area networks -- Port- 1418 Based Network Access Control", IEEE Standard 802.1X-2020 , 1419 February 2020. 1421 [IEEE-802.11] 1422 Institute of Electrical and Electronics Engineers, "IEEE 1423 Standard for Information technology—Telecommunications and 1424 information exchange between systems Local and 1425 metropolitan area networks—Specific requirements - Part 1426 11: Wireless LAN Medium Access Control (MAC) and Physical 1427 Layer (PHY) Specifications", IEEE Standard 802.11-2020 , 1428 February 2021. 1430 [IEEE-802.1AE] 1431 Institute of Electrical and Electronics Engineers, "IEEE 1432 Standard for Local and metropolitan area networks -- Media 1433 Access Control (MAC) Security", IEEE Standard 1434 802.1AE-2018 , December 2018. 1436 [TS.33.501] 1437 3GPP, "Security architecture and procedures for 5G 1438 System", 3GPP TS 33.501 17.3.0, September 2021. 1440 [MulteFire] 1441 MulteFire, "MulteFire Release 1.1 specification", 2019. 1443 [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible 1444 Authentication Protocol (PEAP)", June 2021. 1446 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 1447 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 1448 . 1450 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1451 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1452 . 1454 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1455 Adams, "X.509 Internet Public Key Infrastructure Online 1456 Certificate Status Protocol - OCSP", RFC 2560, 1457 DOI 10.17487/RFC2560, June 1999, 1458 . 1460 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1461 "Remote Authentication Dial In User Service (RADIUS)", 1462 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1463 . 1465 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1466 X.509 Public Key Infrastructure Certificate and 1467 Certificate Revocation List (CRL) Profile", RFC 3280, 1468 DOI 10.17487/RFC3280, April 2002, 1469 . 1471 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 1472 "State Machines for Extensible Authentication Protocol 1473 (EAP) Peer and Authenticator", RFC 4137, 1474 DOI 10.17487/RFC4137, August 2005, 1475 . 1477 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1478 Network Access Identifier", RFC 4282, 1479 DOI 10.17487/RFC4282, December 2005, 1480 . 1482 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1483 (TLS) Protocol Version 1.1", RFC 4346, 1484 DOI 10.17487/RFC4346, April 2006, 1485 . 1487 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 1488 Flexible Authentication via Secure Tunneling Extensible 1489 Authentication Protocol Method (EAP-FAST)", RFC 4851, 1490 DOI 10.17487/RFC4851, May 2007, 1491 . 1493 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1494 "Transport Layer Security (TLS) Session Resumption without 1495 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1496 January 2008, . 1498 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1499 and A. Yegin, "Protocol for Carrying Authentication for 1500 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1501 May 2008, . 1503 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1504 (TLS) Protocol Version 1.2", RFC 5246, 1505 DOI 10.17487/RFC5246, August 2008, 1506 . 1508 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1509 Authentication Protocol (EAP) Key Management Framework", 1510 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1511 . 1513 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 1514 Protocol Tunneled Transport Layer Security Authenticated 1515 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 1516 DOI 10.17487/RFC5281, August 2008, 1517 . 1519 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1520 Verification of Domain-Based Application Service Identity 1521 within Internet Public Key Infrastructure Using X.509 1522 (PKIX) Certificates in the Context of Transport Layer 1523 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1524 2011, . 1526 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1527 Ed., "Diameter Base Protocol", RFC 6733, 1528 DOI 10.17487/RFC6733, October 2012, 1529 . 1531 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1532 "Tunnel Extensible Authentication Protocol (TEAP) Version 1533 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1534 . 1536 [RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., 1537 and D. Kroeselberg, "Extensions to the Emergency Services 1538 Architecture for Dealing With Unauthenticated and 1539 Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, 1540 December 2014, . 1542 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1543 Known Attacks on Transport Layer Security (TLS) and 1544 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1545 February 2015, . 1547 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1548 "Recommendations for Secure Use of Transport Layer 1549 Security (TLS) and Datagram Transport Layer Security 1550 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1551 2015, . 1553 [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 1554 Architecture for Network Roaming", RFC 7593, 1555 DOI 10.17487/RFC7593, September 2015, 1556 . 1558 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1559 Writing an IANA Considerations Section in RFCs", BCP 26, 1560 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1561 . 1563 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1564 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1565 . 1567 [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1568 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1569 . 1571 [I-D.ietf-tls-md5-sha1-deprecate] 1572 Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating 1573 MD5 and SHA-1 signature hashes in (D)TLS 1.2", Work in 1574 Progress, Internet-Draft, draft-ietf-tls-md5-sha1- 1575 deprecate-09, 20 September 2021, 1576 . 1579 [I-D.ietf-emu-eaptlscert] 1580 Sethi, M., Mattsson, J., and S. Turner, "Handling Large 1581 Certificates and Long Certificate Chains in TLS-based EAP 1582 Methods", Work in Progress, Internet-Draft, draft-ietf- 1583 emu-eaptlscert-08, 20 November 2020, 1584 . 1587 [I-D.ietf-tls-ticketrequests] 1588 Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket 1589 Requests", Work in Progress, Internet-Draft, draft-ietf- 1590 tls-ticketrequests-07, 3 December 2020, 1591 . 1594 [I-D.ietf-emu-tls-eap-types] 1595 DeKok, A., "TLS-based EAP types and TLS 1.3", Work in 1596 Progress, Internet-Draft, draft-ietf-emu-tls-eap-types-03, 1597 22 June 2021, . 1600 [I-D.ietf-tls-rfc8446bis] 1601 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1602 Version 1.3", Work in Progress, Internet-Draft, draft- 1603 ietf-tls-rfc8446bis-02, 23 August 2021, 1604 . 1607 Appendix A. Updated References 1609 All the following references in [RFC5216] are updated as specified 1610 below when EAP-TLS is used with TLS 1.3. 1612 All references to [RFC2560] are updated to refer to [RFC6960]. 1614 All references to [RFC3280] are updated to refer to [RFC5280]. 1615 References to Section 4.2.1.13 of [RFC3280] are updated to refer to 1616 Section 4.2.1.12 of [RFC5280]. 1618 All references to [RFC4282] are updated to refer to [RFC7542]. 1619 References to Section 2.1 of [RFC4282] are updated to refer to 1620 Section 2.2 of [RFC7542]. 1622 Acknowledgments 1624 The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton, 1625 Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar, 1626 Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa 1627 Torvinen, Hannes Tschofenig, and Heikki Vatiainen for comments and 1628 suggestions on the draft. Special thanks to the document shepherd 1629 Joseph Salowey. 1631 Contributors 1633 Alan DeKok, FreeRADIUS 1635 Authors' Addresses 1637 John Preuß Mattsson 1638 Ericsson 1639 SE-164 40 Stockholm 1640 Sweden 1642 Email: john.mattsson@ericsson.com 1644 Mohit Sethi 1645 Ericsson 1646 FI-02420 Jorvas 1647 Finland 1649 Email: mohit@piuha.net