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