<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>
<?rfc docmapping="yes"?>

<rfc ipr="pre5378Trust200902" docName="draft-tschofenig-tls-cwt-02" category="std">

  <front>
    <title abbrev="CWTs in TLS/DTLS">Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>

    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Arm Limited</organization>
      <address>
        <email>hannes.tschofenig@arm.com</email>
      </address>
    </author>
    <author initials="M." surname="Brossard" fullname="Mathias Brossard">
      <organization>Arm Limited</organization>
      <address>
        <email>Mathias.Brossard@arm.com</email>
      </address>
    </author>

    <date year="2020" month="July" />

    <area>Security</area>
    <workgroup>TLS</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>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).</t>

<t>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).</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The CBOR Web Token (CWT) <xref target="RFC8392"/> was defined as the CBOR-based version of the JSON Web Token (JWT) <xref target="RFC7519"/>. 
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 <xref target="RFC8152"/>. 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 <xref target="I-D.ietf-ace-cwt-proof-of-possession"/>. 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.</t>

<t>Fundamentally, there are two types of keys that can be used with CWTs:</t>

<t><list style="symbols">
  <t>Asymmetric keys: In this case a CWT contains a COSE_Key <xref target="RFC8152"/> representing
an asymmetric public key. To protect the CWT against modifications the CWT also needs to be digitally signed.</t>
  <t>Symmetric keys: In this case a CWT contains the Encrypted_COSE_Key <xref target="RFC8152"/> 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.</t>
</list></t>

<t>The CWT also allows mixing symmetric and asymmetric crypto although this is less likely to be used in practice.</t>

<t>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.</t>

</section>
<section anchor="conventions-and-terminology" title="Conventions and Terminology">

<t>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 <xref target="RFC2119"/>.</t>

</section>
<section anchor="the-cwt-certificate-type" title="The CWT Certificate Type">

<t>This document defines a new value to the “TLS Certificate Types” sub-registry and 
the value is defined as follows.</t>

<figure><artwork><![CDATA[
     /* Managed by IANA */
      enum {
          X509(0),
          RawPublicKey(2),
          CWT(TBD),
          (255)
      } CertificateType;

      struct {
          select (certificate_type) {

              /* CWT "certificate type" defined in this document.*/
               case CWT:
               opaque cwt_data<1..2^24-1>;

               /* RawPublicKey defined in RFC 7250*/
              case RawPublicKey:
              opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;

              /* X.509 certificate defined in RFC 5246*/
              case X.509:
              opaque cert_data<1..2^24-1>;

               };

             Extension extensions<0..2^16-1>;
      } CertificateEntry;
]]></artwork></figure>

</section>
<section anchor="representation-and-verification-the-identity-of-application-services" title="Representation and Verification the Identity of Application Services">

<t>RFC 6125 <xref target="RFC6125"/> 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.</t>

<t>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).</t>

<t>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.</t>

<t>Note: Verification of the Not Before and the Expiration Time claims 
MUST be performed to determine the validity of the received CWT.</t>

</section>
<section anchor="sec-cons" title="Security and Privacy Considerations">

<t>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.</t>

<t>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 <xref target="RFC7925"/> and <xref target="RFC7525"/>.</t>

<t>CWTs without proof-of-possession keys MUST NOT be used.</t>

<t>When CWTs are used with TLS 1.3 <xref target="RFC8446"/> and DTLS 1.3 <xref target="I-D.ietf-tls-dtls13"/>
additional privacy properties are provided since most handshake messages are encrypted.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>IANA is requested to add a new value to the “TLS Certificate Types” sub-registry 
for CWTs.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In 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.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference anchor="I-D.ietf-tls-dtls13">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<author initials='N' surname='Modadugu' fullname='Nagendra Modadugu'>
    <organization />
</author>

<date month='October' day='11' year='2019' />

<abstract><t>This 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.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-dtls13-33' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls13-33.txt' />
</reference>



<reference anchor="I-D.ietf-ace-cwt-proof-of-possession">
<front>
<title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)</title>

<author initials='M' surname='Jones' fullname='Michael Jones'>
    <organization />
</author>

<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
    <organization />
</author>

<author initials='G' surname='Selander' fullname='Goeran Selander'>
    <organization />
</author>

<author initials='S' surname='Erdtman' fullname='Samuel Erdtman'>
    <organization />
</author>

<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
    <organization />
</author>

<date month='October' day='31' year='2019' />

