idnits 2.17.1 draft-ietf-emu-eap-tls13-10.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 (June 7, 2020) is 1411 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 852 -- Looks like a reference, but probably isn't: '2' on line 856 -- Looks like a reference, but probably isn't: '3' on line 863 -- Looks like a reference, but probably isn't: '4' on line 868 == Outdated reference: A later version (-08) exists of draft-ietf-emu-eaptlscert-03 == Outdated reference: A later version (-12) exists of draft-ietf-tls-oldversions-deprecate-06 -- 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 4366 (Obsoleted by RFC 5246, RFC 6066) -- 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 (~~), 3 warnings (==), 15 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 June 7, 2020 6 Expires: December 9, 2020 8 Using EAP-TLS with TLS 1.3 9 draft-ietf-emu-eap-tls13-10 11 Abstract 13 This document specifies the use of EAP-TLS with TLS 1.3 while 14 remaining backwards compatible with existing implementations of EAP- 15 TLS. TLS 1.3 provides significantly improved security, privacy, and 16 reduced latency when compared to earlier versions of TLS. EAP-TLS 17 with TLS 1.3 further improves security and privacy by mandating use 18 of privacy and revocation checking. This document also provides 19 guidance on authorization and resumption for EAP-TLS in general 20 (regardless of the underlying TLS version used). This document 21 updates RFC 5216. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 9, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements and Terminology . . . . . . . . . . . . . . 4 59 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4 61 2.1.1. Mutual Authentication . . . . . . . . . . . . . . . . 4 62 2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 5 63 2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 6 64 2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 8 65 2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 11 66 2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 12 67 2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 13 68 2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 14 69 2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 14 70 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 15 71 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 16 72 2.4. Parameter Negotiation and Compliance Requirements . . . . 17 73 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 17 74 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 19 75 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 19 78 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 20 79 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 20 80 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 20 81 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 20 82 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 21 83 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 21 84 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 23 85 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 24 86 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 24 87 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 6.1. Normative References . . . . . . . . . . . . . . . . . . 25 89 6.2. Informative references . . . . . . . . . . . . . . . . . 26 90 Appendix A. Updated references . . . . . . . . . . . . . . . . . 29 91 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29 92 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 29 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 95 1. Introduction 97 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 98 provides a standard mechanism for support of multiple authentication 99 methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies 100 an EAP authentication method with certificate-based mutual 101 authentication utilizing the TLS handshake protocol for cryptographic 102 algorithms and protocol version negotiation, mutual authentication, 103 and establishment of shared secret keying material. EAP-TLS is 104 widely supported for authentication and and key establishment in IEEE 105 802.11 [IEEE-802.11] (Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE] (MACsec) 106 networks using IEEE 802.1X [IEEE-802.1X] and it's the default 107 mechanism for certificate based authentication in 3GPP 5G [TS.33.501] 108 and MulteFire [MulteFire] networks. Many other EAP methods such as 109 EAP-FAST [RFC4851], EAP-TTLS [RFC5281], TEAP [RFC7170], and PEAP 110 [PEAP] depend on TLS and EAP-TLS. 112 EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346], 113 but can also work with TLS 1.2 [RFC5246]. TLS 1.0 and 1.1 are 114 formally deprecated and prohibited to negotiate and use 115 [I-D.ietf-tls-oldversions-deprecate]. Weaknesses found in TLS 1.2, 116 as well as new requirements for security, privacy, and reduced 117 latency has led to the specification of TLS 1.3 [RFC8446], which 118 obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is in large parts a complete 119 remodeling of the TLS handshake protocol including a different 120 message flow, different handshake messages, different key schedule, 121 different cipher suites, different resumption, different privacy 122 protection, and record padding. This means that significant parts of 123 the normative text in the previous EAP-TLS specification [RFC5216] 124 are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore, 125 aspects such as resumption, privacy handling, and key derivation need 126 to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). 128 This document defines how to use EAP-TLS with TLS 1.3 (or higher) and 129 does not change how EAP-TLS is used with older versions of TLS. We 130 do however provide additional guidance on authorization and 131 resumption for EAP-TLS in general (regardless of the underlying TLS 132 version used). While this document updates EAP-TLS [RFC5216], it 133 remains backwards compatible with it and existing implementations of 134 EAP-TLS. This document only describes differences compared to 135 [RFC5216]. 137 In addition to the improved security and privacy offered by TLS 1.3, 138 there are other significant benefits of using EAP-TLS with TLS 1.3. 139 Privacy is mandatory and achieved without any additional round-trips, 140 revocation checking is mandatory and simplified with OCSP stapling, 141 and TLS 1.3 introduces more possibilities to reduce fragmentation 142 when compared to earlier versions of TLS. 144 1.1. Requirements and Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14 [RFC2119] [RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 Readers are expected to be familiar with the terms and concepts used 153 in EAP-TLS [RFC5216] and TLS [RFC8446]. 155 2. Protocol Overview 157 2.1. Overview of the EAP-TLS Conversation 159 This section updates Section 2.1 of [RFC5216]. 161 TLS 1.3 changes both the message flow and the handshake messages 162 compared to earlier versions of TLS. Therefore, much of Section 2.1 163 of [RFC5216] does not apply for TLS 1.3 (or higher). 165 After receiving an EAP-Request packet with EAP-Type=EAP-TLS as 166 described in [RFC5216] the conversation will continue with the TLS 167 handshake protocol encapsulated in the data fields of EAP-Response 168 and EAP-Request packets. When EAP-TLS is used with TLS version 1.3 169 or higher, the formatting and processing of the TLS handshake SHALL 170 be done as specified in that version of TLS. This document only 171 lists additional and different requirements, restrictions, and 172 processing compared to [RFC8446] and [RFC5216]. 174 2.1.1. Mutual Authentication 176 This section updates Section 2.1.1 of [RFC5216]. 178 The EAP server MUST authenticate with a certificate and SHOULD 179 require the EAP peer to authenticate with a certificate. 180 Certificates can be of any type supported by TLS including raw public 181 keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except 182 for resumption. SessionID is deprecated in TLS 1.3 and the EAP 183 server SHALL ignore the legacy_session_id field if TLS 1.3 is 184 negotiated. TLS 1.3 introduced early application data which is not 185 used in EAP-TLS. A server which receives an "early_data" extension 186 MUST ignore the extension or respond with a HelloRetryRequest as 187 described in Section 4.2.10 of [RFC8446]. Resumption is handled as 188 described in Section 2.1.3. After the TLS handshake has completed 189 and all Post-Handshake messages have been sent, the EAP server sends 190 EAP-Success. 192 In the case where EAP-TLS with mutual authentication is successful 193 (and neither HelloRetryRequest nor Post-Handshake messages are sent) 194 the conversation will appear as shown in Figure 1. The EAP server 195 commits to not send any more handshake messages by sending a 196 Commitment Message (a TLS record with the application data 0x00), see 197 Section 2.5. 199 EAP Peer EAP Server 201 EAP-Request/ 202 <-------- Identity 203 EAP-Response/ 204 Identity (Privacy-Friendly) --------> 205 EAP-Request/ 206 EAP-Type=EAP-TLS 207 <-------- (TLS Start) 208 EAP-Response/ 209 EAP-Type=EAP-TLS 210 (TLS ClientHello) --------> 211 EAP-Request/ 212 EAP-Type=EAP-TLS 213 (TLS ServerHello, 214 TLS EncryptedExtensions, 215 TLS CertificateRequest, 216 TLS Certificate, 217 TLS CertificateVerify, 218 TLS Finished, 219 <-------- Commitment Message) 220 EAP-Response/ 221 EAP-Type=EAP-TLS 222 (TLS Certificate, 223 TLS CertificateVerify, 224 TLS Finished) --------> 225 <-------- EAP-Success 227 Figure 1: EAP-TLS mutual authentication 229 2.1.2. Ticket Establishment 231 This is a new section when compared to [RFC5216]. 233 To enable resumption when using EAP-TLS with TLS 1.3, the EAP server 234 MUST send a NewSessionTicket message (containing a PSK and other 235 parameters) in the initial authentication. The NewSessionTicket is 236 sent after the EAP server has received the Finished message in the 237 initial authentication. The NewSessionTicket message MUST NOT 238 include an "early_data" extension. 240 In the case where EAP-TLS with mutual authentication and ticket 241 establishment is successful, the conversation will appear as shown in 242 Figure 2. 244 EAP Peer EAP Server 246 EAP-Request/ 247 <-------- Identity 248 EAP-Response/ 249 Identity (Privacy-Friendly) --------> 250 EAP-Request/ 251 EAP-Type=EAP-TLS 252 <-------- (TLS Start) 253 EAP-Response/ 254 EAP-Type=EAP-TLS 255 (TLS ClientHello) --------> 256 EAP-Request/ 257 EAP-Type=EAP-TLS 258 (TLS ServerHello, 259 TLS EncryptedExtensions, 260 TLS CertificateRequest, 261 TLS Certificate, 262 TLS CertificateVerify, 263 <-------- TLS Finished) 264 EAP-Response/ 265 EAP-Type=EAP-TLS 266 (TLS Certificate, 267 TLS CertificateVerify, 268 TLS Finished) --------> 269 EAP-Request/ 270 EAP-Type=EAP-TLS 271 (TLS NewSessionTicket, 272 <-------- Commitment Message) 273 EAP-Response/ 274 EAP-Type=EAP-TLS --------> 275 <-------- EAP-Success 277 Figure 2: EAP-TLS ticket establishment 279 2.1.3. Resumption 281 This section updates Section 2.1.2 of [RFC5216]. 283 TLS 1.3 replaces the session resumption mechanisms in earlier 284 versions of TLS with a new PSK exchange. When EAP-TLS is used with 285 TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism 286 compatible with that version of TLS. 288 For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If 289 the client has received a NewSessionTicket message from the server, 290 the client can use the PSK identity received in the ticket to 291 negotiate the use of the associated PSK. If the server accepts it, 292 then the security context of the new connection is tied to the 293 original connection and the key derived from the initial handshake is 294 used to bootstrap the cryptographic state instead of a full 295 handshake. It is left up to the EAP peer whether to use resumption, 296 but it is RECOMMENDED that the EAP server accept resumption as long 297 as the ticket is valid. However, the server MAY choose to require a 298 full authentication. EAP peers and EAP servers SHOULD follow the 299 client tracking preventions in Appendix C.4 of [RFC8446]. 301 It is RECOMMENDED to use a NAIs with the same realm in the resumption 302 and the original full authentication. This requirement allows EAP 303 packets to be routable to the same destination as the original full 304 authentication. If this recommendation is not followed, resumption 305 is likely to be impossible. When NAI reuse can be done without 306 privacy implications, it is RECOMMENDED to use the same anonymous NAI 307 in the resumption, as was used in the original full authentication. 308 E.g. the NAI @realm can safely be reused, while the NAI 309 ZmxleG8=@realm cannot. The TLS PSK identity is typically derived by 310 the TLS implementation and may be an opaque blob without a routable 311 realm. The TLS PSK identity is therefore in general unsuitable for 312 deriving a NAI to use in the Identity Response. 314 A subsequent authentication using resumption, where both sides 315 authenticate successfully (without the issuance of more resumption 316 tickets) is shown in Figure 3. 318 EAP Peer EAP Server 320 EAP-Request/ 321 <-------- Identity 322 EAP-Response/ 323 Identity (Privacy-Friendly) --------> 324 EAP-Request/ 325 EAP-Type=EAP-TLS 326 <-------- (TLS Start) 327 EAP-Response/ 328 EAP-Type=EAP-TLS 329 (TLS ClientHello) --------> 330 EAP-Request/ 331 EAP-Type=EAP-TLS 332 (TLS ServerHello, 333 TLS EncryptedExtensions, 334 TLS Finished, 335 <-------- Commitment Message) 336 EAP-Response/ 337 EAP-Type=EAP-TLS 338 (TLS Finished) --------> 339 <-------- EAP-Success 341 Figure 3: EAP-TLS resumption 343 As specified in Section 2.2 of [RFC8446], the EAP peer SHOULD supply 344 a "key_share" extension when attempting resumption, which allows the 345 EAP server to potentially decline resumption and fall back to a full 346 handshake. If the EAP peer did not supply a "key_share" extension 347 when attempting resumption, the EAP server needs to reject the 348 ClientHello and the EAP peer needs to restart a full handshake. The 349 message flow in this case is given by Figure 4 followed by Figure 1. 351 Also during resumption, the server can respond with a Hello Retry 352 Request (see Section 2.1.6) or issue a new ticket (see Section 2.1.2) 354 2.1.4. Termination 356 This section updates Section 2.1.3 of [RFC5216]. 358 TLS 1.3 changes both the message flow and the handshake messages 359 compared to earlier versions of TLS. Therefore, some normative text 360 in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3 or higher. 361 The two paragraphs below replaces the corresponding paragraphs in 362 Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or 363 higher. The other paragraphs in Section 2.1.3 of [RFC5216] still 364 apply with the exception that SessionID is deprecated. 366 If the EAP peer authenticates successfully, the EAP server MUST 367 send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS 368 records conforming to the version of TLS used. The message flow 369 ends with the EAP server sending an EAP-Success message. 371 If the EAP server authenticates successfully, the EAP peer MUST 372 send an EAP-Response message with EAP-Type=EAP-TLS containing TLS 373 records conforming to the version of TLS used. 375 Figures 4, 5, and 6 illustrate message flows in several cases where 376 the EAP peer or EAP server sends a TLS fatal alert message. TLS 377 warning alerts generally mean that the connection can continue 378 normally and does not change the message flow. Note that the party 379 receiving a TLS warning alert may choose to terminate the connection 380 by sending a TLS fatal alert, which may add an extra round-trip, see 381 [RFC8446]. 383 In the case where the server rejects the ClientHello with a fatal 384 error, the conversation will appear as shown in Figure 4. The server 385 can also partly reject the ClientHello with a HelloRetryRequest, see 386 Section 2.1.6. 388 EAP Peer EAP 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 Fatal Alert) 403 EAP-Response/ 404 EAP-Type=EAP-TLS --------> 405 <-------- EAP-Failure 407 Figure 4: EAP-TLS server rejection of ClientHello 409 In the case where server authentication is unsuccessful, the 410 conversation will appear as shown in Figure 5. 412 EAP Peer EAP Server 414 EAP-Request/ 415 <-------- Identity 416 EAP-Response/ 417 Identity (Privacy-Friendly) --------> 418 EAP-Request/ 419 EAP-Type=EAP-TLS 420 <-------- (TLS Start) 421 EAP-Response/ 422 EAP-Type=EAP-TLS 423 (TLS ClientHello) --------> 424 EAP-Request/ 425 EAP-Type=EAP-TLS 426 (TLS ServerHello, 427 TLS EncryptedExtensions, 428 TLS CertificateRequest, 429 TLS Certificate, 430 TLS CertificateVerify, 431 TLS Finished, 432 <-------- Commitment Message) 433 EAP-Response/ 434 EAP-Type=EAP-TLS 435 (TLS Fatal Alert) 436 --------> 437 <-------- EAP-Failure 439 Figure 5: EAP-TLS unsuccessful server authentication 441 In the case where the server authenticates to the peer successfully, 442 but the peer fails to authenticate to the server, the conversation 443 will appear as shown in Figure 6. 445 EAP Peer EAP Server 447 EAP-Request/ 448 <-------- Identity 449 EAP-Response/ 450 Identity (Privacy-Friendly) --------> 452 EAP-Request/ 453 EAP-Type=EAP-TLS 454 <-------- (TLS Start) 455 EAP-Response/ 456 EAP-Type=EAP-TLS 457 (TLS ClientHello) --------> 458 EAP-Request/ 459 EAP-Type=EAP-TLS 460 (TLS ServerHello, 461 TLS EncryptedExtensions, 462 TLS CertificateRequest, 463 TLS Certificate, 464 TLS CertificateVerify, 465 TLS Finished, 466 <-------- Commitment Message) 467 EAP-Response/ 468 EAP-Type=EAP-TLS 469 (TLS Certificate, 470 TLS CertificateVerify, 471 TLS Finished) --------> 472 EAP-Request/ 473 EAP-Type=EAP-TLS 474 <-------- (TLS Fatal Alert) 475 EAP-Response/ 476 EAP-Type=EAP-TLS --------> 477 <-------- EAP-Failure 479 Figure 6: EAP-TLS unsuccessful client authentication 481 2.1.5. No Peer Authentication 483 This is a new section when compared to [RFC5216]. 485 In the case where EAP-TLS is used without peer authentication (e.g., 486 emergency services, as described in [RFC7406]) the conversation will 487 appear as shown in Figure 7. 489 EAP Peer EAP 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 Certificate, 506 TLS CertificateVerify, 507 TLS Finished, 508 <-------- Commitment Message) 509 EAP-Response/ 510 EAP-Type=EAP-TLS 511 (TLS Finished) --------> 512 <-------- EAP-Success 514 Figure 7: EAP-TLS without peer authentication 516 2.1.6. Hello Retry Request 518 This is a new section when compared to [RFC5216]. 520 TLS 1.3 [RFC8446] defines that TLS servers can send a 521 HelloRetryRequest message in response to a ClientHello if the server 522 finds an acceptable set of parameters but the initial ClientHello 523 does not contain all the needed information to continue the 524 handshake. One use case is if the server does not support the groups 525 in the "key_share" extension, but supports one of the groups in the 526 "supported_groups" extension. In this case the client should send a 527 new ClientHello with a "key_share" that the server supports. 529 An EAP-TLS peer and server SHOULD support the use of 530 HelloRetryRequest message. As noted in Section 4.1.4 of [RFC8446], 531 the server MUST provide the supported_versions extensions and SHOULD 532 contain the minimal set of extensions necessary for the client to 533 generate a correct ClientHello pair. A HelloRetryRequest MUST NOT 534 contain any extensions that were not first offered by the client in 535 its ClientHello, with the exception of optionally including the 536 cookie extension. 538 The case of a successful EAP-TLS mutual authentication after the 539 server has sent a HelloRetryRequest message is shown in Figure 8. 540 Note the extra round-trip as a result of the HelloRetryRequest. 542 EAP Peer EAP Server 544 EAP-Request/ 545 <-------- Identity 546 EAP-Response/ 547 Identity (Privacy-Friendly) --------> 548 EAP-Request/ 549 EAP-Type=EAP-TLS 550 <-------- (TLS Start) 551 EAP-Response/ 552 EAP-Type=EAP-TLS 553 (TLS ClientHello) --------> 554 EAP-Request/ 555 EAP-Type=EAP-TLS 556 (TLS HelloRetryRequest) 557 <-------- 558 EAP-Response/ 559 EAP-Type=EAP-TLS 560 (TLS ClientHello) --------> 561 EAP-Request/ 562 EAP-Type=EAP-TLS 563 (TLS ServerHello, 564 TLS EncryptedExtensions, 565 TLS Certificate, 566 TLS CertificateVerify, 567 TLS Finished, 568 <-------- Commitment Message) 569 EAP-Response/ 570 EAP-Type=EAP-TLS 571 (TLS Certificate, 572 TLS CertificateVerify, 573 TLS Finished) --------> 574 <-------- EAP-Success 576 Figure 8: EAP-TLS with Hello Retry Request 578 2.1.7. Identity 580 This is a new section when compared to [RFC5216]. 582 It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity 583 Response as such identities are routable and privacy-friendly. While 584 opaque blobs are allowed by [RFC3748], such identities are NOT 585 RECOMMENDED as they are not routable and should only be considered in 586 local deployments where the EAP peer, EAP authenticator, and EAP 587 server all belong to the same network. Many client certificates 588 contains an identity such as an email address, which is already in 589 NAI format. When the client certificate contains a NAI as subject 590 name or alternative subject name, an anonymous NAI SHOULD be derived 591 from the NAI in the certificate, see Section 2.1.8. More details on 592 identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8. 594 2.1.8. Privacy 596 This section updates Section 2.1.4 of [RFC5216]. 598 TLS 1.3 significantly improves privacy when compared to earlier 599 versions of TLS by forbidding cipher suites without confidentiality 600 and encrypting large parts of the TLS handshake including the 601 certificate messages. 603 EAP-TLS peer and server implementations supporting TLS 1.3 or higher 604 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 605 in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its 606 username in cleartext in the Identity Response. Following [RFC7542], 607 it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but 608 other constructions such as a fixed username (e.g. anonymous@realm) 609 or an encrypted username (e.g. YmVuZGVy@realm) are allowed. Note 610 that the NAI MUST be a UTF-8 string as defined by the grammar in 611 Section 2.2 of [RFC7542]. 613 As the certificate messages in TLS 1.3 are encrypted, there is no 614 need to send an empty certificate_list and perform a second handshake 615 for privacy (as needed by EAP-TLS with earlier versions of TLS). 616 When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer 617 and EAP-TLS server SHALL follow the processing specified by the used 618 version of TLS. For TLS 1.3 this means that the EAP-TLS peer only 619 sends an empty certificate_list if it does not have an appropriate 620 certificate to send, and the EAP-TLS server MAY treat an empty 621 certificate_list as a terminal condition. 623 EAP-TLS with TLS 1.3 is always used with privacy. This does not add 624 any extra round-trips and the message flow with privacy is just the 625 normal message flow as shown in Figure 1. 627 2.1.9. Fragmentation 629 This section updates Section 2.1.5 of [RFC5216]. 631 Including ContentType and ProtocolVersion a single TLS record may be 632 up to 16387 octets in length. EAP-TLS fragmentation support is 633 provided through addition of a flags octet within the EAP-Response 634 and EAP-Request packets, as well as a TLS Message Length field of 635 four octets. Implementations MUST NOT set the L bit in unfragmented 636 messages, but MUST accept unfragmented messages with and without the 637 L bit set. 639 Some EAP implementations and access networks may limit the number of 640 EAP packet exchanges that can be handled. To avoid fragmentation, it 641 is RECOMMENDED to keep the sizes of client, server, and trust anchor 642 certificates small and the length of the certificate chains short. 643 In addition, it is RECOMMENDED to use mechanisms that reduce the 644 sizes of Certificate messages. 646 While Elliptic Curve Cryptography (ECC) was optional for earlier 647 version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of 648 [RFC8446]). To avoid fragmentation, the use of ECC in certificates, 649 signature algorithms, and groups are RECOMMENDED when using EAP-TLS 650 with TLS 1.3 or higher. At a 128-bit security level, this reduces 651 public key sizes from 384 bytes (RSA and DHE) to 32-64 bytes (ECDHE) 652 and signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA). 653 An EAP-TLS deployment MAY further reduce the certificate sizes by 654 limiting the number of Subject Alternative Names. 656 Endpoints SHOULD reduce the sizes of Certificate messages by omitting 657 certificates that the other endpoint is known to possess. When using 658 TLS 1.3, all certificates that specifies a trust anchor may be 659 omitted (see Section 4.4.2 of [RFC8446]). When using TLS 1.2, only 660 the self-signed certificate that specifies the root certificate 661 authority may be omitted (see Section 7.4.2 of [RFC5246]). EAP-TLS 662 peers and servers SHOULD support and use the Cached Information 663 Extension as specified in [RFC7924]. EAP-TLS peers and servers MAY 664 use other extensions for reducing the sizes of Certificate messages, 665 e.g. certificate compression [I-D.ietf-tls-certificate-compression]. 667 For a detailed discussion on reducing message sizes to prevent 668 fragmentation, see [I-D.ietf-emu-eaptlscert]. 670 2.2. Identity Verification 672 This section updates Section 2.2 of [RFC5216]. 674 The identity provided in the EAP-Response/Identity is not 675 authenticated by EAP-TLS. Unauthenticated information SHALL NOT be 676 used for accounting purposes or to give authorization. The 677 authenticator and the EAP server MAY examine the identity presented 678 in EAP-Response/Identity for purposes such as routing and EAP method 679 selection. Servers MAY reject conversations if the identity does not 680 match their policy. Note that this also applies to resumption, see 681 Sections 2.1.3, 5.6, and 5.7. 683 2.3. Key Hierarchy 685 This section updates Section 2.3 of [RFC5216]. 687 TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier 688 versions of TLS with HKDF and completely changes the Key Schedule. 689 The key hierarchies shown in Section 2.3 of [RFC5216] are therefore 690 not correct when EAP-TLS is used with TLS version 1.3 or higher. For 691 TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446]. 693 When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, 694 IV, and Method-Id SHALL be derived from the exporter_master_secret 695 using the TLS exporter interface [RFC5705] (for TLS 1.3 this is 696 defined in Section 7.5 of [RFC8446]). 698 Type-Code = 0x0D 699 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 700 Type-Code, 128) 701 IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", 702 Type-Code, 64) 703 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 704 Type-Code, 64) 705 Session-Id = Type-Code || Method-Id 707 All other parameters such as MSK and EMSK are derived in the same 708 manner as with EAP-TLS [RFC5216], Section 2.3. The definitions are 709 repeated below for simplicity: 711 MSK = Key_Material(0, 63) 712 EMSK = Key_Material(64, 127) 713 Enc-RECV-Key = MSK(0, 31) 714 Enc-SEND-Key = MSK(32, 63) 715 RECV-IV = IV(0, 31) 716 SEND-IV = IV(32, 63) 718 The use of these keys is specific to the lower layer, as described 719 [RFC5247]. 721 Note that the key derivation MUST use the length values given above. 722 While in TLS 1.2 and earlier it was possible to truncate the output 723 by requesting less data from the TLS-Exporter function, this practice 724 is not possible with TLS 1.3. If an implementation intends to use 725 only a part of the output of the TLS-Exporter function, then it MUST 726 ask for the full output and then only use the desired part. Failure 727 to do so will result in incorrect values being calculated for the 728 above keying material. 730 By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation 731 without having to extract the Master Secret, ClientHello.random, and 732 ServerHello.random in a non-standard way. 734 2.4. Parameter Negotiation and Compliance Requirements 736 This section updates Section 2.4 of [RFC5216]. 738 TLS 1.3 cipher suites are defined differently than in earlier 739 versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites 740 discussed in Section 2.4 of [RFC5216] can therefore not be used when 741 EAP-TLS is used with TLS version 1.3 or higher. 743 When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS 744 peers and servers MUST comply with the compliance requirements 745 (mandatory-to-implement cipher suites, signature algorithms, key 746 exchange algorithms, extensions, etc.) for the TLS version used. For 747 TLS 1.3 the compliance requirements are defined in Section 9 of 748 [RFC8446]. 750 While EAP-TLS does not protect any application data, the negotiated 751 cipher suites and algorithms MAY be used to secure data as done in 752 other TLS-based EAP methods. 754 2.5. EAP State Machines 756 This is a new section when compared to [RFC5216]. 758 TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- 759 Handshake messages use the handshake content type and can be sent 760 after the main handshake. One such Post-Handshake message is 761 NewSessionTicket. The NewSessionTicket can be used for resumption. 762 After sending TLS Finished, the EAP server may send any number of 763 Post-Handshake messages in separate EAP-Requests. To decrease the 764 uncertainty for the EAP peer, the following procedure MUST be 765 followed: 767 When an EAP server has sent its last handshake message (Finished or a 768 Post-Handshake), it commits to not sending any more handshake 769 messages by sending a Commitment Message. The Commitment Message is 770 a TLS record with application data 0x00 (i.e. a TLS record with 771 TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and 772 TLSPlaintext.fragment = 0x00). Note that the length of the plaintext 773 is greater than the corresponding TLSPlaintext.length due to the 774 inclusion of TLSInnerPlaintext.type and any padding supplied by the 775 sender. EAP server implementations MUST set TLSPlaintext.fragment to 776 0x00, but EAP peer implementations MUST accept any application data 777 as a Commitment Message from the EAP server to not send any more 778 handshake messages. The Commitment Message may be sent in the same 779 EAP-Request as the last handshake record or in a separate EAP- 780 Request. Sending the Commitment Message in a separate EAP-Request 781 adds an additional round-trip, but may be necessary in TLS 782 implementations that only implement a subset of TLS 1.3. In the case 783 where the server sends the Commitment Message in a separate EAP- 784 Request, the conversation will appear as shown in Figure 9. After 785 sending the Commitment Message, the EAP server may only send an EAP- 786 Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. 788 EAP Peer EAP Server 790 EAP-Request/ 791 <-------- Identity 792 EAP-Response/ 793 Identity (Privacy-Friendly) --------> 794 EAP-Request/ 795 EAP-Type=EAP-TLS 796 <-------- (TLS Start) 797 EAP-Response/ 798 EAP-Type=EAP-TLS 799 (TLS ClientHello) --------> 800 EAP-Request/ 801 EAP-Type=EAP-TLS 802 (TLS ServerHello, 803 TLS EncryptedExtensions, 804 TLS CertificateRequest, 805 TLS Certificate, 806 TLS CertificateVerify, 807 <-------- TLS Finished) 808 EAP-Response/ 809 EAP-Type=EAP-TLS 810 (TLS Certificate, 811 TLS CertificateVerify, 812 TLS Finished) --------> 813 EAP-Request/ 814 EAP-Type=EAP-TLS 815 <-------- Commitment Message) 816 EAP-Response/ 817 EAP-Type=EAP-TLS --------> 818 <-------- EAP-Success 820 Figure 9: Commit in separate EAP-Request 822 3. Detailed Description of the EAP-TLS Protocol 824 No updates to Section 3 of [RFC5216]. 826 4. IANA considerations 828 This section provides guidance to the Internet Assigned Numbers 829 Authority (IANA) regarding registration of values related to the EAP- 830 TLS 1.3 protocol in accordance with [RFC8126]. 832 This memo requires IANA to add the following labels to the TLS 833 Exporter Label Registry defined by [RFC5705]. These labels are used 834 in derivation of Key_Material, IV and Method-Id as defined in 835 Section 2.3: 837 o "EXPORTER_EAP_TLS_Key_Material" 839 o "EXPORTER_EAP_TLS_IV" 841 o "EXPORTER_EAP_TLS_Method-Id" 843 5. Security Considerations 845 5.1. Security Claims 847 Using EAP-TLS with TLS 1.3 does not change the security claims for 848 EAP-TLS as given in Section 5.1 of [RFC5216]. However, it 849 strengthens several of the claims as described in the following 850 updates to the notes given in Section 5.1 of [RFC5216]. 852 [1] Mutual authentication: By mandating revocation checking of 853 certificates, the authentication in EAP-TLS with TLS 1.3 is stronger 854 as authentication with revoked certificates will always fail. 856 [2] Confidentiality: The TLS 1.3 handshake offers much better 857 confidentiality than earlier versions of TLS by mandating cipher 858 suites with confidentiality and encrypting certificates and some of 859 the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the 860 use of privacy is mandatory and does not cause any additional round- 861 trips. 863 [3] Key strength: TLS 1.3 forbids all algorithms with known 864 weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 865 only supports cryptographic algorithms offering at least 112-bit 866 security, see [RFC8446]. 868 [4] Cryptographic Negotiation: TLS 1.3 increases the number of 869 cryptographic parameters that are negotiated in the handshake. When 870 EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic 871 negotiation of AEAD algorithm, HKDF hash algorithm, key exchange 872 groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. 874 5.2. Peer and Server Identities 876 No updates to section 5.2 of [RFC5216]. 878 5.3. Certificate Validation 880 No updates to section 5.3 of [RFC5216]. 882 5.4. Certificate Revocation 884 This section updates Section 5.4 of [RFC5216]. 886 While certificates may have long validity periods, there are a number 887 of reasons (e.g. key compromise, CA compromise, privilege withdrawn, 888 etc.) why client, server, or sub-CA certificates have to be revoked 889 before their expiry date. Revocation of the EAP server's certificate 890 is complicated by the fact that the EAP peer may not have Internet 891 connectivity until authentication completes. 893 EAP-TLS peers and servers supporting TLS 1.3 MUST support Certificate 894 Status Requests (OCSP stapling) as specified in [RFC6066] and 895 Section 4.4.2.1 of [RFC8446]. When EAP-TLS is used with TLS 1.3, the 896 peer and server MUST use Certificate Status Requests [RFC6066] for 897 the server's certificate chain and the EAP peer MUST treat a 898 CertificateEntry (except the trust anchor) without a valid 899 CertificateStatus extension as invalid and abort the handshake with 900 an appropriate alert. When EAP-TLS is used with TLS 1.3, the server 901 MUST check the revocation status of the certificates in the client's 902 certificate chain. 904 The OCSP status handling in TLS 1.3 is different from earlier 905 versions of TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the 906 OCSP information is carried in the CertificateEntry containing the 907 associated certificate instead of a separate CertificateStatus 908 message as in [RFC4366]. This enables sending OCSP information for 909 all certificates in the certificate chain. 911 5.5. Packet Modification Attacks 913 No updates to Section 5.5 of [RFC5216]. 915 5.6. Authorization 917 This is a new section when compared to [RFC5216]. The guidance in 918 this section is relevant for EAP-TLS in general (regardless of the 919 underlying TLS version used). 921 EAP-TLS is typically encapsulated in other protocols, such as PPP 922 [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. 923 The encapsulating protocols can also provide additional, non-EAP 924 information to an EAP server. This information can include, but is 925 not limited to, information about the authenticator, information 926 about the EAP peer, or information about the protocol layers above or 927 below EAP (MAC addresses, IP addresses, port numbers, WiFi SSID, 928 etc.). Servers implementing EAP-TLS inside those protocols can make 929 policy decisions and enforce authorization based on a combination of 930 information from the EAP-TLS exchange and non-EAP information. 932 As noted in Section 2.2, the identity presented in EAP-Response/ 933 Identity is not authenticated by EAP-TLS and is therefore trivial for 934 an attacker to forge, modify, or replay. Authorization and 935 accounting MUST be based on authenticated information such as 936 information in the certificate or the PSK identity and cached data 937 provisioned for resumption as described in Section 5.7. Note that 938 the requirements for Network Access Identifiers (NAIs) specified in 939 Section 4 of [RFC7542] still apply and MUST be followed. 941 EAP-TLS servers MAY reject conversations based on non-EAP information 942 provided by the encapsulating protocol, for example, if the MAC 943 address of the authenticator does not match the expected policy. 945 5.7. Resumption 947 This is a new section when compared to [RFC5216]. The guidance in 948 this section is relevant for EAP-TLS in general (regardless of the 949 underlying TLS version used). 951 There are a number of security issues related to resumption that are 952 not described in [RFC5216]. The problems, guidelines, and 953 requirements in this section therefore applies to all version of TLS. 955 When resumption occurs, it is based on cached information at the TLS 956 layer. To perform resumption in a secure way, the EAP-TLS peer and 957 EAP-TLS server need to be able to securely retrieve authorization 958 information such as certificate chains from the initial full 959 handshake. We use the term "cached data" to describe such 960 information. Authorization during resumption MUST be based on such 961 cached data. The EAP peer and sever MAY perform fresh revocation 962 checks on the cached certificate data. Any security policies for 963 authorization MUST be followed also for resumption. The certificates 964 may have been revoked since the initial full handshake and the 965 authorizations of the other party may have been reduced. If the 966 cached revocation information is not sufficiently current, the EAP 967 Peer or EAP Server MAY force a full TLS handshake. 969 There are two ways to retrieve the cached information from the 970 original full handshake. The first method is that the TLS server and 971 client cache the information locally. The cached information is 972 identified by an identifier. For TLS versions before 1.3, the 973 identifier can be the session ID, for TLS 1.3, the identifier is the 974 PSK identity. The second method for retrieving cached information is 975 via [RFC5077] or [RFC8446], where the TLS server encapsulates the 976 information into a ticket and sends it to the client. The client can 977 subsequently do resumption using the obtained ticket. Note that the 978 client still needs to cache the information locally. The following 979 requirements apply to both methods. 981 If the EAP server or EAP client do not apply any authorization 982 policies, they MAY allow resumption where no cached data is 983 available. In all other cases, they MUST cache data during the 984 initial full authentication to enable resumption. The cached data 985 MUST be sufficient to make authorization decisions during resumption. 986 If cached data cannot be retrieved in a secure way, resumption MUST 987 NOT be done. 989 The above requirements also apply if the EAP server expects some 990 system to perform accounting for the session. Since accounting must 991 be tied to an authenticated identity, and resumption does not supply 992 such an identity, accounting is impossible without access to cached 993 data. 995 Information from the EAP-TLS exchange (e.g. the identity provided in 996 EAP-Response/Identity) as well as non-EAP information (e.g. IP 997 addresses) may change between the initial full handshake and 998 resumption. This change creates a "Time-of-check time-of-use" 999 (TOCTOU) security vulnerability. A malicious or compromised user 1000 could supply one set of data during the initial authentication, and a 1001 different set of data during resumption, potentially leading to them 1002 obtaining access that they should not have. 1004 If any authorization, accounting, or policy decisions were made with 1005 information that have changed between the initial full handshake and 1006 resumption, and if change may lead to a different decision, such 1007 decisions MUST be reevaluated. It is RECOMMENDED that authorization, 1008 accounting, and policy decisions are reevaluated based on the 1009 information given in the resumption. EAP servers MAY reject 1010 resumption where the information supplied during resumption does not 1011 match the information supplied during the original authentication. 1012 Where a good decision is unclear, EAP servers SHOULD reject the 1013 resumption. 1015 Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security 1016 consideration for resumption. 1018 5.8. Privacy Considerations 1020 This is a new section when compared to [RFC5216]. 1022 TLS 1.3 offers much better privacy than earlier versions of TLS as 1023 discussed in Section 2.1.8. In this section, we only discuss the 1024 privacy properties of EAP-TLS with TLS 1.3. For privacy properties 1025 of TLS 1.3 itself, see [RFC8446]. 1027 EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in 1028 EAP packets. Additionally, the EAP peer sends an identity in the 1029 first EAP-Response. The other fields in the EAP-TLS Request and the 1030 EAP-TLS Response packets do not contain any cleartext privacy 1031 sensitive information. 1033 Tracking of users by eavesdropping on identity responses or 1034 certificates is a well-known problem in many EAP methods. When EAP- 1035 TLS is used with TLS 1.3, all certificates are encrypted, and the 1036 username part of the identity response is always confidentiality 1037 protected (e.g. using Anonymous NAIs). However, as with other EAP 1038 methods, even when privacy-friendly identifiers or EAP tunneling is 1039 used, the domain name (i.e. the realm) in the NAI is still typically 1040 visible. How much privacy sensitive information the domain name 1041 leaks is highly dependent on how many other users are using the same 1042 domain name in the particular access network. If all EAP peers have 1043 the same domain, no additional information is leaked. If a domain 1044 name is used by a small subset of the EAP peers, it may aid an 1045 attacker in tracking or identifying the user. 1047 Without padding, information about the size of the client certificate 1048 is leaked from the size of the EAP-TLS packets. The EAP-TLS packets 1049 sizes may therefore leak information that can be used to track or 1050 identify the user. If all client certificates have the same length, 1051 no information is leaked. EAP peers SHOULD use record padding, see 1052 Section 5.4 of [RFC8446] to reduce information leakage of certificate 1053 sizes. 1055 If Anonymous NAIs are not used, the privacy-friendly identifiers need 1056 to be generated with care. The identities MUST be generated in a 1057 cryptographically secure way so that that it is computationally 1058 infeasible for an attacker to differentiate two identities belonging 1059 to the same user from two identities belonging to different users in 1060 the same realm. This can be achieved, for instance, by using random 1061 or pseudo-random usernames such as random byte strings or ciphertexts 1062 and only using the pseudo-random usernames a single time. Note that 1063 the privacy-friendly usernames also MUST NOT include substrings that 1064 can be used to relate the identity to a specific user. Similarly, 1065 privacy-friendly username SHOULD NOT be formed by a fixed mapping 1066 that stays the same across multiple different authentications. 1068 An EAP peer with a policy allowing communication with EAP servers 1069 supporting only TLS 1.2 without privacy and with a static RSA key 1070 exchange is vulnerable to disclosure of the peer username. An active 1071 attacker can in this case make the EAP peer believe that an EAP 1072 server supporting TLS 1.3 only supports TLS 1.2 without privacy. The 1073 attacker can simply impersonate the EAP server and negotiate TLS 1.2 1074 with static RSA key exchange and send an TLS alert message when the 1075 EAP peer tries to use privacy by sending an empty certificate 1076 message. Since the attacker (impersonating the EAP server) does not 1077 provide a proof-of-possession of the private key until the Finished 1078 message when a static RSA key exchange is used, an EAP peer may 1079 inadvertently disclose its identity (username) to an attacker. 1080 Therefore, it is RECOMMENDED for EAP peers to not use EAP-TLS with 1081 TLS 1.2 and static RSA based cipher suites without privacy. This 1082 implies that an EAP peer SHOULD NOT continue the handshake if a TLS 1083 1.2 EAP server responds to an empty certificate message with a TLS 1084 alert message. 1086 5.9. Pervasive Monitoring 1088 This is a new section when compared to [RFC5216]. 1090 Pervasive monitoring refers to widespread surveillance of users. In 1091 the context EAP-TLS, pervasive monitoring attacks can target peer 1092 devices for tracking them (and their users) as and when they join a 1093 network. By encrypting more information and by mandating the use of 1094 privacy, TLS 1.3 offers much better protection against pervasive 1095 monitoring. In addition to the privacy attacks discussed above, 1096 surveillance on a large scale may enable tracking of a user over a 1097 wider geographical area and across different access networks. Using 1098 information from EAP-TLS together with information gathered from 1099 other protocols increases the risk of identifying individual users. 1101 5.10. Discovered Vulnerabilities 1103 This is a new section when compared to [RFC5216]. 1105 Over the years, there have been several serious attacks on earlier 1106 versions of Transport Layer Security (TLS), including attacks on its 1107 most commonly used ciphers and modes of operation. [RFC7457] 1108 summarizes the attacks that were known at the time of publishing and 1109 [RFC7525] provides recommendations for improving the security of 1110 deployed services that use TLS. However, many of the attacks are 1111 less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and 1112 does not protect any application data. EAP-TLS implementations 1113 SHOULD mitigate known attacks and follow the recommendations in 1114 [RFC7525] and [I-D.ietf-tls-oldversions-deprecate]. The use of TLS 1115 1.3 mitigates most of the known attacks. 1117 6. References 1119 6.1. Normative References 1121 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1122 Requirement Levels", BCP 14, RFC 2119, 1123 DOI 10.17487/RFC2119, March 1997, 1124 . 1126 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1127 Levkowetz, Ed., "Extensible Authentication Protocol 1128 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1129 . 1131 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1132 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 1133 March 2008, . 1135 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1136 Housley, R., and W. Polk, "Internet X.509 Public Key 1137 Infrastructure Certificate and Certificate Revocation List 1138 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1139 . 1141 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1142 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1143 March 2010, . 1145 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1146 Extensions: Extension Definitions", RFC 6066, 1147 DOI 10.17487/RFC6066, January 2011, 1148 . 1150 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1151 Galperin, S., and C. Adams, "X.509 Internet Public Key 1152 Infrastructure Online Certificate Status Protocol - OCSP", 1153 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1154 . 1156 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1157 DOI 10.17487/RFC7542, May 2015, 1158 . 1160 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1161 (TLS) Cached Information Extension", RFC 7924, 1162 DOI 10.17487/RFC7924, July 2016, 1163 . 1165 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1166 Writing an IANA Considerations Section in RFCs", BCP 26, 1167 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1168 . 1170 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1171 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1172 May 2017, . 1174 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1175 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1176 . 1178 6.2. Informative references 1180 [I-D.ietf-emu-eaptlscert] 1181 Sethi, M., Mattsson, J., and S. Turner, "Handling Large 1182 Certificates and Long Certificate Chains in TLS-based EAP 1183 Methods", draft-ietf-emu-eaptlscert-03 (work in progress), 1184 May 2020. 1186 [I-D.ietf-tls-certificate-compression] 1187 Ghedini, A. and V. Vasiliev, "TLS Certificate 1188 Compression", draft-ietf-tls-certificate-compression-10 1189 (work in progress), January 2020. 1191 [I-D.ietf-tls-oldversions-deprecate] 1192 Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and 1193 TLSv1.1", draft-ietf-tls-oldversions-deprecate-06 (work in 1194 progress), January 2020. 1196 [IEEE-802.11] 1197 Institute of Electrical and Electronics Engineers, "IEEE 1198 Standard for Information technology--Telecommunications 1199 and information exchange between systems Local and 1200 metropolitan area networks--Specific requirements - Part 1201 11: Wireless LAN Medium Access Control (MAC) and Physical 1202 Layer (PHY) Specifications", IEEE Std 802.11-2016 1203 (Revision of IEEE Std 802.11-2012) , December 2016. 1205 [IEEE-802.1AE] 1206 Institute of Electrical and Electronics Engineers, "IEEE 1207 Standard for Local and metropolitan area networks -- Media 1208 Access Control (MAC) Security", IEEE Standard 1209 802.1AE-2018 , December 2018. 1211 [IEEE-802.1X] 1212 Institute of Electrical and Electronics Engineers, "IEEE 1213 Standard for Local and metropolitan area networks -- Port- 1214 Based Network Access Control", IEEE Standard 802.1X-2010 , 1215 February 2010. 1217 [MulteFire] 1218 MulteFire, "MulteFire Release 1.1 specification", 2019. 1220 [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible 1221 Authentication Protocol (PEAP)", 2019. 1223 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 1224 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 1225 . 1227 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1228 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1229 . 1231 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1232 Adams, "X.509 Internet Public Key Infrastructure Online 1233 Certificate Status Protocol - OCSP", RFC 2560, 1234 DOI 10.17487/RFC2560, June 1999, 1235 . 1237 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1238 "Remote Authentication Dial In User Service (RADIUS)", 1239 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1240 . 1242 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1243 X.509 Public Key Infrastructure Certificate and 1244 Certificate Revocation List (CRL) Profile", RFC 3280, 1245 DOI 10.17487/RFC3280, April 2002, 1246 . 1248 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1249 Network Access Identifier", RFC 4282, 1250 DOI 10.17487/RFC4282, December 2005, 1251 . 1253 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1254 (TLS) Protocol Version 1.1", RFC 4346, 1255 DOI 10.17487/RFC4346, April 2006, 1256 . 1258 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1259 and T. Wright, "Transport Layer Security (TLS) 1260 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 1261 . 1263 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 1264 Flexible Authentication via Secure Tunneling Extensible 1265 Authentication Protocol Method (EAP-FAST)", RFC 4851, 1266 DOI 10.17487/RFC4851, May 2007, 1267 . 1269 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1270 "Transport Layer Security (TLS) Session Resumption without 1271 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1272 January 2008, . 1274 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1275 and A. Yegin, "Protocol for Carrying Authentication for 1276 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1277 May 2008, . 1279 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1280 (TLS) Protocol Version 1.2", RFC 5246, 1281 DOI 10.17487/RFC5246, August 2008, 1282 . 1284 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1285 Authentication Protocol (EAP) Key Management Framework", 1286 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1287 . 1289 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 1290 Protocol Tunneled Transport Layer Security Authenticated 1291 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 1292 DOI 10.17487/RFC5281, August 2008, 1293 . 1295 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1296 Ed., "Diameter Base Protocol", RFC 6733, 1297 DOI 10.17487/RFC6733, October 2012, 1298 . 1300 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1301 "Tunnel Extensible Authentication Protocol (TEAP) Version 1302 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1303 . 1305 [RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., 1306 and D. Kroeselberg, "Extensions to the Emergency Services 1307 Architecture for Dealing With Unauthenticated and 1308 Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, 1309 December 2014, . 1311 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1312 Known Attacks on Transport Layer Security (TLS) and 1313 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1314 February 2015, . 1316 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1317 "Recommendations for Secure Use of Transport Layer 1318 Security (TLS) and Datagram Transport Layer Security 1319 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1320 2015, . 1322 [TS.33.501] 1323 3GPP, "Security architecture and procedures for 5G 1324 System", 3GPP TS 33.501 16.1.0, December 2019. 1326 Appendix A. Updated references 1328 All the following references in [RFC5216] are updated as specified 1329 below when EAP-TLS is used with TLS 1.3 or higher. 1331 All references to [RFC2560] are updated with [RFC6960]. 1333 All references to [RFC3280] are updated with [RFC5280]. 1335 All references to [RFC4282] are updated with [RFC7542]. 1337 Acknowledgments 1339 The authors want to thank Bernard Aboba, Jari Arkko, Alan DeKok, Ari 1340 Keraenen, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, and 1341 Vesa Torvinen for comments and suggestions on the draft. 1343 Contributors 1345 Alan DeKok, FreeRADIUS 1347 Authors' Addresses 1349 John Preuss Mattsson 1350 Ericsson 1351 Stockholm 164 40 1352 Sweden 1354 Email: john.mattsson@ericsson.com 1356 Mohit Sethi 1357 Ericsson 1358 Jorvas 02420 1359 Finland 1361 Email: mohit@piuha.net