idnits 2.17.1 draft-ietf-emu-eap-tls13-06.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 (August 2, 2019) is 1722 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 769 -- Looks like a reference, but probably isn't: '2' on line 773 -- Looks like a reference, but probably isn't: '3' on line 780 -- Looks like a reference, but probably isn't: '4' on line 785 == Outdated reference: A later version (-10) exists of draft-ietf-tls-certificate-compression-05 == 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 (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Mattsson 3 Internet-Draft M. Sethi 4 Updates: 5216 (if approved) Ericsson 5 Intended status: Standards Track August 2, 2019 6 Expires: February 3, 2020 8 Using EAP-TLS with TLS 1.3 9 draft-ietf-emu-eap-tls13-06 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 February 3, 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 . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . 27 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 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 and key derivation utilizing the TLS handshake 98 protocol for cryptographic algorithms and protocol version 99 negotiation, mutual authentication, and establishment of shared 100 secret keying material. EAP-TLS is widely supported for 101 authentication in IEEE 802.11 [IEEE-802.11] networks (Wi-Fi) using 102 IEEE 802.1X [IEEE-802.1X] and it's the default mechanism for 103 certificate based authentication in 3GPP 5G [TS.33.501] and MulteFire 104 [MulteFire] networks. EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] 105 and TLS 1.1 [RFC4346], but works perfectly also with TLS 1.2 106 [RFC5246]. TLS 1.0 and 1.1 are formally deprecated and prohibited to 107 negotiate and use [I-D.ietf-tls-oldversions-deprecate]. 109 Weaknesses found in TLS 1.2, as well as new requirements for 110 security, privacy, and reduced latency has led to the specification 111 of TLS 1.3 [RFC8446], which obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is 112 in large parts a complete remodeling of the TLS handshake protocol 113 including a different message flow, different handshake messages, 114 different key schedule, different cipher suites, different 115 resumption, and different privacy protection. This means that 116 significant parts of the normative text in the previous EAP-TLS 117 specification [RFC5216] are not applicable to EAP-TLS with TLS 1.3 118 (or higher). Therefore, aspects such as resumption, privacy 119 handling, and key derivation need to be appropriately addressed for 120 EAP-TLS with TLS 1.3 (or higher). 122 This document defines how to use EAP-TLS with TLS 1.3 (or higher) and 123 does not change how EAP-TLS is used with older versions of TLS. 124 While this document updates EAP-TLS [RFC5216], it remains backwards 125 compatible with it and existing implementations of EAP-TLS. This 126 document only describes differences compared to [RFC5216]. 128 In addition to the improved security and privacy offered by TLS 1.3, 129 there are other significant benefits of using EAP-TLS with TLS 1.3. 130 Privacy is mandatory and achieved without any additional round-trips, 131 revocation checking is mandatory and easy with OCSP stapling, and TLS 132 1.3 introduces more possibilities to reduce fragmentation when 133 compared to earlier versions of TLS. 135 1.1. Requirements and Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 Readers are expected to be familiar with the terms and concepts used 144 in EAP-TLS [RFC5216] and TLS [RFC8446]. 146 2. Protocol Overview 148 2.1. Overview of the EAP-TLS Conversation 150 TLS 1.3 changes both the message flow and the handshake messages 151 compared to earlier versions of TLS. Therefore, much of Section 2.1 152 of [RFC5216] does not apply for TLS 1.3 (or higher). 154 After receiving an EAP-Request packet with EAP-Type=EAP-TLS as 155 described in [RFC5216] the conversation will continue with the TLS 156 handshake protocol encapsulated in the data fields of EAP-Response 157 and EAP-Request packets. When EAP-TLS is used with TLS version 1.3 158 or higher, the formatting and processing of the TLS handshake SHALL 159 be done as specified in that version of TLS. This document only 160 lists additional and different requirements, restrictions, and 161 processing compared to [RFC8446] and [RFC5216]. 163 2.1.1. Mutual Authentication 165 The EAP server MUST authenticate with a certificate and SHOULD 166 require the EAP peer to authenticate with a certificate. 167 Certificates can be of any type supported by TLS including raw public 168 keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except 169 for resumption. SessionID is deprecated in TLS 1.3 and the EAP 170 server SHALL ignore the legacy_session_id field if TLS 1.3 is 171 negotiated. TLS 1.3 introduced early application data which is not 172 used in EAP-TLS. A server which receives an "early_data" extension 173 MUST ignore the extension or respond with a HelloRetryRequest as 174 described in Section 4.2.10 of [RFC8446]. Resumption is handled as 175 described in Section 2.1.6. After the TLS handshake has completed 176 and all Post-Handshake messages have been sent, the EAP server sends 177 EAP-Success. 179 In the case where EAP-TLS with mutual authentication is successful, 180 the conversation will appear as shown in Figure 1. The EAP server 181 commits to not send any more handshake messages by sending a TLS 182 record with the application data 0x00, see Section 2.5. 184 EAP Peer EAP Server 186 EAP-Request/ 187 <-------- Identity 188 EAP-Response/ 189 Identity (Privacy-Friendly) --------> 190 EAP-Request/ 191 EAP-Type=EAP-TLS 192 <-------- (TLS Start) 193 EAP-Response/ 194 EAP-Type=EAP-TLS 195 (TLS ClientHello) --------> 196 EAP-Request/ 197 EAP-Type=EAP-TLS 198 (TLS ServerHello, 199 TLS EncryptedExtensions, 200 TLS CertificateRequest, 201 TLS Certificate, 202 TLS CertificateVerify, 203 TLS Finished, 204 <-------- TLS Application Data) 205 EAP-Response/ 206 EAP-Type=EAP-TLS 207 (TLS Certificate, 208 TLS CertificateVerify, 209 TLS Finished) --------> 210 <-------- EAP-Success 212 Figure 1: EAP-TLS mutual authentication 214 2.1.2. Termination 216 TLS 1.3 changes both the message flow and the handshake messages 217 compared to earlier versions of TLS. Therefore, some normative text 218 in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3 or higher. 219 The two paragraphs below replaces the corresponding paragraphs in 220 Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or 221 higher. The other paragraphs in Section 2.1.3 of [RFC5216] still 222 apply with the exception that SessionID is deprecated. 224 If the EAP server authenticates successfully, the EAP peer MUST 225 send an EAP-Response message with EAP-Type=EAP-TLS containing TLS 226 records conforming to the version of TLS used. 228 If the EAP peer authenticates successfully, the EAP server MUST 229 send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS 230 records conforming to the version of TLS used. The message flow 231 ends with the EAP server sending an EAP-Success message. 233 Figures 2, 3, and 4 illustrate message flows in several cases where 234 the EAP peer or EAP server sends a TLS fatal alert message. TLS 235 warning alerts generally mean that the connection can continue 236 normally and does not change the message flow. Note that the party 237 receiving a TLS warning alert may choose to terminate the connection 238 by sending a TLS fatal alert, which may add an extra round-trip, see 239 [RFC8446]. 241 In the case where the server rejects the ClientHello, the 242 conversation will appear as shown in Figure 2. 244 EAP Peer EAP Server 246 EAP-Request/ 247 <-------- Identity 248 EAP-Response/ 249 Identity (Privacy-Friendly) --------> 250 EAP-Request/ 251 EAP-Type=EAP-TLS 252 <-------- (TLS Start) 253 EAP-Response/ 254 EAP-Type=EAP-TLS 255 (TLS ClientHello) --------> 256 EAP-Request/ 257 EAP-Type=EAP-TLS 258 <-------- (TLS Fatal Alert) 259 EAP-Response/ 260 EAP-Type=EAP-TLS --------> 261 <-------- EAP-Failure 263 Figure 2: EAP-TLS server rejection of ClientHello 265 In the case where server authentication is unsuccessful, the 266 conversation will appear as shown in Figure 3. 268 EAP Peer EAP Server 270 EAP-Request/ 271 <-------- Identity 272 EAP-Response/ 273 Identity (Privacy-Friendly) --------> 274 EAP-Request/ 275 EAP-Type=EAP-TLS 276 <-------- (TLS Start) 277 EAP-Response/ 278 EAP-Type=EAP-TLS 279 (TLS ClientHello) --------> 280 EAP-Request/ 281 EAP-Type=EAP-TLS 282 (TLS ServerHello, 283 TLS EncryptedExtensions, 284 TLS CertificateRequest, 285 TLS Certificate, 286 TLS CertificateVerify, 287 TLS Finished, 288 <-------- TLS Application Data) 289 EAP-Response/ 290 EAP-Type=EAP-TLS 291 (TLS Fatal Alert) 292 --------> 293 <-------- EAP-Failure 295 Figure 3: EAP-TLS unsuccessful server authentication 297 In the case where the server authenticates to the peer successfully, 298 but the peer fails to authenticate to the server, the conversation 299 will appear as shown in Figure 4. 301 EAP Peer EAP Server 303 EAP-Request/ 304 <-------- Identity 305 EAP-Response/ 306 Identity (Privacy-Friendly) --------> 308 EAP-Request/ 309 EAP-Type=EAP-TLS 310 <-------- (TLS Start) 311 EAP-Response/ 312 EAP-Type=EAP-TLS 313 (TLS ClientHello) --------> 314 EAP-Request/ 315 EAP-Type=EAP-TLS 316 (TLS ServerHello, 317 TLS EncryptedExtensions, 318 TLS CertificateRequest, 319 TLS Certificate, 320 TLS CertificateVerify, 321 TLS Finished, 322 <-------- TLS Application Data) 323 EAP-Response/ 324 EAP-Type=EAP-TLS 325 (TLS Certificate, 326 TLS CertificateVerify, 327 TLS Finished) --------> 328 EAP-Request/ 329 EAP-Type=EAP-TLS 330 <-------- (TLS Fatal Alert) 331 EAP-Response/ 332 EAP-Type=EAP-TLS --------> 333 <-------- EAP-Failure 335 Figure 4: EAP-TLS unsuccessful client authentication 337 2.1.3. No Peer Authentication 339 In the case where EAP-TLS is used without peer authentication (e.g., 340 emergency services, as described in [RFC7406]) the conversation will 341 appear as shown in Figure 5. 343 EAP Peer EAP Server 345 EAP-Request/ 346 <-------- Identity 347 EAP-Response/ 348 Identity (Privacy-Friendly) --------> 349 EAP-Request/ 350 EAP-Type=EAP-TLS 351 <-------- (TLS Start) 352 EAP-Response/ 353 EAP-Type=EAP-TLS 354 (TLS ClientHello) --------> 355 EAP-Request/ 356 EAP-Type=EAP-TLS 357 (TLS ServerHello, 358 TLS EncryptedExtensions, 359 TLS Certificate, 360 TLS CertificateVerify, 361 TLS Finished, 362 <-------- TLS Application Data) 363 EAP-Response/ 364 EAP-Type=EAP-TLS 365 (TLS Finished) --------> 366 <-------- EAP-Success 368 Figure 5: EAP-TLS without peer authentication 370 2.1.4. Hello Retry Request 372 TLS 1.3 [RFC8446] defines that TLS servers can send a 373 HelloRetryRequest message in response to a ClientHello if the server 374 finds an acceptable set of parameters but the initial ClientHello 375 does not contain all the needed information to continue the 376 handshake. 378 An EAP-TLS peer and server SHOULD support the use of 379 HelloRetryRequest message. As noted in Section 4.1.4 of [RFC8446], 380 the server MUST provide the supported_versions extensions and SHOULD 381 contain the minimal set of extensions necessary for the client to 382 generate a correct ClientHello pair. A HelloRetryRequest MUST NOT 383 contain any extensions that were not first offered by the client in 384 its ClientHello, with the exception of optionally the cookie 385 extension. 387 The case of a successful EAP-TLS mutual authentication after the 388 server has sent a HelloRetryRequest message is shown in Figure 6. 389 Note the extra round-trip as a result of the HelloRetryRequest. 391 EAP Peer EAP Server 393 EAP-Request/ 394 <-------- Identity 395 EAP-Response/ 396 Identity (Privacy-Friendly) --------> 397 EAP-Request/ 398 EAP-Type=EAP-TLS 399 <-------- (TLS Start) 400 EAP-Response/ 401 EAP-Type=EAP-TLS 402 (TLS ClientHello) --------> 403 EAP-Request/ 404 EAP-Type=EAP-TLS 405 (TLS HelloRetryRequest) 406 <-------- 407 EAP-Response/ 408 EAP-Type=EAP-TLS 409 (TLS ClientHello) --------> 410 EAP-Request/ 411 EAP-Type=EAP-TLS 412 (TLS ServerHello, 413 TLS EncryptedExtensions, 414 TLS Finished, 415 <-------- TLS Application Data) 416 EAP-Response/ 417 EAP-Type=EAP-TLS 418 (TLS Finished) --------> 419 <-------- EAP-Success 421 Figure 6: EAP-TLS with Hello Retry Request 423 2.1.5. Ticket Establishment 425 When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support 426 of resumption in the initial authentication. To indicate support of 427 resumption, the EAP server sends a NewSessionTicket message 428 (containing a PSK and other parameters) after it has received the 429 Finished message. The NewSessionTicket message MUST NOT include an 430 "early_data" extension. 432 In the case where EAP-TLS with mutual authentication and ticket 433 establishment is successful, the conversation will appear as shown in 434 Figure 7. 436 EAP Peer EAP Server 438 EAP-Request/ 439 <-------- Identity 440 EAP-Response/ 441 Identity (Privacy-Friendly) --------> 442 EAP-Request/ 443 EAP-Type=EAP-TLS 444 <-------- (TLS Start) 445 EAP-Response/ 446 EAP-Type=EAP-TLS 447 (TLS ClientHello) --------> 448 EAP-Request/ 449 EAP-Type=EAP-TLS 450 (TLS ServerHello, 451 TLS EncryptedExtensions, 452 TLS CertificateRequest, 453 TLS Certificate, 454 TLS CertificateVerify, 455 <-------- TLS Finished) 456 EAP-Response/ 457 EAP-Type=EAP-TLS 458 (TLS Certificate, 459 TLS CertificateVerify, 460 TLS Finished) --------> 461 EAP-Request/ 462 EAP-Type=EAP-TLS 463 (TLS NewSessionTicket, 464 <-------- TLS Application Data) 465 EAP-Response/ 466 EAP-Type=EAP-TLS --------> 467 <-------- EAP-Success 469 Figure 7: EAP-TLS ticket establishment 471 2.1.6. Resumption 473 TLS 1.3 replaces the session resumption mechanisms in earlier 474 versions of TLS with a new PSK exchange. When EAP-TLS is used with 475 TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism 476 compatible with that version of TLS. 478 For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If 479 the client has received a NewSessionTicket message from the server, 480 the client can use the PSK identity received in the ticket to 481 negotiate the use of the associated PSK. If the server accepts it, 482 then the security context of the new connection is tied to the 483 original connection and the key derived from the initial handshake is 484 used to bootstrap the cryptographic state instead of a full 485 handshake. It is left up to the EAP peer whether to use resumption, 486 but it is RECOMMENDED that the EAP server accept resumption as long 487 as the ticket is valid. However, the server MAY choose to require a 488 full authentication. 490 A subsequent authentication using resumption, where both sides 491 authenticate successfully is shown in Figure 8. 493 EAP Peer EAP Server 495 EAP-Request/ 496 <-------- Identity 497 EAP-Response/ 498 Identity (Privacy-Friendly) --------> 499 EAP-Request/ 500 EAP-Type=EAP-TLS 501 <-------- (TLS Start) 502 EAP-Response/ 503 EAP-Type=EAP-TLS 504 (TLS ClientHello) --------> 505 EAP-Request/ 506 EAP-Type=EAP-TLS 507 (TLS ServerHello, 508 TLS EncryptedExtensions, 509 TLS Finished, 510 <-------- TLS Application Data) 511 EAP-Response/ 512 EAP-Type=EAP-TLS 513 (TLS Finished) --------> 514 <-------- EAP-Success 516 Figure 8: EAP-TLS resumption 518 As specified in Section 2.2 of [RFC8446], the EAP peer SHOULD supply 519 a "key_share" extension when offering resumption, which allows the 520 EAP server to decline resumption and continue the handshake as a full 521 handshake. The message flow in case of mutual authentication is 522 given by Figure 1. If the EAP peer did not supply a "key_share" 523 extension when offering resumption, the EAP server needs to reject 524 the ClientHello and the EAP peer needs to restart a full handshake. 525 The message flow in this case is given by Figure 2 followed by 526 Figure 1. 528 Also during resumption, the server can respond with a Hello Retry 529 Request (see Section 2.1.4) and issue a new ticket (see 530 Section 2.1.5) 532 2.1.7. Privacy 534 TLS 1.3 significantly improves privacy when compared to earlier 535 versions of TLS by forbidding cipher suites without confidentiality 536 and encrypting large parts of the TLS handshake including the 537 certificate messages. 539 EAP-TLS peer and server implementations supporting TLS 1.3 or higher 540 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 541 in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its 542 username in cleartext in the Identity Response. It is RECOMMENDED to 543 use anonymous NAIs, but other privacy-friendly identities (e.g. 544 encrypted usernames) MAY be used. 546 As the certificate messages in TLS 1.3 are encrypted, there is no 547 need to send an empty certificate_list and perform a second handshake 548 for privacy (as needed by EAP-TLS with earlier versions of TLS). 549 When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer 550 and EAP-TLS server SHALL follow the processing specified by the used 551 version of TLS. For TLS 1.3 this means that the EAP-TLS peer only 552 sends an empty certificate_list if it does not have an appropriate 553 certificate to send, and the EAP-TLS server MAY treat an empty 554 certificate_list as a terminal condition. 556 EAP-TLS with TLS 1.3 is always used with privacy. This does not add 557 any extra round-trips and the message flow with privacy is just the 558 normal message flow as shown in Figure 1. 560 2.1.8. Fragmentation 562 Including ContentType and ProtocolVersion a single TLS record may be 563 up to 16387 octets in length. EAP-TLS fragmentation support is 564 provided through addition of a flags octet within the EAP-Response 565 and EAP-Request packets, as well as a TLS Message Length field of 566 four octets. Implementations MUST NOT set the L bit in unfragmented 567 messages, but MUST accept unfragmented messages with and without the 568 L bit set. 570 Some EAP implementations and access networks may limit the number of 571 EAP packet exchanges that can be handled. To avoid fragmentation, it 572 is RECOMMENDED to keep the sizes of client, server, and trust anchor 573 certificates small and the length of the certificate chains short. 574 In addition, it is RECOMMENDED to use mechanisms that reduce the 575 sizes of Certificate messages. 577 While Elliptic Curve Cryptography (ECC) was optional for earlier 578 version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of 579 [RFC8446]). To avoid fragmentation, the use of ECC in certificates, 580 signature algorithms, and groups are RECOMMENDED when using EAP-TLS 581 with TLS 1.3 or higher. At a 128-bit security level, this reduces 582 public key sizes from 384 bytes (RSA and DHE) to 32-64 bytes (ECDHE) 583 and signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA). 584 An EAP-TLS deployment MAY further reduce the certificate sizes by 585 limiting the number of Subject Alternative Names. 587 Endpoints SHOULD reduce the sizes of Certificate messages by omitting 588 certificates that the other endpoint is known to possess. When using 589 TLS 1.3, all certificates that specifies a trust anchor may be 590 omitted (see Section 4.4.2 of [RFC8446]). When using TLS 1.2, only 591 the self-signed certificate that specifies the root certificate 592 authority may be omitted (see Section 7.4.2 of [RFC5246]). EAP-TLS 593 peers and servers SHOULD support and use the Cached Information 594 Extension as specified in [RFC7924]. EAP-TLS peers and servers MAY 595 use other extensions for reducing the sizes of Certificate messages, 596 e.g. certificate compression [I-D.ietf-tls-certificate-compression]. 598 2.2. Identity Verification 600 The identity provided in the EAP-Response/Identity is not 601 authenticated by EAP-TLS. Unauthenticated information SHALL NOT be 602 used for accounting purposes or to give authorization. The 603 authenticator and the EAP server MAY examine the identity presented 604 in EAP-Response/Identity for purposes such as routing and EAP method 605 selection. They MAY reject conversations if the identity does not 606 match their policy. Note that this also applies to resumption, see 607 Sections 2.1.6, 5.6, and 5.7. 609 2.3. Key Hierarchy 611 TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier 612 versions of TLS with HKDF and completely changes the Key Schedule. 613 The key hierarchies shown in Section 2.3 of [RFC5216] are therefore 614 not correct when EAP-TLS is used with TLS version 1.3 or higher. For 615 TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446]. 617 When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, 618 IV, and Method-Id SHALL be derived from the exporter_master_secret 619 using the TLS exporter interface [RFC5705] (for TLS 1.3 this is 620 defined in Section 7.5 of [RFC8446]). 622 Type-Code = 0x0D 623 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 624 Type-Code, 128) 625 IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", 626 Type-Code, 64) 627 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 628 Type-Code, 64) 629 Session-Id = Type-Code || Method-Id 631 All other parameters such as MSK and EMSK are derived in the same 632 manner as with EAP-TLS [RFC5216], Section 2.3. The definitions are 633 repeated below for simplicity: 635 MSK = Key_Material(0, 63) 636 EMSK = Key_Material(64, 127) 637 Enc-RECV-Key = MSK(0, 31) 638 Enc-SEND-Key = MSK(32, 63) 639 RECV-IV = IV(0, 31) 640 SEND-IV = IV(32, 63) 642 The use of these keys is specific to the lower layer, as described 643 [RFC5247]. 645 Note that the key derivation MUST use the length values given above. 646 While in TLS 1.2 and earlier it was possible to truncate the output 647 by requesting less data from the TLS-Exporter function, this practice 648 is not possible with TLS 1.3. If an implementation intends to use 649 only a part of the output of the TLS-Exporter function, then it MUST 650 ask for the full output and then only use the desired part. Failure 651 to do so will result in incorrect values being calculated for the 652 above keying material. 654 By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation 655 without having to extract the Master Secret, ClientHello.random, and 656 ServerHello.random in a non-standard way. 658 2.4. Parameter Negotiation and Compliance Requirements 660 TLS 1.3 cipher suites are defined differently than in earlier 661 versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites 662 discussed in Section 2.4 of [RFC5216] can therefore not be used when 663 EAP-TLS is used with TLS version 1.3 or higher. 665 When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS 666 peers and servers MUST comply with the compliance requirements 667 (mandatory-to-implement cipher suites, signature algorithms, key 668 exchange algorithms, extensions, etc.) for the TLS version used. For 669 TLS 1.3 the compliance requirements are defined in Section 9 of 670 [RFC8446]. 672 While EAP-TLS does not protect any application data, the negotiated 673 cipher suites and algorithms MAY be used to secure data as done in 674 other TLS-based EAP methods. 676 2.5. EAP State Machines 678 TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- 679 Handshake messages use the handshake content type and can be sent 680 after the main handshake. One such Post-Handshake message is 681 NewSessionTicket. The NewSessionTicket can be used for resumption. 682 After sending TLS Finished, the EAP server may send any number of 683 Post-Handshake messages in separate EAP-Requests. To decrease the 684 uncertainty for the EAP peer, the following procedure MUST be 685 followed: 687 When an EAP server has sent its last handshake message (Finished or a 688 Post-Handshake), it commits to not sending any more handshake 689 messages by sending a TLS record with application data 0x00 (i.e. a 690 TLS record with TLSPlaintext.type = application_data, 691 TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00). EAP 692 server implementations MUST set TLSPlaintext.fragment to 0x00, but 693 EAP peer implementations MUST accept any application data as a commit 694 from the EAP server to not send any more handshake messages. The TLS 695 record with application data may be sent in the same EAP-Request as 696 the last handshake record or in a separate EAP-Request. Sending the 697 commit in a separate EAP-Request adds an additional round-trip, but 698 may be necessary in TLS implementations that only implement a subset 699 of TLS 1.3. In the case where the server sends the commit in a 700 separate commit, the conversation will appear as shown in Figure 9. 701 After sending the application data record, the EAP server may only 702 send an EAP-Success, an EAP-Failure, or an EAP-Request with a TLS 703 Alert Message. 705 EAP Peer EAP Server 707 EAP-Request/ 708 <-------- Identity 709 EAP-Response/ 710 Identity (Privacy-Friendly) --------> 711 EAP-Request/ 712 EAP-Type=EAP-TLS 713 <-------- (TLS Start) 714 EAP-Response/ 715 EAP-Type=EAP-TLS 716 (TLS ClientHello) --------> 717 EAP-Request/ 718 EAP-Type=EAP-TLS 719 (TLS ServerHello, 720 TLS EncryptedExtensions, 721 TLS CertificateRequest, 722 TLS Certificate, 723 TLS CertificateVerify, 724 <-------- TLS Finished, 725 EAP-Response/ 726 EAP-Type=EAP-TLS 727 (TLS Certificate, 728 TLS CertificateVerify, 729 TLS Finished) --------> 730 EAP-Request/ 731 EAP-Type=EAP-TLS 732 <-------- TLS Application Data) 733 EAP-Response/ 734 EAP-Type=EAP-TLS --------> 735 <-------- EAP-Success 737 Figure 9: Commit in separate EAP-Request 739 3. Detailed Description of the EAP-TLS Protocol 741 No updates to [RFC5216]. 743 4. IANA considerations 745 This section provides guidance to the Internet Assigned Numbers 746 Authority (IANA) regarding registration of values related to the EAP- 747 TLS 1.3 protocol in accordance with [RFC8126]. 749 This memo requires IANA to add the following labels to the TLS 750 Exporter Label Registry defined by [RFC5705]. These labels are used 751 in derivation of Key_Material, IV and Method-Id as defined in 752 Section 2.3: 754 o "EXPORTER_EAP_TLS_Key_Material" 756 o "EXPORTER_EAP_TLS_IV" 758 o "EXPORTER_EAP_TLS_Method-Id" 760 5. Security Considerations 762 5.1. Security Claims 764 Using EAP-TLS with TLS 1.3 does not change the security claims for 765 EAP-TLS as given in Section 4.1 of [RFC5216]. However, it 766 strengthens several of the claims as described in the following 767 updates to the notes given in Section 4.1 of [RFC5216]. 769 [1] Mutual authentication: By mandating revocation checking of 770 certificates, the authentication in EAP-TLS with TLS 1.3 is stronger 771 as authentication with revoked certificates will always fail. 773 [2] Confidentiality: The TLS 1.3 handshake offers much better 774 confidentiality than earlier versions of TLS by mandating cipher 775 suites with confidentiality and encrypting certificates and some of 776 the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the 777 use of privacy is mandatory and does not cause any additional round- 778 trips. 780 [3] Key strength: TLS 1.3 forbids all algorithms with known 781 weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 782 only supports cryptographic algorithms offering at least 112-bit 783 security, see [RFC8446]. 785 [4] Cryptographic Negotiation: TLS 1.3 increases the number of 786 cryptographic parameters that are negotiated in the handshake. When 787 EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic 788 negotiation of AEAD algorithm, HKDF hash algorithm, key exchange 789 groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. 791 5.2. Peer and Server Identities 793 No updates to [RFC5216]. 795 5.3. Certificate Validation 797 No updates to [RFC5216]. 799 5.4. Certificate Revocation 801 While certificates often have a long validity period spanning several 802 years, there are a number of reasons (e.g. key compromise, CA 803 compromise, privilege withdrawn, etc.) why client, server, or sub-CA 804 certificates have to be revoked before their expiry date. Revocation 805 of the EAP server's certificate is complicated by the fact that the 806 EAP peer may not have Internet connectivity until authentication 807 completes. 809 EAP-TLS peers and servers supporting TLS 1.3 MUST support Certificate 810 Status Requests (OCSP stapling) as specified in [RFC6066] and 811 Section 4.4.2.1 of [RFC8446]. When EAP-TLS is used with TLS 1.3, the 812 peer and server MUST use Certificate Status Requests [RFC6066] for 813 the server's certificate chain and the EAP peer MUST treat a 814 CertificateEntry (except the trust anchor) without a valid 815 CertificateStatus extension as invalid and abort the handshake with 816 an appropriate alert. When EAP-TLS is used with TLS 1.3, the server 817 MUST check the revocation status of the certificates in the 818 certificates in the client's certificate chain. 820 The OCSP status handling in TLS 1.3 is different from earlier 821 versions of TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the 822 OCSP information is carried in the CertificateEntry containing the 823 associated certificate instead of a separate CertificateStatus 824 message as in [RFC4366]. This enables sending OCSP information for 825 all certificates in the certificate chain. 827 5.5. Packet Modification Attacks 829 No updates to [RFC5216]. 831 5.6. Authorization 833 EAP-TLS is typically encapsulated in other protocols, such as PPP 834 [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. 835 The encapsulating protocols can also provide additional, non-EAP 836 information to an EAP server. This information can include, but is 837 not limited to, information about the authenticator, information 838 about the EAP peer, or information about the protocol layers above or 839 below EAP (MAC addresses, IP addresses, port numbers, WiFi SSID, 840 etc.). Servers implementing EAP-TLS inside those protocols can make 841 policy decisions and enforce authorization based on a combination of 842 information from the EAP-TLS exchange and non-EAP information. 844 As noted in Section 2.2, the identity presented in EAP-Response/ 845 Identity is not authenticated by EAP-TLS and is therefore trivial for 846 an attacker to forge, modify, or replay. Authorization and 847 accounting MUST be based on authenticated information such as 848 information in the certificate or the PSK identity and cached data 849 provisioned for resumption as described in Section 5.7. Note that 850 the requirements for Network Access Identifiers (NAIs) specified in 851 Section 4 of [RFC7542] still apply and MUST be followed. 853 EAP-TLS servers MAY reject conversations based on non-EAP information 854 provided by the encapsulating protocol, for example, if the MAC 855 address of the authenticator does not match the expected policy. 857 5.7. Resumption 859 There are a number of security issues related to resumption that are 860 not described in [RFC5216]. The problems, guidelines, and 861 requirements in this section therefore applies to all version of TLS. 863 When resumption occurs, it is based on cached information at the TLS 864 layer. To perform resumption in a secure way, the EAP-TLS peer and 865 EAP-TLS server need to be able to securely retrieve authorization 866 information such as certificate chains, revocation status, etc. from 867 the initial full handshake. We use the term "cached data" to 868 describe such information. Authorization during resumption MUST be 869 based on such cached data. 871 There are two ways to retrieve the cached information from the 872 original full handshake. The first method is that the TLS server and 873 client cache the information locally. The cached information is 874 identified by an identifier. For TLS versions before 1.3, the 875 identifier can be the session ID, for TLS 1.3, the identifier is the 876 PSK identity. The second method for retrieving cached information is 877 via [RFC5077] or [RFC8446], where the TLS server encapsulates the 878 information into a ticket and sends it to the client. The client can 879 subsequently do resumption using the obtained ticket. Note that the 880 client still needs to cache the information locally. The following 881 requirements apply to both methods. 883 If the EAP server or EAP client do not apply any authorization 884 policies, they MAY allow resumption where no cached data is 885 available. In all other cases, they MUST cache data during the 886 initial full authentication to enable resumption. The cached data 887 MUST be sufficient to make authorization decisions during resumption. 888 If cached data cannot be retrieved in a secure way, resumption MUST 889 NOT be done. 891 The above requirements also apply if the EAP server expects some 892 system to perform accounting for the session. Since accounting must 893 be tied to an authenticated identity, and resumption does not supply 894 such an identity, accounting is impossible without access to cached 895 data. 897 Information from the EAP-TLS exchange (e.g. the identity provided in 898 EAP-Response/Identity) as well as non-EAP information (e.g. IP 899 addresses) may change between the initial full handshake and 900 resumption. This change creates a "Time-of-check time-of-use" 901 (TOCTOU) security vulnerability. A malicious or compromised user 902 could supply one set of data during the initial authentication, and a 903 different set of data during resumption, potentially leading to them 904 obtaining access that they should not have. 906 If any authorization, accounting, or policy decisions were made with 907 information that have changed between the initial full handshake and 908 resumption, and if change may lead to a different decision, such 909 decisions MUST be reevaluated. It is RECOMMENDED that authorization, 910 accounting, and policy decisions are reevaluated based on the 911 information given in the resumption. EAP servers MAY reject 912 resumption where the information supplied during resumption does not 913 match the information supplied during the original authentication. 914 Where a good decision is unclear, EAP servers SHOULD reject the 915 resumption. 917 Any security policies for authorization MUST be followed also for 918 resumption. The EAP-TLS client and server MAY need to recheck the 919 authorization and revocation status of the other party. The 920 certificates may have been revoked since the initial full handshake 921 and the authorizations of the other party may have been reduced. If 922 the cached revocation information is not sufficiently current, the 923 EAP Peer or EAP Server needs to force a full TLS handshake. 925 5.8. Privacy Considerations 927 [RFC6973] suggests that the privacy considerations of IETF protocols 928 be documented. 930 TLS 1.3 offers much better privacy than earlier versions of TLS as 931 discussed in Section 2.1.7. In this section, we only discuss the 932 privacy properties of EAP-TLS with TLS 1.3. For privacy properties 933 of TLS 1.3 itself, see [RFC8446]. 935 EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in 936 EAP packets. Additionally, the EAP peer sends an identity in the 937 first EAP-Response. The other fields in the EAP-TLS Request and the 938 EAP-TLS Response packets do not contain any cleartext privacy 939 sensitive information. 941 Tracking of users by eavesdropping on identity responses or 942 certificates is a well-known problem in many EAP methods. When EAP- 943 TLS is used with TLS 1.3, all certificates are encrypted, and the 944 username part of the identity response is always confidentiality 945 protected (e.g. using Anonymous NAIs). However, as with other EAP 946 methods, even when privacy-friendly identifiers or EAP tunneling is 947 used, the domain name (i.e. the realm) in the NAI is still typically 948 visible. How much privacy sensitive information the domain name 949 leaks is highly dependent on how many other users are using the same 950 domain name in the particular access network. If all EAP peers have 951 the same domain, no additional information is leaked. If a domain 952 name is used by a small subset of the EAP peers, it may aid an 953 attacker in tracking or identifying the user. 955 If Anonymous NAIs are not used, the privacy-friendly identifiers need 956 to be generated with care. The identities MUST be generated in a 957 cryptographically secure way so that that it is computationally 958 infeasible for an attacker to differentiate two identities belonging 959 to the same user from two identities belonging to different users in 960 the same realm. This can be achieved, for instance, by using random 961 or pseudo-random usernames such as random byte strings or 962 ciphertexts. Note that the privacy-friendly usernames also MUST NOT 963 include substrings that can be used to relate the identity to a 964 specific user. Similarly, privacy-friendly username SHOULD NOT be 965 formed by a fixed mapping that stays the same across multiple 966 different authentications. 968 An EAP peer with a policy allowing communication with EAP servers 969 supporting only TLS 1.2 without privacy and with a static RSA key 970 exchange is vulnerable to disclosure of the peer username. An active 971 attacker can in this case make the EAP peer believe that an EAP 972 server supporting TLS 1.3 only supports TLS 1.2 without privacy. The 973 attacker can simply impersonate the EAP server and negotiate TLS 1.2 974 with static RSA key exchange and send an TLS alert message when the 975 EAP peer tries to use privacy by sending an empty certificate 976 message. Since the attacker (impersonating the EAP server) does not 977 provide a proof-of-possession of the private key until the Finished 978 message when a static RSA key exchange is used, an EAP peer may 979 inadvertently disclose its identity (username) to an attacker. 980 Therefore, it is RECOMMENDED for EAP peers to not use EAP-TLS with 981 TLS 1.2 and static RSA based cipher suites without privacy. 983 5.9. Pervasive Monitoring 985 As required by [RFC7258], work on IETF protocols needs to consider 986 the effects of pervasive monitoring and mitigate them when possible. 988 Pervasive Monitoring is widespread surveillance of users. By 989 encrypting more information and by mandating the use of privacy, TLS 990 1.3 offers much better protection against pervasive monitoring. In 991 addition to the privacy attacks discussed above, surveillance on a 992 large scale may enable tracking of a user over a wider geographical 993 area and across different access networks. Using information from 994 EAP-TLS together with information gathered from other protocols 995 increases the risk of identifying individual users. 997 5.10. Discovered Vulnerabilities 999 Over the years, there have been several serious attacks on earlier 1000 versions of Transport Layer Security (TLS), including attacks on its 1001 most commonly used ciphers and modes of operation. [RFC7457] 1002 summarizes the attacks that were known at the time of publishing and 1003 [RFC7525] provides recommendations for improving the security of 1004 deployed services that use TLS. However, many of the attacks are 1005 less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and 1006 does not protect any application data. EAP-TLS implementations 1007 SHOULD mitigate known attacks and follow the recommendations in 1008 [RFC7525] and [I-D.ietf-tls-oldversions-deprecate]. The use of TLS 1009 1.3 mitigates most of the known attacks. 1011 6. References 1013 6.1. Normative References 1015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1016 Requirement Levels", BCP 14, RFC 2119, 1017 DOI 10.17487/RFC2119, March 1997, 1018 . 1020 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1021 Levkowetz, Ed., "Extensible Authentication Protocol 1022 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1023 . 1025 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1026 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 1027 March 2008, . 1029 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1030 Housley, R., and W. Polk, "Internet X.509 Public Key 1031 Infrastructure Certificate and Certificate Revocation List 1032 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1033 . 1035 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1036 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1037 March 2010, . 1039 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1040 Extensions: Extension Definitions", RFC 6066, 1041 DOI 10.17487/RFC6066, January 2011, 1042 . 1044 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1045 Galperin, S., and C. Adams, "X.509 Internet Public Key 1046 Infrastructure Online Certificate Status Protocol - OCSP", 1047 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1048 . 1050 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1051 DOI 10.17487/RFC7542, May 2015, 1052 . 1054 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1055 (TLS) Cached Information Extension", RFC 7924, 1056 DOI 10.17487/RFC7924, July 2016, 1057 . 1059 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1060 Writing an IANA Considerations Section in RFCs", BCP 26, 1061 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1062 . 1064 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1065 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1066 May 2017, . 1068 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1069 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1070 . 1072 6.2. Informative references 1074 [I-D.ietf-tls-certificate-compression] 1075 Ghedini, A. and V. Vasiliev, "TLS Certificate 1076 Compression", draft-ietf-tls-certificate-compression-05 1077 (work in progress), April 2019. 1079 [I-D.ietf-tls-oldversions-deprecate] 1080 Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and 1081 TLSv1.1", draft-ietf-tls-oldversions-deprecate-05 (work in 1082 progress), June 2019. 1084 [IEEE-802.11] 1085 Institute of Electrical and Electronics Engineers, "IEEE 1086 Standard for Information technology--Telecommunications 1087 and information exchange between systems Local and 1088 metropolitan area networks--Specific requirements - Part 1089 11: Wireless LAN Medium Access Control (MAC) and Physical 1090 Layer (PHY) Specifications", IEEE Std 802.11-2016 1091 (Revision of IEEE Std 802.11-2012) , December 2016. 1093 [IEEE-802.1X] 1094 Institute of Electrical and Electronics Engineers, "IEEE 1095 Standard for Local and metropolitan area networks -- Port- 1096 Based Network Access Control", IEEE Standard 802.1X-2010 , 1097 February 2010. 1099 [MulteFire] 1100 MulteFire, "MulteFire Release 1.1 specification", 2019. 1102 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 1103 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 1104 . 1106 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1107 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1108 . 1110 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1111 Adams, "X.509 Internet Public Key Infrastructure Online 1112 Certificate Status Protocol - OCSP", RFC 2560, 1113 DOI 10.17487/RFC2560, June 1999, 1114 . 1116 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1117 "Remote Authentication Dial In User Service (RADIUS)", 1118 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1119 . 1121 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1122 X.509 Public Key Infrastructure Certificate and 1123 Certificate Revocation List (CRL) Profile", RFC 3280, 1124 DOI 10.17487/RFC3280, April 2002, 1125 . 1127 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1128 Network Access Identifier", RFC 4282, 1129 DOI 10.17487/RFC4282, December 2005, 1130 . 1132 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1133 (TLS) Protocol Version 1.1", RFC 4346, 1134 DOI 10.17487/RFC4346, April 2006, 1135 . 1137 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1138 and T. Wright, "Transport Layer Security (TLS) 1139 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 1140 . 1142 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1143 "Transport Layer Security (TLS) Session Resumption without 1144 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1145 January 2008, . 1147 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1148 and A. Yegin, "Protocol for Carrying Authentication for 1149 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1150 May 2008, . 1152 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1153 (TLS) Protocol Version 1.2", RFC 5246, 1154 DOI 10.17487/RFC5246, August 2008, 1155 . 1157 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1158 Authentication Protocol (EAP) Key Management Framework", 1159 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1160 . 1162 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1163 Ed., "Diameter Base Protocol", RFC 6733, 1164 DOI 10.17487/RFC6733, October 2012, 1165 . 1167 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1168 Morris, J., Hansen, M., and R. Smith, "Privacy 1169 Considerations for Internet Protocols", RFC 6973, 1170 DOI 10.17487/RFC6973, July 2013, 1171 . 1173 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1174 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1175 2014, . 1177 [RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., 1178 and D. Kroeselberg, "Extensions to the Emergency Services 1179 Architecture for Dealing With Unauthenticated and 1180 Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, 1181 December 2014, . 1183 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1184 Known Attacks on Transport Layer Security (TLS) and 1185 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1186 February 2015, . 1188 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1189 "Recommendations for Secure Use of Transport Layer 1190 Security (TLS) and Datagram Transport Layer Security 1191 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1192 2015, . 1194 [TS.33.501] 1195 3GPP, "Security architecture and procedures for 5G 1196 System", 3GPP TS 33.501 15.5.0, June 2019. 1198 Appendix A. Updated references 1200 All the following references in [RFC5216] are updated as specified 1201 below when EAP-TLS is used with TLS 1.3 or higher. 1203 All references to [RFC2560] are updated with [RFC6960]. 1205 All references to [RFC3280] are updated with [RFC5280]. 1207 All references to [RFC4282] are updated with [RFC7542]. 1209 Acknowledgments 1211 The authors want to thank Bernard Aboba, Jari Arkko, Alan DeKok, Ari 1212 Keraenen, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, and 1213 Vesa Torvinen for comments and suggestions on the draft. 1215 Contributors 1217 Alan DeKok, FreeRADIUS 1219 Authors' Addresses 1220 John Mattsson 1221 Ericsson 1222 Stockholm 164 40 1223 Sweden 1225 Email: john.mattsson@ericsson.com 1227 Mohit Sethi 1228 Ericsson 1229 Jorvas 02420 1230 Finland 1232 Email: mohit@piuha.net