idnits 2.17.1 draft-dthakore-tls-authz-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: 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. -- The document date (October 15, 2012) is 4211 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 138, but not defined -- Looks like a reference, but probably isn't: '32' on line 208 == Unused Reference: 'RFC2629' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 334, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Thakore 3 Internet-Draft CableLabs 4 Intended status: Informational October 15, 2012 5 Expires: April 18, 2013 7 Transport Layer Security (TLS) Authorization Using DTCP Certificate 8 draft-dthakore-tls-authz-00 10 Abstract 12 This document specifies the use of DTCP certificate as an 13 authorization extension in the Transport Layer Security Handshake 14 Protocol, according to guidelines in RFC 5878. Extensions carried in 15 the client and server Hello messages confirm that both parties 16 support the desired authorization data types. Then if supported by 17 both the client and server, DTCP certificates are exchanged in the 18 supplemental data handshake TLS handshake message as specified in 19 RFC4680. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 18, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Overview of Supplemental Data handshake . . . . . . . . . . 3 56 2.2. Overview of authorization extensions . . . . . . . . . . . 4 57 2.3. Overview of Supplemental Data usage for authorization . . . 5 58 3. DTCP Authorization Data Format . . . . . . . . . . . . . . . . 5 59 3.1. DTCP Authorization Type . . . . . . . . . . . . . . . . . . 5 60 3.2. DTCP Authorization Data . . . . . . . . . . . . . . . . . . 6 61 3.3. Usage rules for clients to exchange DTCP Authorization 62 data . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.4. Usage rules for servers to exchange DTCP Authorization 64 data . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.5. Alert Messages . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 9 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The Transport Layer Security (TLS) protocol (TLS1.0 [RFC2246], TLS1.1 78 [RFC4346], TLS1.2 [RFC5246]) is being used in an increasing variety 79 of operational environments, the most common among which is its use 80 in securing HTTP traffic ([RFC2818]). RFC 5878 [AUTHZ] introduces 81 extensions that enable TLS to operate in environments where 82 authorization information needs to be exchanged between the client 83 and the server before any protected data is exchanged. The use of 84 these TLS authorization extensions is especially attractive since it 85 can allow the client and server to determine the type of protected 86 data to exchange based on the authorization information received in 87 the extensions. 89 A number of consumer electronics devices such as TV's, tablets, game 90 consoles, settop boxes and other multimedia devices contain Digital 91 Transmission Licensing Administrator [DTLA] issued Digital 92 Transmission Content Protection [DTCP] certificates. These 93 certificates are used for link protection over various types of links 94 like DTCP over IP [DTCP-IP] to securely transmit premium audio visual 95 content between devices. These DTCP certificates can also be used to 96 verify device functionality, other than link protection. 98 This document describes the format and necessary identifiers to 99 exchange DTCP certificates inside a TLS exchange. This credential 100 exchange allows a client and/or server to perform certain actions or 101 provide specific services. The DTCP certificate is cryptographically 102 tied to the X.509 certificate being used during the TLS tunnel 103 establishment by an EC-DSA [DTCP] signature. 105 1.1. Conventions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. Overview 113 2.1. Overview of Supplemental Data handshake 115 Figure 1 (Figure 1) illustrates the exchange of SupplementalData 116 message during the TLS handshake as specified in RFC4680 [SuppData] 117 and is repeated here for convenience. 119 TLS handshake message exchange with SupplementalData [SuppData] 121 Client Server 123 ClientHello (with extensions) --------> 125 ServerHello(with extensions) 126 SupplementalData* 127 Certificate* 128 ServerKeyExchange* 129 CertificateRequest* 130 <-------- ServerHelloDone 132 SupplementalData* 133 Certificate* 134 ClientKeyExchange 135 CertificateVerify* 136 [ChangeCipherSpec] 137 Finished --------> 138 [ChangeCipherSpec] 139 <-------- Finished 140 Application Data <-------> Application Data 142 * Indicates optional or situation-dependent messages that are 143 not always sent. 145 [] Indicates that ChangeCipherSpec is an independent TLS 146 protocol content type; it is not a TLS handshake message. 148 Figure 1 150 2.2. Overview of authorization extensions 152 RFC5878 [AUTHZ] defines two authorization extension types that are 153 used in the ClientHello and ServerHello messages and are repeated 154 below for convenience. 156 enum { 157 client_authz(7), server_authz(8), (65535) 158 } ExtensionType; 160 A client uses the client_authz and server_authz extensions in the 161 ClientHello message to indicate that it will send client 162 authorization data and receive server authorization data respectively 163 in the SupplementalData messages. A server uses the extensions in a 164 similar manner in its ServerHello message. RFC5878 [AUTHZ] also 165 establishes a registry that is maintained by IANA for registering 166 authorization data formats. This document defines a new 167 authorization data type that is used in both the client_authz and 168 server_authz extensions and allows the client and server to exchange 169 DTCP certificates in the SupplementalData message. 171 2.3. Overview of Supplemental Data usage for authorization 173 Section 3 of RFC5878 [AUTHZ] specifies the syntax of the Supplemental 174 Data message when carrying the authz_data message that is negotiated 175 in the client_authz and/or server_authz types. The syntax is 176 repeated here for convenience. 178 enum { 179 authz_data(16386), (65535) 180 } SupplementalDataType; 182 struct { 183 SupplementalDataType supplemental_data_type; 184 select(SupplementalDataType) { 185 case authz_data: AuthorizationData; 186 } 187 } SupplementalData; 189 This document defines a new authorization data format that is used in 190 the authz_data message when sending DTCP Authorization data. 192 3. DTCP Authorization Data Format 194 3.1. DTCP Authorization Type 196 The DTCP Authorization type definition in the TLS Authorization Data 197 Formats registry is: 199 dtcp_authorization(TBA); 201 3.2. DTCP Authorization Data 203 The DTCP Authorization data SHALL be sent in the authz_data message 204 when the authorization data type is dtcp_authorization. The syntax 205 of the authorization data is: 207 struct { 208 opaque random_bytes[32]; 209 } RandomNonce; 211 struct { 212 opaque ASN.1 Cert<1..2^24-1>; 213 opaque DTCP Cert<1..2^24-1>; 214 } DigitallySigned; 216 struct { 217 RandomNonce nonce; 218 DigitallySigned certs; 219 } dtcp_authz_data; 221 The ASN.1 Certificate in the structure above MUST be the same as the 222 sender's certificate that will be sent in the Certificate or 223 ClientCertificate message. 225 RandomNonce - consists of 32 bytes generated by a secure random 226 number generator. The dtcp_authz_data message MUST always contain a 227 RandomNonce. 229 DigitallySigned - contains the tuple {ASN.1 Certificate, DTCP 230 Certificate} followed by the digital signature generated using the 231 private key associated with the DTCP certificate using an Elleptic 232 Curve Digital Signature Algorithm (EC-DSA) as specified in [DTCP]. 233 The sender SHALL include this in the dtcp_authz_data message only 234 when it is sending its own DTCP Certificate. 236 3.3. Usage rules for clients to exchange DTCP Authorization data 238 A client MUST include both the client_authz and server_authz 239 extensions in the extended client hello message when indicating its 240 desire to exchange DTCP authorization data with the server. 241 Additionally the client MUST use the authorization data type 242 specified in Section 3.1 in the extension_data field to specify the 243 format of the authorization data. A client will receive the server's 244 dtcp_authz_data before it sends its own dtcp_authz_data. When 245 sending its own dtcp_authz_data message, the client MUST use the same 246 RandomNonce that it received in the server's dtcp_authz_data message. 248 3.4. Usage rules for servers to exchange DTCP Authorization data 250 A server MUST respond with both the client_authz and server_authz 251 extensions in the extended server hello message when indicating its 252 desire to exchange dtcp_authorization data with the client. 253 Additionally the server MUST use the authorization data type 254 specified in Section 3.1 in the extension_data field to specify the 255 format of the dtcp_authorization data. A server MUST generate and 256 populate the RandomNonce in the dtcp_authz_data message. If the 257 client's hello message does not contain both the client_authz and 258 server_authz extensions with dtcp_authorization type, the server 259 SHALL not include support for dtcp_authorization data in its hello 260 message. 262 3.5. Alert Messages 264 This document reuses TLS Alert messages for any errors that arise 265 during authorization processing, while preserving the AlertLevels as 266 specified in [AUTHZ]. Additionally the following AlertDescription 267 values SHALL be used to report errors in dlna_authorization 268 processing: 270 unsupported_extension: 271 In dtcp_authorization processing a client uses this when 272 it receives a server hello message that indicates support 273 for only one of client_authz or server_authz extension. 275 4. Acknowledgements 277 This document derives its structure and much of its content from 278 [SuppData], [AUTHZ] and [RFC6042]. 280 5. IANA Considerations 282 This document requires a new entry in the IANA-maintained TLS 283 Authorization Data Formats registry, dtcp_authorization(TBA). This 284 registry is defined in [AUTHZ]. 286 6. Security Considerations 288 There are no security considerations beyond those discussed in 289 [DTCP], [DTCP-IP] and [AUTHZ]. 291 7. References 293 7.1. Normative References 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 299 RFC 2246, January 1999, 300 . 302 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 303 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 305 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 306 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 308 [SuppData] 309 Santesson, S., "TLS Handshake Message for Supplemental 310 Data", September 2006, 311 . 313 [AUTHZ] Brown, M. and R. Housley, "Transport Layer Security (TLS) 314 Authorization Extensions", RFC 5878, May 2010, 315 . 317 [DTCP] Digital Transmission Licensing Administrator, "Digital 318 Transmission Content Protection", . 321 [DTCP-IP] Digital Transmission Licensing Administrator, "DTCP Volume 322 1 Supplement E", . 325 7.2. Informative References 327 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 328 June 1999. 330 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 331 Text on Security Considerations", BCP 72, RFC 3552, 332 July 2003. 334 [I-D.narten-iana-considerations-rfc2434bis] 335 Narten, T. and H. Alvestrand, "Guidelines for Writing an 336 IANA Considerations Section in RFCs", 337 draft-narten-iana-considerations-rfc2434bis-09 (work in 338 progress), March 2008. 340 [DTLA] Digital Transmission Licensing Administrator, "DTLA", 341 . 343 [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000, 344 . 346 [RFC6042] Keromytis, A., "Transport Layer Security (TLS) 347 Authorization Using KeyNote", RFC 6042, October 2010, 348 . 350 Appendix A. Additional Stuff 352 This becomes an Appendix. 354 Author's Address 356 Darshak Thakore 357 Cable Television Laboratories, Inc. 358 858 Coal Creek Circle 359 Louisville, CO 80023 360 USA 362 Email: d.thakore@cablelabs.com