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