idnits 2.17.1 draft-dthakore-tls-authz-03.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 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 2013) is 4088 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 448, but not defined -- Looks like a reference, but probably isn't: '32' on line 259 -- Looks like a reference, but probably isn't: '40' on line 270 == Unused Reference: 'RFC2629' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 509, 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 (==), 6 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 February 2013 5 Expires: August 03, 2013 7 Transport Layer Security (TLS) Authorization Using DTCP Certificate 8 draft-dthakore-tls-authz-03 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 August 03, 2013. 38 Copyright Notice 40 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Use Case for using DTCP Certificates . . . . . . . . . . . 3 54 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Overview of DTCP Certificates . . . . . . . . . . . . . . 3 57 2.2. Overview of Supplemental Data handshake . . . . . . . . . 4 58 2.3. Overview of authorization extensions . . . . . . . . . . . 5 59 2.4. Overview of supplemental data usage for authorization . . 5 60 3. DTCP Authorization Data Format . . . . . . . . . . . . . . . . 6 61 3.1. DTCP Authorization Type . . . . . . . . . . . . . . . . . 6 62 3.2. DTCP Authorization Data . . . . . . . . . . . . . . . . . 6 63 3.3. Usage rules for clients to exchange DTCP Authorization data 7 64 3.4. Usage rules for servers to exchange DTCP Authorization data 7 65 3.5. TLS message exchange with dtcp_authz_data . . . . . . . . 7 66 3.6. Alert Messages . . . . . . . . . . . . . . . . . . . . . . 8 67 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 12 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The Transport Layer Security (TLS) protocol (TLS1.0 [RFC2246], TLS1.1 79 [RFC4346], TLS1.2 [RFC5246]) is being used in an increasing variety 80 of operational environments, the most common among which is its use 81 in securing HTTP traffic ([RFC2818]). RFC 5878 [AUTHZ] introduces 82 extensions that enable TLS to operate in environments where 83 authorization information needs to be exchanged between the client 84 and the server before any protected data is exchanged. The use of 85 these TLS authorization extensions is especially attractive since it 86 can allow the client and server to determine the type of protected 87 data to exchange based on the authorization information received in 88 the extensions. 90 A number of consumer electronics devices such as TV's, tablets, game 91 consoles, set-top boxes and other multimedia devices contain Digital 92 Transmission Licensing Administrator [DTLA] issued Digital 93 Transmission Content Protection [DTCP] certificates. These 94 certificates are used for link protection over various types of links 95 like DTCP over IP [DTCP-IP] to securely transmit premium audio-visual 96 content between devices. These DTCP certificates can also be used to 97 verify device functionality, besides being used to protect audio- 98 visual content. 100 This document describes the format and necessary identifiers to 101 exchange DTCP certificates within the supplemental data message (see 102 [SuppData]) while negotiating a TLS exchange. The DTCP certificates 103 are then used for authorization independent of its use for content 104 protection and the corresponding DTCP Authentication and Key Exchange 105 (AKE) protocol. This authorization allows a client and/or server to 106 perform certain actions or provide specific services. The actual 107 semantics of the authorization decision by the client/server are 108 beyond the scope of this document. The DTCP certificate can be 109 cryptographically tied to the X.509 certificate being used during the 110 TLS tunnel establishment by an EC-DSA [DTCP] signature. 112 1.1. Use Case for using DTCP Certificates 114 As mentioned above, the primary use of DTCP Certificates in consumer 115 electronics devices (eg. TV's) is for secure transmission of audio- 116 visual content. The Authentication and Key Exchange (AKE) protocol 117 defined in [DTCP] is used to exchange DTCP Certificates and allows a 118 device to be identified and authenticated based on the information in 119 the DTCP Certificate. However these devices also have additional 120 functionality (eg. HTML5 User Agents, web enabled apps) that is 121 distinct from its capability to transmit and play audio-visual 122 content. The mechanism outlined in this document allows a device to 123 authenticate and authorize itself using its DTCP Certificate when 124 accessing services over the internet (eg. web app on a TV accessing 125 some service over HTTPS). This allows reusing an already provisioned 126 credential for different services that are delivered over TLS. 128 1.2. Conventions 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 2. Overview 136 2.1. Overview of DTCP Certificates 138 DTCP certificates are issued by [DTLA] for compliant devices and come 139 in three general variations (see Section 4.2.3.1 of the DTCP 140 Specification [DTCP]) 142 Restricted Authentication device certificate format (Format 0): Typic 143 ally issued to devices with limited computation resources. 144 Baseline Full Authentication device certificate format (Format 1): Th 145 is is the most commonly issued certificate format. Format 1 146 certificates include a unique Device ID and device EC-DSA public/ 147 private key pair generated by the DTLA. (See Section 4.3 of DTCP 148 [DTCP]) 150 Extended Full Authentication device certificate format (Format 2): Th 151 is is issued to devices that possess additional functions (eg. 152 additional channel ciphers, specific device properties). The 153 presence of these additional functions is indicated by the device 154 capability mask as specified in Section 4.2.3.2 of the DTCP 155 specification [DTCP]. Format 2 certificates also include a 156 unique Device ID and device EC-DSA public/private key pair 157 generated by the DTLA. (See Section 4.3 of DTCP [DTCP]) 159 The mechanism specified in this document allows only Format 1 and 160 Format 2 type DTCP certificates to be exchanged in the supplemental 161 data message since it requires the use of the EC-DSA private key 162 associated with the certificate. 164 2.2. Overview of Supplemental Data handshake 166 Figure 1 (Figure 1) illustrates the exchange of SupplementalData 167 message during the TLS handshake as specified in RFC4680 [SuppData] 168 and is repeated here for convenience. 170 TLS handshake message exchange with SupplementalData [SuppData] 172 Client Server 174 ClientHello (with extensions) --------> 176 ServerHello(with extensions) 177 SupplementalData* 178 Certificate* 179 ServerKeyExchange* 180 CertificateRequest* 181 <-------- ServerHelloDone 183 SupplementalData* 184 Certificate* 185 ClientKeyExchange 186 CertificateVerify* 187 [ChangeCipherSpec] 188 Finished --------> 189 [ChangeCipherSpec] 190 <-------- Finished 191 Application Data <-------> Application Data 193 * Indicates optional or situation-dependent messages that are 194 not always sent. 196 [] Indicates that ChangeCipherSpec is an independent TLS 197 protocol content type; it is not a TLS handshake message. 199 Figure 1 201 2.3. Overview of authorization extensions 203 RFC5878 [AUTHZ] defines two authorization extension types that are 204 used in the ClientHello and ServerHello messages and are repeated 205 below for convenience. 207 enum { 208 client_authz(7), server_authz(8), (65535) 209 } ExtensionType; 211 A client uses the client_authz and server_authz extensions in the 212 ClientHello message to indicate that it will send client 213 authorization data and receive server authorization data respectively 214 in the SupplementalData messages. A server uses the extensions in a 215 similar manner in its ServerHello message. RFC5878 [AUTHZ] also 216 establishes a registry that is maintained by IANA for registering 217 authorization data formats. This document defines a new 218 authorization data type that is used in both the client_authz and 219 server_authz extensions and allows the client and server to exchange 220 DTCP certificates in the SupplementalData message. 222 2.4. Overview of supplemental data usage for authorization 224 Section 3 of RFC5878 [AUTHZ] specifies the syntax of the supplemental 225 data message when carrying the authz_data message that is negotiated 226 in the client_authz and/or server_authz types. The syntax is 227 repeated here for convenience. 229 enum { 230 authz_data(16386), (65535) 231 } SupplementalDataType; 233 struct { 234 SupplementalDataType supplemental_data_type; 235 select(SupplementalDataType) { 236 case authz_data: AuthorizationData; 237 } 238 } SupplementalData; 240 This document defines a new authorization data format that is used in 241 the authz_data message 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 3.2. DTCP Authorization Data 254 The DTCP Authorization data SHALL be sent in the authz_data message 255 when the authorization data type is dtcp_authorization. The syntax 256 of the authorization data is: 258 struct { 259 opaque random_bytes[32]; 260 } RandomNonce; 262 digitally-signed struct { 263 RandomNonce nonce; 264 opaque DTCPCert<1..2^24-1>; 265 opaque ASN.1Cert<0..2^24-1>; 266 } DigitallySignedData; 268 struct { 269 DigitallySignedData certs; 270 opaque signature[40]; 271 } dtcp_authz_data; 273 RandomNonce - generated by the server and consists of 32 bytes 274 generated by a high quality secure random number generator. The 275 dtcp_authz_data message MUST always contain a RandomNonce to avoid 276 replay attacks. 278 If the ASN.1 Certificate is being sent in the structure above, it 279 MUST be the same as the sender's certificate that will be sent in the 280 Certificate or ClientCertificate message. 282 DigitallySignedData - contains the RandomNonce, DTCP Certificate and 283 the optional ASN.1 Certificate. This is then followed by the digital 284 signature covering the RandomNonce, DTCP Certificate and the ASN.1 285 certificate if it is present. The signature is generated using the 286 private key associated with the DTCP certificate using an Elliptic 287 Curve Digital Signature Algorithm (EC-DSA) and SHA-1 Hash Algorithm 288 as specified in Section 4.4 of [DTCP]. This signature provides proof 289 of the possession of the private key by the sender. A sender sending 290 its own DTCP Certificate MUST populate the certs field. 292 3.3. Usage rules for clients to exchange DTCP Authorization data 294 A client MUST include both the client_authz and server_authz 295 extensions in the extended client hello message when indicating its 296 desire to exchange DTCP authorization data with the server. 297 Additionally the client MUST use the authorization data type 298 specified in Section 3.1 in the extension_data field to specify the 299 format of the authorization data. A client will receive the server's 300 dtcp_authz_data before it sends its own dtcp_authz_data. When 301 sending its own dtcp_authz_data message, the client MUST NOT generate 302 a RandomNonce and MUST use the same RandomNonce that it receives in 303 the server's dtcp_authz_data message. A client MUST include its DTCP 304 Certificate in the dtcp_authz_data message. A client MAY include its 305 ASN.1 Certificate in the certs field to cryptographically tie its 306 dtcp_authz_data with the TLS session being established. 308 3.4. Usage rules for servers to exchange DTCP Authorization data 310 A server MUST respond with both the client_authz and server_authz 311 extensions in the extended server hello message when indicating its 312 desire to exchange dtcp_authorization data with the client. 313 Additionally the server MUST use the authorization data type 314 specified in Section 3.1 in the extension_data field to specify the 315 format of the dtcp_authorization data. A server MUST always generate 316 and populate the RandomNonce in the dtcp_authz_data message. If the 317 client's hello message does not contain both the client_authz and 318 server_authz extensions with dtcp_authorization type, the server 319 SHALL NOT include support for dtcp_authorization data in its hello 320 message. A server MAY include its DTCP Certificate in the 321 dtcp_authz_data message. IF the server includes its DTCP 322 Certificate, it MUST also include its ASN.1 Certificate in the certs 323 field to cryptographically tie its dtcp_authz_data with the TLS 324 session being established. 326 3.5. TLS message exchange with dtcp_authz_data 328 Based on the usage rules in the sections above, the Figure 2 (Figure 329 2) below provides a possible TLS message exchange where the client 330 sends its DTCP Certificate to the server within the dtcp_authz_data 331 message. 333 Client Server 335 ClientHello (with extensions) --------> 337 ServerHello(with extensions) 338 SupplementalData(with Nonce N1) 339 Certificate 340 ServerKeyExchange* 341 CertificateRequest 342 <-------- ServerHelloDone 344 SupplementalData(with Data D1) 345 Certificate 346 ClientKeyExchange 347 CertificateVerify 348 [ChangeCipherSpec] 349 Finished --------> 350 [ChangeCipherSpec] 351 <-------- Finished 352 Application Data <-------> Application Data 354 N1 Random nonce generated by server 356 D1 Contains dtcp_authz_data populated with the following 357 {(N1, DTCP Cert, Client X.509 Cert) Signature covering all three elements} 359 * Indicates optional or situation-dependent messages that are 360 not always sent. 362 [] Indicates that ChangeCipherSpec is an independent TLS 363 protocol content type; it is not a TLS handshake message. 365 Figure 2 367 3.6. Alert Messages 369 This document reuses TLS Alert messages for any errors that arise 370 during authorization processing, while preserving the AlertLevels as 371 specified in [AUTHZ]. Additionally the following AlertDescription 372 values SHALL be used to report errors in dtcp_authorization 373 processing: 375 unsupported_extension: 376 In dtcp_authorization processing a client uses this when 377 it receives a server hello message that indicates support 378 for only one of client_authz or server_authz extension. 379 This message is always fatal. 381 4. Acknowledgements 383 This document derives its structure and much of its content from 384 [SuppData], [AUTHZ] and [RFC6042]. 386 5. IANA Considerations 388 This document requires a new entry in the IANA-maintained TLS 389 Authorization Data Formats registry, dtcp_authorization(TBA). This 390 registry is defined in [AUTHZ]. 392 6. Security Considerations 394 In cases where the SupplementalData information is sensitive, the 395 double handshake technique described in [SuppData] can be used to 396 provide protection for the SupplementalData information. The double 397 handshake specified in [SuppData] assumes that the client knows the 398 context of the TLS session that is being set up and uses the 399 authorization extensions as needed. Figure 3 illustrates a variation 400 of the double handshake that addresses the case where the client may 401 not have a priori knowledge that it will be communicating with a 402 server capable of exchanging dtcp_authz_data (typical for https 403 usages based on [RFC2818]). In Figure 3 (Figure 3) below client's 404 Hello messages always include support for the client_authz and 405 server_authz extensions. The server simply establishes an encrypted 406 TLS tunnel with the client in the first handshake by not indicating 407 support for any authz extensions. The server initiates a second 408 handshake by sending a HelloRequest. The second handshake will 409 include server's support for authz extensions which will result in 410 SupplementalData being exchanged. 412 The double handshake mechanism is vulnerable to the TLS MITM 413 Renegotiation exploit as explained in [RFC5746]. In order to address 414 this vulnerability, clients and servers MUST use the 415 secure_renegotiation extension as specified in [RFC5746] when 416 performing a double handshake. 418 Double Handshake to protect Supplemental Data 419 Client Server 421 ClientHello (w/ extensions) --------> |0 422 ServerHello (no authz extensions) |0 423 Certificate* |0 424 ServerKeyExchange* |0 425 CertificateRequest* |0 426 <-------- ServerHelloDone |0 427 Certificate* |0 428 ClientKeyExchange |0 429 CertificateVerify* |0 430 [ChangeCipherSpec] |0 431 Finished --------> |1 432 [ChangeCipherSpec] |0 433 <-------- Finished |1 434 <-------- HelloRequest |1 435 ClientHello (w/ extensions) --------> |1 436 ServerHello (w/ extensions) |1 437 SupplementalData* |1 438 Certificate* |1 439 ServerKeyExchange* |1 440 CertificateRequest* |1 441 <-------- ServerHelloDone |1 442 SupplementalData* |1 443 Certificate* |1 444 ClientKeyExchange |1 445 CertificateVerify* |1 446 [ChangeCipherSpec] |1 447 Finished --------> |2 448 [ChangeCipherSpec] |1 449 <-------- Finished |2 450 Application Data <-------> Application Data |2 452 * Indicates optional or situation-dependent messages. 454 Figure 3 456 There are no additional security considerations beyond those 457 discussed in [DTCP], [DTCP-IP] and [AUTHZ]. 459 7. References 461 7.1. Normative References 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, March 1997. 466 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0 ", 467 RFC 2246, January 1999, . 470 [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1 471 ", RFC 4346, April 2006, . 474 [RFC5246] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2 475 ", RFC 5246, August 2008, . 478 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 479 "Transport Layer Security (TLS) Renegotiation Indication 480 Extension ", RFC 5746, February 2010, . 483 [SuppData] 484 Santesson, S., "TLS Handshake Message for Supplemental 485 Data", September 2006, . 488 [AUTHZ] Brown, M. and R. Housley, "Transport Layer Security (TLS) 489 Authorization Extensions ", RFC 5878, May 2010, . 492 [DTCP] Digital Transmission Licensing Administrator, "Digital 493 Transmission Content Protection", , . 496 [DTCP-IP] Digital Transmission Licensing Administrator, "DTCP Volume 497 1 Supplement E", , . 500 7.2. Informative References 502 [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, 503 June 1999. 505 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 506 Text on Security Considerations", BCP 72, RFC 3552, July 507 2003. 509 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 510 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 511 May 2008. 513 [DTLA] Digital Transmission Licensing Administrator, "DTLA", , 514 . 516 [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000, . 519 [RFC6042] Keromytis, A., "Transport Layer Security (TLS) 520 Authorization Using KeyNote ", RFC 6042, October 2010, 521 . 523 Appendix A. Additional Stuff 525 This becomes an Appendix. 527 Author's Address 529 D. Thakore 530 Cable Television Laboratories, Inc. 531 858 Coal Creek Circle 532 Louisville, CO 80023 533 USA 535 Email: d.thakore@cablelabs.com