idnits 2.17.1 draft-ietf-emu-eap-tls13-00.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 (May 29, 2018) is 2156 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 573 -- Looks like a reference, but probably isn't: '3' on line 580 -- Looks like a reference, but probably isn't: '4' on line 585 == 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 May 29, 2018 6 Expires: November 30, 2018 8 Using EAP-TLS with TLS 1.3 9 draft-ietf-emu-eap-tls13-00 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 November 30, 2018. 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 . . . . . . . . . . . . . . . . . . . . . 7 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 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 13 66 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 14 69 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 14 70 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 14 71 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 14 72 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 15 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 75 6.2. Informative references . . . . . . . . . . . . . . . . . 16 76 Appendix A. Updated references . . . . . . . . . . . . . . . . . 17 77 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 80 1. Introduction 82 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 83 provides a standard mechanism for support of multiple authentication 84 methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies 85 an EAP authentication method with certificate-based mutual 86 authentication and key derivation utilizing the TLS handshake 87 protocol for cryptographic algorithms and protocol version 88 negotiation, mutual authentication, and establishment of shared 89 secret keying material. EAP-TLS is widely supported for 90 authentication in IEEE 802.11 [IEEE-802.11] networks (Wi-Fi) using 91 IEEE 802.1X [IEEE-802.1X] and it's the default mechanism for 92 certificate based authentication in MulteFire [MulteFire] and 3GPP 5G 93 [TS.33.501] networks. EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] 94 and TLS 1.1 [RFC4346], but works perfectly also with TLS 1.2 95 [RFC5246]. 97 Weaknesses found in previous versions of TLS, as well as new 98 requirements for security, privacy, and reduced latency has led to 99 the development of TLS 1.3 [I-D.ietf-tls-tls13], which in large parts 100 is a complete remodeling of the TLS handshake protocol including a 101 different message flow, different handshake messages, different key 102 schedule, different cipher suites, different resumption, and 103 different privacy protection. This means that significant parts of 104 the normative text in the previous EAP-TLS specification [RFC5216] 105 are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore, 106 aspects such as resumption, privacy handling, and key derivation need 107 to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). 109 This document defines how to use EAP-TLS with TLS 1.3 (or higher) and 110 does not change how EAP-TLS is used with older versions of TLS. 111 While this document updates EAP-TLS [RFC5216], it remains backwards 112 compatible with it and existing implementations of EAP-TLS. This 113 document only describes differences compared to [RFC5216]. 115 In addition to the improved security and privacy offered by TLS 1.3, 116 there are other significant benefits of using EAP-TLS with TLS 1.3. 117 When EAP-TLS is used with support for privacy, TLS 1.3 requires two 118 fewer round-trips. TLS 1.3 also introduces more possibilities to 119 reduce fragmentation when compared to earlier versions of TLS. 121 1.1. Requirements and Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. Readers 126 are expected to be familiar with the terms and concepts used in EAP- 127 TLS [RFC5216] and TLS 1.3 [I-D.ietf-tls-tls13]. 129 2. Protocol Overview 131 2.1. Overview of the EAP-TLS Conversation 133 2.1.1. Base Case 135 TLS 1.3 changes both the message flow and the handshake messages 136 compared to earlier versions of TLS. Therefore, much of Section 2.1 137 of RFC5216 [RFC5216] does not apply for TLS 1.3 (or higher). 139 After receiving an EAP-Request packet with EAP-Type=EAP-TLS as 140 described in [RFC5216] the conversation will continue with the TLS 141 handshake protocol encapsulated in the data fields of EAP-Response 142 and EAP-Request packets. When EAP-TLS is used with TLS version 1.3 143 or higher, the formatting and processing of the TLS handshake SHALL 144 be done as specified in that version of TLS. This document only 145 lists additional and different requirements, restrictions, and 146 processing compared to [I-D.ietf-tls-tls13] and [RFC5216]. 148 The EAP server MUST authenticate with a certificate and SHOULD 149 require the EAP peer to authenticate with a certificate. 150 Certificates can be of any type supported by TLS including raw public 151 keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except 152 for resumption. SessionID is deprecated in TLS 1.3 and the EAP 153 server SHALL ignore the legacy_session_id field if TLS 1.3 is 154 negotiated. Resumption is handled as described in Section 2.1.2. 155 After the TLS handshake has completed, the EAP server sends EAP- 156 Success. 158 As stated in [RFC5216], the TLS cipher suite shall not be used to 159 protect application data. This applies also for early application 160 data. When EAP-TLS is used with TLS 1.3, early application data 161 SHALL NOT be used. 163 In the case where EAP-TLS with mutual authentication is successful, 164 the conversation will appear as shown in Figure 1. 166 EAP Peer EAP Server 168 EAP-Request/ 169 <-------- Identity 170 EAP-Response/ 171 Identity (MyID) --------> 172 EAP-Request/ 173 EAP-Type=EAP-TLS 174 <-------- (TLS Start) 175 EAP-Response/ 176 EAP-Type=EAP-TLS 177 (TLS ClientHello) --------> 178 EAP-Request/ 179 EAP-Type=EAP-TLS 180 (TLS ServerHello, 181 TLS EncryptedExtensions, 182 TLS CertificateRequest, 183 TLS Certificate, 184 TLS CertificateVerify, 185 <-------- TLS Finished) 186 EAP-Response/ 187 EAP-Type=EAP-TLS 188 (TLS Certificate, 189 TLS CertificateVerify, 190 TLS Finished) --------> 191 <-------- EAP-Success 193 Figure 1: EAP-TLS mutual authentication 195 When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support 196 of resumption in the initial authentication. To indicate support of 197 resumption, the EAP server sends a NewSessionTicket message 198 (containing a PSK and other parameters) after it has received the 199 Finished message. 201 In the case where EAP-TLS with mutual authentication and ticket 202 establishment is successful, the conversation will appear as shown in 203 Figure 2. 205 EAP Peer EAP Server 207 EAP-Request/ 208 <-------- Identity 209 EAP-Response/ 210 Identity (MyID) --------> 211 EAP-Request/ 212 EAP-Type=EAP-TLS 213 <-------- (TLS Start) 214 EAP-Response/ 215 EAP-Type=EAP-TLS 216 (TLS ClientHello) --------> 217 EAP-Request/ 218 EAP-Type=EAP-TLS 219 (TLS ServerHello, 220 TLS EncryptedExtensions, 221 TLS CertificateRequest, 222 TLS Certificate, 223 TLS CertificateVerify, 224 <-------- TLS Finished) 225 EAP-Response/ 226 EAP-Type=EAP-TLS 227 (TLS Certificate, 228 TLS CertificateVerify, 229 TLS Finished) --------> 230 EAP-Request/ 231 EAP-Type=EAP-TLS 232 <-------- (TLS NewSessionTicket) 233 EAP-Response/ 234 EAP-Type=EAP-TLS --------> 235 <-------- EAP-Success 237 Figure 2: EAP-TLS ticket establishment 239 2.1.2. Resumption 241 TLS 1.3 replaces the session resumption mechanisms in earlier 242 versions of TLS with a new PSK exchange. When EAP-TLS is used with 243 TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism 244 compatible with that version of TLS. 246 For TLS 1.3, resumption is described in Section 2.2 of 247 [I-D.ietf-tls-tls13]. If the client has received a NewSessionTicket 248 message from the server, the client can use the PSK identity received 249 in the ticket to negotiate the use of the associated PSK. If the 250 server accepts it, then the security context of the new connection is 251 tied to the original connection and the key derived from the initial 252 handshake is used to bootstrap the cryptographic state instead of a 253 full handshake. It is left up to the EAP peer whether to use 254 resumption, but a EAP peer SHOULD use resumption as long as it has a 255 valid ticket cached. It is RECOMMENDED that the EAP server accept 256 resumption as long as the ticket is valid. However, the server MAY 257 choose to require a full authentication. 259 A subsequent authentication using resumption, where both sides 260 authenticate successfully is shown in Figure 3. 262 EAP Peer EAP Server 264 EAP-Request/ 265 <-------- Identity 266 EAP-Response/ 267 Identity (MyID) --------> 268 EAP-Request/ 269 EAP-Type=EAP-TLS 270 <-------- (TLS Start) 271 EAP-Response/ 272 EAP-Type=EAP-TLS 273 (TLS ClientHello) --------> 274 EAP-Request/ 275 EAP-Type=EAP-TLS 276 (TLS ServerHello, 277 TLS EncryptedExtensions, 278 <-------- TLS Finished) 279 EAP-Response/ 280 EAP-Type=EAP-TLS 281 (TLS Finished) --------> 282 <-------- EAP-Success 284 Figure 3: EAP-TLS resumption 286 As specified in Section 2.2 of [I-D.ietf-tls-tls13], the EAP peer 287 SHOULD supply a "key_share" extension when offering resumption, which 288 allows the EAP server to decline resumption and continue the 289 handshake as a full handshake. The message flow in this case is 290 given by Figure 1 or Figure 2. If the EAP peer did not supply a 291 "key_share" extension when offering resumption, the EAP server needs 292 to reject the ClientHello and the EAP peer needs to restart a full 293 handshake. The message flow in this case is given by Figure 4 294 followed by Figure 1 or Figure 2. 296 2.1.3. Termination 298 TLS 1.3 changes both the message flow and the handshake messages 299 compared to earlier versions of TLS. Therefore, some normative text 300 in Section 2.1.3 of RC5216 [RFC5216] does not apply for TLS 1.3 or 301 higher. The two paragraphs below replaces the corresponding 302 paragraphs in Section 2.1.3 of RC5216 [RFC5216] when EAP-TLS is used 303 with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 of 304 RC5216 [RFC5216] still apply with the exception that SessionID is 305 deprecated. 307 If the EAP Server authenticates successfully the EAP Peer MUST 308 send an EAP-Response message with EAP-Type=EAP-TLS containing TLS 309 records confirming the processing in the version of TLS used. 311 If the EAP Peer authenticates successfully the EAP Server MUST 312 send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS 313 records confirming to the processing in the version of TLS used. 314 The message flow ends with the EAP Server sending a EAP-Success 315 message. 317 In the case where the server rejects the ClientHello, the 318 conversation will appear as shown in Figure 4. 320 EAP Peer EAP Server 322 EAP-Request/ 323 <-------- Identity 324 EAP-Response/ 325 Identity (MyID) --------> 326 EAP-Request/ 327 EAP-Type=EAP-TLS 328 <-------- (TLS Start) 329 EAP-Response/ 330 EAP-Type=EAP-TLS 331 (TLS ClientHello) --------> 332 EAP-Request/ 333 EAP-Type=EAP-TLS 334 <-------- (TLS Alert Message) 335 EAP-Response/ 336 EAP-Type=EAP-TLS --------> 337 <-------- EAP-Failure 339 Figure 4: EAP-TLS server rejection of ClientHello 341 In the case where server authentication is unsuccessful, the 342 conversation will appear as shown in Figure 5. 344 EAP Peer EAP Server 346 EAP-Request/ 347 <-------- Identity 348 EAP-Response/ 349 Identity (MyID) --------> 350 EAP-Request/ 351 EAP-Type=EAP-TLS 352 <-------- (TLS Start) 353 EAP-Response/ 354 EAP-Type=EAP-TLS 355 (TLS ClientHello) --------> 356 EAP-Request/ 357 EAP-Type=EAP-TLS 358 (TLS ServerHello, 359 TLS EncryptedExtensions, 360 TLS CertificateRequest, 361 TLS Certificate, 362 TLS CertificateVerify, 363 <-------- TLS Finished) 364 EAP-Response/ 365 EAP-Type=EAP-TLS 366 (TLS Alert Message) 367 --------> 368 <-------- EAP-Failure 370 Figure 5: EAP-TLS unsuccessful server authentication 372 In the case where the server authenticates to the peer successfully, 373 but the peer fails to authenticate to the server, the conversation 374 will appear as shown in Figure 6. 376 EAP Peer EAP Server 378 EAP-Request/ 379 <-------- Identity 380 EAP-Response/ 381 Identity (MyID) --------> 382 EAP-Request/ 383 EAP-Type=EAP-TLS 384 <-------- (TLS Start) 385 EAP-Response/ 386 EAP-Type=EAP-TLS 387 (TLS ClientHello) --------> 388 EAP-Request/ 389 EAP-Type=EAP-TLS 390 (TLS ServerHello, 391 TLS EncryptedExtensions, 392 TLS CertificateRequest, 393 TLS Certificate, 394 TLS CertificateVerify, 395 <-------- TLS Finished) 396 EAP-Response/ 397 EAP-Type=EAP-TLS 398 (TLS Certificate, 399 TLS CertificateVerify, 400 TLS Finished) --------> 401 EAP-Request/ 402 EAP-Type=EAP-TLS 403 <-------- (TLS Alert Message) 404 EAP-Response/ 405 EAP-Type=EAP-TLS --------> 406 <-------- EAP-Failure 408 Figure 6: EAP-TLS unsuccessful client authentication 410 2.1.4. Privacy 412 TLS 1.3 significantly increases privacy when compared to earlier 413 version of TLS by forbidding cipher suites without confidentiality 414 and encrypting large parts of the TLS handshake including the 415 certificate messages. 417 EAP-TLS peer and server implementations supporting TLS 1.3 or higher 418 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 419 in [RFC7542]) and the client MUST confidentiality protect its 420 identity (e.g. using Anonymous NAIs) when the EAP-TLS server is known 421 to support TLS 1.3 or higher. 423 As the certificate messages in TLS 1.3 are encrypted, there is no 424 need to send an empty certificate_list or perform a second handshake 425 (as needed by EAP-TLS when with earlier versions of TLS). When EAP- 426 TLS is used with TLS version 1.3 or higher the EAP-TLS peer and EAP- 427 TLS server SHALL follow the processing specified by the used version 428 of TLS. For TLS 1.3 this means that the EAP-TLS peer only sends an 429 empty certificate_list if it does not have an appropriate certificate 430 to send and the EAP-TLS server MAY treat an empty certificate_list as 431 a terminal condition. 433 When EAP-TLS is used with TLS 1.3 and privacy, no extra round-trips 434 are added and the message flow looks just like a normal message flow 435 with the only difference that an anonymous NAI is used. In the case 436 where EAP-TLS with mutual authentication and privacy is successful, 437 the conversation will appear as shown in Figure 7. 439 EAP Peer EAP Server 441 EAP-Request/ 442 <-------- Identity 443 EAP-Response/ 444 Identity (Anonymous NAI) --------> 445 EAP-Request/ 446 EAP-Type=EAP-TLS 447 <-------- (TLS Start) 448 EAP-Response/ 449 EAP-Type=EAP-TLS 450 (TLS ClientHello) --------> 451 EAP-Request/ 452 EAP-Type=EAP-TLS 453 (TLS ServerHello, 454 TLS EncryptedExtensions, 455 TLS CertificateRequest, 456 TLS Certificate, 457 TLS CertificateVerify, 458 <-------- TLS Finished) 459 EAP-Response/ 460 EAP-Type=EAP-TLS 461 (TLS Certificate, 462 TLS CertificateVerify, 463 TLS Finished) --------> 464 <-------- EAP-Success 466 Figure 7: EAP-TLS privacy 468 2.1.5. Fragmentation 470 Including ContentType and ProtocolVersion a single TLS record may be 471 up to 16387 octets in length. Some EAP implementations and access 472 networks may limit the number of EAP packet exchanges that can be 473 handled. To avoid fragmentation, it is RECOMMENDED to keep the sizes 474 of client, server, and trust anchor certificates small and the length 475 of the certificate chains short. It addition, it is RECOMMENDED to 476 use mechanisms that reduce the sizes of Certificate messages. 478 While Elliptic Curve Cryptography (ECC) was optional for earlier 479 version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of 480 [I-D.ietf-tls-tls13]). To avoid fragmentation, the use of ECC in 481 certificates, signature algorithms, and groups are RECOMMENDED when 482 using EAP-TLS with TLS 1.3 or higher. At a 128-bit security level, 483 this reduces public key sizes from 384 bytes (RSA and DHE) to 32 484 bytes (ECDHE) and signatures from 384 bytes (RSA) to 64 bytes (ECDSA 485 and EdDSA). An EAP-TLS deployment MAY further reduce the certificate 486 sizes by limiting the number of Subject Alternative Names. 488 Endpoints SHOULD reduce the sizes of Certificate messages by omitting 489 certificates that the other endpoint is known to possess. When using 490 TLS 1.3, all certificates that specifies a trust anchor may be 491 omitted (see Section 4.4.2 of [I-D.ietf-tls-tls13]). When using TLS 492 1.2 or earlier, only the self-signed certificate that specifies the 493 root certificate authority may be omitted (see Section 7.4.2 of 494 [RFC5246]). EAP-TLS peers and servers SHOULD support and use the 495 Cached Information Extension as specified in [RFC7924]. EAP-TLS 496 peers and servers MAY use other extensions for reducing the sizes of 497 Certificate messages, e.g. certificate compression 498 [I-D.ietf-tls-certificate-compression]. 500 2.2. Identity Verification 502 No updates to [RFC5216]. 504 2.3. Key Hierarchy 506 TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier 507 versions of TLS with HKDF and completely changes the Key Schedule. 508 The key hierarchies shown in Section 2.3 of [RFC5216] are therefore 509 not correct when EAP-TLS is used with TLS version 1.3 or higher. For 510 TLS 1.3 the key schedule is described in Section 7.1 of 511 [I-D.ietf-tls-tls13]. 513 When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, 514 IV, and Session-Id SHALL be derived from the exporter_master_secret 515 using the TLS exporter interface [RFC5705] (for TLS 1.3 this is 516 defined in Section 7.5 of [I-D.ietf-tls-tls13]). 518 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128) 519 IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", "", 64) 520 Session-Id = TLS-Exporter("EXPORTER_EAP_TLS_Session-Id", "", 64) 522 By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation 523 without having to extract the Master Secret, ClientHello.random, and 524 ServerHello.random in a non-standard way. 526 All other parameters such as MSK and EMSK are derived as specified in 527 EAP-TLS [RFC5216], Section 2.3. The use of these keys is specific to 528 the lower layer, as described [RFC5247]. 530 2.4. Parameter Negotiation and Compliance Requirements 532 TLS 1.3 cipher suites are defined differently than in earlier 533 versions of TLS (see Section B.4 of [I-D.ietf-tls-tls13]), and the 534 cipher suites discussed in Section 2.4 of [RFC5216] can therefore not 535 be used when EAP-TLS is used with TLS version 1.3 or higher. The 536 requirements on protocol version and compression given in Section 2.4 537 of [RFC5216] still apply. 539 When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS 540 peers and servers MUST comply with the requirements for the TLS 541 version used. For TLS 1.3 the compliance requirements are defined in 542 Section 9 of [I-D.ietf-tls-tls13]. 544 3. Detailed Description of the EAP-TLS Protocol 546 No updates to [RFC5216]. 548 4. IANA considerations 550 This section provides guidance to the Internet Assigned Numbers 551 Authority (IANA) regarding registration of values related to the EAP- 552 TLS 1.3 protocol in accordance with [RFC8126]. 554 This memo requires IANA to add the following labels to the TLS 555 Exporter Label Registry defined by [RFC5705]. These labels are used 556 in derivation of Key_Material, IV and Session-Id as defined in 557 Section 2.3: 559 o "EXPORTER_EAP_TLS_Key_Material" 561 o "EXPORTER_EAP_TLS_IV" 562 o "EXPORTER_EAP_TLS_Session-Id" 564 5. Security Considerations 566 5.1. Security Claims 568 Using EAP-TLS with TLS 1.3 does not change the security claims for 569 EAP-TLS as given in Section 4.1 of [RFC5216]. However, it 570 strengthens several of the claims as described in the following 571 updates to the notes given in Section 4.1 of [RFC5216]. 573 [2] Confidentiality: The TLS 1.3 handshake offers much better 574 confidentiality than earlier versions of TLS by mandating cipher 575 suites with confidentiality and encrypting certificates and some of 576 the extensions, see [I-D.ietf-tls-tls13]. When using EAP-TLS with 577 TLS 1.3, the use of privacy does not cause any additional round- 578 trips. 580 [3] Key strength: TLS 1.3 forbids all algorithms with known 581 weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 582 only supports cryptographic algorithms offering at least 112-bit 583 security, see [I-D.ietf-tls-tls13]. 585 [4] Cryptographic Negotiation: TLS 1.3 increases the number of 586 cryptographic parameters that are negotiated in the handshake. When 587 EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic 588 negotiation of AEAD algorithm, HKDF hash algorithm, key exchange 589 groups, and signature algorithm, see Section 4.1.1 of 590 [I-D.ietf-tls-tls13]. 592 5.2. Peer and Server Identities 594 No updates to [RFC5216]. 596 5.3. Certificate Validation 598 No updates to [RFC5216]. 600 5.4. Certificate Revocation 602 The OCSP status handling in TLS 1.3 is different from earlier 603 versions of TLS, see Section 4.4.2.1 of [I-D.ietf-tls-tls13]. In TLS 604 1.3 the OCSP information is carried in the CertificateEntry 605 containing the associated certificate instead of a separate 606 CertificateStatus message as in [RFC4366]. This enables sending OCSP 607 information for all certificates in the certificate chain. 609 EAP-TLS peers and servers supporting TLS 1.3 SHOULD support 610 Certificate Status Requests (OCSP stapling) as specified in [RFC6066] 611 and Section 4.4.2.1 of [I-D.ietf-tls-tls13]. The use of Certificate 612 Status Requests to determine the current status of the EAP server's 613 certificate is RECOMMENDED. 615 5.5. Packet Modification Attacks 617 No updates to [RFC5216]. 619 6. References 621 6.1. Normative References 623 [I-D.ietf-tls-tls13] 624 Rescorla, E., "The Transport Layer Security (TLS) Protocol 625 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 626 March 2018. 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, 630 DOI 10.17487/RFC2119, March 1997, 631 . 633 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 634 Levkowetz, Ed., "Extensible Authentication Protocol 635 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 636 . 638 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 639 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 640 March 2008, . 642 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 643 Housley, R., and W. Polk, "Internet X.509 Public Key 644 Infrastructure Certificate and Certificate Revocation List 645 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 646 . 648 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 649 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 650 March 2010, . 652 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 653 Extensions: Extension Definitions", RFC 6066, 654 DOI 10.17487/RFC6066, January 2011, 655 . 657 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 658 Galperin, S., and C. Adams, "X.509 Internet Public Key 659 Infrastructure Online Certificate Status Protocol - OCSP", 660 RFC 6960, DOI 10.17487/RFC6960, June 2013, 661 . 663 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 664 DOI 10.17487/RFC7542, May 2015, 665 . 667 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 668 (TLS) Cached Information Extension", RFC 7924, 669 DOI 10.17487/RFC7924, July 2016, 670 . 672 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 673 Writing an IANA Considerations Section in RFCs", BCP 26, 674 RFC 8126, DOI 10.17487/RFC8126, June 2017, 675 . 677 6.2. Informative references 679 [I-D.ietf-tls-certificate-compression] 680 Ghedini, A. and V. Vasiliev, "Transport Layer Security 681 (TLS) Certificate Compression", draft-ietf-tls- 682 certificate-compression-03 (work in progress), April 2018. 684 [IEEE-802.11] 685 Institute of Electrical and Electronics Engineers, "IEEE 686 Standard for Information technology--Telecommunications 687 and information exchange between systems Local and 688 metropolitan area networks--Specific requirements - Part 689 11: Wireless LAN Medium Access Control (MAC) and Physical 690 Layer (PHY) Specifications", IEEE Std 802.11-2016 691 (Revision of IEEE Std 802.11-2012) , December 2016. 693 [IEEE-802.1X] 694 Institute of Electrical and Electronics Engineers, "IEEE 695 Standard for Local and metropolitan area networks -- Port- 696 Based Network Access Control", IEEE Standard 802.1X-2010 , 697 February 2010. 699 [MulteFire] 700 MulteFire, "MulteFire Release 1.0.1 specification", 2017. 702 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 703 RFC 2246, DOI 10.17487/RFC2246, January 1999, 704 . 706 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 707 Adams, "X.509 Internet Public Key Infrastructure Online 708 Certificate Status Protocol - OCSP", RFC 2560, 709 DOI 10.17487/RFC2560, June 1999, 710 . 712 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 713 X.509 Public Key Infrastructure Certificate and 714 Certificate Revocation List (CRL) Profile", RFC 3280, 715 DOI 10.17487/RFC3280, April 2002, 716 . 718 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 719 Network Access Identifier", RFC 4282, 720 DOI 10.17487/RFC4282, December 2005, 721 . 723 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 724 (TLS) Protocol Version 1.1", RFC 4346, 725 DOI 10.17487/RFC4346, April 2006, 726 . 728 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 729 and T. Wright, "Transport Layer Security (TLS) 730 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 731 . 733 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 734 (TLS) Protocol Version 1.2", RFC 5246, 735 DOI 10.17487/RFC5246, August 2008, 736 . 738 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 739 Authentication Protocol (EAP) Key Management Framework", 740 RFC 5247, DOI 10.17487/RFC5247, August 2008, 741 . 743 [TS.33.501] 744 3GPP, "Security architecture and procedures for 5G 745 System", 3GPP TS 33.501 0.7.1, February 2018. 747 Appendix A. Updated references 749 All the following references in [RFC5216] are updated as specified 750 below when EAP-TLS is used with TLS 1.3 or higher. 752 All references to [RFC2560] are updated with [RFC6960]. 754 All references to [RFC3280] are updated with [RFC5280]. 756 All references to [RFC4282] are updated with [RFC7542]. 758 Appendix B. Acknowledgments 760 The authors want to thank Alan DeKok, Ari Keraenen, Bernard Aboba, 761 Jari Arkko, and Vesa Torvinen for comments and suggestions on the 762 draft. 764 Authors' Addresses 766 John Mattsson 767 Ericsson 768 164 40 Stockholm 769 Sweden 771 Email: john.mattsson@ericsson.com 773 Mohit Sethi 774 Ericsson 775 Jorvas 02420 776 Finland 778 Email: mohit@piuha.net