RFC 7562

Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates

📅 published July 2015, from ietf

Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates ✨

Okay, title block tea 🫖: this is an Independent Submission, so it's not coming from an IETF working group. It's RFC 7562 (ISSN 2070-1721), written by D. Thakore from CableLabs, dated July 2015. The category is Informational, which means it's published for info and is not a Standards Track spec 💅. The title block doesn't list anything it obsoletes or updates, so no drama there. 🌸

Abstract

Okay so this doc is all about using DTCP certificates as an authorization data type inside the authorization extension for TLS 🔐. It follows the guidelines for authorization extensions in RFC 5878, so it's giving consistency. Like other TLS extensions, this authorization data can ride along in the client and server hello messages to confirm that both sides support the authorization data types they want 🤝. If both the client and the server support it, the DTCP certificates get exchanged in the supplemental data TLS handshake message from RFC 4680 ✨. This whole extension exists for devices carrying DTCP certificates issued by the Digital Transmission Licensing Administrator (DTLA) 📺.

Status of This Memo

Not gonna lie, this part is the legal-ish bit, but it's important 🙈. This document is not an Internet Standards Track specification. It's published for informational purposes 🎀.

It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about its value for implementation or deployment. Docs the RFC Editor approves for publication aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741 🦋.

You can find info about the current status of this doc, any errata, and how to give feedback at http://www.rfc-editor.org/info/rfc7562 🔗.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions with respect to this document 📜.

Table of Contents

   1. Introduction ....................................................3
      1.1. Applicability Statement ....................................3
      1.2. Conventions ................................................4
   2. Overview ........................................................4
      2.1. Overview of DTCP Certificates ..............................4
      2.2. Overview of SupplementalData Handshake .....................5
      2.3. Overview of Authorization Extensions .......................5
      2.4. Overview of SupplementalData Usage for Authorization .......6
   3. DTCP Authorization Data Format ..................................6
      3.1. DTCP Authorization Type ....................................6
      3.2. DTCP Authorization Data ....................................6
      3.3. Usage Rules for Clients to Exchange DTCP
           Authorization Data .........................................7
      3.4. Usage Rules for Servers to Exchange DTCP
           Authorization Data .........................................8
      3.5. TLS Message Exchange with dtcp_authz_data ..................8
      3.6. Alert Messages .............................................9
   4. IANA Considerations ............................................10
   5. Security Considerations ........................................10
   6. References .....................................................11
      6.1. Normative References ......................................11
      6.2. Informative References ....................................12
   Appendix A. Alternate Double Handshake Example ....................13
   Acknowledgements ..................................................15
   Author's Address ..................................................15

1. Introduction ✨

Okay so TLS (see TLS 1.0 [RFC2246], TLS 1.1 [RFC4346], and TLS1 .2 [RFC5246]) is showing up in an ever-increasing variety of operational environments 🌍. The most common one is securing HTTP traffic [RFC2818], which is iconic. [RFC5878] adds extensions so TLS can work in places where authorization info needs to be swapped between client and server before any protected data moves 🔑. The lowkey best part is that it lets the client and server pick what kind of protected data to exchange based on the authorization info they got in those extensions 🫶.

A huge pile of consumer electronics, like TVs, tablets, game consoles, set-top boxes, and other multimedia devices, carry Digital Transmission Content Protection [DTCP] certificates issued by [DTLA] 📺✨. These certs make secure transmission of premium audiovisual content possible between devices over different kinds of links (for example, DTCP over IP [DTCP-IP]). They can also be used to verify device functionality, like which device features are supported 🧚.

This doc describes the format and the identifiers needed to exchange DTCP certificates inside the supplemental data message (see [RFC4680]) while a TLS session is being negotiated 💖. The DTCP certificates are then used separately from content protection (for example, to verify supported features) and from the corresponding DTCP Authentication and Key Exchange (AKE) protocol 🌈. This communication lets the client, the server, or both do certain actions or provide specific services 👑. The actual semantics of the client/server authorization decision are beyond the scope of this document 🙈. Also, the DTCP certificate isn't an X.509 certificate, but it can be cryptographically tied to the X.509 certificate used while the TLS tunnel is being set up, using an Elliptic Curve Digital Signature Algorithm (EC-DSA) [DTCP] signature 🔐.

