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