Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)Arm Limitedhannes.tschofenig@arm.comArm LimitedMathias.Brossard@arm.com
Security
TLSInternet-DraftThe 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).The CBOR Web Token (CWT) was defined as the CBOR-based version of the JSON Web Token (JWT) .
JWT is used extensively on Web application and for use with Internet of Things environments the believe is that
a more lightweight encoding, namely CBOR, is needed. CWTs, like JWTs, contain claims and those claims are
protected against modifications using COSE . CWTs are flexible with regard to the use of
cryptography and hence CWTs may be protected using a keyed message digest, or a digital signature. One of the
claims allows keys to be included, as described in . This specification
makes use of these proof-of-possession claims in CWTs. This document mandates a minimum number of claims to be present in a CWT. There may, however, be a number of additional claims present in a CWT. An example of a token with a larger number of claims is the Entity Attestation Token (EAT), which may also be encoded as a CWT.Fundamentally, there are two types of keys that can be used with CWTs:Asymmetric keys: In this case a CWT contains a COSE_Key representing
an asymmetric public key. To protect the CWT against modifications the CWT also needs to be digitally signed.Symmetric keys: In this case a CWT contains the Encrypted_COSE_Key structure representing a symmetric key
encrypted to a key known to the recipient using COSE_Encrypt or COSE_Encrypt0. Again, to protect the CWT
against modifications a keyed message digest is used.The CWT also allows mixing symmetric and asymmetric crypto although this is less likely to be used in practice.Exchanging CWTs in the TLS / DTLS handshake offers an alternative to the use of raw
public keys and X.509 certificates. Compared to raw public keys, CWTs allow more information to be included via
the use of claims. Compared to X.509 certificates CBOR offers an alternative encoding format, which may also
be used by the application layer thereby potentially reducing the overall code size requirements.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 RFC 2119 .This document defines a new value to the “TLS Certificate Types” sub-registry and
the value is defined as follows.RFC 6125 provides guidance for matching identifiers used in X.509 certificates
against a reference identifier, i.e. an identifier constructed from a source
domain and optionally an application service type. Different types of identifiers have been
defined over time, such as CN-IDs, DNS-IDs, SRV-IDs, and URI-IDs, and they may be carried
in different fields inside the X.509 certificate, such as in the Common Name or in the
subjectAltName extension.For CWTs issued to servers the following rule applies: To claim conformance with this
specification an implementation MUST populate the Subject claim
with the value of the Server Name Indication (SNI) extension. The Subject claim is of type
StringOrURI. If it is string an equality match is used between the Subject claim value and the SNI.
If the value contains a URI then the URI schema must be matched against the service being requested
and the remaining part of the URI is matched against the SNI in an equality match (since the SNI
only defines Hostname types).For CWTs issued to clients the application service interacting with the TLS/DTLS stack on the
server side is responsible for authenticating the client. No specific rules apply but the
Subject and the Audience claims are likely to be good candidates for authorization policy checks.Note: Verification of the Not Before and the Expiration Time claims
MUST be performed to determine the validity of the received CWT.The security and privacy characteristics of this extension are best described
in relationship to certificates (when asymmetric keys are used) and to Kerberos
tickets (when symmetric keys are used) since the main difference is in the
encoding.When creating proof-of-possession keys the recommendations for state-of-the-art
key sizes and algorithms have to be followed. For TLS/DTLS those algorithm
recommendations can be found in and .CWTs without proof-of-possession keys MUST NOT be used.When CWTs are used with TLS 1.3 and DTLS 1.3
additional privacy properties are provided since most handshake messages are encrypted.IANA is requested to add a new value to the “TLS Certificate Types” sub-registry
for CWTs.Key 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.The Datagram Transport Layer Security (DTLS) Protocol Version 1.3This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol.Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)This specification describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of- possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and CWTs rather than JSON and JWTs.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.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.CBOR Object Signing and Encryption (COSE)Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.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.JSON Web Token (JWT)JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of ThingsA common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]RFC EDITOR: PLEASE REMOVE THE THIS SECTION-01: Minor editorial bugfixes and reference updates; refreshing draft-00: Initial versionThe discussion list for the IETF TLS working group is located at the e-mail
address tls@ietf.org. Information on the group and information on how to
subscribe to the list is at https://www1.ietf.org/mailman/listinfo/tlsArchives of the list can be found at:
https://www.ietf.org/mail-archive/web/tls/current/index.html