idnits 2.17.1 draft-ietf-emu-eaptlscert-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 date (November 19, 2020) is 1255 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-emu-eap-tls13-12 == Outdated reference: A later version (-10) exists of draft-ietf-tls-ctls-01 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Sethi 3 Internet-Draft J. Mattsson 4 Intended status: Informational Ericsson 5 Expires: May 23, 2021 S. Turner 6 sn3rd 7 November 19, 2020 9 Handling Large Certificates and Long Certificate Chains 10 in TLS-based EAP Methods 11 draft-ietf-emu-eaptlscert-07 13 Abstract 15 The Extensible Authentication Protocol (EAP), defined in RFC3748, 16 provides a standard mechanism for support of multiple authentication 17 methods. EAP-Transport Layer Security (EAP-TLS) and other TLS-based 18 EAP methods are widely deployed and used for network access 19 authentication. Large certificates and long certificate chains 20 combined with authenticators that drop an EAP session after only 40 - 21 50 round-trips is a major deployment problem. This document looks at 22 this problem in detail and describes the potential solutions 23 available. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 23, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Experience with Deployments . . . . . . . . . . . . . . . . . 4 62 4. Handling of Large Certificates and Long Certificate Chains . 5 63 4.1. Updating Certificates and Certificate Chains . . . . . . 5 64 4.1.1. Guidelines for Certificates . . . . . . . . . . . . . 6 65 4.1.2. Pre-distributing and Omitting CA certificates . . . . 7 66 4.1.3. Using Fewer Intermediate Certificates . . . . . . . . 7 67 4.2. Updating TLS and EAP-TLS Code . . . . . . . . . . . . . . 7 68 4.2.1. URLs for Client Certificates . . . . . . . . . . . . 7 69 4.2.2. Caching Certificates . . . . . . . . . . . . . . . . 8 70 4.2.3. Compressing Certificates . . . . . . . . . . . . . . 8 71 4.2.4. Compact TLS 1.3 . . . . . . . . . . . . . . . . . . . 9 72 4.2.5. Suppressing Intermediate Certificates . . . . . . . . 9 73 4.2.6. Raw Public Keys . . . . . . . . . . . . . . . . . . . 9 74 4.2.7. New Certificate Types and Compression Algorithms . . 10 75 4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 10 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 7.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 87 provides a standard mechanism for support of multiple authentication 88 methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] 89 [I-D.ietf-emu-eap-tls13] relies on TLS [RFC8446] to provide strong 90 mutual authentication with certificates [RFC5280] and is widely 91 deployed and often used for network access authentication. There are 92 also many other TLS-based EAP methods, such as Flexible 93 Authentication via Secure Tunneling (EAP-FAST) [RFC4851], Tunneled 94 Transport Layer Security (EAP-TTLS) [RFC5281], Tunnel Extensible 95 Authentication Protocol (EAP-TEAP) [RFC7170], and possibly many 96 vendor-specific EAP methods. 98 Certificates in EAP deployments can be relatively large, and the 99 certificate chains can be long. Unlike the use of TLS on the web, 100 where typically only the TLS server is authenticated; EAP-TLS 101 deployments typically authenticate both the EAP peer and the EAP 102 server. Also, from deployment experience, EAP peers typically have 103 longer certificate chains than servers. This is because EAP peers 104 often follow organizational hierarchies and tend to have many 105 intermediate certificates. Thus, EAP-TLS authentication usually 106 involves exchange of significantly more octets than when TLS is used 107 as part of HTTPS. 109 Section 3.1 of [RFC3748] states that EAP implementations can assume a 110 Maximum Transmission Unit (MTU) of at least 1020 octets from lower 111 layers. The EAP fragment size in typical deployments is just 1020 - 112 1500 octets (since the maximum Ethernet frame size is ~ 1500 bytes). 113 Thus, EAP-TLS authentication needs to be fragmented into many smaller 114 packets for transportation over the lower layers. Such fragmentation 115 not only can negatively affect the latency, but also results in other 116 challenges. For example, some EAP authenticator (access point) 117 implementations will drop an EAP session if it has not finished after 118 40 - 50 round-trips. This is a major problem and means that in many 119 situations, the EAP peer cannot perform network access authentication 120 even though both the sides have valid credentials for successful 121 authentication and key derivation. 123 Not all EAP deployments are constrained by the MTU of the lower 124 layer. For example, some implementations support EAP over Ethernet 125 "Jumbo" frames that can easily allow very large EAP packets. Larger 126 packets will naturally help lower the number of round trips required 127 for successful EAP-TLS authentication. However, deployment 128 experience has shown that these jumbo frames are not always 129 implemented correctly. Additionally, EAP fragment size is also 130 restricted by protocols such as RADIUS [RFC2865] which are 131 responsible for transporting EAP messages between an authenticator 132 and an EAP server. RADIUS can generally transport only about 4000 133 octets of EAP in a single message (the maximum length of RADIUS 134 packet is restricted to 4096 octets in [RFC2865]). 136 This document looks at related work and potential tools available for 137 overcoming the deployment challenges induced by large certificates 138 and long certificate chains. It then discusses the solutions 139 available to overcome these challenges. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 Readers are expected to be familiar with the terms and concepts used 150 in EAP [RFC3748], EAP-TLS [RFC5216], and TLS [RFC8446]. In 151 particular, this document frequently uses the following terms as they 152 have been defined in [RFC5216]: 154 Authenticator The entity initiating EAP authentication. Typically 155 implemented as part of a network switch or a wireless access 156 point. 158 EAP peer The entity that responds to the authenticator. In 159 [IEEE-802.1X], this entity is known as the supplicant. In EAP- 160 TLS, the EAP peer implements the TLS client role. 162 EAP server The entity that terminates the EAP authentication method 163 with the peer. In the case where no backend authentication 164 server is used, the EAP server is part of the authenticator. 165 In the case where the authenticator operates in pass-through 166 mode, the EAP server is located on the backend authentication 167 server. In EAP-TLS, the EAP server implements the TLS server 168 role. 170 The document additionally uses the terms "trust anchor" and 171 "certification path" defined in [RFC5280]. 173 3. Experience with Deployments 175 As stated earlier, the EAP fragment size in typical deployments is 176 just 1020 - 1500 octets. A certificate can, however, be large for a 177 number of reasons: 179 o It can have a long Subject Alternative Name field. 181 o It can have long Public Key and Signature fields. 183 o It can contain multiple object identifiers (OID) that indicate the 184 permitted uses of the certificate as noted in Section 5.3 of 185 [RFC5216]. Most implementations verify the presence of these OIDs 186 for successful authentication. 188 o It can contain multiple organization fields to reflect the 189 multiple group memberships of a user (in a client certificate). 191 A certificate chain (called a certification path in [RFC5280]) in 192 EAP-TLS can commonly have 2 - 6 intermediate certificates between the 193 end-entity certificate and the trust anchor. 195 The size of certificates (and certificate chains) may also increase 196 many-fold in the future with the introduction of quantum-safe 197 cryptography. For example, lattice-based cryptography would have 198 public keys of approximately 1000 bytes and signatures of 199 approximately 2000 bytes. 201 Many access point implementations drop EAP sessions that do not 202 complete within 40 - 50 round-trips. This means that if the chain is 203 larger than ~ 60 kbytes, EAP-TLS authentication cannot complete 204 successfully in most deployments. 206 4. Handling of Large Certificates and Long Certificate Chains 208 This section discusses some possible alternatives for overcoming the 209 challenge of large certificates and long certificate chains in EAP- 210 TLS authentication. Section 4.1 considers recommendations that 211 require an update of the certificates or certificate chains used for 212 EAP-TLS authentication without requiring changes to the existing EAP- 213 TLS code base. It also provides some guidelines that should be 214 followed when issuing certificates for use with EAP-TLS. Section 4.2 215 considers recommendations that rely on updates to the EAP-TLS 216 implementations and can be deployed with existing certificates. 217 Finally, Section 4.3 briefly discusses what could be done to update 218 or reconfigure authenticators when it is infeasible to replace 219 deployed components giving a solution which can be deployed without 220 changes to existing certificates or code. 222 4.1. Updating Certificates and Certificate Chains 224 Many IETF protocols now use elliptic curve cryptography (ECC) 225 [RFC6090] for the underlying cryptographic operations. The use of 226 ECC can reduce the size of certificates and signatures. For example, 227 at a 128-bit security level, the size of a public key with 228 traditional RSA is about 384 bytes, while the size of a public key 229 with ECC is only 32-64 bytes. Similarly, the size of a digital 230 signature with traditional RSA is 384 bytes, while the size is only 231 64 bytes with elliptic curve digital signature algorithm (ECDSA) and 232 Edwards-curve digital signature algorithm (EdDSA) [RFC8032]. Using 233 certificates that use ECC can reduce the number of messages in EAP- 234 TLS authentication, which can alleviate the problem of authenticators 235 dropping an EAP session because of too many round-trips. In the 236 absence of a standard application profile specifying otherwise, TLS 237 1.3 [RFC8446] requires implementations to support ECC. New cipher 238 suites that use ECC are also specified for TLS 1.2 [RFC8422]. Using 239 ECC-based cipher suites with existing code can significantly reduce 240 the number of messages in a single EAP session. 242 4.1.1. Guidelines for Certificates 244 The general guideline of keeping the certificate size small by not 245 populating fields with excessive information can help avert the 246 problems of failed EAP-TLS authentication. More specific 247 recommendations for certificates used with EAP-TLS are as follows: 249 o Object Identifier (OID) is an ASN.1 data type that defines unique 250 identifiers for objects. The OID's ASN.1 value, which is a string 251 of integers, is then used to name objects to which they relate. 252 The Distinguished Encoding Rules (DER) specify that the first two 253 integers always occupy one octet and subsequent integers are base 254 128-encoded in the fewest possible octets. OIDs are used lavishly 255 in X.509 certificates [RFC5280] and while not all can be avoided, 256 e.g., OIDs for extensions or algorithms and their associate 257 parameters, some are well within the certificate issuer's control: 259 * Each naming attribute in a DN (Directory Name) has one. DNs 260 are used in the issuer and subject fields as well as numerous 261 extensions. A shallower naming will be smaller, e.g., C=FI, 262 O=Example, SN=B0A123499EFC as against C=FI, O=Example, 263 OU=Division 1, SOPN=Southern Finland, CN=Coolest IoT Gadget 264 Ever, SN=B0A123499EFC. 266 * Every certificate policy (and qualifier) and any mappings to 267 another policy uses identifiers. Consider carefully what 268 policies apply. 270 o DirectoryString and GeneralName types are used extensively to name 271 things, e.g., the DN naming attribute O= (the organizational 272 naming attribute) DirectoryString includes "Example" for the 273 Example organization and uniformResourceIdentifier can be used to 274 indicate the location of the CRL, e.g., "http://crl.example.com/ 275 sfig2s1-128.crl", in the CRL Distribution Point extension. For 276 these particular examples, each character is a byte. For some 277 non-ASCII character strings in the DN, characters can be multi- 278 byte. Obviously, the names need to be unique, but there is more 279 than one way to accomplish this without long strings. This is 280 especially true if the names are not meant to be meaningful to 281 users. 283 o Extensions are necessary to comply with [RFC5280], but the vast 284 majority are optional. Include only those that are necessary to 285 operate. 287 o As stated earlier, certificate chains of the EAP peer often follow 288 organizational hierarchies. In such cases, information in 289 intermediate certificates (such as postal addresses) do not 290 provide any additional value and they can be shortened (for 291 example: only including the department name instead of the full 292 postal address). 294 4.1.2. Pre-distributing and Omitting CA certificates 296 The TLS Certificate message conveys the sending endpoint's 297 certificate chain. TLS allows endpoints to reduce the size of the 298 Certificate message by omitting certificates that the other endpoint 299 is known to possess. When using TLS 1.3, all certificates that 300 specify a trust anchor known by the other endpoint may be omitted 301 (see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or earlier, 302 only the self-signed certificate that specifies the root certificate 303 authority may be omitted (see Section 7.4.2 of [RFC5246] Therefore, 304 updating TLS implementations to version 1.3 can help to significantly 305 reduce the number of messages exchanged for EAP-TLS authentication. 306 The omitted certificates need to be pre-distributed independently of 307 TLS and the TLS implementations need to be configured to omit these 308 pre-distributed certificates. 310 4.1.3. Using Fewer Intermediate Certificates 312 The EAP peer certificate chain does not have to mirror the 313 organizational hierarchy. For successful EAP-TLS authentication, 314 certificate chains SHOULD NOT contain more than 4 intermediate 315 certificates. 317 Administrators responsible for deployments using TLS-based EAP 318 methods can examine the certificate chains and make rough 319 calculations about the number of round trips required for successful 320 authentication. For example, dividing the total size of all the 321 certificates in the peer and server certificate chain (in bytes) by 322 1020 bytes will indicate the minimum number of round trips required. 323 If this number exceeds 50, then, administrators can expect failures 324 with many common authenticator implementations. 326 4.2. Updating TLS and EAP-TLS Code 328 This section discusses how the fragmentation problem can be avoided 329 by updating the underlying TLS or EAP-TLS implementation. Note that 330 in some cases the new feature may already be implemented in the 331 underlying library and simply needs to be taken into use. 333 4.2.1. URLs for Client Certificates 335 [RFC6066] defines the "client_certificate_url" extension which allows 336 TLS clients to send a sequence of Uniform Resource Locators (URLs) 337 instead of the client certificate. URLs can refer to a single 338 certificate or a certificate chain. Using this extension can curtail 339 the amount of fragmentation in EAP deployments thereby allowing EAP 340 sessions to successfully complete. 342 4.2.2. Caching Certificates 344 The TLS Cached Information Extension [RFC7924] specifies an extension 345 where a server can exclude transmission of certificate information 346 cached in an earlier TLS handshake. The client and the server would 347 first execute the full TLS handshake. The client would then cache 348 the certificate provided by the server. When the TLS client later 349 connects to the same TLS server without using session resumption, it 350 can attach the "cached_info" extension to the ClientHello message. 351 This would allow the client to indicate that it has cached the 352 certificate. The client would also include a fingerprint of the 353 server certificate chain. If the server's certificate has not 354 changed, then the server does not need to send its certificate and 355 the corresponding certificate chain again. In case information has 356 changed, which can be seen from the fingerprint provided by the 357 client, the certificate payload is transmitted to the client to allow 358 the client to update the cache. The extension however necessitates a 359 successful full handshake before any caching. This extension can be 360 useful when, for example, a successful authentication between an EAP 361 peer and EAP server has occurred in the home network. If 362 authenticators in a roaming network are stricter at dropping long EAP 363 sessions, an EAP peer can use the Cached Information Extension to 364 reduce the total number of messages. 366 However, if all authenticators drop the EAP session for a given EAP 367 peer and EAP server combination, a successful full handshake is not 368 possible. An option in such a scenario would be to cache validated 369 certificate chains even if the EAP-TLS exchange fails, but such 370 caching is currently not specified in [RFC7924]. 372 4.2.3. Compressing Certificates 374 The TLS working group is also working on an extension for TLS 1.3 375 [I-D.ietf-tls-certificate-compression] that allows compression of 376 certificates and certificate chains during full handshakes. The 377 client can indicate support for compressed server certificates by 378 including this extension in the ClientHello message. Similarly, the 379 server can indicate support for compression of client certificates by 380 including this extension in the CertificateRequest message. While 381 such an extension can alleviate the problem of excessive 382 fragmentation in EAP-TLS, it can only be used with TLS version 1.3 383 and higher. Deployments that rely on older versions of TLS cannot 384 benefit from this extension. 386 4.2.4. Compact TLS 1.3 388 [I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and 389 reduces the message size of the protocol by removing obsolete 390 material and using more efficient encoding. It also defines a 391 compression profile with which either side can define a dictionary of 392 "known certificates". Thus, cTLS could provide another mechanism for 393 EAP-TLS deployments to reduce the size of messages and avoid 394 excessive fragmentation. 396 4.2.5. Suppressing Intermediate Certificates 398 For a client that has all intermediate certificates in the 399 certificate chain, having the server send intermediates in the TLS 400 handshake increases the size of the handshake unnecessarily. 401 [I-D.thomson-tls-sic] proposes an extension for TLS 1.3 that allows a 402 TLS client that has access to the complete set of published 403 intermediate certificates to inform servers of this fact so that the 404 server can avoid sending intermediates, reducing the size of the TLS 405 handshake. The mechanism is intended to be complementary with 406 certificate compression. 408 The Authority Information Access (AIA) extension specified in 409 [RFC5280] can be used with end-entity and CA certificates to access 410 information about the issuer of the certificate in which the 411 extension appears. For example, it can be used to provide the 412 address of the OCSP responder from where revocation status of the 413 certificate (in which the extension appears) can be checked. It can 414 also be used to obtain the issuer certificate. Thus, the AIA 415 extension can reduce the size of the certificate chain by only 416 including a pointer to the issuer certificate instead of including 417 the entire issuer certificate. However, it requires the side 418 receiving the certificate containing the extension to have network 419 connectivity (unless the information is already cached locally). 420 Naturally, such indirection cannot be used for the server certificate 421 (since EAP peers in most deployments do not have network connectivity 422 before authentication and typically do not maintain an up-to-date 423 local cache of issuer certificates). 425 4.2.6. Raw Public Keys 427 [RFC7250] defines a new certificate type and TLS extensions to enable 428 the use of raw public keys for authentication. Raw public keys use 429 only a subset of information found in typical certificates and are 430 therefore much smaller in size. However, raw public keys require an 431 out-of-band mechanism to bind the public key with the entity 432 presenting the key. Using raw public keys will obviously avoid the 433 fragmentation problems resulting from large certificates and long 434 certificate chains. Deployments can consider their use as long as an 435 appropriate out-of-band mechanism for binding public keys with 436 identifiers is in place. Naturally, deployments will also need to 437 consider the challenges of revocation and key rotation with the use 438 of raw public keys. 440 4.2.7. New Certificate Types and Compression Algorithms 442 There is ongoing work to specify new certificate types and 443 compression algorithms. For example, 444 [I-D.mattsson-tls-cbor-cert-compress] defines a compression algorithm 445 for certificates that relies on Concise Binary Object Representation 446 (CBOR) [RFC7049]. [I-D.tschofenig-tls-cwt] registers a new TLS 447 Certificate type which would enable TLS implementations to use CBOR 448 Web Tokens (CWTs) [RFC8392] as certificates. While these are early 449 initiatives, future EAP-TLS deployments can consider the use of these 450 new certificate types and compression algorithms to avoid large 451 message sizes. 453 4.3. Updating Authenticators 455 There are several legitimate reasons that authenticators may want to 456 limit the number of round-trips/packets/octets that can be sent. The 457 main reason has been to work around issues where the EAP peer and EAP 458 server end up in an infinite loop ACKing their messages. Another 459 reason is that unlimited communication from an unauthenticated device 460 using EAP could provide a channel for inappropriate bulk data 461 transfer. A third reason is to prevent denial-of-service attacks. 463 Updating the millions of already deployed access points and switches 464 is in many cases not realistic. Vendors may be out of business or no 465 longer supporting the products and administrators may have lost the 466 login information to the devices. For practical purposes the EAP 467 infrastructure is ossified for the time being. 469 Vendors making new authenticators should consider increasing the 470 number of round-trips allowed to 100 before denying the EAP 471 authentication to complete. Based on the size of the certificates 472 and certificate chains currently deployed, such an increase would 473 likely ensure that peers and servers can complete EAP-TLS 474 authentication. At the same time, administrators responsible for EAP 475 deployments should ensure that this 100 roundtrip limit is not 476 exceeded in practice. 478 5. IANA Considerations 480 This document includes no request to IANA. 482 6. Security Considerations 484 Updating implementations to TLS version 1.3 allows omitting all 485 certificates with a trust anchor known by the other endpoint. TLS 486 1.3 additionally provides improved security, privacy, and reduced 487 latency for EAP-TLS [I-D.ietf-emu-eap-tls13]. 489 Security considerations when compressing certificates are specified 490 in [I-D.ietf-tls-certificate-compression]. 492 Specific security considerations of the referenced documents apply 493 when they are taken into use. 495 7. References 497 7.1. Normative References 499 [I-D.ietf-emu-eap-tls13] 500 Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3", 501 draft-ietf-emu-eap-tls13-12 (work in progress), November 502 2020. 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, 506 DOI 10.17487/RFC2119, March 1997, 507 . 509 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 510 Levkowetz, Ed., "Extensible Authentication Protocol 511 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 512 . 514 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 515 Flexible Authentication via Secure Tunneling Extensible 516 Authentication Protocol Method (EAP-FAST)", RFC 4851, 517 DOI 10.17487/RFC4851, May 2007, 518 . 520 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 521 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 522 March 2008, . 524 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 525 Housley, R., and W. Polk, "Internet X.509 Public Key 526 Infrastructure Certificate and Certificate Revocation List 527 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 528 . 530 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 531 Protocol Tunneled Transport Layer Security Authenticated 532 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 533 DOI 10.17487/RFC5281, August 2008, 534 . 536 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 537 "Tunnel Extensible Authentication Protocol (TEAP) Version 538 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 539 . 541 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 542 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 543 May 2017, . 545 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 546 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 547 . 549 7.2. Informative References 551 [I-D.ietf-tls-certificate-compression] 552 Ghedini, A. and V. Vasiliev, "TLS Certificate 553 Compression", draft-ietf-tls-certificate-compression-10 554 (work in progress), January 2020. 556 [I-D.ietf-tls-ctls] 557 Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 558 1.3", draft-ietf-tls-ctls-01 (work in progress), November 559 2020. 561 [I-D.mattsson-tls-cbor-cert-compress] 562 Mattsson, J., Selander, G., Raza, S., Hoglund, J., and M. 563 Furuhed, "CBOR Certificate Algorithm for TLS Certificate 564 Compression", draft-mattsson-tls-cbor-cert-compress-00 565 (work in progress), March 2020. 567 [I-D.thomson-tls-sic] 568 Thomson, M., "Suppressing Intermediate Certificates in 569 TLS", draft-thomson-tls-sic-00 (work in progress), March 570 2019. 572 [I-D.tschofenig-tls-cwt] 573 Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens 574 (CWTs) in Transport Layer Security (TLS) and Datagram 575 Transport Layer Security (DTLS)", draft-tschofenig-tls- 576 cwt-02 (work in progress), July 2020. 578 [IEEE-802.1X] 579 Institute of Electrical and Electronics Engineers, "IEEE 580 Standard for Local and metropolitan area networks -- Port- 581 Based Network Access Control", IEEE Standard 802.1X-2010 , 582 February 2010. 584 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 585 "Remote Authentication Dial In User Service (RADIUS)", 586 RFC 2865, DOI 10.17487/RFC2865, June 2000, 587 . 589 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 590 (TLS) Protocol Version 1.2", RFC 5246, 591 DOI 10.17487/RFC5246, August 2008, 592 . 594 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 595 Extensions: Extension Definitions", RFC 6066, 596 DOI 10.17487/RFC6066, January 2011, 597 . 599 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 600 Curve Cryptography Algorithms", RFC 6090, 601 DOI 10.17487/RFC6090, February 2011, 602 . 604 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 605 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 606 October 2013, . 608 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 609 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 610 Transport Layer Security (TLS) and Datagram Transport 611 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 612 June 2014, . 614 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 615 (TLS) Cached Information Extension", RFC 7924, 616 DOI 10.17487/RFC7924, July 2016, 617 . 619 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 620 Signature Algorithm (EdDSA)", RFC 8032, 621 DOI 10.17487/RFC8032, January 2017, 622 . 624 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 625 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 626 May 2018, . 628 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 629 Curve Cryptography (ECC) Cipher Suites for Transport Layer 630 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 631 DOI 10.17487/RFC8422, August 2018, 632 . 634 Acknowledgements 636 This draft is a result of several useful discussions with Alan DeKok, 637 Bernard Aboba, Jari Arkko, Jouni Malinen, Darshak Thakore, and Hannes 638 Tschofening. 640 Authors' Addresses 642 Mohit Sethi 643 Ericsson 644 Jorvas 02420 645 Finland 647 Email: mohit@piuha.net 649 John Mattsson 650 Ericsson 651 Kista 652 Sweden 654 Email: john.mattsson@ericsson.com 656 Sean Turner 657 sn3rd 659 Email: sean@sn3rd.com