idnits 2.17.1 draft-dthakore-tls-authz-06.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 (January 30, 2014) is 3739 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 572, 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 271 == Unused Reference: 'RFC2629' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 497, 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 (~~), 4 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 30, 2014 5 Expires: August 3, 2014 7 Transport Layer Security (TLS) Authorization Using DTCP Certificate 8 draft-dthakore-tls-authz-06 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 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 12 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 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 struct { 264 opaque RandomNonce nonce; 265 opaque DTCPCert<1..2^24-1>; 266 opaque ASN.1Cert<0..2^24-1>; 267 } DigitallySignedData; 269 struct { 270 DigitallySignedData certs; 271 opaque signature[40]; 272 } dtcp_authz_data; 274 RandomNonce is generated by the server and consists of 32 bytes 275 generated by a high quality secure random number generator. The 276 RandomNonce helps detect replay attacks. 278 DTCPCert is the sender's DTCP certificate, see Section 4.2.3.1 of the 279 DTCP Specification [DTCP] 281 ASN.1Cert is the sender's certificate used to establish the TLS 282 session, i.e. sent in the Certificate or ClientCertificate message 283 using the Certificate structure defined in Section 7.4.2 of 284 [RFC5246]. 286 The DTCPCert and ASN.1Cert are variable length vectors as specified 287 in Section 4.3 of [RFC5246]. Hence the actual length precedes the 288 vector's contents in the byte stream. If the ASN.1Cert is not being 289 sent, the ASN.1Cert_length MUST be 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. The client MAY include 315 its ASN.1 Certificate (certificate in the ClientCertificate message) 316 in the ASN.1Cert field of the dtcp_authz_data to cryptographically 317 tie the dtcp_authz_data with its ASN.1Cert being used to establish 318 the TLS session. 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 ASN.1 336 Certificate used in the TLS 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 The dtcp_authorization data as specified in this document carries the 414 DTCP Certificate that identifies the associated device. Inclusion of 415 the X.509 Certificate being used to establish a TLS Session in the 416 dtcp_authorization data allows an application to cryptographically 417 tie them. However a TLS Client is not required to (and may not 418 possess) an X.509 Certificate. In this case, the dtcp_authorization 419 data exchange is prone to a man-in-the-middle attack. In such 420 situations, a TLS server MUST deny access to the application features 421 dependent on the DTCP Certificate or use a double handshake. The 422 double handshake mechanism is also vulnerable to the TLS MITM 423 Renegotiation exploit as explained in [RFC5746]. In order to address 424 this vulnerability, clients and servers MUST use the 425 secure_renegotiation extension as specified in [RFC5746] when 426 exchanging dtcp_authorization data. 428 It should be noted that for double handshake to succeed, any 429 extension (e.g., TLS Session Ticket [RFC5077]) that results in the 430 TLS Handshake sequence being modified may result in failure to 431 exchange SupplementalData. 433 Additionally the security considerations specified in [RFC5878] and 434 [RFC5246] apply to the extension specified in this document. In 435 addition, the dtcp_authorization data may be carried along with other 436 supplemental data or some other authorization data and that 437 information may require additional protection. Finally, implementers 438 should also reference [DTCP] and [DTCP-IP] for more information 439 regarding DTCP certificates, their usage and associated security 440 considerations. 442 6. Acknowledgements 444 The author wishes to thank Mark Brown, Sean Turner, Sumanth 445 Channabasappa; and the Chairs (EKR, Joe Saloway) and members of the 446 TLS Working Group who provided feedback and comments on one or more 447 revisions of this document. 449 This document derives its structure and much of its content from 450 [RFC4680], [RFC5878] and [RFC6042]. 452 7. References 454 7.1. Normative References 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 460 RFC 2246, January 1999, 461 . 463 [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 464 1.1", RFC 4346, April 2006, 465 . 467 [RFC5246] Dierks, T. and E. Rescorla, "The TLS Protocol Version 468 1.2", RFC 5246, August 2008, 469 . 471 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 472 "Transport Layer Security (TLS) Renegotiation Indication 473 Extension", RFC 5746, February 2010, 474 . 476 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 477 Data", September 2006, 478 . 480 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 481 Authorization Extensions", RFC 5878, May 2010, 482 . 484 [DTCP] Digital Transmission Licensing Administrator, "Digital 485 Transmission Content Protection", . 488 [DTCP-IP] Digital Transmission Licensing Administrator, "DTCP Volume 489 1 Supplement E", . 492 7.2. Informative References 494 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 495 June 1999. 497 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 498 Text on Security Considerations", BCP 72, RFC 3552, July 499 2003. 501 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 502 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 503 May 2008. 505 [DTLA] Digital Transmission Licensing Administrator, "DTLA", 506 . 508 [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000, 509 . 511 [RFC5077] Salowey, J. and P. Eronen, "Transport Layer Security (TLS) 512 Session Resumption without Server-Side State", RFC 5077, 513 January 2008, . 515 [RFC6042] Keromytis, A., "Transport Layer Security (TLS) 516 Authorization Using KeyNote", RFC 6042, October 2010, 517 . 519 Appendix A. Additional Stuff 521 This document specifies a TLS authorization data extension that 522 allows TLS clients and servers to exchange DTCP certificates during a 523 TLS handshake exchange. In cases where the supplemental data 524 contains sensitive information, the double handshake technique 525 described in [RFC4680] can be used to provide protection for the 526 supplemental data information. The double handshake specified in 527 [RFC4680] assumes that the client knows the context of the TLS 528 session that is being set up and uses the authorization extensions as 529 needed. Figure 3 illustrates a variation of the double handshake 530 that addresses the case where the client may not have a priori 531 knowledge that it will be communicating with a server capable of 532 exchanging dtcp_authz_data (typical for https connections; see 533 [RFC2818]). In Figure 3 (Figure 3), the client's Hello messages 534 includes the client_authz and server_authz extensions. The server 535 simply establishes an encrypted TLS session with the client in the 536 first handshake by not indicating support for any authz extensions. 537 The server initiates a second handshake by sending a HelloRequest. 538 The second handshake will include server's support for authz 539 extensions which will result in SupplementalData being exchanged. 541 Double Handshake to protect Supplemental Data 543 Client Server 545 ClientHello (w/ extensions) --------> |0 546 ServerHello (no authz extensions) |0 547 Certificate* |0 548 ServerKeyExchange* |0 549 CertificateRequest* |0 550 <-------- ServerHelloDone |0 551 Certificate* |0 552 ClientKeyExchange |0 553 CertificateVerify* |0 554 [ChangeCipherSpec] |0 555 Finished --------> |1 556 [ChangeCipherSpec] |0 557 <-------- Finished |1 558 <-------- HelloRequest |1 559 ClientHello (w/ extensions) --------> |1 560 ServerHello (w/ extensions) |1 561 SupplementalData* |1 562 Certificate* |1 563 ServerKeyExchange* |1 564 CertificateRequest* |1 565 <-------- ServerHelloDone |1 566 SupplementalData* |1 567 Certificate* |1 568 ClientKeyExchange |1 569 CertificateVerify* |1 570 [ChangeCipherSpec] |1 571 Finished --------> |2 572 [ChangeCipherSpec] |1 573 <-------- Finished |2 574 Application Data <-------> Application Data |2 576 * Indicates optional or situation-dependent messages. 578 Figure 3 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