TLS handshake message exchange with SupplementalData [SuppData]

            
            
     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

2.3. Overview of authorization extensions

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

RFC5878 [AUTHZ] defines two authorization extension types that are used in the ClientHello and ServerHello messages and are repeated below for convenience. RFC5878 [AUTHZ] also establishes a registry that is maintained by IANA for registering authorization data formats. This document defines a new authorization data type that is used in both the client_authz and server_authz extensions and allows the client and server to exchange DTCP certificates in the SupplementalData message.

2.4. Overview of supplemental data usage for authorization

              
              
       enum {
          authz_data(16386), (65535)
       } SupplementalDataType;
      
       struct {
          SupplementalDataType supplemental_data_type;
          select(SupplementalDataType) {
             case authz_data:  AuthorizationData;
          }
       } SupplementalData;              
              
              
            

Section 3 of RFC5878 [AUTHZ] specifies the syntax of the supplemental data message when carrying the authz_data message that is negotiated in the client_authz and/or server_authz types. The syntax is repeated here for convenience.

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(TBA); 
       
                    
        

3.2. DTCP Authorization Data

The DTCP Authorization data SHALL be sent in the authz_data message when the authorization data type is dtcp_authorization. The syntax of the authorization data is:

            
            
      struct {          
          opaque random_bytes[32];
      } RandomNonce;

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

RandomNonce - consists of 32 bytes generated by a secure random number generator. The dtcp_authz_data message MUST always contain a RandomNonce to avoid replay attacks.

If the ASN.1 Certificate is being sent in the structure above, it MUST be the same as the sender's certificate that will be sent in the Certificate or ClientCertificate message.

DigitallySigned - contains the DTCP Certificate and the optional ASN.1 Certificate. This is then followed by a digital signature covering the DTCP Certificate and the ASN.1 certificate if it is present. The signature is generated using the private key associated with the DTCP certificate using an Elliptic Curve Digital Signature Algorithm (EC-DSA) as specified in [DTCP]. This signature provides proof of the possession of the private key by the sender. A sender sending its own DTCP Certificate MUST populate the certs field.

3.3. Usage rules for clients to exchange DTCP Authorization data

A client MUST include both the client_authz and server_authz extensions in the extended client hello message when indicating its desire to exchange DTCP authorization data with the server. Additionally the client MUST use the authorization data type specified in Section 3.1 in the extension_data field to specify the format of the authorization data. A client will receive the server's dtcp_authz_data before it sends its own dtcp_authz_data. When sending its own dtcp_authz_data message, the client MUST use the same RandomNonce that it received in the server's dtcp_authz_data message. A client MAY include its ASN.1 Certificate in the certs field to cryptographically tie its dtcp_authz_data with the TLS session being established.

3.4. Usage rules for servers to exchange DTCP Authorization data

A server MUST respond with both the client_authz and server_authz extensions in the extended server hello message when indicating its desire to exchange dtcp_authorization data with the client. Additionally the server MUST use the authorization data type specified in Section 3.1 in the extension_data field to specify the format of the dtcp_authorization data. A server MUST generate and populate the RandomNonce in the dtcp_authz_data message. If the client's hello message does not contain both the client_authz and server_authz extensions with dtcp_authorization type, the server SHALL NOT include support for dtcp_authorization data in its hello message. A server MAY include its ASN.1 Certificate in the certs field to cryptographically tie its dtcp_authz_data with the TLS session being established.

3.5. Alert Messages

This document reuses TLS Alert messages for any errors that arise during authorization processing, while preserving the AlertLevels as specified in [AUTHZ]. Additionally the following AlertDescription values SHALL be used to report errors in dtcp_authorization processing:

            
        
        unsupported_extension:
          In dtcp_authorization processing a client uses this when 
          it receives a server hello message that indicates support
          for only one of client_authz or server_authz extension.
          This message is always fatal.
        
                        
          

4. Acknowledgements

This document derives its structure and much of its content from [SuppData], [AUTHZ] and [RFC6042].

5. IANA Considerations

This document requires a new entry in the IANA-maintained TLS Authorization Data Formats registry, dtcp_authorization(TBA). This registry is defined in [AUTHZ].

6. Security Considerations

In cases where the SupplementalData information is sensitive, the double handshake technique described in [SuppData] can be used to provide protection for the SupplementalData information. The double handshake specified in [SuppData] assumes that the client knows the context of the TLS session that is being set up and uses the authorization extensions as needed. Figure 2 illustrates a variation of the double handshake that addresses the case where the client may not have a priori knowledge that it will be communicating with a server capable of exchanging dtcp_authz_data (typical for https usages based on [RFC2818]). In Figure 2 [sd_double_exchange] below client's Hello messages always include support for the client_authz and server_authz extensions. The server simply establishes an encrypted TLS tunnel with the client in the first handshake by not indicating support for any authz extensions. The server initiates a second handshake by sending a HelloRequest. The second handshake will include server's support for authz extensions which will result in SupplementalData being exchanged.

The double handshake mechanism is vulnerable to the TLS MITM Renegotiation exploit as explained in [RFC5746]. In order to address this vulnerability, clients and servers MUST use the secure_renegotiation extension as specified in [RFC5746] when performing a double 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.