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