Handling Large Certificates and Long Certificate Chains in TLS‑Based EAP MethodsEricssonJorvas02420Finlandmohit@iki.fiEricssonKistaSwedenjohn.mattsson@ericsson.comsn3rdsean@sn3rd.comNetwork Working GroupEAP-TLSX.509EAP authenticatorMaximum Transmission Unit
The Extensible Authentication Protocol (EAP), defined in RFC
3748, provides a standard mechanism for support of multiple
authentication methods. EAP-TLS and other TLS-based EAP
methods are widely deployed and used for network access
authentication. Large certificates and long certificate chains
combined with authenticators that drop an EAP session after
only 40 - 50 round trips is a major deployment problem. This
document looks at this problem in detail and describes the
potential solutions available.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
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.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Terminology
. Experience with Deployments
. Handling of Large Certificates and Long Certificate Chains
. Updating Certificates and Certificate Chains
. Guidelines for Certificates
. Pre-distributing and Omitting CA Certificates
. Using Fewer Intermediate Certificates
. Updating TLS and EAP-TLS Code
. URLs for Client Certificates
. Caching Certificates
. Compressing Certificates
. Compact TLS 1.3
. Suppressing Intermediate Certificates
. Raw Public Keys
. New Certificate Types and Compression Algorithms
. Updating Authenticators
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
Introduction
The Extensible Authentication Protocol (EAP), defined in , provides a standard mechanism for support
of multiple authentication methods. EAP-TLS relies on TLS
to provide strong mutual
authentication with certificates and
is widely deployed and often used for network access authentication.
There are also many other standardized TLS-based EAP methods such as Flexible
Authentication via Secure Tunneling (EAP-FAST) , Tunneled Transport Layer Security (EAP-TTLS) , the Tunnel Extensible Authentication Protocol
(TEAP) , as well as several
vendor-specific EAP methods such as the Protected Extensible Authentication Protocol (PEAP) .
Certificates in EAP deployments can be relatively large, and the certificate chains can be long. Unlike the use of TLS on the web, where typically only the TLS server is authenticated, EAP-TLS deployments typically authenticate both the EAP peer and the EAP server. Also, from deployment experience, EAP peers typically have longer certificate chains than servers. This is because EAP peers often follow organizational hierarchies and tend to have many intermediate certificates. Thus, EAP-TLS authentication usually involves exchange of significantly more octets than when TLS is used as part of HTTPS.
states that EAP implementations can
assume a Maximum Transmission Unit (MTU) of at least
1020 octets from lower layers. The EAP fragment size
in typical deployments is just 1020 - 1500 octets
(since the maximum Ethernet frame size is ~ 1500
bytes). Thus, EAP-TLS authentication needs to be
fragmented into many smaller packets for
transportation over the lower layers. Such
fragmentation not only can negatively affect the
latency, but also results in other challenges.
For example, some EAP authenticator (e.g., an access
point) implementations will drop an EAP session if it
has not finished after 40 - 50 round trips. This is a
major problem and means that, in many situations, the
EAP peer cannot perform network access authentication
even though both the sides have valid credentials for
successful authentication and key derivation.
Not all EAP deployments are constrained by the MTU of
the lower layer. For example, some implementations
support EAP over Ethernet "jumbo" frames that can
easily allow very large EAP packets. Larger packets
will naturally help lower the number of round trips
required for successful EAP-TLS
authentication. However, deployment experience has
shown that these jumbo frames are not always
implemented correctly. Additionally, EAP fragment size
is also restricted by protocols such as RADIUS , which are
responsible for transporting EAP messages between an
authenticator and an EAP server. RADIUS can generally
transport only about 4000 octets of EAP in a single
message (the maximum length of a RADIUS packet is
restricted to 4096 octets in ).
This document looks at related work and potential
tools available for overcoming the deployment
challenges induced by large certificates and long
certificate chains.
It then discusses the solutions available to overcome
these challenges. Many of the solutions require TLS
1.3 . The IETF has
standardized EAP-TLS 1.3 and
is working on specifications such as for how other TLS-based EAP
methods use TLS 1.3.
Terminology
The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be
interpreted as described in BCP 14 when, and only
when, they appear in all capitals, as shown here.
Readers are expected to be familiar with the terms and
concepts used in EAP , EAP-TLS , and TLS . In particular, this document
frequently uses the following terms as they have been
defined in :
Authenticator:
The entity initiating EAP
authentication. Typically implemented
as part of a network switch or a
wireless access point.
EAP peer:
The entity that responds to the
authenticator. In , this entity is
known as the supplicant. In EAP-TLS,
the EAP peer implements the TLS client
role.
EAP server:
The entity that terminates the EAP
authentication method with the
peer. In the case where no backend
authentication server is used, the EAP
server is part of the
authenticator. In the case where the
authenticator operates in pass-through
mode, the EAP server is located on the
backend authentication server. In
EAP-TLS, the EAP server implements the
TLS server role.
The document additionally uses the terms "trust anchor" and "certification path" defined in .
Experience with Deployments
As stated earlier, the EAP fragment size in typical deployments is just 1020 - 1500 octets. A certificate can, however, be large for a number of reasons:
It can have a long Subject Alternative Name field.
It can have long Public Key and Signature fields.
It can contain multiple object identifiers (OIDs) that indicate the
permitted uses of the certificate as noted in . Most implementations verify the
presence of these OIDs for successful authentication.
It can contain multiple organization naming fields to reflect the
multiple group memberships of a user (in a client certificate).
A certificate chain (called a certification path in
) in EAP-TLS
can commonly have 2 - 6 intermediate certificates
between the end-entity certificate and the trust
anchor.
The size of certificates (and certificate chains) may
also increase manyfold in the future with the
introduction of post-quantum cryptography. For
example, lattice-based cryptography would have public
keys of approximately 1000 bytes and signatures of
approximately 2000 bytes.
Many access point implementations drop EAP sessions
that do not complete within 40 - 50 round trips. This
means that if the chain is larger than ~ 60 kilobytes,
EAP-TLS authentication cannot complete successfully in
most deployments.
Handling of Large Certificates and Long Certificate Chains
This section discusses some possible alternatives for overcoming the challenge of large certificates and long certificate chains in EAP-TLS authentication. considers recommendations that require an update of the certificates or certificate chains used for EAP-TLS authentication without requiring changes to the existing EAP-TLS code base. It also provides some guidelines that should be followed when issuing certificates for use with EAP-TLS. considers recommendations that rely on updates to the EAP-TLS implementations and can be deployed with existing certificates. Finally, briefly discusses what could be done to update or reconfigure authenticators when it is infeasible to replace deployed components giving a solution that can be deployed without changes to existing certificates or code.
Updating Certificates and Certificate Chains
Many IETF protocols now use elliptic curve cryptography (ECC) for the underlying cryptographic operations. The use of ECC can reduce the size of certificates and signatures. For example, 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 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 64 bytes with the elliptic curve digital signature algorithm (ECDSA) and the Edwards-curve digital signature algorithm (EdDSA) . Using certificates that use ECC can reduce the number of messages in EAP-TLS authentication, which can alleviate the problem of authenticators dropping an EAP session because of too many round trips. In the absence of a standard application profile specifying otherwise, TLS 1.3 requires implementations to support ECC. New cipher suites that use ECC are also specified for TLS 1.2 . Using ECC-based cipher suites with existing code can significantly reduce the number of messages in a single EAP session.
Guidelines for CertificatesThe general guideline of keeping the certificate size small by not populating fields with excessive information can help avert the problems of failed EAP-TLS authentication. More specific recommendations for certificates used with EAP-TLS are as follows:
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 of integers, is then used to name objects to which
they relate. The Distinguished Encoding Rules (DER) specify
that the first two integers always occupy one octet and
subsequent integers are base-128 encoded in the fewest
possible octets. OIDs are used lavishly in X.509 certificates
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 (Distinguished Name) has one. DNs
are used in the issuer and subject fields as well as numerous
extensions. A shallower name will be smaller, e.g., C=FI,
O=Example, SN=B0A123499EFC as against C=FI, O=Example,
OU=Division 1, SOPN=Southern Finland, CN=Coolest IoT Gadget
Ever, and SN=B0A123499EFC.
Every certificate policy (and qualifier) and any mappings to
another policy uses identifiers. Consider carefully what
policies apply.
DirectoryString and GeneralName types are used extensively to
name things, e.g., the DN naming attribute O= (the
organizational naming attribute) DirectoryString includes
"Example" for the Example organization and
uniformResourceIdentifier can be used to indicate the location
of the Certificate Revocation List (CRL), e.g.,
"http://crl.example.com/sfig2s1-128.crl", in the CRL
Distribution Point extension. For these particular examples,
each character is a single byte. For some non-ASCII character
strings, characters can be several bytes. Obviously, the names
need to be unique, but there is more than one way to
accomplish this without long strings. This is especially true
if the names are not meant to be meaningful to users.
Extensions are necessary to comply with , but the vast majority are
optional. Include only those that are necessary to operate.
As stated earlier, certificate chains of the EAP peer often
follow organizational hierarchies. In such cases, information in
intermediate certificates (such as postal addresses) do not
provide any additional value and they can be shortened (for
example, only including the department name instead of the full
postal address).
Pre-distributing and Omitting CA Certificates
The TLS Certificate message conveys the sending endpoint's
certificate chain. TLS allows endpoints to reduce the size of
the Certificate message by omitting certificates that the
other endpoint is known to possess. When using TLS 1.3, all
certificates that specify a trust anchor known by the other
endpoint may be omitted (see ). When using TLS 1.2 or
earlier, only the self-signed certificate that specifies the
root certificate authority may be omitted (see ).
Therefore, updating TLS implementations to version 1.3 can
help to significantly reduce the number of messages exchanged
for EAP-TLS authentication. The omitted certificates need to
be pre-distributed independently of TLS, and the TLS
implementations need to be configured to omit these
pre-distributed certificates.
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 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 (in bytes) by 1020 bytes will indicate
the number of round trips required. If this number exceeds 50,
then administrators can expect failures with many common authenticator
implementations.
Updating TLS and EAP-TLS CodeThis section discusses how the fragmentation problem can be avoided by updating the underlying TLS or EAP-TLS implementation. Note that in some cases, the new feature may already be implemented in the underlying library and simply needs to be enabled.URLs for Client Certificates defines the "client_certificate_url" extension, which allows TLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate chain. URLs can refer to a single certificate or a certificate chain. Using this extension can curtail the amount of fragmentation in EAP deployments thereby allowing EAP sessions to successfully complete.
Caching Certificates
The TLS Cached Information Extension specifies an extension where a server can exclude transmission of certificate information cached in an earlier TLS handshake. The client and the server would first execute the full TLS handshake. The client would then cache the certificate provided by the server. When the TLS client later connects to the same TLS server without using session resumption, it can attach the "cached_info" extension to the ClientHello message. This would allow the client to indicate that it has cached the certificate. The client would also include a fingerprint of the server certificate chain. If the server's certificate has not changed, then the server does not need to send its certificate and the corresponding certificate chain again. In case information has changed, which can be seen from the fingerprint provided by the client, the certificate payload is transmitted to the client to allow the client to update the cache. The extension, however, necessitates a successful full handshake before any caching. This extension can be useful when, for example, a successful authentication between an EAP peer and EAP server has occurred in the home network. If authenticators in a roaming network are stricter at dropping long EAP sessions, an EAP peer can use the Cached Information Extension to reduce the total number of messages.
However, if all authenticators drop the EAP session for a given EAP peer and EAP server combination, a successful full handshake is not possible. An option in such a scenario would be to cache validated certificate chains even if the EAP-TLS exchange fails, but such caching is currently not specified in .
Compressing Certificates
The TLS Working Group has standardized an extension for TLS 1.3 that allows compression of
certificates and certificate chains during full handshakes. The client
can indicate support for compressed server certificates by including
this extension in the ClientHello message. Similarly, the server can
indicate support for compression of client certificates by including
this extension in the CertificateRequest message. While such an
extension can alleviate the problem of excessive 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 benefit
from this extension.
Compact TLS 1.3 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 a dictionary of "known certificates". Thus, cTLS could provide another mechanism for EAP-TLS deployments to reduce the size of messages and avoid excessive fragmentation.
Suppressing Intermediate Certificates
For a client that has all intermediate certificates in the certificate chain, having the server send intermediates in the TLS handshake increases the size of the handshake unnecessarily. proposes an extension for TLS 1.3 that allows a TLS client that has access to the complete set of published intermediate certificates to inform servers of this fact so that the server can avoid sending intermediates, reducing the size of the TLS handshake. The mechanism is intended to be complementary with certificate compression.
The Authority Information Access (AIA)
extension specified in
can be used with end-entity and CA
certificates to access information
about the issuer of the certificate in
which the extension appears. For
example, it can be used to provide the
address of the Online Certificate
Status Protocol (OCSP) responder from
where revocation status of the
certificate (in which the extension
appears) can be checked. It can also
be used to obtain the issuer
certificate. Thus, the AIA extension
can reduce the size of the certificate
chain by only including a pointer to
the issuer certificate instead of
including the entire issuer
certificate. However, it requires the
side receiving the certificate
containing the extension to have
network connectivity (unless the
information is already cached
locally). Naturally, such indirection
cannot be used for the server
certificate (since EAP peers in most
deployments do not have network
connectivity before authentication and
typically do not maintain an
up-to-date local cache of issuer
certificates).
Raw Public Keys defines a new
certificate type and TLS extensions to
enable the use of raw public keys for
authentication. Raw public keys use
only a subset of information found in
typical certificates and are 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. Naturally, deployments
will also need to consider the
challenges of revocation and key
rotation with the use of raw public
keys.
New Certificate Types and Compression Algorithms
There is ongoing work to specify new certificate types that are
smaller than traditional X.509 certificates. For example,
defines a Concise Binary Object Representation (CBOR) encoding of X.509
Certificates. The CBOR encoding can be used to compress existing X.509
certificates or for natively signed CBOR certificates. registers a new TLS
Certificate type that would enable TLS implementations to use CBOR
Web Tokens (CWTs) 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.
Updating Authenticators
There are several legitimate reasons that authenticators may want to
limit the number of packets / octets / round trips that can be sent. The
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
reason is that unlimited communication from an unauthenticated device
using EAP could provide a channel for inappropriate bulk data
transfer. A third reason is to prevent denial-of-service attacks.
Updating the millions of already deployed
access points and switches is in many cases
not realistic. Vendors may be out of business
or no longer supporting the products and
administrators may have lost the login
information to the devices. For practical
purposes, the EAP infrastructure is ossified
for the time being.
Vendors making new authenticators should
consider increasing the number of round trips
allowed to 100 before denying the EAP
authentication to complete. Based on the size
of the certificates and certificate chains
currently deployed, such an increase would
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
round-trip limit is not exceeded in practice.
IANA ConsiderationsThis document has no IANA actions.Security Considerations
Updating implementations to TLS version 1.3 allows
omitting all certificates with a trust anchor known by
the other endpoint. TLS 1.3 additionally provides
improved security, privacy, and reduced latency for
EAP-TLS .
Security considerations when compressing certificates
are specified in .
Specific security considerations of the referenced
documents apply when they are taken into use.
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Extensible Authentication Protocol (EAP)This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. This memo provides information for the Internet community.The EAP-TLS Authentication ProtocolThe Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. This memo provides information for the Internet community.Tunnel Extensible Authentication Protocol (TEAP) Version 1This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3Informative ReferencesCBOR Encoded X.509 Certificates (C509 Certificates)RISE ABRISE ABEricsson ABEricsson ABNexus GroupWork in ProgressCompact TLS 1.3MozillaCiscoArm Limited This document specifies a "compact" version of TLS 1.3. It is
isomorphic to TLS 1.3 but saves space by trimming obsolete material,
tighter encoding, a template-based specialization technique, and
alternative cryptographic techniques. cTLS is not directly
interoperable with TLS 1.3, but it should eventually be possible for
a cTLS/TLS 1.3 server to exist and successfully interoperate.
Work in ProgressIEEE Standard for Local and Metropolitan Area NNetworks--Port-Based Network Access ControlIEEE[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)Microsoft CorporationRemote Authentication Dial In User Service (RADIUS)This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]Transport Layer Security (TLS) Extensions: Extension DefinitionsThis document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]Fundamental Elliptic Curve Cryptography AlgorithmsThis note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.Transport Layer Security (TLS) Cached Information ExtensionTransport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.Edwards-Curve Digital Signature Algorithm (EdDSA)This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.CBOR Web Token (CWT)CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and EarlierThis document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.This document obsoletes RFC 4492.TLS Certificate CompressionIn TLS handshakes, certificate chains often take up the majority of the bytes transmitted.This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips.Concise Binary Object Representation (CBOR)The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)Arm LimitedArm Limited The TLS protocol supports different credentials, including pre-shared
keys, raw public keys, and X.509 certificates. For use with public
key cryptography developers have to decide between raw public keys,
which require out-of-band agreement and full-fletched X.509
certificates. For devices where the reduction of code size is
important it is desirable to minimize the use of X.509-related
libraries. With the CBOR Web Token (CWT) a structure has been
defined that allows CBOR-encoded claims to be protected with CBOR
Object Signing and Encryption (COSE).
This document registers a new value to the "TLS Certificate Types"
sub-registry to allow TLS and DTLS to use CWTs. Conceptually, CWTs
can be seen as a certificate format (when with public key
cryptography) or a Kerberos ticket (when used with symmetric key
cryptography).
Work in ProgressTLS-based EAP types and TLS 1.3FreeRADIUSWork in ProgressSuppressing Intermediate Certificates in TLSMozilla A TLS client that has access to the complete set of published
intermediate certificates can inform servers of this fact so that the
server can avoid sending intermediates, reducing the size of the TLS
handshake.
Work in ProgressAcknowledgements
This document is a result of several useful discussions with
, , , , , and .
Authors' AddressesEricssonJorvas02420Finlandmohit@iki.fiEricssonKistaSwedenjohn.mattsson@ericsson.comsn3rdsean@sn3rd.com