idnits 2.17.1 draft-dthakore-tls-authz-05.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 623 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([DTLA], [RFC5878]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 15, 2014) is 3754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 487, but not defined -- Looks like a reference, but probably isn't: '32' on line 260 -- Looks like a reference, but probably isn't: '40' on line 273 == Unused Reference: 'RFC2629' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 554, 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) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 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 January 15, 2014 5 Expires: July 19, 2014 7 Transport Layer Security (TLS) Authorization Using DTCP Certificate 8 draft-dthakore-tls-authz-05 10 Abstract 12 This document specifies the use of Digital Transmission Content 13 Protection (DTCP) certificates as an authorization data type in the 14 authorization extension for the Transport Layer Security (TLS) 15 Protocol. This is in accordance with the guidelines for 16 authorization extensions as specified in [RFC5878]. As with other 17 TLS extensions, this authorization data can be included in the client 18 and server Hello messages to confirm that both parties support the 19 desired authorization data types. If supported by both the client 20 and the server, DTCP certificates are exchanged in the supplemental 21 data TLS handshake message as specified in RFC4680. This 22 authorization data type extension is in support of devices containing 23 DTCP certificates, issued by the Digital Transmission Licensing 24 Administrator [DTLA]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 19, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. 55 Table of Contents 57 1. Introduction 58 1.1. Applicability Statement 59 1.2. Conventions 60 2. Overview 61 2.1. Overview of DTCP Certificates 62 2.2. Overview of Supplemental Data handshake 63 2.3. Overview of authorization extensions 64 2.4. Overview of supplemental data usage for authorization 65 3. DTCP Authorization Data Format 66 3.1. DTCP Authorization Type 67 3.2. DTCP Authorization Data 68 3.3. Usage rules for clients to exchange DTCP Authorization 69 data 70 3.4. Usage rules for servers to exchange DTCP Authorization 71 data 72 3.5. TLS message exchange with dtcp_authz_data 73 3.6. Alert Messages 74 4. IANA Considerations 75 5. Security Considerations 76 6. Acknowledgements 77 7. References 78 7.1. Normative References 79 7.2. Informative References 80 Appendix A. Additional Stuff 81 Author's Address 83 1. Introduction 85 The Transport Layer Security (TLS) protocol (TLS1.0 [RFC2246], TLS1.1 86 [RFC4346], TLS1.2 [RFC5246]) is being used in an ever increasing 87 variety of operational environments, the most common among which is 88 its use in securing HTTP traffic ([RFC2818]). [RFC5878] introduces 89 extensions that enable TLS to operate in environments where 90 authorization information needs to be exchanged between the client 91 and the server before any protected data is exchanged. The use of 92 these TLS authorization extensions is especially attractive since it 93 allows the client and server to determine the type of protected data 94 to exchange based on the authorization information received in the 95 extensions. 97 A substantial number of deployed consumer electronics devices such as 98 televisions, tablets, game consoles, set-top boxes and other 99 multimedia devices contain [DTLA] issued Digital Transmission Content 100 Protection [DTCP] certificates. These DTCP certificates enable 101 secure transmission of premium audio-visual content between devices 102 over various types of links (e.g., DTCP over IP [DTCP-IP]). These 103 DTCP certificates can also be used to verify device functionality 104 (e.g., supported device features) 106 This document describes the format and necessary identifiers to 107 exchange DTCP certificates within the supplemental data message (see 108 [RFC4680]) while negotiating a TLS session. The DTCP certificates 109 are then used independent of their use for content protection (e.g., 110 to verify supported features) and the corresponding DTCP 111 Authentication and Key Exchange (AKE) protocol. This communication 112 allows either the client or the server or both to perform certain 113 actions or provide specific services. The actual semantics of the 114 authorization decision by the client/server are beyond the scope of 115 this document. The DTCP certificate, which is not an X.509 116 certificate, can be cryptographically tied to the X.509 certificate 117 being used during the TLS tunnel establishment by an EC-DSA [DTCP] 118 signature. 120 1.1. Applicability Statement 122 DTCP-enabled consumer electronics devices (eg. televisions, game 123 consoles) use DTCP certificates for secure transmission of audio- 124 visual content. The Authentication and Key Exchange (AKE) protocol 125 defined in [DTCP] is used to exchange DTCP Certificates and allows a 126 device to be identified and authenticated based on the information in 127 the DTCP Certificate. However these DTCP-enabled devices offer 128 additional functionality (e.g., via HTML5 User Agents or web enabled 129 applications) that is distinct from its capability to transmit and 130 play audio-visual content. The mechanism outlined in this document 131 allows a DTCP-enabled consumer electronics device to authenticate and 132 authorize using its DTCP Certificate when accessing services over the 133 internet; for example ,web applications on televisions that can 134 enable value-added services. This is anticipated to be very valuable 135 since there are a considerable number of such devices. The re-use of 136 well-known web security will also keep such communication consistent 137 with existing standards and best practices. 139 1.2. Conventions 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 2. Overview 147 2.1. Overview of DTCP Certificates 149 DTCP certificates issued by [DTLA] to DTLA-compliant devices come in 150 three general variations (see [DTCP], Section 4.2.3.1) 152 * Restricted Authentication device certificate format (Format 0): 153 Typically issued to devices with limited computation resources. 155 * Baseline Full Authentication device certificate format (Format 1): 157 This is the most commonly issued certificate format. Format 1 158 certificates include a unique Device ID and device EC-DSA public 159 /private key pair generated by the DTLA. (See Section 4.3 of 160 [DTCP]) 162 * Extended Full Authentication device certificate format (Format 2): 164 This is issued to devices that possess additional functions 165 (e.g., additional channel ciphers, specific device properties). 166 The presence of these additional functions is indicated by the 167 device capability mask as specified in Section 4.2.3.2 of the 168 DTCP specification [DTCP]. Format 2 certificates also include a 169 unique Device ID and device EC-DSA public/private key pair 170 generated by the DTLA. (See Section 4.3 of [DTCP]) 172 The mechanism specified in this document allows only Format 1 and 173 Format 2 DTCP certificates to be exchanged in the supplemental data 174 message since it requires the use of the EC-DSA private key 175 associated with the certificate. 177 2.2. Overview of Supplemental Data handshake 179 Figure 1 illustrates the exchange of SupplementalData message during 180 the TLS handshake as specified in [RFC4680] and is repeated here for 181 convenience: 183 Client Server 185 ClientHello (with extensions) --------> 187 ServerHello(with extensions) 188 SupplementalData* 189 Certificate* 190 ServerKeyExchange* 191 CertificateRequest* 192 <-------- ServerHelloDone 194 SupplementalData* 195 Certificate* 196 ClientKeyExchange 197 CertificateVerify* 198 [ChangeCipherSpec] 199 Finished --------> 200 [ChangeCipherSpec] 201 <-------- Finished 202 Application Data <-------> Application Data 204 * Indicates optional or situation-dependent messages that are 205 not always sent. 207 [] Indicates that ChangeCipherSpec is an independent TLS 208 protocol content type; it is not a TLS handshake message. 210 TLS handshake message exchange with Supplemental Data 212 Figure 1 214 2.3. Overview of authorization extensions 216 [RFC5878] defines two authorization extension types that are used in 217 the ClientHello and ServerHello messages and are repeated below for 218 convenience: 220 enum { 221 client_authz(7), server_authz(8), (65535) 222 } ExtensionType; 224 A client uses the client_authz and server_authz extensions in the 225 ClientHello message to indicate that it will send client 226 authorization data and receive server authorization data respectively 227 in the SupplementalData messages. A server uses the extensions in a 228 similar manner in its ServerHello message. [RFC5878] also 229 establishes a registry that is maintained by IANA for registering 230 authorization data formats. This document defines a new 231 authorization data type for both the client_authz and server_authz 232 extensions and allows the client and server to exchange DTCP 233 certificates in the SupplementalData message. 235 2.4. Overview of supplemental data usage for authorization 237 Section 3 of [RFC5878] specifies the syntax of the supplemental data 238 message when carrying the authz_data message that is negotiated in 239 the client_authz and/or server_authz types. This document defines a 240 new authorization data format that is used in the authz_data message 241 when sending DTCP Authorization data. 243 3. DTCP Authorization Data Format 245 3.1. DTCP Authorization Type 247 The DTCP Authorization type definition in the TLS Authorization Data 248 Formats registry is: 250 dtcp_authorization(TBA); 252 Note to RFC Editor: Please populate the number assigned by IANA 254 3.2. DTCP Authorization Data 256 The DTCP Authorization data is used when the AuthzDataFormat type is 257 dtcp_authorization. The syntax of the authorization data is: 259 struct { 260 opaque random_bytes[32]; 261 } RandomNonce; 263 digitally-signed struct { 264 RandomNonce nonce; 265 uint16 DTCPCert_length; 266 opaque DTCPCert<1..2^24-1>; 267 uint16 ASN.1Cert_length; 268 opaque ASN.1Cert<0..2^24-1>; 269 } DigitallySignedData; 271 struct { 272 DigitallySignedData certs; 273 opaque signature[40]; 274 } dtcp_authz_data; 276 RandomNonce is generated by the server and consists of 32 bytes 277 generated by a high quality secure random number generator. The 278 RandomNonce helps detect replay attacks. 280 DTCPCert is the sender's DTCP certificate, see Section 4.2.3.1 of the 281 DTCP Specification [DTCP] 283 ASN.1Cert is the sender's certificate used to establish the TLS 284 session, i.e., sent in the Certificate or ClientCertificate message 285 using the Certificate structure defined in Section 7.4.2 of 286 [RFC5246]. 288 If the ASN.1Cert is not being sent, the ASN.1Cert_length MUST be 289 zero. 291 DigitallySignedData - contains the RandomNonce, DTCP Certificate and 292 the optional ASN.1 Certificate. This is then followed by the digital 293 signature covering the RandomNonce, DTCP Certificate and the ASN.1 294 certificate if it is present. The signature is generated using the 295 private key associated with the DTCP certificate using the Signature 296 Algorithm and Hash Algorithm as specified in Section 4.4 of [DTCP]. 297 This signature provides proof of the possession of the private key by 298 the sender. A sender sending its own DTCP Certificate MUST populate 299 the certs field. 301 3.3. Usage rules for clients to exchange DTCP Authorization data 303 A client includes both the client_authz and server_authz extensions 304 in the extended client hello message when indicating its desire to 305 exchange DTCP authorization data with the server. Additionally, the 306 client includes the AuthzDataFormat type specified in Section 3.1 in 307 the extension_data field to specify the format of the authorization 308 data. 310 A client will receive the server's dtcp_authz_data before it sends 311 its own dtcp_authz_data. When sending its own dtcp_authz_data 312 message, the client includes the same RandomNonce that it receives in 313 the server's dtcp_authz_data message. Clients include its DTCP 314 Certificate in the dtcp_authz_data message. If the client wants to 315 cryptographically tie its dtcp_authz_data with the TLS session, then 316 the client includes the ASN.1 Certificate used to establish the TLS 317 session (certificate in the ClientCertificate message) in the 318 ASN.1Cert field in dtcp_authz_data. 320 3.4. Usage rules for servers to exchange DTCP Authorization data 322 A server responds with both the client_authz and server_authz 323 extensions in the extended server hello message when indicating its 324 desire to exchange dtcp_authorization data with the client. 325 Additionally, the server includes the AuthzDataFormat type specified 326 in Section 3.1 in the extension_data field to specify the format of 327 the dtcp_authorization data. A server always generates and populates 328 the RandomNonce in the dtcp_authz_data message. If the client's 329 hello message does not contain both the client_authz and server_authz 330 extensions with dtcp_authorization type, the server MUST NOT include 331 support for dtcp_authorization data in its hello message. A server 332 MAY include its DTCP Certificate in the dtcp_authz_data message. If 333 the server includes its DTCP Certificate, it MUST also include its 334 server certificate (sent in the TLS Certificate message) in the certs 335 field to cryptographically tie its dtcp_authz_data with the TLS 336 session being established. 338 3.5. TLS message exchange with dtcp_authz_data 340 Based on the usage rules in the sections above, Figure 2 (Figure 2) 341 below provides one possible TLS message exchange where the client 342 sends its DTCP Certificate to the server within the dtcp_authz_data 343 message. 345 Client Server 347 ClientHello (with extensions) --------> 349 ServerHello(with extensions) 350 SupplementalData(with Nonce N1) 351 Certificate 352 ServerKeyExchange* 353 CertificateRequest 354 <-------- ServerHelloDone 356 SupplementalData(with Data D1) 357 Certificate 358 ClientKeyExchange 359 CertificateVerify 360 [ChangeCipherSpec] 361 Finished --------> 362 [ChangeCipherSpec] 363 <-------- Finished 364 Application Data <-------> Application Data 366 N1 Random nonce generated by server 368 D1 Contains dtcp_authz_data populated with the following 369 {(N1, DTCP Cert, Client X.509 Cert) Signature over all elements} 371 * Indicates optional or situation-dependent messages that are 372 not always sent. 374 [] Indicates that ChangeCipherSpec is an independent TLS 375 protocol content type; it is not a TLS handshake message. 377 Figure 2 379 3.6. Alert Messages 381 This document reuses TLS Alert messages for any errors that arise 382 during authorization processing, and reuses the AlertLevels as 383 specified in [RFC5878]. Additionally the following AlertDescription 384 values are used to report errors in dtcp_authorization processing: 386 unsupported_extension: 387 During processing of dtcp_authorization, a client uses this 388 when it receives a server hello message that does not indicate 389 support for both client_authz and server_authz extension. 390 This message is always fatal. 392 certificate_unknown: 393 During processing of dtcp_authorization, a client or server 394 uses this when it has received an X.509 certificate in the 395 dtcp_authorization data and that X.509 certificate does 396 not match the certificate sent in the corresponding 397 ClientCertificate or Certificate message. 399 4. IANA Considerations 401 This document proposes a new entry to be registered in the IANA- 402 maintained TLS Authorization Data Formats registry for 403 dtcp_authorization(TBA). This registry is defined in [RFC5878] and 404 defines two ranges: one is IETF review and the other is specification 405 required. The value for dtcp_authorization should be assigned via 406 [RFC5226] Specification Required. 408 Note to RFC Editor: Please populate the number assigned by IANA in 409 TBA above. 411 5. Security Considerations 413 This document specifies a TLS authorization data extension that 414 allows TLS clients and servers to exchange DTCP certificates during a 415 TLS handshake exchange. The dtcp_authorizaton data as specified in 416 this document carries the DTCP Certificate that identified the 417 associated device. Given that it is anticipated by DTCP to be shared 418 in the open (e.g., similar to its usage in AKE), this document does 419 not add any additional security threats (e.g., confidentiality). 420 Further its integrity is ensured by the TLS protocol. Hence the 421 security considerations specified in [RFC5878] and [RFC5246] apply to 422 the extension specified in this document. In addition, the 423 dtcp_authorization data may be carried along with other supplemental 424 data or some other authorization data and that information may 425 require additional protection. 427 In cases where the supplemental data contains sensitive information, 428 the double handshake technique described in [RFC4680] can be used to 429 provide protection for the supplemental data information. The double 430 handshake specified in [RFC4680] assumes that the client knows the 431 context of the TLS session that is being set up and uses the 432 authorization extensions as needed. Figure 3 illustrates a variation 433 of the double handshake that addresses the case where the client may 434 not have a priori knowledge that it will be communicating with a 435 server capable of exchanging dtcp_authz_data (typical for https 436 connections; see [RFC2818]). In Figure 3 (Figure 3), the client's 437 Hello messages includes the client_authz and server_authz extensions. 438 The server simply establishes an encrypted TLS session with the 439 client in the first handshake by not indicating support for any authz 440 extensions. The server initiates a second handshake by sending a 441 HelloRequest. The second handshake will include server's support for 442 authz extensions which will result in SupplementalData being 443 exchanged. 445 This double handshake mechanism is vulnerable to the TLS MITM 446 Renegotiation exploit as explained in [RFC5746]. In order to address 447 this vulnerability, clients and servers MUST use the 448 secure_renegotiation extension as specified in [RFC5746] when 449 performing a double handshake. 451 It should be noted that for double handshake to succeed, any 452 extension (e.g., TLS Session Ticket [RFC5077]) that results in the 453 TLS Handshake sequence being modified may result in failure to 454 exchange SupplementalData. 456 Double Handshake to protect Supplemental Data 458 Client Server 460 ClientHello (w/ extensions) --------> |0 461 ServerHello (no authz extensions) |0 462 Certificate* |0 463 ServerKeyExchange* |0 464 CertificateRequest* |0 465 <-------- ServerHelloDone |0 466 Certificate* |0 467 ClientKeyExchange |0 468 CertificateVerify* |0 469 [ChangeCipherSpec] |0 470 Finished --------> |1 471 [ChangeCipherSpec] |0 472 <-------- Finished |1 473 <-------- HelloRequest |1 474 ClientHello (w/ extensions) --------> |1 475 ServerHello (w/ extensions) |1 476 SupplementalData* |1 477 Certificate* |1 478 ServerKeyExchange* |1 479 CertificateRequest* |1 480 <-------- ServerHelloDone |1 481 SupplementalData* |1 482 Certificate* |1 483 ClientKeyExchange |1 484 CertificateVerify* |1 485 [ChangeCipherSpec] |1 486 Finished --------> |2 487 [ChangeCipherSpec] |1 488 <-------- Finished |2 489 Application Data <-------> Application Data |2 491 * Indicates optional or situation-dependent messages. 493 Figure 3 495 Finally, implementers should also reference [DTCP] and [DTCP-IP] for 496 more information regarding DTCP certificates, their usage and 497 associated security considerations. 499 6. Acknowledgements 501 The author wishes to thank Mark Brown, Sean Turner, Sumanth 502 Channabasappa; and the Chairs (EKR, Joe Saloway) and members of the 503 TLS Working Group who provided feedback and comments on one or more 504 revisions of this document. 506 This document derives its structure and much of its content from 507 [RFC4680], [RFC5878] and [RFC6042]. 509 7. References 511 7.1. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 517 RFC 2246, January 1999, 518 . 520 [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 521 1.1", RFC 4346, April 2006, 522 . 524 [RFC5246] Dierks, T. and E. Rescorla, "The TLS Protocol Version 525 1.2", RFC 5246, August 2008, 526 . 528 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 529 "Transport Layer Security (TLS) Renegotiation Indication 530 Extension", RFC 5746, February 2010, 531 . 533 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 534 Data", September 2006, 535 . 537 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 538 Authorization Extensions", RFC 5878, May 2010, 539 . 541 [DTCP] Digital Transmission Licensing Administrator, "Digital 542 Transmission Content Protection", . 545 [DTCP-IP] Digital Transmission Licensing Administrator, "DTCP Volume 546 1 Supplement E", . 549 7.2. Informative References 551 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 552 June 1999. 554 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 555 Text on Security Considerations", BCP 72, RFC 3552, July 556 2003. 558 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 559 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 560 May 2008. 562 [DTLA] Digital Transmission Licensing Administrator, "DTLA", 563 . 565 [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000, 566 . 568 [RFC5077] Salowey, J. and P. Eronen, "Transport Layer Security (TLS) 569 Session Resumption without Server-Side State", RFC 5077, 570 January 2008, . 572 [RFC6042] Keromytis, A., "Transport Layer Security (TLS) 573 Authorization Using KeyNote", RFC 6042, October 2010, 574 . 576 Appendix A. Additional Stuff 578 This becomes an Appendix. 580 Author's Address 582 D. Thakore 583 Cable Television Laboratories, Inc. 584 858 Coal Creek Circle 585 Louisville, CO 80023 586 USA 588 Email: d.thakore@cablelabs.com