< draft-ietf-emu-eaptlscert-04.txt   draft-ietf-emu-eaptlscert-05.txt >
Network Working Group M. Sethi Network Working Group M. Sethi
Internet-Draft J. Mattsson Internet-Draft J. Mattsson
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: December 10, 2020 S. Turner Expires: December 17, 2020 S. Turner
sn3rd sn3rd
June 8, 2020 June 15, 2020
Handling Large Certificates and Long Certificate Chains Handling Large Certificates and Long Certificate Chains
in TLS-based EAP Methods in TLS-based EAP Methods
draft-ietf-emu-eaptlscert-04 draft-ietf-emu-eaptlscert-05
Abstract Abstract
EAP-TLS and other TLS-based EAP methods are widely deployed and used EAP-TLS and other TLS-based EAP methods are widely deployed and used
for network access authentication. Large certificates and long for network access authentication. Large certificates and long
certificate chains combined with authenticators that drop an EAP certificate chains combined with authenticators that drop an EAP
session after only 40 - 50 round-trips is a major deployment problem. session after only 40 - 50 round-trips is a major deployment problem.
This document looks at the this problem in detail and describes the This document looks at the this problem in detail and describes the
potential solutions available. potential solutions available.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 10, 2020. This Internet-Draft will expire on December 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Experience with Deployments . . . . . . . . . . . . . . . . . 4 3. Experience with Deployments . . . . . . . . . . . . . . . . . 4
4. Handling of Large Certificates and Long Certificate Chains . 5 4. Handling of Large Certificates and Long Certificate Chains . 5
4.1. Updating Certificates and Certificate Chains . . . . . . 5 4.1. Updating Certificates and Certificate Chains . . . . . . 5
4.1.1. Guidelines for Certificates . . . . . . . . . . . . . 5 4.1.1. Guidelines for Certificates . . . . . . . . . . . . . 5
4.1.2. New Certificate Types and Compression Algorithms . . 6 4.1.2. Pre-distributing and Omitting CA certificates . . . . 6
4.1.3. Using Fewer Intermediate Certificates . . . . . . . . 7
4.2. Updating TLS and EAP-TLS Code . . . . . . . . . . . . . . 7 4.2. Updating TLS and EAP-TLS Code . . . . . . . . . . . . . . 7
4.2.1. Pre-distributing and Omitting CA certificates . . . . 7 4.2.1. URLs for Client Certificates . . . . . . . . . . . . 7
4.2.2. URLs for Client Certificates . . . . . . . . . . . . 7 4.2.2. Caching Certificates . . . . . . . . . . . . . . . . 7
4.2.3. Compact TLS 1.3 . . . . . . . . . . . . . . . . . . . 7 4.2.3. Compressing Certificates . . . . . . . . . . . . . . 8
4.2.4. Caching Certificates . . . . . . . . . . . . . . . . 8 4.2.4. Compact TLS 1.3 . . . . . . . . . . . . . . . . . . . 8
4.2.5. Compressing Certificates . . . . . . . . . . . . . . 8 4.2.5. Suppressing Intermediate Certificates . . . . . . . . 9
4.2.6. Suppressing Intermediate Certificates . . . . . . . . 9 4.2.6. Raw Public Keys . . . . . . . . . . . . . . . . . . . 9
4.2.7. Using Fewer Intermediate Certificates . . . . . . . . 9 4.2.7. New Certificate Types and Compression Algorithms . . 9
4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 9 4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
skipping to change at page 5, line 35 skipping to change at page 5, line 35
[RFC6090] for the underlying cryptographic operations. The use of [RFC6090] for the underlying cryptographic operations. The use of
ECC can reduce the size of certificates and signatures. For example, ECC can reduce the size of certificates and signatures. For example,
at a 128-bit security level, the size of public keys with traditional at a 128-bit security level, the size of public keys with traditional
RSA is about 384 bytes, while the size of public keys with ECC is RSA is about 384 bytes, while the size of public keys with ECC is
only 32-64 bytes. Similarly, the size of digital signatures with only 32-64 bytes. Similarly, the size of digital signatures with
traditional RSA is 384 bytes, while the size is only 64 bytes with traditional RSA is 384 bytes, while the size is only 64 bytes with
elliptic curve digital signature algorithm (ECDSA) and Edwards-curve elliptic curve digital signature algorithm (ECDSA) and Edwards-curve
digital signature algorithm (EdDSA) [RFC8032]. Using certificates digital signature algorithm (EdDSA) [RFC8032]. Using certificates
that use ECC can reduce the number of messages in EAP-TLS that use ECC can reduce the number of messages in EAP-TLS
authentication which can alleviate the problem of authenticators authentication which can alleviate the problem of authenticators
dropping an EAP session because of too many round-trips. TLS 1.3 dropping an EAP session because of too many round-trips. In the
[RFC8446] requires implementations to support ECC. New cipher suites absence of a standard application profile specifying otherwise, TLS
that use ECC are also specified for TLS 1.2 [RFC5289]. Using ECC 1.3 [RFC8446] requires implementations to support ECC. New cipher
based cipher suites with existing code can significantly reduce the suites that use ECC are also specified for TLS 1.2 [RFC5289]. Using
number of messages in a single EAP session. ECC based cipher suites with existing code can significantly reduce
the number of messages in a single EAP session.
4.1.1. Guidelines for Certificates 4.1.1. Guidelines for Certificates
The general guideline of keeping the certificate size small by not The general guideline of keeping the certificate size small by not
populating fields with excessive information can help avert the populating fields with excessive information can help avert the
problems of failed EAP-TLS authentication. More specific problems of failed EAP-TLS authentication. More specific
recommendations for certificates used with EAP-TLS is as follows: recommendations for certificates used with EAP-TLS is as follows:
o Object Identifiers (OIDs) is ASN.1 data type that defines unique o Object Identifiers (OIDs) is ASN.1 data type that defines unique
identifiers for objects. The OID's ASN.1 value, which is a string identifiers for objects. The OID's ASN.1 value, which is a string
skipping to change at page 6, line 45 skipping to change at page 6, line 47
majority are optional. Include only those that are necessary to majority are optional. Include only those that are necessary to
operate. operate.
o As stated earlier, certificate chains of the EAP peer often follow o As stated earlier, certificate chains of the EAP peer often follow
organizational hierarchies. In such cases, information in organizational hierarchies. In such cases, information in
intermediate certificates (such as postal addresses) do not intermediate certificates (such as postal addresses) do not
provide any additional value and they can be shortened (for provide any additional value and they can be shortened (for
example: only including the department name instead of the full example: only including the department name instead of the full
postal address). postal address).
4.1.2. New Certificate Types and Compression Algorithms 4.1.2. Pre-distributing and Omitting CA certificates
There is ongoing work to specify new certificate types and
compression algorithms. For example,
[I-D.mattsson-tls-cbor-cert-compress] defines a compression algorithm
for certificates that relies on Concise Binary Object Representation
(CBOR) [RFC7049]. [I-D.tschofenig-tls-cwt] registers a new TLS
Certificate type which would enable TLS implementations to use CBOR
Web Tokens (CWTs) [RFC8392] as certificates. While these are early
initiatives, future EAP-TLS deployments can consider the use of these
new certificate types and compression algorithms to avoid large
message sizes.
4.2. Updating TLS and EAP-TLS Code
4.2.1. Pre-distributing and Omitting CA certificates
The TLS Certificate message conveys the sending endpoint's The TLS Certificate message conveys the sending endpoint's
certificate chain. TLS allows endpoints to reduce the size of the certificate chain. TLS allows endpoints to reduce the size of the
Certificate message by omitting certificates that the other endpoint Certificate message by omitting certificates that the other endpoint
is known to possess. When using TLS 1.3, all certificates that is known to possess. When using TLS 1.3, all certificates that
specify a trust anchor known by the other endpoint may be omitted specify a trust anchor known by the other endpoint may be omitted
(see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or earlier, (see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or earlier,
only the self-signed certificate that specifies the root certificate only the self-signed certificate that specifies the root certificate
authority may be omitted (see Section 7.4.2 of [RFC5246] Therefore, authority may be omitted (see Section 7.4.2 of [RFC5246] Therefore,
updating TLS implementations to version 1.3 can help to significantly updating TLS implementations to version 1.3 can help to significantly
reduce the number of messages exchanged for EAP-TLS authentication. reduce the number of messages exchanged for EAP-TLS authentication.
The omitted certificates need to be pre-distributed independently of The omitted certificates need to be pre-distributed independently of
TLS and the TLS implementations need to be configured to omit these TLS and the TLS implementations need to be configured to omit these
pre-distributed certificates. pre-distributed certificates.
4.2.2. URLs for Client Certificates 4.1.3. Using Fewer Intermediate Certificates
The EAP peer certificate chain does not have to mirror the
organizational hierarchy. For successful EAP-TLS authentication,
certificate chains SHOULD NOT contain more than 2-4 intermediate
certificates.
Administrators responsible for deployments using TLS-based EAP
methods can examine the certificate chains and make rough
calculations about the number of round trips required for successful
authentication. For example, dividing the total size of all the
certificates in the peer and server certificate chain by 1020 will
indicate the minimum number of round trips required. If this number
exceeds 50, then, administrators can expect failures with many common
authenticator implementations.
4.2. Updating TLS and EAP-TLS Code
This section discusses how the fragmentation problem can be avoided
by updating the underlying TLS or EAP-TLS implementation. Note that
in many cases the new feature may already be implemented in the
underlying library and simply needs to be taken into use.
4.2.1. URLs for Client Certificates
[RFC6066] defines the "client_certificate_url" extension which allows [RFC6066] defines the "client_certificate_url" extension which allows
TLS clients to send a sequence of Uniform Resource Locators (URLs) TLS clients to send a sequence of Uniform Resource Locators (URLs)
instead of the client certificate. URLs can refer to a single instead of the client certificate. URLs can refer to a single
certificate or a certificate chain. Using this extension can curtail certificate or a certificate chain. Using this extension can curtail
the amount of fragmentation in EAP deployments thereby allowing EAP the amount of fragmentation in EAP deployments thereby allowing EAP
sessions to successfully complete. sessions to successfully complete.
4.2.3. Compact TLS 1.3 4.2.2. Caching Certificates
[I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and
reduces the message size of the protocol by removing obsolete
material and using more efficient encoding. This naturally means
that cTLS is not interoperable with previous versions of the TLS
protocol. It also defines a compression profile with which either
side can define dictionary of "known certificates". Thus, cTLS can
provide another mechanism for EAP-TLS deployments to reduce the size
of messages and avoid excessive fragmentation.
4.2.4. Caching Certificates
The TLS Cached Information Extension [RFC7924] specifies an extension The TLS Cached Information Extension [RFC7924] specifies an extension
where a server can exclude transmission of certificate information where a server can exclude transmission of certificate information
cached in an earlier TLS handshake. The client and the server would cached in an earlier TLS handshake. The client and the server would
first execute the full TLS handshake. The client would then cache first execute the full TLS handshake. The client would then cache
the certificate provided by the server. When the TLS client later the certificate provided by the server. When the TLS client later
connects to the same TLS server without using session resumption, it connects to the same TLS server without using session resumption, it
can attach the "cached_info" extension to the ClientHello message. can attach the "cached_info" extension to the ClientHello message.
This would allow the client to indicate that it has cached the This would allow the client to indicate that it has cached the
certificate. The client would also include a fingerprint of the certificate. The client would also include a fingerprint of the
skipping to change at page 8, line 35 skipping to change at page 8, line 28
authenticators in a roaming network are more strict at dropping long authenticators in a roaming network are more strict at dropping long
EAP sessions, an EAP peer can use the Cached Information Extension to EAP sessions, an EAP peer can use the Cached Information Extension to
reduce the total number of messages. reduce the total number of messages.
However, if all authenticators drop the EAP session for a given EAP However, if all authenticators drop the EAP session for a given EAP
peer and EAP server combination, a successful full handshake is not peer and EAP server combination, a successful full handshake is not
possible. An option in such a scenario would be to cache validated possible. An option in such a scenario would be to cache validated
certificate chains even if the EAP-TLS exchange fails, but this is certificate chains even if the EAP-TLS exchange fails, but this is
currently not allowed according to [RFC7924]. currently not allowed according to [RFC7924].
4.2.5. Compressing Certificates 4.2.3. Compressing Certificates
The TLS working group is also working on an extension for TLS 1.3 The TLS working group is also working on an extension for TLS 1.3
[I-D.ietf-tls-certificate-compression] that allows compression of [I-D.ietf-tls-certificate-compression] that allows compression of
certificates and certificate chains during full handshakes. The certificates and certificate chains during full handshakes. The
client can indicate support for compressed server certificates by client can indicate support for compressed server certificates by
including this extension in the ClientHello message. Similarly, the including this extension in the ClientHello message. Similarly, the
server can indicate support for compression of client certificates by server can indicate support for compression of client certificates by
including this extension in the CertificateRequest message. While including this extension in the CertificateRequest message. While
such an extension can alleviate the problem of excessive such an extension can alleviate the problem of excessive
fragmentation in EAP-TLS, it can only be used with TLS version 1.3 fragmentation in EAP-TLS, it can only be used with TLS version 1.3
and higher. Deployments that rely on older versions of TLS cannot and higher. Deployments that rely on older versions of TLS cannot
benefit from this extension. benefit from this extension.
4.2.6. Suppressing Intermediate Certificates 4.2.4. Compact TLS 1.3
[I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and
reduces the message size of the protocol by removing obsolete
material and using more efficient encoding. It also defines a
compression profile with which either side can define dictionary of
"known certificates". Thus, cTLS can provide another mechanism for
EAP-TLS deployments to reduce the size of messages and avoid
excessive fragmentation.
4.2.5. Suppressing Intermediate Certificates
For a client that has all intermediates, having the server send For a client that has all intermediates, having the server send
intermediates in the TLS handshake increases the size of the intermediates in the TLS handshake increases the size of the
handshake unnecessarily. The TLS working group is working on an handshake unnecessarily. The TLS working group is working on an
extension for TLS 1.3 [I-D.thomson-tls-sic] that allows a TLS client extension for TLS 1.3 [I-D.thomson-tls-sic] that allows a TLS client
that has access to the complete set of published intermediate that has access to the complete set of published intermediate
certificates to inform servers of this fact so that the server can certificates to inform servers of this fact so that the server can
avoid sending intermediates, reducing the size of the TLS handshake. avoid sending intermediates, reducing the size of the TLS handshake.
The mechanism is intended to be complementary with certificate The mechanism is intended to be complementary with certificate
compression. compression.
4.2.7. Using Fewer Intermediate Certificates 4.2.6. Raw Public Keys
The EAP peer certificate chain does not have to mirror the [RFC7250] defines a new certificate type and TLS extensions to enable
organizational hierarchy. For successful EAP-TLS authentication, the use of raw public keys for authentication. Raw public keys use
certificate chains SHOULD NOT contain more than 2-4 intermediate only a subset of information found in typical certificates and are
certificates. therefore much smaller in size. However, raw public keys require an
out-of-band mechanism to bind the public key with the entity
presenting the key. Using raw public keys will obviously avoid the
fragmentation problems resulting from large certificates and long
certificate chains. Deployments can consider their use as long as an
appropriate out-of-band mechanism for binding public keys with
identifiers is in place.
Administrators responsible for deployments using TLS-based EAP 4.2.7. New Certificate Types and Compression Algorithms
methods can examine the certificate chains and make rough
calculations about the number of round trips required for successful There is ongoing work to specify new certificate types and
authentication. For example, dividing the total size of all the compression algorithms. For example,
certificates in the peer and server certificate chain by 1020 will [I-D.mattsson-tls-cbor-cert-compress] defines a compression algorithm
indicate the minimum number of round trips required. If this number for certificates that relies on Concise Binary Object Representation
exceeds 50, then, administrators can expect failures with many common (CBOR) [RFC7049]. [I-D.tschofenig-tls-cwt] registers a new TLS
authenticator implementations. Certificate type which would enable TLS implementations to use CBOR
Web Tokens (CWTs) [RFC8392] as certificates. While these are early
initiatives, future EAP-TLS deployments can consider the use of these
new certificate types and compression algorithms to avoid large
message sizes.
4.3. Updating Authenticators 4.3. Updating Authenticators
There are several legitimate reasons that authenticators may want to There are several legitimate reasons that authenticators may want to
limit the number of round-trips/packets/octets that can be sent. The limit the number of round-trips/packets/octets that can be sent. The
main reason has been to work around issues where the EAP peer and EAP main reason has been to work around issues where the EAP peer and EAP
server end up in an infinite loop ACKing their messages. Another server end up in an infinite loop ACKing their messages. Another
second reason is that unlimited communication from an unauthenticated second reason is that unlimited communication from an unauthenticated
device as EAP could otherwise be use for bulk data transfer. A third device as EAP could otherwise be use for bulk data transfer. A third
reason is to prevent denial-of-service attacks. reason is to prevent denial-of-service attacks.
skipping to change at page 13, line 5 skipping to change at page 13, line 9
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011, DOI 10.17487/RFC6090, February 2011,
<https://www.rfc-editor.org/info/rfc6090>. <https://www.rfc-editor.org/info/rfc6090>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924, (TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016, DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/info/rfc7924>. <https://www.rfc-editor.org/info/rfc7924>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
 End of changes. 16 change blocks. 
61 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/