idnits 2.17.1 draft-dthakore-tls-authz-01.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 : ---------------------------------------------------------------------------- ** There are 30 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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. 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. -- The document date (October 2012) is 4211 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 342, but not defined -- Looks like a reference, but probably isn't: '32' on line 203 == Unused Reference: 'RFC2629' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 403, 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 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Layer Security D. Thakore 3 Internet-Draft CableLabs 4 Intended status: Informational October 2012 5 Expires: April 02, 2013 7 Transport Layer Security (TLS) Authorization Using DTCP Certificate 8 draft-dthakore-tls-authz-01 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." 35 This Internet-Draft will expire on April 02, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Overview of Supplemental Data handshake . . . . . . . . . 3 55 2.2. Overview of authorization extensions . . . . . . . . . . . 4 56 2.3. Overview of Supplemental Data usage for authorization . . 5 57 3. DTCP Authorization Data Format . . . . . . . . . . . . . . . . 5 58 3.1. DTCP Authorization Type . . . . . . . . . . . . . . . . . 5 59 3.2. DTCP Authorization Data . . . . . . . . . . . . . . . . . 5 60 3.3. Usage rules for clients to exchange DTCP Authorization data 6 61 3.4. Usage rules for servers to exchange DTCP Authorization data 7 62 3.5. Alert Messages . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 69 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 11 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 The Transport Layer Security (TLS) protocol (TLS1.0 [RFC2246], TLS1.1 75 [RFC4346], TLS1.2 [RFC5246]) is being used in an increasing variety 76 of operational environments, the most common among which is its use 77 in securing HTTP traffic ([RFC2818]). RFC 5878 [AUTHZ] introduces 78 extensions that enable TLS to operate in environments where 79 authorization information needs to be exchanged between the client 80 and the server before any protected data is exchanged. The use of 81 these TLS authorization extensions is especially attractive since it 82 can allow the client and server to determine the type of protected 83 data to exchange based on the authorization information received in 84 the extensions. 86 A number of consumer electronics devices such as TV's, tablets, game 87 consoles, settop boxes and other multimedia devices contain Digital 88 Transmission Licensing Administrator [DTLA] issued Digital 89 Transmission Content Protection [DTCP] certificates. These 90 certificates are used for link protection over various types of links 91 like DTCP over IP [DTCP-IP] to securely transmit premium audio visual 92 content between devices. These DTCP certificates can also be used to 93 verify device functionality, other than link protection. 95 This document describes the format and necessary identifiers to 96 exchange DTCP certificates inside a TLS exchange. This credential 97 exchange allows a client and/or server to perform certain actions or 98 provide specific services. The DTCP certificate is cryptographically 99 tied to the X.509 certificate being used during the TLS tunnel 100 establishment by an EC-DSA [DTCP] signature. 102 1.1. Conventions 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Overview 110 2.1. Overview of Supplemental Data handshake 112 Figure 1 (Figure 1) illustrates the exchange of SupplementalData 113 message during the TLS handshake as specified in RFC4680 [SuppData] 114 and is repeated here for convenience. 116 TLS handshake message exchange with SupplementalData [SuppData] 117 Client Server 119 ClientHello (with extensions) --------> 121 ServerHello(with extensions) 122 SupplementalData* 123 Certificate* 124 ServerKeyExchange* 125 CertificateRequest* 126 <-------- ServerHelloDone 128 SupplementalData* 129 Certificate* 130 ClientKeyExchange 131 CertificateVerify* 132 [ChangeCipherSpec] 133 Finished --------> 134 [ChangeCipherSpec] 135 <-------- Finished 136 Application Data <-------> Application Data 138 * Indicates optional or situation-dependent messages that are 139 not always sent. 141 [] Indicates that ChangeCipherSpec is an independent TLS 142 protocol content type; it is not a TLS handshake message. 144 Figure 1 146 2.2. Overview of authorization extensions 148 RFC5878 [AUTHZ] defines two authorization extension types that are 149 used in the ClientHello and ServerHello messages and are repeated 150 below for convenience. 152 enum { 153 client_authz(7), server_authz(8), (65535) 154 } ExtensionType; 156 A client uses the client_authz and server_authz extensions in the 157 ClientHello message to indicate that it will send client 158 authorization data and receive server authorization data respectively 159 in the SupplementalData messages. A server uses the extensions in a 160 similar manner in its ServerHello message. RFC5878 [AUTHZ] also 161 establishes a registry that is maintained by IANA for registering 162 authorization data formats. This document defines a new 163 authorization data type that is used in both the client_authz and 164 server_authz extensions and allows the client and server to exchange 165 DTCP certificates in the SupplementalData message. 167 2.3. Overview of Supplemental Data usage for authorization 169 Section 3 of RFC5878 [AUTHZ] specifies the syntax of the Supplemental 170 Data message when carrying the authz_data message that is negotiated 171 in the client_authz and/or server_authz types. The syntax is 172 repeated here for convenience. 174 enum { 175 authz_data(16386), (65535) 176 } SupplementalDataType; 178 struct { 179 SupplementalDataType supplemental_data_type; 180 select(SupplementalDataType) { 181 case authz_data: AuthorizationData; 182 } 183 } SupplementalData; 185 This document defines a new authorization data format that is used in 186 the authz_data message when sending DTCP Authorization data. 188 3. DTCP Authorization Data Format 190 3.1. DTCP Authorization Type 192 The DTCP Authorization type definition in the TLS Authorization Data 193 Formats registry is: 195 dtcp_authorization(TBA); 197 3.2. DTCP Authorization Data 198 The DTCP Authorization data SHALL be sent in the authz_data message 199 when the authorization data type is dtcp_authorization. The syntax 200 of the authorization data is: 202 struct { 203 opaque random_bytes[32]; 204 } RandomNonce; 206 digitally-signed struct { 207 opaque DTCPCert<1..2^24-1>; 208 [[opaque ASN.1 Cert<0..2^24-1>]]; 209 opaque signature<0..2^16-1>; 210 } DigitallySigned; 212 struct { 213 RandomNonce nonce; 214 [[DigitallySigned certs]]; 215 } dtcp_authz_data; 217 RandomNonce - consists of 32 bytes generated by a secure random 218 number generator. The dtcp_authz_data message MUST always contain a 219 RandomNonce. 221 If the ASN.1 Certificate is being sent in the structure above it MUST 222 be the same as the sender's certificate that will be sent in the 223 Certificate or ClientCertificate message. 225 DigitallySigned - contains the DTCP Certificate and the optional 226 ASN.1 Certificate followed by the digital signature generated using 227 the private key associated with the DTCP certificate using an 228 Elleptic Curve Digital Signature Algorithm (EC-DSA) as specified in 229 [DTCP]. If the sender is sending its own DTCP Certificate, it MUST 230 populate the certs field. 232 3.3. Usage rules for clients to exchange DTCP Authorization data 234 A client MUST include both the client_authz and server_authz 235 extensions in the extended client hello message when indicating its 236 desire to exchange DTCP authorization data with the server. 237 Additionally the client MUST use the authorization data type 238 specified in Section 3.1 in the extension_data field to specify the 239 format of the authorization data. A client will receive the server's 240 dtcp_authz_data before it sends its own dtcp_authz_data. When 241 sending its own dtcp_authz_data message, the client MUST use the same 242 RandomNonce that it received in the server's dtcp_authz_data message. 243 A client MAY include its ASN.1 Certificate in the certs field to 244 cryptographically tie its dtcp_authz_data with the TLS session being 245 established. 247 3.4. Usage rules for servers to exchange DTCP Authorization data 249 A server MUST respond with both the client_authz and server_authz 250 extensions in the extended server hello message when indicating its 251 desire to exchange dtcp_authorization data with the client. 252 Additionally the server MUST use the authorization data type 253 specified in Section 3.1 in the extension_data field to specify the 254 format of the dtcp_authorization data. A server MUST generate and 255 populate the RandomNonce in the dtcp_authz_data message. If the 256 client's hello message does not contain both the client_authz and 257 server_authz extensions with dtcp_authorization type, the server 258 SHALL not include support for dtcp_authorization data in its hello 259 message. A server MAY include its ASN.1 Certificate in the certs 260 field to cryptographically tie its dtcp_authz_data with the TLS 261 session being established. 263 3.5. Alert Messages 265 This document reuses TLS Alert messages for any errors that arise 266 during authorization processing, while preserving the AlertLevels as 267 specified in [AUTHZ]. Additionally the following AlertDescription 268 values SHALL be used to report errors in dlna_authorization 269 processing: 271 unsupported_extension: 272 In dtcp_authorization processing a client uses this when 273 it receives a server hello message that indicates support 274 for only one of client_authz or server_authz extension. 276 4. Acknowledgements 278 This document derives its structure and much of its content from 279 [SuppData], [AUTHZ] and [RFC6042]. 281 5. IANA Considerations 283 This document requires a new entry in the IANA-maintained TLS 284 Authorization Data Formats registry, dtcp_authorization(TBA). This 285 registry is defined in [AUTHZ]. 287 6. Security Considerations 288 In cases where the SupplementalData information is sensitive, the 289 double handshake technique described in [SuppData] can be used to 290 provide protection for the SupplementalData information. The double 291 handshake specified in [SuppData] assumes that the client knows the 292 context of the TLS session that is being set up; thus, the client 293 uses the authorization extensions as needed. Figure 2 (Figure 2) 294 illustrates a variation of the double handshake that addresses the 295 case where the client may not have a priori knowledge that it will be 296 communicating with a server capable of exchanging dtcp_authz_data 297 (typical for https usages based on [RFC2818]). In Figure 2 (Figure 298 2) below client's Hello messages always include support for the 299 client_authz and server_authz extensions. The server simply 300 establishes an encrypted TLS tunnel with the client in the first 301 hanshake by not indicating support for any authz extensions. The 302 server initiates a second handshake by sending a HelloRequest. The 303 second handshake will include server's support for authz extensions 304 which will result in SupplementalData being exchanged. 306 The double handshake mechanism is vulnerable to the TLS MITM 307 Renegotiation exploit as explained in [RFC5746]. In order to address 308 this vulnerability, clients and servers MUST use the 309 secure_renegotiation extension as specified in [RFC5746] when 310 performing a double handshake. 312 Double Handshake to protect Supplemental Data 313 Client Server 315 ClientHello (w/ extensions) --------> |0 316 ServerHello (no authz extensions) |0 317 Certificate* |0 318 ServerKeyExchange* |0 319 CertificateRequest* |0 320 <-------- ServerHelloDone |0 321 Certificate* |0 322 ClientKeyExchange |0 323 CertificateVerify* |0 324 [ChangeCipherSpec] |0 325 Finished --------> |1 326 [ChangeCipherSpec] |0 327 <-------- Finished |1 328 <-------- HelloRequest |1 329 ClientHello (w/ extensions) --------> |1 330 ServerHello (w/ extensions) |1 331 SupplementalData* |1 332 Certificate* |1 333 ServerKeyExchange* |1 334 CertificateRequest* |1 335 <-------- ServerHelloDone |1 336 SupplementalData* |1 337 Certificate* |1 338 ClientKeyExchange |1 339 CertificateVerify* |1 340 [ChangeCipherSpec] |1 341 Finished --------> |2 342 [ChangeCipherSpec] |1 343 <-------- Finished |2 344 Application Data <-------> Application Data |2 346 * Indicates optional or situation-dependent messages. 348 Figure 2 350 There are no additional security considerations beyond those 351 discussed in [DTCP], [DTCP-IP] and [AUTHZ]. 353 7. References 355 7.1. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0 ", 361 RFC 2246, January 1999, . 364 [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1 365 ", RFC 4346, April 2006, . 368 [RFC5246] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2 369 ", RFC 5246, August 2008, . 372 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 373 "Transport Layer Security (TLS) Renegotiation Indication 374 Extension ", RFC 5746, February 2010, . 377 [SuppData] 378 Santesson, S., "TLS Handshake Message for Supplemental 379 Data", September 2006, . 382 [AUTHZ] Brown, M. and R. Housley, "Transport Layer Security (TLS) 383 Authorization Extensions ", RFC 5878, May 2010, . 386 [DTCP] Digital Transmission Licensing Administrator, "Digital 387 Transmission Content Protection", , . 390 [DTCP-IP] Digital Transmission Licensing Administrator, "DTCP Volume 391 1 Supplement E", , . 394 7.2. Informative References 396 [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, 397 June 1999. 399 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 400 Text on Security Considerations", BCP 72, RFC 3552, July 401 2003. 403 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 404 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 405 May 2008. 407 [DTLA] Digital Transmission Licensing Administrator, "DTLA", , 408 . 410 [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000, . 413 [RFC6042] Keromytis, A., "Transport Layer Security (TLS) 414 Authorization Using KeyNote ", RFC 6042, October 2010, 415 . 417 Appendix A. Additional Stuff 419 This becomes an Appendix. 421 Author's Address 423 D. Thakore 424 Cable Television Laboratories, Inc. 425 858 Coal Creek Circle 426 Louisville, CO 80023 427 USA 429 Email: d.thakore@cablelabs.com