idnits 2.17.1 draft-ietf-emu-eap-tls13-04.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 (March 11, 2019) is 1866 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 710 -- Looks like a reference, but probably isn't: '2' on line 714 -- Looks like a reference, but probably isn't: '3' on line 721 -- Looks like a reference, but probably isn't: '4' on line 726 == Unused Reference: 'RFC7301' is defined on line 1123, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-tls-certificate-compression-04 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 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 March 11, 2019 6 Expires: September 12, 2019 8 Using EAP-TLS with TLS 1.3 9 draft-ietf-emu-eap-tls13-04 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 September 12, 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. Base Case . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1.2. Resumption . . . . . . . . . . . . . . . . . . . . . 7 60 2.1.3. Termination . . . . . . . . . . . . . . . . . . . . . 9 61 2.1.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . 13 62 2.1.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 14 63 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 15 64 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 15 65 2.4. Parameter Negotiation and Compliance Requirements . . . . 16 66 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 17 67 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 17 68 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 70 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 18 71 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 18 72 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 18 73 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 18 74 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 19 75 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 19 76 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 20 77 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 21 78 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 22 79 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 23 80 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 6.1. Normative References . . . . . . . . . . . . . . . . . . 23 82 6.2. Informative references . . . . . . . . . . . . . . . . . 24 83 Appendix A. Updated references . . . . . . . . . . . . . . . . . 27 84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 27 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 88 1. Introduction 90 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 91 provides a standard mechanism for support of multiple authentication 92 methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies 93 an EAP authentication method with certificate-based mutual 94 authentication and key derivation utilizing the TLS handshake 95 protocol for cryptographic algorithms and protocol version 96 negotiation, mutual authentication, and establishment of shared 97 secret keying material. EAP-TLS is widely supported for 98 authentication in IEEE 802.11 [IEEE-802.11] networks (Wi-Fi) using 99 IEEE 802.1X [IEEE-802.1X] and it's the default mechanism for 100 certificate based authentication in 3GPP 5G [TS.33.501] and MulteFire 101 [MulteFire] networks. EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] 102 and TLS 1.1 [RFC4346], but works perfectly also with TLS 1.2 103 [RFC5246]. 105 Weaknesses found in previous versions of TLS, as well as new 106 requirements for security, privacy, and reduced latency has led to 107 the development of TLS 1.3 [RFC8446], which in large parts is a 108 complete remodeling of the TLS handshake protocol including a 109 different message flow, different handshake messages, different key 110 schedule, different cipher suites, different resumption, and 111 different privacy protection. This means that significant parts of 112 the normative text in the previous EAP-TLS specification [RFC5216] 113 are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore, 114 aspects such as resumption, privacy handling, and key derivation need 115 to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). 117 This document defines how to use EAP-TLS with TLS 1.3 (or higher) and 118 does not change how EAP-TLS is used with older versions of TLS. 119 While this document updates EAP-TLS [RFC5216], it remains backwards 120 compatible with it and existing implementations of EAP-TLS. This 121 document only describes differences compared to [RFC5216]. 123 In addition to the improved security and privacy offered by TLS 1.3, 124 there are other significant benefits of using EAP-TLS with TLS 1.3. 125 Privacy is mandatory and achieved without any additional round-trips, 126 revocation checking is mandatory and easy with OCSP stapling, and TLS 127 1.3 introduces more possibilities to reduce fragmentation when 128 compared to earlier versions of TLS. 130 1.1. Requirements and Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 Readers are expected to be familiar with the terms and concepts used 139 in EAP-TLS [RFC5216] and TLS [RFC8446]. 141 2. Protocol Overview 143 2.1. Overview of the EAP-TLS Conversation 145 2.1.1. Base Case 147 TLS 1.3 changes both the message flow and the handshake messages 148 compared to earlier versions of TLS. Therefore, much of Section 2.1 149 of RFC5216 [RFC5216] does not apply for TLS 1.3 (or higher). 151 After receiving an EAP-Request packet with EAP-Type=EAP-TLS as 152 described in [RFC5216] the conversation will continue with the TLS 153 handshake protocol encapsulated in the data fields of EAP-Response 154 and EAP-Request packets. When EAP-TLS is used with TLS version 1.3 155 or higher, the formatting and processing of the TLS handshake SHALL 156 be done as specified in that version of TLS. This document only 157 lists additional and different requirements, restrictions, and 158 processing compared to [RFC8446] and [RFC5216]. 160 The EAP server MUST authenticate with a certificate and SHOULD 161 require the EAP peer to authenticate with a certificate. 162 Certificates can be of any type supported by TLS including raw public 163 keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except 164 for resumption. SessionID is deprecated in TLS 1.3 and the EAP 165 server SHALL ignore the legacy_session_id field if TLS 1.3 is 166 negotiated. TLS 1.3 introduces early application data; early 167 application data SHALL NOT be used with EAP-TLS. Resumption is 168 handled as described in Section 2.1.2. After the TLS handshake has 169 completed and all Post-Handshake messages have been sent, the EAP 170 server sends EAP-Success. 172 In the case where EAP-TLS with mutual authentication is successful, 173 the conversation will appear as shown in Figure 1. The EAP server 174 commits to not send any more handshake messages by sending an empty 175 TLS record, see Section 2.5. 177 EAP Peer EAP Server 179 EAP-Request/ 180 <-------- Identity 181 EAP-Response/ 182 Identity (Privacy-Friendly) --------> 183 EAP-Request/ 184 EAP-Type=EAP-TLS 185 <-------- (TLS Start) 186 EAP-Response/ 187 EAP-Type=EAP-TLS 188 (TLS ClientHello) --------> 189 EAP-Request/ 190 EAP-Type=EAP-TLS 191 (TLS ServerHello, 192 TLS EncryptedExtensions, 193 TLS CertificateRequest, 194 TLS Certificate, 195 TLS CertificateVerify, 196 TLS Finished, 197 <-------- TLS empty record) 198 EAP-Response/ 199 EAP-Type=EAP-TLS 200 (TLS Certificate, 201 TLS CertificateVerify, 202 TLS Finished) --------> 203 <-------- EAP-Success 205 Figure 1: EAP-TLS mutual authentication 207 In the case where EAP-TLS is used without peer authentication (e.g., 208 emergency services, as described in [RFC7406]) the conversation will 209 appear as shown in Figure 2. 211 EAP Peer EAP Server 213 EAP-Request/ 214 <-------- Identity 215 EAP-Response/ 216 Identity (Privacy-Friendly) --------> 217 EAP-Request/ 218 EAP-Type=EAP-TLS 219 <-------- (TLS Start) 220 EAP-Response/ 221 EAP-Type=EAP-TLS 222 (TLS ClientHello) --------> 223 EAP-Request/ 224 EAP-Type=EAP-TLS 225 (TLS ServerHello, 226 TLS EncryptedExtensions, 227 TLS Certificate, 228 TLS CertificateVerify, 229 TLS Finished, 230 <-------- TLS empty record) 231 EAP-Response/ 232 EAP-Type=EAP-TLS 233 (TLS Finished) --------> 234 <-------- EAP-Success 236 Figure 2: EAP-TLS without peer authentication 238 When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support 239 of resumption in the initial authentication. To indicate support of 240 resumption, the EAP server sends a NewSessionTicket message 241 (containing a PSK and other parameters) after it has received the 242 Finished message. 244 In the case where EAP-TLS with mutual authentication and ticket 245 establishment is successful, the conversation will appear as shown in 246 Figure 3. 248 EAP Peer EAP Server 250 EAP-Request/ 251 <-------- Identity 252 EAP-Response/ 253 Identity (Privacy-Friendly) --------> 254 EAP-Request/ 255 EAP-Type=EAP-TLS 256 <-------- (TLS Start) 257 EAP-Response/ 258 EAP-Type=EAP-TLS 259 (TLS ClientHello) --------> 260 EAP-Request/ 261 EAP-Type=EAP-TLS 262 (TLS ServerHello, 263 TLS EncryptedExtensions, 264 TLS CertificateRequest, 265 TLS Certificate, 266 TLS CertificateVerify, 267 <-------- TLS Finished) 268 EAP-Response/ 269 EAP-Type=EAP-TLS 270 (TLS Certificate, 271 TLS CertificateVerify, 272 TLS Finished) --------> 273 EAP-Request/ 274 EAP-Type=EAP-TLS 275 (TLS NewSessionTicket, 276 <-------- TLS empty record) 277 EAP-Response/ 278 EAP-Type=EAP-TLS --------> 279 <-------- EAP-Success 281 Figure 3: EAP-TLS ticket establishment 283 2.1.2. Resumption 285 TLS 1.3 replaces the session resumption mechanisms in earlier 286 versions of TLS with a new PSK exchange. When EAP-TLS is used with 287 TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism 288 compatible with that version of TLS. 290 For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If 291 the client has received a NewSessionTicket message from the server, 292 the client can use the PSK identity received in the ticket to 293 negotiate the use of the associated PSK. If the server accepts it, 294 then the security context of the new connection is tied to the 295 original connection and the key derived from the initial handshake is 296 used to bootstrap the cryptographic state instead of a full 297 handshake. It is left up to the EAP peer whether to use resumption, 298 but an EAP peer SHOULD use resumption as long as it has a valid 299 ticket cached. It is RECOMMENDED that the EAP server accept 300 resumption as long as the ticket is valid. However, the server MAY 301 choose to require a full authentication. 303 A subsequent authentication using resumption, where both sides 304 authenticate successfully is shown in Figure 4. 306 EAP Peer EAP Server 308 EAP-Request/ 309 <-------- Identity 310 EAP-Response/ 311 Identity (Privacy-Friendly) --------> 312 EAP-Request/ 313 EAP-Type=EAP-TLS 314 <-------- (TLS Start) 315 EAP-Response/ 316 EAP-Type=EAP-TLS 317 (TLS ClientHello) --------> 318 EAP-Request/ 319 EAP-Type=EAP-TLS 320 (TLS ServerHello, 321 TLS EncryptedExtensions, 322 TLS Finished, 323 <-------- TLS empty record) 324 EAP-Response/ 325 EAP-Type=EAP-TLS 326 (TLS Finished) --------> 327 <-------- EAP-Success 329 Figure 4: EAP-TLS resumption 331 As specified in Section 2.2 of [RFC8446], the EAP peer SHOULD supply 332 a "key_share" extension when offering resumption, which allows the 333 EAP server to decline resumption and continue the handshake as a full 334 handshake. The message flow in this case is given by Figure 1 or 335 Figure 3. If the EAP peer did not supply a "key_share" extension 336 when offering resumption, the EAP server needs to reject the 337 ClientHello and the EAP peer needs to restart a full handshake. The 338 message flow in this case is given by Figure 5 followed by Figure 1 339 or Figure 3. 341 2.1.3. Termination 343 TLS 1.3 changes both the message flow and the handshake messages 344 compared to earlier versions of TLS. Therefore, some normative text 345 in Section 2.1.3 of RFC 5216 [RFC5216] does not apply for TLS 1.3 or 346 higher. The two paragraphs below replaces the corresponding 347 paragraphs in Section 2.1.3 of RFC 5216 [RFC5216] when EAP-TLS is 348 used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 349 of RFC 5216 [RFC5216] still apply with the exception that SessionID 350 is deprecated. 352 If the EAP server authenticates successfully, the EAP peer MUST 353 send an EAP-Response message with EAP-Type=EAP-TLS containing TLS 354 records conforming to the version of TLS used. 356 If the EAP peer authenticates successfully, the EAP server MUST 357 send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS 358 records conforming to the version of TLS used. The message flow 359 ends with the EAP server sending an EAP-Success message. 361 Figures 5, 6, 7, and 8 illustrate message flows in several cases 362 where the EAP peer or EAP server sends a TLS fatal alert message. 363 TLS warning alerts generally mean that the connection can continue 364 normally and does not change the message flow. Note that the party 365 receiving a TLS warning alert may choose to terminate the connection 366 by sending a TLS fatal alert, which may add an extra round-trip, see 367 [RFC8446]. 369 In the case where the server rejects the ClientHello, the 370 conversation will appear as shown in Figure 5. 372 EAP Peer EAP Server 374 EAP-Request/ 375 <-------- Identity 376 EAP-Response/ 377 Identity (Privacy-Friendly) --------> 378 EAP-Request/ 379 EAP-Type=EAP-TLS 380 <-------- (TLS Start) 381 EAP-Response/ 382 EAP-Type=EAP-TLS 383 (TLS ClientHello) --------> 384 EAP-Request/ 385 EAP-Type=EAP-TLS 386 <-------- (TLS Fatal Alert) 387 EAP-Response/ 388 EAP-Type=EAP-TLS --------> 389 <-------- EAP-Failure 391 Figure 5: EAP-TLS server rejection of ClientHello 393 In the case where server authentication is unsuccessful, the 394 conversation will appear as shown in Figure 6. 396 EAP Peer EAP Server 398 EAP-Request/ 399 <-------- Identity 400 EAP-Response/ 401 Identity (Privacy-Friendly) --------> 402 EAP-Request/ 403 EAP-Type=EAP-TLS 404 <-------- (TLS Start) 405 EAP-Response/ 406 EAP-Type=EAP-TLS 407 (TLS ClientHello) --------> 408 EAP-Request/ 409 EAP-Type=EAP-TLS 410 (TLS ServerHello, 411 TLS EncryptedExtensions, 412 TLS CertificateRequest, 413 TLS Certificate, 414 TLS CertificateVerify, 415 TLS Finished, 416 <-------- TLS empty record) 417 EAP-Response/ 418 EAP-Type=EAP-TLS 419 (TLS Fatal Alert) 420 --------> 421 <-------- EAP-Failure 423 Figure 6: EAP-TLS unsuccessful server authentication 425 In the case where the server authenticates to the peer successfully, 426 but the peer fails to authenticate to the server, the conversation 427 will appear as shown in Figure 7. 429 EAP Peer EAP Server 431 EAP-Request/ 432 <-------- Identity 433 EAP-Response/ 434 Identity (Privacy-Friendly) --------> 436 EAP-Request/ 437 EAP-Type=EAP-TLS 438 <-------- (TLS Start) 439 EAP-Response/ 440 EAP-Type=EAP-TLS 441 (TLS ClientHello) --------> 442 EAP-Request/ 443 EAP-Type=EAP-TLS 444 (TLS ServerHello, 445 TLS EncryptedExtensions, 446 TLS CertificateRequest, 447 TLS Certificate, 448 TLS CertificateVerify, 449 TLS Finished, 450 <-------- TLS empty record) 451 EAP-Response/ 452 EAP-Type=EAP-TLS 453 (TLS Certificate, 454 TLS CertificateVerify, 455 TLS Finished) --------> 456 EAP-Request/ 457 EAP-Type=EAP-TLS 458 <-------- (TLS Fatal Alert) 459 EAP-Response/ 460 EAP-Type=EAP-TLS --------> 461 <-------- EAP-Failure 463 Figure 7: EAP-TLS unsuccessful client authentication 465 In the case where the client rejects a NewSessionTicket, the 466 conversation will appear as shown in Figure 8. 468 EAP Peer EAP Server 470 EAP-Request/ 471 <-------- Identity 472 EAP-Response/ 473 Identity (Privacy-Friendly) --------> 475 EAP-Request/ 476 EAP-Type=EAP-TLS 477 <-------- (TLS Start) 478 EAP-Response/ 479 EAP-Type=EAP-TLS 480 (TLS ClientHello) --------> 481 EAP-Request/ 482 EAP-Type=EAP-TLS 483 (TLS ServerHello, 484 TLS EncryptedExtensions, 485 TLS CertificateRequest, 486 TLS Certificate, 487 TLS CertificateVerify, 488 <-------- TLS Finished) 489 EAP-Response/ 490 EAP-Type=EAP-TLS 491 (TLS Certificate, 492 TLS CertificateVerify, 493 TLS Finished) --------> 494 EAP-Request/ 495 EAP-Type=EAP-TLS 496 (TLS NewSessionTicket, 497 <-------- TLS empty record) 498 EAP-Response/ 499 EAP-Type=EAP-TLS 500 (TLS Fatal Alert) 501 --------> 502 <-------- EAP-Failure 504 Figure 8: EAP-TLS client rejection of NewSessionTicket 506 2.1.4. Privacy 508 TLS 1.3 significantly improves privacy when compared to earlier 509 versions of TLS by forbidding cipher suites without confidentiality 510 and encrypting large parts of the TLS handshake including the 511 certificate messages. 513 EAP-TLS peer and server implementations supporting TLS 1.3 or higher 514 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 515 in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its 516 username in cleartext in the Identity Response. It is RECOMMENDED to 517 use anonymous NAIs, but other privacy-friendly identities (e.g. 518 encrypted usernames) MAY be used. 520 As the certificate messages in TLS 1.3 are encrypted, there is no 521 need to send an empty certificate_list or perform a second handshake 522 (as needed by EAP-TLS with earlier versions of TLS). When EAP-TLS is 523 used with TLS version 1.3 or higher the EAP-TLS peer and EAP-TLS 524 server SHALL follow the processing specified by the used version of 525 TLS. For TLS 1.3 this means that the EAP-TLS peer only sends an 526 empty certificate_list if it does not have an appropriate certificate 527 to send, and the EAP-TLS server MAY treat an empty certificate_list 528 as a terminal condition. 530 EAP-TLS with TLS 1.3 is always used with privacy. This does not add 531 any extra round-trips and the message flow with privacy is just the 532 normal message flow as shown in Figure 1. 534 2.1.5. Fragmentation 536 Including ContentType and ProtocolVersion a single TLS record may be 537 up to 16387 octets in length. EAP-TLS fragmentation support is 538 provided through addition of a flags octet within the EAP-Response 539 and EAP-Request packets, as well as a TLS Message Length field of 540 four octets. Unfragmented messages MAY have the L bit set and 541 include the length of the message (though this information is 542 redundant). 544 Some EAP implementations and access networks may limit the number of 545 EAP packet exchanges that can be handled. To avoid fragmentation, it 546 is RECOMMENDED to keep the sizes of client, server, and trust anchor 547 certificates small and the length of the certificate chains short. 548 In addition, it is RECOMMENDED to use mechanisms that reduce the 549 sizes of Certificate messages. 551 While Elliptic Curve Cryptography (ECC) was optional for earlier 552 version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of 553 [RFC8446]). To avoid fragmentation, the use of ECC in certificates, 554 signature algorithms, and groups are RECOMMENDED when using EAP-TLS 555 with TLS 1.3 or higher. At a 128-bit security level, this reduces 556 public key sizes from 384 bytes (RSA and DHE) to 32-64 bytes (ECDHE) 557 and signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA). 558 An EAP-TLS deployment MAY further reduce the certificate sizes by 559 limiting the number of Subject Alternative Names. 561 Endpoints SHOULD reduce the sizes of Certificate messages by omitting 562 certificates that the other endpoint is known to possess. When using 563 TLS 1.3, all certificates that specifies a trust anchor may be 564 omitted (see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or 565 earlier, only the self-signed certificate that specifies the root 566 certificate authority may be omitted (see Section 7.4.2 of 567 [RFC5246]). EAP-TLS peers and servers SHOULD support and use the 568 Cached Information Extension as specified in [RFC7924]. EAP-TLS 569 peers and servers MAY use other extensions for reducing the sizes of 570 Certificate messages, e.g. certificate compression 571 [I-D.ietf-tls-certificate-compression]. 573 2.2. Identity Verification 575 The identity provided in the EAP-Response/Identity is not 576 authenticated by EAP-TLS. Unauthenticated information SHALL NOT be 577 used for accounting purposes or to give authorization. The 578 authenticator and the EAP server MAY examine the identity presented 579 in EAP-Response/Identity for purposes such as routing and EAP method 580 selection. They MAY reject conversations if the identity does not 581 match their policy. Note that this also applies to resumption, see 582 Sections 2.1.2, 5.6, and 5.7. 584 2.3. Key Hierarchy 586 TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier 587 versions of TLS with HKDF and completely changes the Key Schedule. 588 The key hierarchies shown in Section 2.3 of [RFC5216] are therefore 589 not correct when EAP-TLS is used with TLS version 1.3 or higher. For 590 TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446]. 592 When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, 593 IV, and Method-Id SHALL be derived from the exporter_master_secret 594 using the TLS exporter interface [RFC5705] (for TLS 1.3 this is 595 defined in Section 7.5 of [RFC8446]). 597 Type-Code = 0x0D 598 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 599 Type-Code, 128) 600 IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", 601 Type-Code, 64) 602 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 603 Type-Code, 64) 604 Session-Id = Type-Code || Method-Id 606 All other parameters such as MSK and EMSK are derived in the same 607 manner as with EAP-TLS [RFC5216], Section 2.3. The definitions are 608 repeated below for simplicity: 610 MSK = Key_Material(0, 63) 611 EMSK = Key_Material(64, 127) 612 Enc-RECV-Key = MSK(0, 31) 613 Enc-SEND-Key = MSK(32, 63) 614 RECV-IV = IV(0, 31) 615 SEND-IV = IV(32, 63) 617 The use of these keys is specific to the lower layer, as described 618 [RFC5247]. 620 Note that the key derivation MUST use the length values given above. 621 Where in TLS 1.2 and earlier it was possible to truncate the output 622 by requesting less data from the TLS-Exporter function, this practice 623 is not possible with TLS 1.3. If an implementation intends to use 624 only part of the output of the TLS-Exporter function, then it MUST 625 ask for the full output, and then only use part of that output. 626 Failure to do so will result in incorrect values being calculated for 627 the above keying material. 629 By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation 630 without having to extract the Master Secret, ClientHello.random, and 631 ServerHello.random in a non-standard way. 633 Other TLS-based EAP methods can perform similar key derivations by 634 replacing the Type-Code with the value of their EAP type. The Type- 635 Code is defined to be 1 octet for values smaller than 256, otherwise 636 it is a 32-bit number (four octets), in network byte order. 637 Additional discussion of other EAP methods is outside of the scope of 638 this document. 640 2.4. Parameter Negotiation and Compliance Requirements 642 TLS 1.3 cipher suites are defined differently than in earlier 643 versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites 644 discussed in Section 2.4 of [RFC5216] can therefore not be used when 645 EAP-TLS is used with TLS version 1.3 or higher. The requirements on 646 protocol version and compression given in Section 2.4 of [RFC5216] 647 still apply. 649 When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS 650 peers and servers MUST comply with the compliance requirements 651 (mandatory-to-implement cipher suites, signature algorithms, key 652 exchange algorithms, extensions, etc.) for the TLS version used. For 653 TLS 1.3 the compliance requirements are defined in Section 9 of 654 [RFC8446]. 656 While EAP-TLS does not protect any application data, the negotiated 657 cipher suites and algorithms MAY be used to secure data as done in 658 other TLS-based EAP methods. 660 2.5. EAP State Machines 662 TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- 663 Handshake messages use the handshake content type and can be sent 664 after the main handshake. One such Post-Handshake message is 665 NewSessionTicket. The NewSessionTicket can be used for resumption. 666 After sending TLS Finished, the EAP server may send any number of 667 Post-Handshake messages in separate EAP-Requests. To decrease the 668 uncertainty for the EAP peer, the following procedure MUST be 669 followed: 671 When an EAP server has sent its last handshake message (Finished or a 672 Post-Handshake), it commits to not sending any more handshake 673 messages by appending an empty application data record (i.e. a TLS 674 record with TLSPlaintext.type = application_data and 675 TLSPlaintext.length = 0) to the last handshake record. After sending 676 an empty application data record, the EAP server may only send an 677 EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert 678 Message. 680 3. Detailed Description of the EAP-TLS Protocol 682 No updates to [RFC5216]. 684 4. IANA considerations 686 This section provides guidance to the Internet Assigned Numbers 687 Authority (IANA) regarding registration of values related to the EAP- 688 TLS 1.3 protocol in accordance with [RFC8126]. 690 This memo requires IANA to add the following labels to the TLS 691 Exporter Label Registry defined by [RFC5705]. These labels are used 692 in derivation of Key_Material, IV and Method-Id as defined in 693 Section 2.3: 695 o "EXPORTER_EAP_TLS_Key_Material" 697 o "EXPORTER_EAP_TLS_IV" 699 o "EXPORTER_EAP_TLS_Method-Id" 701 5. Security Considerations 703 5.1. Security Claims 705 Using EAP-TLS with TLS 1.3 does not change the security claims for 706 EAP-TLS as given in Section 4.1 of [RFC5216]. However, it 707 strengthens several of the claims as described in the following 708 updates to the notes given in Section 4.1 of [RFC5216]. 710 [1] Mutual authentication: By mandating revocation checking of 711 certificates, the authentication in EAP-TLS with TLS 1.3 is stronger 712 as authentication with revoked certificates will always fail. 714 [2] Confidentiality: The TLS 1.3 handshake offers much better 715 confidentiality than earlier versions of TLS by mandating cipher 716 suites with confidentiality and encrypting certificates and some of 717 the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the 718 use of privacy is mandatory and does not cause any additional round- 719 trips. 721 [3] Key strength: TLS 1.3 forbids all algorithms with known 722 weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 723 only supports cryptographic algorithms offering at least 112-bit 724 security, see [RFC8446]. 726 [4] Cryptographic Negotiation: TLS 1.3 increases the number of 727 cryptographic parameters that are negotiated in the handshake. When 728 EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic 729 negotiation of AEAD algorithm, HKDF hash algorithm, key exchange 730 groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. 732 5.2. Peer and Server Identities 734 No updates to [RFC5216]. 736 5.3. Certificate Validation 738 No updates to [RFC5216]. 740 5.4. Certificate Revocation 742 While certificates often have a long validity period spanning several 743 years, there are a number of reasons (e.g. key compromise, CA 744 compromise, privilege withdrawn, etc.) why client, server, or sub-CA 745 certificates have to be revoked before their expiry date. Revocation 746 of the EAP server's certificate is complicated by the fact that the 747 EAP peer may not have Internet connectivity until authentication 748 completes. 750 EAP-TLS peers and servers supporting TLS 1.3 MUST support Certificate 751 Status Requests (OCSP stapling) as specified in [RFC6066] and 752 Section 4.4.2.1 of [RFC8446]. When EAP-TLS is used with TLS 1.3, the 753 peer and server MUST use Certificate Status Requests [RFC6066] for 754 the server's certificate chain and the EAP peer MUST treat a 755 CertificateEntry (except the trust anchor) without a valid 756 CertificateStatus extension as invalid and abort the handshake with 757 an appropriate alert. When EAP-TLS is used with TLS 1.3, the server 758 MUST check the revocation status of the certificates in the 759 certificates in the client's certificate chain. 761 The OCSP status handling in TLS 1.3 is different from earlier 762 versions of TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the 763 OCSP information is carried in the CertificateEntry containing the 764 associated certificate instead of a separate CertificateStatus 765 message as in [RFC4366]. This enables sending OCSP information for 766 all certificates in the certificate chain. 768 5.5. Packet Modification Attacks 770 No updates to [RFC5216]. 772 5.6. Authorization 774 EAP-TLS may be encapsulated in other protocols, such as PPP 775 [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. 776 Systems implementing those protocols interact with EAP-TLS and can 777 make policy decisions and enforce authorization based on information 778 from the EAP-TLS exchange. The encapsulating protocols can also 779 provide additional, non-EAP information to the EAP server. This 780 information can include, but is not limited to, information about the 781 authenticator, information about the EAP peer, or information about 782 the protocol layers below EAP (MAC addresses, IP addresses, port 783 numbers, WiFi SSID, etc.). 785 As noted in Section 2.2, the identity presented in EAP-Response/ 786 Identity is not authenticated by EAP-TLS and is therefore trivial for 787 an attacker to forge, modify, or replay. Authorization and 788 accounting MUST be based on authenticated information such as 789 information in the certificate or the PSK identity and cached data 790 provisioned for resumption as described in Section 5.7. Note that 791 the requirements for Network Access Identifiers (NAIs) specified in 792 Section 4 of [RFC7542] still apply and MUST be followed. 794 Policy decisions are often based on a mixture of information from 795 TLS, EAP, and encapsulating protocols. EAP servers MAY reject 796 conversations based on examining unauthenticated information such as 797 an unknown MAC address or an identity provided in in EAP-Response/ 798 Identity that do not match a certain policy. 800 5.7. Resumption 802 There are a number of security issues related to resumption that are 803 not described in [RFC5216]. The problems, guidelines, and 804 requirements in this section therefore applies to all version of TLS. 806 When resumption occurs, it is based on cached information at the TLS 807 layer. As described in Section 2.2, the identity provided in the 808 EAP-Response/Identity is not authenticated by EAP-TLS. 810 To perform resumption in a secure way, the EAP peer and EAP server 811 need to be able to securely retrieve information such as certificate 812 chains, revocation status, and other authorization information from 813 the initial full handshake. We use the term "cached data" to 814 describe such information. Authorization during resumption MUST be 815 based on such cached data. The resumption MAY be rejected based on 816 examining unauthenticated information. 818 There are two ways to retrieve the needed information. The first 819 method is that the TLS server and client caches the information 820 locally, identified by an identifier and secured by the other party 821 showing proof-of-position of a key obtained from the initial full 822 handshake. For TLS versions before 1.3, the identifier can be the 823 session ID, for TLS 1.3, the identifier is the PSK identity. The 824 second method is via [RFC5077], where the TLS server encapsulates the 825 information into a ticket and forwards it to the client. The client 826 can subsequently do resumption using the obtained ticket. Note that 827 the client still needs to cache the information locally. The 828 following requirements apply to both methods. 830 If the EAP server or EAP client do not apply any authorization 831 policies, they MAY allow resumption where no cached data is 832 available. In all other cases, they MUST cache data during the 833 initial full authentication to enable resumption. The cached data 834 MUST be sufficient to make authorization decisions during resumption. 835 If cached data cannot be retrieved in a secure way, resumption MUST 836 NOT be done. 838 The above requirements also apply if the EAP server expects some 839 system to perform accounting for the session. Since accounting must 840 be tied to an authenticated identity, and resumption does not supply 841 such an identity, accounting is impossible without access to cached 842 data. 844 Some information such as IP addresses and the identity provided in 845 EAP-Response/Identity may change between the initial full handshake 846 and resumption. This change creates a "Time of check, time of use" 847 (TOCTOU) security vulnerability. A malicious or compromised user 848 could supply one set of data during the initial authentication, and a 849 different set of data during resumption, potentially leading to them 850 obtaining access that they should not have. 852 If any authorization, accounting, or policy decisions were made with 853 information that have changed since the initial full handshake and 854 resumption, and if change may lead to a different decision, such 855 decisions MUST be reevaluated. It is RECOMMENDED that authorization, 856 accounting, and policy decisions are reevaluated based on the 857 information given in the resumption. EAP servers MAY reject 858 resumption where the information supplied during resumption does not 859 match the information supplied during the original authentication. 860 Where a good decision is unclear, EAP servers SHOULD err on the side 861 of caution, and therefore reject the resumption. 863 Any security policies for authorization and revocation MUST be 864 followed also for resumption. The EAP client and server MAY need to 865 recheck the authorization and revocation status of the other party. 866 The certificates may have been revoked since the initial full 867 handshake and the authorizations of the other party may have been 868 reduced. 870 It is difficult to state the above requirements more precisely. If 871 the EAP server determine that the user is acting maliciously, they 872 MUST reject the resumption. It's up to each implementation and / or 873 deploymentment of EAP-TLS to determine which information to examine, 874 and which policies to apply. 876 5.8. Privacy Considerations 878 [RFC6973] suggests that the privacy considerations of IETF protocols 879 be documented. 881 TLS 1.3 offers much better privacy than earlier versions of TLS as 882 discussed in Section 2.1.4. In this section, we only discuss the 883 privacy properties of EAP-TLS with TLS 1.3. For privacy properties 884 of TLS 1.3 itself, see [RFC8446]. 886 EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in 887 EAP packets. Additionally, the EAP peer sends an identity in the 888 first EAP-Response. The other fields in the EAP-TLS Request and the 889 EAP-TLS Response packets do not contain any cleartext privacy 890 sensitive information. 892 Tracking of users by eavesdropping on identity responses or 893 certificates is a well-known problem in many EAP methods. When EAP- 894 TLS is used with TLS 1.3, all certificates are encrypted, and the 895 username part of the identity response is always confidentiality 896 protected (e.g. using Anonymous NAIs). However, as with other EAP 897 methods, even when privacy-friendly identifiers or EAP tunneling is 898 used, the domain name (i.e. the realm) in the NAI is still typically 899 visible. How much privacy sensitive information the domain name 900 leaks is highly dependent on how many other users are using the same 901 domain name in the particular access network. If all EAP peers have 902 the same domain, no additional information is leaked. If a domain 903 name is used by a small subset of the EAP peers, it may aid an 904 attacker in tracking or identifying the user. 906 If Anonymous NAIs are not used, the privacy-friendly identifiers need 907 to be generated with care. The identities MUST be generated in a 908 cryptographically secure way so that that it is computationally 909 infeasible for an attacker to differentiate two identities belonging 910 to the same user from two identities belonging to different users in 911 the same realm. This can be achieved, for instance, by using random 912 or pseudo-random usernames such as random byte strings or 913 ciphertexts. Note that the privacy-friendly usernames also MUST NOT 914 include substrings that can be used to relate the identity to a 915 specific user. Similarly, privacy-friendly username SHOULD NOT be 916 formed by a fixed mapping that stays the same across multiple 917 different authentications. 919 An EAP peer with a policy allowing communication with EAP servers 920 supporting only TLS 1.2 (or lower) without privacy and with a static 921 RSA key exchange is vulnerable to disclosure of the peer username. 922 An active attacker can in this case make the EAP peer believe that an 923 EAP server supporting TLS 1.3 only supports TLS 1.2 (or lower) 924 without privacy. The attacker can simply impersonate the EAP server 925 and negotiate TLS 1.2 (or lower) with static RSA key exchange and 926 send an TLS alert message when the EAP peer tries to use privacy by 927 sending an empty certificate message. Since the attacker 928 (impersonating the EAP server) does not provide a proof-of-possession 929 of the private key until the Finished message when a static RSA key 930 exchange is used, an EAP peer may inadvertently disclose its identity 931 (username) to an attacker. Therefore, it is RECOMMENDED for EAP 932 peers to not use EAP-TLS with TLS 1.2 (or lower) and RSA based cipher 933 suites without privacy. 935 5.9. Pervasive Monitoring 937 As required by [RFC7258], work on IETF protocols needs to consider 938 the effects of pervasive monitoring and mitigate them when possible. 940 Pervasive Monitoring is widespread surveillance of users. By 941 encrypting more information and by mandating the use of privacy, TLS 942 1.3 offers much better protection against pervasive monitoring. In 943 addition to the privacy attacks discussed above, surveillance on a 944 large scale may enable tracking of a user over a wider geographical 945 area and across different access networks. Using information from 946 EAP-TLS together with information gathered from other protocols 947 increases the risk of identifying individual users. 949 5.10. Discovered Vulnerabilities 951 Over the years, there have been several serious attacks on earlier 952 versions of Transport Layer Security (TLS), including attacks on its 953 most commonly used ciphers and modes of operation. [RFC7457] 954 summarizes the attacks that were known at the time of publishing and 955 [RFC7525] provides recommendations for improving the security of 956 deployed services that use TLS. However, many of the attacks are 957 less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and 958 does not protect any application data. EAP-TLS implementations 959 SHOULD mitigate known attacks and follow the recommendations in 960 [RFC7525]. The use of TLS 1.3 mitigates most of the known attacks. 962 6. References 964 6.1. Normative References 966 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 967 Requirement Levels", BCP 14, RFC 2119, 968 DOI 10.17487/RFC2119, March 1997, 969 . 971 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 972 Levkowetz, Ed., "Extensible Authentication Protocol 973 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 974 . 976 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 977 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 978 March 2008, . 980 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 981 Housley, R., and W. Polk, "Internet X.509 Public Key 982 Infrastructure Certificate and Certificate Revocation List 983 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 984 . 986 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 987 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 988 March 2010, . 990 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 991 Extensions: Extension Definitions", RFC 6066, 992 DOI 10.17487/RFC6066, January 2011, 993 . 995 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 996 Galperin, S., and C. Adams, "X.509 Internet Public Key 997 Infrastructure Online Certificate Status Protocol - OCSP", 998 RFC 6960, DOI 10.17487/RFC6960, June 2013, 999 . 1001 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1002 DOI 10.17487/RFC7542, May 2015, 1003 . 1005 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1006 (TLS) Cached Information Extension", RFC 7924, 1007 DOI 10.17487/RFC7924, July 2016, 1008 . 1010 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1011 Writing an IANA Considerations Section in RFCs", BCP 26, 1012 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1013 . 1015 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1016 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1017 May 2017, . 1019 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1020 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1021 . 1023 6.2. Informative references 1025 [I-D.ietf-tls-certificate-compression] 1026 Ghedini, A. and V. Vasiliev, "TLS Certificate 1027 Compression", draft-ietf-tls-certificate-compression-04 1028 (work in progress), October 2018. 1030 [IEEE-802.11] 1031 Institute of Electrical and Electronics Engineers, "IEEE 1032 Standard for Information technology--Telecommunications 1033 and information exchange between systems Local and 1034 metropolitan area networks--Specific requirements - Part 1035 11: Wireless LAN Medium Access Control (MAC) and Physical 1036 Layer (PHY) Specifications", IEEE Std 802.11-2016 1037 (Revision of IEEE Std 802.11-2012) , December 2016. 1039 [IEEE-802.1X] 1040 Institute of Electrical and Electronics Engineers, "IEEE 1041 Standard for Local and metropolitan area networks -- Port- 1042 Based Network Access Control", IEEE Standard 802.1X-2010 , 1043 February 2010. 1045 [MulteFire] 1046 MulteFire, "MulteFire Release 1.0.1 specification", 2017. 1048 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 1049 STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 1050 . 1052 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1053 RFC 2246, DOI 10.17487/RFC2246, January 1999, 1054 . 1056 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1057 Adams, "X.509 Internet Public Key Infrastructure Online 1058 Certificate Status Protocol - OCSP", RFC 2560, 1059 DOI 10.17487/RFC2560, June 1999, 1060 . 1062 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1063 "Remote Authentication Dial In User Service (RADIUS)", 1064 RFC 2865, DOI 10.17487/RFC2865, June 2000, 1065 . 1067 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1068 X.509 Public Key Infrastructure Certificate and 1069 Certificate Revocation List (CRL) Profile", RFC 3280, 1070 DOI 10.17487/RFC3280, April 2002, 1071 . 1073 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1074 Network Access Identifier", RFC 4282, 1075 DOI 10.17487/RFC4282, December 2005, 1076 . 1078 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1079 (TLS) Protocol Version 1.1", RFC 4346, 1080 DOI 10.17487/RFC4346, April 2006, 1081 . 1083 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1084 and T. Wright, "Transport Layer Security (TLS) 1085 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 1086 . 1088 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1089 "Transport Layer Security (TLS) Session Resumption without 1090 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1091 January 2008, . 1093 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1094 and A. Yegin, "Protocol for Carrying Authentication for 1095 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1096 May 2008, . 1098 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1099 (TLS) Protocol Version 1.2", RFC 5246, 1100 DOI 10.17487/RFC5246, August 2008, 1101 . 1103 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1104 Authentication Protocol (EAP) Key Management Framework", 1105 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1106 . 1108 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1109 Ed., "Diameter Base Protocol", RFC 6733, 1110 DOI 10.17487/RFC6733, October 2012, 1111 . 1113 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1114 Morris, J., Hansen, M., and R. Smith, "Privacy 1115 Considerations for Internet Protocols", RFC 6973, 1116 DOI 10.17487/RFC6973, July 2013, 1117 . 1119 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1120 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1121 2014, . 1123 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1124 "Transport Layer Security (TLS) Application-Layer Protocol 1125 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1126 July 2014, . 1128 [RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., 1129 and D. Kroeselberg, "Extensions to the Emergency Services 1130 Architecture for Dealing With Unauthenticated and 1131 Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, 1132 December 2014, . 1134 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1135 Known Attacks on Transport Layer Security (TLS) and 1136 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1137 February 2015, . 1139 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1140 "Recommendations for Secure Use of Transport Layer 1141 Security (TLS) and Datagram Transport Layer Security 1142 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1143 2015, . 1145 [TS.33.501] 1146 3GPP, "Security architecture and procedures for 5G 1147 System", 3GPP TS 33.501 15.3.1, December 2018. 1149 Appendix A. Updated references 1151 All the following references in [RFC5216] are updated as specified 1152 below when EAP-TLS is used with TLS 1.3 or higher. 1154 All references to [RFC2560] are updated with [RFC6960]. 1156 All references to [RFC3280] are updated with [RFC5280]. 1158 All references to [RFC4282] are updated with [RFC7542]. 1160 Acknowledgments 1162 The authors want to thank Alan DeKok, Ari Keraenen, Bernard Aboba, 1163 Eric Rescorla, Jari Arkko, Jim Schaad, Jouni Malinen, and Vesa 1164 Torvinen for comments and suggestions on the draft. 1166 Contributors 1168 Alan DeKok, FreeRADIUS 1170 Authors' Addresses 1172 John Mattsson 1173 Ericsson 1174 Stockholm 164 40 1175 Sweden 1177 Email: john.mattsson@ericsson.com 1179 Mohit Sethi 1180 Ericsson 1181 Jorvas 02420 1182 Finland 1184 Email: mohit@piuha.net