idnits 2.17.1 draft-ietf-emu-eaptlscert-03.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 (May 9, 2020) is 1447 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-09 == Outdated reference: A later version (-10) exists of draft-ietf-tls-ctls-00 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: November 10, 2020 S. Turner 6 sn3rd 7 May 9, 2020 9 Handling Large Certificates and Long Certificate Chains 10 in TLS-based EAP Methods 11 draft-ietf-emu-eaptlscert-03 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 November 10, 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.2. Updating TLS and EAP-TLS Code . . . . . . . . . . . . . . 6 63 4.2.1. Pre-distributing and Omitting CA Certificates . . . . 6 64 4.2.2. URLs for Client Certificates . . . . . . . . . . . . 7 65 4.2.3. Compact TLS 1.3 . . . . . . . . . . . . . . . . . . . 7 66 4.2.4. Caching Certificates . . . . . . . . . . . . . . . . 7 67 4.2.5. Compressing Certificates . . . . . . . . . . . . . . 8 68 4.2.6. Suppressing Intermediate Certificates . . . . . . . . 8 69 4.2.7. Using Fewer Intermediate Certificates . . . . . . . . 8 70 4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 9 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 7.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The Extensible Authentication Protocol (EAP), defined in [RFC3748], 82 provides a standard mechanism for support of multiple authentication 83 methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] 84 [I-D.ietf-emu-eap-tls13] relies on TLS [RFC8446] to provide strong 85 mutual authentication with certificates [RFC5280] and is widely 86 deployed and often used for network access authentication. There are 87 also many other TLS-based EAP methods, such as Flexible 88 Authentication via Secure Tunneling (EAP-FAST) [RFC4851], Tunneled 89 Transport Layer Security (EAP-TTLS) [RFC5281], Tunnel Extensible 90 Authentication Protocol (EAP-TEAP) [RFC7170], and possibly many 91 vendor specific EAP methods. 93 TLS certificates in EAP deployments can be relatively large, and the 94 certificate chains can be long. Unlike the use of TLS on the web, 95 where typically only the TLS server is authenticated; EAP-TLS 96 deployments typically authenticates both the EAP peer and the EAP 97 server. Also, from deployment experience, EAP peers typically have 98 longer certificate chains than servers. This is because EAP peers 99 often follow organizational hierarchies and tend to have many 100 intermediate certificates. Thus, EAP-TLS authentication usually 101 involve significantly more octets than when TLS is used as part of 102 HTTPS. 104 Section 3.1 of [RFC3748] states that EAP implementations can assume a 105 MTU of at least 1020 octets from lower layers. The EAP fragment size 106 in typical deployments is just 1020 - 1500 octets (since the maximum 107 Ethernet frame size is ~ 1500 bytes). Thus, EAP-TLS authentication 108 needs to be fragmented into many smaller packets for transportation 109 over the lower layers. Such fragmentation can not only negatively 110 affect the latency, but also results in other challenges. For 111 example, some EAP authenticator (access point) implementations will 112 drop an EAP session if it has not finished after 40 - 50 round-trips. 113 This is a major problem and means that in many situations, the EAP 114 peer cannot perform network access authentication even though both 115 the sides have valid credentials for successful authentication and 116 key derivation. 118 Not all EAP deployments are constrained by the MTU of the lower 119 layer. For example, some implementations support EAP over Ethernet 120 "Jumbo" frames that can easily allow very large EAP packets. Larger 121 packets will naturally help lower the number of round trips required 122 for successful EAP-TLS authentication. However, deployment 123 experience has shown that these jumbo frames are not always 124 implemented correctly. Additionally, EAP fragment size is also 125 restricted by protocols such as RADIUS [RFC2865] which are 126 responsible for transporting EAP messages between an authenticator 127 and an EAP server. RADIUS can generally transport only about 4000 128 octets of EAP in a single message (the maximum length of RADIUS 129 packet is restricted to 4096 octets in [RFC2865]). 131 This document looks at related work and potential tools available for 132 overcoming the deployment challenges induced by large certificates 133 and long certificate chains. It then discusses the solutions 134 available to overcome these challenges. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 Readers are expected to be familiar with the terms and concepts used 145 in EAP [RFC3748], EAP-TLS [RFC5216], and TLS [RFC8446]. In 146 particular, this document frequently uses the following terms as they 147 have been defined in [RFC5216]: 149 Authenticator The entity initiating EAP authentication. Typically 150 implemented as part of a network switch or a wireless access 151 point. 153 EAP peer The entity that responds to the authenticator. In 154 [IEEE-802.1X], this entity is known as the supplicant. In EAP- 155 TLS, the EAP peer implements the TLS client role. 157 EAP server The entity that terminates the EAP authentication method 158 with the peer. In the case where no backend authentication 159 server is used, the EAP server is part of the authenticator. 160 In the case where the authenticator operates in pass-through 161 mode, the EAP server is located on the backend authentication 162 server. In EAP-TLS, the EAP server implements the TLS server 163 role. 165 The document additionally uses the terms trust anchor and 166 certification path defined in [RFC5280]. 168 3. Experience with Deployments 170 As stated earlier, the EAP fragment size in typical deployments is 171 just 1020 - 1500 octets. Certificate sizes can however be large for 172 a number of reasons: 174 o Long Subject Alternative Name field. 176 o Long Public Key and Signature fields. 178 o Can contain multiple object identifiers (OID) that indicate the 179 permitted uses of the certificate as noted in Section 5.3 of 180 [RFC5216]. Most implementations verify the presence of these OIDs 181 for successful authentication. 183 o Multiple user groups in the certificate. 185 A certificate chain (called a certification path in [RFC5280]) can 186 have 2 - 6 intermediate certificates between the end-entity 187 certificate and the trust anchor. 189 Many access point implementations drop EAP sessions that do not 190 complete within 50 round-trips. This means that if the chain is 191 larger than ~ 60 kB, EAP-TLS authentication cannot complete 192 successfully in most deployments. 194 4. Handling of Large Certificates and Long Certificate Chains 196 This section discusses some possible alternatives for overcoming the 197 challenge of large certificates and long certificate chains in EAP- 198 TLS authentication. In Section 4.1 we look at recommendations that 199 require an update of the certificates or certificate chains that are 200 used for EAP-TLS authentication without requiring changes to the 201 existing EAP-TLS code base. We also provide some guidelines when 202 issuing certificates for use with EAP-TLS. In Section 4.2 we look at 203 recommendations that rely on updates to the EAP-TLS implementations 204 which can be deployed with existing certificates. In Section 4.3 we 205 shortly discuss the solution to update or reconfigure authenticator 206 which can be deployed without changes to existing certificates or 207 EAP-TLS code. 209 4.1. Updating Certificates and Certificate Chains 211 Many IETF protocols now use elliptic curve cryptography (ECC) 212 [RFC6090] for the underlying cryptographic operations. The use of 213 ECC can reduce the size of certificates and signatures. For example, 214 at a 128-bit security level, the size of public keys with traditional 215 RSA is about 384 bytes, while the size of public keys with ECC is 216 only 32-64 bytes. Similarly, the size of digital signatures with 217 traditional RSA is 384 bytes, while the size is only 64 bytes with 218 elliptic curve digital signature algorithm (ECDSA) and Edwards-curve 219 digital signature algorithm (EdDSA) [RFC8032]. Using certificates 220 that use ECC can reduce the number of messages in EAP-TLS 221 authentication which can alleviate the problem of authenticators 222 dropping an EAP session because of too many round-trips. TLS 1.3 223 [RFC8446] requires implementations to support ECC. New cipher suites 224 that use ECC are also specified for TLS 1.2 [RFC5289]. Using ECC 225 based cipher suites with existing code can significantly reduce the 226 number of messages in a single EAP session. 228 4.1.1. Guidelines for certificates 230 This section provides some recommendations for certificates used for 231 EAP-TLS authentication: 233 o Object Identifiers (OIDs) is ASN.1 data type that defines unique 234 identifiers for objects. The OID's ASN.1 value, which is a string 235 of integers, is then used to name objects to which they relate. 236 The DER length for the 1st two integers is always one octet and 237 subsequent integers are base 128-encoded in the fewest possible 238 octets. OIDs are used lavishly in X.509 certificates and while 239 not all can be avoided, e.g., OIDs for extensions or algorithms 240 and their associate parameters, some are well within the 241 certificate issuer's control: 243 * Each naming attribute in a DN (Directory Name) has one. DNs 244 used in the issuer and subject fields as well as numerous 245 extensions. A shallower naming will be smaller, e.g., C=FI, 246 O=Example, SN=B0A123499EFC vs C=FI, O=Example, OU=Division 1, 247 SOPN=Southern Finland, CN=Coolest IoT Gadget Ever, 248 SN=B0A123499EFC. 250 * Every certificate policy (and qualifier) and any mappings to 251 another policy uses identifiers. Consider carefully what 252 policies apply. 254 o DirectoryString and GeneralName types are used extensively to name 255 things, e.g., the DN naming attribute O= (the organizational 256 naming attribute) DirectoryString includes "Example" for the 257 Example organization and uniformResourceIdentifier can be used to 258 indicate the location of the CRL, e.g., "http://crl.example.com/ 259 sfig2s1-128.crl", in the CRL Distribution Point extension. For 260 these particular examples, each character is a byte. For some 261 non-ASCII character strings in the DN, characters can be multi- 262 byte. Obviously, the names need to be unique, but there is more 263 than one way to accomplish this without long strings. This is 264 especially true if the names are not meant to be meaningful to 265 users. 267 o Extensions are necessary to comply with [RFC5280], but the vast 268 majority are optional. Include only those that are necessary to 269 operate. 271 o As stated earlier, certificate chains of the EAP peer often follow 272 organizational hierarchies. In such cases, information in 273 intermediate certificates (such as postal addresses) do not 274 provide any additional value and they can be shortened (for 275 example: only including the department name instead of the full 276 postal address). 278 4.2. Updating TLS and EAP-TLS Code 280 4.2.1. Pre-distributing and Omitting CA Certificates 282 The TLS Certificate message conveys the sending endpoint's 283 certificate chain. TLS allows endpoints to reduce the size of the 284 Certificate message by omitting certificates that the other endpoint 285 is known to possess. When using TLS 1.3, all certificates that 286 specify a trust anchor known by the other endpoint may be omitted 287 (see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or earlier, 288 only the self-signed certificate that specifies the root certificate 289 authority may be omitted (see Section 7.4.2 of [RFC5246] Therefore, 290 updating TLS implementations to version 1.3 can help to significantly 291 reduce the number of messages exchanged for EAP-TLS authentication. 292 The omitted certificates need to be pre-distributed independently of 293 TLS and the TLS implementations need to be configured to omit these 294 pre-distributed certificates. 296 4.2.2. URLs for Client Certificates 298 [RFC6066] defines the "client_certificate_url" extension which allows 299 TLS clients to send a sequence of Uniform Resource Locators (URLs) 300 instead of the client certificate. URLs can refer to a single 301 certificate or a certificate chain. Using this extension can curtail 302 the amount of fragmentation in EAP deployments thereby allowing EAP 303 sessions to successfully complete. 305 4.2.3. Compact TLS 1.3 307 [I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and 308 reduces the message size of the protocol by removing obsolete 309 material and using more efficient encoding. This naturally means 310 that cTLS is not interoperable with previous versions of the TLS 311 protocol. It also defines a compression profile with which either 312 side can define dictionary of "known certificates". Thus, cTLS can 313 provide another mechanism for EAP-TLS deployments to reduce the size 314 of messages and avoid excessive fragmentation. 316 4.2.4. Caching Certificates 318 The TLS Cached Information Extension [RFC7924] specifies an extension 319 where a server can exclude transmission of certificate information 320 cached in an earlier TLS handshake. The client and the server would 321 first execute the full TLS handshake. The client would then cache 322 the certificate provided by the server. When the TLS client later 323 connects to the same TLS server without using session resumption, it 324 can attach the "cached_info" extension to the ClientHello message. 325 This would allow the client to indicate that it has cached the 326 certificate. The client would also include a fingerprint of the 327 server certificate chain. If the server's certificate has not 328 changed, then the server does not need to send its certificate and 329 the corresponding certificate chain again. In case information has 330 changed, which can be seen from the fingerprint provided by the 331 client, the certificate payload is transmitted to the client to allow 332 the client to update the cache. The extension however necessitates a 333 successful full handshake before any caching. This extension can be 334 useful when, for example, when a successful authentication between an 335 EAP peer and EAP server has occurred in the home network. If 336 authenticators in a roaming network are more strict at dropping long 337 EAP sessions, an EAP peer can use the Cached Information Extension to 338 reduce the total number of messages. 340 However, if all authenticators drop the EAP session for a given EAP 341 peer and EAP server combination, a successful full handshake is not 342 possible. An option in such a scenario would be to cache validated 343 certificate chains even if the EAP-TLS exchange fails, but this is 344 currently not allowed according to [RFC7924]. 346 4.2.5. Compressing Certificates 348 The TLS working group is also working on an extension for TLS 1.3 349 [I-D.ietf-tls-certificate-compression] that allows compression of 350 certificates and certificate chains during full handshakes. The 351 client can indicate support for compressed server certificates by 352 including this extension in the ClientHello message. Similarly, the 353 server can indicate support for compression of client certificates by 354 including this extension in the CertificateRequest message. While 355 such an extension can alleviate the problem of excessive 356 fragmentation in EAP-TLS, it can only be used with TLS version 1.3 357 and higher. Deployments that rely on older versions of TLS cannot 358 benefit from this extension. 360 4.2.6. Suppressing Intermediate Certificates 362 For a client that has all intermediates, having the server send 363 intermediates in the TLS handshake increases the size of the 364 handshake unnecessarily. The TLS working group is working on an 365 extension for TLS 1.3 [I-D.thomson-tls-sic] that allows a TLS client 366 that has access to the complete set of published intermediate 367 certificates to inform servers of this fact so that the server can 368 avoid sending intermediates, reducing the size of the TLS handshake. 369 The mechanism is intended to be complementary with certificate 370 compression. 372 4.2.7. Using Fewer Intermediate Certificates 374 The EAP peer certificate chain does not have to mirror the 375 organizational hierarchy. For successful EAP-TLS authentication, 376 certificate chains should not contain more than 2-4 intermediate 377 certificates. 379 Administrators responsible for deployments using TLS-based EAP 380 methods can examine the certificate chains and make rough 381 calculations about the number of round trips required for successful 382 authentication. For example, dividing the total size of all the 383 certificates in the peer and server certificate chain by 1020 will 384 indicate the minimum number of round trips required. If this number 385 exceeds 50, then, administrators can expect failures with many common 386 authenticator implementations. 388 4.3. Updating Authenticators 390 There are several legitimate reasons that authenticators may want to 391 limit the number of round-trips/packets/octets that can be sent. The 392 main reason has been to work around issues where the EAP peer and EAP 393 server end up in an infinite loop ACKing their messages. Another 394 second reason is that unlimited communication from an unauthenticated 395 device as EAP could otherwise be use for bulk data transfer. A third 396 reason is to prevent denial-of-service attacks. 398 Updating the millions of already deployed access points and switches 399 is in many cases not realistic. Vendors may be out of business or do 400 no longer support the products and administrators may have lost the 401 login information to the devices. For practical purposes the EAP 402 infrastructure is ossified for the time being. 404 Vendors making new authenticators should consider increasing the 405 number of round-trips allowed to 100 before denying the EAP 406 authentication to complete. At the same time, administrators 407 responsible for EAP deployments should ensure that this 100 roundtrip 408 limit is not exceeded in practice. 410 5. IANA Considerations 412 This document includes no request to IANA. 414 6. Security Considerations 416 Updating implementations to TLS version 1.3 allows omitting all 417 certificates with a trust anchor known by the other endpoint. TLS 418 1.3 additionally provides improved security, privacy, and reduced 419 latency for EAP-TLS [I-D.ietf-emu-eap-tls13]. 421 When compressing certificates, the underlying compression algorithm 422 MUST output the same data that was provided as input by. After 423 decompression, the Certificate message MUST be processed as if it 424 were encoded without being compressed. Additional security 425 considerations when compressing certificates are specified in 426 [I-D.ietf-tls-certificate-compression] 428 As noted in [I-D.thomson-tls-sic], suppressing intermediate 429 certificates creates an unencrypted signal that might be used to 430 identify which clients believe that they have all intermediates. 432 This might also allow more effective fingerprinting and tracking of 433 clients. 435 7. References 437 7.1. Normative References 439 [I-D.ietf-emu-eap-tls13] 440 Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3", 441 draft-ietf-emu-eap-tls13-09 (work in progress), March 442 2020. 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, 446 DOI 10.17487/RFC2119, March 1997, 447 . 449 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 450 Levkowetz, Ed., "Extensible Authentication Protocol 451 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 452 . 454 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 455 Flexible Authentication via Secure Tunneling Extensible 456 Authentication Protocol Method (EAP-FAST)", RFC 4851, 457 DOI 10.17487/RFC4851, May 2007, 458 . 460 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 461 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 462 March 2008, . 464 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 465 Housley, R., and W. Polk, "Internet X.509 Public Key 466 Infrastructure Certificate and Certificate Revocation List 467 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 468 . 470 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 471 Protocol Tunneled Transport Layer Security Authenticated 472 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 473 DOI 10.17487/RFC5281, August 2008, 474 . 476 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 477 "Tunnel Extensible Authentication Protocol (TEAP) Version 478 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 479 . 481 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 482 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 483 May 2017, . 485 7.2. Informative References 487 [I-D.ietf-tls-certificate-compression] 488 Ghedini, A. and V. Vasiliev, "TLS Certificate 489 Compression", draft-ietf-tls-certificate-compression-10 490 (work in progress), January 2020. 492 [I-D.ietf-tls-ctls] 493 Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 494 1.3", draft-ietf-tls-ctls-00 (work in progress), April 495 2020. 497 [I-D.thomson-tls-sic] 498 Thomson, M., "Suppressing Intermediate Certificates in 499 TLS", draft-thomson-tls-sic-00 (work in progress), March 500 2019. 502 [IEEE-802.1X] 503 Institute of Electrical and Electronics Engineers, "IEEE 504 Standard for Local and metropolitan area networks -- Port- 505 Based Network Access Control", IEEE Standard 802.1X-2010 , 506 February 2010. 508 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 509 "Remote Authentication Dial In User Service (RADIUS)", 510 RFC 2865, DOI 10.17487/RFC2865, June 2000, 511 . 513 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 514 (TLS) Protocol Version 1.2", RFC 5246, 515 DOI 10.17487/RFC5246, August 2008, 516 . 518 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 519 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 520 DOI 10.17487/RFC5289, August 2008, 521 . 523 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 524 Extensions: Extension Definitions", RFC 6066, 525 DOI 10.17487/RFC6066, January 2011, 526 . 528 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 529 Curve Cryptography Algorithms", RFC 6090, 530 DOI 10.17487/RFC6090, February 2011, 531 . 533 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 534 (TLS) Cached Information Extension", RFC 7924, 535 DOI 10.17487/RFC7924, July 2016, 536 . 538 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 539 Signature Algorithm (EdDSA)", RFC 8032, 540 DOI 10.17487/RFC8032, January 2017, 541 . 543 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 544 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 545 . 547 Acknowledgements 549 This draft is a result of several useful discussions with Alan DeKok, 550 Bernard Aboba, Jari Arkko, Jouni Malinen, Darshak Thakore, and Hannes 551 Tschofening. 553 Authors' Addresses 555 Mohit Sethi 556 Ericsson 557 Jorvas 02420 558 Finland 560 Email: mohit@piuha.net 562 John Mattsson 563 Ericsson 564 Kista 565 Sweden 567 Email: john.mattsson@ericsson.com 569 Sean Turner 570 sn3rd 572 Email: sean@sn3rd.com