rfc9191.original   rfc9191.txt 
Network Working Group M. Sethi Internet Engineering Task Force (IETF) M. Sethi
Internet-Draft J. Mattsson Request for Comments: 9191 J. Preuß Mattsson
Intended status: Informational Ericsson Category: Informational Ericsson
Expires: May 24, 2021 S. Turner ISSN: 2070-1721 S. Turner
sn3rd sn3rd
November 20, 2020 February 2022
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-08
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in RFC3748, The Extensible Authentication Protocol (EAP), defined in RFC 3748,
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) and other TLS-based methods. EAP-TLS and other TLS-based EAP methods are widely deployed
EAP methods are widely deployed and used for network access and used for network access authentication. Large certificates and
authentication. Large certificates and long certificate chains long certificate chains combined with authenticators that drop an EAP
combined with authenticators that drop an EAP session after only 40 - session after only 40 - 50 round trips is a major deployment problem.
50 round-trips is a major deployment problem. This document looks at This document looks at this problem in detail and describes the
this problem in detail and describes the potential solutions potential solutions available.
available.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on May 24, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9191.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2022 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Experience with Deployments . . . . . . . . . . . . . . . . . 4 3. Experience with Deployments
4. Handling of Large Certificates and Long Certificate Chains . 5 4. Handling of Large Certificates and Long Certificate Chains
4.1. Updating Certificates and Certificate Chains . . . . . . 5 4.1. Updating Certificates and Certificate Chains
4.1.1. Guidelines for Certificates . . . . . . . . . . . . . 6 4.1.1. Guidelines for Certificates
4.1.2. Pre-distributing and Omitting CA certificates . . . . 7 4.1.2. Pre-distributing and Omitting CA Certificates
4.1.3. Using Fewer Intermediate Certificates . . . . . . . . 7 4.1.3. Using Fewer Intermediate Certificates
4.2. Updating TLS and EAP-TLS Code . . . . . . . . . . . . . . 7 4.2. Updating TLS and EAP-TLS Code
4.2.1. URLs for Client Certificates . . . . . . . . . . . . 7 4.2.1. URLs for Client Certificates
4.2.2. Caching Certificates . . . . . . . . . . . . . . . . 8 4.2.2. Caching Certificates
4.2.3. Compressing Certificates . . . . . . . . . . . . . . 8 4.2.3. Compressing Certificates
4.2.4. Compact TLS 1.3 . . . . . . . . . . . . . . . . . . . 9 4.2.4. Compact TLS 1.3
4.2.5. Suppressing Intermediate Certificates . . . . . . . . 9 4.2.5. Suppressing Intermediate Certificates
4.2.6. Raw Public Keys . . . . . . . . . . . . . . . . . . . 9 4.2.6. Raw Public Keys
4.2.7. New Certificate Types and Compression Algorithms . . 10 4.2.7. New Certificate Types and Compression Algorithms
4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 10 4.3. Updating Authenticators
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.1. Normative References
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.2. Informative References
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
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-TLS [RFC5216] [RFC9190] relies on TLS [RFC8446] to
[I-D.ietf-emu-eap-tls13] relies on TLS [RFC8446] to provide strong provide strong mutual authentication with certificates [RFC5280] and
mutual authentication with certificates [RFC5280] and is widely is widely deployed and often used for network access authentication.
deployed and often used for network access authentication. There are There are also many other standardized TLS-based EAP methods such as
also many other TLS-based EAP methods, such as Flexible Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851],
Authentication via Secure Tunneling (EAP-FAST) [RFC4851], Tunneled Tunneled Transport Layer Security (EAP-TTLS) [RFC5281], the Tunnel
Transport Layer Security (EAP-TTLS) [RFC5281], Tunnel Extensible Extensible Authentication Protocol (TEAP) [RFC7170], as well as
Authentication Protocol (EAP-TEAP) [RFC7170], and possibly many several vendor-specific EAP methods such as the Protected Extensible
vendor-specific EAP methods. Authentication Protocol (PEAP) [PEAP].
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 authenticate both the EAP peer and the EAP deployments typically authenticate 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 exchange of significantly more octets than when TLS is used involves exchange of significantly more octets than when TLS is used
as part of 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
Maximum Transmission Unit (MTU) of at least 1020 octets from lower Maximum Transmission Unit (MTU) of at least 1020 octets from lower
layers. The EAP fragment size in typical deployments is just 1020 - layers. The EAP fragment size in typical deployments is just 1020 -
1500 octets (since the maximum Ethernet frame size is ~ 1500 bytes). 1500 octets (since the maximum Ethernet frame size is ~ 1500 bytes).
Thus, EAP-TLS authentication needs to be fragmented into many smaller Thus, EAP-TLS authentication needs to be fragmented into many smaller
packets for transportation over the lower layers. Such fragmentation packets for transportation over the lower layers. Such fragmentation
not only can negatively affect the latency, but also results in other not only can negatively affect the latency, but also results in other
challenges. For example, some EAP authenticator (access point) challenges. For example, some EAP authenticator (e.g., an access
implementations will drop an EAP session if it has not finished after point) implementations will drop an EAP session if it has not
40 - 50 round-trips. This is a major problem and means that in many finished after 40 - 50 round trips. This is a major problem and
situations, the EAP peer cannot perform network access authentication means that, in many situations, the EAP peer cannot perform network
even though both the sides have valid credentials for successful access authentication even though both the sides have valid
authentication and key derivation. credentials for successful authentication and key derivation.
Not all EAP deployments are constrained by the MTU of the lower Not all EAP deployments are constrained by the MTU of the lower
layer. For example, some implementations support EAP over Ethernet layer. For example, some implementations support EAP over Ethernet
"Jumbo" frames that can easily allow very large EAP packets. Larger "jumbo" frames that can easily allow very large EAP packets. Larger
packets will naturally help lower the number of round trips required packets will naturally help lower the number of round trips required
for successful EAP-TLS authentication. However, deployment for successful EAP-TLS authentication. However, deployment
experience has shown that these jumbo frames are not always experience has shown that these jumbo frames are not always
implemented correctly. Additionally, EAP fragment size is also implemented correctly. Additionally, EAP fragment size is also
restricted by protocols such as RADIUS [RFC2865] which are restricted by protocols such as RADIUS [RFC2865], which are
responsible for transporting EAP messages between an authenticator responsible for transporting EAP messages between an authenticator
and an EAP server. RADIUS can generally transport only about 4000 and an EAP server. RADIUS can generally transport only about 4000
octets of EAP in a single message (the maximum length of RADIUS octets of EAP in a single message (the maximum length of a RADIUS
packet is restricted to 4096 octets in [RFC2865]). packet is restricted to 4096 octets in [RFC2865]).
This document looks at related work and potential tools available for This document looks at related work and potential tools available for
overcoming the deployment challenges induced by large certificates overcoming the deployment challenges induced by large certificates
and long certificate chains. It then discusses the solutions and long certificate chains. It then discusses the solutions
available to overcome these challenges. available to overcome these challenges. Many of the solutions
require TLS 1.3 [RFC8446]. The IETF has standardized EAP-TLS 1.3
[RFC9190] and is working on specifications such as [TLS-EAP-TYPES]
for how other TLS-based EAP methods use TLS 1.3.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts used Readers are expected to be familiar with the terms and concepts used
in EAP [RFC3748], EAP-TLS [RFC5216], and TLS [RFC8446]. In in EAP [RFC3748], EAP-TLS [RFC5216], and TLS [RFC8446]. In
particular, this document frequently uses the following terms as they particular, this document frequently uses the following terms as they
have been defined in [RFC5216]: have been defined in [RFC5216]:
Authenticator The entity initiating EAP authentication. Typically Authenticator: The entity initiating EAP authentication. Typically
implemented as part of a network switch or a wireless access implemented as part of a network switch or a wireless access
point. point.
EAP peer The entity that responds to the authenticator. In EAP peer: The entity that responds to the authenticator. In
[IEEE-802.1X], this entity is known as the supplicant. In EAP- [IEEE-802.1X], this entity is known as the supplicant. In EAP-
TLS, the EAP peer implements the TLS client role. TLS, the EAP peer implements the TLS client role.
EAP server The entity that terminates the EAP authentication method EAP server: The entity that terminates the EAP authentication method
with the peer. In the case where no backend authentication with the peer. In the case where no backend authentication
server is used, the EAP server is part of the authenticator. server is used, the EAP server is part of the authenticator.
In the case where the authenticator operates in pass-through In the case where the authenticator operates in pass-through
mode, the EAP server is located on the backend authentication mode, the EAP server is located on the backend authentication
server. In EAP-TLS, the EAP server implements the TLS server server. In EAP-TLS, the EAP server implements the TLS server
role. role.
The document additionally uses the terms "trust anchor" and The document additionally uses the terms "trust anchor" and
"certification path" defined in [RFC5280]. "certification path" defined in [RFC5280].
3. Experience with Deployments 3. Experience with Deployments
As stated earlier, the EAP fragment size in typical deployments is As stated earlier, the EAP fragment size in typical deployments is
just 1020 - 1500 octets. A certificate can, however, be large for a just 1020 - 1500 octets. A certificate can, however, be large for a
number of reasons: number of reasons:
o It can have a long Subject Alternative Name field. * It can have a long Subject Alternative Name field.
o It can have long Public Key and Signature fields. * It can have long Public Key and Signature fields.
o It can contain multiple object identifiers (OID) that indicate the * It can contain multiple object identifiers (OIDs) that indicate
permitted uses of the certificate as noted in Section 5.3 of the 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 It can contain multiple organization fields to reflect the * It can contain multiple organization naming fields to reflect the
multiple group memberships of a user (in a client certificate). multiple group memberships of a user (in a client certificate).
A certificate chain (called a certification path in [RFC5280]) in A certificate chain (called a certification path in [RFC5280]) in
EAP-TLS can commonly have 2 - 6 intermediate certificates between the EAP-TLS can commonly have 2 - 6 intermediate certificates between the
end-entity certificate and the trust anchor. end-entity certificate and the trust anchor.
The size of certificates (and certificate chains) may also increase The size of certificates (and certificate chains) may also increase
many-fold in the future with the introduction of quantum-safe manyfold in the future with the introduction of post-quantum
cryptography. For example, lattice-based cryptography would have cryptography. For example, lattice-based cryptography would have
public keys of approximately 1000 bytes and signatures of public keys of approximately 1000 bytes and signatures of
approximately 2000 bytes. approximately 2000 bytes.
Many access point implementations drop EAP sessions that do not Many access point implementations drop EAP sessions that do not
complete within 40 - 50 round-trips. This means that if the chain is complete within 40 - 50 round trips. This means that if the chain is
larger than ~ 60 kbytes, EAP-TLS authentication cannot complete larger than ~ 60 kilobytes, 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. Section 4.1 considers recommendations that TLS authentication. Section 4.1 considers recommendations that
require an update of the certificates or certificate chains used for require an update of the certificates or certificate chains used for
EAP-TLS authentication without requiring changes to the existing EAP- EAP-TLS authentication without requiring changes to the existing EAP-
TLS code base. It also provides some guidelines that should be TLS code base. It also provides some guidelines that should be
followed when issuing certificates for use with EAP-TLS. Section 4.2 followed when issuing certificates for use with EAP-TLS. Section 4.2
considers recommendations that rely on updates to the EAP-TLS considers recommendations that rely on updates to the EAP-TLS
implementations and can be deployed with existing certificates. implementations and can be deployed with existing certificates.
Finally, Section 4.3 briefly discusses what could be done to update Finally, Section 4.3 briefly discusses what could be done to update
or reconfigure authenticators when it is infeasible to replace or reconfigure authenticators when it is infeasible to replace
deployed components giving a solution which can be deployed without deployed components giving a solution that can be deployed without
changes to existing certificates or code. 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 a public key with at a 128-bit security level, the size of a public key with
traditional RSA is about 384 bytes, while the size of a public key traditional RSA is about 384 bytes, while the size of a public key
with ECC is only 32-64 bytes. Similarly, the size of a digital with ECC is only 32-64 bytes. Similarly, the size of a digital
signature with traditional RSA is 384 bytes, while the size is only signature with traditional RSA is 384 bytes, while the size is only
64 bytes with elliptic curve digital signature algorithm (ECDSA) and 64 bytes with the elliptic curve digital signature algorithm (ECDSA)
Edwards-curve digital signature algorithm (EdDSA) [RFC8032]. Using and the Edwards-curve digital signature algorithm (EdDSA) [RFC8032].
certificates that use ECC can reduce the number of messages in EAP- Using certificates that use ECC can reduce the number of messages in
TLS authentication, which can alleviate the problem of authenticators EAP-TLS authentication, which can alleviate the problem of
dropping an EAP session because of too many round-trips. In the authenticators dropping an EAP session because of too many round
absence of a standard application profile specifying otherwise, TLS trips. In the absence of a standard application profile specifying
1.3 [RFC8446] requires implementations to support ECC. New cipher otherwise, TLS 1.3 [RFC8446] requires implementations to support ECC.
suites that use ECC are also specified for TLS 1.2 [RFC8422]. Using New cipher suites that use ECC are also specified for TLS 1.2
ECC-based cipher suites with existing code can significantly reduce [RFC8422]. Using ECC-based cipher suites with existing code can
the number of messages in a single EAP session. 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 are as follows: recommendations for certificates used with EAP-TLS are as follows:
o Object Identifier (OID) is an ASN.1 data type that defines unique * Object Identifier (OID) is an 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
of integers, is then used to name objects to which they relate. of integers, is then used to name objects to which they relate.
The Distinguished Encoding Rules (DER) specify that the first two The Distinguished Encoding Rules (DER) specify that the first two
integers always occupy one octet and subsequent integers are base integers always occupy one octet and subsequent integers are
128-encoded in the fewest possible octets. OIDs are used lavishly base-128 encoded in the fewest possible octets. OIDs are used
in X.509 certificates [RFC5280] and while not all can be avoided, lavishly in X.509 certificates [RFC5280] and while not all can be
e.g., OIDs for extensions or algorithms and their associate avoided, e.g., OIDs for extensions or algorithms and their
parameters, some are well within the certificate issuer's control: 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 (Distinguished Name) has one.
are used in the issuer and subject fields as well as numerous DNs are used in the issuer and subject fields as well as
extensions. A shallower naming will be smaller, e.g., C=FI, numerous extensions. A shallower name will be smaller, e.g.,
O=Example, SN=B0A123499EFC as against C=FI, O=Example, C=FI, O=Example, SN=B0A123499EFC as against C=FI, O=Example,
OU=Division 1, SOPN=Southern Finland, CN=Coolest IoT Gadget OU=Division 1, SOPN=Southern Finland, CN=Coolest IoT Gadget
Ever, SN=B0A123499EFC. Ever, and 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 * 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 Certificate Revocation List (CRL),
sfig2s1-128.crl", in the CRL Distribution Point extension. For e.g., "http://crl.example.com/sfig2s1-128.crl", in the CRL
these particular examples, each character is a byte. For some Distribution Point extension. For these particular examples, each
non-ASCII character strings in the DN, characters can be multi- character is a single byte. For some non-ASCII character strings,
byte. Obviously, the names need to be unique, but there is more characters can be several bytes. Obviously, the names need to be
than one way to accomplish this without long strings. This is unique, but there is more than one way to accomplish this without
especially true if the names are not meant to be meaningful to long strings. This is especially true if the names are not meant
users. to be meaningful to users.
o Extensions are necessary to comply with [RFC5280], but the vast * Extensions are necessary to comply with [RFC5280], but the vast
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 * 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. Pre-distributing and Omitting CA certificates 4.1.2. 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]).
updating TLS implementations to version 1.3 can help to significantly Therefore, updating TLS implementations to version 1.3 can help to
reduce the number of messages exchanged for EAP-TLS authentication. significantly reduce the number of messages exchanged for EAP-TLS
The omitted certificates need to be pre-distributed independently of authentication. The omitted certificates need to be pre-distributed
TLS and the TLS implementations need to be configured to omit these independently of TLS, and the TLS implementations need to be
pre-distributed certificates. configured to omit these pre-distributed certificates.
4.1.3. Using Fewer Intermediate Certificates 4.1.3. Using Fewer Intermediate Certificates
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 4 intermediate certificate chains SHOULD NOT contain more than 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 (in bytes) by certificates in the peer and server certificate chain (in bytes) by
1020 bytes will indicate the minimum number of round trips required. 1020 bytes will indicate the number of round trips required. If this
If this number exceeds 50, then, administrators can expect failures number exceeds 50, then administrators can expect failures with many
with many common authenticator implementations. 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 some cases the new feature may already be implemented in the in some 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 enabled.
4.2.1. URLs for Client Certificates 4.2.1. URLs for Client Certificates
[RFC6066] defines the "client_certificate_url" extension which allows [RFC6066] defines the "client_certificate_url" extension, which
TLS clients to send a sequence of Uniform Resource Locators (URLs) allows TLS clients to send a sequence of Uniform Resource Locators
instead of the client certificate. URLs can refer to a single (URLs) instead of the client certificate chain. URLs can refer to a
certificate or a certificate chain. Using this extension can curtail single certificate or a certificate chain. Using this extension can
the amount of fragmentation in EAP deployments thereby allowing EAP curtail the amount of fragmentation in EAP deployments thereby
sessions to successfully complete. allowing EAP sessions to successfully complete.
4.2.2. Caching Certificates 4.2.2. 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
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
successful full handshake before any caching. This extension can be a successful full handshake before any caching. This extension can
useful when, for example, a successful authentication between an EAP be useful when, for example, a successful authentication between an
peer and EAP server has occurred in the home network. If EAP peer and EAP server has occurred in the home network. If
authenticators in a roaming network are stricter at dropping long EAP authenticators in a roaming network are stricter at dropping long 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 such certificate chains even if the EAP-TLS exchange fails, but such
caching is currently not specified in [RFC7924]. caching is currently not specified in [RFC7924].
4.2.3. 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 has standardized an extension for TLS 1.3
[I-D.ietf-tls-certificate-compression] that allows compression of [RFC8879] that allows compression of certificates and certificate
certificates and certificate chains during full handshakes. The chains during full handshakes. The client can indicate support for
client can indicate support for compressed server certificates by compressed server certificates by including this extension in the
including this extension in the ClientHello message. Similarly, the ClientHello message. Similarly, the server can indicate support for
server can indicate support for compression of client certificates by compression of client certificates by including this extension in the
including this extension in the CertificateRequest message. While CertificateRequest message. While such an extension can alleviate
such an extension can alleviate the problem of excessive the problem of excessive fragmentation in EAP-TLS, it can only be
fragmentation in EAP-TLS, it can only be used with TLS version 1.3 used with TLS version 1.3 and higher. Deployments that rely on older
and higher. Deployments that rely on older versions of TLS cannot 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 [cTLS] defines a "compact" version of TLS 1.3 and reduces the message
reduces the message size of the protocol by removing obsolete size of the protocol by removing obsolete material and using more
material and using more efficient encoding. It also defines a efficient encoding. It also defines a compression profile with which
compression profile with which either side can define a dictionary of either side can define a dictionary of "known certificates". Thus,
"known certificates". Thus, cTLS could provide another mechanism for cTLS could provide another mechanism for EAP-TLS deployments to
EAP-TLS deployments to reduce the size of messages and avoid 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 intermediate certificates in the For a client that has all intermediate certificates in the
certificate chain, having the server send intermediates in the TLS certificate chain, having the server send intermediates in the TLS
handshake increases the size of the handshake unnecessarily. handshake increases the size of the handshake unnecessarily.
[I-D.thomson-tls-sic] proposes an extension for TLS 1.3 that allows a [TLS-SIC] proposes an extension for TLS 1.3 that allows a TLS client
TLS client that has access to the complete set of published that has access to the complete set of published intermediate
intermediate certificates to inform servers of this fact so that the certificates to inform servers of this fact so that the server can
server can avoid sending intermediates, reducing the size of the TLS avoid sending intermediates, reducing the size of the TLS handshake.
handshake. The mechanism is intended to be complementary with The mechanism is intended to be complementary with certificate
certificate compression. compression.
The Authority Information Access (AIA) extension specified in The Authority Information Access (AIA) extension specified in
[RFC5280] can be used with end-entity and CA certificates to access [RFC5280] can be used with end-entity and CA certificates to access
information about the issuer of the certificate in which the information about the issuer of the certificate in which the
extension appears. For example, it can be used to provide the extension appears. For example, it can be used to provide the
address of the OCSP responder from where revocation status of the address of the Online Certificate Status Protocol (OCSP) responder
certificate (in which the extension appears) can be checked. It can from where revocation status of the certificate (in which the
also be used to obtain the issuer certificate. Thus, the AIA extension appears) can be checked. It can also be used to obtain the
extension can reduce the size of the certificate chain by only issuer certificate. Thus, the AIA extension can reduce the size of
including a pointer to the issuer certificate instead of including the certificate chain by only including a pointer to the issuer
the entire issuer certificate. However, it requires the side certificate instead of including the entire issuer certificate.
receiving the certificate containing the extension to have network However, it requires the side receiving the certificate containing
connectivity (unless the information is already cached locally). the extension to have network connectivity (unless the information is
Naturally, such indirection cannot be used for the server certificate already cached locally). Naturally, such indirection cannot be used
(since EAP peers in most deployments do not have network connectivity for the server certificate (since EAP peers in most deployments do
before authentication and typically do not maintain an up-to-date not have network connectivity before authentication and typically do
local cache of issuer certificates). not maintain an up-to-date local cache of issuer certificates).
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
certificate chains. Deployments can consider their use as long as an certificate chains. Deployments can consider their use as long as an
appropriate out-of-band mechanism for binding public keys with appropriate out-of-band mechanism for binding public keys with
identifiers is in place. Naturally, deployments will also need to identifiers is in place. Naturally, deployments will also need to
consider the challenges of revocation and key rotation with the use consider the challenges of revocation and key rotation with the use
of raw public keys. of raw public keys.
4.2.7. New Certificate Types and Compression Algorithms 4.2.7. New Certificate Types and Compression Algorithms
There is ongoing work to specify new certificate types which are There is ongoing work to specify new certificate types that are
smaller than traditional X.509 certificates. For example, smaller than traditional X.509 certificates. For example,
[I-D.mattsson-cose-cbor-cert-compress] defines a Concise Binary [CBOR-CERT] defines a Concise Binary Object Representation (CBOR)
Object Representation (CBOR) [RFC7049] encoding of X.509 [RFC8949] encoding of X.509 Certificates. The CBOR encoding can be
Certificates. The CBOR encoding can be used to compress existing used to compress existing X.509 certificates or for natively signed
X.509 certificate or for natively signed CBOR certificates. CBOR certificates. [TLS-CWT] registers a new TLS Certificate type
[I-D.tschofenig-tls-cwt] registers a new TLS Certificate type which that would enable TLS implementations to use CBOR Web Tokens (CWTs)
would enable TLS implementations to use CBOR Web Tokens (CWTs)
[RFC8392] as certificates. While these are early initiatives, future [RFC8392] as certificates. While these are early initiatives, future
EAP-TLS deployments can consider the use of these new certificate EAP-TLS deployments can consider the use of these new certificate
types and compression algorithms to avoid large message sizes. 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 packets / octets / round trips that can be sent.
main reason has been to work around issues where the EAP peer and EAP The main reason has been to work around issues where the EAP peer and
server end up in an infinite loop ACKing their messages. Another EAP server end up in an infinite loop ACKing their messages. Another
reason is that unlimited communication from an unauthenticated device reason is that unlimited communication from an unauthenticated device
using EAP could provide a channel for inappropriate bulk data using EAP could provide a channel for inappropriate bulk data
transfer. A third 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 no is in many cases not realistic. Vendors may be out of business or no
longer supporting the products and administrators may have lost the longer supporting 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. Based on the size of the certificates authentication to complete. Based on the size of the certificates
and certificate chains currently deployed, such an increase would and certificate chains currently deployed, such an increase would
likely ensure that peers and servers can complete EAP-TLS likely ensure that peers and servers can complete EAP-TLS
authentication. At the same time, administrators responsible for EAP authentication. At the same time, administrators responsible for EAP
deployments should ensure that this 100 roundtrip limit is not deployments should ensure that this 100 round-trip limit is not
exceeded in practice. exceeded in practice.
5. IANA Considerations 5. IANA Considerations
This document includes no request to IANA. This document has no IANA actions.
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 [RFC9190].
Security considerations when compressing certificates are specified Security considerations when compressing certificates are specified
in [I-D.ietf-tls-certificate-compression]. in [RFC8879].
Specific security considerations of the referenced documents apply Specific security considerations of the referenced documents apply
when they are taken into use. when they are taken into use.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-emu-eap-tls13]
Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",
draft-ietf-emu-eap-tls13-12 (work in progress), November
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 30 skipping to change at line 543
<https://www.rfc-editor.org/info/rfc7170>. <https://www.rfc-editor.org/info/rfc7170>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
7.2. Informative References [RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
Extensible Authentication Protocol with TLS 1.3",
[I-D.ietf-tls-certificate-compression] RFC 9190, DOI 10.17487/RFC9190, February 2022,
Ghedini, A. and V. Vasiliev, "TLS Certificate <https://www.rfc-editor.org/rfc/rfc9190>.
Compression", draft-ietf-tls-certificate-compression-10
(work in progress), January 2020.
[I-D.ietf-tls-ctls]
Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
1.3", draft-ietf-tls-ctls-01 (work in progress), November
2020.
[I-D.mattsson-cose-cbor-cert-compress] 7.2. Informative References
Raza, S., Hoglund, J., Selander, G., Mattsson, J., and M.
Furuhed, "CBOR Encoding of X.509 Certificates (CBOR
Certificates)", draft-mattsson-cose-cbor-cert-compress-03
(work in progress), November 2020.
[I-D.thomson-tls-sic] [CBOR-CERT]
Thomson, M., "Suppressing Intermediate Certificates in Raza, S., Höglund, J., Selander, G., Preuß Mattsson, J.,
TLS", draft-thomson-tls-sic-00 (work in progress), March and M. Furuhed, "CBOR Encoded X.509 Certificates (C509
2019. Certificates)", Work in Progress, Internet-Draft, draft-
mattsson-cose-cbor-cert-compress-08, 22 February 2021,
<https://datatracker.ietf.org/doc/html/draft-mattsson-
cose-cbor-cert-compress-08>.
[I-D.tschofenig-tls-cwt] [cTLS] Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
(CWTs) in Transport Layer Security (TLS) and Datagram ctls-04, 25 October 2021,
Transport Layer Security (DTLS)", draft-tschofenig-tls- <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
cwt-02 (work in progress), July 2020. ctls-04>.
[IEEE-802.1X] [IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "IEEE IEEE, "IEEE Standard for Local and Metropolitan Area
Standard for Local and metropolitan area networks -- Port- NNetworks--Port-Based Network Access Control",
Based Network Access Control", IEEE Standard 802.1X-2010 , DOI 10.1109/IEEESTD.2020.9018454, IEEE Standard 802.1X-
February 2010. 2020, February 2020,
<https://doi.org/10.1109/IEEESTD.2020.9018454>.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", June 2021.
[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,
<https://www.rfc-editor.org/info/rfc2865>. <https://www.rfc-editor.org/info/rfc2865>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
skipping to change at page 13, line 37 skipping to change at line 594
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[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
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/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>.
skipping to change at page 14, line 20 skipping to change at line 620
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422, Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018, DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>. <https://www.rfc-editor.org/info/rfc8422>.
[RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate
Compression", RFC 8879, DOI 10.17487/RFC8879, December
2020, <https://www.rfc-editor.org/info/rfc8879>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[TLS-CWT] Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens
(CWTs) in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS)", Work in Progress,
Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
tls-cwt-02>.
[TLS-EAP-TYPES]
DeKok, A., "TLS-based EAP types and TLS 1.3", Work in
Progress, Internet-Draft, draft-ietf-emu-tls-eap-types-04,
22 January 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-emu-tls-eap-types-04>.
[TLS-SIC] Thomson, M., "Suppressing Intermediate Certificates in
TLS", Work in Progress, Internet-Draft, draft-thomson-tls-
sic-00, 27 March 2019,
<https://datatracker.ietf.org/doc/html/draft-thomson-tls-
sic-00>.
Acknowledgements Acknowledgements
This draft is a result of several useful discussions with Alan DeKok, This document is a result of several useful discussions with Alan
Bernard Aboba, Jari Arkko, Jouni Malinen, Darshak Thakore, and Hannes DeKok, Bernard Aboba, Jari Arkko, Jouni Malinen, Darshak Thakore, and
Tschofening. Hannes Tschofening.
Authors' Addresses Authors' Addresses
Mohit Sethi Mohit Sethi
Ericsson Ericsson
Jorvas 02420 FI-02420 Jorvas
Finland Finland
Email: mohit@piuha.net Email: mohit@iki.fi
John Mattsson John Preuß Mattsson
Ericsson Ericsson
Kista Kista
Sweden Sweden
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Sean Turner Sean Turner
sn3rd sn3rd
Email: sean@sn3rd.com Email: sean@sn3rd.com
 End of changes. 71 change blocks. 
241 lines changed or deleted 254 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/