-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-ietf-dance-tls-clientid.xml
350 lines (345 loc) · 18 KB
/
draft-ietf-dance-tls-clientid.xml
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
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-dance-tls-clientid-03" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="TLS DANE ClientID Extension">TLS Extension for DANE Client Identity</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-dance-tls-clientid-03"/>
<author fullname="Shumon Huque" initials="S." surname="Huque">
<organization>Salesforce</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<author fullname="Viktor Dukhovni" initials="V." surname="Dukhovni">
<organization>Two Sigma</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date day="08" month="01" year="2024"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>TLS</keyword>
<keyword>Extension</keyword>
<keyword>DANE</keyword>
<keyword>Client</keyword>
<keyword>Identity</keyword>
<abstract>
<t>
This document specifies a TLS and DTLS extension to convey a
DNS-Based Authentication of Named Entities (DANE) Client Identity
to a TLS or DTLS server. This is useful for applications that
perform TLS client authentication via DANE TLSA records.
</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>
This document specifies a <xref target="RFC6066" format="default">
Transport Layer Security (TLS) extension</xref> to convey a
<xref target="RFC6698" format="default">DANE</xref>
Client Identity to the TLS server. This is useful for
applications that perform TLS client authentication
via DANE TLSA records, as described in
<xref target="DANECLIENT" format="default"/>. The extension could be
empty to indicate to the server that the client has a DANE record and
that the server can perform DANE authentication of the client with
the identity extracted from the client certificate. Or the extension
can contain the full client identity, in the form of the DNS domain
name that is expected to have a DANE TLSA record published for it.
</t>
<t>
This extension supports both TLS <xref target="RFC5246" format="default"/>
<xref target="RFC8446" format="default"/> and <xref target="RFC6347" format="default">DTLS
</xref>, and the term TLS in this document is used generically
to describe both protocols. It is presently defined to work for
both TLS 1.2 and 1.3 versions, and is expected to work with newer
versions going forward.
</t>
</section>
<section anchor="Overview" numbered="true" toc="default">
<name>Overview</name>
<t>
When TLS clients use X.509 client certificates or raw public
keys that are authenticated via DANE TLSA records, it is useful
for them to convey their intent to be authenticated via DANE, or
even to convey their complete DANE identity to the server. The TLS
extension defined in this document is used to accomplish this.
</t>
<t>
In the case of X.509 client certificates, a TLS server can
learn the client's identity by examining subject alternative
names included in the certificate itself. However, without a
mechanism such as the one defined in this extension, the TLS
server cannot know apriori that the client has a published
TLSA record, and thus may unnecessarily issue DNS queries for
DANE TLSA records in-band with the TLS handshake even in cases
where the client has no TLSA record associated with it. When
multiple identities are present in the certificate, a client
MUST use this extension to specify exactly which one the server
should use. An additional situation in which this extension
helps is where some TLS servers may need to selectively prompt
for client certificate credentials only for clients that are
equipped to provide certificates.
</t>
<t>
When <xref target="RFC7250" format="default">TLS raw public
keys</xref> are being used to authenticate the client, the
client MUST use this extension to explicitly indicate to the
server what its domain name identity is (since there is no
X.509 certificate from which the identity can be extracted).
</t>
<t>
Detailed protocol behavior of TLS clients and servers is
described in <xref target="DANECLIENT" format="default"/>.
</t>
</section>
<section numbered="true" toc="default">
<name>DANE Client Identity Extension</name>
<t>
The DANE Client Identity Extension type, "dane_clientid",
will have a value assigned and registered in the IANA
TLS Extensions registry. Its extension data (if not
empty) has the following format:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
opaque ClientName<1..2^8-1>;
]]></artwork>
<t>
The ClientName field contains the single domain name of
the client in textual presentation format, as described in
<xref target="RFC1035" format="default">RFC 1035</xref>,
omitting the trailing dot.
</t>
<t>
The wire format of a domain name is limited to 255 octets.
In keeping with the practice of most TLS extensions, this
extension specifies the use of the textual presentation
format of domain names instead. In theory, the presentation
format can exceed 255 characters because it allows the
expression of any arbitrary octet with the "\DDD" sequence
of characters (where DDD is the decimal value). Applications
using this extension (and the DANE TLSA Client Authentication
protocol more generally) should ensure that client domain names
being used do not need to resort to the \DDD syntax by limiting
the alphabet suitably, such as only allowing letters, digits,
hyphens, and underscores. This ensures that the presentation
format client domain name will comfortably fit within the 255
octet limit.
</t>
<t>
A TLS server implementing this specification MUST send
an empty extension of type "dane_clientid" to indicate that
it understands the extension and is capable of performing
DANE client authentication. In TLS 1.2, the empty extension
is sent in the ServerHello message. In TLS 1.3, it is sent
in the CertificateRequest message.
</t>
<t>
A TLS client implementing this specification and intending to
use DANE client authentication the TLS server, MUST send
an extension of type "dane_clientid". If the client only needs
to indicate that it has a DANE record and that the client's
domain name identity can be obtained from its certificate, then
the extension sent can be empty. If the client needs to send
its domain name identity, then the "extension_data" field
of the extension MUST contain a "ClientName" data structure
populated with the domain name.
</t>
<t>
In TLS 1.2, the client extension is sent in the ClientHello message.
In TLS 1.3, it is sent in the Certificate message. Additionally, in
TLS 1.3, the client is only permitted to send the extension if it
sees the corresponding empty extension in the server's
CertificateRequest message.
</t>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
In TLS 1.3, this extension is sent in the CertificateRequest
and Certificate messages, which are encrypted.
</t>
<t>
In TLS 1.2, this extension cannot be encrypted. When used
with TLS 1.2, to prevent unnecessary privacy leakage of the
client's name in cleartext, a TLS client implementing this
specification should be configured to only send this extension
to TLS servers it intends to perform client authentication with.
</t>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
This extension requires the registration of a new value in the
TLS ExtensionsType registry.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references>
<name>Normative References</name>
<reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<front>
<title>Domain names - implementation and specification</title>
<author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
<organization/>
</author>
<date year="1987" month="November"/>
<abstract>
<t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<seriesInfo name="DOI" value="10.17487/RFC1035"/>
</reference>
<reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5246" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials="T." surname="Dierks" fullname="T. Dierks">
<organization/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2008" month="August"/>
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5246"/>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2018" month="August"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6066" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml">
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
<organization/>
</author>
<date year="2011" month="January"/>
<abstract>
<t>This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6066"/>
<seriesInfo name="DOI" value="10.17487/RFC6066"/>
</reference>
<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<author initials="N." surname="Modadugu" fullname="N. Modadugu">
<organization/>
</author>
<date year="2012" month="January"/>
<abstract>
<t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6347"/>
<seriesInfo name="DOI" value="10.17487/RFC6347"/>
</reference>
<reference anchor="RFC6698" target="https://www.rfc-editor.org/info/rfc6698" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml">
<front>
<title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</title>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization/>
</author>
<author initials="J." surname="Schlyter" fullname="J. Schlyter">
<organization/>
</author>
<date year="2012" month="August"/>
<abstract>
<t>Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6698"/>
<seriesInfo name="DOI" value="10.17487/RFC6698"/>
</reference>
<reference anchor="RFC7250" target="https://www.rfc-editor.org/info/rfc7250" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml">
<front>
<title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
<author initials="P." surname="Wouters" fullname="P. Wouters" role="editor">
<organization/>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig" role="editor">
<organization/>
</author>
<author initials="J." surname="Gilmore" fullname="J. Gilmore">
<organization/>
</author>
<author initials="S." surname="Weiler" fullname="S. Weiler">
<organization/>
</author>
<author initials="T." surname="Kivinen" fullname="T. Kivinen">
<organization/>
</author>
<date year="2014" month="June"/>
<abstract>
<t>This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7250"/>
<seriesInfo name="DOI" value="10.17487/RFC7250"/>
</reference>
<reference anchor="DANECLIENT" target="https://tools.ietf.org/html/draft-huque-dane-client-cert">
<front>
<title>TLS Client Authentication via DANE TLSA Records</title>
<author fullname="Shumon Huque" initials="S" surname="Huque"/>
<author fullname="Viktor Dukhovni" initials="V" surname="Dukhovni"/>
<author fullname="Ash Wilson" initials="A" surname="Wilson"/>
<date day="2" month="5" year="2021"/>
</front>
</reference>
</references>
</back>
</rfc>