idnits 2.17.1 draft-ietf-emu-eap-tls13-01.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 (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 18, 2018) is 2044 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: '2' on line 611 -- Looks like a reference, but probably isn't: '3' on line 617 -- Looks like a reference, but probably isn't: '4' on line 622 == Outdated reference: A later version (-10) exists of draft-ietf-tls-certificate-compression-03 -- 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 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 12 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 18, 2018 6 Expires: March 22, 2019 8 Using EAP-TLS with TLS 1.3 9 draft-ietf-emu-eap-tls13-01 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. This 17 document updates RFC 5216. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 22, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements and Terminology . . . . . . . . . . . . . . 3 55 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 3 57 2.1.1. Base Case . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1.2. Resumption . . . . . . . . . . . . . . . . . . . . . 6 59 2.1.3. Termination . . . . . . . . . . . . . . . . . . . . . 8 60 2.1.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . 10 61 2.1.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 62 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 12 63 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 12 64 2.4. Parameter Negotiation and Compliance Requirements . . . . 13 65 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 13 66 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 14 67 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 14 70 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 15 71 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 15 72 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 15 73 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 15 74 5.6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 5.7. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 15 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 6.1. Normative References . . . . . . . . . . . . . . . . . . 16 78 6.2. Informative references . . . . . . . . . . . . . . . . . 17 79 Appendix A. Updated references . . . . . . . . . . . . . . . . . 19 80 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 86 provides a standard mechanism for support of multiple authentication 87 methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies 88 an EAP authentication method with certificate-based mutual 89 authentication and key derivation utilizing the TLS handshake 90 protocol for cryptographic algorithms and protocol version 91 negotiation, mutual authentication, and establishment of shared 92 secret keying material. EAP-TLS is widely supported for 93 authentication in IEEE 802.11 [IEEE-802.11] networks (Wi-Fi) using 94 IEEE 802.1X [IEEE-802.1X] and it's the default mechanism for 95 certificate based authentication in MulteFire [MulteFire] and 3GPP 5G 97 [TS.33.501] networks. EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] 98 and TLS 1.1 [RFC4346], but works perfectly also with TLS 1.2 99 [RFC5246]. 101 Weaknesses found in previous versions of TLS, as well as new 102 requirements for security, privacy, and reduced latency has led to 103 the development of TLS 1.3 [RFC8446], which in large parts is a 104 complete remodeling of the TLS handshake protocol including a 105 different message flow, different handshake messages, different key 106 schedule, different cipher suites, different resumption, and 107 different privacy protection. This means that significant parts of 108 the normative text in the previous EAP-TLS specification [RFC5216] 109 are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore, 110 aspects such as resumption, privacy handling, and key derivation need 111 to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). 113 This document defines how to use EAP-TLS with TLS 1.3 (or higher) and 114 does not change how EAP-TLS is used with older versions of TLS. 115 While this document updates EAP-TLS [RFC5216], it remains backwards 116 compatible with it and existing implementations of EAP-TLS. This 117 document only describes differences compared to [RFC5216]. 119 In addition to the improved security and privacy offered by TLS 1.3, 120 there are other significant benefits of using EAP-TLS with TLS 1.3. 121 When EAP-TLS is used with support for privacy, TLS 1.3 requires two 122 fewer round-trips. TLS 1.3 also introduces more possibilities to 123 reduce fragmentation when compared to earlier versions of TLS. 125 1.1. Requirements and Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. Readers 130 are expected to be familiar with the terms and concepts used in EAP- 131 TLS [RFC5216] and TLS 1.3 [RFC8446]. 133 2. Protocol Overview 135 2.1. Overview of the EAP-TLS Conversation 137 2.1.1. Base Case 139 TLS 1.3 changes both the message flow and the handshake messages 140 compared to earlier versions of TLS. Therefore, much of Section 2.1 141 of RFC5216 [RFC5216] does not apply for TLS 1.3 (or higher). 143 After receiving an EAP-Request packet with EAP-Type=EAP-TLS as 144 described in [RFC5216] the conversation will continue with the TLS 145 handshake protocol encapsulated in the data fields of EAP-Response 146 and EAP-Request packets. When EAP-TLS is used with TLS version 1.3 147 or higher, the formatting and processing of the TLS handshake SHALL 148 be done as specified in that version of TLS. This document only 149 lists additional and different requirements, restrictions, and 150 processing compared to [RFC8446] and [RFC5216]. 152 The EAP server MUST authenticate with a certificate and SHOULD 153 require the EAP peer to authenticate with a certificate. 154 Certificates can be of any type supported by TLS including raw public 155 keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except 156 for resumption. SessionID is deprecated in TLS 1.3 and the EAP 157 server SHALL ignore the legacy_session_id field if TLS 1.3 is 158 negotiated. Resumption is handled as described in Section 2.1.2. 159 After the TLS handshake has completed, the EAP server sends EAP- 160 Success. 162 As stated in [RFC5216], the TLS cipher suite shall not be used to 163 protect application data. This applies also for early application 164 data. When EAP-TLS is used with TLS 1.3, early application data 165 SHALL NOT be used. 167 In the case where EAP-TLS with mutual authentication is successful, 168 the conversation will appear as shown in Figure 1. The EAP server 169 commits to not send any more handshake messages by sending an empty 170 TLS record, see Section 2.5. 172 EAP Peer EAP Server 174 EAP-Request/ 175 <-------- Identity 176 EAP-Response/ 177 Identity (MyID) --------> 178 EAP-Request/ 179 EAP-Type=EAP-TLS 180 <-------- (TLS Start) 181 EAP-Response/ 182 EAP-Type=EAP-TLS 183 (TLS ClientHello) --------> 184 EAP-Request/ 185 EAP-Type=EAP-TLS 186 (TLS ServerHello, 187 TLS EncryptedExtensions, 188 TLS CertificateRequest, 189 TLS Certificate, 190 TLS CertificateVerify, 191 TLS Finished, 192 <-------- TLS empty record) 193 EAP-Response/ 194 EAP-Type=EAP-TLS 195 (TLS Certificate, 196 TLS CertificateVerify, 197 TLS Finished) --------> 198 <-------- EAP-Success 200 Figure 1: EAP-TLS mutual authentication 202 When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support 203 of resumption in the initial authentication. To indicate support of 204 resumption, the EAP server sends a NewSessionTicket message 205 (containing a PSK and other parameters) after it has received the 206 Finished message. 208 In the case where EAP-TLS with mutual authentication and ticket 209 establishment is successful, the conversation will appear as shown in 210 Figure 2. 212 EAP Peer EAP Server 214 EAP-Request/ 215 <-------- Identity 216 EAP-Response/ 217 Identity (MyID) --------> 218 EAP-Request/ 219 EAP-Type=EAP-TLS 220 <-------- (TLS Start) 221 EAP-Response/ 222 EAP-Type=EAP-TLS 223 (TLS ClientHello) --------> 224 EAP-Request/ 225 EAP-Type=EAP-TLS 226 (TLS ServerHello, 227 TLS EncryptedExtensions, 228 TLS CertificateRequest, 229 TLS Certificate, 230 TLS CertificateVerify, 231 <-------- TLS Finished) 232 EAP-Response/ 233 EAP-Type=EAP-TLS 234 (TLS Certificate, 235 TLS CertificateVerify, 236 TLS Finished) --------> 237 EAP-Request/ 238 EAP-Type=EAP-TLS 239 (TLS NewSessionTicket, 240 <-------- TLS empty record) 241 EAP-Response/ 242 EAP-Type=EAP-TLS --------> 243 <-------- EAP-Success 245 Figure 2: EAP-TLS ticket establishment 247 2.1.2. Resumption 249 TLS 1.3 replaces the session resumption mechanisms in earlier 250 versions of TLS with a new PSK exchange. When EAP-TLS is used with 251 TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism 252 compatible with that version of TLS. 254 For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If 255 the client has received a NewSessionTicket message from the server, 256 the client can use the PSK identity received in the ticket to 257 negotiate the use of the associated PSK. If the server accepts it, 258 then the security context of the new connection is tied to the 259 original connection and the key derived from the initial handshake is 260 used to bootstrap the cryptographic state instead of a full 261 handshake. It is left up to the EAP peer whether to use resumption, 262 but a EAP peer SHOULD use resumption as long as it has a valid ticket 263 cached. It is RECOMMENDED that the EAP server accept resumption as 264 long as the ticket is valid. However, the server MAY choose to 265 require a full authentication. 267 A subsequent authentication using resumption, where both sides 268 authenticate successfully is shown in Figure 3. 270 EAP Peer EAP Server 272 EAP-Request/ 273 <-------- Identity 274 EAP-Response/ 275 Identity (MyID) --------> 276 EAP-Request/ 277 EAP-Type=EAP-TLS 278 <-------- (TLS Start) 279 EAP-Response/ 280 EAP-Type=EAP-TLS 281 (TLS ClientHello) --------> 282 EAP-Request/ 283 EAP-Type=EAP-TLS 284 (TLS ServerHello, 285 TLS EncryptedExtensions, 286 TLS Finished, 287 <-------- TLS empty record) 288 EAP-Response/ 289 EAP-Type=EAP-TLS 290 (TLS Finished) --------> 291 <-------- EAP-Success 293 Figure 3: EAP-TLS resumption 295 As specified in Section 2.2 of [RFC8446], the EAP peer SHOULD supply 296 a "key_share" extension when offering resumption, which allows the 297 EAP server to decline resumption and continue the handshake as a full 298 handshake. The message flow in this case is given by Figure 1 or 299 Figure 2. If the EAP peer did not supply a "key_share" extension 300 when offering resumption, the EAP server needs to reject the 301 ClientHello and the EAP peer needs to restart a full handshake. The 302 message flow in this case is given by Figure 4 followed by Figure 1 303 or Figure 2. 305 2.1.3. Termination 307 TLS 1.3 changes both the message flow and the handshake messages 308 compared to earlier versions of TLS. Therefore, some normative text 309 in Section 2.1.3 of RFC 5216 [RFC5216] does not apply for TLS 1.3 or 310 higher. The two paragraphs below replaces the corresponding 311 paragraphs in Section 2.1.3 of RFC 5216 [RFC5216] when EAP-TLS is 312 used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 313 of RFC 5216 [RFC5216] still apply with the exception that SessionID 314 is deprecated. 316 If the EAP Server authenticates successfully the EAP Peer MUST 317 send an EAP-Response message with EAP-Type=EAP-TLS containing TLS 318 records confirming the processing in the version of TLS used. 320 If the EAP Peer authenticates successfully the EAP Server MUST 321 send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS 322 records confirming to the processing in the version of TLS used. 323 The message flow ends with the EAP Server sending a EAP-Success 324 message. 326 In the case where the server rejects the ClientHello, the 327 conversation will appear as shown in Figure 4. 329 EAP Peer EAP Server 331 EAP-Request/ 332 <-------- Identity 333 EAP-Response/ 334 Identity (MyID) --------> 335 EAP-Request/ 336 EAP-Type=EAP-TLS 337 <-------- (TLS Start) 338 EAP-Response/ 339 EAP-Type=EAP-TLS 340 (TLS ClientHello) --------> 341 EAP-Request/ 342 EAP-Type=EAP-TLS 343 <-------- (TLS Alert Message) 344 EAP-Response/ 345 EAP-Type=EAP-TLS --------> 346 <-------- EAP-Failure 348 Figure 4: EAP-TLS server rejection of ClientHello 350 In the case where server authentication is unsuccessful, the 351 conversation will appear as shown in Figure 5. 353 EAP Peer EAP Server 355 EAP-Request/ 356 <-------- Identity 357 EAP-Response/ 358 Identity (MyID) --------> 359 EAP-Request/ 360 EAP-Type=EAP-TLS 361 <-------- (TLS Start) 362 EAP-Response/ 363 EAP-Type=EAP-TLS 364 (TLS ClientHello) --------> 365 EAP-Request/ 366 EAP-Type=EAP-TLS 367 (TLS ServerHello, 368 TLS EncryptedExtensions, 369 TLS CertificateRequest, 370 TLS Certificate, 371 TLS CertificateVerify, 372 TLS Finished, 373 <-------- TLS empty record) 374 EAP-Response/ 375 EAP-Type=EAP-TLS 376 (TLS Alert Message) 377 --------> 378 <-------- EAP-Failure 380 Figure 5: EAP-TLS unsuccessful server authentication 382 In the case where the server authenticates to the peer successfully, 383 but the peer fails to authenticate to the server, the conversation 384 will appear as shown in Figure 6. 386 EAP Peer EAP Server 388 EAP-Request/ 389 <-------- Identity 390 EAP-Response/ 391 Identity (MyID) --------> 392 EAP-Request/ 393 EAP-Type=EAP-TLS 394 <-------- (TLS Start) 395 EAP-Response/ 396 EAP-Type=EAP-TLS 397 (TLS ClientHello) --------> 398 EAP-Request/ 399 EAP-Type=EAP-TLS 400 (TLS ServerHello, 401 TLS EncryptedExtensions, 402 TLS CertificateRequest, 403 TLS Certificate, 404 TLS CertificateVerify, 405 TLS Finished, 406 <-------- TLS empty record) 407 EAP-Response/ 408 EAP-Type=EAP-TLS 409 (TLS Certificate, 410 TLS CertificateVerify, 411 TLS Finished) --------> 412 EAP-Request/ 413 EAP-Type=EAP-TLS 414 <-------- (TLS Alert Message) 415 EAP-Response/ 416 EAP-Type=EAP-TLS --------> 417 <-------- EAP-Failure 419 Figure 6: EAP-TLS unsuccessful client authentication 421 2.1.4. Privacy 423 TLS 1.3 significantly increases privacy when compared to earlier 424 version of TLS by forbidding cipher suites without confidentiality 425 and encrypting large parts of the TLS handshake including the 426 certificate messages. 428 EAP-TLS peer and server implementations supporting TLS 1.3 or higher 429 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 430 in [RFC7542]) and the client MUST confidentiality protect its 431 identity (e.g. using Anonymous NAIs) when the EAP-TLS server is known 432 to support TLS 1.3 or higher. 434 As the certificate messages in TLS 1.3 are encrypted, there is no 435 need to send an empty certificate_list or perform a second handshake 436 (as needed by EAP-TLS when with earlier versions of TLS). When EAP- 437 TLS is used with TLS version 1.3 or higher the EAP-TLS peer and EAP- 438 TLS server SHALL follow the processing specified by the used version 439 of TLS. For TLS 1.3 this means that the EAP-TLS peer only sends an 440 empty certificate_list if it does not have an appropriate certificate 441 to send and the EAP-TLS server MAY treat an empty certificate_list as 442 a terminal condition. 444 When EAP-TLS is used with TLS 1.3 and privacy, no extra round-trips 445 are added and the message flow looks just like a normal message flow 446 with the only difference that an anonymous NAI is used. In the case 447 where EAP-TLS with mutual authentication and privacy is successful, 448 the conversation will appear as shown in Figure 7. 450 EAP Peer EAP Server 452 EAP-Request/ 453 <-------- Identity 454 EAP-Response/ 455 Identity (Anonymous NAI) --------> 456 EAP-Request/ 457 EAP-Type=EAP-TLS 458 <-------- (TLS Start) 459 EAP-Response/ 460 EAP-Type=EAP-TLS 461 (TLS ClientHello) --------> 462 EAP-Request/ 463 EAP-Type=EAP-TLS 464 (TLS ServerHello, 465 TLS EncryptedExtensions, 466 TLS CertificateRequest, 467 TLS Certificate, 468 TLS CertificateVerify, 469 TLS Finished, 470 <-------- TLS empty record) 471 EAP-Response/ 472 EAP-Type=EAP-TLS 473 (TLS Certificate, 474 TLS CertificateVerify, 475 TLS Finished) --------> 476 <-------- EAP-Success 478 Figure 7: EAP-TLS privacy 480 2.1.5. Fragmentation 482 Including ContentType and ProtocolVersion a single TLS record may be 483 up to 16387 octets in length. Some EAP implementations and access 484 networks may limit the number of EAP packet exchanges that can be 485 handled. To avoid fragmentation, it is RECOMMENDED to keep the sizes 486 of client, server, and trust anchor certificates small and the length 487 of the certificate chains short. It addition, it is RECOMMENDED to 488 use mechanisms that reduce the sizes of Certificate messages. 490 While Elliptic Curve Cryptography (ECC) was optional for earlier 491 version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of 492 [RFC8446]). To avoid fragmentation, the use of ECC in certificates, 493 signature algorithms, and groups are RECOMMENDED when using EAP-TLS 494 with TLS 1.3 or higher. At a 128-bit security level, this reduces 495 public key sizes from 384 bytes (RSA and DHE) to 32 bytes (ECDHE) and 496 signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA). An 497 EAP-TLS deployment MAY further reduce the certificate sizes by 498 limiting the number of Subject Alternative Names. 500 Endpoints SHOULD reduce the sizes of Certificate messages by omitting 501 certificates that the other endpoint is known to possess. When using 502 TLS 1.3, all certificates that specifies a trust anchor may be 503 omitted (see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or 504 earlier, only the self-signed certificate that specifies the root 505 certificate authority may be omitted (see Section 7.4.2 of 506 [RFC5246]). EAP-TLS peers and servers SHOULD support and use the 507 Cached Information Extension as specified in [RFC7924]. EAP-TLS 508 peers and servers MAY use other extensions for reducing the sizes of 509 Certificate messages, e.g. certificate compression 510 [I-D.ietf-tls-certificate-compression]. 512 2.2. Identity Verification 514 No updates to [RFC5216]. 516 2.3. Key Hierarchy 518 TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier 519 versions of TLS with HKDF and completely changes the Key Schedule. 520 The key hierarchies shown in Section 2.3 of [RFC5216] are therefore 521 not correct when EAP-TLS is used with TLS version 1.3 or higher. For 522 TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446]. 524 When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, 525 IV, and Method-Id SHALL be derived from the exporter_master_secret 526 using the TLS exporter interface [RFC5705] (for TLS 1.3 this is 527 defined in Section 7.5 of [RFC8446]). 529 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128) 530 IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", "", 64) 531 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", "", 64) 532 Session-Id = 0x0D || Method-Id 534 By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation 535 without having to extract the Master Secret, ClientHello.random, and 536 ServerHello.random in a non-standard way. 538 All other parameters such as MSK and EMSK are derived as specified in 539 EAP-TLS [RFC5216], Section 2.3. The use of these keys is specific to 540 the lower layer, as described [RFC5247]. 542 2.4. Parameter Negotiation and Compliance Requirements 544 TLS 1.3 cipher suites are defined differently than in earlier 545 versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites 546 discussed in Section 2.4 of [RFC5216] can therefore not be used when 547 EAP-TLS is used with TLS version 1.3 or higher. The requirements on 548 protocol version and compression given in Section 2.4 of [RFC5216] 549 still apply. 551 When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS 552 peers and servers MUST comply with the requirements for the TLS 553 version used. For TLS 1.3 the compliance requirements are defined in 554 Section 9 of [RFC8446]. 556 2.5. EAP State Machines 558 TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- 559 Handshake messages use the handshake content type and can be sent 560 after the main handshake. One such Post-Handshake message is 561 NewSessionTicket. The NewSessopmTicket can be used for resumption. 562 After sending TLS Finished, the EAP server may send any number of 563 Post-Handshake messages in separate EAP-Requests. To decrease the 564 uncertainty for the EAP Peer, the following procedure MUST be 565 followed: 567 When an EAP Server has sent its last handshake message (Finished or a 568 Post-Handshake), it commits to not sending any more handshake 569 messages by appending an empty application data record (i.e. a TLS 570 record with TLSPlaintext.type = application_data and 571 TLSPlaintext.length = 0) to the last handshake record. After sending 572 an empty application data record, the EAP Server may only send an 573 EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert 574 Message. 576 Note that the use of an empty application data record does not 577 violate the requirement that the TLS cipher suite shall not be used 578 to protect application data, as the application data is the empty 579 string, no application data is protected. 581 3. Detailed Description of the EAP-TLS Protocol 583 No updates to [RFC5216]. 585 4. IANA considerations 587 This section provides guidance to the Internet Assigned Numbers 588 Authority (IANA) regarding registration of values related to the EAP- 589 TLS 1.3 protocol in accordance with [RFC8126]. 591 This memo requires IANA to add the following labels to the TLS 592 Exporter Label Registry defined by [RFC5705]. These labels are used 593 in derivation of Key_Material, IV and Method-Id as defined in 594 Section 2.3: 596 o "EXPORTER_EAP_TLS_Key_Material" 598 o "EXPORTER_EAP_TLS_IV" 600 o "EXPORTER_EAP_TLS_Method-Id" 602 5. Security Considerations 604 5.1. Security Claims 606 Using EAP-TLS with TLS 1.3 does not change the security claims for 607 EAP-TLS as given in Section 4.1 of [RFC5216]. However, it 608 strengthens several of the claims as described in the following 609 updates to the notes given in Section 4.1 of [RFC5216]. 611 [2] Confidentiality: The TLS 1.3 handshake offers much better 612 confidentiality than earlier versions of TLS by mandating cipher 613 suites with confidentiality and encrypting certificates and some of 614 the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the 615 use of privacy does not cause any additional round-trips. 617 [3] Key strength: TLS 1.3 forbids all algorithms with known 618 weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 619 only supports cryptographic algorithms offering at least 112-bit 620 security, see [RFC8446]. 622 [4] Cryptographic Negotiation: TLS 1.3 increases the number of 623 cryptographic parameters that are negotiated in the handshake. When 624 EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic 625 negotiation of AEAD algorithm, HKDF hash algorithm, key exchange 626 groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. 628 5.2. Peer and Server Identities 630 No updates to [RFC5216]. 632 5.3. Certificate Validation 634 No updates to [RFC5216]. 636 5.4. Certificate Revocation 638 The OCSP status handling in TLS 1.3 is different from earlier 639 versions of TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the 640 OCSP information is carried in the CertificateEntry containing the 641 associated certificate instead of a separate CertificateStatus 642 message as in [RFC4366]. This enables sending OCSP information for 643 all certificates in the certificate chain. 645 EAP-TLS peers and servers supporting TLS 1.3 SHOULD support 646 Certificate Status Requests (OCSP stapling) as specified in [RFC6066] 647 and Section 4.4.2.1 of [RFC8446]. The use of Certificate Status 648 Requests to determine the current status of the EAP server's 649 certificate is RECOMMENDED. 651 5.5. Packet Modification Attacks 653 No updates to [RFC5216]. 655 5.6. Privacy 657 [RFC6973] suggests that the privacy considerations of IETF protocols 658 be documented. 660 TODO 662 5.7. Pervasive Monitoring 664 As required by [RFC7258], work on IETF protocols needs to consider 665 the effects of pervasive monitoring and mitigate them when possible. 667 TODO 669 6. References 671 6.1. Normative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, 675 DOI 10.17487/RFC2119, March 1997, 676 . 678 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 679 Levkowetz, Ed., "Extensible Authentication Protocol 680 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 681 . 683 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 684 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 685 March 2008, . 687 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 688 Housley, R., and W. Polk, "Internet X.509 Public Key 689 Infrastructure Certificate and Certificate Revocation List 690 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 691 . 693 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 694 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 695 March 2010, . 697 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 698 Extensions: Extension Definitions", RFC 6066, 699 DOI 10.17487/RFC6066, January 2011, 700 . 702 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 703 Galperin, S., and C. Adams, "X.509 Internet Public Key 704 Infrastructure Online Certificate Status Protocol - OCSP", 705 RFC 6960, DOI 10.17487/RFC6960, June 2013, 706 . 708 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 709 DOI 10.17487/RFC7542, May 2015, 710 . 712 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 713 (TLS) Cached Information Extension", RFC 7924, 714 DOI 10.17487/RFC7924, July 2016, 715 . 717 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 718 Writing an IANA Considerations Section in RFCs", BCP 26, 719 RFC 8126, DOI 10.17487/RFC8126, June 2017, 720 . 722 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 723 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 724 . 726 6.2. Informative references 728 [I-D.ietf-tls-certificate-compression] 729 Ghedini, A. and V. Vasiliev, "Transport Layer Security 730 (TLS) Certificate Compression", draft-ietf-tls- 731 certificate-compression-03 (work in progress), April 2018. 733 [IEEE-802.11] 734 Institute of Electrical and Electronics Engineers, "IEEE 735 Standard for Information technology--Telecommunications 736 and information exchange between systems Local and 737 metropolitan area networks--Specific requirements - Part 738 11: Wireless LAN Medium Access Control (MAC) and Physical 739 Layer (PHY) Specifications", IEEE Std 802.11-2016 740 (Revision of IEEE Std 802.11-2012) , December 2016. 742 [IEEE-802.1X] 743 Institute of Electrical and Electronics Engineers, "IEEE 744 Standard for Local and metropolitan area networks -- Port- 745 Based Network Access Control", IEEE Standard 802.1X-2010 , 746 February 2010. 748 [MulteFire] 749 MulteFire, "MulteFire Release 1.0.1 specification", 2017. 751 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 752 RFC 2246, DOI 10.17487/RFC2246, January 1999, 753 . 755 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 756 Adams, "X.509 Internet Public Key Infrastructure Online 757 Certificate Status Protocol - OCSP", RFC 2560, 758 DOI 10.17487/RFC2560, June 1999, 759 . 761 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 762 X.509 Public Key Infrastructure Certificate and 763 Certificate Revocation List (CRL) Profile", RFC 3280, 764 DOI 10.17487/RFC3280, April 2002, 765 . 767 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 768 Network Access Identifier", RFC 4282, 769 DOI 10.17487/RFC4282, December 2005, 770 . 772 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 773 (TLS) Protocol Version 1.1", RFC 4346, 774 DOI 10.17487/RFC4346, April 2006, 775 . 777 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 778 and T. Wright, "Transport Layer Security (TLS) 779 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 780 . 782 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 783 (TLS) Protocol Version 1.2", RFC 5246, 784 DOI 10.17487/RFC5246, August 2008, 785 . 787 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 788 Authentication Protocol (EAP) Key Management Framework", 789 RFC 5247, DOI 10.17487/RFC5247, August 2008, 790 . 792 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 793 Morris, J., Hansen, M., and R. Smith, "Privacy 794 Considerations for Internet Protocols", RFC 6973, 795 DOI 10.17487/RFC6973, July 2013, 796 . 798 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 799 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 800 2014, . 802 [TS.33.501] 803 3GPP, "Security architecture and procedures for 5G 804 System", 3GPP TS 33.501 0.7.1, February 2018. 806 Appendix A. Updated references 808 All the following references in [RFC5216] are updated as specified 809 below when EAP-TLS is used with TLS 1.3 or higher. 811 All references to [RFC2560] are updated with [RFC6960]. 813 All references to [RFC3280] are updated with [RFC5280]. 815 All references to [RFC4282] are updated with [RFC7542]. 817 Appendix B. Acknowledgments 819 The authors want to thank Alan DeKok, Ari Keraenen, Bernard Aboba, 820 Eric Rescorla, Jari Arkko, Jim Schaad, Jouni Malinen, and Vesa 821 Torvinen for comments and suggestions on the draft. 823 Authors' Addresses 825 John Mattsson 826 Ericsson 827 Stockholm 164 40 828 Sweden 830 Email: john.mattsson@ericsson.com 832 Mohit Sethi 833 Ericsson 834 Jorvas 02420 835 Finland 837 Email: mohit@piuha.net