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