idnits 2.17.1 draft-ietf-emu-eap-tls13-05.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 (May 26, 2019) is 1768 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 726 -- Looks like a reference, but probably isn't: '2' on line 730 -- Looks like a reference, but probably isn't: '3' on line 737 -- Looks like a reference, but probably isn't: '4' on line 742 == 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-04 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 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 May 26, 2019 6 Expires: November 27, 2019 8 Using EAP-TLS with TLS 1.3 9 draft-ietf-emu-eap-tls13-05 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 November 27, 2019. 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 . . . . . . . . 16 71 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 17 74 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 17 75 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 17 76 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 17 77 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 18 78 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 18 79 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 19 80 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 20 81 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 21 82 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 21 83 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 6.1. Normative References . . . . . . . . . . . . . . . . . . 22 85 6.2. Informative references . . . . . . . . . . . . . . . . . 23 86 Appendix A. Updated references . . . . . . . . . . . . . . . . . 26 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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 an empty 182 TLS record, 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 empty record) 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 empty record) 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 empty record) 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 empty record) 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 empty record) 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 empty record) 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 empty record) 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 appending an empty application data record (i.e. a TLS 690 record with TLSPlaintext.type = application_data and 691 TLSPlaintext.length = 0) to the last handshake record. After sending 692 an empty application data record, the EAP server may only send an 693 EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert 694 Message. 696 3. Detailed Description of the EAP-TLS Protocol 698 No updates to [RFC5216]. 700 4. IANA considerations 702 This section provides guidance to the Internet Assigned Numbers 703 Authority (IANA) regarding registration of values related to the EAP- 704 TLS 1.3 protocol in accordance with [RFC8126]. 706 This memo requires IANA to add the following labels to the TLS 707 Exporter Label Registry defined by [RFC5705]. These labels are used 708 in derivation of Key_Material, IV and Method-Id as defined in 709 Section 2.3: 711 o "EXPORTER_EAP_TLS_Key_Material" 713 o "EXPORTER_EAP_TLS_IV" 715 o "EXPORTER_EAP_TLS_Method-Id" 717 5. Security Considerations 719 5.1. Security Claims 721 Using EAP-TLS with TLS 1.3 does not change the security claims for 722 EAP-TLS as given in Section 4.1 of [RFC5216]. However, it 723 strengthens several of the claims as described in the following 724 updates to the notes given in Section 4.1 of [RFC5216]. 726 [1] Mutual authentication: By mandating revocation checking of 727 certificates, the authentication in EAP-TLS with TLS 1.3 is stronger 728 as authentication with revoked certificates will always fail. 730 [2] Confidentiality: The TLS 1.3 handshake offers much better 731 confidentiality than earlier versions of TLS by mandating cipher 732 suites with confidentiality and encrypting certificates and some of 733 the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the 734 use of privacy is mandatory and does not cause any additional round- 735 trips. 737 [3] Key strength: TLS 1.3 forbids all algorithms with known 738 weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 739 only supports cryptographic algorithms offering at least 112-bit 740 security, see [RFC8446]. 742 [4] Cryptographic Negotiation: TLS 1.3 increases the number of 743 cryptographic parameters that are negotiated in the handshake. When 744 EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic 745 negotiation of AEAD algorithm, HKDF hash algorithm, key exchange 746 groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. 748 5.2. Peer and Server Identities 750 No updates to [RFC5216]. 752 5.3. Certificate Validation 754 No updates to [RFC5216]. 756 5.4. Certificate Revocation 758 While certificates often have a long validity period spanning several 759 years, there are a number of reasons (e.g. key compromise, CA 760 compromise, privilege withdrawn, etc.) why client, server, or sub-CA 761 certificates have to be revoked before their expiry date. Revocation 762 of the EAP server's certificate is complicated by the fact that the 763 EAP peer may not have Internet connectivity until authentication 764 completes. 766 EAP-TLS peers and servers supporting TLS 1.3 MUST support Certificate 767 Status Requests (OCSP stapling) as specified in [RFC6066] and 768 Section 4.4.2.1 of [RFC8446]. When EAP-TLS is used with TLS 1.3, the 769 peer and server MUST use Certificate Status Requests [RFC6066] for 770 the server's certificate chain and the EAP peer MUST treat a 771 CertificateEntry (except the trust anchor) without a valid 772 CertificateStatus extension as invalid and abort the handshake with 773 an appropriate alert. When EAP-TLS is used with TLS 1.3, the server 774 MUST check the revocation status of the certificates in the 775 certificates in the client's certificate chain. 777 The OCSP status handling in TLS 1.3 is different from earlier 778 versions of TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the 779 OCSP information is carried in the CertificateEntry containing the 780 associated certificate instead of a separate CertificateStatus 781 message as in [RFC4366]. This enables sending OCSP information for 782 all certificates in the certificate chain. 784 5.5. Packet Modification Attacks 786 No updates to [RFC5216]. 788 5.6. Authorization 790 EAP-TLS is typically encapsulated in other protocols, such as PPP 791 [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. 792 The encapsulating protocols can also provide additional, non-EAP 793 information to an EAP server. This information can include, but is 794 not limited to, information about the authenticator, information 795 about the EAP peer, or information about the protocol layers above or 796 below EAP (MAC addresses, IP addresses, port numbers, WiFi SSID, 797 etc.). Servers implementing EAP-TLS inside those protocols can make 798 policy decisions and enforce authorization based on a combination of 799 information from the EAP-TLS exchange and non-EAP information. 801 As noted in Section 2.2, the identity presented in EAP-Response/ 802 Identity is not authenticated by EAP-TLS and is therefore trivial for 803 an attacker to forge, modify, or replay. Authorization and 804 accounting MUST be based on authenticated information such as 805 information in the certificate or the PSK identity and cached data 806 provisioned for resumption as described in Section 5.7. Note that 807 the requirements for Network Access Identifiers (NAIs) specified in 808 Section 4 of [RFC7542] still apply and MUST be followed. 810 EAP-TLS servers MAY reject conversations based on non-EAP information 811 provided by the encapsulating protocol, for example, if the MAC 812 address of the authenticator does not match the expected policy. 814 5.7. Resumption 816 There are a number of security issues related to resumption that are 817 not described in [RFC5216]. The problems, guidelines, and 818 requirements in this section therefore applies to all version of TLS. 820 When resumption occurs, it is based on cached information at the TLS 821 layer. To perform resumption in a secure way, the EAP-TLS peer and 822 EAP-TLS server need to be able to securely retrieve authorization 823 information such as certificate chains, revocation status, etc. from 824 the initial full handshake. We use the term "cached data" to 825 describe such information. Authorization during resumption MUST be 826 based on such cached data. 828 There are two ways to retrieve the cached information from the 829 original full handshake. The first method is that the TLS server and 830 client cache the information locally. The cached information is 831 identified by an identifier. For TLS versions before 1.3, the 832 identifier can be the session ID, for TLS 1.3, the identifier is the 833 PSK identity. The second method for retrieving cached information is 834 via [RFC5077] or [RFC8446], where the TLS server encapsulates the 835 information into a ticket and sends it to the client. The client can 836 subsequently do resumption using the obtained ticket. Note that the 837 client still needs to cache the information locally. The following 838 requirements apply to both methods. 840 If the EAP server or EAP client do not apply any authorization 841 policies, they MAY allow resumption where no cached data is 842 available. In all other cases, they MUST cache data during the 843 initial full authentication to enable resumption. The cached data 844 MUST be sufficient to make authorization decisions during resumption. 845 If cached data cannot be retrieved in a secure way, resumption MUST 846 NOT be done. 848 The above requirements also apply if the EAP server expects some 849 system to perform accounting for the session. Since accounting must 850 be tied to an authenticated identity, and resumption does not supply 851 such an identity, accounting is impossible without access to cached 852 data. 854 Information from the EAP-TLS exchange (e.g. the identity provided in 855 EAP-Response/Identity) as well as non-EAP information (e.g. IP 856 addresses) may change between the initial full handshake and 857 resumption. This change creates a "Time-of-check time-of-use" 858 (TOCTOU) security vulnerability. A malicious or compromised user 859 could supply one set of data during the initial authentication, and a 860 different set of data during resumption, potentially leading to them 861 obtaining access that they should not have. 863 If any authorization, accounting, or policy decisions were made with 864 information that have changed between the initial full handshake and 865 resumption, and if change may lead to a different decision, such 866 decisions MUST be reevaluated. It is RECOMMENDED that authorization, 867 accounting, and policy decisions are reevaluated based on the 868 information given in the resumption. EAP servers MAY reject 869 resumption where the information supplied during resumption does not 870 match the information supplied during the original authentication. 871 Where a good decision is unclear, EAP servers SHOULD reject the 872 resumption. 874 Any security policies for authorization MUST be followed also for 875 resumption. The EAP-TLS client and server MAY need to recheck the 876 authorization and revocation status of the other party. The 877 certificates may have been revoked since the initial full handshake 878 and the authorizations of the other party may have been reduced. If 879 the cached revocation information is not sufficiently current, the 880 EAP Peer or EAP Server needs to force a full TLS handshake. 882 5.8. Privacy Considerations 884 [RFC6973] suggests that the privacy considerations of IETF protocols 885 be documented. 887 TLS 1.3 offers much better privacy than earlier versions of TLS as 888 discussed in Section 2.1.7. In this section, we only discuss the 889 privacy properties of EAP-TLS with TLS 1.3. For privacy properties 890 of TLS 1.3 itself, see [RFC8446]. 892 EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in 893 EAP packets. Additionally, the EAP peer sends an identity in the 894 first EAP-Response. The other fields in the EAP-TLS Request and the 895 EAP-TLS Response packets do not contain any cleartext privacy 896 sensitive information. 898 Tracking of users by eavesdropping on identity responses or 899 certificates is a well-known problem in many EAP methods. When EAP- 900 TLS is used with TLS 1.3, all certificates are encrypted, and the 901 username part of the identity response is always confidentiality 902 protected (e.g. using Anonymous NAIs). However, as with other EAP 903 methods, even when privacy-friendly identifiers or EAP tunneling is 904 used, the domain name (i.e. the realm) in the NAI is still typically 905 visible. How much privacy sensitive information the domain name 906 leaks is highly dependent on how many other users are using the same 907 domain name in the particular access network. If all EAP peers have 908 the same domain, no additional information is leaked. If a domain 909 name is used by a small subset of the EAP peers, it may aid an 910 attacker in tracking or identifying the user. 912 If Anonymous NAIs are not used, the privacy-friendly identifiers need 913 to be generated with care. The identities MUST be generated in a 914 cryptographically secure way so that that it is computationally 915 infeasible for an attacker to differentiate two identities belonging 916 to the same user from two identities belonging to different users in 917 the same realm. This can be achieved, for instance, by using random 918 or pseudo-random usernames such as random byte strings or 919 ciphertexts. Note that the privacy-friendly usernames also MUST NOT 920 include substrings that can be used to relate the identity to a 921 specific user. Similarly, privacy-friendly username SHOULD NOT be 922 formed by a fixed mapping that stays the same across multiple 923 different authentications. 925 An EAP peer with a policy allowing communication with EAP servers 926 supporting only TLS 1.2 without privacy and with a static RSA key 927 exchange is vulnerable to disclosure of the peer username. An active 928 attacker can in this case make the EAP peer believe that an EAP 929 server supporting TLS 1.3 only supports TLS 1.2 without privacy. The 930 attacker can simply impersonate the EAP server and negotiate TLS 1.2 931 with static RSA key exchange and send an TLS alert message when the 932 EAP peer tries to use privacy by sending an empty certificate 933 message. Since the attacker (impersonating the EAP server) does not 934 provide a proof-of-possession of the private key until the Finished 935 message when a static RSA key exchange is used, an EAP peer may 936 inadvertently disclose its identity (username) to an attacker. 937 Therefore, it is RECOMMENDED for EAP peers to not use EAP-TLS with 938 TLS 1.2 and static RSA based cipher suites without privacy. 940 5.9. Pervasive Monitoring 942 As required by [RFC7258], work on IETF protocols needs to consider 943 the effects of pervasive monitoring and mitigate them when possible. 945 Pervasive Monitoring is widespread surveillance of users. By 946 encrypting more information and by mandating the use of privacy, TLS 947 1.3 offers much better protection against pervasive monitoring. In 948 addition to the privacy attacks discussed above, surveillance on a 949 large scale may enable tracking of a user over a wider geographical 950 area and across different access networks. Using information from 951 EAP-TLS together with information gathered from other protocols 952 increases the risk of identifying individual users. 954 5.10. Discovered Vulnerabilities 956 Over the years, there have been several serious attacks on earlier 957 versions of Transport Layer Security (TLS), including attacks on its 958 most commonly used ciphers and modes of operation. [RFC7457] 959 summarizes the attacks that were known at the time of publishing and 961 [RFC7525] provides recommendations for improving the security of 962 deployed services that use TLS. However, many of the attacks are 963 less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and 964 does not protect any application data. EAP-TLS implementations 965 SHOULD mitigate known attacks and follow the recommendations in 966 [RFC7525] and [I-D.ietf-tls-oldversions-deprecate]. The use of TLS 967 1.3 mitigates most of the known attacks. 969 6. References 971 6.1. Normative References 973 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 974 Requirement Levels", BCP 14, RFC 2119, 975 DOI 10.17487/RFC2119, March 1997, 976 . 978 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 979 Levkowetz, Ed., "Extensible Authentication Protocol 980 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 981 . 983 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 984 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 985 March 2008, . 987 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 988 Housley, R., and W. Polk, "Internet X.509 Public Key 989 Infrastructure Certificate and Certificate Revocation List 990 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 991 . 993 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 994 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 995 March 2010, . 997 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 998 Extensions: Extension Definitions", RFC 6066, 999 DOI 10.17487/RFC6066, January 2011, 1000 . 1002 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1003 Galperin, S., and C. Adams, "X.509 Internet Public Key 1004 Infrastructure Online Certificate Status Protocol - OCSP", 1005 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1006 . 1008 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1009 DOI 10.17487/RFC7542, May 2015, 1010 . 1012 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1013 (TLS) Cached Information Extension", RFC 7924, 1014 DOI 10.17487/RFC7924, July 2016, 1015 . 1017 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1018 Writing an IANA Considerations Section in RFCs", BCP 26, 1019 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1020 . 1022 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1023 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1024 May 2017, . 1026 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1027 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1028 . 1030 6.2. Informative references 1032 [I-D.ietf-tls-certificate-compression] 1033 Ghedini, A. and V. Vasiliev, "TLS Certificate 1034 Compression", draft-ietf-tls-certificate-compression-05 1035 (work in progress), April 2019. 1037 [I-D.ietf-tls-oldversions-deprecate] 1038 Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and 1039 TLSv1.1", draft-ietf-tls-oldversions-deprecate-04 (work in 1040 progress), May 2019. 1042 [IEEE-802.11] 1043 Institute of Electrical and Electronics Engineers, "IEEE 1044 Standard for Information technology--Telecommunications 1045 and information exchange between systems Local and 1046 metropolitan area networks--Specific requirements - Part 1047 11: Wireless LAN Medium Access Control (MAC) and Physical 1048 Layer (PHY) Specifications", IEEE Std 802.11-2016 1049 (Revision of IEEE Std 802.11-2012) , December 2016. 1051 [IEEE-802.1X] 1052 Institute of Electrical and Electronics Engineers, "IEEE 1053 Standard for Local and metropolitan area networks -- Port- 1054 Based Network Access Control", IEEE Standard 802.1X-2010 , 1055 February 2010. 1057 [MulteFire] 1058 MulteFire, "MulteFire Release 1.0.1 specification", 2017. 1060 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 1061 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 1062 . 1064 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1065 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1066 . 1068 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1069 Adams, "X.509 Internet Public Key Infrastructure Online 1070 Certificate Status Protocol - OCSP", RFC 2560, 1071 DOI 10.17487/RFC2560, June 1999, 1072 . 1074 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1075 "Remote Authentication Dial In User Service (RADIUS)", 1076 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1077 . 1079 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1080 X.509 Public Key Infrastructure Certificate and 1081 Certificate Revocation List (CRL) Profile", RFC 3280, 1082 DOI 10.17487/RFC3280, April 2002, 1083 . 1085 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1086 Network Access Identifier", RFC 4282, 1087 DOI 10.17487/RFC4282, December 2005, 1088 . 1090 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1091 (TLS) Protocol Version 1.1", RFC 4346, 1092 DOI 10.17487/RFC4346, April 2006, 1093 . 1095 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1096 and T. Wright, "Transport Layer Security (TLS) 1097 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 1098 . 1100 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1101 "Transport Layer Security (TLS) Session Resumption without 1102 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1103 January 2008, . 1105 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1106 and A. Yegin, "Protocol for Carrying Authentication for 1107 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1108 May 2008, . 1110 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1111 (TLS) Protocol Version 1.2", RFC 5246, 1112 DOI 10.17487/RFC5246, August 2008, 1113 . 1115 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1116 Authentication Protocol (EAP) Key Management Framework", 1117 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1118 . 1120 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1121 Ed., "Diameter Base Protocol", RFC 6733, 1122 DOI 10.17487/RFC6733, October 2012, 1123 . 1125 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1126 Morris, J., Hansen, M., and R. Smith, "Privacy 1127 Considerations for Internet Protocols", RFC 6973, 1128 DOI 10.17487/RFC6973, July 2013, 1129 . 1131 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1132 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1133 2014, . 1135 [RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., 1136 and D. Kroeselberg, "Extensions to the Emergency Services 1137 Architecture for Dealing With Unauthenticated and 1138 Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, 1139 December 2014, . 1141 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1142 Known Attacks on Transport Layer Security (TLS) and 1143 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1144 February 2015, . 1146 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1147 "Recommendations for Secure Use of Transport Layer 1148 Security (TLS) and Datagram Transport Layer Security 1149 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1150 2015, . 1152 [TS.33.501] 1153 3GPP, "Security architecture and procedures for 5G 1154 System", 3GPP TS 33.501 15.4.0, March 2019. 1156 Appendix A. Updated references 1158 All the following references in [RFC5216] are updated as specified 1159 below when EAP-TLS is used with TLS 1.3 or higher. 1161 All references to [RFC2560] are updated with [RFC6960]. 1163 All references to [RFC3280] are updated with [RFC5280]. 1165 All references to [RFC4282] are updated with [RFC7542]. 1167 Acknowledgments 1169 The authors want to thank Bernard Aboba, Jari Arkko, Alan DeKok, Ari 1170 Keraenen, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, and 1171 Vesa Torvinen for comments and suggestions on the draft. 1173 Contributors 1175 Alan DeKok, FreeRADIUS 1177 Authors' Addresses 1179 John Mattsson 1180 Ericsson 1181 Stockholm 164 40 1182 Sweden 1184 Email: john.mattsson@ericsson.com 1186 Mohit Sethi 1187 Ericsson 1188 Jorvas 02420 1189 Finland 1191 Email: mohit@piuha.net