1.1. Applicability Statement

DTCP-enabled consumer electronics devices (like TVs and game consoles) use DTCP certificates to securely transmit audiovisual content 📺. The AKE protocol defined in [DTCP] is used to exchange DTCP certificates, and it lets a device be identified and authenticated based on the info inside its DTCP certificate 🪪. BUT these DTCP-enabled devices also do extra stuff, like HTML5 User Agents or web-enabled apps, which is totally separate from transmitting and playing audiovisual content 🎀. The mechanism in this doc lets a DTCP-enabled consumer electronics device authenticate and authorize itself with its DTCP certificate when it accesses services over the internet. For example, web apps on TVs that enable value-added services 💅. This is expected to be super valuable since there are a considerable number of these devices 🤩. Reusing well-known web security also keeps this communication consistent with existing standards and best practices 🌸.

1.2. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These are the BCP 14 key words, so they're the ones with the real weight, babe 💜.

2. Overview 🦋

2.1. Overview of DTCP Certificates

DTCP certificates issued by [DTLA] to DTLA-compliant devices come in three general variations (see Section 4.2.3.1 of [DTCP]) 🎀:

  • Restricted Authentication device certificate format (Format 0): Typically issued to devices with limited computation resources.
  • Baseline Full Authentication device certificate format (Format 1): This is the most commonly issued certificate format. Format 1 certificates include a unique DeviceID and device EC-DSA public/private key pair generated by the DTLA. (See Section 4.3 of [DTCP].)
  • Extended Full Authentication device certificate format (Format 2): This is issued to devices that have additional functions (for example, additional channel ciphers or specific device properties). The presence of these additional functions is indicated by the device capability mask as specified in Section 4.2.3.2 of [DTCP]. Format 2 certificates also include a unique DeviceID and device EC-DSA public/private key pair generated by the DTLA (see Section 4.3 of [DTCP]) ✨.

Here's the catch: the mechanism in this doc only lets Formats 1 and 2 DTCP certificates be exchanged in the supplemental data message, because it needs the EC-DSA private key associated with the certificate 🔑. Format 0 is out, bestie 💀.

2.2. Overview of SupplementalData Handshake

Figure 1 shows the SupplementalData message being exchanged during the TLS handshake, as specified in [RFC4680] (repeated here for convenience) 📊:

     Client                                               Server

     ClientHello (with extensions) -------->

                                    ServerHello(with extensions)
                                               SupplementalData*
                                                    Certificate*
                                              ServerKeyExchange*
                                             CertificateRequest*
                                  <--------      ServerHelloDone

     SupplementalData*
     Certificate*
     ClientKeyExchange
     CertificateVerify*
     [ChangeCipherSpec]
     Finished                     -------->
                                              [ChangeCipherSpec]
                                  <--------             Finished
     Application Data             <------->     Application Data

     *  Indicates optional or situation-dependent messages that are
        not always sent.

     [] Indicates that ChangeCipherSpec is an independent TLS
        protocol content type; it is not a TLS handshake message.

   Figure 1: TLS Handshake Message Exchange with SupplementalData

2.3. Overview of Authorization Extensions

[RFC5878] defines two authorization extension types that are used in the ClientHello and ServerHello messages. They're repeated below for convenience 🫶:

      enum {
        client_authz(7), server_authz(8), (65535)
      } ExtensionType;

A client uses the client_authz and server_authz extensions in the ClientHello message to say that it will send client authorization data and receive server authorization data, respectively, in the SupplementalData messages. A server uses the extensions in a similar manner in its ServerHello message 💖. [RFC5878] also sets up a registry, maintained by IANA, for registering authorization data formats 📋. This document defines a new authorization data type for both the client_authz and server_authz extensions, which lets the client and server exchange DTCP certificates in the SupplementalData message 🌈.