<abstract><t>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.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-ace-cwt-proof-of-possession-11' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-ace-cwt-proof-of-possession-11.txt' />
</reference>


<reference  anchor="RFC8446" target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2018' month='August' />
<abstract><t>This 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.</t><t>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.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>



<reference  anchor="RFC7250" target='https://www.rfc-editor.org/info/rfc7250'>
<front>
<title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
<author initials='P.' surname='Wouters' fullname='P. Wouters' role='editor'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig' role='editor'><organization /></author>
<author initials='J.' surname='Gilmore' fullname='J. Gilmore'><organization /></author>
<author initials='S.' surname='Weiler' fullname='S. Weiler'><organization /></author>
<author initials='T.' surname='Kivinen' fullname='T. Kivinen'><organization /></author>
<date year='2014' month='June' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='RFC' value='7250'/>
<seriesInfo name='DOI' value='10.17487/RFC7250'/>
</reference>



<reference  anchor="RFC8152" target='https://www.rfc-editor.org/info/rfc8152'>
<front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></author>
<date year='2017' month='July' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='RFC' value='8152'/>
<seriesInfo name='DOI' value='10.17487/RFC8152'/>
</reference>



<reference  anchor="RFC8392" target='https://www.rfc-editor.org/info/rfc8392'>
<front>
<title>CBOR Web Token (CWT)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<author initials='E.' surname='Wahlstroem' fullname='E. Wahlstroem'><organization /></author>
<author initials='S.' surname='Erdtman' fullname='S. Erdtman'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2018' month='May' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='RFC' value='8392'/>
<seriesInfo name='DOI' value='10.17487/RFC8392'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC7519" target='https://www.rfc-editor.org/info/rfc7519'>
<front>
<title>JSON Web Token (JWT)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<author initials='J.' surname='Bradley' fullname='J. Bradley'><organization /></author>
<author initials='N.' surname='Sakimura' fullname='N. Sakimura'><organization /></author>
<date year='2015' month='May' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='RFC' value='7519'/>
<seriesInfo name='DOI' value='10.17487/RFC7519'/>
</reference>



<reference  anchor="RFC7925" target='https://www.rfc-editor.org/info/rfc7925'>
<front>
<title>Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things</title>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig' role='editor'><organization /></author>
<author initials='T.' surname='Fossati' fullname='T. Fossati'><organization /></author>
<date year='2016' month='July' />
<abstract><t>A 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.</t><t>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.</t></abstract>
</front>
<seriesInfo name='RFC' value='7925'/>
<seriesInfo name='DOI' value='10.17487/RFC7925'/>
</reference>



<reference  anchor="RFC7525" target='https://www.rfc-editor.org/info/rfc7525'>
<front>
<title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
<author initials='Y.' surname='Sheffer' fullname='Y. Sheffer'><organization /></author>
<author initials='R.' surname='Holz' fullname='R. Holz'><organization /></author>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'><organization /></author>
<date year='2015' month='May' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='BCP' value='195'/>
<seriesInfo name='RFC' value='7525'/>
<seriesInfo name='DOI' value='10.17487/RFC7525'/>
</reference>



<reference  anchor="RFC6125" target='https://www.rfc-editor.org/info/rfc6125'>
<front>
<title>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)</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'><organization /></author>
<author initials='J.' surname='Hodges' fullname='J. Hodges'><organization /></author>
<date year='2011' month='March' />
<abstract><t>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]</t></abstract>
</front>
<seriesInfo name='RFC' value='6125'/>
<seriesInfo name='DOI' value='10.17487/RFC6125'/>
</reference>




    </references>


<section anchor="history" title="History">

<t>RFC EDITOR: PLEASE REMOVE THE THIS SECTION</t>

<t><list style="symbols">

  <t>-01: Minor editorial bugfixes and reference updates; refreshing draft</t>

  <t>-00: Initial version</t>
</list></t>

</section>
<section anchor="working-group-information" title="Working Group Information">

<t>The discussion list for the IETF TLS working group is located at the e-mail
address <eref target="mailto:tls@ietf.org">tls@ietf.org</eref>. Information on the group and information on how to
subscribe to the list is at <eref target="https://www1.ietf.org/mailman/listinfo/tls">https://www1.ietf.org/mailman/listinfo/tls</eref></t>

<t>Archives of the list can be found at:
<eref target="https://www.ietf.org/mail-archive/web/tls/current/index.html">https://www.ietf.org/mail-archive/web/tls/current/index.html</eref></t>

</section>


  </back>


</rfc>

