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