2.4. Overview of SupplementalData Usage for Authorization

Section 3 of [RFC5878] specifies the syntax of the supplemental data message when it carries the authz_data message negotiated in the client_authz and/or server_authz types 🧾. This document defines a new authorization data format that's used in the authz_data message when sending DTCP Authorization Data 👑.

3. DTCP Authorization Data Format 💅

3.1. DTCP Authorization Type

The DTCP Authorization type definition in the TLS Authorization Data Formats registry is 🎀:

       dtcp_authorization(66);

3.2. DTCP Authorization Data 💖

okay so this is the actual data layout you get when AuthzDataFormat is dtcp_authorization 🎀 here's the syntax:

struct {
    opaque random_bytes[32];
} RandomNonce;

struct {
    opaque RandomNonce nonce;
    opaque DTCPCert<0..2^24-1>;
    opaque ASN.1Cert<0..2^24-1>;
    opaque signature<0..2^16-1>;
} dtcp_authz_data;

the RandomNonce is made by the server 🌸 it's 32 bytes from a high-quality, secure random number generator, and the client ALWAYS sends that same server-made RandomNonce back inside its dtcp_authz_data. the nonce is how the server spots replay attacks 🙈 and the client can catch them too, by matching the ASN.1 certificate in dtcp_authz_data against the one from the Certificate message of the TLS handshake. so the client doesn't need a separate nonce of its own. no extra work, bestie 💅

the DTCPCert is the sender's DTCP certificate. go check Section 4.2.3.1 of the DTCP Specification [DTCP] for the details 🦋

the ASN.1Cert is the sender's certificate that set up the TLS session. basically it's the one sent in the Certificate or ClientCertificate message, using the Certificate structure from Section 7.4.2 of [RFC5246] ✨

both DTCPCert and ASN.1Cert are variable-length vectors, as laid out in Section 4.3 of [RFC5246]. so the actual length shows up first, right before the contents in the byte stream 🧚 and if the ASN.1Cert isn't being sent, the ASN.1Cert_length MUST be zero. no exceptions, periodt 💀

