idnits 2.17.1 draft-ietf-emu-eap-tls13-13.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 (November 19, 2020) is 1254 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 834 -- Looks like a reference, but probably isn't: '2' on line 838 -- Looks like a reference, but probably isn't: '3' on line 845 -- Looks like a reference, but probably isn't: '4' on line 850 == Outdated reference: A later version (-08) exists of draft-ietf-emu-eaptlscert-07 == Outdated reference: A later version (-09) exists of draft-ietf-tls-md5-sha1-deprecate-04 == Outdated reference: A later version (-12) exists of draft-ietf-tls-oldversions-deprecate-09 -- 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 (~~), 4 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 November 19, 2020 6 Expires: May 23, 2021 8 Using EAP-TLS with TLS 1.3 9 draft-ietf-emu-eap-tls13-13 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 May 23, 2021. 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 . . . . . . . . . . . . . . . . . . . . . . 15 72 2.4. Parameter Negotiation and Compliance Requirements . . . . 16 73 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 17 74 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 18 75 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 19 78 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . 25 86 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 25 87 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 6.1. Normative References . . . . . . . . . . . . . . . . . . 25 89 6.2. Informative references . . . . . . . . . . . . . . . . . 26 90 Appendix A. Updated references . . . . . . . . . . . . . . . . . 30 91 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30 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]. The term EAP-TLS peer is 154 used for the entity acting as EAP peer and TLS client. The term EAP- 155 TLS server is used for the entity acting as EAP server and TLS 156 server. 158 2. Protocol Overview 160 2.1. Overview of the EAP-TLS Conversation 162 This section updates Section 2.1 of [RFC5216]. 164 TLS 1.3 changes both the message flow and the handshake messages 165 compared to earlier versions of TLS. Therefore, much of Section 2.1 166 of [RFC5216] does not apply for TLS 1.3 (or higher). 168 After receiving an EAP-Request packet with EAP-Type=EAP-TLS as 169 described in [RFC5216] the conversation will continue with the TLS 170 handshake protocol encapsulated in the data fields of EAP-Response 171 and EAP-Request packets. When EAP-TLS is used with TLS version 1.3 172 or higher, the formatting and processing of the TLS handshake SHALL 173 be done as specified in that version of TLS. This document only 174 lists additional and different requirements, restrictions, and 175 processing compared to [RFC8446] and [RFC5216]. 177 2.1.1. Mutual Authentication 179 This section updates Section 2.1.1 of [RFC5216]. 181 The EAP-TLS server MUST authenticate with a certificate and SHOULD 182 require the EAP-TLS peer to authenticate with a certificate. 183 Certificates can be of any type supported by TLS including raw public 184 keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except 185 for resumption. SessionID is deprecated in TLS 1.3 and the EAP-TLS 186 server SHALL ignore the legacy_session_id field if TLS 1.3 is 187 negotiated. TLS 1.3 introduced early application data which is not 188 used in EAP-TLS. A EAP-TLS server which receives an "early_data" 189 extension MUST ignore the extension or respond with a 190 HelloRetryRequest as described in Section 4.2.10 of [RFC8446]. 191 Resumption is handled as described in Section 2.1.3. The EAP-TLS 192 server commits to not send any more handshake messages by sending a 193 Commitment Message (an encrypted TLS record with the application data 194 0x00), see Section 2.5. After the EAP-TLS server has recieved a EAP- 195 Response to the EAP-Request containing the Commitment Message, the 196 EAP-TLS server sends EAP-Success. 198 In the case where EAP-TLS with mutual authentication is successful 199 (and neither HelloRetryRequest nor Post-Handshake messages are sent) 200 the conversation will appear as shown in Figure 1. 202 EAP-TLS Peer EAP-TLS Server 204 EAP-Request/ 205 <-------- Identity 206 EAP-Response/ 207 Identity (Privacy-Friendly) --------> 208 EAP-Request/ 209 EAP-Type=EAP-TLS 210 <-------- (TLS Start) 211 EAP-Response/ 212 EAP-Type=EAP-TLS 213 (TLS ClientHello) --------> 214 EAP-Request/ 215 EAP-Type=EAP-TLS 216 (TLS ServerHello, 217 TLS EncryptedExtensions, 218 TLS CertificateRequest, 219 TLS Certificate, 220 TLS CertificateVerify, 221 TLS Finished, 222 <-------- Commitment Message) 223 EAP-Response/ 224 EAP-Type=EAP-TLS 225 (TLS Certificate, 226 TLS CertificateVerify, 227 TLS Finished) --------> 228 <-------- EAP-Success 230 Figure 1: EAP-TLS mutual authentication 232 2.1.2. Ticket Establishment 234 This is a new section when compared to [RFC5216]. 236 To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS 237 server MUST send a NewSessionTicket message (containing a PSK and 238 other parameters) in the initial authentication. The 239 NewSessionTicket is sent after the EAP-TLS server has received the 240 Finished message in the initial authentication. The NewSessionTicket 241 message MUST NOT include an "early_data" extension. 243 In the case where EAP-TLS with mutual authentication and ticket 244 establishment is successful, the conversation will appear as shown in 245 Figure 2. 247 EAP-TLS Peer EAP-TLS Server 249 EAP-Request/ 250 <-------- Identity 251 EAP-Response/ 252 Identity (Privacy-Friendly) --------> 253 EAP-Request/ 254 EAP-Type=EAP-TLS 255 <-------- (TLS Start) 256 EAP-Response/ 257 EAP-Type=EAP-TLS 258 (TLS ClientHello) --------> 259 EAP-Request/ 260 EAP-Type=EAP-TLS 261 (TLS ServerHello, 262 TLS EncryptedExtensions, 263 TLS CertificateRequest, 264 TLS Certificate, 265 TLS CertificateVerify, 266 <-------- TLS Finished) 267 EAP-Response/ 268 EAP-Type=EAP-TLS 269 (TLS Certificate, 270 TLS CertificateVerify, 271 TLS Finished) --------> 272 EAP-Request/ 273 EAP-Type=EAP-TLS 274 (TLS NewSessionTicket, 275 <-------- Commitment Message) 276 EAP-Response/ 277 EAP-Type=EAP-TLS --------> 278 <-------- EAP-Success 280 Figure 2: EAP-TLS ticket establishment 282 2.1.3. Resumption 284 This section updates Section 2.1.2 of [RFC5216]. 286 TLS 1.3 replaces the session resumption mechanisms in earlier 287 versions of TLS with a new PSK exchange. When EAP-TLS is used with 288 TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism 289 compatible with that version of TLS. 291 For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If 292 the client has received a NewSessionTicket message from the EAP-TLS 293 server, the client can use the PSK identity received in the ticket to 294 negotiate the use of the associated PSK. If the EAP-TLS server 295 accepts it, then the security context of the new connection is tied 296 to the original connection and the key derived from the initial 297 handshake is used to bootstrap the cryptographic state instead of a 298 full handshake. It is left up to the EAP-TLS peer whether to use 299 resumption, but it is RECOMMENDED that the EAP-TLS server accept 300 resumption as long as the ticket is valid. However, the EAP-TLS 301 server MAY choose to require a full authentication. EAP-TLS peers 302 and EAP-TLS servers SHOULD follow the client tracking preventions in 303 Appendix C.4 of [RFC8446]. 305 It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the 306 same realm in the resumption and the original full authentication. 307 This requirement allows EAP packets to be routable to the same 308 destination as the original full authentication. If this 309 recommendation is not followed, resumption is likely to be 310 impossible. When NAI reuse can be done without privacy implications, 311 it is RECOMMENDED to use the same anonymous NAI in the resumption, as 312 was used in the original full authentication. E.g. the NAI @realm 313 can safely be reused, while the NAI ZmxleG8=@realm cannot. The TLS 314 PSK identity is typically derived by the TLS implementation and may 315 be an opaque blob without a routable realm. The TLS PSK identity is 316 therefore in general unsuitable for deriving a NAI to use in the 317 Identity Response. 319 A subsequent authentication using resumption, where both sides 320 authenticate successfully (without the issuance of more resumption 321 tickets) is shown in Figure 3. 323 EAP-TLS Peer EAP-TLS Server 325 EAP-Request/ 326 <-------- Identity 327 EAP-Response/ 328 Identity (Privacy-Friendly) --------> 329 EAP-Request/ 330 EAP-Type=EAP-TLS 331 <-------- (TLS Start) 332 EAP-Response/ 333 EAP-Type=EAP-TLS 334 (TLS ClientHello) --------> 335 EAP-Request/ 336 EAP-Type=EAP-TLS 337 (TLS ServerHello, 338 TLS EncryptedExtensions, 339 TLS Finished, 340 <-------- Commitment Message) 341 EAP-Response/ 342 EAP-Type=EAP-TLS 343 (TLS Finished) --------> 344 <-------- EAP-Success 346 Figure 3: EAP-TLS resumption 348 As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD 349 supply a "key_share" extension when attempting resumption, which 350 allows the EAP-TLS server to potentially decline resumption and fall 351 back to a full handshake. If the EAP-TLS peer did not supply a 352 "key_share" extension when attempting resumption, the EAP-TLS server 353 needs to reject the ClientHello and the EAP-TLS peer needs to restart 354 a full handshake. The message flow in this case is given by Figure 4 355 followed by Figure 1. 357 Also during resumption, the EAP-TLS server can respond with a Hello 358 Retry Request (see Section 2.1.6) or issue a new ticket (see 359 Section 2.1.2) 361 2.1.4. Termination 363 This section updates Section 2.1.3 of [RFC5216]. 365 TLS 1.3 changes both the message flow and the handshake messages 366 compared to earlier versions of TLS. Therefore, some normative text 367 in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3 or higher. 368 The two paragraphs below replaces the corresponding paragraphs in 369 Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or 370 higher. The other paragraphs in Section 2.1.3 of [RFC5216] still 371 apply with the exception that SessionID is deprecated. 373 If the EAP-TLS peer authenticates successfully, the EAP-TLS server 374 MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing 375 TLS records conforming to the version of TLS used. The message 376 flow ends with the EAP-TLS server sending an EAP-Success message. 378 If the EAP-TLS server authenticates successfully, the EAP-TLS peer 379 MUST send an EAP-Response message with EAP-Type=EAP-TLS containing 380 TLS records conforming to the version of TLS used. 382 Figures 4, 5, and 6 illustrate message flows in several cases where 383 the EAP-TLS peer or EAP-TLS server sends a TLS fatal alert message. 384 TLS warning alerts generally mean that the connection can continue 385 normally and does not change the message flow. Note that the party 386 receiving a TLS warning alert may choose to terminate the connection 387 by sending a TLS fatal alert, which may add an extra round-trip, see 388 [RFC8446]. 390 In the case where the EAP-TLS server rejects the ClientHello with a 391 fatal error, the conversation will appear as shown in Figure 4. The 392 EAP-TLS server can also partly reject the ClientHello with a 393 HelloRetryRequest, see Section 2.1.6. 395 EAP-TLS Peer EAP-TLS Server 397 EAP-Request/ 398 <-------- Identity 399 EAP-Response/ 400 Identity (Privacy-Friendly) --------> 401 EAP-Request/ 402 EAP-Type=EAP-TLS 403 <-------- (TLS Start) 404 EAP-Response/ 405 EAP-Type=EAP-TLS 406 (TLS ClientHello) --------> 407 EAP-Request/ 408 EAP-Type=EAP-TLS 409 <-------- (TLS Fatal Alert) 410 EAP-Response/ 411 EAP-Type=EAP-TLS --------> 412 <-------- EAP-Failure 414 Figure 4: EAP-TLS server rejection of ClientHello 416 In the case where EAP-TLS server authentication is unsuccessful, the 417 conversation will appear as shown in Figure 5. 419 EAP-TLS Peer EAP-TLS Server 421 EAP-Request/ 422 <-------- Identity 423 EAP-Response/ 424 Identity (Privacy-Friendly) --------> 425 EAP-Request/ 426 EAP-Type=EAP-TLS 427 <-------- (TLS Start) 428 EAP-Response/ 429 EAP-Type=EAP-TLS 430 (TLS ClientHello) --------> 431 EAP-Request/ 432 EAP-Type=EAP-TLS 433 (TLS ServerHello, 434 TLS EncryptedExtensions, 435 TLS CertificateRequest, 436 TLS Certificate, 437 TLS CertificateVerify, 438 TLS Finished, 439 <-------- Commitment Message) 440 EAP-Response/ 441 EAP-Type=EAP-TLS 442 (TLS Fatal Alert) 443 --------> 444 <-------- EAP-Failure 446 Figure 5: EAP-TLS unsuccessful EAP-TLS server authentication 448 In the case where the EAP-TLS server authenticates to the EAP-TLS 449 peer successfully, but the EAP-TLS peer fails to authenticate to the 450 EAP-TLS server, the conversation will appear as shown in Figure 6. 452 EAP-TLS Peer EAP-TLS Server 454 EAP-Request/ 455 <-------- Identity 456 EAP-Response/ 457 Identity (Privacy-Friendly) --------> 459 EAP-Request/ 460 EAP-Type=EAP-TLS 461 <-------- (TLS Start) 462 EAP-Response/ 463 EAP-Type=EAP-TLS 464 (TLS ClientHello) --------> 465 EAP-Request/ 466 EAP-Type=EAP-TLS 467 (TLS ServerHello, 468 TLS EncryptedExtensions, 469 TLS CertificateRequest, 470 TLS Certificate, 471 TLS CertificateVerify, 472 TLS Finished, 473 <-------- Commitment Message) 474 EAP-Response/ 475 EAP-Type=EAP-TLS 476 (TLS Certificate, 477 TLS CertificateVerify, 478 TLS Finished) --------> 479 EAP-Request/ 480 EAP-Type=EAP-TLS 481 <-------- (TLS Fatal Alert) 482 EAP-Response/ 483 EAP-Type=EAP-TLS --------> 484 <-------- EAP-Failure 486 Figure 6: EAP-TLS unsuccessful client authentication 488 2.1.5. No Peer Authentication 490 This is a new section when compared to [RFC5216]. 492 In the case where EAP-TLS is used without peer authentication (e.g., 493 emergency services, as described in [RFC7406]) the conversation will 494 appear as shown in Figure 7. 496 EAP-TLS Peer EAP-TLS Server 498 EAP-Request/ 499 <-------- Identity 500 EAP-Response/ 501 Identity (Privacy-Friendly) --------> 502 EAP-Request/ 503 EAP-Type=EAP-TLS 504 <-------- (TLS Start) 505 EAP-Response/ 506 EAP-Type=EAP-TLS 507 (TLS ClientHello) --------> 508 EAP-Request/ 509 EAP-Type=EAP-TLS 510 (TLS ServerHello, 511 TLS EncryptedExtensions, 512 TLS Certificate, 513 TLS CertificateVerify, 514 TLS Finished, 515 <-------- Commitment Message) 516 EAP-Response/ 517 EAP-Type=EAP-TLS 518 (TLS Finished) --------> 519 <-------- EAP-Success 521 Figure 7: EAP-TLS without peer authentication 523 2.1.6. Hello Retry Request 525 This is a new section when compared to [RFC5216]. 527 As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a 528 HelloRetryRequest message in response to a ClientHello if the EAP-TLS 529 server finds an acceptable set of parameters but the initial 530 ClientHello does not contain all the needed information to continue 531 the handshake. One use case is if the EAP-TLS server does not 532 support the groups in the "key_share" extension, but supports one of 533 the groups in the "supported_groups" extension. In this case the 534 client should send a new ClientHello with a "key_share" that the EAP- 535 TLS server supports. 537 The case of a successful EAP-TLS mutual authentication after the EAP- 538 TLS server has sent a HelloRetryRequest message is shown in Figure 8. 539 Note the extra round-trip as a result of the HelloRetryRequest. 541 EAP-TLS Peer EAP-TLS Server 543 EAP-Request/ 544 <-------- Identity 545 EAP-Response/ 546 Identity (Privacy-Friendly) --------> 547 EAP-Request/ 548 EAP-Type=EAP-TLS 549 <-------- (TLS Start) 550 EAP-Response/ 551 EAP-Type=EAP-TLS 552 (TLS ClientHello) --------> 553 EAP-Request/ 554 EAP-Type=EAP-TLS 555 (TLS HelloRetryRequest) 556 <-------- 557 EAP-Response/ 558 EAP-Type=EAP-TLS 559 (TLS ClientHello) --------> 560 EAP-Request/ 561 EAP-Type=EAP-TLS 562 (TLS ServerHello, 563 TLS EncryptedExtensions, 564 TLS Certificate, 565 TLS CertificateVerify, 566 TLS Finished, 567 <-------- Commitment Message) 568 EAP-Response/ 569 EAP-Type=EAP-TLS 570 (TLS Certificate, 571 TLS CertificateVerify, 572 TLS Finished) --------> 573 <-------- EAP-Success 575 Figure 8: EAP-TLS with Hello Retry Request 577 2.1.7. Identity 579 This is a new section when compared to [RFC5216]. 581 It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity 582 Response as such identities are routable and privacy-friendly. While 583 opaque blobs are allowed by [RFC3748], such identities are NOT 584 RECOMMENDED as they are not routable and should only be considered in 585 local deployments where the EAP-TLS peer, EAP authenticator, and EAP- 586 TLS server all belong to the same network. Many client certificates 587 contains an identity such as an email address, which is already in 588 NAI format. When the client certificate contains a NAI as subject 589 name or alternative subject name, an anonymous NAI SHOULD be derived 590 from the NAI in the certificate, see Section 2.1.8. More details on 591 identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8. 593 2.1.8. Privacy 595 This section updates Section 2.1.4 of [RFC5216]. 597 TLS 1.3 significantly improves privacy when compared to earlier 598 versions of TLS by forbidding cipher suites without confidentiality 599 and encrypting large parts of the TLS handshake including the 600 certificate messages. 602 EAP-TLS peer and server implementations supporting TLS 1.3 or higher 603 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 604 in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its 605 username in cleartext in the Identity Response. Following [RFC7542], 606 it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but 607 other constructions such as a fixed username (e.g. anonymous@realm) 608 or an encrypted username (e.g. YmVuZGVy@realm) are allowed. Note 609 that the NAI MUST be a UTF-8 string as defined by the grammar in 610 Section 2.2 of [RFC7542]. 612 As the certificate messages in TLS 1.3 are encrypted, there is no 613 need to send an empty certificate_list and perform a second handshake 614 for privacy (as needed by EAP-TLS with earlier versions of TLS). 615 When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer 616 and EAP-TLS server SHALL follow the processing specified by the used 617 version of TLS. For TLS 1.3 this means that the EAP-TLS peer only 618 sends an empty certificate_list if it does not have an appropriate 619 certificate to send, and the EAP-TLS server MAY treat an empty 620 certificate_list as a terminal condition. 622 EAP-TLS with TLS 1.3 is always used with privacy. This does not add 623 any extra round-trips and the message flow with privacy is just the 624 normal message flow as shown in Figure 1. 626 2.1.9. Fragmentation 628 This section updates Section 2.1.5 of [RFC5216]. 630 Including ContentType and ProtocolVersion a single TLS record may be 631 up to 16387 octets in length. EAP-TLS fragmentation support is 632 provided through addition of a flags octet within the EAP-Response 633 and EAP-Request packets, as well as a TLS Message Length field of 634 four octets. Implementations MUST NOT set the L bit in unfragmented 635 messages, but MUST accept unfragmented messages with and without the 636 L bit set. 638 Some EAP implementations and access networks may limit the number of 639 EAP packet exchanges that can be handled. To avoid fragmentation, it 640 is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and 641 trust anchor certificates small and the length of the certificate 642 chains short. In addition, it is RECOMMENDED to use mechanisms that 643 reduce the sizes of Certificate messages. For a detailed discussion 644 on reducing message sizes to prevent fragmentation, see 645 [I-D.ietf-emu-eaptlscert]. 647 2.2. Identity Verification 649 This section updates Section 2.2 of [RFC5216]. 651 The identity provided in the EAP-Response/Identity is not 652 authenticated by EAP-TLS. Unauthenticated information SHALL NOT be 653 used for accounting purposes or to give authorization. The 654 authenticator and the EAP-TLS server MAY examine the identity 655 presented in EAP-Response/Identity for purposes such as routing and 656 EAP method selection. EAP-TLS servers MAY reject conversations if 657 the identity does not match their policy. Note that this also 658 applies to resumption, see Sections 2.1.3, 5.6, and 5.7. 660 2.3. Key Hierarchy 662 This section updates Section 2.3 of [RFC5216]. 664 TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier 665 versions of TLS with HKDF and completely changes the Key Schedule. 666 The key hierarchies shown in Section 2.3 of [RFC5216] are therefore 667 not correct when EAP-TLS is used with TLS version 1.3 or higher. For 668 TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446]. 670 When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, 671 IV, and Method-Id SHALL be derived from the exporter_master_secret 672 using the TLS exporter interface [RFC5705] (for TLS 1.3 this is 673 defined in Section 7.5 of [RFC8446]). 675 Type-Code = 0x0D 676 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 677 Type-Code, 128) 678 IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", 679 Type-Code, 64) 680 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 681 Type-Code, 64) 682 Session-Id = Type-Code || Method-Id 683 All other parameters such as MSK and EMSK are derived in the same 684 manner as with EAP-TLS [RFC5216], Section 2.3. The definitions are 685 repeated below for simplicity: 687 MSK = Key_Material(0, 63) 688 EMSK = Key_Material(64, 127) 689 Enc-RECV-Key = MSK(0, 31) 690 Enc-SEND-Key = MSK(32, 63) 691 RECV-IV = IV(0, 31) 692 SEND-IV = IV(32, 63) 694 The use of these keys is specific to the lower layer, as described 695 [RFC5247]. 697 Note that the key derivation MUST use the length values given above. 698 While in TLS 1.2 and earlier it was possible to truncate the output 699 by requesting less data from the TLS-Exporter function, this practice 700 is not possible with TLS 1.3. If an implementation intends to use 701 only a part of the output of the TLS-Exporter function, then it MUST 702 ask for the full output and then only use the desired part. Failure 703 to do so will result in incorrect values being calculated for the 704 above keying material. 706 By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation 707 without having to extract the Master Secret, ClientHello.random, and 708 ServerHello.random in a non-standard way. 710 2.4. Parameter Negotiation and Compliance Requirements 712 This section updates Section 2.4 of [RFC5216]. 714 TLS 1.3 cipher suites are defined differently than in earlier 715 versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites 716 discussed in Section 2.4 of [RFC5216] can therefore not be used when 717 EAP-TLS is used with TLS version 1.3 or higher. 719 When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS 720 peers and EAP-TLS servers MUST comply with the compliance 721 requirements (mandatory-to-implement cipher suites, signature 722 algorithms, key exchange algorithms, extensions, etc.) for the TLS 723 version used. For TLS 1.3 the compliance requirements are defined in 724 Section 9 of [RFC8446]. 726 While EAP-TLS does not protect any application data except for the 727 Commitment Message, the negotiated cipher suites and algorithms MAY 728 be used to secure data as done in other TLS-based EAP methods. 730 2.5. EAP State Machines 732 This is a new section when compared to [RFC5216]. 734 TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- 735 Handshake messages use the handshake content type and can be sent 736 after the main handshake. One such Post-Handshake message is 737 NewSessionTicket. The NewSessionTicket can be used for resumption. 738 After sending TLS Finished, the EAP-TLS server may send any number of 739 Post-Handshake messages in separate EAP-Requests. To decrease the 740 uncertainty for the EAP-TLS peer, the following procedure MUST be 741 followed: 743 When an EAP-TLS server has sent its last handshake message (Finished 744 or a Post-Handshake), it commits to not sending any more handshake 745 messages by sending a Commitment Message. The Commitment Message is 746 an encrypted TLS record with application data 0x00 (i.e. a TLS record 747 with TLSPlaintext.type = application_data, TLSPlaintext.length = 1, 748 and TLSPlaintext.fragment = 0x00). Note that the length of the 749 plaintext is greater than the corresponding TLSPlaintext.length due 750 to the inclusion of TLSInnerPlaintext.type and any padding supplied 751 by the sender. EAP-TLS server implementations MUST set 752 TLSPlaintext.fragment to 0x00, but EAP-TLS peer implementations MUST 753 accept any application data as a Commitment Message from the EAP-TLS 754 server to not send any more handshake messages. The Commitment 755 Message may be sent in the same EAP-Request as the last handshake 756 record or in a separate EAP-Request. Sending the Commitment Message 757 in a separate EAP-Request adds an additional round-trip, but may be 758 necessary in TLS implementations that only implement a subset of TLS 759 1.3. In the case where the EAP-TLS server sends the Commitment 760 Message in a separate EAP-Request, the conversation will appear as 761 shown in Figure 9. After sending the Commitment Message, the EAP-TLS 762 server may only send an EAP-Success, an EAP-Failure, or an EAP- 763 Request with a TLS Alert Message. 765 EAP-TLS Peer EAP-TLS Server 766 EAP-Request/ 767 <-------- Identity 768 EAP-Response/ 769 Identity (Privacy-Friendly) --------> 770 EAP-Request/ 771 EAP-Type=EAP-TLS 772 <-------- (TLS Start) 773 EAP-Response/ 774 EAP-Type=EAP-TLS 775 (TLS ClientHello) --------> 776 EAP-Request/ 777 EAP-Type=EAP-TLS 778 (TLS ServerHello, 779 TLS EncryptedExtensions, 780 TLS CertificateRequest, 781 TLS Certificate, 782 TLS CertificateVerify, 783 <-------- TLS Finished) 784 EAP-Response/ 785 EAP-Type=EAP-TLS 786 (TLS Certificate, 787 TLS CertificateVerify, 788 TLS Finished) --------> 789 EAP-Request/ 790 EAP-Type=EAP-TLS 791 <-------- Commitment Message) 792 EAP-Response/ 793 EAP-Type=EAP-TLS --------> 794 <-------- EAP-Success 796 Figure 9: Commit in separate EAP-Request 798 3. Detailed Description of the EAP-TLS Protocol 800 No updates to Section 3 of [RFC5216]. 802 4. IANA considerations 804 This section provides guidance to the Internet Assigned Numbers 805 Authority (IANA) regarding registration of values related to the EAP- 806 TLS 1.3 protocol in accordance with [RFC8126]. 808 This memo requires IANA to add the following labels to the TLS 809 Exporter Label Registry defined by [RFC5705]. These labels are used 810 in derivation of Key_Material, IV and Method-Id as defined in 811 Section 2.3: 813 +-------------------------------+---------+-------------+------+ 814 | Value | DTLS-OK | Recommended | Note | 815 +-------------------------------+---------+-------------+------+ 816 | EXPORTER_EAP_TLS_Key_Material | N | Y | | 817 | | | | | 818 | EXPORTER_EAP_TLS_IV | N | Y | | 819 | | | | | 820 | EXPORTER_EAP_TLS_Method-Id | N | Y | | 821 +-------------------------------+---------+-------------+------+ 823 Table 1: TLS Exporter Label Registry 825 5. Security Considerations 827 5.1. Security Claims 829 Using EAP-TLS with TLS 1.3 does not change the security claims for 830 EAP-TLS as given in Section 5.1 of [RFC5216]. However, it 831 strengthens several of the claims as described in the following 832 updates to the notes given in Section 5.1 of [RFC5216]. 834 [1] Mutual authentication: By mandating revocation checking of 835 certificates, the authentication in EAP-TLS with TLS 1.3 is stronger 836 as authentication with revoked certificates will always fail. 838 [2] Confidentiality: The TLS 1.3 handshake offers much better 839 confidentiality than earlier versions of TLS by mandating cipher 840 suites with confidentiality and encrypting certificates and some of 841 the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the 842 use of privacy is mandatory and does not cause any additional round- 843 trips. 845 [3] Key strength: TLS 1.3 forbids all algorithms with known 846 weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 847 only supports cryptographic algorithms offering at least 112-bit 848 security, see [RFC8446]. 850 [4] Cryptographic Negotiation: TLS 1.3 increases the number of 851 cryptographic parameters that are negotiated in the handshake. When 852 EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic 853 negotiation of AEAD algorithm, HKDF hash algorithm, key exchange 854 groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. 856 5.2. Peer and Server Identities 858 No updates to section 5.2 of [RFC5216]. 860 5.3. Certificate Validation 862 No updates to section 5.3 of [RFC5216]. 864 5.4. Certificate Revocation 866 This section updates Section 5.4 of [RFC5216]. 868 While certificates may have long validity periods, there are a number 869 of reasons (e.g. key compromise, CA compromise, privilege withdrawn, 870 etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have 871 to be revoked before their expiry date. Revocation of the EAP-TLS 872 server's certificate is complicated by the fact that the EAP-TLS peer 873 may not have Internet connectivity until authentication completes. 875 When EAP-TLS is used with TLS 1.3, the revocation status of all the 876 certificates in the certificate chains MUST be checked. 878 EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status 879 Requests (OCSP stapling) as specified in [RFC6066] and 880 Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers 881 and EAP-TLS servers use OCSP stapling for verifying the status of the 882 EAP-TLS server's certificate chain. When an EAP-TLS peer uses 883 Certificate Status Requests to check the revocation status of the 884 EAP-TLSserver's certificate chain it MUST treat a CertificateEntry 885 (except the trust anchor) without a valid CertificateStatus extension 886 as invalid and abort the handshake with an appropriate alert. The 887 OCSP status handling in TLS 1.3 is different from earlier versions of 888 TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP 889 information is carried in the CertificateEntry containing the 890 associated certificate instead of a separate CertificateStatus 891 message as in [RFC4366]. This enables sending OCSP information for 892 all certificates in the certificate chain (except the trust anchor). 894 To enable revocation checking in situations where EAP-TLS peers do 895 not implement or use OCSP stapling, and where network connectivity is 896 not available prior to authentication completion, EAP--TLS peer 897 implementations MUST also support checking for certificate revocation 898 after authentication completes and network connectivity is available, 899 and they SHOULD utilize this capability by default. 901 5.5. Packet Modification Attacks 903 No updates to Section 5.5 of [RFC5216]. 905 5.6. Authorization 907 This is a new section when compared to [RFC5216]. The guidance in 908 this section is relevant for EAP-TLS in general (regardless of the 909 underlying TLS version used). 911 EAP-TLS is typically encapsulated in other protocols, such as PPP 912 [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. 913 The encapsulating protocols can also provide additional, non-EAP 914 information to an EAP-TLS server. This information can include, but 915 is not limited to, information about the authenticator, information 916 about the EAP-TLS peer, or information about the protocol layers 917 above or below EAP (MAC addresses, IP addresses, port numbers, WiFi 918 SSID, etc.). EAP-TLS Servers implementing EAP-TLS inside those 919 protocols can make policy decisions and enforce authorization based 920 on a combination of information from the EAP-TLS exchange and non-EAP 921 information. 923 As noted in Section 2.2, the identity presented in EAP-Response/ 924 Identity is not authenticated by EAP-TLS and is therefore trivial for 925 an attacker to forge, modify, or replay. Authorization and 926 accounting MUST be based on authenticated information such as 927 information in the certificate or the PSK identity and cached data 928 provisioned for resumption as described in Section 5.7. Note that 929 the requirements for Network Access Identifiers (NAIs) specified in 930 Section 4 of [RFC7542] still apply and MUST be followed. 932 EAP-TLS servers MAY reject conversations based on non-EAP information 933 provided by the encapsulating protocol, for example, if the MAC 934 address of the authenticator does not match the expected policy. 936 5.7. Resumption 938 This is a new section when compared to [RFC5216]. The guidance in 939 this section is relevant for EAP-TLS in general (regardless of the 940 underlying TLS version used). 942 There are a number of security issues related to resumption that are 943 not described in [RFC5216]. The problems, guidelines, and 944 requirements in this section therefore applies to all version of TLS. 946 When resumption occurs, it is based on cached information at the TLS 947 layer. To perform resumption in a secure way, the EAP-TLS peer and 948 EAP-TLS server need to be able to securely retrieve authorization 949 information such as certificate chains from the initial full 950 handshake. We use the term "cached data" to describe such 951 information. Authorization during resumption MUST be based on such 952 cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh 953 revocation checks on the cached certificate data. Any security 954 policies for authorization MUST be followed also for resumption. The 955 certificates may have been revoked since the initial full handshake 956 and the authorizations of the other party may have been reduced. If 957 the cached revocation is not sufficiently current, the EAP-TLS peer 958 or EAP-TLS server MAY force a full TLS handshake. 960 There are two ways to retrieve the cached data from the original full 961 handshake. The first method is that the EAP-TLS server and client 962 cache the information locally. The cached information is identified 963 by an identifier. For TLS versions before 1.3, the identifier can be 964 the session ID, for TLS 1.3, the identifier is the PSK identity. The 965 second method for retrieving cached information is via [RFC5077] or 966 [RFC8446], where the EAP-TLS server avoids storing information 967 locally and instead encapsulates the information into a ticket or PSK 968 which is sent to the client for storage. This ticket or PSK is 969 encrypted using a key that only the EAP-TLS server knows. Note that 970 the client still needs to cache the original handshake information 971 locally and will use the session ID or PSK identity to lookup this 972 information during resumption. However, the EAP-TLS server is able 973 to decrypt the ticket or PSK to obtain the original handshake 974 information. 976 If the EAP-TLS server or EAP client do not apply any authorization 977 policies, they MAY allow resumption where no cached data is 978 available. In all other cases, they MUST cache data during the 979 initial full authentication to enable resumption. The cached data 980 MUST be sufficient to make authorization decisions during resumption. 981 If cached data cannot be retrieved in a secure way, resumption MUST 982 NOT be done. 984 The above requirements also apply if the EAP-TLS server expects some 985 system to perform accounting for the session. Since accounting must 986 be tied to an authenticated identity, and resumption does not supply 987 such an identity, accounting is impossible without access to cached 988 data. Therefore systems which expect to perform accounting for the 989 session SHOULD cache an identifier which can be used in subsequent 990 accounting. 992 As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption 993 PSKs or tickets (and associated cached data) for longer than 7 days, 994 regardless of the PSK or ticket lifetime. The EAP-TLS peer MAY 995 delete them earlier based on local policy. The cached data MAY also 996 be removed on the EAP-TLS server or EAP-TLS peer if any certificate 997 in the certificate chain has been revoked or has expired. In all 998 such cases, resumption results in a full TLS handshake instead. 1000 Information from the EAP-TLS exchange (e.g. the identity provided in 1001 EAP-Response/Identity) as well as non-EAP information (e.g. IP 1002 addresses) may change between the initial full handshake and 1003 resumption. This change creates a "time-of-check time-of-use" 1004 (TOCTOU) security vulnerability. A malicious or compromised user 1005 could supply one set of data during the initial authentication, and a 1006 different set of data during resumption, potentially allowing them to 1007 obtain access that they should not have. 1009 If any authorization, accounting, or policy decisions were made with 1010 information that have changed between the initial full handshake and 1011 resumption, and if change may lead to a different decision, such 1012 decisions MUST be reevaluated. It is RECOMMENDED that authorization, 1013 accounting, and policy decisions are reevaluated based on the 1014 information given in the resumption. EAP-TLS servers MAY reject 1015 resumption where the information supplied during resumption does not 1016 match the information supplied during the original authentication. 1017 Where a good decision is unclear, EAP-TLS servers SHOULD reject the 1018 resumption. 1020 Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security 1021 considerations for resumption. 1023 5.8. Privacy Considerations 1025 This is a new section when compared to [RFC5216]. 1027 TLS 1.3 offers much better privacy than earlier versions of TLS as 1028 discussed in Section 2.1.8. In this section, we only discuss the 1029 privacy properties of EAP-TLS with TLS 1.3. For privacy properties 1030 of TLS 1.3 itself, see [RFC8446]. 1032 EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in 1033 EAP packets. Additionally, the EAP-TLS peer sends an identity in the 1034 first EAP-Response. The other fields in the EAP-TLS Request and the 1035 EAP-TLS Response packets do not contain any cleartext privacy 1036 sensitive information. 1038 Tracking of users by eavesdropping on identity responses or 1039 certificates is a well-known problem in many EAP methods. When EAP- 1040 TLS is used with TLS 1.3, all certificates are encrypted, and the 1041 username part of the identity response is always confidentiality 1042 protected (e.g. using anonymous NAIs). However, as with other EAP 1043 methods, even when privacy-friendly identifiers or EAP tunneling is 1044 used, the domain name (i.e. the realm) in the NAI is still typically 1045 visible. How much privacy sensitive information the domain name 1046 leaks is highly dependent on how many other users are using the same 1047 domain name in the particular access network. If all EAP-TLS peers 1048 have the same domain, no additional information is leaked. If a 1049 domain name is used by a small subset of the EAP-TLS peers, it may 1050 aid an attacker in tracking or identifying the user. 1052 Without padding, information about the size of the client certificate 1053 is leaked from the size of the EAP-TLS packets. The EAP-TLS packets 1054 sizes may therefore leak information that can be used to track or 1055 identify the user. If all client certificates have the same length, 1056 no information is leaked. EAP-TLS peers SHOULD use record padding, 1057 see Section 5.4 of [RFC8446] to reduce information leakage of 1058 certificate sizes. 1060 If anonymous NAIs are not used, the privacy-friendly identifiers need 1061 to be generated with care. The identities MUST be generated in a 1062 cryptographically secure way so that that it is computationally 1063 infeasible for an attacker to differentiate two identities belonging 1064 to the same user from two identities belonging to different users in 1065 the same realm. This can be achieved, for instance, by using random 1066 or pseudo-random usernames such as random byte strings or ciphertexts 1067 and only using the pseudo-random usernames a single time. Note that 1068 the privacy-friendly usernames also MUST NOT include substrings that 1069 can be used to relate the identity to a specific user. Similarly, 1070 privacy-friendly username SHOULD NOT be formed by a fixed mapping 1071 that stays the same across multiple different authentications. 1073 An EAP-TLS peer with a policy allowing communication with EAP-TLS 1074 servers supporting only TLS 1.2 without privacy and with a static RSA 1075 key exchange is vulnerable to disclosure of the EAP-TLS peer 1076 username. An active attacker can in this case make the EAP-TLS peer 1077 believe that an EAP-TLS server supporting TLS 1.3 only supports TLS 1078 1.2 without privacy. The attacker can simply impersonate the EAP-TLS 1079 server and negotiate TLS 1.2 with static RSA key exchange and send an 1080 TLS alert message when the EAP-TLS peer tries to use privacy by 1081 sending an empty certificate message. Since the attacker 1082 (impersonating the EAP-TLS server) does not provide a proof-of- 1083 possession of the private key until the Finished message when a 1084 static RSA key exchange is used, an EAP-TLS peer may inadvertently 1085 disclose its identity (username) to an attacker. Therefore, it is 1086 RECOMMENDED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and 1087 static RSA based cipher suites without privacy. This implies that an 1088 EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS 1089 server responds to an empty certificate message with a TLS alert 1090 message. 1092 5.9. Pervasive Monitoring 1094 This is a new section when compared to [RFC5216]. 1096 Pervasive monitoring refers to widespread surveillance of users. In 1097 the context EAP-TLS, pervasive monitoring attacks can target EAP-TLS 1098 peer devices for tracking them (and their users) as and when they 1099 join a network. By encrypting more information and by mandating the 1100 use of privacy, TLS 1.3 offers much better protection against 1101 pervasive monitoring. In addition to the privacy attacks discussed 1102 above, surveillance on a large scale may enable tracking of a user 1103 over a wider geographical area and across different access networks. 1104 Using information from EAP-TLS together with information gathered 1105 from other protocols increases the risk of identifying individual 1106 users. 1108 5.10. Discovered Vulnerabilities 1110 This is a new section when compared to [RFC5216]. 1112 Over the years, there have been several serious attacks on earlier 1113 versions of Transport Layer Security (TLS), including attacks on its 1114 most commonly used ciphers and modes of operation. [RFC7457] 1115 summarizes the attacks that were known at the time of publishing and 1116 [RFC7525] provides recommendations for improving the security of 1117 deployed services that use TLS. However, many of the attacks are 1118 less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and 1119 does not protect any application data. EAP-TLS implementations MUST 1120 mitigate known attacks. EAP-TLS implementations need to monitor and 1121 follow new EAP and TLS related security guidance and requirements 1122 such as [RFC8447], [I-D.ietf-tls-oldversions-deprecate], 1123 [I-D.ietf-tls-md5-sha1-deprecate]. 1125 6. References 1127 6.1. Normative References 1129 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1130 Requirement Levels", BCP 14, RFC 2119, 1131 DOI 10.17487/RFC2119, March 1997, 1132 . 1134 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1135 Levkowetz, Ed., "Extensible Authentication Protocol 1136 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1137 . 1139 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1140 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 1141 March 2008, . 1143 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1144 Housley, R., and W. Polk, "Internet X.509 Public Key 1145 Infrastructure Certificate and Certificate Revocation List 1146 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1147 . 1149 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1150 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1151 March 2010, . 1153 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1154 Extensions: Extension Definitions", RFC 6066, 1155 DOI 10.17487/RFC6066, January 2011, 1156 . 1158 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1159 Galperin, S., and C. Adams, "X.509 Internet Public Key 1160 Infrastructure Online Certificate Status Protocol - OCSP", 1161 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1162 . 1164 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1165 DOI 10.17487/RFC7542, May 2015, 1166 . 1168 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1169 Writing an IANA Considerations Section in RFCs", BCP 26, 1170 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1171 . 1173 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1174 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1175 May 2017, . 1177 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1178 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1179 . 1181 6.2. Informative references 1183 [I-D.ietf-emu-eaptlscert] 1184 Sethi, M., Mattsson, J., and S. Turner, "Handling Large 1185 Certificates and Long Certificate Chains in TLS-based EAP 1186 Methods", draft-ietf-emu-eaptlscert-07 (work in progress), 1187 November 2020. 1189 [I-D.ietf-tls-md5-sha1-deprecate] 1190 Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating 1191 MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf- 1192 tls-md5-sha1-deprecate-04 (work in progress), October 1193 2020. 1195 [I-D.ietf-tls-oldversions-deprecate] 1196 Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and 1197 TLSv1.1", draft-ietf-tls-oldversions-deprecate-09 (work in 1198 progress), November 2020. 1200 [IEEE-802.11] 1201 Institute of Electrical and Electronics Engineers, "IEEE 1202 Standard for Information technology--Telecommunications 1203 and information exchange between systems Local and 1204 metropolitan area networks--Specific requirements - Part 1205 11: Wireless LAN Medium Access Control (MAC) and Physical 1206 Layer (PHY) Specifications", IEEE Std 802.11-2016 1207 (Revision of IEEE Std 802.11-2012) , December 2016. 1209 [IEEE-802.1AE] 1210 Institute of Electrical and Electronics Engineers, "IEEE 1211 Standard for Local and metropolitan area networks -- Media 1212 Access Control (MAC) Security", IEEE Standard 1213 802.1AE-2018 , December 2018. 1215 [IEEE-802.1X] 1216 Institute of Electrical and Electronics Engineers, "IEEE 1217 Standard for Local and metropolitan area networks -- Port- 1218 Based Network Access Control", IEEE Standard 802.1X-2010 , 1219 February 2010. 1221 [MulteFire] 1222 MulteFire, "MulteFire Release 1.1 specification", 2019. 1224 [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible 1225 Authentication Protocol (PEAP)", 2018. 1227 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 1228 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 1229 . 1231 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1232 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1233 . 1235 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1236 Adams, "X.509 Internet Public Key Infrastructure Online 1237 Certificate Status Protocol - OCSP", RFC 2560, 1238 DOI 10.17487/RFC2560, June 1999, 1239 . 1241 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1242 "Remote Authentication Dial In User Service (RADIUS)", 1243 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1244 . 1246 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1247 X.509 Public Key Infrastructure Certificate and 1248 Certificate Revocation List (CRL) Profile", RFC 3280, 1249 DOI 10.17487/RFC3280, April 2002, 1250 . 1252 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1253 Network Access Identifier", RFC 4282, 1254 DOI 10.17487/RFC4282, December 2005, 1255 . 1257 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1258 (TLS) Protocol Version 1.1", RFC 4346, 1259 DOI 10.17487/RFC4346, April 2006, 1260 . 1262 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1263 and T. Wright, "Transport Layer Security (TLS) 1264 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 1265 . 1267 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 1268 Flexible Authentication via Secure Tunneling Extensible 1269 Authentication Protocol Method (EAP-FAST)", RFC 4851, 1270 DOI 10.17487/RFC4851, May 2007, 1271 . 1273 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1274 "Transport Layer Security (TLS) Session Resumption without 1275 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1276 January 2008, . 1278 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1279 and A. Yegin, "Protocol for Carrying Authentication for 1280 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1281 May 2008, . 1283 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1284 (TLS) Protocol Version 1.2", RFC 5246, 1285 DOI 10.17487/RFC5246, August 2008, 1286 . 1288 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1289 Authentication Protocol (EAP) Key Management Framework", 1290 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1291 . 1293 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 1294 Protocol Tunneled Transport Layer Security Authenticated 1295 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 1296 DOI 10.17487/RFC5281, August 2008, 1297 . 1299 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1300 Ed., "Diameter Base Protocol", RFC 6733, 1301 DOI 10.17487/RFC6733, October 2012, 1302 . 1304 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1305 "Tunnel Extensible Authentication Protocol (TEAP) Version 1306 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1307 . 1309 [RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., 1310 and D. Kroeselberg, "Extensions to the Emergency Services 1311 Architecture for Dealing With Unauthenticated and 1312 Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, 1313 December 2014, . 1315 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1316 Known Attacks on Transport Layer Security (TLS) and 1317 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1318 February 2015, . 1320 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1321 "Recommendations for Secure Use of Transport Layer 1322 Security (TLS) and Datagram Transport Layer Security 1323 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1324 2015, . 1326 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1327 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1328 . 1330 [TS.33.501] 1331 3GPP, "Security architecture and procedures for 5G 1332 System", 3GPP TS 33.501 16.4.0, September 2020. 1334 Appendix A. Updated references 1336 All the following references in [RFC5216] are updated as specified 1337 below when EAP-TLS is used with TLS 1.3 or higher. 1339 All references to [RFC2560] are updated with [RFC6960]. 1341 All references to [RFC3280] are updated with [RFC5280]. 1343 All references to [RFC4282] are updated with [RFC7542]. 1345 Acknowledgments 1347 The authors want to thank Bernard Aboba, Jari Arkko, Alan DeKok, Ari 1348 Keraenen, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, Terry 1349 Burton, Vesa Torvinen, and Hannes Tschofenig for comments and 1350 suggestions on the draft. 1352 Contributors 1354 Alan DeKok, FreeRADIUS 1356 Authors' Addresses 1358 John Preuss Mattsson 1359 Ericsson 1360 Stockholm 164 40 1361 Sweden 1363 Email: john.mattsson@ericsson.com 1365 Mohit Sethi 1366 Ericsson 1367 Jorvas 02420 1368 Finland 1370 Email: mohit@piuha.net