< draft-ietf-emu-eaptlscert-05.txt   draft-ietf-emu-eaptlscert-06.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 17, 2020 S. Turner Expires: May 1, 2021 S. Turner
sn3rd sn3rd
June 15, 2020 October 28, 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-05 draft-ietf-emu-eaptlscert-06
Abstract Abstract
EAP-TLS and other TLS-based EAP methods are widely deployed and used The Extensible Authentication Protocol (EAP), defined in RFC3748,
for network access authentication. Large certificates and long provides a standard mechanism for support of multiple authentication
certificate chains combined with authenticators that drop an EAP methods. EAP-Transport Layer Security (EAP-TLS) and other TLS-based
session after only 40 - 50 round-trips is a major deployment problem. EAP methods are widely deployed and used for network access
This document looks at the this problem in detail and describes the authentication. Large certificates and long certificate chains
potential solutions available. combined with authenticators that drop an EAP session after only 40 -
50 round-trips is a major deployment problem. This document looks at
the this problem in detail and describes the potential solutions
available.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 17, 2020. This Internet-Draft will expire on May 1, 2021.
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 20
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. Pre-distributing and Omitting CA certificates . . . . 6 4.1.2. Pre-distributing and Omitting CA certificates . . . . 7
4.1.3. Using Fewer Intermediate Certificates . . . . . . . . 7 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. URLs for Client Certificates . . . . . . . . . . . . 7 4.2.1. URLs for Client Certificates . . . . . . . . . . . . 7
4.2.2. Caching Certificates . . . . . . . . . . . . . . . . 7 4.2.2. Caching Certificates . . . . . . . . . . . . . . . . 8
4.2.3. Compressing Certificates . . . . . . . . . . . . . . 8 4.2.3. Compressing Certificates . . . . . . . . . . . . . . 8
4.2.4. Compact TLS 1.3 . . . . . . . . . . . . . . . . . . . 8 4.2.4. Compact TLS 1.3 . . . . . . . . . . . . . . . . . . . 9
4.2.5. Suppressing Intermediate Certificates . . . . . . . . 9 4.2.5. Suppressing Intermediate Certificates . . . . . . . . 9
4.2.6. Raw Public Keys . . . . . . . . . . . . . . . . . . . 9 4.2.6. Raw Public Keys . . . . . . . . . . . . . . . . . . . 9
4.2.7. New Certificate Types and Compression Algorithms . . 9 4.2.7. New Certificate Types and Compression Algorithms . . 9
4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 9 4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
provides a standard mechanism for support of multiple authentication provides a standard mechanism for support of multiple authentication
methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216]
[I-D.ietf-emu-eap-tls13] relies on TLS [RFC8446] to provide strong [I-D.ietf-emu-eap-tls13] relies on TLS [RFC8446] to provide strong
mutual authentication with certificates [RFC5280] and is widely mutual authentication with certificates [RFC5280] and is widely
deployed and often used for network access authentication. There are deployed and often used for network access authentication. There are
also many other TLS-based EAP methods, such as Flexible also many other TLS-based EAP methods, such as Flexible
skipping to change at page 3, line 10 skipping to change at page 3, line 13
vendor specific EAP methods. vendor specific EAP methods.
Certificates in EAP deployments can be relatively large, and the Certificates in EAP deployments can be relatively large, and the
certificate chains can be long. Unlike the use of TLS on the web, certificate chains can be long. Unlike the use of TLS on the web,
where typically only the TLS server is authenticated; EAP-TLS where typically only the TLS server is authenticated; EAP-TLS
deployments typically authenticates both the EAP peer and the EAP deployments typically authenticates both the EAP peer and the EAP
server. Also, from deployment experience, EAP peers typically have server. Also, from deployment experience, EAP peers typically have
longer certificate chains than servers. This is because EAP peers longer certificate chains than servers. This is because EAP peers
often follow organizational hierarchies and tend to have many often follow organizational hierarchies and tend to have many
intermediate certificates. Thus, EAP-TLS authentication usually intermediate certificates. Thus, EAP-TLS authentication usually
involves significantly more octets than when TLS is used as part of involves exchange of significantly more octets than when TLS is used
HTTPS. as part of HTTPS.
Section 3.1 of [RFC3748] states that EAP implementations can assume a Section 3.1 of [RFC3748] states that EAP implementations can assume a
MTU of at least 1020 octets from lower layers. The EAP fragment size MTU of at least 1020 octets from lower layers. The EAP fragment size
in typical deployments is just 1020 - 1500 octets (since the maximum in typical deployments is just 1020 - 1500 octets (since the maximum
Ethernet frame size is ~ 1500 bytes). Thus, EAP-TLS authentication Ethernet frame size is ~ 1500 bytes). Thus, EAP-TLS authentication
needs to be fragmented into many smaller packets for transportation needs to be fragmented into many smaller packets for transportation
over the lower layers. Such fragmentation can not only negatively over the lower layers. Such fragmentation can not only negatively
affect the latency, but also results in other challenges. For affect the latency, but also results in other challenges. For
example, some EAP authenticator (access point) implementations will example, some EAP authenticator (access point) implementations will
drop an EAP session if it has not finished after 40 - 50 round-trips. drop an EAP session if it has not finished after 40 - 50 round-trips.
skipping to change at page 4, line 47 skipping to change at page 4, line 49
o Long Public Key and Signature fields. o Long Public Key and Signature fields.
o Can contain multiple object identifiers (OID) that indicate the o Can contain multiple object identifiers (OID) that indicate the
permitted uses of the certificate as noted in Section 5.3 of permitted uses of the certificate as noted in Section 5.3 of
[RFC5216]. Most implementations verify the presence of these OIDs [RFC5216]. Most implementations verify the presence of these OIDs
for successful authentication. for successful authentication.
o Multiple user groups in the certificate. o Multiple user groups in the certificate.
A certificate chain (called a certification path in [RFC5280]) can A certificate chain (called a certification path in [RFC5280]) can
have 2 - 6 intermediate certificates between the end-entity commonly have 2 - 6 intermediate certificates between the end-entity
certificate and the trust anchor. certificate and the trust anchor.
Many access point implementations drop EAP sessions that do not Many access point implementations drop EAP sessions that do not
complete within 50 round-trips. This means that if the chain is complete within 50 round-trips. This means that if the chain is
larger than ~ 60 kB, EAP-TLS authentication cannot complete larger than ~ 60 kbytes, EAP-TLS authentication cannot complete
successfully in most deployments. successfully in most deployments.
4. Handling of Large Certificates and Long Certificate Chains 4. Handling of Large Certificates and Long Certificate Chains
This section discusses some possible alternatives for overcoming the This section discusses some possible alternatives for overcoming the
challenge of large certificates and long certificate chains in EAP- challenge of large certificates and long certificate chains in EAP-
TLS authentication. In Section 4.1 we look at recommendations that TLS authentication. Section 4.1 considers recommendations that
require an update of the certificates or certificate chains that are require an update of the certificates or certificate chains used for
used for EAP-TLS authentication without requiring changes to the EAP-TLS authentication without requiring changes to the existing EAP-
existing EAP-TLS code base. We also provide some guidelines when TLS code base. It also provides some guidelines that should be
issuing certificates for use with EAP-TLS. In Section 4.2 we look at followed when issuing certificates for use with EAP-TLS. Section 4.2
recommendations that rely on updates to the EAP-TLS implementations considers recommendations that rely on updates to the EAP-TLS
which can be deployed with existing certificates. In Section 4.3 we implementations and can be deployed with existing certificates.
shortly discuss the solution to update or reconfigure authenticator Finally, Section 4.3 briefly discusses what could be done to update
which can be deployed without changes to existing certificates or or reconfigure authenticators when it is infeasible to replace
EAP-TLS code. deployed components giving a solution which can be deployed without
changes to existing certificates or code.
4.1. Updating Certificates and Certificate Chains 4.1. Updating Certificates and Certificate Chains
Many IETF protocols now use elliptic curve cryptography (ECC) Many IETF protocols now use elliptic curve cryptography (ECC)
[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
skipping to change at page 5, line 47 skipping to change at page 5, line 51
1.3 [RFC8446] requires implementations to support ECC. New cipher 1.3 [RFC8446] requires implementations to support ECC. New cipher
suites that use ECC are also specified for TLS 1.2 [RFC5289]. Using suites that use ECC are also specified for TLS 1.2 [RFC5289]. Using
ECC based cipher suites with existing code can significantly reduce ECC based cipher suites with existing code can significantly reduce
the number of messages in a single EAP session. 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 are as follows:
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
of integers, is then used to name objects to which they relate.
The DER length for the 1st two integers is always one octet and o Object Identifiers (OIDs) is an ASN.1 data type that defines
subsequent integers are base 128-encoded in the fewest possible unique identifiers for objects. The OID's ASN.1 value, which is a
octets. OIDs are used lavishly in X.509 certificates and while string of integers, is then used to name objects to which they
not all can be avoided, e.g., OIDs for extensions or algorithms relate. The Distinguished Encoding Rules (DER) length for the
and their associate parameters, some are well within the first two integers is always one octet and subsequent integers are
certificate issuer's control: base 128-encoded in the fewest possible octets. OIDs are used
lavishly in X.509 certificates [RFC5280] and while not all can be
avoided, e.g., OIDs for extensions or algorithms and their
associate parameters, some are well within the certificate
issuer's control:
* Each naming attribute in a DN (Directory Name) has one. DNs * Each naming attribute in a DN (Directory Name) has one. DNs
used in the issuer and subject fields as well as numerous used in the issuer and subject fields as well as numerous
extensions. A shallower naming will be smaller, e.g., C=FI, extensions. A shallower naming will be smaller, e.g., C=FI,
O=Example, SN=B0A123499EFC vs C=FI, O=Example, OU=Division 1, O=Example, SN=B0A123499EFC as against C=FI, O=Example,
SOPN=Southern Finland, CN=Coolest IoT Gadget Ever, OU=Division 1, SOPN=Southern Finland, CN=Coolest IoT Gadget
SN=B0A123499EFC. Ever, SN=B0A123499EFC.
* Every certificate policy (and qualifier) and any mappings to * Every certificate policy (and qualifier) and any mappings to
another policy uses identifiers. Consider carefully what another policy uses identifiers. Consider carefully what
policies apply. policies apply.
o DirectoryString and GeneralName types are used extensively to name o DirectoryString and GeneralName types are used extensively to name
things, e.g., the DN naming attribute O= (the organizational things, e.g., the DN naming attribute O= (the organizational
naming attribute) DirectoryString includes "Example" for the naming attribute) DirectoryString includes "Example" for the
Example organization and uniformResourceIdentifier can be used to Example organization and uniformResourceIdentifier can be used to
indicate the location of the CRL, e.g., "http://crl.example.com/ indicate the location of the CRL, e.g., "http://crl.example.com/
skipping to change at page 7, line 25 skipping to change at page 7, line 32
The EAP peer certificate chain does not have to mirror the The EAP peer certificate chain does not have to mirror the
organizational hierarchy. For successful EAP-TLS authentication, organizational hierarchy. For successful EAP-TLS authentication,
certificate chains SHOULD NOT contain more than 2-4 intermediate certificate chains SHOULD NOT contain more than 2-4 intermediate
certificates. certificates.
Administrators responsible for deployments using TLS-based EAP Administrators responsible for deployments using TLS-based EAP
methods can examine the certificate chains and make rough methods can examine the certificate chains and make rough
calculations about the number of round trips required for successful calculations about the number of round trips required for successful
authentication. For example, dividing the total size of all the authentication. For example, dividing the total size of all the
certificates in the peer and server certificate chain by 1020 will certificates in the peer and server certificate chain (in bytes) by
indicate the minimum number of round trips required. If this number 1020 bytes will indicate the minimum number of round trips required.
exceeds 50, then, administrators can expect failures with many common If this number exceeds 50, then, administrators can expect failures
authenticator implementations. with many common authenticator implementations.
4.2. Updating TLS and EAP-TLS Code 4.2. Updating TLS and EAP-TLS Code
This section discusses how the fragmentation problem can be avoided This section discusses how the fragmentation problem can be avoided
by updating the underlying TLS or EAP-TLS implementation. Note that by updating the underlying TLS or EAP-TLS implementation. Note that
in many cases the new feature may already be implemented in the in many cases the new feature may already be implemented in the
underlying library and simply needs to be taken into use. underlying library and simply needs to be taken into use.
4.2.1. URLs for Client Certificates 4.2.1. URLs for Client Certificates
skipping to change at page 8, line 16 skipping to change at page 8, line 23
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
server certificate chain. If the server's certificate has not server certificate chain. If the server's certificate has not
changed, then the server does not need to send its certificate and changed, then the server does not need to send its certificate and
the corresponding certificate chain again. In case information has the corresponding certificate chain again. In case information has
changed, which can be seen from the fingerprint provided by the changed, which can be seen from the fingerprint provided by the
client, the certificate payload is transmitted to the client to allow client, the certificate payload is transmitted to the client to allow
the client to update the cache. The extension however necessitates a the client to update the cache. The extension however necessitates a
successful full handshake before any caching. This extension can be successful full handshake before any caching. This extension can be
useful when, for example, when a successful authentication between an useful when, for example, a successful authentication between an EAP
EAP peer and EAP server has occurred in the home network. If peer and EAP server has occurred in the home network. If
authenticators in a roaming network are more strict at dropping long authenticators in a roaming network are stricter at dropping long EAP
EAP sessions, an EAP peer can use the Cached Information Extension to 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.3. Compressing Certificates 4.2.3. Compressing Certificates
skipping to change at page 8, line 47 skipping to change at page 9, line 10
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.4. Compact TLS 1.3 4.2.4. Compact TLS 1.3
[I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and [I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and
reduces the message size of the protocol by removing obsolete reduces the message size of the protocol by removing obsolete
material and using more efficient encoding. It also defines a material and using more efficient encoding. It also defines a
compression profile with which either side can define dictionary of compression profile with which either side can define a dictionary of
"known certificates". Thus, cTLS can provide another mechanism for "known certificates". Thus, cTLS can provide another mechanism for
EAP-TLS deployments to reduce the size of messages and avoid EAP-TLS deployments to reduce the size of messages and avoid
excessive fragmentation. excessive fragmentation.
4.2.5. Suppressing Intermediate Certificates 4.2.5. Suppressing Intermediate Certificates
For a client that has all intermediates, having the server send For a client that has all intermediate certificates in the
intermediates in the TLS handshake increases the size of the certificate chain, having the server send intermediates in the TLS
handshake unnecessarily. The TLS working group is working on an handshake increases the size of the handshake unnecessarily. The TLS
extension for TLS 1.3 [I-D.thomson-tls-sic] that allows a TLS client working group is working on an extension for TLS 1.3
that has access to the complete set of published intermediate [I-D.thomson-tls-sic] that allows a TLS client that has access to the
certificates to inform servers of this fact so that the server can complete set of published intermediate certificates to inform servers
avoid sending intermediates, reducing the size of the TLS handshake. of this fact so that the server can avoid sending intermediates,
The mechanism is intended to be complementary with certificate reducing the size of the TLS handshake. The mechanism is intended to
compression. be complementary with certificate compression.
4.2.6. Raw Public Keys 4.2.6. Raw Public Keys
[RFC7250] defines a new certificate type and TLS extensions to enable [RFC7250] defines a new certificate type and TLS extensions to enable
the use of raw public keys for authentication. Raw public keys use the use of raw public keys for authentication. Raw public keys use
only a subset of information found in typical certificates and are only a subset of information found in typical certificates and are
therefore much smaller in size. However, raw public keys require an therefore much smaller in size. However, raw public keys require an
out-of-band mechanism to bind the public key with the entity out-of-band mechanism to bind the public key with the entity
presenting the key. Using raw public keys will obviously avoid the presenting the key. Using raw public keys will obviously avoid the
fragmentation problems resulting from large certificates and long fragmentation problems resulting from large certificates and long
skipping to change at page 9, line 49 skipping to change at page 10, line 11
initiatives, future EAP-TLS deployments can consider the use of these initiatives, future EAP-TLS deployments can consider the use of these
new certificate types and compression algorithms to avoid large new certificate types and compression algorithms to avoid large
message sizes. 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 reason is that unlimited communication from an unauthenticated device
device as EAP could otherwise be use for bulk data transfer. A third using EAP could provide a channel for inappropriate bulk data
reason is to prevent denial-of-service attacks. transfer. A third reason is to prevent denial-of-service attacks.
Updating the millions of already deployed access points and switches Updating the millions of already deployed access points and switches
is in many cases not realistic. Vendors may be out of business or do is in many cases not realistic. Vendors may be out of business or do
no longer support the products and administrators may have lost the no longer support the products and administrators may have lost the
login information to the devices. For practical purposes the EAP login information to the devices. For practical purposes the EAP
infrastructure is ossified for the time being. infrastructure is ossified for the time being.
Vendors making new authenticators should consider increasing the Vendors making new authenticators should consider increasing the
number of round-trips allowed to 100 before denying the EAP number of round-trips allowed to 100 before denying the EAP
authentication to complete. At the same time, administrators authentication to complete. Based on the size of the certificates
responsible for EAP deployments should ensure that this 100 roundtrip and certificate chains currently deployed, such an increase would
limit is not exceeded in practice. likely ensure that peers and servers can complete EAP-TLS
authentication. At the same time, administrators responsible for EAP
deployments should ensure that this 100 roundtrip limit is not
exceeded in practice.
5. IANA Considerations 5. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
6. Security Considerations 6. Security Considerations
Updating implementations to TLS version 1.3 allows omitting all Updating implementations to TLS version 1.3 allows omitting all
certificates with a trust anchor known by the other endpoint. TLS certificates with a trust anchor known by the other endpoint. TLS
1.3 additionally provides improved security, privacy, and reduced 1.3 additionally provides improved security, privacy, and reduced
latency for EAP-TLS [I-D.ietf-emu-eap-tls13]. latency for EAP-TLS [I-D.ietf-emu-eap-tls13].
When compressing certificates, the underlying compression algorithm Security considerations when compressing certificates are specified
MUST output the same data that was provided as input by. After in [I-D.ietf-tls-certificate-compression].
decompression, the Certificate message MUST be processed as if it
were encoded without being compressed. Additional security
considerations when compressing certificates are specified in
[I-D.ietf-tls-certificate-compression]
As noted in [I-D.thomson-tls-sic], suppressing intermediate As noted in [I-D.thomson-tls-sic], suppressing intermediate
certificates creates an unencrypted signal that might be used to certificates creates an unencrypted signal that might be used to
identify which clients believe that they have all intermediates. identify which clients believe that they have all intermediates.
This might also allow more effective fingerprinting and tracking of This might also allow more effective fingerprinting and tracking of
clients. clients.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-emu-eap-tls13] [I-D.ietf-emu-eap-tls13]
Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3", Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",
draft-ietf-emu-eap-tls13-10 (work in progress), June 2020. draft-ietf-emu-eap-tls13-11 (work in progress), October
2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
skipping to change at page 12, line 20 skipping to change at page 12, line 36
[I-D.thomson-tls-sic] [I-D.thomson-tls-sic]
Thomson, M., "Suppressing Intermediate Certificates in Thomson, M., "Suppressing Intermediate Certificates in
TLS", draft-thomson-tls-sic-00 (work in progress), March TLS", draft-thomson-tls-sic-00 (work in progress), March
2019. 2019.
[I-D.tschofenig-tls-cwt] [I-D.tschofenig-tls-cwt]
Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens
(CWTs) in Transport Layer Security (TLS) and Datagram (CWTs) in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS)", draft-tschofenig-tls- Transport Layer Security (DTLS)", draft-tschofenig-tls-
cwt-01 (work in progress), November 2019. cwt-02 (work in progress), July 2020.
[IEEE-802.1X] [IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Port- Standard for Local and metropolitan area networks -- Port-
Based Network Access Control", IEEE Standard 802.1X-2010 , Based Network Access Control", IEEE Standard 802.1X-2010 ,
February 2010. February 2010.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000, RFC 2865, DOI 10.17487/RFC2865, June 2000,
 End of changes. 27 change blocks. 
78 lines changed or deleted 82 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/