dtcp_authz_data holds the RandomNonce, the DTCP certificate, and the optional ASN.1 certificate. then comes the digital signature, which covers the RandomNonce, the DTCP certificate, and the ASN.1 certificate (if it's there). the signature is made with the private key tied to the DTCP certificate, using the Signature Algorithm and Hash Algorithm from Section 4.4 of [DTCP]. it's the proof that the sender actually has that private key 🔑 A sender sending its own DTCP certificate MUST populate this field. the signature length is set by those same Signature Algorithm and Hash Algorithm, so it isn't encoded explicitly in dtcp_authz_data. (for example, a SHA1+ECDSA combo gives you 40 bytes 🍓)

3.3. Usage Rules for Clients to Exchange DTCP Authorization Data 🫶

a client puts both the client_authz and server_authz extensions in its extended client hello when it wants to swap dtcp_authorization data with the server 🌈 it also puts the AuthzDataFormat type from Section 3.1 in the extension_data field so the format is clear.

the client gets the server's dtcp_authz_data FIRST, then sends its own. when the client sends its dtcp_authz_data, it reuses the same RandomNonce it got from the server's dtcp_authz_data message. Clients MUST include their DTCP certificate in the dtcp_authz_data message ✨ A client MAY include its ASN.1 certificate (the one in its ClientCertificate message) in the ASN.1Cert field of dtcp_authz_data. that's how it cryptographically ties dtcp_authz_data to the ASN.1 certificate that's actually used to set up the TLS session 🔥

3.4. Usage Rules for Servers to Exchange DTCP Authorization Data 👑

a server replies with both the client_authz and server_authz extensions in its extended server hello when it wants to swap dtcp_authorization data with the client 🎀

the server also includes the AuthzDataFormat type from Section 3.1 in the extension_data field, so the dtcp_authorization format is labelled 🦋 here's the tricky bit: a client might or might not send an ASN.1 certificate during the TLS handshake, but the server doesn't know which at the time it sends the SupplementalData message 😭 so a server MUST generate and populate the RandomNonce in the dtcp_authz_data message. if the client's hello doesn't have both client_authz and server_authz extensions with the dtcp_authorization type, the server MUST NOT include support for dtcp_authorization data in its hello message. A server MAY include its DTCP certificate in the dtcp_authz_data message. if it doesn't, it sends only the RandomNonce in dtcp_authz_data 🌸 and if the server DOES include its DTCP certificate, it MUST also include its server certificate (the one sent in the TLS Certificate message) in the certs field. that's what cryptographically ties its dtcp_authz_data to the ASN.1 certificate used in the TLS session being set up. it also helps the client catch replay attacks 🫶

3.5. TLS Message Exchange with dtcp_authz_data 🧚

based on the usage rules above, Figure 2 shows one possible TLS message exchange where the client sends its DTCP certificate to the server inside the dtcp_authz_data message 💜

        Client                                               Server

        ClientHello (with extensions) -------->

                                       ServerHello(with extensions)
                                    SupplementalData(with Nonce N1)
                                                        Certificate
                                                 ServerKeyExchange*
                                                 CertificateRequest
                                     <--------      ServerHelloDone

        SupplementalData(with Data D1)
        Certificate
        ClientKeyExchange
        CertificateVerify
        [ChangeCipherSpec]
        Finished                     -------->
                                                 [ChangeCipherSpec]
                                     <--------             Finished
        Application Data             <------->     Application Data

      N1 Indicates a Random nonce generated by server

      D1 Contains dtcp_authz_data populated with the following
        {(N1, DTCP Cert, Client X.509 Cert) Signature over all elements}

      *  Indicates optional or situation-dependent messages that are
         not always sent.

      [] Indicates that ChangeCipherSpec is an independent TLS
         protocol content type; it is not a TLS handshake message.

                 Figure 2: DTCP SupplementalData Exchange

3.6. Alert Messages 🚨

this doc reuses TLS Alert messages for any errors that pop up during authorization processing, and it reuses the AlertLevels from [RFC5878] too 🍓 on top of that, these AlertDescription values are used to report errors in dtcp_authorization processing:

unsupported_extension: During dtcp_authorization processing, a client uses this when it gets a server hello that supports dtcp_authorization in only one of client_authz or server_authz, but NOT both extensions. this one is always fatal 😬 Note: completely leaving out the dtcp_authorization extension, and/or leaving out client_authz and server_authz entirely, is allowed, and should not be the reason this alert gets sent.

certificate_unknown: During dtcp_authorization processing, a client or server uses this when it has received an X.509 certificate in the dtcp_authorization data, and that X.509 certificate doesn't match the certificate sent in the corresponding ClientCertificate or Certificate message 🙈

4. IANA Considerations 🎀

this doc includes an entry in the IANA-maintained "TLS Authorization Data Formats" registry for dtcp_authorization(66) ✨ that registry is defined in [RFC5878] and has two ranges: IETF Review, and Specification Required. the value for dtcp_authorization should be assigned via [RFC5226] Specification Required. the extension in this doc is compatible with Data Transport Layer Security (DTLS) [RFC6347], and the registry assignment is marked "Y" for DTLS-OK 💖

5. Security Considerations 🔐

okay bestie, this section is SERIOUS so pay attention 👀

the dtcp_authorization data, as specified in this doc, carries the DTCP certificate that identifies the associated device. putting the X.509 certificate used to set up a TLS Session inside dtcp_authorization data lets an application cryptographically tie the two together 🦋 however, a TLS Client is not required to use an X.509 certificate, and it may not even have one. in that case, the dtcp_authorization data exchange is prone to a man-in-the-middle (MITM) attack 😱 in those situations a TLS server MUST deny access to the application features that depend on the DTCP certificate, OR use a double handshake.

the double handshake is also vulnerable to the TLS MITM Renegotiation exploit, as explained in [RFC5746] 💀 to deal with that, clients and servers MUST use the secure_renegotiation extension from [RFC5746] when exchanging dtcp_authorization data. and the renegotiation is ALSO vulnerable to the Triple Handshake exploit 🙈 to mitigate that, servers MUST use the same ASN.1 certificate during renegotiation as the one used in the initial handshake.

it should be noted that for the double handshake to succeed, any extension (for example, TLS Session Ticket [RFC5077]) that changes the TLS handshake sequence may make the exchange of SupplementalData fail 🫠

on top of all that, the security considerations in [RFC5878] and [RFC5246] apply to the extension in this doc 🌈 also, dtcp_authorization data may travel alongside other supplemental data or some other authorization data, and that information might need extra protection. finally, implementers should also check out [DTCP] and [DTCP-IP] for more on DTCP certificates, how they're used, and their security considerations 👑

6. References 📚

6.1. Normative References ✨

6.2. Informative References 📚

Appendix A. Alternate Double Handshake Example 🧚

okay so this bit is about a sneaky way to protect the good stuff 🫶 This document defines a TLS authorization data extension that lets TLS clients and servers swap DTCP certificates during a TLS handshake. Now, if the supplemental data is sensitive, the double handshake trick from [RFC4680] can keep it protected 🔒 That double handshake assumes the client already knows what kind of TLS session it's setting up and uses the authorization extensions when needed.

But here's the twist: sometimes the client has no clue the server can even do dtcp_authz_data. That's super typical for https connections (see [RFC2818]) 😭 So Figure 3 shows a variation that handles this. The client's hello messages include the client_authz and server_authz extensions. The server first sets up an encrypted TLS session without indicating support for any authz extensions. Then it kicks off a second handshake by sending a HelloRequest. That second handshake includes the server's authz support, and that's what gets SupplementalData swapped 💅

There's also another option! The server can send the authorization extensions during both the first and the second handshake. Based on what it receives in the first handshake, the server gets to decide whether it actually needs a second handshake 🦋

  Client                                                   Server

  ClientHello (w/ extensions) -------->                            |0
                                ServerHello (no authz extensions)  |0
                                                     Certificate*  |0
                                               ServerKeyExchange*  |0
                                              CertificateRequest*  |0
                              <--------           ServerHelloDone  |0
  Certificate*                                                     |0
  ClientKeyExchange                                                |0
  CertificateVerify*                                               |0
  [ChangeCipherSpec]                                               |0
  Finished                    -------->                            |1
                                               [ChangeCipherSpec]  |0
                              <--------                  Finished  |1
                              <--------              HelloRequest  |1
  ClientHello (w/ extensions) -------->                            |1
                                      ServerHello (w/ extensions)  |1
                                                SupplementalData*  |1
                                                     Certificate*  |1
                                               ServerKeyExchange*  |1
                                              CertificateRequest*  |1
                              <--------           ServerHelloDone  |1
  SupplementalData*                                                |1
  Certificate*                                                     |1
  ClientKeyExchange                                                |1
  CertificateVerify*                                               |1
  [ChangeCipherSpec]                                               |1
  Finished                    -------->                            |2
                                               [ChangeCipherSpec]  |1
                              <--------                  Finished  |2
  Application Data            <------->          Application Data  |2

  *  Indicates optional or situation-dependent messages.

       Figure 3: Double Handshake to Protect SupplementalData

Acknowledgements 🌸

The author wishes to thank Mark Brown, Sean Turner, Sumanth Channabasappa, and the Chairs (EKR, Joe Saloway) and members of the TLS Working Group who gave feedback and comments on one or more revisions of this document 🫶

This document derives its structure and much of its content from [RFC4680], [RFC5878], and [RFC6042]. literally the main character energy of building on what already works ✨

Author's Address 🎀

D. Thakore Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, CO 80023 United States

Email: d.thakore@cablelabs.com

📦 where this page comes from