Internet DRAFT - draft-ietf-dance-tls-clientid
draft-ietf-dance-tls-clientid
Internet Engineering Task Force S. Huque
Internet-Draft Salesforce
Intended status: Standards Track V. Dukhovni
Expires: 11 July 2024 Two Sigma
8 January 2024
TLS Extension for DANE Client Identity
draft-ietf-dance-tls-clientid-03
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 July 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) 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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Huque & Dukhovni Expires 11 July 2024 [Page 1]
Internet-Draft TLS DANE ClientID Extension January 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. DANE Client Identity Extension . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
This document specifies a Transport Layer Security (TLS) extension
[RFC6066] to convey a DANE [RFC6698] Client Identity to the TLS
server. This is useful for applications that perform TLS client
authentication via DANE TLSA records, as described in [DANECLIENT].
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.
This extension supports both TLS [RFC5246] [RFC8446] and DTLS
[RFC6347], 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.
2. Overview
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.
Huque & Dukhovni Expires 11 July 2024 [Page 2]
Internet-Draft TLS DANE ClientID Extension January 2024
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.
When TLS raw public keys [RFC7250] 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).
Detailed protocol behavior of TLS clients and servers is described in
[DANECLIENT].
3. DANE Client Identity Extension
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:
opaque ClientName<1..2^8-1>;
The ClientName field contains the single domain name of the client in
textual presentation format, as described in RFC 1035 [RFC1035],
omitting the trailing dot.
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.
Huque & Dukhovni Expires 11 July 2024 [Page 3]
Internet-Draft TLS DANE ClientID Extension January 2024
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.
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.
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.
4. Security Considerations
In TLS 1.3, this extension is sent in the CertificateRequest and
Certificate messages, which are encrypted.
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.
5. IANA Considerations
This extension requires the registration of a new value in the TLS
ExtensionsType registry.
6. Normative References
[DANECLIENT]
Huque, S., Dukhovni, V., and A. Wilson, "TLS Client
Authentication via DANE TLSA Records", 2 May 2021,
<https://tools.ietf.org/html/draft-huque-dane-client-
cert>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
Huque & Dukhovni Expires 11 July 2024 [Page 4]
Internet-Draft TLS DANE ClientID Extension January 2024
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Authors' Addresses
Shumon Huque
Salesforce
Email: shuque@gmail.com
Viktor Dukhovni
Two Sigma
Email: ietf-dane@dukhovni.org
Huque & Dukhovni Expires 11 July 2024 [Page 5]
