idnits 2.17.1 draft-ietf-emu-eap-tls13-03.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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 14, 2018) is 1989 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: '2' on line 630 -- Looks like a reference, but probably isn't: '3' on line 637 -- Looks like a reference, but probably isn't: '4' on line 642 == Outdated reference: A later version (-10) exists of draft-ietf-tls-certificate-compression-04 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 12 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 14, 2018 6 Expires: May 18, 2019 8 Using EAP-TLS with TLS 1.3 9 draft-ietf-emu-eap-tls13-03 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 provides significantly improved protection against 18 pervasive monitoring by mandating use of privacy. This document 19 updates RFC 5216. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 18, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements and Terminology . . . . . . . . . . . . . . 3 57 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 3 59 2.1.1. Base Case . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1.2. Resumption . . . . . . . . . . . . . . . . . . . . . 6 61 2.1.3. Termination . . . . . . . . . . . . . . . . . . . . . 8 62 2.1.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . 12 63 2.1.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 13 64 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 14 65 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 14 66 2.4. Parameter Negotiation and Compliance Requirements . . . . 14 67 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 15 68 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 15 69 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 16 72 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 16 73 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 16 74 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 16 75 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 17 76 5.6. Privacy Considerations . . . . . . . . . . . . . . . . . 17 77 5.7. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 18 78 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 6.1. Normative References . . . . . . . . . . . . . . . . . . 18 80 6.2. Informative references . . . . . . . . . . . . . . . . . 19 81 Appendix A. Updated references . . . . . . . . . . . . . . . . . 21 82 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 85 1. Introduction 87 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 88 provides a standard mechanism for support of multiple authentication 89 methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies 90 an EAP authentication method with certificate-based mutual 91 authentication and key derivation utilizing the TLS handshake 92 protocol for cryptographic algorithms and protocol version 93 negotiation, mutual authentication, and establishment of shared 94 secret keying material. EAP-TLS is widely supported for 95 authentication in IEEE 802.11 [IEEE-802.11] networks (Wi-Fi) using 96 IEEE 802.1X [IEEE-802.1X] and it's the default mechanism for 97 certificate based authentication in MulteFire [MulteFire] and 3GPP 5G 98 [TS.33.501] networks. EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] 99 and TLS 1.1 [RFC4346], but works perfectly also with TLS 1.2 100 [RFC5246]. 102 Weaknesses found in previous versions of TLS, as well as new 103 requirements for security, privacy, and reduced latency has led to 104 the development of TLS 1.3 [RFC8446], which in large parts is a 105 complete remodeling of the TLS handshake protocol including a 106 different message flow, different handshake messages, different key 107 schedule, different cipher suites, different resumption, and 108 different privacy protection. This means that significant parts of 109 the normative text in the previous EAP-TLS specification [RFC5216] 110 are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore, 111 aspects such as resumption, privacy handling, and key derivation need 112 to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). 114 This document defines how to use EAP-TLS with TLS 1.3 (or higher) and 115 does not change how EAP-TLS is used with older versions of TLS. 116 While this document updates EAP-TLS [RFC5216], it remains backwards 117 compatible with it and existing implementations of EAP-TLS. This 118 document only describes differences compared to [RFC5216]. 120 In addition to the improved security and privacy offered by TLS 1.3, 121 there are other significant benefits of using EAP-TLS with TLS 1.3. 122 Privacy is achieved without any additional round-trips, and TLS 1.3 123 introduces more possibilities to reduce fragmentation when compared 124 to earlier versions of TLS. 126 1.1. Requirements and Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 Readers are expected to be familiar with the terms and concepts used 135 in EAP-TLS [RFC5216] and TLS 1.3 [RFC8446]. 137 2. Protocol Overview 139 2.1. Overview of the EAP-TLS Conversation 140 2.1.1. Base Case 142 TLS 1.3 changes both the message flow and the handshake messages 143 compared to earlier versions of TLS. Therefore, much of Section 2.1 144 of RFC5216 [RFC5216] does not apply for TLS 1.3 (or higher). 146 After receiving an EAP-Request packet with EAP-Type=EAP-TLS as 147 described in [RFC5216] the conversation will continue with the TLS 148 handshake protocol encapsulated in the data fields of EAP-Response 149 and EAP-Request packets. When EAP-TLS is used with TLS version 1.3 150 or higher, the formatting and processing of the TLS handshake SHALL 151 be done as specified in that version of TLS. This document only 152 lists additional and different requirements, restrictions, and 153 processing compared to [RFC8446] and [RFC5216]. 155 The EAP server MUST authenticate with a certificate and SHOULD 156 require the EAP peer to authenticate with a certificate. 157 Certificates can be of any type supported by TLS including raw public 158 keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except 159 for resumption. SessionID is deprecated in TLS 1.3 and the EAP 160 server SHALL ignore the legacy_session_id field if TLS 1.3 is 161 negotiated. Resumption is handled as described in Section 2.1.2. 162 After the TLS handshake has completed and all Post-Handshake messages 163 have been sent, the EAP server sends EAP-Success. 165 As stated in [RFC5216], the TLS cipher suite shall not be used to 166 protect application data. This applies also for early application 167 data. When EAP-TLS is used with TLS 1.3, early application data 168 SHALL NOT be used. 170 In the case where EAP-TLS with mutual authentication is successful, 171 the conversation will appear as shown in Figure 1. The EAP server 172 commits to not send any more handshake messages by sending an empty 173 TLS record, see Section 2.5. 175 EAP Peer EAP Server 177 EAP-Request/ 178 <-------- Identity 179 EAP-Response/ 180 Identity (Anonymous NAI) --------> 181 EAP-Request/ 182 EAP-Type=EAP-TLS 183 <-------- (TLS Start) 184 EAP-Response/ 185 EAP-Type=EAP-TLS 186 (TLS ClientHello) --------> 187 EAP-Request/ 188 EAP-Type=EAP-TLS 189 (TLS ServerHello, 190 TLS EncryptedExtensions, 191 TLS CertificateRequest, 192 TLS Certificate, 193 TLS CertificateVerify, 194 TLS Finished, 195 <-------- TLS empty record) 196 EAP-Response/ 197 EAP-Type=EAP-TLS 198 (TLS Certificate, 199 TLS CertificateVerify, 200 TLS Finished) --------> 201 <-------- EAP-Success 203 Figure 1: EAP-TLS mutual authentication 205 When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support 206 of resumption in the initial authentication. To indicate support of 207 resumption, the EAP server sends a NewSessionTicket message 208 (containing a PSK and other parameters) after it has received the 209 Finished message. 211 In the case where EAP-TLS with mutual authentication and ticket 212 establishment is successful, the conversation will appear as shown in 213 Figure 2. 215 EAP Peer EAP Server 217 EAP-Request/ 218 <-------- Identity 219 EAP-Response/ 220 Identity (Anonymous NAI) --------> 221 EAP-Request/ 222 EAP-Type=EAP-TLS 223 <-------- (TLS Start) 224 EAP-Response/ 225 EAP-Type=EAP-TLS 226 (TLS ClientHello) --------> 227 EAP-Request/ 228 EAP-Type=EAP-TLS 229 (TLS ServerHello, 230 TLS EncryptedExtensions, 231 TLS CertificateRequest, 232 TLS Certificate, 233 TLS CertificateVerify, 234 <-------- TLS Finished) 235 EAP-Response/ 236 EAP-Type=EAP-TLS 237 (TLS Certificate, 238 TLS CertificateVerify, 239 TLS Finished) --------> 240 EAP-Request/ 241 EAP-Type=EAP-TLS 242 (TLS NewSessionTicket, 243 <-------- TLS empty record) 244 EAP-Response/ 245 EAP-Type=EAP-TLS --------> 246 <-------- EAP-Success 248 Figure 2: EAP-TLS ticket establishment 250 2.1.2. Resumption 252 TLS 1.3 replaces the session resumption mechanisms in earlier 253 versions of TLS with a new PSK exchange. When EAP-TLS is used with 254 TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism 255 compatible with that version of TLS. 257 For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If 258 the client has received a NewSessionTicket message from the server, 259 the client can use the PSK identity received in the ticket to 260 negotiate the use of the associated PSK. If the server accepts it, 261 then the security context of the new connection is tied to the 262 original connection and the key derived from the initial handshake is 263 used to bootstrap the cryptographic state instead of a full 264 handshake. It is left up to the EAP peer whether to use resumption, 265 but an EAP peer SHOULD use resumption as long as it has a valid 266 ticket cached. It is RECOMMENDED that the EAP server accept 267 resumption as long as the ticket is valid. However, the server MAY 268 choose to require a full authentication. 270 A subsequent authentication using resumption, where both sides 271 authenticate successfully is shown in Figure 3. 273 EAP Peer EAP Server 275 EAP-Request/ 276 <-------- Identity 277 EAP-Response/ 278 Identity (Anonymous NAI) --------> 279 EAP-Request/ 280 EAP-Type=EAP-TLS 281 <-------- (TLS Start) 282 EAP-Response/ 283 EAP-Type=EAP-TLS 284 (TLS ClientHello) --------> 285 EAP-Request/ 286 EAP-Type=EAP-TLS 287 (TLS ServerHello, 288 TLS EncryptedExtensions, 289 TLS Finished, 290 <-------- TLS empty record) 291 EAP-Response/ 292 EAP-Type=EAP-TLS 293 (TLS Finished) --------> 294 <-------- EAP-Success 296 Figure 3: EAP-TLS resumption 298 As specified in Section 2.2 of [RFC8446], the EAP peer SHOULD supply 299 a "key_share" extension when offering resumption, which allows the 300 EAP server to decline resumption and continue the handshake as a full 301 handshake. The message flow in this case is given by Figure 1 or 302 Figure 2. If the EAP peer did not supply a "key_share" extension 303 when offering resumption, the EAP server needs to reject the 304 ClientHello and the EAP peer needs to restart a full handshake. The 305 message flow in this case is given by Figure 4 followed by Figure 1 306 or Figure 2. 308 2.1.3. Termination 310 TLS 1.3 changes both the message flow and the handshake messages 311 compared to earlier versions of TLS. Therefore, some normative text 312 in Section 2.1.3 of RFC 5216 [RFC5216] does not apply for TLS 1.3 or 313 higher. The two paragraphs below replaces the corresponding 314 paragraphs in Section 2.1.3 of RFC 5216 [RFC5216] when EAP-TLS is 315 used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 316 of RFC 5216 [RFC5216] still apply with the exception that SessionID 317 is deprecated. 319 If the EAP server authenticates successfully, the EAP peer MUST 320 send an EAP-Response message with EAP-Type=EAP-TLS containing TLS 321 records conforming to the version of TLS used. 323 If the EAP peer authenticates successfully, the EAP server MUST 324 send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS 325 records conforming to the version of TLS used. The message flow 326 ends with the EAP server sending an EAP-Success message. 328 Figures 4, 5, 6, and 7 illustrate message flows in several cases 329 where the EAP peer or EAP server sends a TLS fatal alert message. 330 TLS warning alerts generally mean that the connection can continue 331 normally and does not change the message flow. Note that the party 332 receiving a TLS warning alert may choose to terminate the connection 333 by sending a TLS fatal alert, which may add an extra round-trip, see 334 [RFC8446]. 336 In the case where the server rejects the ClientHello, the 337 conversation will appear as shown in Figure 4. 339 EAP Peer EAP Server 341 EAP-Request/ 342 <-------- Identity 343 EAP-Response/ 344 Identity (Anonymous NAI) --------> 345 EAP-Request/ 346 EAP-Type=EAP-TLS 347 <-------- (TLS Start) 348 EAP-Response/ 349 EAP-Type=EAP-TLS 350 (TLS ClientHello) --------> 351 EAP-Request/ 352 EAP-Type=EAP-TLS 353 <-------- (TLS Fatal Alert) 354 EAP-Response/ 355 EAP-Type=EAP-TLS --------> 356 <-------- EAP-Failure 358 Figure 4: EAP-TLS server rejection of ClientHello 360 In the case where server authentication is unsuccessful, the 361 conversation will appear as shown in Figure 5. 363 EAP Peer EAP Server 365 EAP-Request/ 366 <-------- Identity 367 EAP-Response/ 368 Identity (Anonymous NAI) --------> 369 EAP-Request/ 370 EAP-Type=EAP-TLS 371 <-------- (TLS Start) 372 EAP-Response/ 373 EAP-Type=EAP-TLS 374 (TLS ClientHello) --------> 375 EAP-Request/ 376 EAP-Type=EAP-TLS 377 (TLS ServerHello, 378 TLS EncryptedExtensions, 379 TLS CertificateRequest, 380 TLS Certificate, 381 TLS CertificateVerify, 382 TLS Finished, 383 <-------- TLS empty record) 384 EAP-Response/ 385 EAP-Type=EAP-TLS 386 (TLS Fatal Alert) 387 --------> 388 <-------- EAP-Failure 390 Figure 5: EAP-TLS unsuccessful server authentication 392 In the case where the server authenticates to the peer successfully, 393 but the peer fails to authenticate to the server, the conversation 394 will appear as shown in Figure 6. 396 EAP Peer EAP Server 398 EAP-Request/ 399 <-------- Identity 400 EAP-Response/ 401 Identity (Anonymous NAI) --------> 402 EAP-Request/ 403 EAP-Type=EAP-TLS 404 <-------- (TLS Start) 405 EAP-Response/ 406 EAP-Type=EAP-TLS 407 (TLS ClientHello) --------> 408 EAP-Request/ 409 EAP-Type=EAP-TLS 410 (TLS ServerHello, 411 TLS EncryptedExtensions, 412 TLS CertificateRequest, 413 TLS Certificate, 414 TLS CertificateVerify, 415 TLS Finished, 416 <-------- TLS empty record) 417 EAP-Response/ 418 EAP-Type=EAP-TLS 419 (TLS Certificate, 420 TLS CertificateVerify, 421 TLS Finished) --------> 422 EAP-Request/ 423 EAP-Type=EAP-TLS 424 <-------- (TLS Fatal Alert) 425 EAP-Response/ 426 EAP-Type=EAP-TLS --------> 427 <-------- EAP-Failure 429 Figure 6: EAP-TLS unsuccessful client authentication 431 In the case where the client rejects a NewSessionTicket, the 432 conversation will appear as shown in Figure 7. 434 EAP Peer EAP Server 436 EAP-Request/ 437 <-------- Identity 438 EAP-Response/ 439 Identity (Anonymous NAI) --------> 440 EAP-Request/ 441 EAP-Type=EAP-TLS 442 <-------- (TLS Start) 443 EAP-Response/ 444 EAP-Type=EAP-TLS 445 (TLS ClientHello) --------> 446 EAP-Request/ 447 EAP-Type=EAP-TLS 448 (TLS ServerHello, 449 TLS EncryptedExtensions, 450 TLS CertificateRequest, 451 TLS Certificate, 452 TLS CertificateVerify, 453 <-------- TLS Finished) 454 EAP-Response/ 455 EAP-Type=EAP-TLS 456 (TLS Certificate, 457 TLS CertificateVerify, 458 TLS Finished) --------> 459 EAP-Request/ 460 EAP-Type=EAP-TLS 461 (TLS NewSessionTicket, 462 <-------- TLS empty record) 463 EAP-Response/ 464 EAP-Type=EAP-TLS 465 (TLS Fatal Alert) 466 --------> 467 <-------- EAP-Failure 469 Figure 7: EAP-TLS client rejection of NewSessionTicket 471 2.1.4. Privacy 473 TLS 1.3 significantly improves privacy when compared to earlier 474 versions of TLS by forbidding cipher suites without confidentiality 475 and encrypting large parts of the TLS handshake including the 476 certificate messages. 478 EAP-TLS peer and server implementations supporting TLS 1.3 or higher 479 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 480 in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its 481 username in cleartext in the Identity Response. It is RECOMMENDED to 482 use anonymous NAIs, but other solutions where the username is 483 encrypted MAY be used. 485 As the certificate messages in TLS 1.3 are encrypted, there is no 486 need to send an empty certificate_list or perform a second handshake 487 (as needed by EAP-TLS with earlier versions of TLS). When EAP-TLS is 488 used with TLS version 1.3 or higher the EAP-TLS peer and EAP-TLS 489 server SHALL follow the processing specified by the used version of 490 TLS. For TLS 1.3 this means that the EAP-TLS peer only sends an 491 empty certificate_list if it does not have an appropriate certificate 492 to send, and the EAP-TLS server MAY treat an empty certificate_list 493 as a terminal condition. 495 EAP-TLS with TLS 1.3 is always used with privacy since this does not 496 add any extra round-trips and the message flow with privacy is just 497 the normal message flow as shown in Figure 1. 499 2.1.5. Fragmentation 501 Including ContentType and ProtocolVersion a single TLS record may be 502 up to 16387 octets in length. Some EAP implementations and access 503 networks may limit the number of EAP packet exchanges that can be 504 handled. To avoid fragmentation, it is RECOMMENDED to keep the sizes 505 of client, server, and trust anchor certificates small and the length 506 of the certificate chains short. In addition, it is RECOMMENDED to 507 use mechanisms that reduce the sizes of Certificate messages. 509 While Elliptic Curve Cryptography (ECC) was optional for earlier 510 version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of 511 [RFC8446]). To avoid fragmentation, the use of ECC in certificates, 512 signature algorithms, and groups are RECOMMENDED when using EAP-TLS 513 with TLS 1.3 or higher. At a 128-bit security level, this reduces 514 public key sizes from 384 bytes (RSA and DHE) to 32 bytes (ECDHE) and 515 signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA). An 516 EAP-TLS deployment MAY further reduce the certificate sizes by 517 limiting the number of Subject Alternative Names. 519 Endpoints SHOULD reduce the sizes of Certificate messages by omitting 520 certificates that the other endpoint is known to possess. When using 521 TLS 1.3, all certificates that specifies a trust anchor may be 522 omitted (see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or 523 earlier, only the self-signed certificate that specifies the root 524 certificate authority may be omitted (see Section 7.4.2 of 525 [RFC5246]). EAP-TLS peers and servers SHOULD support and use the 526 Cached Information Extension as specified in [RFC7924]. EAP-TLS 527 peers and servers MAY use other extensions for reducing the sizes of 528 Certificate messages, e.g. certificate compression 529 [I-D.ietf-tls-certificate-compression]. 531 2.2. Identity Verification 533 No updates to [RFC5216]. 535 2.3. Key Hierarchy 537 TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier 538 versions of TLS with HKDF and completely changes the Key Schedule. 539 The key hierarchies shown in Section 2.3 of [RFC5216] are therefore 540 not correct when EAP-TLS is used with TLS version 1.3 or higher. For 541 TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446]. 543 When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, 544 IV, and Method-Id SHALL be derived from the exporter_master_secret 545 using the TLS exporter interface [RFC5705] (for TLS 1.3 this is 546 defined in Section 7.5 of [RFC8446]). 548 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128) 549 IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", "", 64) 550 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", "", 64) 551 Session-Id = 0x0D || Method-Id 553 By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation 554 without having to extract the Master Secret, ClientHello.random, and 555 ServerHello.random in a non-standard way. 557 All other parameters such as MSK and EMSK are derived as specified in 558 EAP-TLS [RFC5216], Section 2.3. The use of these keys is specific to 559 the lower layer, as described [RFC5247]. 561 2.4. Parameter Negotiation and Compliance Requirements 563 TLS 1.3 cipher suites are defined differently than in earlier 564 versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites 565 discussed in Section 2.4 of [RFC5216] can therefore not be used when 566 EAP-TLS is used with TLS version 1.3 or higher. The requirements on 567 protocol version and compression given in Section 2.4 of [RFC5216] 568 still apply. 570 When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS 571 peers and servers MUST comply with the requirements for the TLS 572 version used. For TLS 1.3 the compliance requirements are defined in 573 Section 9 of [RFC8446]. 575 2.5. EAP State Machines 577 TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- 578 Handshake messages use the handshake content type and can be sent 579 after the main handshake. One such Post-Handshake message is 580 NewSessionTicket. The NewSessionTicket can be used for resumption. 581 After sending TLS Finished, the EAP server may send any number of 582 Post-Handshake messages in separate EAP-Requests. To decrease the 583 uncertainty for the EAP peer, the following procedure MUST be 584 followed: 586 When an EAP server has sent its last handshake message (Finished or a 587 Post-Handshake), it commits to not sending any more handshake 588 messages by appending an empty application data record (i.e. a TLS 589 record with TLSPlaintext.type = application_data and 590 TLSPlaintext.length = 0) to the last handshake record. After sending 591 an empty application data record, the EAP server may only send an 592 EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert 593 Message. 595 Note that the use of an empty application data record does not 596 violate the requirement that the TLS cipher suite shall not be used 597 to protect application data, as the application data is the empty 598 string, no application data is protected. 600 3. Detailed Description of the EAP-TLS Protocol 602 No updates to [RFC5216]. 604 4. IANA considerations 606 This section provides guidance to the Internet Assigned Numbers 607 Authority (IANA) regarding registration of values related to the EAP- 608 TLS 1.3 protocol in accordance with [RFC8126]. 610 This memo requires IANA to add the following labels to the TLS 611 Exporter Label Registry defined by [RFC5705]. These labels are used 612 in derivation of Key_Material, IV and Method-Id as defined in 613 Section 2.3: 615 o "EXPORTER_EAP_TLS_Key_Material" 617 o "EXPORTER_EAP_TLS_IV" 619 o "EXPORTER_EAP_TLS_Method-Id" 621 5. Security Considerations 623 5.1. Security Claims 625 Using EAP-TLS with TLS 1.3 does not change the security claims for 626 EAP-TLS as given in Section 4.1 of [RFC5216]. However, it 627 strengthens several of the claims as described in the following 628 updates to the notes given in Section 4.1 of [RFC5216]. 630 [2] Confidentiality: The TLS 1.3 handshake offers much better 631 confidentiality than earlier versions of TLS by mandating cipher 632 suites with confidentiality and encrypting certificates and some of 633 the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the 634 use of privacy is mandatory and does not cause any additional round- 635 trips. 637 [3] Key strength: TLS 1.3 forbids all algorithms with known 638 weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 639 only supports cryptographic algorithms offering at least 112-bit 640 security, see [RFC8446]. 642 [4] Cryptographic Negotiation: TLS 1.3 increases the number of 643 cryptographic parameters that are negotiated in the handshake. When 644 EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic 645 negotiation of AEAD algorithm, HKDF hash algorithm, key exchange 646 groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. 648 5.2. Peer and Server Identities 650 No updates to [RFC5216]. 652 5.3. Certificate Validation 654 No updates to [RFC5216]. 656 5.4. Certificate Revocation 658 The OCSP status handling in TLS 1.3 is different from earlier 659 versions of TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the 660 OCSP information is carried in the CertificateEntry containing the 661 associated certificate instead of a separate CertificateStatus 662 message as in [RFC4366]. This enables sending OCSP information for 663 all certificates in the certificate chain. 665 EAP-TLS peers and servers supporting TLS 1.3 SHOULD support 666 Certificate Status Requests (OCSP stapling) as specified in [RFC6066] 667 and Section 4.4.2.1 of [RFC8446]. The use of Certificate Status 668 Requests to determine the current status of the EAP server's 669 certificate is RECOMMENDED. 671 5.5. Packet Modification Attacks 673 No updates to [RFC5216]. 675 5.6. Privacy Considerations 677 [RFC6973] suggests that the privacy considerations of IETF protocols 678 be documented. 680 TLS 1.3 offers much better privacy than earlier versions of TLS as 681 discussed in Section 2.1.4. In this section, we only discuss the 682 privacy properties of EAP-TLS with TLS 1.3. For privacy properties 683 of TLS 1.3 itself, see [RFC8446]. 685 EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in 686 EAP packets. Additionally, the EAP peer sends an identity in the 687 first EAP-Response. The other fields in the EAP-TLS Request and the 688 EAP-TLS Response packets do not contain any cleartext privacy 689 sensitive information. 691 When EAP-TLS is used with TLS 1.3, the username part of the identity 692 response is always confidentiality protected (e.g. using Anonymous 693 NAIs). However, as with other EAP methods, even when privacy- 694 friendly identifiers or EAP tunneling is used, the domain name (i.e. 695 the realm) in the NAI is still typically visible. How much privacy 696 sensitive information the domain name leaks is highly dependent on 697 how many other users are using the same domain name in the particular 698 access network. If all EAP peers have the same domain, no additional 699 information is leaked. If a domain name is used by a small subset of 700 the EAP peers, it may aid an attacker in tracking or identifying the 701 user. 703 An EAP peer with a policy allowing communication with EAP servers 704 supporting only TLS 1.2 (or lower) without privacy and with RSA key 705 exchange is vulnerable to disclosure of the peer username. An active 706 attacker can in this case make the EAP peer believe that an EAP 707 server supporting TLS 1.3 only supports TLS 1.2 (or lower) without 708 privacy. The attacker can simply impersonate the EAP server and 709 negotiate TLS 1.2 (or lower) with RSA key exchange and send an TLS 710 alert message when the EAP peer tries to use privacy by sending an 711 empty certificate message. Since the attacker (impersonating the EAP 712 server) does not provide a proof-of-possession of the private key 713 until the Finished message when RSA key exchange is used, an EAP peer 714 may inadvertently disclose its identity (username) to an attacker. 716 Therefore, it is RECOMMENDED for EAP peers to not use EAP-TLS with 717 TLS 1.2 (or lower) and RSA based cipher suites without privacy. 719 5.7. Pervasive Monitoring 721 As required by [RFC7258], work on IETF protocols needs to consider 722 the effects of pervasive monitoring and mitigate them when possible. 724 Pervasive Monitoring is widespread surveillance of users. By 725 encrypting more information and by mandating the use of privacy, TLS 726 1.3 offers much better protection against pervasive monitoring. In 727 addition to the privacy attacks discussed above, surveillance on a 728 large scale may enable tracking of a user over a wider geographical 729 area and across different access networks. Using information from 730 EAP-TLS together with information gathered from other protocols 731 increases the risk of identifying individual users. 733 6. References 735 6.1. Normative References 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, 739 DOI 10.17487/RFC2119, March 1997, 740 . 742 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 743 Levkowetz, Ed., "Extensible Authentication Protocol 744 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 745 . 747 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 748 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 749 March 2008, . 751 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 752 Housley, R., and W. Polk, "Internet X.509 Public Key 753 Infrastructure Certificate and Certificate Revocation List 754 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 755 . 757 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 758 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 759 March 2010, . 761 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 762 Extensions: Extension Definitions", RFC 6066, 763 DOI 10.17487/RFC6066, January 2011, 764 . 766 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 767 Galperin, S., and C. Adams, "X.509 Internet Public Key 768 Infrastructure Online Certificate Status Protocol - OCSP", 769 RFC 6960, DOI 10.17487/RFC6960, June 2013, 770 . 772 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 773 DOI 10.17487/RFC7542, May 2015, 774 . 776 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 777 (TLS) Cached Information Extension", RFC 7924, 778 DOI 10.17487/RFC7924, July 2016, 779 . 781 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 782 Writing an IANA Considerations Section in RFCs", BCP 26, 783 RFC 8126, DOI 10.17487/RFC8126, June 2017, 784 . 786 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 787 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 788 May 2017, . 790 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 791 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 792 . 794 6.2. Informative references 796 [I-D.ietf-tls-certificate-compression] 797 Ghedini, A. and V. Vasiliev, "TLS Certificate 798 Compression", draft-ietf-tls-certificate-compression-04 799 (work in progress), October 2018. 801 [IEEE-802.11] 802 Institute of Electrical and Electronics Engineers, "IEEE 803 Standard for Information technology--Telecommunications 804 and information exchange between systems Local and 805 metropolitan area networks--Specific requirements - Part 806 11: Wireless LAN Medium Access Control (MAC) and Physical 807 Layer (PHY) Specifications", IEEE Std 802.11-2016 808 (Revision of IEEE Std 802.11-2012) , December 2016. 810 [IEEE-802.1X] 811 Institute of Electrical and Electronics Engineers, "IEEE 812 Standard for Local and metropolitan area networks -- Port- 813 Based Network Access Control", IEEE Standard 802.1X-2010 , 814 February 2010. 816 [MulteFire] 817 MulteFire, "MulteFire Release 1.0.1 specification", 2017. 819 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 820 RFC 2246, DOI 10.17487/RFC2246, January 1999, 821 . 823 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 824 Adams, "X.509 Internet Public Key Infrastructure Online 825 Certificate Status Protocol - OCSP", RFC 2560, 826 DOI 10.17487/RFC2560, June 1999, 827 . 829 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 830 X.509 Public Key Infrastructure Certificate and 831 Certificate Revocation List (CRL) Profile", RFC 3280, 832 DOI 10.17487/RFC3280, April 2002, 833 . 835 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 836 Network Access Identifier", RFC 4282, 837 DOI 10.17487/RFC4282, December 2005, 838 . 840 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 841 (TLS) Protocol Version 1.1", RFC 4346, 842 DOI 10.17487/RFC4346, April 2006, 843 . 845 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 846 and T. Wright, "Transport Layer Security (TLS) 847 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 848 . 850 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 851 (TLS) Protocol Version 1.2", RFC 5246, 852 DOI 10.17487/RFC5246, August 2008, 853 . 855 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 856 Authentication Protocol (EAP) Key Management Framework", 857 RFC 5247, DOI 10.17487/RFC5247, August 2008, 858 . 860 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 861 Morris, J., Hansen, M., and R. Smith, "Privacy 862 Considerations for Internet Protocols", RFC 6973, 863 DOI 10.17487/RFC6973, July 2013, 864 . 866 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 867 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 868 2014, . 870 [TS.33.501] 871 3GPP, "Security architecture and procedures for 5G 872 System", 3GPP TS 33.501 15.2.0, September 2018. 874 Appendix A. Updated references 876 All the following references in [RFC5216] are updated as specified 877 below when EAP-TLS is used with TLS 1.3 or higher. 879 All references to [RFC2560] are updated with [RFC6960]. 881 All references to [RFC3280] are updated with [RFC5280]. 883 All references to [RFC4282] are updated with [RFC7542]. 885 Acknowledgments 887 The authors want to thank Alan DeKok, Ari Keraenen, Bernard Aboba, 888 Eric Rescorla, Jari Arkko, Jim Schaad, Jouni Malinen, and Vesa 889 Torvinen for comments and suggestions on the draft. 891 Authors' Addresses 893 John Mattsson 894 Ericsson 895 Stockholm 164 40 896 Sweden 898 Email: john.mattsson@ericsson.com 899 Mohit Sethi 900 Ericsson 901 Jorvas 02420 902 Finland 904 Email: mohit@piuha.net