idnits 2.17.1 draft-ms-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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (October 22, 2018) is 2007 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-tls-certificate-compression-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: April 25, 2019 October 22, 2018 7 Handling Large Certificates and Long Certificate Chains in EAP-TLS 8 draft-ms-emu-eaptlscert-01 10 Abstract 12 Extensible Authentication Protocol (EAP) provides support for 13 multiple authentication methods. EAP-Transport Layer Security (EAP- 14 TLS) provides means for key derivation and strong mutual 15 authentication with certificates. However, certificates can often be 16 relatively large in size. The certificate chain to the root-of-trust 17 can also be long when multiple intermediate Certification Authorities 18 (CAs) are involved. This implies that EAP-TLS authentication needs 19 to be fragmented into many smaller packets for transportation over 20 the lower-layer. Such fragmentation can not only negatively affect 21 the latency, but also results in implementation challenges. For 22 example, many authenticator (access point) implementations will drop 23 an EAP session if it hasn't finished after 40 - 50 packets. This can 24 result in failed authentication even when the two communicating 25 parties have the correct credentials for mutual authentication. 26 Moreover, there are no mechanisms available to easily recover from 27 such situations. This memo looks at the problem in detail and 28 discusses the solutions available to overcome these deployment 29 challenges. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 25, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Experience with Deployments . . . . . . . . . . . . . . . . . 3 68 4. Handling of Large Certificates and Long Certificate Chains . 4 69 4.1. Updating Certificates . . . . . . . . . . . . . . . . . . 4 70 4.2. Updating Code . . . . . . . . . . . . . . . . . . . . . . 5 71 4.3. Guidelines for certificates . . . . . . . . . . . . . . . 6 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 7.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 EAP-TLS is widely deployed and often used for network access 83 authentication of requesting peers. EAP-TLS provides strong mutual 84 authentication with certificates. However, certificates can be large 85 and certificate chains can often be long. This implies that EAP-TLS 86 authentication needs to be fragmented into many smaller packets for 87 transportation over the lower-layer. Such fragmentation can not only 88 negatively affect the latency, but also results in implementation 89 challenges. For example, many authenticator (access point) 90 implementations will drop an EAP session if it hasn't finished after 91 40-50 packets. This has led to a situation where a client and server 92 cannot authenticate each other even though both the sides have valid 93 credentials for successful authentication and key derivation. 95 Unlike TLS authentication on the web, where typically only the server 96 is authenticated with certificates; in EAP-TLS both the client and 97 server are authenticated with certificates. Therefore, EAP-TLS 98 authentication involves exchange of larger number of messages than 99 regular TLS authentication on the web. Also, from deployment 100 experience, the end-entity certificate for clients typically has a 101 longer certificate chain to the root-of-trust than the end-entity 102 certificate for the server. 104 This memo looks at related work and potential tools available for 105 overcoming the implementation challenges induced by large 106 certificates and long certificate chains. It then discusses the 107 solutions available to overcome these deployment challenges. The 108 draft is an early version and aims to foster discussion in the 109 working group. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in RFC 116 8174 [RFC8174]. 118 In addition, this document frequently uses the following terms as 119 they have been defined in [RFC5216]: 121 authenticator The entity initiating EAP authentication. 123 peer The entity that responds to the authenticator. In 124 [IEEE-802.1X], this entity is known as the supplicant. 126 server The entity that terminates the EAP authentication method with 127 the peer. In the case where no backend authentication server 128 is used, the EAP server is part of the authenticator. In the 129 case where the authenticator operates in pass-through mode, the 130 EAP server is located on the backend authentication server. 132 3. Experience with Deployments 134 The EAP fragment size in typical deployments can be 1000 - 1500 135 bytes. Certificate sizes can be large for a number of reasons: 137 o Long Subject Alternative Name field. 139 o Long Public Key and Signature fields. 141 o Can contain multiple object identifiers (OID) that indicate the 142 permitted uses of the certificate. For example, Windows requires 143 certain OID's in the certificates for EAP-TLS to work. 145 o Multiple user groups in the certificate. 147 The certificate chain can typically include 2 - 6 certificates to the 148 root-of-trust. 150 Most common access point implementations drop EAP sessions that don't 151 complete within 50 round trips. This means that if the chain is 152 larger than ~ 60 kB, EAP-TLS authentication cannot complete 153 successfully in most deployments. 155 4. Handling of Large Certificates and Long Certificate Chains 157 This section discusses some possible alternatives for overcoming the 158 challenge of large certificates and long certificate chains in EAP- 159 TLS authentication. In Section 4.1 we look at recommendations that 160 require an update of the certificates that are used for EAP-TLS 161 authentication without requiring changes to the existing code base. 162 In Section 4.2 we look at recommendations that rely on updates to the 163 EAP-TLS implementations which can be deployed with existing 164 certificates. Finally, in Section 4.3, we provide some guidelines 165 when issuing certificates for use with EAP-TLS. 167 4.1. Updating Certificates 169 Many IETF protocols now use elliptic curve cryptography (ECC) 170 [RFC6090] for the underlying cryptographic operations. The use of 171 ECC can reduce the size of certificates and signatures. For example, 172 the size of public keys with traditional RSA is about 384 bytes, 173 while the size of public keys with ECC is only 32 bytes. Similarly, 174 the size of digital signatures with traditional RSA is 384 bytes, 175 while the size is only 64 bytes with elliptic curve digital signature 176 algorithm (ECDSA) and Edwards-curve digital signature algorithm 177 (EdDSA) [RFC8032]. Using certificates that use ECC can reduce the 178 number of messages in EAP-TLS authentication which can alleviate the 179 problem of authenticators dropping an EAP session because of too many 180 packets. TLS 1.3 [RFC8446] requires implementations to support ECC. 181 New cipher suites that use ECC are also specified for TLS 1.2 182 [RFC5289]. Using ECC based cipher suites with existing code can 183 significantly reduce the number of messages in a single EAP session. 185 4.2. Updating Code 187 TLS allows endpoints to reduce the sizes of Certificate messages by 188 omitting certificates that the other endpoint is known to possess. 189 When using TLS 1.3, all certificates that specify a trust anchor 190 known by the other endpoint may be omitted. When using TLS 1.2 or 191 earlier, only the self-signed certificate that specifies the root 192 certificate authority may be omitted. Therefore, updating TLS 193 implementations to version 1.3 can help to significantly reduce the 194 number of messages exchanged for EAP-TLS authentication. 196 The TLS Cached Information Extension [RFC7924] specifies an extension 197 where a server can exclude transmission of certificate information 198 cached in an earlier TLS handshake. The client and the server would 199 first execute the full TLS handshake. The client would then cache 200 the certificate provided by the server. When the TLS client later 201 connects to the same TLS server without using session resumption, it 202 can attach the "cached_info" extension to the ClientHello message. 203 This would allow the client to indicate that it has cached the 204 certificate. The client would also include a fingerprint of the 205 server certificate chain. If the server's certificate has not 206 changed, then the server does not need to send its certificate and 207 the corresponding certificate chain again. In case information has 208 changed, which can be seen from the fingerprint provided by the 209 client, the certificate payload is transmitted to the client to allow 210 the client to update the cache. The extension however necessitates a 211 successful full handshake before any caching. This extension can be 212 useful when, for example, when a successful authentication between an 213 EAP peer and EAP server has occurred in the home network. If 214 authenticators in a roaming network are more strict at dropping long 215 EAP sessions, an EAP peer can use the Cached Information Extension to 216 reduce the total number of messages. 218 However, if all authenticators drop the EAP session for a given EAP 219 peer and EAP server combination, a successful full handshake is not 220 possible. An option in such a scenario would be to cache validated 221 certificate chains even if the EAP-TLS exchange fails, but this is 222 currently not allowed according to [RFC7924]. 224 The TLS working group is also working on an extension for TLS 1.3 225 [I-D.ietf-tls-certificate-compression] that allows compression of 226 certificates and certificate chains during full handshakes. The 227 client can indicate support for compressed server certificates by 228 including this extension in the ClientHello message. Similarly, the 229 server can indicate support for compression of client certificates by 230 including this extension in the CertificateRequest message. While 231 such an extension can alleviate the problem of excessive 232 fragmentation in EAP-TLS, it can only be used with TLS version 1.3 233 and higher. Deployments that rely on older versions of TLS cannot 234 benefit from this extension. 236 4.3. Guidelines for certificates 238 This section provides some recommendations for certificates used for 239 EAP-TLS authentication. Unlike TLS authentication on the web, EAP- 240 TLS messages are often carried over the link-layer 242 o Reasonable number of OIDs 244 o ... 246 5. IANA Considerations 248 This memo includes no request to IANA. 250 6. Security Considerations 252 TBD 254 7. References 256 7.1. Normative References 258 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 259 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 260 March 2008, . 262 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 263 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 264 May 2017, . 266 7.2. Informative References 268 [I-D.ietf-tls-certificate-compression] 269 Ghedini, A. and V. Vasiliev, "TLS Certificate 270 Compression", draft-ietf-tls-certificate-compression-04 271 (work in progress), October 2018. 273 [IEEE-802.1X] 274 Institute of Electrical and Electronics Engineers, "Local 275 and Metropolitan Area Networks: Port-Based Network Access 276 Control", IEEE Standard 802.1X-2004. , December 2004. 278 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 279 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 280 DOI 10.17487/RFC5289, August 2008, 281 . 283 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 284 Curve Cryptography Algorithms", RFC 6090, 285 DOI 10.17487/RFC6090, February 2011, 286 . 288 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 289 (TLS) Cached Information Extension", RFC 7924, 290 DOI 10.17487/RFC7924, July 2016, 291 . 293 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 294 Signature Algorithm (EdDSA)", RFC 8032, 295 DOI 10.17487/RFC8032, January 2017, 296 . 298 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 299 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 300 . 302 Acknowledgements 304 This draft is a result of several useful discussions with Alan DeKok, 305 Bernard Aboba, Jari Arkko, Darshak Thakore and Hannes Tschofening. 307 Authors' Addresses 309 Mohit Sethi 310 Ericsson 311 Jorvas 02420 312 Finland 314 Email: mohit@piuha.net 316 John Mattsson 317 Ericsson 318 Kista 319 Sweden 321 Email: john.mattsson@ericsson.com