idnits 2.17.1 draft-ietf-emu-eap-tls13-20.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1418): 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 September 2021) is 967 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 994 -- Looks like a reference, but probably isn't: '2' on line 998 -- Looks like a reference, but probably isn't: '3' on line 1005 -- Looks like a reference, but probably isn't: '4' on line 1010 -- 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-08 == 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-02 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 September 2021 6 Expires: 7 March 2022 8 Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) 9 draft-ietf-emu-eap-tls13-20 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 7 March 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 . . . . . . . . . . . . . . . . . . . . . 11 68 2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 14 69 2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 15 70 2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 16 71 2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 17 72 2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 17 73 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 18 74 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 19 75 2.4. Parameter Negotiation and Compliance Requirements . . . . 20 76 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 21 77 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 22 78 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 80 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 22 81 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 23 82 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 23 83 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 23 84 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 24 85 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 25 86 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 25 87 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 27 88 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 29 89 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 29 90 5.11. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 29 91 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 6.1. Normative References . . . . . . . . . . . . . . . . . . 30 93 6.2. Informative references . . . . . . . . . . . . . . . . . 31 94 Appendix A. Updated References . . . . . . . . . . . . . . . . . 35 95 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 96 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 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] by amending it with the 191 following text. 193 If the TLS implementation correctly implements TLS version 194 negotiation, EAP-TLS will automatically leverage that capability. 195 The EAP-TLS implementation needs to know which version of TLS was 196 negotiated to correctly support EAP-TLS 1.3 as well as to maintain 197 backward compatibility with EAP-TLS 1.2. 199 TLS 1.3 changes both the message flow and the handshake messages 200 compared to earlier versions of TLS. Therefore, much of Section 2.1 201 of [RFC5216] does not apply for TLS 1.3. Except for Sections 2.2 and 202 5.7 this document applies only when TLS 1.3 is negotiated. When TLS 203 1.2 is negotiated, then [RFC5216] applies. 205 TLS 1.3 introduces several new handshake messages including 206 HelloRetryRequest, NewSessionTicket, and KeyUpdate. In general, 207 these messages will be handled by the underlying TLS libraries and 208 are not visible to EAP-TLS, however there are a few things to note: 210 * The HelloRetryRequest is used by the server to reject the 211 parameters offered in the ClientHello and suggest new parameters. 212 When this message is encountered it will increase the number of 213 round trips used by the protocol. 215 * The NewSessionTicket message is used to convey resumption 216 information and is covered in Sections 2.1.2 and 2.1.3. 218 * The KeyUpdate message is used to update the traffic keys used on a 219 TLS connection. EAP-TLS does not encrypt significant amounts of 220 data so this functionality is not needed. Implementations SHOULD 221 NOT send this message, however some TLS libraries may 222 automatically generate and process this message. 224 * Early Data MUST NOT be used in EAP-TLS. EAP-TLS servers MUST NOT 225 send an early_data extension and clients MUST NOT send an 226 EndOfEarlyData message. 228 * Servers MUST NOT request post-handshake client authentication. 230 After receiving an EAP-Request packet with EAP-Type=EAP-TLS as 231 described in [RFC5216] the conversation will continue with the TLS 232 handshake protocol encapsulated in the data fields of EAP-Response 233 and EAP-Request packets. When EAP-TLS is used with TLS version 1.3, 234 the formatting and processing of the TLS handshake SHALL be done as 235 specified in version 1.3 of TLS. This document only lists additional 236 and different requirements, restrictions, and processing compared to 237 [RFC8446] and [RFC5216]. 239 2.1.1. Authentication 241 This section updates Section 2.1.1 of [RFC5216] by amending it with 242 the following text. 244 The EAP-TLS server MUST authenticate with a certificate and SHOULD 245 require the EAP-TLS peer to authenticate with a certificate. 246 Certificates can be of any type supported by TLS including raw public 247 keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except 248 for resumption. The full handshake in EAP-TLS with TLS 1.3 always 249 provides forward secrecy by exchange of ephemeral "key_share" 250 extensions in the ClientHello and ServerHello (e.g., containing 251 ephemeral ECDHE public keys). SessionID is deprecated in TLS 1.3, 252 see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early 253 application data which like all other application data is not used in 254 EAP-TLS, see Section 4.2.10 of [RFC8446] for additional information 255 of the "early_data" extension. Resumption is handled as described in 256 Section 2.1.3. As a protected success indication [RFC3748] the EAP- 257 TLS server always sends TLS application data 0x00, see Section 2.5. 258 Note that a TLS implementation MAY not allow the EAP-TLS layer to 259 control in which order things are sent and the application data MAY 260 therefore be sent before a NewSessionTicket. TLS application data 261 0x00 is therefore to be interpreted as success after the EAP-Request 262 that contains TLS application data 0x00. After the EAP-TLS server 263 has sent an EAP-Request containing the TLS application data 0x00 and 264 received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the 265 EAP-TLS server sends EAP-Success. 267 Figure 1 shows an example message flow for a successful EAP-TLS full 268 handshake with mutual authentication (and neither HelloRetryRequest 269 nor post-handshake messages are sent). 271 EAP-TLS Peer EAP-TLS Server 273 EAP-Request/ 274 <-------- Identity 275 EAP-Response/ 276 Identity (Privacy-Friendly) --------> 277 EAP-Request/ 278 EAP-Type=EAP-TLS 279 <-------- (TLS Start) 280 EAP-Response/ 281 EAP-Type=EAP-TLS 282 (TLS ClientHello) --------> 283 EAP-Request/ 284 EAP-Type=EAP-TLS 285 (TLS ServerHello, 286 TLS EncryptedExtensions, 287 TLS CertificateRequest, 288 TLS Certificate, 289 TLS CertificateVerify, 290 <-------- TLS Finished) 291 EAP-Response/ 292 EAP-Type=EAP-TLS 293 (TLS Certificate, 294 TLS CertificateVerify, 295 TLS Finished) --------> 296 EAP-Request/ 297 EAP-Type=EAP-TLS 298 <-------- (TLS Application Data 0x00) 299 EAP-Response/ 300 EAP-Type=EAP-TLS --------> 301 <-------- EAP-Success 303 Figure 1: EAP-TLS mutual authentication 305 2.1.2. Ticket Establishment 307 This is a new section when compared to [RFC5216]. 309 To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS 310 server MUST send one or more post-handshake NewSessionTicket messages 311 (each associated with a PSK, a PSK identity, a ticket lifetime, and 312 other parameters) in the initial authentication. Note that TLS 1.3 313 [RFC8446] limits the ticket lifetime to a maximum of 604800 seconds 314 (7 days) and EAP-TLS servers MUST respect this upper limit when 315 issuing tickets. The NewSessionTicket is sent after the EAP-TLS 316 server has received the client Finished message in the initial 317 authentication. The NewSessionTicket can be sent in the same flight 318 as the TLS server Finished or later. The PSK associated with the 319 ticket depends on the client Finished and cannot be pre-computed in 320 handshakes with client authentication. The NewSessionTicket message 321 MUST NOT include an "early_data" extension. If the "early_data" 322 extension is received then it MUST be ignored. Servers should take 323 into account that fewer NewSessionTickets will likely be needed in 324 EAP-TLS than in the usual HTTPS connection scenario. In most cases a 325 single NewSessionTicket will be sufficient. A mechanism by which 326 clients can specify the desired number of tickets needed for future 327 connections is defined in [I-D.ietf-tls-ticketrequests]. 329 Figure 2 shows an example message flow for a successful EAP-TLS full 330 handshake with mutual authentication and ticket establishment of a 331 single ticket. 333 EAP-TLS Peer EAP-TLS Server 335 EAP-Request/ 336 <-------- Identity 337 EAP-Response/ 338 Identity (Privacy-Friendly) --------> 339 EAP-Request/ 340 EAP-Type=EAP-TLS 341 <-------- (TLS Start) 342 EAP-Response/ 343 EAP-Type=EAP-TLS 344 (TLS ClientHello) --------> 345 EAP-Request/ 346 EAP-Type=EAP-TLS 347 (TLS ServerHello, 348 TLS EncryptedExtensions, 349 TLS CertificateRequest, 350 TLS Certificate, 351 TLS CertificateVerify, 352 <-------- TLS Finished) 353 EAP-Response/ 354 EAP-Type=EAP-TLS 355 (TLS Certificate, 356 TLS CertificateVerify, 357 TLS Finished) --------> 358 EAP-Request/ 359 EAP-Type=EAP-TLS 360 (TLS NewSessionTicket, 361 <-------- (TLS Application Data 0x00) 362 EAP-Response/ 363 EAP-Type=EAP-TLS --------> 364 <-------- EAP-Success 366 Figure 2: EAP-TLS ticket establishment 368 2.1.3. Resumption 370 This section updates Section 2.1.2 of [RFC5216] by amending it with 371 the following text. 373 EAP-TLS is typically used with client authentication and typically 374 fragments the TLS flights into a large number of EAP requests and EAP 375 responses. Resumption significantly reduces the number of round- 376 trips and enables the EAP-TLS server to omit database lookups needed 377 during a full handshake with client authentication. TLS 1.3 replaces 378 the session resumption mechanisms in earlier versions of TLS with a 379 new PSK exchange. When EAP-TLS is used with TLS version 1.3, EAP-TLS 380 SHALL use a resumption mechanism compatible with version 1.3 of TLS. 382 For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If 383 the client has received a NewSessionTicket message from the EAP-TLS 384 server, the client can use the PSK identity associated with the 385 ticket to negotiate the use of the associated PSK. If the EAP-TLS 386 server accepts it, then the resumed session has been deemed to be 387 authenticated, and securely associated with the prior authentication 388 or resumption. It is up to the EAP-TLS peer to use resumption, but 389 it is RECOMMENDED that the EAP-TLS peer use resumption if it has a 390 valid ticket that has not been used before. It is left to the EAP- 391 TLS server whether to accept resumption, but it is RECOMMENDED that 392 the EAP-TLS server accept resumption if the ticket which was issued 393 is still valid. However, the EAP-TLS server MAY choose to require a 394 full handshake. In the case a full handshake is required, the 395 negotiation proceeds as if the session was a new authentication, and 396 resumption had never been requested. The requirements of Sections 397 2.1.1 and 2.1.2 then apply in their entirety. As described in 398 Appendix C.4 of [RFC8446], reuse of a ticket allows passive observers 399 to correlate different connections. EAP-TLS peers and EAP-TLS 400 servers SHOULD follow the client tracking preventions in Appendix C.4 401 of [RFC8446]. 403 It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the 404 same realm during resumption and the original full handshake. This 405 requirement allows EAP packets to be routed to the same destination 406 as the original full handshake. If this recommendation is not 407 followed, resumption is likely impossible. When NAI reuse can be 408 done without privacy implications, it is RECOMMENDED to use the same 409 NAI in the resumption, as was used in the original full handshake 410 [RFC7542]. For example, the NAI @realm can safely be reused since it 411 does not provide any specific information to associate a user's 412 resumption attempt with the original full handshake. However, 413 reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path 414 attacker to associate a resumption attempt with the original full 415 handshake. The TLS PSK identity is typically derived by the TLS 416 implementation and may be an opaque blob without a routable realm. 417 The TLS PSK identity on its own is therefore unsuitable as a NAI in 418 the Identity Response. 420 Figure 3 shows an example message flow for a subsequent successful 421 EAP-TLS resumption handshake where both sides authenticate via a PSK 422 provisioned via an earlier NewSessionTicket and where the server 423 provisions a single new ticket. 425 EAP-TLS Peer EAP-TLS Server 427 EAP-Request/ 428 <-------- Identity 429 EAP-Response/ 430 Identity (Privacy-Friendly) --------> 431 EAP-Request/ 432 EAP-Type=EAP-TLS 433 <-------- (TLS Start) 434 EAP-Response/ 435 EAP-Type=EAP-TLS 436 (TLS ClientHello) --------> 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 key leakage does not compromise any earlier connections. The 467 "psk_dh_ke" mechanism MUST be used for resumption unless the 468 deployment has a local requirement to allow configuration of other 469 mechanisms. 471 2.1.4. Termination 473 This section updates Section 2.1.3 of [RFC5216] by amending it with 474 the following text. 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, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and 489 no data from the EAP-TLS peer, follwed 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) --------> 581 EAP-Request/ 582 EAP-Type=EAP-TLS 583 <-------- (TLS Start) 584 EAP-Response/ 585 EAP-Type=EAP-TLS 586 (TLS ClientHello) --------> 587 EAP-Request/ 588 EAP-Type=EAP-TLS 589 (TLS ServerHello, 590 TLS EncryptedExtensions, 591 TLS CertificateRequest, 592 TLS Certificate, 593 TLS CertificateVerify, 594 <-------- TLS Finished) 595 EAP-Response/ 596 EAP-Type=EAP-TLS 597 (TLS Certificate, 598 TLS CertificateVerify, 599 TLS Finished) --------> 600 EAP-Request/ 601 EAP-Type=EAP-TLS 602 <-------- (TLS Error Alert) 603 EAP-Response/ 604 EAP-Type=EAP-TLS --------> 605 <-------- EAP-Failure 607 Figure 6: EAP-TLS unsuccessful client authentication 609 2.1.5. No Peer Authentication 611 This is a new section when compared to [RFC5216]. 613 Figure 7 shows an example message flow for a successful EAP-TLS full 614 handshake without peer authentication (e.g., emergency services, as 615 described in [RFC7406]). 617 EAP-TLS Peer EAP-TLS Server 619 EAP-Request/ 620 <-------- Identity 621 EAP-Response/ 622 Identity (Privacy-Friendly) --------> 623 EAP-Request/ 624 EAP-Type=EAP-TLS 625 <-------- (TLS Start) 626 EAP-Response/ 627 EAP-Type=EAP-TLS 628 (TLS ClientHello) --------> 629 EAP-Request/ 630 EAP-Type=EAP-TLS 631 (TLS ServerHello, 632 TLS EncryptedExtensions, 633 TLS Certificate, 634 TLS CertificateVerify, 635 <-------- TLS Finished) 636 EAP-Response/ 637 EAP-Type=EAP-TLS 638 (TLS Finished) --------> 639 EAP-Request/ 640 EAP-Type=EAP-TLS 641 <-------- (TLS Application Data 0x00) 642 EAP-Response/ 643 EAP-Type=EAP-TLS --------> 644 <-------- EAP-Success 646 Figure 7: EAP-TLS without peer authentication 648 2.1.6. Hello Retry Request 650 This is a new section when compared to [RFC5216]. 652 As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a 653 HelloRetryRequest message in response to a ClientHello if the EAP-TLS 654 server finds an acceptable set of parameters but the initial 655 ClientHello does not contain all the needed information to continue 656 the handshake. One use case is if the EAP-TLS server does not 657 support the groups in the "key_share" extension (or there is no 658 "key_share" extension), but supports one of the groups in the 659 "supported_groups" extension. In this case the client should send a 660 new ClientHello with a "key_share" that the EAP-TLS server supports. 662 Figure 8 shows an example message flow for a successful EAP-TLS full 663 handshake with mutual authentication and HelloRetryRequest. Note the 664 extra round-trip as a result of the HelloRetryRequest. 666 EAP-TLS Peer EAP-TLS Server 668 EAP-Request/ 669 <-------- Identity 670 EAP-Response/ 671 Identity (Privacy-Friendly) --------> 672 EAP-Request/ 673 EAP-Type=EAP-TLS 674 <-------- (TLS Start) 675 EAP-Response/ 676 EAP-Type=EAP-TLS 677 (TLS ClientHello) --------> 678 EAP-Request/ 679 EAP-Type=EAP-TLS 680 (TLS HelloRetryRequest) 681 <-------- 682 EAP-Response/ 683 EAP-Type=EAP-TLS 684 (TLS ClientHello) --------> 685 EAP-Request/ 686 EAP-Type=EAP-TLS 687 (TLS ServerHello, 688 TLS EncryptedExtensions, 689 TLS CertificateRequest, 690 TLS Certificate, 691 TLS CertificateVerify, 692 TLS Finished) 693 EAP-Response/ 694 EAP-Type=EAP-TLS 695 (TLS Certificate, 696 TLS CertificateVerify, 697 TLS Finished) --------> 698 EAP-Request/ 699 EAP-Type=EAP-TLS 700 <-------- (TLS Application Data 0x00) 701 EAP-Response/ 702 EAP-Type=EAP-TLS --------> 703 <-------- EAP-Success 705 Figure 8: EAP-TLS with Hello Retry Request 707 2.1.7. Identity 709 This is a new section when compared to [RFC5216]. 711 It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity 712 Response as such identities are routable and privacy-friendly. While 713 opaque blobs are allowed by [RFC3748], such identities are NOT 714 RECOMMENDED as they are not routable and should only be considered in 715 local deployments where the EAP-TLS peer, EAP authenticator, and EAP- 716 TLS server all belong to the same network. Many client certificates 717 contain an identity such as an email address, which is already in NAI 718 format. When the client certificate contains a NAI as subject name 719 or alternative subject name, an anonymous NAI SHOULD be derived from 720 the NAI in the certificate, see Section 2.1.8. More details on 721 identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8. 723 2.1.8. Privacy 725 This section updates Section 2.1.4 of [RFC5216] by amending it with 726 the following text. 728 EAP-TLS 1.3 significantly improves privacy when compared to earlier 729 versions of EAP-TLS. EAP-TLS 1.3 forbids cipher suites without 730 confidentiality which means that TLS 1.3 is always encrypting large 731 parts of the TLS handshake including the certificate messages. 733 EAP-TLS peer and server implementations supporting TLS 1.3 MUST 734 support anonymous Network Access Identifiers (NAIs) (Section 2.4 in 735 [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its username 736 in cleartext in the Identity Response. Following [RFC7542], it is 737 RECOMMENDED to omit the username (i.e., the NAI is @realm), but other 738 constructions such as a fixed username (e.g., anonymous@realm) or an 739 encrypted username (e.g., 740 xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. 741 Note that the NAI MUST be a UTF-8 string as defined by the grammar in 742 Section 2.2 of [RFC7542]. 744 As the certificate messages in TLS 1.3 are encrypted, there is no 745 need to send an empty certificate_list and perform a second handshake 746 for privacy (as needed by EAP-TLS with earlier versions of TLS). 747 When EAP-TLS is used with TLS version 1.3 the EAP-TLS peer and EAP- 748 TLS server SHALL follow the processing specified by version 1.3 of 749 TLS. This means that the EAP-TLS peer only sends an empty 750 certificate_list if it does not have an appropriate certificate to 751 send, and the EAP-TLS server MAY treat an empty certificate_list as a 752 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 with 761 the following text. 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 TLS Message Length field of four octets. Implementations 768 MUST NOT set the L bit in unfragmented messages, but MUST accept 769 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 with the 783 following text. The guidance in this section is relevant for EAP-TLS 784 in general (regardless of the underlying TLS version used). 786 The EAP peer identity provided in the EAP-Response/Identity is not 787 authenticated by EAP-TLS. Unauthenticated information MUST NOT be 788 used for accounting purposes or to give authorization. The 789 authenticator and the EAP-TLS server MAY examine the identity 790 presented in EAP-Response/Identity for purposes such as routing and 791 EAP method selection. EAP-TLS servers MAY reject conversations if 792 the identity does not match their policy. Note that this also 793 applies to resumption, see Sections 2.1.3, 5.6, and 5.7. 795 The EAP server identity in the TLS server certificate is typically a 796 fully qualified domain name (FQDN) in the SubjectAltName (SAN) 797 extension. Since EAP-TLS deployments may use more than one EAP 798 server, each with a different certificate, EAP peer implementations 799 SHOULD allow for the configuration of one or more trusted root 800 certificates (CA certificate) to authenticate the server certificate 801 and one or more server names to match against the SubjectAltName 802 (SAN) extension in the server certificate. If any of the configured 803 names match any of the names in the SAN extension then the name check 804 passes. To simplify name matching, an EAP-TLS deployment can assign 805 a name to represent an authorized EAP server and EAP Server 806 certificates can include this name in the list of SANs for each 807 certificate that represents an EAP-TLS server. If server name 808 matching is not used, then it degrades the confidence that the EAP 809 server with which it is interacting is authoritative for the given 810 network. If name matching is not used with a public root CA, then 811 effectively any server can obtain a certificate which will be trusted 812 for EAP authentication by the Peer. While this requirement to verify 813 domain names is new, and was not mentioned in [RFC5216], it has been 814 widely implemented in EAP-TLS peers. As such, it is believed that 815 this section contains minimal new interoperability or implementation 816 requirements on EAP-TLS peers and can be applied to earlier versions 817 of TLS. 819 The process of configuring a root CA certificate and a server name is 820 non-trivial and therefore automated methods of provisioning are 821 RECOMMENDED. For example, the eduroam federation [RFC7593] provides 822 a Configuration Assistant Tool (CAT) to automate the configuration 823 process. In the absence of a trusted root CA certificate (user 824 configured or system-wide), EAP peers MAY implement a trust on first 825 use (TOFU) mechanism where the peer trusts and stores the server 826 certificate during the first connection attempt. The EAP peer 827 ensures that the server presents the same stored certificate on 828 subsequent interactions. Use of a TOFU mechanism does not allow for 829 the server certificate to change without out-of-band validation of 830 the certificate and is therefore not suitable for many deployments 831 including ones where multiple EAP servers are deployed for high 832 availability. TOFU mechanisms increase the susceptibility to traffic 833 interception attacks and should only be used if there are adequate 834 controls in place to mitigate this risk. 836 2.3. Key Hierarchy 838 This section updates Section 2.3 of [RFC5216] by replacing it with 839 the following text. 841 TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier 842 versions of TLS with HKDF and completely changes the Key Schedule. 843 The key hierarchies shown in Section 2.3 of [RFC5216] are therefore 844 not correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3 845 the key schedule is described in Section 7.1 of [RFC8446]. 847 When EAP-TLS is used with TLS version 1.3 the Key_Material and 848 Method-Id SHALL be derived from the exporter_secret using the TLS 849 exporter interface [RFC5705] (for TLS 1.3 this is defined in 850 Section 7.5 of [RFC8446]). Type is the value of the EAP Type field 851 defined in Section 2 of [RFC3748]. For EAP-TLS the Type field has 852 value 0x0D. 854 Type = 0x0D 855 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 856 Type, 128) 857 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 858 Type, 64) 859 Session-Id = Type || Method-Id 861 The MSK and EMSK are derived from the Key_Material in the same manner 862 as with EAP-TLS [RFC5216], Section 2.3. The definitions are repeated 863 below for simplicity: 865 MSK = Key_Material(0, 63) 866 EMSK = Key_Material(64, 127) 868 Other TLS based EAP methods can use the TLS exporter in a similar 869 fashion, see [I-D.ietf-emu-tls-eap-types]. 871 [RFC5247] deprecates the use of IV. Thus, RECV-IV and SEND-IV are 872 not exported in EAP-TLS with TLS 1.3. As noted in [RFC5247], lower 873 layers use the MSK in a lower-layer dependent manner. EAP-TLS with 874 TLS 1.3 exports the MSK and does not specify how it is used by lower 875 layers. 877 Note that the key derivation MUST use the length values given above. 878 While in TLS 1.2 and earlier it was possible to truncate the output 879 by requesting less data from the TLS-Exporter function, this practice 880 is not possible with TLS 1.3. If an implementation intends to use 881 only a part of the output of the TLS-Exporter function, then it MUST 882 ask for the full output and then only use the desired part. Failure 883 to do so will result in incorrect values being calculated for the 884 above keying material. 886 By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation 887 which provides a public API for the exporter. Note that EAP-TLS with 888 TLS 1.2 [RFC5216] can be used with the TLS exporter since the public 889 exporter was defined in [RFC5705]. 891 2.4. Parameter Negotiation and Compliance Requirements 893 This section updates Section 2.4 of [RFC5216] by amending it with the 894 following text. 896 TLS 1.3 cipher suites are defined differently than in earlier 897 versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites 898 discussed in Section 2.4 of [RFC5216] can therefore not be used when 899 EAP-TLS is used with TLS version 1.3. 901 When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- 902 TLS servers MUST comply with the compliance requirements (mandatory- 903 to-implement cipher suites, signature algorithms, key exchange 904 algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. In 905 EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL 906 be supported. 908 While EAP-TLS does not protect any application data except for the 909 TLS record with application data 0x00, the negotiated cipher suites 910 and algorithms MAY be used to secure data as done in other TLS-based 911 EAP methods. 913 2.5. EAP State Machines 915 This is a new section when compared to [RFC5216] and only applies to 916 TLS 1.3. [RFC4137] offers a proposed state machine for EAP. 918 TLS 1.3 [RFC8446] introduces post-handshake messages. These post- 919 handshake messages use the handshake content type and can be sent 920 after the main handshake. Examples of post-handshake messages are 921 NewSessionTicket, which is used for resumption and KeyUpdate, which 922 is not useful and not expected in EAP-TLS. After sending TLS 923 Finished, the EAP-TLS server may send any number of post-handshake 924 messages in separate EAP-Requests. 926 To provide a protected success result indication and to decrease the 927 uncertainty for the EAP-TLS peer, the following procedure MUST be 928 followed: 930 When an EAP-TLS server has successfully processed the TLS client 931 Finished and sent its last handshake message (Finished or a post- 932 handshake message), it sends an encrypted TLS record with application 933 data 0x00. The encrypted TLS record with application data 0x00 is a 934 protected success result indication, as defined in [RFC3748]. After 935 sending an EAP-Request that contains the protected success result 936 indication, the EAP-TLS server must not send any more EAP-Request and 937 may only send an EAP-Success. The EAP-TLS server MUST NOT send an 938 encrypted TLS record with application data 0x00 alert before it has 939 successfully processed the client finished and sent its last 940 handshake message. 942 TLS Error alerts SHOULD be considered a failure result indication, as 943 defined in [RFC3748]. Implementations following [RFC4137] sets the 944 alternate indication of failure variable altReject after sending or 945 receiving an error alert. After sending or receiving a TLS Error 946 alert, the EAP-TLS server may only send an EAP-Failure. Protected 947 TLS Error alerts are protected failure result indications, 948 unprotected TLS Error alerts are not. 950 The keying material can be derived after the TLS server Finished has 951 been sent or received. Implementations following [RFC4137] can then 952 set the eapKeyData and aaaEapKeyData variables. 954 The keying material can be made available to lower layers and the 955 authenticator after the authenticated success result indication has 956 been sent or received. Implementations following [RFC4137] can set 957 the eapKeyAvailable and aaaEapKeyAvailable variables. 959 3. Detailed Description of the EAP-TLS Protocol 961 No updates to Section 3 of [RFC5216]. 963 4. IANA considerations 965 This section provides guidance to the Internet Assigned Numbers 966 Authority (IANA) regarding registration of values related to the EAP- 967 TLS 1.3 protocol in accordance with [RFC8126]. 969 This document requires IANA to add the following labels to the TLS 970 Exporter Label Registry defined by [RFC5705]. These labels are used 971 in derivation of Key_Material and Method-Id as defined in 972 Section 2.3: 974 +===============================+=========+=============+======+ 975 | Value | DTLS-OK | Recommended | Note | 976 +===============================+=========+=============+======+ 977 | EXPORTER_EAP_TLS_Key_Material | N | Y | | 978 +-------------------------------+---------+-------------+------+ 979 +-------------------------------+---------+-------------+------+ 980 | EXPORTER_EAP_TLS_Method-Id | N | Y | | 981 +-------------------------------+---------+-------------+------+ 983 Table 1: TLS Exporter Label Registry 985 5. Security Considerations 987 5.1. Security Claims 989 Using EAP-TLS with TLS 1.3 does not change the security claims for 990 EAP-TLS as given in Section 5.1 of [RFC5216]. However, it 991 strengthens several of the claims as described in the following 992 updates to the notes given in Section 5.1 of [RFC5216]. 994 [1] Mutual authentication: By mandating revocation checking of 995 certificates, the authentication in EAP-TLS with TLS 1.3 is stronger 996 as authentication with revoked certificates will always fail. 998 [2] Confidentiality: The TLS 1.3 handshake offers much better 999 confidentiality than earlier versions of TLS. EAP-TLS with TLS 1.3 1000 mandates use of cipher suites that ensure confidentiality. TLS 1.3 1001 also encrypts certificates and some of the extensions. When using 1002 EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not 1003 cause any additional round-trips. 1005 [3] Cryptographic strength: TLS 1.3 only defines strong algorithms 1006 without major weaknesses and EAP-TLS with TLS 1.3 always provides 1007 forward secrecy, see [RFC8446]. Weak algorithms such as 3DES, CBC 1008 mode, RC4, SHA-1, MD5, P-192, and RSA-1024 cannot be negotiated. 1010 [4] Cryptographic Negotiation: The TLS layer handles the negotiation 1011 of cryptographic parameters. When EAP-TLS is used with TLS 1.3, EAP- 1012 TLS inherits the cryptographic negotiation of AEAD algorithm, HKDF 1013 hash algorithm, key exchange groups, and signature algorithm, see 1014 Section 4.1.1 of [RFC8446]. 1016 5.2. Peer and Server Identities 1018 No updates to section 5.2 of [RFC5216]. Note that Section 2.2 has 1019 additional discussion on identities. 1021 5.3. Certificate Validation 1023 No updates to section 5.3 of [RFC5216]. 1025 5.4. Certificate Revocation 1027 This section updates Section 5.4 of [RFC5216] by amending it with the 1028 following text. 1030 There are a number of reasons (e.g., key compromise, CA compromise, 1031 privilege withdrawn, etc.) why EAP-TLS peer, EAP-TLS server, or sub- 1032 CA certificates have to be revoked before their expiry date. 1033 Revocation of the EAP-TLS server's certificate is complicated by the 1034 fact that the EAP-TLS peer may not have Internet connectivity until 1035 authentication completes. 1037 When EAP-TLS is used with TLS 1.3, the revocation status of all the 1038 certificates in the certificate chains MUST be checked (except the 1039 trust anchor). An implementation may use Certificate Revocation List 1040 (CRL), Online Certificate Status Protocol (OSCP), or other 1041 standardized/proprietary methods for revocation checking. Examples 1042 of proprietary methods are non-standard formats for distribution of 1043 revocation lists as well as certificates with very short lifetime. 1045 EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status 1046 Requests (OCSP stapling) as specified in [RFC6066] and 1047 Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers 1048 and EAP-TLS servers use OCSP stapling for verifying the status of the 1049 EAP-TLS server's certificate chain. When an EAP-TLS peer uses 1050 Certificate Status Requests to check the revocation status of the 1051 EAP-TLS server's certificate chain it MUST treat a CertificateEntry 1052 (except the trust anchor) without a valid CertificateStatus extension 1053 as invalid and abort the handshake with an appropriate alert. The 1054 OCSP status handling in TLS 1.3 is different from earlier versions of 1055 TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP 1056 information is carried in the CertificateEntry containing the 1057 associated certificate instead of a separate CertificateStatus 1058 message as in [RFC6066]. This enables sending OCSP information for 1059 all certificates in the certificate chain (except the trust anchor). 1061 To enable revocation checking in situations where EAP-TLS peers do 1062 not implement or use OCSP stapling, and where network connectivity is 1063 not available prior to authentication completion, EAP-TLS peer 1064 implementations MUST also support checking for certificate revocation 1065 after authentication completes and network connectivity is available. 1066 An EAP peer implementation SHOULD NOT trust the network (and any 1067 services) until it has verified the revocation status of the server 1068 certificate after receiving network connectivity. An EAP peer MUST 1069 use a secure transport to verify the revocation status of the server 1070 certificate. An EAP peer SHOULD NOT send any other traffic before 1071 revocation checking for the server certificate is complete. 1073 5.5. Packet Modification Attacks 1075 This section updates Section 5.5 of [RFC5216] by amending it with the 1076 following text. 1078 As described in [RFC3748] and Section 5.5 of [RFC5216], the only 1079 information that is integrity and replay protected in EAP-TLS are the 1080 parts of the TLS Data that TLS protects. All other information in 1081 the EAP-TLS message exchange including EAP-Request and EAP-Response 1082 headers, the identity in the identity response, EAP-TLS packet header 1083 fields, Type, and Flags, EAP-Success, and EAP-Failure can be 1084 modified, spoofed, or replayed. 1086 Protected TLS Error alerts are protected failure result indications 1087 and enables the EAP-TLS peer and EAP-TLS server to determine that the 1088 failure result was not spoofed by an attacker. Protected failure 1089 result indications provide integrity and replay protection but MAY be 1090 unauthenticated. Protected failure results do not significantly 1091 improve availability as TLS 1.3 treats most malformed data as a fatal 1092 error. 1094 5.6. Authorization 1096 This is a new section when compared to [RFC5216]. The guidance in 1097 this section is relevant for EAP-TLS in general (regardless of the 1098 underlying TLS version used). 1100 EAP servers will usually require the EAP peer to provide a valid 1101 certificate and will fail the connection if one is not provided. 1102 Some deployments may permit no peer authentication for some or all 1103 connections. When peer authentication is not used, EAP-TLS server 1104 implementations MUST take care to limit network access appropriately 1105 for unauthenticated peers and implementations MUST use resumption 1106 with caution to ensure that a resumed session is not granted more 1107 privilege than was intended for the original session. An example of 1108 limiting network access would be to invoke a vendor's walled garden 1109 or quarantine network functionality. 1111 EAP-TLS is typically encapsulated in other protocols, such as PPP 1112 [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. 1113 The encapsulating protocols can also provide additional, non-EAP 1114 information to an EAP-TLS server. This information can include, but 1115 is not limited to, information about the authenticator, information 1116 about the EAP-TLS peer, or information about the protocol layers 1117 above or below EAP (MAC addresses, IP addresses, port numbers, WiFi 1118 SSID, etc.). EAP-TLS servers implementing EAP-TLS inside those 1119 protocols can make policy decisions and enforce authorization based 1120 on a combination of information from the EAP-TLS exchange and non-EAP 1121 information. 1123 As noted in Section 2.2, the identity presented in EAP-Response/ 1124 Identity is not authenticated by EAP-TLS and is therefore trivial for 1125 an attacker to forge, modify, or replay. Authorization and 1126 accounting MUST be based on authenticated information such as 1127 information in the certificate or the PSK identity and cached data 1128 provisioned for resumption as described in Section 5.7. Note that 1129 the requirements for Network Access Identifiers (NAIs) specified in 1130 Section 4 of [RFC7542] still apply and MUST be followed. 1132 EAP-TLS servers MAY reject conversations based on non-EAP information 1133 provided by the encapsulating protocol, for example, if the MAC 1134 address of the authenticator does not match the expected policy. 1136 5.7. Resumption 1138 This is a new section when compared to [RFC5216]. The guidance in 1139 this section is relevant for EAP-TLS in general (regardless of the 1140 underlying TLS version used). 1142 There are a number of security issues related to resumption that are 1143 not described in [RFC5216]. The problems, guidelines, and 1144 requirements in this section therefore applies to EAP-TLS when it is 1145 used with any version of TLS. 1147 When resumption occurs, it is based on cached information at the TLS 1148 layer. To perform resumption in a secure way, the EAP-TLS peer and 1149 EAP-TLS server need to be able to securely retrieve authorization 1150 information such as certificate chains from the initial full 1151 handshake. This document uses the term "cached data" to describe 1152 such information. Authorization during resumption MUST be based on 1153 such cached data. The EAP-TLS peer and EAP-TLS server MAY perform 1154 fresh revocation checks on the cached certificate data. Any security 1155 policies for authorization MUST be followed also for resumption. The 1156 certificates may have been revoked since the initial full handshake 1157 and the authorizations of the other party may have reduced. If the 1158 cached revocation data is not sufficiently current, the EAP-TLS peer 1159 or EAP-TLS server MAY force a full TLS handshake. 1161 There are two ways to retrieve the cached data from the original full 1162 handshake. The first method is that the EAP-TLS server and client 1163 cache the information locally. The cached information is identified 1164 by an identifier. For TLS versions before 1.3, the identifier can be 1165 the session ID, for TLS 1.3, the identifier is the PSK identity. The 1166 second method for retrieving cached information is via [RFC5077] or 1167 [RFC8446], where the EAP-TLS server avoids storing information 1168 locally and instead encapsulates the information into a ticket or PSK 1169 which is sent to the client for storage. This ticket or PSK is 1170 encrypted using a key that only the EAP-TLS server knows. Note that 1171 the client still needs to cache the original handshake information 1172 locally and will use the session ID or PSK identity to lookup this 1173 information during resumption. However, the EAP-TLS server is able 1174 to decrypt the ticket or PSK to obtain the original handshake 1175 information. 1177 The EAP-TLS server or EAP client MUST cache data during the initial 1178 full handshake sufficient to allow authorization decisions to be made 1179 during resumption. If cached data cannot be retrieved in a secure 1180 way, resumption MUST NOT be done. 1182 The above requirements also apply if the EAP-TLS server expects some 1183 system to perform accounting for the session. Since accounting must 1184 be tied to an authenticated identity, and resumption does not supply 1185 such an identity, accounting is impossible without access to cached 1186 data. Therefore systems which expect to perform accounting for the 1187 session SHOULD cache an identifier which can be used in subsequent 1188 accounting. 1190 As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption 1191 PSKs or tickets (and associated cached data) for longer than 604800 1192 seconds (7 days), regardless of the PSK or ticket lifetime. The EAP- 1193 TLS peer MAY delete them earlier based on local policy. The cached 1194 data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any 1195 certificate in the certificate chain has been revoked or has expired. 1196 In all such cases, an attempt at resumption results in a full TLS 1197 handshake instead. 1199 Information from the EAP-TLS exchange (e.g., the identity provided in 1200 EAP-Response/Identity) as well as non-EAP information (e.g., IP 1201 addresses) may change between the initial full handshake and 1202 resumption. This change creates a "time-of-check time-of-use" 1203 (TOCTOU) security vulnerability. A malicious or compromised user 1204 could supply one set of data during the initial authentication, and a 1205 different set of data during resumption, potentially allowing them to 1206 obtain access that they should not have. 1208 If any authorization, accounting, or policy decisions were made with 1209 information that has changed between the initial full handshake and 1210 resumption, and if change may lead to a different decision, such 1211 decisions MUST be reevaluated. It is RECOMMENDED that authorization, 1212 accounting, and policy decisions are reevaluated based on the 1213 information given in the resumption. EAP-TLS servers MAY reject 1214 resumption where the information supplied during resumption does not 1215 match the information supplied during the original authentication. 1216 If a safe decision is not possible, EAP-TLS servers SHOULD reject the 1217 resumption and continue with a full handshake. 1219 Section 2.2 and 4.2.11 of [RFC8446] provides security considerations 1220 for TLS 1.3 resumption. 1222 5.8. Privacy Considerations 1224 This is a new section when compared to [RFC5216]. 1226 TLS 1.3 offers much better privacy than earlier versions of TLS as 1227 discussed in Section 2.1.8. In this section, we only discuss the 1228 privacy properties of EAP-TLS with TLS 1.3. For privacy properties 1229 of TLS 1.3 itself, see [RFC8446]. 1231 EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in 1232 EAP packets. Additionally, the EAP-TLS peer sends an identity in the 1233 first EAP-Response. The other fields in the EAP-TLS Request and the 1234 EAP-TLS Response packets do not contain any cleartext privacy 1235 sensitive information. 1237 Tracking of users by eavesdropping on identity responses or 1238 certificates is a well-known problem in many EAP methods. When EAP- 1239 TLS is used with TLS 1.3, all certificates are encrypted, and the 1240 username part of the identity response is not revealed (e.g., using 1241 anonymous NAIs). Note that even though all certificates are 1242 encrypted, the server's identity is only protected against passive 1243 attackers while client's identity is protected against both passive 1244 and active attackers. As with other EAP methods, even when privacy- 1245 friendly identifiers or EAP tunneling is used, the domain name (i.e., 1246 the realm) in the NAI is still typically visible. How much privacy 1247 sensitive information the domain name leaks is highly dependent on 1248 how many other users are using the same domain name in the particular 1249 access network. If all EAP-TLS peers have the same domain, no 1250 additional information is leaked. If a domain name is used by a 1251 small subset of the EAP-TLS peers, it may aid an attacker in tracking 1252 or identifying the user. 1254 Without padding, information about the size of the client certificate 1255 is leaked from the size of the EAP-TLS packets. The EAP-TLS packets 1256 sizes may therefore leak information that can be used to track or 1257 identify the user. If all client certificates have the same length, 1258 no information is leaked. EAP-TLS peers SHOULD use record padding, 1259 see Section 5.4 of [RFC8446] to reduce information leakage of 1260 certificate sizes. 1262 If anonymous NAIs are not used, the privacy-friendly identifiers need 1263 to be generated with care. The identities MUST be generated in a 1264 cryptographically secure way so that that it is computationally 1265 infeasible for an attacker to differentiate two identities belonging 1266 to the same user from two identities belonging to different users in 1267 the same realm. This can be achieved, for instance, by using random 1268 or pseudo-random usernames such as random byte strings or ciphertexts 1269 and only using the pseudo-random usernames a single time. Note that 1270 the privacy-friendly usernames also MUST NOT include substrings that 1271 can be used to relate the identity to a specific user. Similarly, 1272 privacy-friendly username MUST NOT be formed by a fixed mapping that 1273 stays the same across multiple different authentications. 1275 An EAP-TLS peer with a policy allowing communication with EAP-TLS 1276 servers supporting only TLS 1.2 without privacy and with a static RSA 1277 key exchange is vulnerable to disclosure of the EAP-TLS peer 1278 username. An active attacker can in this case make the EAP-TLS peer 1279 believe that an EAP-TLS server supporting TLS 1.3 only supports TLS 1280 1.2 without privacy. The attacker can simply impersonate the EAP-TLS 1281 server and negotiate TLS 1.2 with static RSA key exchange and send an 1282 TLS alert message when the EAP-TLS peer tries to use privacy by 1283 sending an empty certificate message. Since the attacker 1284 (impersonating the EAP-TLS server) does not provide a proof-of- 1285 possession of the private key until the Finished message when a 1286 static RSA key exchange is used, an EAP-TLS peer may inadvertently 1287 disclose its identity (username) to an attacker. Therefore, it is 1288 RECOMMENDED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and 1289 static RSA based cipher suites without privacy. This implies that an 1290 EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS 1291 server sends an EAP-TLS/Request with a TLS alert message in response 1292 to an empty certificate message from the peer. 1294 5.9. Pervasive Monitoring 1296 This is a new section when compared to [RFC5216]. 1298 Pervasive monitoring refers to widespread surveillance of users. In 1299 the context of EAP-TLS, pervasive monitoring attacks can target EAP- 1300 TLS peer devices for tracking them (and their users) as and when they 1301 join a network. By encrypting more information, mandating the use of 1302 privacy, and always providing forward secrecy, EAP-TLS with TLS 1.3 1303 offers much better protection against pervasive monitoring. In 1304 addition to the privacy attacks discussed above, surveillance on a 1305 large scale may enable tracking of a user over a wide geographical 1306 area and across different access networks. Using information from 1307 EAP-TLS together with information gathered from other protocols 1308 increases the risk of identifying individual users. 1310 5.10. Discovered Vulnerabilities 1312 This is a new section when compared to [RFC5216]. 1314 Over the years, there have been several serious attacks on earlier 1315 versions of Transport Layer Security (TLS), including attacks on its 1316 most commonly used ciphers and modes of operation. [RFC7457] 1317 summarizes the attacks that were known at the time of publishing and 1318 BCP 195 [RFC7525] provides recommendations for improving the security 1319 of deployed services that use TLS. However, many of the attacks are 1320 less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and 1321 does not protect any application data. EAP-TLS implementations MUST 1322 mitigate known attacks. EAP-TLS implementations need to monitor and 1323 follow new EAP and TLS related security guidance and requirements 1324 such as [RFC8447], [RFC8996], [I-D.ietf-tls-md5-sha1-deprecate]. 1326 5.11. Cross-Protocol Attacks 1328 This is a new section when compared to [RFC5216]. 1330 Allowing the same certificate to be used in multiple protocols can 1331 potentially allow an attacker to authenticate via one protocol, and 1332 then "resume" that session in another protocol. Section 2.2 above 1333 suggests that certificates typically have one or more FQDNs in the 1334 SAN extension. However, those fields are for EAP validation only, 1335 and do not indicate that the certificates are suitable for use on WWW 1336 (or other) protocol server on the named host. 1338 Section 2.1.3 above suggests that authorization rules should be re- 1339 applied on resumption, but does not mandate this behavior. As a 1340 result, this cross-protocol resumption could allow the attacker to 1341 bypass authorization policies, and to obtain undesired access to 1342 secured systems. Along with making sure that appropriate 1343 authorization information is available and used during resumption, 1344 using different certificates and resumption caches for different 1345 protocols is RECOMMENDED to help keep different protocol usages 1346 separate. 1348 6. References 1350 6.1. Normative References 1352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1353 Requirement Levels", BCP 14, RFC 2119, 1354 DOI 10.17487/RFC2119, March 1997, 1355 . 1357 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1358 Levkowetz, Ed., "Extensible Authentication Protocol 1359 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1360 . 1362 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1363 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 1364 March 2008, . 1366 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1367 Housley, R., and W. Polk, "Internet X.509 Public Key 1368 Infrastructure Certificate and Certificate Revocation List 1369 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1370 . 1372 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1373 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1374 March 2010, . 1376 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1377 Extensions: Extension Definitions", RFC 6066, 1378 DOI 10.17487/RFC6066, January 2011, 1379 . 1381 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1382 Galperin, S., and C. Adams, "X.509 Internet Public Key 1383 Infrastructure Online Certificate Status Protocol - OCSP", 1384 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1385 . 1387 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1388 DOI 10.17487/RFC7542, May 2015, 1389 . 1391 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1392 Writing an IANA Considerations Section in RFCs", BCP 26, 1393 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1394 . 1396 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1397 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1398 May 2017, . 1400 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1401 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1402 . 1404 [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1405 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1406 . 1408 6.2. Informative references 1410 [IEEE-802.1X] 1411 Institute of Electrical and Electronics Engineers, "IEEE 1412 Standard for Local and metropolitan area networks -- Port- 1413 Based Network Access Control", IEEE Standard 802.1X-2020 , 1414 February 2020. 1416 [IEEE-802.11] 1417 Institute of Electrical and Electronics Engineers, "IEEE 1418 Standard for Information technology—Telecommunications and 1419 information exchange between systems Local and 1420 metropolitan area networks—Specific requirements - Part 1421 11: Wireless LAN Medium Access Control (MAC) and Physical 1422 Layer (PHY) Specifications", IEEE Standard 802.11-2020 , 1423 February 2021. 1425 [IEEE-802.1AE] 1426 Institute of Electrical and Electronics Engineers, "IEEE 1427 Standard for Local and metropolitan area networks -- Media 1428 Access Control (MAC) Security", IEEE Standard 1429 802.1AE-2018 , December 2018. 1431 [TS.33.501] 1432 3GPP, "Security architecture and procedures for 5G 1433 System", 3GPP TS 33.501 17.2.1, July 2021. 1435 [MulteFire] 1436 MulteFire, "MulteFire Release 1.1 specification", 2019. 1438 [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible 1439 Authentication Protocol (PEAP)", April 2021. 1441 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 1442 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 1443 . 1445 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1446 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1447 . 1449 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1450 Adams, "X.509 Internet Public Key Infrastructure Online 1451 Certificate Status Protocol - OCSP", RFC 2560, 1452 DOI 10.17487/RFC2560, June 1999, 1453 . 1455 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1456 "Remote Authentication Dial In User Service (RADIUS)", 1457 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1458 . 1460 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1461 X.509 Public Key Infrastructure Certificate and 1462 Certificate Revocation List (CRL) Profile", RFC 3280, 1463 DOI 10.17487/RFC3280, April 2002, 1464 . 1466 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 1467 "State Machines for Extensible Authentication Protocol 1468 (EAP) Peer and Authenticator", RFC 4137, 1469 DOI 10.17487/RFC4137, August 2005, 1470 . 1472 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1473 Network Access Identifier", RFC 4282, 1474 DOI 10.17487/RFC4282, December 2005, 1475 . 1477 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1478 (TLS) Protocol Version 1.1", RFC 4346, 1479 DOI 10.17487/RFC4346, April 2006, 1480 . 1482 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 1483 Flexible Authentication via Secure Tunneling Extensible 1484 Authentication Protocol Method (EAP-FAST)", RFC 4851, 1485 DOI 10.17487/RFC4851, May 2007, 1486 . 1488 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1489 "Transport Layer Security (TLS) Session Resumption without 1490 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1491 January 2008, . 1493 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1494 and A. Yegin, "Protocol for Carrying Authentication for 1495 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1496 May 2008, . 1498 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1499 (TLS) Protocol Version 1.2", RFC 5246, 1500 DOI 10.17487/RFC5246, August 2008, 1501 . 1503 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1504 Authentication Protocol (EAP) Key Management Framework", 1505 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1506 . 1508 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 1509 Protocol Tunneled Transport Layer Security Authenticated 1510 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 1511 DOI 10.17487/RFC5281, August 2008, 1512 . 1514 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1515 Ed., "Diameter Base Protocol", RFC 6733, 1516 DOI 10.17487/RFC6733, October 2012, 1517 . 1519 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1520 "Tunnel Extensible Authentication Protocol (TEAP) Version 1521 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1522 . 1524 [RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., 1525 and D. Kroeselberg, "Extensions to the Emergency Services 1526 Architecture for Dealing With Unauthenticated and 1527 Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, 1528 December 2014, . 1530 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1531 Known Attacks on Transport Layer Security (TLS) and 1532 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1533 February 2015, . 1535 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1536 "Recommendations for Secure Use of Transport Layer 1537 Security (TLS) and Datagram Transport Layer Security 1538 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1539 2015, . 1541 [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 1542 Architecture for Network Roaming", RFC 7593, 1543 DOI 10.17487/RFC7593, September 2015, 1544 . 1546 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1547 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1548 . 1550 [I-D.ietf-tls-md5-sha1-deprecate] 1551 Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating 1552 MD5 and SHA-1 signature hashes in (D)TLS 1.2", Work in 1553 Progress, Internet-Draft, draft-ietf-tls-md5-sha1- 1554 deprecate-08, 3 September 2021, 1555 . 1558 [I-D.ietf-emu-eaptlscert] 1559 Sethi, M., Mattsson, J., and S. Turner, "Handling Large 1560 Certificates and Long Certificate Chains in TLS-based EAP 1561 Methods", Work in Progress, Internet-Draft, draft-ietf- 1562 emu-eaptlscert-08, 20 November 2020, 1563 . 1566 [I-D.ietf-tls-ticketrequests] 1567 Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket 1568 Requests", Work in Progress, Internet-Draft, draft-ietf- 1569 tls-ticketrequests-07, 3 December 2020, 1570 . 1573 [I-D.ietf-emu-tls-eap-types] 1574 DeKok, A., "TLS-based EAP types and TLS 1.3", Work in 1575 Progress, Internet-Draft, draft-ietf-emu-tls-eap-types-03, 1576 22 June 2021, . 1579 [I-D.ietf-tls-rfc8446bis] 1580 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1581 Version 1.3", Work in Progress, Internet-Draft, draft- 1582 ietf-tls-rfc8446bis-02, 23 August 2021, 1583 . 1586 Appendix A. Updated References 1588 All the following references in [RFC5216] are updated as specified 1589 below when EAP-TLS is used with TLS 1.3. 1591 All references to [RFC2560] are updated with [RFC6960]. 1593 All references to [RFC3280] are updated with [RFC5280]. 1595 All references to [RFC4282] are updated with [RFC7542]. 1597 Acknowledgments 1599 The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton, 1600 Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar, 1601 Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa 1602 Torvinen, Hannes Tschofenig, and Heikki Vatiainen for comments and 1603 suggestions on the draft. Special thanks to the document shepard 1604 Joseph Salowey. 1606 Contributors 1608 Alan DeKok, FreeRADIUS 1610 Authors' Addresses 1611 John Preuß Mattsson 1612 Ericsson 1613 SE-164 40 Stockholm 1614 Sweden 1616 Email: john.mattsson@ericsson.com 1618 Mohit Sethi 1619 Ericsson 1620 FI-02420 Jorvas 1621 Finland 1623 Email: mohit@piuha.net