idnits 2.17.1 draft-ietf-emu-eap-tls13-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (February 2, 2021) is 1173 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 864 -- Looks like a reference, but probably isn't: '2' on line 868 -- Looks like a reference, but probably isn't: '3' on line 875 -- Looks like a reference, but probably isn't: '4' on line 881 == Outdated reference: A later version (-09) exists of draft-ietf-tls-md5-sha1-deprecate-04 -- 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) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Mattsson 3 Internet-Draft M. Sethi 4 Updates: 5216 (if approved) Ericsson 5 Intended status: Standards Track February 2, 2021 6 Expires: August 6, 2021 8 Using EAP-TLS with TLS 1.3 9 draft-ietf-emu-eap-tls13-14 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 further 20 improves security and privacy by always providing forward secrecy, 21 never disclosing the peer identity, and by mandating use of 22 revocation checking. This document also provides guidance on 23 authorization and resumption for EAP-TLS in general (regardless of 24 the underlying TLS version used). This document updates RFC 5216. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 6, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements and Terminology . . . . . . . . . . . . . . 4 62 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4 64 2.1.1. Mutual Authentication . . . . . . . . . . . . . . . . 4 65 2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 6 66 2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 8 67 2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 18 75 2.4. Parameter Negotiation and Compliance Requirements . . . . 19 76 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 20 77 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 20 78 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 21 81 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 22 82 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 22 83 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 22 84 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 23 85 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 23 86 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 23 87 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 25 88 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 27 89 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 27 90 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 91 6.1. Normative References . . . . . . . . . . . . . . . . . . 27 92 6.2. Informative references . . . . . . . . . . . . . . . . . 29 93 Appendix A. Updated references . . . . . . . . . . . . . . . . . 32 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32 95 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 32 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 98 1. Introduction 100 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 101 provides a standard mechanism for support of multiple authentication 102 methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies 103 an EAP authentication method with certificate-based mutual 104 authentication utilizing the TLS handshake protocol for cryptographic 105 algorithms and protocol version negotiation, mutual authentication, 106 and establishment of shared secret keying material. EAP-TLS is 107 widely supported for authentication and key establishment in IEEE 108 802.11 [IEEE-802.11] (Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE] (MACsec) 109 networks using IEEE 802.1X [IEEE-802.1X] and it's the default 110 mechanism for certificate based authentication in 3GPP 5G [TS.33.501] 111 and MulteFire [MulteFire] networks. Many other EAP methods such as 112 EAP-FAST [RFC4851], EAP-TTLS [RFC5281], TEAP [RFC7170], and PEAP 113 [PEAP] depend on TLS and EAP-TLS. 115 EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346], 116 but can also work with TLS 1.2 [RFC5246]. TLS 1.0 and 1.1 are 117 formally deprecated and prohibited to negotiate and use 118 [I-D.ietf-tls-oldversions-deprecate]. Weaknesses found in TLS 1.2, 119 as well as new requirements for security, privacy, and reduced 120 latency has led to the specification of TLS 1.3 [RFC8446], which 121 obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is in large parts a complete 122 remodeling of the TLS handshake protocol including a different 123 message flow, different handshake messages, different key schedule, 124 different cipher suites, different resumption, different privacy 125 protection, and record padding. This means that significant parts of 126 the normative text in the previous EAP-TLS specification [RFC5216] 127 are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore, 128 aspects such as resumption, privacy handling, and key derivation need 129 to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). 131 This document defines how to use EAP-TLS with TLS 1.3 (or higher) and 132 does not change how EAP-TLS is used with older versions of TLS. It 133 does however provide additional guidance on authorization and 134 resumption for EAP-TLS in general (regardless of the underlying TLS 135 version used). While this document updates EAP-TLS [RFC5216], it 136 remains backwards compatible with it and existing implementations of 137 EAP-TLS. This document only describes differences compared to 138 [RFC5216]. All message flow are specific to TLS 1.3 and do not apply 139 to TLS 1.2. 141 In addition to the improved security and privacy offered by TLS 1.3, 142 there are other significant benefits of using EAP-TLS with TLS 1.3. 143 Privacy, which in EAP-TLS means that the peer username is not 144 disclosed, is mandatory and achieved without any additional round- 145 trips. Revocation checking is mandatory and simplified with OCSP 146 stapling, and TLS 1.3 introduces more possibilities to reduce 147 fragmentation when compared to earlier versions of TLS. 149 1.1. Requirements and Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 Readers are expected to be familiar with the terms and concepts used 158 in EAP-TLS [RFC5216] and TLS [RFC8446]. The term EAP-TLS peer is 159 used for the entity acting as EAP peer and TLS client. The term EAP- 160 TLS server is used for the entity acting as EAP server and TLS 161 server. 163 2. Protocol Overview 165 2.1. Overview of the EAP-TLS Conversation 167 This section updates Section 2.1 of [RFC5216]. 169 TLS 1.3 changes both the message flow and the handshake messages 170 compared to earlier versions of TLS. Therefore, much of Section 2.1 171 of [RFC5216] does not apply for TLS 1.3 (or higher). 173 After receiving an EAP-Request packet with EAP-Type=EAP-TLS as 174 described in [RFC5216] the conversation will continue with the TLS 175 handshake protocol encapsulated in the data fields of EAP-Response 176 and EAP-Request packets. When EAP-TLS is used with TLS version 1.3 177 or higher, the formatting and processing of the TLS handshake SHALL 178 be done as specified in that version of TLS. This document only 179 lists additional and different requirements, restrictions, and 180 processing compared to [RFC8446] and [RFC5216]. 182 2.1.1. Mutual Authentication 184 This section updates Section 2.1.1 of [RFC5216]. 186 The EAP-TLS server MUST authenticate with a certificate and SHOULD 187 require the EAP-TLS peer to authenticate with a certificate. 188 Certificates can be of any type supported by TLS including raw public 189 keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except 190 for resumption. The full handshake in EAP-TLS with TLS 1.3 always 191 provide forward secrecy by exchange of ephemeral "key_share" 192 extentions in the ClientHello and ServerHello (e.g. containing 193 ephemeral ECDHE public keys). SessionID is deprecated in TLS 1.3, 194 see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early 195 application data which like all other application data is not used in 196 EAP-TLS, see Section 4.2.10 of [RFC8446] for additional information 197 of the "early_data" extension. Resumption is handled as described in 198 Section 2.1.3. TLS 1.3 introduced the Post-Handshake KeyUpdate 199 message which is not useful and not expected in EAP-TLS. The EAP-TLS 200 server always commits to not send any more handshake messages by 201 sending a TLS close_notify alert. After the EAP-TLS server has 202 received an empty EAP-Response to the EAP-Request containing the TLS 203 close_notify alert, the EAP-TLS server sends EAP-Success. 205 In the case where EAP-TLS with mutual authentication is successful 206 (and neither HelloRetryRequest nor Post-Handshake messages are sent) 207 the conversation will appear as shown in Figure 1. 209 EAP-TLS Peer EAP-TLS Server 211 EAP-Request/ 212 <-------- Identity 213 EAP-Response/ 214 Identity (Privacy-Friendly) --------> 215 EAP-Request/ 216 EAP-Type=EAP-TLS 217 <-------- (TLS Start) 218 EAP-Response/ 219 EAP-Type=EAP-TLS 220 (TLS ClientHello) --------> 221 EAP-Request/ 222 EAP-Type=EAP-TLS 223 (TLS ServerHello, 224 TLS EncryptedExtensions, 225 TLS CertificateRequest, 226 TLS Certificate, 227 TLS CertificateVerify, 228 <-------- TLS Finished) 229 EAP-Response/ 230 EAP-Type=EAP-TLS 231 (TLS Certificate, 232 TLS CertificateVerify, 233 TLS Finished) --------> 234 EAP-Request/ 235 EAP-Type=EAP-TLS 236 <-------- (TLS close_notify) 237 EAP-Response/ 238 EAP-Type=EAP-TLS --------> 239 <-------- EAP-Success 241 Figure 1: EAP-TLS mutual authentication 243 2.1.2. Ticket Establishment 245 This is a new section when compared to [RFC5216]. 247 To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS 248 server MUST send one or more NewSessionTicket messages (each 249 containing a PSK, a PSK identity, a ticket lifetime, and other 250 parameters) in the initial authentication. Note that TLS 1.3 251 [RFC8446] limits the ticket lifetime to a maximum of 604800 seconds 252 (7 days) and EAP-TLS servers MUST respect this upper limit when 253 issuing tickets. The NewSessionTicket is sent after the EAP-TLS 254 server has received the client Finished message in the initial 255 authentication. The PSK associated with the ticket depends on the 256 client Finished and cannot be pre-computed in handshakes with client 257 authentication. The NewSessionTicket message MUST NOT include an 258 "early_data" extension. A mechanism by which clients can specify the 259 desired number of tickets needed for future connections is defined in 260 [I-D.ietf-tls-ticketrequests]. 262 In the case where EAP-TLS with mutual authentication and ticket 263 establishment with two tickets is successful, the conversation will 264 appear as shown in Figure 2. 266 EAP-TLS Peer EAP-TLS Server 268 EAP-Request/ 269 <-------- Identity 270 EAP-Response/ 271 Identity (Privacy-Friendly) --------> 272 EAP-Request/ 273 EAP-Type=EAP-TLS 274 <-------- (TLS Start) 275 EAP-Response/ 276 EAP-Type=EAP-TLS 277 (TLS ClientHello) --------> 278 EAP-Request/ 279 EAP-Type=EAP-TLS 280 (TLS ServerHello, 281 TLS EncryptedExtensions, 282 TLS CertificateRequest, 283 TLS Certificate, 284 TLS CertificateVerify, 285 <-------- TLS Finished) 286 EAP-Response/ 287 EAP-Type=EAP-TLS 288 (TLS Certificate, 289 TLS CertificateVerify, 290 TLS Finished) --------> 291 EAP-Request/ 292 EAP-Type=EAP-TLS 293 (TLS NewSessionTicket, 294 TLS NewSessionTicket, 295 <-------- TLS close_notify) 296 EAP-Response/ 297 EAP-Type=EAP-TLS --------> 298 <-------- EAP-Success 300 Figure 2: EAP-TLS ticket establishment 302 2.1.3. Resumption 304 This section updates Section 2.1.2 of [RFC5216]. 306 TLS 1.3 replaces the session resumption mechanisms in earlier 307 versions of TLS with a new PSK exchange. When EAP-TLS is used with 308 TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism 309 compatible with that version of TLS. 311 For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If 312 the client has received a NewSessionTicket message from the EAP-TLS 313 server, the client can use the PSK identity received in the ticket to 314 negotiate the use of the associated PSK. If the EAP-TLS server 315 accepts it, then the security context of the new connection is tied 316 to the original connection and the key derived from the initial 317 handshake is used to bootstrap the cryptographic state instead of a 318 full handshake. It is up to the EAP-TLS peer whether to offer 319 resumption, ut it is RECOMMENDED that the EAP-TLS peer offer 320 resumption if it has a valid ticket that has not been used before. 321 It is left to the EAP-TLS server whether to accept resumption, but it 322 is RECOMMENDED that the EAP-TLS server accept resumption if the 323 ticket that it issued is still valid. However, the EAP-TLS server 324 MAY choose to require a full handshake. As in a full handshake, 325 sending a NewSessionTicket is optional. As described in Appendix C.4 326 of [RFC8446], reuse of a ticket allows passive observers to correlate 327 different connections. EAP-TLS peers and EAP-TLS servers SHOULD 328 follow the client tracking preventions in Appendix C.4 of [RFC8446]. 330 It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the 331 same realm in the resumption and the original full handshake. This 332 requirement allows EAP packets to be routable to the same destination 333 as the original full handshake. If this recommendation is not 334 followed, resumption is likely to be impossible. When NAI reuse can 335 be done without privacy implications, it is RECOMMENDED to use the 336 same anonymous NAI in the resumption, as was used in the original 337 full handshake [RFC7542]. For example, the NAI @realm can safely be 338 reused since it does not provide any specific information to 339 associate a user's resumption attempt with the original full 340 handshake. However, reusing the NAI 341 P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path attacker to 342 associate a resumption attempt with the original full handshake. The 343 TLS PSK identity is typically derived by the TLS implementation and 344 may be an opaque blob without a routable realm. The TLS PSK identity 345 is therefore in general unsuitable for deriving a NAI to use in the 346 Identity Response. 348 A subsequent successful resumption handshake where both sides 349 authenticate via a PSK provisioned via an earlier NewSessionTicket 350 and where the server provisions a single new ticket is shown in 351 Figure 3. 353 EAP-TLS Peer EAP-TLS Server 355 EAP-Request/ 356 <-------- Identity 357 EAP-Response/ 358 Identity (Privacy-Friendly) --------> 359 EAP-Request/ 360 EAP-Type=EAP-TLS 361 <-------- (TLS Start) 362 EAP-Response/ 363 EAP-Type=EAP-TLS 364 (TLS ClientHello) --------> 365 EAP-Request/ 366 EAP-Type=EAP-TLS 367 (TLS ServerHello, 368 TLS EncryptedExtensions, 369 <-------- TLS Finished) 370 EAP-Response/ 371 EAP-Type=EAP-TLS 372 (TLS Finished) --------> 373 EAP-Request/ 374 EAP-Type=EAP-TLS 375 (TLS NewSessionTicket, 376 <-------- TLS close_notify) 377 EAP-Response/ 378 EAP-Type=EAP-TLS --------> 379 <-------- EAP-Success 381 Figure 3: EAP-TLS resumption 383 A subsequent successful resumption handshake where both sides 384 authenticate via a PSK provisioned via an earlier NewSessionTicket 385 and where the server does not provision any new tickets is shown in 386 Figure 4. 388 EAP-TLS Peer EAP-TLS Server 390 EAP-Request/ 391 <-------- Identity 392 EAP-Response/ 393 Identity (Privacy-Friendly) --------> 394 EAP-Request/ 395 EAP-Type=EAP-TLS 396 <-------- (TLS Start) 397 EAP-Response/ 398 EAP-Type=EAP-TLS 399 (TLS ClientHello) --------> 400 EAP-Request/ 401 EAP-Type=EAP-TLS 402 (TLS ServerHello, 403 TLS EncryptedExtensions, 404 <-------- TLS Finished) 405 EAP-Response/ 406 EAP-Type=EAP-TLS 407 (TLS Finished) --------> 408 EAP-Request/ 409 EAP-Type=EAP-TLS 410 <-------- (TLS close_notify) 411 EAP-Response/ 412 EAP-Type=EAP-TLS --------> 413 <-------- EAP-Success 415 Figure 4: EAP-TLS resumption 417 As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD 418 supply a "key_share" extension when attempting resumption, which 419 allows the EAP-TLS server to potentially decline resumption and fall 420 back to a full handshake. If the EAP-TLS peer did not supply a 421 "key_share" extension when attempting resumption, the EAP-TLS server 422 needs to send HelloRetryRequest to signal that additional information 423 is needed to complete the handshake, and the EAP-TLS peer needs to 424 send a second ClientHello containing that information. Providing a 425 "key_share" and using the "psk_dhe_ke" pre-shared key exchange mode 426 is also important in order to limit the impact of a key compromise. 427 When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning 428 that key leakage does not compromise any earlier connections. It is 429 RECOMMMENDED to use "psk_dhe_ke" for resumption. 431 2.1.4. Termination 433 This section updates Section 2.1.3 of [RFC5216]. 435 TLS 1.3 changes both the message flow and the handshake messages 436 compared to earlier versions of TLS. Therefore, some normative text 437 in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3 or higher. 438 The two paragraphs below replaces the corresponding paragraphs in 439 Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or 440 higher. The other paragraphs in Section 2.1.3 of [RFC5216] still 441 apply with the exception that SessionID is deprecated. 443 If the EAP-TLS peer authenticates successfully, the EAP-TLS server 444 MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing 445 TLS records conforming to the version of TLS used. The message 446 flow ends with the EAP-TLS server sending an EAP-Success message. 448 If the EAP-TLS server authenticates successfully, the EAP-TLS peer 449 MUST send an EAP-Response message with EAP-Type=EAP-TLS containing 450 TLS records conforming to the version of TLS used. 452 Figures 5, 6, and 7 illustrate message flows in several cases where 453 the EAP-TLS peer or EAP-TLS server sends a TLS fatal alert message. 454 In earlier versions of TLS, error alerts could be warnings or fatal. 455 In TLS 1.3, error alerts are always fatal and the only alerts sent at 456 warning level are "close_notify" and "user_cancelled", both of which 457 indicate that the connection is not going to continue normally, see 458 [RFC8446]. 460 In the case where the EAP-TLS server rejects the ClientHello with a 461 fatal error, the conversation will appear as shown in Figure 5. The 462 EAP-TLS server can also partly reject the ClientHello with a 463 HelloRetryRequest, see Section 2.1.6. 465 EAP-TLS Peer EAP-TLS Server 467 EAP-Request/ 468 <-------- Identity 469 EAP-Response/ 470 Identity (Privacy-Friendly) --------> 471 EAP-Request/ 472 EAP-Type=EAP-TLS 473 <-------- (TLS Start) 474 EAP-Response/ 475 EAP-Type=EAP-TLS 476 (TLS ClientHello) --------> 477 EAP-Request/ 478 EAP-Type=EAP-TLS 479 <-------- (TLS Fatal Alert) 480 EAP-Response/ 481 EAP-Type=EAP-TLS --------> 482 <-------- EAP-Failure 484 Figure 5: EAP-TLS server rejection of ClientHello 486 In the case where EAP-TLS server authentication is unsuccessful, the 487 conversation will appear as shown in Figure 6. 489 EAP-TLS Peer EAP-TLS Server 491 EAP-Request/ 492 <-------- Identity 493 EAP-Response/ 494 Identity (Privacy-Friendly) --------> 495 EAP-Request/ 496 EAP-Type=EAP-TLS 497 <-------- (TLS Start) 498 EAP-Response/ 499 EAP-Type=EAP-TLS 500 (TLS ClientHello) --------> 501 EAP-Request/ 502 EAP-Type=EAP-TLS 503 (TLS ServerHello, 504 TLS EncryptedExtensions, 505 TLS CertificateRequest, 506 TLS Certificate, 507 TLS CertificateVerify, 508 <-------- TLS Finished) 509 EAP-Response/ 510 EAP-Type=EAP-TLS 511 (TLS Fatal Alert) 512 --------> 513 <-------- EAP-Failure 515 Figure 6: EAP-TLS unsuccessful EAP-TLS server authentication 517 In the case where the EAP-TLS server authenticates to the EAP-TLS 518 peer successfully, but the EAP-TLS peer fails to authenticate to the 519 EAP-TLS server, the conversation will appear as shown in Figure 7. 521 EAP-TLS Peer EAP-TLS Server 523 EAP-Request/ 524 <-------- Identity 525 EAP-Response/ 526 Identity (Privacy-Friendly) --------> 528 EAP-Request/ 529 EAP-Type=EAP-TLS 530 <-------- (TLS Start) 531 EAP-Response/ 532 EAP-Type=EAP-TLS 533 (TLS ClientHello) --------> 534 EAP-Request/ 535 EAP-Type=EAP-TLS 536 (TLS ServerHello, 537 TLS EncryptedExtensions, 538 TLS CertificateRequest, 539 TLS Certificate, 540 TLS CertificateVerify, 541 <-------- TLS Finished) 542 EAP-Response/ 543 EAP-Type=EAP-TLS 544 (TLS Certificate, 545 TLS CertificateVerify, 546 TLS Finished) --------> 547 EAP-Request/ 548 EAP-Type=EAP-TLS 549 <-------- (TLS Fatal Alert) 550 EAP-Response/ 551 EAP-Type=EAP-TLS --------> 552 <-------- EAP-Failure 554 Figure 7: EAP-TLS unsuccessful client authentication 556 2.1.5. No Peer Authentication 558 This is a new section when compared to [RFC5216]. 560 In the case where EAP-TLS is used without peer authentication (e.g., 561 emergency services, as described in [RFC7406]) the conversation will 562 appear as shown in Figure 8. 564 EAP-TLS Peer EAP-TLS Server 566 EAP-Request/ 567 <-------- Identity 568 EAP-Response/ 569 Identity (Privacy-Friendly) --------> 570 EAP-Request/ 571 EAP-Type=EAP-TLS 572 <-------- (TLS Start) 573 EAP-Response/ 574 EAP-Type=EAP-TLS 575 (TLS ClientHello) --------> 576 EAP-Request/ 577 EAP-Type=EAP-TLS 578 (TLS ServerHello, 579 TLS EncryptedExtensions, 580 TLS Certificate, 581 TLS CertificateVerify, 582 <-------- TLS Finished) 583 EAP-Response/ 584 EAP-Type=EAP-TLS 585 (TLS Finished) --------> 586 EAP-Request/ 587 EAP-Type=EAP-TLS 588 <-------- (TLS close_notify) 589 EAP-Response/ 590 EAP-Type=EAP-TLS --------> 591 <-------- EAP-Success 593 Figure 8: EAP-TLS without peer authentication 595 2.1.6. Hello Retry Request 597 This is a new section when compared to [RFC5216]. 599 As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a 600 HelloRetryRequest message in response to a ClientHello if the EAP-TLS 601 server finds an acceptable set of parameters but the initial 602 ClientHello does not contain all the needed information to continue 603 the handshake. One use case is if the EAP-TLS server does not 604 support the groups in the "key_share" extension (or there is no 605 "key_share" extension), but supports one of the groups in the 606 "supported_groups" extension. In this case the client should send a 607 new ClientHello with a "key_share" that the EAP-TLS server supports. 609 The case of a successful EAP-TLS mutual authentication after the EAP- 610 TLS server has sent a HelloRetryRequest message is shown in Figure 9. 611 Note the extra round-trip as a result of the HelloRetryRequest. 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 HelloRetryRequest) 628 <-------- 629 EAP-Response/ 630 EAP-Type=EAP-TLS 631 (TLS ClientHello) --------> 632 EAP-Request/ 633 EAP-Type=EAP-TLS 634 (TLS ServerHello, 635 TLS EncryptedExtensions, 636 TLS CertificateRequest, 637 TLS Certificate, 638 TLS CertificateVerify, 639 TLS Finished) 640 EAP-Response/ 641 EAP-Type=EAP-TLS 642 (TLS Certificate, 643 TLS CertificateVerify, 644 TLS Finished) --------> 645 EAP-Request/ 646 EAP-Type=EAP-TLS 647 <-------- (TLS close_notify) 648 EAP-Response/ 649 EAP-Type=EAP-TLS --------> 650 <-------- EAP-Success 652 Figure 9: EAP-TLS with Hello Retry Request 654 2.1.7. Identity 656 This is a new section when compared to [RFC5216]. 658 It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity 659 Response as such identities are routable and privacy-friendly. While 660 opaque blobs are allowed by [RFC3748], such identities are NOT 661 RECOMMENDED as they are not routable and should only be considered in 662 local deployments where the EAP-TLS peer, EAP authenticator, and EAP- 663 TLS server all belong to the same network. Many client certificates 664 contain an identity such as an email address, which is already in NAI 665 format. When the client certificate contains a NAI as subject name 666 or alternative subject name, an anonymous NAI SHOULD be derived from 667 the NAI in the certificate, see Section 2.1.8. More details on 668 identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8. 670 2.1.8. Privacy 672 This section updates Section 2.1.4 of [RFC5216]. 674 TLS 1.3 significantly improves privacy when compared to earlier 675 versions of TLS by forbidding cipher suites without confidentiality 676 and encrypting large parts of the TLS handshake including the 677 certificate messages. 679 EAP-TLS peer and server implementations supporting TLS 1.3 or higher 680 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 681 in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its 682 username in cleartext in the Identity Response. Following [RFC7542], 683 it is RECOMMENDED to omit the username (i.e., the NAI is @realm), but 684 other constructions such as a fixed username (e.g. anonymous@realm) 685 or an encrypted username (e.g., 686 xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. 687 Note that the NAI MUST be a UTF-8 string as defined by the grammar in 688 Section 2.2 of [RFC7542]. 690 As the certificate messages in TLS 1.3 are encrypted, there is no 691 need to send an empty certificate_list and perform a second handshake 692 for privacy (as needed by EAP-TLS with earlier versions of TLS). 693 When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer 694 and EAP-TLS server SHALL follow the processing specified by the used 695 version of TLS. For TLS 1.3 this means that the EAP-TLS peer only 696 sends an empty certificate_list if it does not have an appropriate 697 certificate to send, and the EAP-TLS server MAY treat an empty 698 certificate_list as a terminal condition. 700 EAP-TLS with TLS 1.3 is always used with privacy. This does not add 701 any extra round-trips and the message flow with privacy is just the 702 normal message flow as shown in Figure 1. 704 2.1.9. Fragmentation 706 This section updates Section 2.1.5 of [RFC5216]. 708 Including ContentType (1 byte), ProtocolVersion (2 bytes), and length 709 (2 bytes) headers a single TLS record may be up to 16645 octets in 710 length. EAP-TLS fragmentation support is provided through addition 711 of a flags octet within the EAP-Response and EAP-Request packets, as 712 well as a TLS Message Length field of four octets. Implementations 713 MUST NOT set the L bit in unfragmented messages, but MUST accept 714 unfragmented messages with and without the L bit set. 716 Some EAP implementations and access networks may limit the number of 717 EAP packet exchanges that can be handled. To avoid fragmentation, it 718 is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and 719 trust anchor certificates small and the length of the certificate 720 chains short. In addition, it is RECOMMENDED to use mechanisms that 721 reduce the sizes of Certificate messages. For a detailed discussion 722 on reducing message sizes to prevent fragmentation, see 723 [I-D.ietf-emu-eaptlscert]. 725 2.2. Identity Verification 727 This section updates Section 2.2 of [RFC5216]. 729 The identity provided in the EAP-Response/Identity is not 730 authenticated by EAP-TLS. Unauthenticated information SHALL NOT be 731 used for accounting purposes or to give authorization. The 732 authenticator and the EAP-TLS server MAY examine the identity 733 presented in EAP-Response/Identity for purposes such as routing and 734 EAP method selection. EAP-TLS servers MAY reject conversations if 735 the identity does not match their policy. Note that this also 736 applies to resumption, see Sections 2.1.3, 5.6, and 5.7. 738 2.3. Key Hierarchy 740 This section updates Section 2.3 of [RFC5216]. 742 TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier 743 versions of TLS with HKDF and completely changes the Key Schedule. 744 The key hierarchies shown in Section 2.3 of [RFC5216] are therefore 745 not correct when EAP-TLS is used with TLS version 1.3 or higher. For 746 TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446]. 748 When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, 749 IV, and Method-Id SHALL be derived from the exporter_master_secret 750 using the TLS exporter interface [RFC5705] (for TLS 1.3 this is 751 defined in Section 7.5 of [RFC8446]). 753 Type-Code = 0x0D 754 MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK_"+Type-Code, 755 "",64) 756 EMSK = TLS-Exporter("EXPORTER_EAP_TLS_EMSK_"+Type-Code, 757 "",64) 758 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id_"+Type-Code, 759 "",64) 760 Session-Id = Type-Code || Method-Id 762 A zero-length context (indicated by "") is used in the TLS exporter 763 interface. The EAP-TLS Type-Code of '0D' (in hexadecimal) is 764 appended to the label strings. Other TLS based EAP methods can use 765 exporters in a similar fashion by replacing the EAP-TLS Type-Code 766 with their own Type-Code (encoded as a hexadecimal string). 768 [RFC5247] deprecates the use of IV. Thus, RECV-IV and SEND-IV are 769 not exported in EAP-TLS with TLS 1.3. As noted in [RFC5247], lower 770 layers use the MSK in a lower-layer dependent manner. EAP-TLS with 771 TLS 1.3 exports the MSK and does not specify how it used by lower 772 layers. 774 Note that the key derivation MUST use the length values given above. 775 While in TLS 1.2 and earlier it was possible to truncate the output 776 by requesting less data from the TLS-Exporter function, this practice 777 is not possible with TLS 1.3. If an implementation intends to use 778 only a part of the output of the TLS-Exporter function, then it MUST 779 ask for the full output and then only use the desired part. Failure 780 to do so will result in incorrect values being calculated for the 781 above keying material. 783 By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation 784 without having to extract the Master Secret, ClientHello.random, and 785 ServerHello.random in a non-standard way. 787 2.4. Parameter Negotiation and Compliance Requirements 789 This section updates Section 2.4 of [RFC5216]. 791 TLS 1.3 cipher suites are defined differently than in earlier 792 versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites 793 discussed in Section 2.4 of [RFC5216] can therefore not be used when 794 EAP-TLS is used with TLS version 1.3 or higher. 796 When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS 797 peers and EAP-TLS servers MUST comply with the compliance 798 requirements (mandatory-to-implement cipher suites, signature 799 algorithms, key exchange algorithms, extensions, etc.) for the TLS 800 version used. For TLS 1.3 the compliance requirements are defined in 801 Section 9 of [RFC8446]. In EAP-TLS with TLS 1.3, only cipher suites 802 with confidentiality SHALL be supported. 804 While EAP-TLS does not protect any application data except for the 805 Commitment Message, the negotiated cipher suites and algorithms MAY 806 be used to secure data as done in other TLS-based EAP methods. 808 2.5. EAP State Machines 810 This is a new section when compared to [RFC5216]. 812 TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- 813 Handshake messages use the handshake content type and can be sent 814 after the main handshake. One such Post-Handshake message is 815 NewSessionTicket. The NewSessionTicket can be used for resumption. 816 After sending TLS Finished, the EAP-TLS server may send any number of 817 Post-Handshake messages in separate EAP-Requests. To decrease the 818 uncertainty for the EAP-TLS peer, the following procedure MUST be 819 followed: 821 When an EAP-TLS server has sent its last handshake message (Finished 822 or a Post-Handshake), it commits to not sending any more handshake 823 messages by sending a TLS close_notify alert. After sending the 824 alert, the EAP-TLS server may only send an EAP-Success or an EAP- 825 Failure. Using the TLS close_notify however results in an extra EAP- 826 Request and EAP-Response exchange between the peer and the server. 828 3. Detailed Description of the EAP-TLS Protocol 830 No updates to Section 3 of [RFC5216]. 832 4. IANA considerations 834 This section provides guidance to the Internet Assigned Numbers 835 Authority (IANA) regarding registration of values related to the EAP- 836 TLS 1.3 protocol in accordance with [RFC8126]. 838 This memo requires IANA to add the following labels to the TLS 839 Exporter Label Registry defined by [RFC5705]. These labels are used 840 in derivation of Key_Material, IV and Method-Id as defined in 841 Section 2.3: 843 +-----------------------------+---------+-------------+------+ 844 | Value | DTLS-OK | Recommended | Note | 845 +-----------------------------+---------+-------------+------+ 846 | EXPORTER_EAP_TLS_MSK_ | N | Y | | 847 | | | | | 848 | EXPORTER_EAP_TLS_EMSK_ | N | Y | | 849 | | | | | 850 | EXPORTER_EAP_TLS_Method-Id_ | N | Y | | 851 +-----------------------------+---------+-------------+------+ 853 Table 1: TLS Exporter Label Registry 855 5. Security Considerations 857 5.1. Security Claims 859 Using EAP-TLS with TLS 1.3 does not change the security claims for 860 EAP-TLS as given in Section 5.1 of [RFC5216]. However, it 861 strengthens several of the claims as described in the following 862 updates to the notes given in Section 5.1 of [RFC5216]. 864 [1] Mutual authentication: By mandating revocation checking of 865 certificates, the authentication in EAP-TLS with TLS 1.3 is stronger 866 as authentication with revoked certificates will always fail. 868 [2] Confidentiality: The TLS 1.3 handshake offers much better 869 confidentiality than earlier versions of TLS. EAP-TLS with TLS 1.3 870 mandates use of cipher suites that ensure confidentiality. TLS 1.3 871 also encrypts certificates and some of the extensions. When using 872 EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not 873 cause any additional round-trips. 875 [3] Cryptographic strength: TLS 1.3 only define strong algorithms 876 without major weaknesses and EAP-TLS with TLS 1.3 always provide 877 forward secrecy, see [RFC8446]. Weak algorithms such as 3DES, CBC 878 mode, RC4, SHA-1, MD5, P-192, and RSA-1024 can therefore not be 879 negotiated. 881 [4] Cryptographic Negotiation: TLS 1.3 increases the number of 882 cryptographic parameters that are negotiated in the handshake. When 883 EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic 884 negotiation of AEAD algorithm, HKDF hash algorithm, key exchange 885 groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. 887 5.2. Peer and Server Identities 889 No updates to section 5.2 of [RFC5216]. 891 5.3. Certificate Validation 893 No updates to section 5.3 of [RFC5216]. 895 5.4. Certificate Revocation 897 This section updates Section 5.4 of [RFC5216]. 899 While certificates may have long validity periods, there are a number 900 of reasons (e.g., key compromise, CA compromise, privilege withdrawn, 901 etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have 902 to be revoked before their expiry date. Revocation of the EAP-TLS 903 server's certificate is complicated by the fact that the EAP-TLS peer 904 may not have Internet connectivity until authentication completes. 906 When EAP-TLS is used with TLS 1.3, the revocation status of all the 907 certificates in the certificate chains MUST be checked (except the 908 trust anchor). An implementation may use Certificate Revocation List 909 (CRL) Online Certificate Status Protocol (OSCP) or other standardized 910 or proprietary methods for revocation checking. Examples of 911 proprietary methods are non-standard formats and distribution of 912 revocation lists as well as certificates with very short lifetime. 914 EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status 915 Requests (OCSP stapling) as specified in [RFC6066] and 916 Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers 917 and EAP-TLS servers use OCSP stapling for verifying the status of the 918 EAP-TLS server's certificate chain. When an EAP-TLS peer uses 919 Certificate Status Requests to check the revocation status of the 920 EAP-TLS server's certificate chain it MUST treat a CertificateEntry 921 (except the trust anchor) without a valid CertificateStatus extension 922 as invalid and abort the handshake with an appropriate alert. The 923 OCSP status handling in TLS 1.3 is different from earlier versions of 924 TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP 925 information is carried in the CertificateEntry containing the 926 associated certificate instead of a separate CertificateStatus 927 message as in [RFC6066]. This enables sending OCSP information for 928 all certificates in the certificate chain (except the trust anchor). 930 To enable revocation checking in situations where EAP-TLS peers do 931 not implement or use OCSP stapling, and where network connectivity is 932 not available prior to authentication completion, EAP-TLS peer 933 implementations MUST also support checking for certificate revocation 934 after authentication completes and network connectivity is available. 936 An implementation MAY enforce limited authorization before revocation 937 checking has been done. 939 5.5. Packet Modification Attacks 941 No updates to Section 5.5 of [RFC5216]. 943 5.6. Authorization 945 This is a new section when compared to [RFC5216]. The guidance in 946 this section is relevant for EAP-TLS in general (regardless of the 947 underlying TLS version used). 949 EAP-TLS is typically encapsulated in other protocols, such as PPP 950 [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. 951 The encapsulating protocols can also provide additional, non-EAP 952 information to an EAP-TLS server. This information can include, but 953 is not limited to, information about the authenticator, information 954 about the EAP-TLS peer, or information about the protocol layers 955 above or below EAP (MAC addresses, IP addresses, port numbers, WiFi 956 SSID, etc.). EAP-TLS Servers implementing EAP-TLS inside those 957 protocols can make policy decisions and enforce authorization based 958 on a combination of information from the EAP-TLS exchange and non-EAP 959 information. 961 As noted in Section 2.2, the identity presented in EAP-Response/ 962 Identity is not authenticated by EAP-TLS and is therefore trivial for 963 an attacker to forge, modify, or replay. Authorization and 964 accounting MUST be based on authenticated information such as 965 information in the certificate or the PSK identity and cached data 966 provisioned for resumption as described in Section 5.7. Note that 967 the requirements for Network Access Identifiers (NAIs) specified in 968 Section 4 of [RFC7542] still apply and MUST be followed. 970 EAP-TLS servers MAY reject conversations based on non-EAP information 971 provided by the encapsulating protocol, for example, if the MAC 972 address of the authenticator does not match the expected policy. 974 5.7. Resumption 976 This is a new section when compared to [RFC5216]. The guidance in 977 this section is relevant for EAP-TLS in general (regardless of the 978 underlying TLS version used). 980 There are a number of security issues related to resumption that are 981 not described in [RFC5216]. The problems, guidelines, and 982 requirements in this section therefore applies to all version of TLS. 984 When resumption occurs, it is based on cached information at the TLS 985 layer. To perform resumption in a secure way, the EAP-TLS peer and 986 EAP-TLS server need to be able to securely retrieve authorization 987 information such as certificate chains from the initial full 988 handshake. We use the term "cached data" to describe such 989 information. Authorization during resumption MUST be based on such 990 cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh 991 revocation checks on the cached certificate data. Any security 992 policies for authorization MUST be followed also for resumption. The 993 certificates may have been revoked since the initial full handshake 994 and the authorizations of the other party may have been reduced. If 995 the cached revocation data is not sufficiently current, the EAP-TLS 996 peer or EAP-TLS server MAY force a full TLS handshake. 998 There are two ways to retrieve the cached data from the original full 999 handshake. The first method is that the EAP-TLS server and client 1000 cache the information locally. The cached information is identified 1001 by an identifier. For TLS versions before 1.3, the identifier can be 1002 the session ID, for TLS 1.3, the identifier is the PSK identity. The 1003 second method for retrieving cached information is via [RFC5077] or 1004 [RFC8446], where the EAP-TLS server avoids storing information 1005 locally and instead encapsulates the information into a ticket or PSK 1006 which is sent to the client for storage. This ticket or PSK is 1007 encrypted using a key that only the EAP-TLS server knows. Note that 1008 the client still needs to cache the original handshake information 1009 locally and will use the session ID or PSK identity to lookup this 1010 information during resumption. However, the EAP-TLS server is able 1011 to decrypt the ticket or PSK to obtain the original handshake 1012 information. 1014 If the EAP-TLS server or EAP client do not apply any authorization 1015 policies, they MAY allow resumption where no cached data is 1016 available. In all other cases, they MUST cache data during the 1017 initial full handshake to enable resumption. The cached data MUST be 1018 sufficient to make authorization decisions during resumption. If 1019 cached data cannot be retrieved in a secure way, resumption MUST NOT 1020 be done. 1022 The above requirements also apply if the EAP-TLS server expects some 1023 system to perform accounting for the session. Since accounting must 1024 be tied to an authenticated identity, and resumption does not supply 1025 such an identity, accounting is impossible without access to cached 1026 data. Therefore systems which expect to perform accounting for the 1027 session SHOULD cache an identifier which can be used in subsequent 1028 accounting. 1030 As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption 1031 PSKs or tickets (and associated cached data) for longer than 7 days, 1032 regardless of the PSK or ticket lifetime. The EAP-TLS peer MAY 1033 delete them earlier based on local policy. The cached data MAY also 1034 be removed on the EAP-TLS server or EAP-TLS peer if any certificate 1035 in the certificate chain has been revoked or has expired. In all 1036 such cases, an attempt at resumption results in a full TLS handshake 1037 instead. 1039 Information from the EAP-TLS exchange (e.g., the identity provided in 1040 EAP-Response/Identity) as well as non-EAP information (e.g., IP 1041 addresses) may change between the initial full handshake and 1042 resumption. This change creates a "time-of-check time-of-use" 1043 (TOCTOU) security vulnerability. A malicious or compromised user 1044 could supply one set of data during the initial authentication, and a 1045 different set of data during resumption, potentially allowing them to 1046 obtain access that they should not have. 1048 If any authorization, accounting, or policy decisions were made with 1049 information that has changed between the initial full handshake and 1050 resumption, and if change may lead to a different decision, such 1051 decisions MUST be reevaluated. It is RECOMMENDED that authorization, 1052 accounting, and policy decisions are reevaluated based on the 1053 information given in the resumption. EAP-TLS servers MAY reject 1054 resumption where the information supplied during resumption does not 1055 match the information supplied during the original authentication. 1056 If a safe decision is not possible, EAP-TLS servers SHOULD reject the 1057 resumption and continue with a full handshake. 1059 Section 2.2 and 4.2.11,[RFC8446] provides security considerations for 1060 resumption. 1062 5.8. Privacy Considerations 1064 This is a new section when compared to [RFC5216]. 1066 TLS 1.3 offers much better privacy than earlier versions of TLS as 1067 discussed in Section 2.1.8. In this section, we only discuss the 1068 privacy properties of EAP-TLS with TLS 1.3. For privacy properties 1069 of TLS 1.3 itself, see [RFC8446]. 1071 EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in 1072 EAP packets. Additionally, the EAP-TLS peer sends an identity in the 1073 first EAP-Response. The other fields in the EAP-TLS Request and the 1074 EAP-TLS Response packets do not contain any cleartext privacy 1075 sensitive information. 1077 Tracking of users by eavesdropping on identity responses or 1078 certificates is a well-known problem in many EAP methods. When EAP- 1079 TLS is used with TLS 1.3, all certificates are encrypted, and the 1080 username part of the identity response is always confidentiality 1081 protected (e.g., using anonymous NAIs). Note that even though all 1082 certificates are encrypted, the server's identity is only protected 1083 against passive attackers while client's identity is protected 1084 against both passive and active attackers. As with other EAP 1085 methods, even when privacy-friendly identifiers or EAP tunneling is 1086 used, the domain name (i.e., the realm) in the NAI is still typically 1087 visible. How much privacy sensitive information the domain name 1088 leaks is highly dependent on how many other users are using the same 1089 domain name in the particular access network. If all EAP-TLS peers 1090 have the same domain, no additional information is leaked. If a 1091 domain name is used by a small subset of the EAP-TLS peers, it may 1092 aid an attacker in tracking or identifying the user. 1094 Without padding, information about the size of the client certificate 1095 is leaked from the size of the EAP-TLS packets. The EAP-TLS packets 1096 sizes may therefore leak information that can be used to track or 1097 identify the user. If all client certificates have the same length, 1098 no information is leaked. EAP-TLS peers SHOULD use record padding, 1099 see Section 5.4 of [RFC8446] to reduce information leakage of 1100 certificate sizes. 1102 If anonymous NAIs are not used, the privacy-friendly identifiers need 1103 to be generated with care. The identities MUST be generated in a 1104 cryptographically secure way so that that it is computationally 1105 infeasible for an attacker to differentiate two identities belonging 1106 to the same user from two identities belonging to different users in 1107 the same realm. This can be achieved, for instance, by using random 1108 or pseudo-random usernames such as random byte strings or ciphertexts 1109 and only using the pseudo-random usernames a single time. Note that 1110 the privacy-friendly usernames also MUST NOT include substrings that 1111 can be used to relate the identity to a specific user. Similarly, 1112 privacy-friendly username MUST NOT be formed by a fixed mapping that 1113 stays the same across multiple different authentications. 1115 An EAP-TLS peer with a policy allowing communication with EAP-TLS 1116 servers supporting only TLS 1.2 without privacy and with a static RSA 1117 key exchange is vulnerable to disclosure of the EAP-TLS peer 1118 username. An active attacker can in this case make the EAP-TLS peer 1119 believe that an EAP-TLS server supporting TLS 1.3 only supports TLS 1120 1.2 without privacy. The attacker can simply impersonate the EAP-TLS 1121 server and negotiate TLS 1.2 with static RSA key exchange and send an 1122 TLS alert message when the EAP-TLS peer tries to use privacy by 1123 sending an empty certificate message. Since the attacker 1124 (impersonating the EAP-TLS server) does not provide a proof-of- 1125 possession of the private key until the Finished message when a 1126 static RSA key exchange is used, an EAP-TLS peer may inadvertently 1127 disclose its identity (username) to an attacker. Therefore, it is 1128 RECOMMENDED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and 1129 static RSA based cipher suites without privacy. This implies that an 1130 EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS 1131 server sends an EAP-TLS/Request with a TLS alert message in response 1132 to an empty certificate message from the peer. 1134 5.9. Pervasive Monitoring 1136 This is a new section when compared to [RFC5216]. 1138 Pervasive monitoring refers to widespread surveillance of users. In 1139 the context of EAP-TLS, pervasive monitoring attacks can target EAP- 1140 TLS peer devices for tracking them (and their users) as and when they 1141 join a network. By encrypting more information, mandating the use of 1142 privacy, and always providing forward secrecy, EAP-TLS with TLS 1.3 1143 offers much better protection against pervasive monitoring. In 1144 addition to the privacy attacks discussed above, surveillance on a 1145 large scale may enable tracking of a user over a wider geographical 1146 area and across different access networks. Using information from 1147 EAP-TLS together with information gathered from other protocols 1148 increases the risk of identifying individual users. 1150 5.10. Discovered Vulnerabilities 1152 This is a new section when compared to [RFC5216]. 1154 Over the years, there have been several serious attacks on earlier 1155 versions of Transport Layer Security (TLS), including attacks on its 1156 most commonly used ciphers and modes of operation. [RFC7457] 1157 summarizes the attacks that were known at the time of publishing and 1158 BCP 195 [RFC7525] provides recommendations for improving the security 1159 of deployed services that use TLS. However, many of the attacks are 1160 less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and 1161 does not protect any application data. EAP-TLS implementations MUST 1162 mitigate known attacks. EAP-TLS implementations need to monitor and 1163 follow new EAP and TLS related security guidance and requirements 1164 such as [RFC8447], [I-D.ietf-tls-oldversions-deprecate], 1165 [I-D.ietf-tls-md5-sha1-deprecate]. 1167 6. References 1169 6.1. Normative References 1171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1172 Requirement Levels", BCP 14, RFC 2119, 1173 DOI 10.17487/RFC2119, March 1997, 1174 . 1176 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1177 Levkowetz, Ed., "Extensible Authentication Protocol 1178 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1179 . 1181 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1182 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 1183 March 2008, . 1185 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1186 Housley, R., and W. Polk, "Internet X.509 Public Key 1187 Infrastructure Certificate and Certificate Revocation List 1188 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1189 . 1191 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1192 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1193 March 2010, . 1195 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1196 Extensions: Extension Definitions", RFC 6066, 1197 DOI 10.17487/RFC6066, January 2011, 1198 . 1200 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1201 Galperin, S., and C. Adams, "X.509 Internet Public Key 1202 Infrastructure Online Certificate Status Protocol - OCSP", 1203 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1204 . 1206 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1207 DOI 10.17487/RFC7542, May 2015, 1208 . 1210 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1211 Writing an IANA Considerations Section in RFCs", BCP 26, 1212 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1213 . 1215 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1216 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1217 May 2017, . 1219 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1220 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1221 . 1223 6.2. Informative references 1225 [I-D.ietf-emu-eaptlscert] 1226 Sethi, M., Mattsson, J., and S. Turner, "Handling Large 1227 Certificates and Long Certificate Chains in TLS-based EAP 1228 Methods", draft-ietf-emu-eaptlscert-08 (work in progress), 1229 November 2020. 1231 [I-D.ietf-tls-md5-sha1-deprecate] 1232 Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating 1233 MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf- 1234 tls-md5-sha1-deprecate-04 (work in progress), October 1235 2020. 1237 [I-D.ietf-tls-oldversions-deprecate] 1238 Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and 1239 TLSv1.1", draft-ietf-tls-oldversions-deprecate-12 (work in 1240 progress), January 2021. 1242 [I-D.ietf-tls-ticketrequests] 1243 Pauly, T., Schinazi, D., and C. Wood, "TLS Ticket 1244 Requests", draft-ietf-tls-ticketrequests-07 (work in 1245 progress), December 2020. 1247 [IEEE-802.11] 1248 Institute of Electrical and Electronics Engineers, "IEEE 1249 Standard for Information technology--Telecommunications 1250 and information exchange between systems Local and 1251 metropolitan area networks--Specific requirements - Part 1252 11: Wireless LAN Medium Access Control (MAC) and Physical 1253 Layer (PHY) Specifications", IEEE Std 802.11-2016 1254 (Revision of IEEE Std 802.11-2012) , December 2016. 1256 [IEEE-802.1AE] 1257 Institute of Electrical and Electronics Engineers, "IEEE 1258 Standard for Local and metropolitan area networks -- Media 1259 Access Control (MAC) Security", IEEE Standard 1260 802.1AE-2018 , December 2018. 1262 [IEEE-802.1X] 1263 Institute of Electrical and Electronics Engineers, "IEEE 1264 Standard for Local and metropolitan area networks -- Port- 1265 Based Network Access Control", IEEE Standard 802.1X-2020 , 1266 January 2020. 1268 [MulteFire] 1269 MulteFire, "MulteFire Release 1.1 specification", 2019. 1271 [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible 1272 Authentication Protocol (PEAP)", 2018. 1274 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 1275 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 1276 . 1278 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1279 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1280 . 1282 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1283 Adams, "X.509 Internet Public Key Infrastructure Online 1284 Certificate Status Protocol - OCSP", RFC 2560, 1285 DOI 10.17487/RFC2560, June 1999, 1286 . 1288 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1289 "Remote Authentication Dial In User Service (RADIUS)", 1290 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1291 . 1293 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1294 X.509 Public Key Infrastructure Certificate and 1295 Certificate Revocation List (CRL) Profile", RFC 3280, 1296 DOI 10.17487/RFC3280, April 2002, 1297 . 1299 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1300 Network Access Identifier", RFC 4282, 1301 DOI 10.17487/RFC4282, December 2005, 1302 . 1304 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1305 (TLS) Protocol Version 1.1", RFC 4346, 1306 DOI 10.17487/RFC4346, April 2006, 1307 . 1309 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 1310 Flexible Authentication via Secure Tunneling Extensible 1311 Authentication Protocol Method (EAP-FAST)", RFC 4851, 1312 DOI 10.17487/RFC4851, May 2007, 1313 . 1315 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1316 "Transport Layer Security (TLS) Session Resumption without 1317 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1318 January 2008, . 1320 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1321 and A. Yegin, "Protocol for Carrying Authentication for 1322 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1323 May 2008, . 1325 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1326 (TLS) Protocol Version 1.2", RFC 5246, 1327 DOI 10.17487/RFC5246, August 2008, 1328 . 1330 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1331 Authentication Protocol (EAP) Key Management Framework", 1332 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1333 . 1335 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 1336 Protocol Tunneled Transport Layer Security Authenticated 1337 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 1338 DOI 10.17487/RFC5281, August 2008, 1339 . 1341 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1342 Ed., "Diameter Base Protocol", RFC 6733, 1343 DOI 10.17487/RFC6733, October 2012, 1344 . 1346 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1347 "Tunnel Extensible Authentication Protocol (TEAP) Version 1348 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1349 . 1351 [RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., 1352 and D. Kroeselberg, "Extensions to the Emergency Services 1353 Architecture for Dealing With Unauthenticated and 1354 Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, 1355 December 2014, . 1357 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1358 Known Attacks on Transport Layer Security (TLS) and 1359 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1360 February 2015, . 1362 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1363 "Recommendations for Secure Use of Transport Layer 1364 Security (TLS) and Datagram Transport Layer Security 1365 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1366 2015, . 1368 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1369 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1370 . 1372 [TS.33.501] 1373 3GPP, "Security architecture and procedures for 5G 1374 System", 3GPP TS 33.501 17.0.0, December 2020. 1376 Appendix A. Updated references 1378 All the following references in [RFC5216] are updated as specified 1379 below when EAP-TLS is used with TLS 1.3 or higher. 1381 All references to [RFC2560] are updated with [RFC6960]. 1383 All references to [RFC3280] are updated with [RFC5280]. 1385 All references to [RFC4282] are updated with [RFC7542]. 1387 Acknowledgments 1389 The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton, 1390 Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar, 1391 Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa 1392 Torvinen, and Hannes Tschofenig for comments and suggestions on the 1393 draft. 1395 Contributors 1397 Alan DeKok, FreeRADIUS 1399 Authors' Addresses 1401 John Preuss Mattsson 1402 Ericsson 1403 Stockholm 164 40 1404 Sweden 1406 Email: john.mattsson@ericsson.com 1408 Mohit Sethi 1409 Ericsson 1410 Jorvas 02420 1411 Finland 1413 Email: mohit@piuha.net