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