1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
|
<pre>Independent Submission D. Thakore
Request for Comments: 7562 CableLabs
Category: Informational July 2015
ISSN: 2070-1721
<span class="h1">Transport Layer Security (TLS) Authorization Using</span>
<span class="h1">Digital Transmission Content Protection (DTCP) Certificates</span>
Abstract
This document specifies the use of Digital Transmission Content
Protection (DTCP) certificates as an authorization data type in the
authorization extension for the Transport Layer Security (TLS)
protocol. This is in accordance with the guidelines for
authorization extensions as specified in <a href="./rfc5878">RFC 5878</a>. As with other TLS
extensions, this authorization data can be included in the client and
server hello messages to confirm that both parties support the
desired authorization data types. If supported by both the client
and the server, DTCP certificates are exchanged in the supplemental
data TLS handshake message as specified in <a href="./rfc4680">RFC 4680</a>. This
authorization data type extension is in support of devices containing
DTCP certificates issued by the Digital Transmission Licensing
Administrator (DTLA).
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7562">http://www.rfc-editor.org/info/rfc7562</a>.
<span class="grey">Thakore Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Applicability Statement ....................................<a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Conventions ................................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Overview ........................................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Overview of DTCP Certificates ..............................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Overview of SupplementalData Handshake .....................<a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Overview of Authorization Extensions .......................<a href="#page-5">5</a>
<a href="#section-2.4">2.4</a>. Overview of SupplementalData Usage for Authorization .......<a href="#page-6">6</a>
<a href="#section-3">3</a>. DTCP Authorization Data Format ..................................<a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. DTCP Authorization Type ....................................<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. DTCP Authorization Data ....................................<a href="#page-6">6</a>
3.3. Usage Rules for Clients to Exchange DTCP
Authorization Data .........................................<a href="#page-7">7</a>
3.4. Usage Rules for Servers to Exchange DTCP
Authorization Data .........................................<a href="#page-8">8</a>
<a href="#section-3.5">3.5</a>. TLS Message Exchange with dtcp_authz_data ..................<a href="#page-8">8</a>
<a href="#section-3.6">3.6</a>. Alert Messages .............................................<a href="#page-9">9</a>
<a href="#section-4">4</a>. IANA Considerations ............................................<a href="#page-10">10</a>
<a href="#section-5">5</a>. Security Considerations ........................................<a href="#page-10">10</a>
<a href="#section-6">6</a>. References .....................................................<a href="#page-11">11</a>
<a href="#section-6.1">6.1</a>. Normative References ......................................<a href="#page-11">11</a>
<a href="#section-6.2">6.2</a>. Informative References ....................................<a href="#page-12">12</a>
<a href="#appendix-A">Appendix A</a>. Alternate Double Handshake Example ....................<a href="#page-13">13</a>
Acknowledgements ..................................................<a href="#page-15">15</a>
Author's Address ..................................................<a href="#page-15">15</a>
<span class="grey">Thakore Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Transport Layer Security (TLS) protocol (see TLS 1.0 [<a href="./rfc2246" title=""The TLS Protocol Version 1.0"">RFC2246</a>],
TLS 1.1 [<a href="./rfc4346" title=""The Transport Layer Security (TLS) Protocol Version 1.1"">RFC4346</a>], and TLS1 .2 [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>]) is being used in an ever
increasing variety of operational environments, the most common among
which is its use in securing HTTP traffic [<a href="./rfc2818" title=""HTTP Over TLS"">RFC2818</a>]. [<a href="./rfc5878" title=""Transport Layer Security (TLS) Authorization Extensions"">RFC5878</a>]
introduces extensions that enable TLS to operate in environments
where authorization information needs to be exchanged between the
client and the server before any protected data is exchanged. The
use of these TLS authorization extensions is especially attractive
since it allows the client and server to determine the type of
protected data to exchange based on the authorization information
received in the extensions.
A substantial number of deployed consumer electronics devices, such
as televisions, tablets, game consoles, set-top boxes, and other
multimedia devices, contain Digital Transmission Content Protection
[<a href="#ref-DTCP" title=""Digital Transmission Content Protection Specification"">DTCP</a>] certificates issued by [<a href="#ref-DTLA" title=""DTLA"">DTLA</a>]. These DTCP certificates enable
secure transmission of premium audiovisual content between devices
over various types of links (e.g., DTCP over IP [<a href="#ref-DTCP-IP" title=""Mapping DTCP to IP"">DTCP-IP</a>]). These
DTCP certificates can also be used to verify device functionality
(e.g., supported device features).
This document describes the format and necessary identifiers to
exchange DTCP certificates within the supplemental data message (see
[<a href="./rfc4680" title=""TLS Handshake Message for Supplemental Data"">RFC4680</a>]) while negotiating a TLS session. The DTCP certificates
are then used independent of their use for content protection (e.g.,
to verify supported features) and the corresponding DTCP
Authentication and Key Exchange (AKE) protocol. This communication
allows either the client, the server, or both to perform certain
actions or provide specific services. The actual semantics of the
authorization decision by the client/server are beyond the scope of
this document. The DTCP certificate, which is not an X.509
certificate, can be cryptographically tied to the X.509 certificate
being used during the TLS tunnel establishment by an Elliptic Curve
Digital Signature Algorithm (EC-DSA) [<a href="#ref-DTCP" title=""Digital Transmission Content Protection Specification"">DTCP</a>] signature.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Applicability Statement</span>
DTCP-enabled consumer electronics devices (e.g., televisions, game
consoles) use DTCP certificates for secure transmission of
audiovisual content. The AKE protocol defined in [<a href="#ref-DTCP" title=""Digital Transmission Content Protection Specification"">DTCP</a>] is used to
exchange DTCP certificates and allows a device to be identified and
authenticated based on the information in the DTCP certificate.
However, these DTCP-enabled devices offer additional functionality
(e.g., via HTML5 User Agents or web-enabled applications) that is
distinct from its capability to transmit and play audiovisual
content. The mechanism outlined in this document allows a DTCP-
<span class="grey">Thakore Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
enabled consumer electronics device to authenticate and authorize
using its DTCP certificate when accessing services over the internet;
for example, web applications on televisions that can enable value-
added services. This is anticipated to be very valuable since there
are a considerable number of such devices. The reuse of well-known
web security will also keep such communication consistent with
existing standards and best practices.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Conventions</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Overview</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Overview of DTCP Certificates</span>
DTCP certificates issued by [<a href="#ref-DTLA" title=""DTLA"">DTLA</a>] to DTLA-compliant devices come in
three general variations (see Section 4.2.3.1 of [<a href="#ref-DTCP" title=""Digital Transmission Content Protection Specification"">DTCP</a>]):
o Restricted Authentication device certificate format (Format 0):
Typically issued to devices with limited computation resources.
o Baseline Full Authentication device certificate format (Format 1):
This is the most commonly issued certificate format. Format 1
certificates include a unique DeviceID and device EC-DSA public/
private key pair generated by the DTLA. (See Section 4.3 of
[<a href="#ref-DTCP" title=""Digital Transmission Content Protection Specification"">DTCP</a>]).
o Extended Full Authentication device certificate format (Format 2):
This is issued to devices that possess additional functions (e.g.,
additional channel ciphers, specific device properties). The
presence of these additional functions is indicated by the device
capability mask as specified in Section 4.2.3.2 of [<a href="#ref-DTCP" title=""Digital Transmission Content Protection Specification"">DTCP</a>]. Format
2 certificates also include a unique DeviceID and device EC-DSA
public/private key pair generated by the DTLA (see Section 4.3 of
[<a href="#ref-DTCP" title=""Digital Transmission Content Protection Specification"">DTCP</a>]).
The mechanism specified in this document allows only Formats 1 and 2
DTCP certificates to be exchanged in the supplemental data message
since it requires the use of the EC-DSA private key associated with
the certificate.
<span class="grey">Thakore Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Overview of SupplementalData Handshake</span>
Figure 1 illustrates the exchange of the SupplementalData message
during the TLS handshake as specified in [<a href="./rfc4680" title=""TLS Handshake Message for Supplemental Data"">RFC4680</a>] (repeated here for
convenience):
Client Server
ClientHello (with extensions) -------->
ServerHello(with extensions)
SupplementalData*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
SupplementalData*
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates optional or situation-dependent messages that are
not always sent.
[] Indicates that ChangeCipherSpec is an independent TLS
protocol content type; it is not a TLS handshake message.
Figure 1: TLS Handshake Message Exchange with SupplementalData
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Overview of Authorization Extensions</span>
[<a id="ref-RFC5878">RFC5878</a>] defines two authorization extension types that are used in
the ClientHello and ServerHello messages and are repeated below for
convenience:
enum {
client_authz(7), server_authz(8), (65535)
} ExtensionType;
A client uses the client_authz and server_authz extensions in the
ClientHello message to indicate that it will send client
authorization data and receive server authorization data,
<span class="grey">Thakore Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
respectively, in the SupplementalData messages. A server uses the
extensions in a similar manner in its ServerHello message. [<a href="./rfc5878" title=""Transport Layer Security (TLS) Authorization Extensions"">RFC5878</a>]
also establishes a registry that is maintained by IANA to register
authorization data formats. This document defines a new
authorization data type for both the client_authz and server_authz
extensions and allows the client and server to exchange DTCP
certificates in the SupplementalData message.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Overview of SupplementalData Usage for Authorization</span>
<a href="./rfc5878#section-3">Section 3 of [RFC5878]</a> specifies the syntax of the supplemental data
message when carrying the authz_data message that is negotiated in
the client_authz and/or server_authz types. This document defines a
new authorization data format that is used in the authz_data message
when sending DTCP Authorization Data.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. DTCP Authorization Data Format</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. DTCP Authorization Type</span>
The DTCP Authorization type definition in the TLS Authorization Data
Formats registry is:
dtcp_authorization(66);
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. DTCP Authorization Data</span>
The DTCP Authorization Data is used when the AuthzDataFormat type is
dtcp_authorization. The syntax of the authorization data is:
struct {
opaque random_bytes[32];
} RandomNonce;
struct {
opaque RandomNonce nonce;
opaque DTCPCert<0..2^24-1>;
opaque ASN.1Cert<0..2^24-1>;
opaque signature<0..2^16-1>;
} dtcp_authz_data;
RandomNonce is generated by the server and consists of 32 bytes
generated by a high-quality, secure random number generator. The
client always sends back the server-generated RandomNonce in its
dtcp_authz_data structure. The RandomNonce helps the server in
detecting replay attacks. A client can detect replay attacks by
<span class="grey">Thakore Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
associating the ASN.1 certificate in the dtcp_authz_data structure
with the certificate received in the Certificate message of the TLS
handshake, so a separate nonce for the client is not required.
DTCPCert is the sender's DTCP certificate. See <a href="#section-4.2.3.1">Section 4.2.3.1</a> of
the DTCP Specification [<a href="#ref-DTCP" title=""Digital Transmission Content Protection Specification"">DTCP</a>].
ASN.1Cert is the sender's certificate used to establish the TLS
session, i.e., it is sent in the Certificate or ClientCertificate
message using the Certificate structure defined in <a href="./rfc5246#section-7.4.2">Section 7.4.2 of
[RFC5246]</a>.
The DTCPCert and ASN.1Cert are variable-length vectors as specified
in <a href="./rfc5246#section-4.3">Section 4.3 of [RFC5246]</a>. Hence, the actual length precedes the
vector's contents in the byte stream. If the ASN.1Cert is not being
sent, the ASN.1Cert_length MUST be zero.
dtcp_authz_data contains the RandomNonce, the DTCP certificate, and
the optional ASN.1 certificate. This is then followed by the digital
signature covering the RandomNonce, the DTCP certificate, and the
ASN.1 certificate (if present). The signature is generated using the
private key associated with the DTCP certificate and using the
Signature Algorithm and Hash Algorithm as specified in Section 4.4 of
[<a href="#ref-DTCP" title=""Digital Transmission Content Protection Specification"">DTCP</a>]. This signature provides proof of the possession of the
private key by the sender. A sender sending its own DTCP certificate
MUST populate this field. The length of the signature field is
determined by the Signature Algorithm and Hash Algorithm as specified
in Section 4.4 of [<a href="#ref-DTCP" title=""Digital Transmission Content Protection Specification"">DTCP</a>], and so it is not explicitly encoded in the
dtcp_authz_data structure (e.g., the length will be 40 bytes for a
SHA1+ECDSA algorithm combination).
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Usage Rules for Clients to Exchange DTCP Authorization Data</span>
A client includes both the client_authz and server_authz extensions
in the extended client hello message when indicating its desire to
exchange dtcp_authorization data with the server. Additionally, the
client includes the AuthzDataFormat type specified in <a href="#section-3.1">Section 3.1</a> in
the extension_data field to specify the format of the authorization
data.
A client will receive the server's dtcp_authz_data before it sends
its own dtcp_authz_data. When sending its own dtcp_authz_data
message, the client includes the same RandomNonce that it receives in
the server's dtcp_authz_data message. Clients MUST include its DTCP
certificate in the dtcp_authz_data message. A client MAY include its
ASN.1 certificate (certificate in the ClientCertificate message) in
<span class="grey">Thakore Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
the ASN.1Cert field of the dtcp_authz_data to cryptographically tie
the dtcp_authz_data with its ASN.1Cert being used to establish the
TLS session (i.e., sent in the ClientCertificate message).
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Usage Rules for Servers to Exchange DTCP Authorization Data</span>
A server responds with both the client_authz and server_authz
extensions in the extended server hello message when indicating its
desire to exchange dtcp_authorization data with the client.
Additionally, the server includes the AuthzDataFormat type specified
in <a href="#section-3.1">Section 3.1</a> in the extension_data field to specify the format of
the dtcp_authorization data. A client may or may not include an
ASN.1 certificate during the TLS handshake. However, the server will
not know that at the time of sending the SupplementalData message.
Hence, a server MUST generate and populate the RandomNonce in the
dtcp_authz_data message. If the client's hello message does not
contain both the client_authz and server_authz extensions with
dtcp_authorization type, the server MUST NOT include support for
dtcp_authorization data in its hello message. A server MAY include
its DTCP certificate in the dtcp_authz_data message. If the server
does not send a DTCP certificate, it will send only the RandomNonce
in its dtcp_authz_data message. If the server includes its DTCP
certificate, it MUST also include its server certificate (sent in the
TLS Certificate message) in the certs field to cryptographically tie
its dtcp_authz_data with the ASN.1 certificate used in the TLS
session being established. This also helps the client in detecting
replay attacks.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. TLS Message Exchange with dtcp_authz_data</span>
Based on the usage rules in the sections above, Figure 2 provides one
possible TLS message exchange where the client sends its DTCP
certificate to the server within the dtcp_authz_data message.
<span class="grey">Thakore Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
Client Server
ClientHello (with extensions) -------->
ServerHello(with extensions)
SupplementalData(with Nonce N1)
Certificate
ServerKeyExchange*
CertificateRequest
<-------- ServerHelloDone
SupplementalData(with Data D1)
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
N1 Indicates a Random nonce generated by server
D1 Contains dtcp_authz_data populated with the following
{(N1, DTCP Cert, Client X.509 Cert) Signature over all elements}
* Indicates optional or situation-dependent messages that are
not always sent.
[] Indicates that ChangeCipherSpec is an independent TLS
protocol content type; it is not a TLS handshake message.
Figure 2: DTCP SupplementalData Exchange
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Alert Messages</span>
This document reuses TLS Alert messages for any errors that arise
during authorization processing and reuses the AlertLevels as
specified in [<a href="./rfc5878" title=""Transport Layer Security (TLS) Authorization Extensions"">RFC5878</a>]. Additionally, the following AlertDescription
values are used to report errors in dtcp_authorization processing:
unsupported_extension:
During processing of dtcp_authorization, a client uses this when
it receives a server hello message that includes support for
dtcp_authorization in only one of client_authz or server_authz but
not in both the extensions. This message is always fatal. Note:
<span class="grey">Thakore Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
Completely omitting the dtcp_authorization extension and/or
omitting the client_authz and server_authz completely is allowed
and should not constitute the reason that this alert is sent.
certificate_unknown:
During processing of dtcp_authorization, a client or server uses
this when it has received an X.509 certificate in the
dtcp_authorization data and that X.509 certificate does not match
the certificate sent in the corresponding ClientCertificate or
Certificate message.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IANA Considerations</span>
This document includes an entry registered in the IANA-maintained
"TLS Authorization Data Formats" registry for dtcp_authorization(66).
This registry is defined in [<a href="./rfc5878" title=""Transport Layer Security (TLS) Authorization Extensions"">RFC5878</a>] and defines two ranges: one is
IETF Review, and the other is Specification Required. The value for
dtcp_authorization should be assigned via [<a href="./rfc5226" title="">RFC5226</a>] Specification
Required. The extension defined in this document is compatible with
Data Transport Layer Security (DTLS) [<a href="./rfc6347" title=""Datagram Transport Layer Security Version 1.2"">RFC6347</a>], and the registry
assignment has been marked "Y" for DTLS-OK.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
The dtcp_authorization data, as specified in this document, carries
the DTCP certificate that identifies the associated device.
Inclusion of the X.509 certificate being used to establish a TLS
Session in the dtcp_authorization data allows an application to
cryptographically tie them. However, a TLS Client is not required to
use (and may not possess) an X.509 certificate. In this case, the
dtcp_authorization data exchange is prone to a man-in-the-middle
(MITM) attack. In such situations, a TLS server MUST deny access to
the application features dependent on the DTCP certificate or use a
double handshake. The double handshake mechanism is also vulnerable
to the TLS MITM Renegotiation exploit as explained in [<a href="./rfc5746" title=""Transport Layer Security (TLS) Renegotiation Indication Extension"">RFC5746</a>]. In
order to address this vulnerability, clients and servers MUST use the
secure_renegotiation extension as specified in [<a href="./rfc5746" title=""Transport Layer Security (TLS) Renegotiation Indication Extension"">RFC5746</a>] when
exchanging dtcp_authorization data. Additionally, the renegotiation
is also vulnerable to the Triple Handshake exploit. To mitigate
this, servers MUST use the same ASN.1 certificate during
renegotiation as the one used in the initial handshake.
It should be noted that for the double handshake to succeed, any
extension (e.g., TLS Session Ticket [<a href="./rfc5077" title=""Transport Layer Security (TLS) Session Resumption without Server-Side State"">RFC5077</a>]) that results in the
TLS handshake sequence being modified may result in failure to
exchange SupplementalData.
<span class="grey">Thakore Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
Additionally, the security considerations specified in [<a href="./rfc5878" title=""Transport Layer Security (TLS) Authorization Extensions"">RFC5878</a>] and
[<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] apply to the extension specified in this document. In
addition, the dtcp_authorization data may be carried along with other
supplemental data or some other authorization data and that
information may require additional protection. Finally, implementers
should also reference [<a href="#ref-DTCP" title=""Digital Transmission Content Protection Specification"">DTCP</a>] and [<a href="#ref-DTCP-IP" title=""Mapping DTCP to IP"">DTCP-IP</a>] for more information
regarding DTCP certificates, their usage, and associated security
considerations.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC2246">RFC2246</a>] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
<a href="./rfc2246">RFC 2246</a>, DOI 10.17487/RFC2246, January 1999,
<<a href="http://www.rfc-editor.org/info/rfc2246">http://www.rfc-editor.org/info/rfc2246</a>>.
[<a id="ref-RFC4346">RFC4346</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", <a href="./rfc4346">RFC 4346</a>,
DOI 10.17487/RFC4346, April 2006,
<<a href="http://www.rfc-editor.org/info/rfc4346">http://www.rfc-editor.org/info/rfc4346</a>>.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>,
DOI 10.17487/RFC5246, August 2008,
<<a href="http://www.rfc-editor.org/info/rfc5246">http://www.rfc-editor.org/info/rfc5246</a>>.
[<a id="ref-RFC5746">RFC5746</a>] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", <a href="./rfc5746">RFC 5746</a>, DOI 10.17487/RFC5746, February 2010,
<<a href="http://www.rfc-editor.org/info/rfc5746">http://www.rfc-editor.org/info/rfc5746</a>>.
[<a id="ref-RFC4680">RFC4680</a>] Santesson, S., "TLS Handshake Message for Supplemental
Data", <a href="./rfc4680">RFC 4680</a>, DOI 10.17487/RFC4680, October 2006,
<<a href="http://www.rfc-editor.org/info/rfc4680">http://www.rfc-editor.org/info/rfc4680</a>>.
[<a id="ref-RFC5878">RFC5878</a>] Brown, M. and R. Housley, "Transport Layer Security (TLS)
Authorization Extensions", <a href="./rfc5878">RFC 5878</a>, DOI 10.17487/RFC5878,
May 2010, <<a href="http://www.rfc-editor.org/info/rfc5878">http://www.rfc-editor.org/info/rfc5878</a>>.
[<a id="ref-RFC6347">RFC6347</a>] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", <a href="./rfc6347">RFC 6347</a>, DOI 10.17487/RFC6347,
January 2012, <<a href="http://www.rfc-editor.org/info/rfc6347">http://www.rfc-editor.org/info/rfc6347</a>>.
<span class="grey">Thakore Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
[<a id="ref-DTCP">DTCP</a>] Digital Transmission Licensing Administrator, "Digital
Transmission Content Protection Specification", Volume 1,
Informational Version,
<<a href="http://www.dtcp.com/documents/dtcp/info-20130605-dtcp-v1-rev-1-7-ed2.pdf">http://www.dtcp.com/documents/dtcp/</a>
<a href="http://www.dtcp.com/documents/dtcp/info-20130605-dtcp-v1-rev-1-7-ed2.pdf">info-20130605-dtcp-v1-rev-1-7-ed2.pdf</a>>.
[<a id="ref-DTCP-IP">DTCP-IP</a>] Digital Transmission Licensing Administrator, "Mapping
DTCP to IP", Volume 1, Supplement E, Informational
Version, <<a href="http://www.dtcp.com/documents/dtcp/info-20130605-dtcp-v1se-ip-rev-1-4-ed3.pdf">http://www.dtcp.com/documents/dtcp/</a>
<a href="http://www.dtcp.com/documents/dtcp/info-20130605-dtcp-v1se-ip-rev-1-4-ed3.pdf">info-20130605-dtcp-v1se-ip-rev-1-4-ed3.pdf</a>>.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
DOI 10.17487/RFC5226, May 2008,
<<a href="http://www.rfc-editor.org/info/rfc5226">http://www.rfc-editor.org/info/rfc5226</a>>.
[<a id="ref-DTLA">DTLA</a>] Digital Transmission Licensing Administrator, "DTLA",
<<a href="http://www.dtcp.com">http://www.dtcp.com</a>>.
[<a id="ref-RFC2818">RFC2818</a>] Rescorla, E., "HTTP Over TLS", <a href="./rfc2818">RFC 2818</a>,
DOI 10.17487/RFC2818, May 2000,
<<a href="http://www.rfc-editor.org/info/rfc2818">http://www.rfc-editor.org/info/rfc2818</a>>.
[<a id="ref-RFC5077">RFC5077</a>] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", <a href="./rfc5077">RFC 5077</a>, DOI 10.17487/RFC5077,
January 2008, <<a href="http://www.rfc-editor.org/info/rfc5077">http://www.rfc-editor.org/info/rfc5077</a>>.
[<a id="ref-RFC6042">RFC6042</a>] Keromytis, A., "Transport Layer Security (TLS)
Authorization Using KeyNote", <a href="./rfc6042">RFC 6042</a>,
DOI 10.17487/RFC6042, October 2010,
<<a href="http://www.rfc-editor.org/info/rfc6042">http://www.rfc-editor.org/info/rfc6042</a>>.
<span class="grey">Thakore Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Alternate Double Handshake Example</span>
This document specifies a TLS authorization data extension that
allows TLS clients and servers to exchange DTCP certificates during a
TLS handshake exchange. In cases where the supplemental data
contains sensitive information, the double handshake technique
described in [<a href="./rfc4680" title=""TLS Handshake Message for Supplemental Data"">RFC4680</a>] can be used to provide protection for the
supplemental data information. The double handshake specified in
[<a href="./rfc4680" title=""TLS Handshake Message for Supplemental Data"">RFC4680</a>] assumes that the client knows the context of the TLS
session that is being set up and uses the authorization extensions as
needed. Figure 3 illustrates a variation of the double handshake
that addresses the case where the client may not have a priori
knowledge that it will be communicating with a server capable of
exchanging dtcp_authz_data (typical for https connections; see
[<a href="./rfc2818" title=""HTTP Over TLS"">RFC2818</a>]). In Figure 3, the client's hello messages includes the
client_authz and server_authz extensions. The server simply
establishes an encrypted TLS session with the client in the first
handshake by not indicating support for any authz extensions. The
server initiates a second handshake by sending a HelloRequest. The
second handshake will include the server's support for authz
extensions, which will result in SupplementalData being exchanged.
Alternately, it is also possible to do a double handshake where the
server sends the authorization extensions during both the first and
the second handshake. Depending on the information received in the
first handshake, the server can decide whether or not a second
handshake is needed.
<span class="grey">Thakore Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
Client Server
ClientHello (w/ extensions) --------> |0
ServerHello (no authz extensions) |0
Certificate* |0
ServerKeyExchange* |0
CertificateRequest* |0
<-------- ServerHelloDone |0
Certificate* |0
ClientKeyExchange |0
CertificateVerify* |0
[ChangeCipherSpec] |0
Finished --------> |1
[ChangeCipherSpec] |0
<-------- Finished |1
<-------- HelloRequest |1
ClientHello (w/ extensions) --------> |1
ServerHello (w/ extensions) |1
SupplementalData* |1
Certificate* |1
ServerKeyExchange* |1
CertificateRequest* |1
<-------- ServerHelloDone |1
SupplementalData* |1
Certificate* |1
ClientKeyExchange |1
CertificateVerify* |1
[ChangeCipherSpec] |1
Finished --------> |2
[ChangeCipherSpec] |1
<-------- Finished |2
Application Data <-------> Application Data |2
* Indicates optional or situation-dependent messages.
Figure 3: Double Handshake to Protect SupplementalData
<span class="grey">Thakore Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7562">RFC 7562</a> TLS Auth Using DTCP July 2015</span>
Acknowledgements
The author wishes to thank Mark Brown, Sean Turner, Sumanth
Channabasappa, and the Chairs (EKR, Joe Saloway) and members of the
TLS Working Group who provided feedback and comments on one or more
revisions of this document.
This document derives its structure and much of its content from
[<a href="./rfc4680" title=""TLS Handshake Message for Supplemental Data"">RFC4680</a>], [<a href="./rfc5878" title=""Transport Layer Security (TLS) Authorization Extensions"">RFC5878</a>], and [<a href="./rfc6042" title=""Transport Layer Security (TLS) Authorization Using KeyNote"">RFC6042</a>].
Author's Address
D. Thakore
Cable Television Laboratories, Inc.
858 Coal Creek Circle
Louisville, CO 80023
United States
Email: d.thakore@cablelabs.com
Thakore Informational [Page 15]
</pre>
|
