idnits 2.17.1 draft-dthakore-tls-authz-09.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 : ---------------------------------------------------------------------------- ** 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 (February 2, 2015) is 3371 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 604, but not defined -- Looks like a reference, but probably isn't: '32' on line 260 == Unused Reference: 'RFC2629' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 523, 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 normative reference: RFC 6347 (Obsoleted by RFC 9147) -- 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: 5 errors (**), 0 flaws (~~), 4 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 2, 2015 5 Expires: August 6, 2015 7 Transport Layer Security (TLS) Authorization Using DTCP Certificate 8 draft-dthakore-tls-authz-09 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 August 6, 2015. 43 Copyright Notice 45 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3 59 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Overview of DTCP Certificates . . . . . . . . . . . . . . 4 62 2.2. Overview of Supplemental Data handshake . . . . . . . . . 4 63 2.3. Overview of authorization extensions . . . . . . . . . . 5 64 2.4. Overview of supplemental data usage for authorization . . 6 65 3. DTCP Authorization Data Format . . . . . . . . . . . . . . . 6 66 3.1. DTCP Authorization Type . . . . . . . . . . . . . . . . . 6 67 3.2. DTCP Authorization Data . . . . . . . . . . . . . . . . . 6 68 3.3. Usage rules for clients to exchange DTCP Authorization 69 data . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.4. Usage rules for servers to exchange DTCP Authorization 71 data . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.5. TLS message exchange with dtcp_authz_data . . . . . . . . 8 73 3.6. Alert Messages . . . . . . . . . . . . . . . . . . . . . 9 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 7.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 13 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 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 159 public/private key pair generated by the DTLA. (See Section 4.3 160 of [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 struct { 264 opaque RandomNonce nonce; 265 opaque DTCPCert<0..2^24-1>; 266 opaque ASN.1Cert<0..2^24-1>; 267 opaque signature<0..2^16-1>; 268 } dtcp_authz_data; 270 RandomNonce is generated by the server and consists of 32 bytes 271 generated by a high quality secure random number generator. The 272 client always sends back the server generated RandomNonce in its 273 dtcp_authz_data structure. The RandomNonce helps the server in 274 detecting replay attacks. A client can detect replay attacks by 275 associating the ASN.1 Certificate in the dtcp_authz_data structure 276 with the certificate received in the Certificate message of the TLS 277 handshake so a separate nonce for the client is not required. 279 DTCPCert is the sender's DTCP certificate, see Section 4.2.3.1 of the 280 DTCP Specification [DTCP] 282 ASN.1Cert is the sender's certificate used to establish the TLS 283 session, i.e. sent in the Certificate or ClientCertificate message 284 using the Certificate structure defined in Section 7.4.2 of 285 [RFC5246]. 287 The DTCPCert and ASN.1Cert are variable length vectors as specified 288 in Section 4.3 of [RFC5246]. Hence the actual length precedes the 289 vector's contents in the byte stream. If the ASN.1Cert is not being 290 sent, the ASN.1Cert_length MUST be zero. 292 dtcp_authz_data - contains the RandomNonce, DTCP Certificate and the 293 optional ASN.1 Certificate. This is then followed by the digital 294 signature covering the RandomNonce, DTCP Certificate and the ASN.1 295 certificate (if present). The signature is generated using the 296 private key associated with the DTCP certificate using the Signature 297 Algorithm and Hash Algorithm as specified in Section 4.4 of [DTCP]. 298 This signature provides proof of the possession of the private key by 299 the sender. A sender sending its own DTCP Certificate MUST populate 300 this field. The length of the signature field is determined by the 301 Signature Algorithm and Hash Algorithm as specified in Section 4.4 of 302 [DTCP] and so it is not explicitly encoded in the dtcp_authz_data 303 structure (e.g. The length will be 40 bytes for SHA1+ECDSA algorithm 304 combination). 306 3.3. Usage rules for clients to exchange DTCP Authorization data 308 A client includes both the client_authz and server_authz extensions 309 in the extended client hello message when indicating its desire to 310 exchange DTCP authorization data with the server. Additionally, the 311 client includes the AuthzDataFormat type specified in Section 3.1 in 312 the extension_data field to specify the format of the authorization 313 data. 315 A client will receive the server's dtcp_authz_data before it sends 316 its own dtcp_authz_data. When sending its own dtcp_authz_data 317 message, the client includes the same RandomNonce that it receives in 318 the server's dtcp_authz_data message. Clients MUST include its DTCP 319 Certificate in the dtcp_authz_data message. Clients MAY include its 320 ASN.1 Certificate (certificate in the ClientCertificate message) in 321 the ASN.1Cert field of the dtcp_authz_data to cryptographically tie 322 the dtcp_authz_data with its ASN.1Cert being used to establish the 323 TLS session (i.e. sent in the ClientCertificate message). 325 3.4. Usage rules for servers to exchange DTCP Authorization data 327 A server responds with both the client_authz and server_authz 328 extensions in the extended server hello message when indicating its 329 desire to exchange dtcp_authorization data with the client. 330 Additionally, the server includes the AuthzDataFormat type specified 331 in Section 3.1 in the extension_data field to specify the format of 332 the dtcp_authorization data. A client may or may not include an 333 ASN.1 Cerificate during the TLS handshake. However, the server will 334 not know that at the time of sending the SupplementalData message. 335 Hence a server MUST generate and populate the RandomNonce in the 336 dtcp_authz_data message. If the client's hello message does not 337 contain both the client_authz and server_authz extensions with 338 dtcp_authorization type, the server MUST NOT include support for 339 dtcp_authorization data in its hello message. A server MAY include 340 its DTCP Certificate in the dtcp_authz_data message. If the server 341 does not send a DTCP Certificate, it will send only the RandomNonce 342 in its dtcp_authz_data message. If the server includes its DTCP 343 Certificate, it MUST also include its server certificate (sent in the 344 TLS Certificate message) in the certs field to cryptographically tie 345 its dtcp_authz_data with the ASN.1 Certificate used in the TLS 346 session being established. This also helps the client in detecting 347 replay attacks. 349 3.5. TLS message exchange with dtcp_authz_data 351 Based on the usage rules in the sections above, Figure 2 (Figure 2) 352 below provides one possible TLS message exchange where the client 353 sends its DTCP Certificate to the server within the dtcp_authz_data 354 message. 356 Client Server 358 ClientHello (with extensions) --------> 360 ServerHello(with extensions) 361 SupplementalData(with Nonce N1) 362 Certificate 363 ServerKeyExchange* 364 CertificateRequest 365 <-------- ServerHelloDone 367 SupplementalData(with Data D1) 368 Certificate 369 ClientKeyExchange 370 CertificateVerify 371 [ChangeCipherSpec] 372 Finished --------> 373 [ChangeCipherSpec] 374 <-------- Finished 375 Application Data <-------> Application Data 377 N1 Random nonce generated by server 379 D1 Contains dtcp_authz_data populated with the following 380 {(N1, DTCP Cert, Client X.509 Cert) Signature over all elements} 382 * Indicates optional or situation-dependent messages that are 383 not always sent. 385 [] Indicates that ChangeCipherSpec is an independent TLS 386 protocol content type; it is not a TLS handshake message. 388 Figure 2 390 3.6. Alert Messages 392 This document reuses TLS Alert messages for any errors that arise 393 during authorization processing, and reuses the AlertLevels as 394 specified in [RFC5878]. Additionally the following AlertDescription 395 values are used to report errors in dtcp_authorization processing: 397 unsupported_extension: 398 During processing of dtcp_authorization, a client uses this 399 when it receives a server hello message that includes support 400 for dtcp_authorization in only one of client_authz or 401 server_authz but not in both the extensions. 402 This message is always fatal. 403 Note: Completely omitting the dtcp_authorization extension 404 and/or omitting the client_authz and server_authz completely 405 is allowed and should not constitute the reason that this 406 alert is sent. 408 certificate_unknown: 409 During processing of dtcp_authorization, a client or server 410 uses this when it has received an X.509 certificate in the 411 dtcp_authorization data and that X.509 certificate does 412 not match the certificate sent in the corresponding 413 ClientCertificate or Certificate message. 415 4. IANA Considerations 417 This document proposes a new entry to be registered in the IANA- 418 maintained TLS Authorization Data Formats registry for 419 dtcp_authorization(TBA). This registry is defined in [RFC5878] and 420 defines two ranges: one is IETF review and the other is specification 421 required. The value for dtcp_authorization should be assigned via 422 [RFC5226] Specification Required. The extension defined in this 423 document is compatible with DTLS [RFC6347] and the registry 424 assignment should be marked "Y" for DTLS-OK. 426 Note to RFC Editor: Please populate the number assigned by IANA in 427 TBA above. 429 5. Security Considerations 431 The dtcp_authorization data as specified in this document carries the 432 DTCP Certificate that identifies the associated device. Inclusion of 433 the X.509 Certificate being used to establish a TLS Session in the 434 dtcp_authorization data allows an application to cryptographically 435 tie them. However a TLS Client is not required to (and may not 436 possess) an X.509 Certificate. In this case, the dtcp_authorization 437 data exchange is prone to a man-in-the-middle attack. In such 438 situations, a TLS server MUST deny access to the application features 439 dependent on the DTCP Certificate or use a double handshake. The 440 double handshake mechanism is also vulnerable to the TLS MITM 441 Renegotiation exploit as explained in [RFC5746]. In order to address 442 this vulnerability, clients and servers MUST use the 443 secure_renegotiation extension as specified in [RFC5746] when 444 exchanging dtcp_authorization data. Additionally, the renegotiation 445 is also vulnerable to the Triple Handshake exploit. To mitigate 446 this, servers MUST use the same ASN.1 certificate during 447 renegotiation as the one used in the initial handshake. 449 It should be noted that for double handshake to succeed, any 450 extension (e.g., TLS Session Ticket [RFC5077]) that results in the 451 TLS Handshake sequence being modified may result in failure to 452 exchange SupplementalData. 454 Additionally the security considerations specified in [RFC5878] and 455 [RFC5246] apply to the extension specified in this document. In 456 addition, the dtcp_authorization data may be carried along with other 457 supplemental data or some other authorization data and that 458 information may require additional protection. Finally, implementers 459 should also reference [DTCP] and [DTCP-IP] for more information 460 regarding DTCP certificates, their usage and associated security 461 considerations. 463 6. Acknowledgements 465 The author wishes to thank Mark Brown, Sean Turner, Sumanth 466 Channabasappa; and the Chairs (EKR, Joe Saloway) and members of the 467 TLS Working Group who provided feedback and comments on one or more 468 revisions of this document. 470 This document derives its structure and much of its content from 471 [RFC4680], [RFC5878] and [RFC6042]. 473 7. References 475 7.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, March 1997. 480 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 481 RFC 2246, January 1999, 482 . 484 [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 485 1.1", RFC 4346, April 2006, 486 . 488 [RFC5246] Dierks, T. and E. Rescorla, "The TLS Protocol Version 489 1.2", RFC 5246, August 2008, 490 . 492 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 493 "Transport Layer Security (TLS) Renegotiation Indication 494 Extension", RFC 5746, February 2010, 495 . 497 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 498 Data", September 2006, 499 . 501 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 502 Authorization Extensions", RFC 5878, May 2010, 503 . 505 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 506 Security Version 1.2", RFC 6347, Jan 2012, 507 . 509 [DTCP] Digital Transmission Licensing Administrator, "Digital 510 Transmission Content Protection", 511 . 514 [DTCP-IP] Digital Transmission Licensing Administrator, "DTCP Volume 515 1 Supplement E", . 518 7.2. Informative References 520 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 521 June 1999. 523 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 524 Text on Security Considerations", BCP 72, RFC 3552, July 525 2003. 527 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 528 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 529 May 2008. 531 [DTLA] Digital Transmission Licensing Administrator, "DTLA", 532 . 534 [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000, 535 . 537 [RFC5077] Salowey, J. and P. Eronen, "Transport Layer Security (TLS) 538 Session Resumption without Server-Side State", RFC 5077, 539 January 2008, . 541 [RFC6042] Keromytis, A., "Transport Layer Security (TLS) 542 Authorization Using KeyNote", RFC 6042, October 2010, 543 . 545 Appendix A. Additional Stuff 547 This document specifies a TLS authorization data extension that 548 allows TLS clients and servers to exchange DTCP certificates during a 549 TLS handshake exchange. In cases where the supplemental data 550 contains sensitive information, the double handshake technique 551 described in [RFC4680] can be used to provide protection for the 552 supplemental data information. The double handshake specified in 553 [RFC4680] assumes that the client knows the context of the TLS 554 session that is being set up and uses the authorization extensions as 555 needed. Figure 3 illustrates a variation of the double handshake 556 that addresses the case where the client may not have a priori 557 knowledge that it will be communicating with a server capable of 558 exchanging dtcp_authz_data (typical for https connections; see 559 [RFC2818]). In Figure 3 (Figure 3), the client's Hello messages 560 includes the client_authz and server_authz extensions. The server 561 simply establishes an encrypted TLS session with the client in the 562 first handshake by not indicating support for any authz extensions. 563 The server initiates a second handshake by sending a HelloRequest. 564 The second handshake will include server's support for authz 565 extensions which will result in SupplementalData being exchanged. 567 Alternately, it is also possible to do a double handshake where the 568 server sends the authorization extensions during both the first and 569 the second handshake. Depending on the information received in the 570 first handshake, the server can decide if a second handshake is 571 needed or not. 573 Double Handshake to protect Supplemental Data 575 Client Server 577 ClientHello (w/ extensions) --------> |0 578 ServerHello (no authz extensions) |0 579 Certificate* |0 580 ServerKeyExchange* |0 581 CertificateRequest* |0 582 <-------- ServerHelloDone |0 583 Certificate* |0 584 ClientKeyExchange |0 585 CertificateVerify* |0 586 [ChangeCipherSpec] |0 587 Finished --------> |1 588 [ChangeCipherSpec] |0 589 <-------- Finished |1 590 <-------- HelloRequest |1 591 ClientHello (w/ extensions) --------> |1 592 ServerHello (w/ extensions) |1 593 SupplementalData* |1 594 Certificate* |1 595 ServerKeyExchange* |1 596 CertificateRequest* |1 597 <-------- ServerHelloDone |1 598 SupplementalData* |1 599 Certificate* |1 600 ClientKeyExchange |1 601 CertificateVerify* |1 602 [ChangeCipherSpec] |1 603 Finished --------> |2 604 [ChangeCipherSpec] |1 605 <-------- Finished |2 606 Application Data <-------> Application Data |2 608 * Indicates optional or situation-dependent messages. 610 Figure 3 612 Author's Address 614 D. Thakore 615 Cable Television Laboratories, Inc. 616 858 Coal Creek Circle 617 Louisville, CO 80023 618 USA 620 Email: d.thakore@cablelabs.com