TLS Client Authentication via DANE TLSA records
Salesforce
shuque@gmail.com
Two Sigma
ietf-dane@dukhovni.org
General
Internet Engineering Task Force
Internet-Draft
DANE
DNSSEC
Authentication
Client Certificate
X.509 Certificate
Raw Public Key
The DANE TLSA protocol
describes how to publish Transport Layer Security (TLS) server
certificates or public keys in the DNS. This document updates RFC
6698 and RFC 7671.
It describes how to additionally use the TLSA record to publish
client certificates or public keys, and also the rules and
considerations for using them with TLS.
Introduction and Motivation
The Transport Layer Security (TLS) protocol
optionally supports the authentication of
clients using X.509 certificates or
raw public keys. TLS applications
that perform DANE authentication of servers using TLSA records
may also desire to authenticate clients using the same mechanism,
especially if the client identity is in the form of or can be
represented by a DNS domain name. Some design patterns from the
Internet of Things (IoT) plan to make use of this form of
authentication, where large networks of physical objects identified
by DNS names may authenticate themselves using TLS to centralized
device management and control platforms.
In this document, the term TLS is used generically to describe
both the TLS and
DTLS (Datagram Transport Layer Security)
protocols.
Associating Client Identities in TLSA Records
Different applications may have quite different conventions
for naming clients via domain names. This document thus does not
proscribe a single format, but mentions a few that may have
wide applicability.
Format 1: Service specific client identity
In this format, the owner name of the client TLSA record
has the following structure:
The first label identifies the application service name. The
remaining labels are composed of the client domain name.
Encoding the application service name into the owner name allows
the same client domain name to have different authentication
credentials for different application services. There is no need
to encode the transport label - the same name form is usable with
both TLS and DTLS.
The _service label could be a custom string for an application,
but more commonly is expected to be a service name registered in
the IANA Service Name Registry.
The RDATA or data field portion of the TLSA record is formed
exactly as specified in RFC 6698 and RFC 7671, and carries the
same meaning.
Format 2: DevId: IOT Device Identity
The DevID form of the TLSA record has the following structure:
It is loosely based on the proposed
PKI Certificate Identifier Format
for Devices, but is simpler in form. It makes no
distinction between manufacturer issued and locally issued
certificates, and does away with the "serial" and "type"
labels. The "_device"
label that precedes the organization domain name allows all
the device identities to be delegated to a subzone or to another
party.
Authentication Model
The authentication model assumed in this document is the following:
The client is assigned an identity corresponding to a DNS
domain name. This domain name doesn't necessarily have any
relation to its network layer addresses. Clients often
have dynamic or unpredictable addresses, and may move around
the network, so tying their identity to network addresses is
not feasible or wise in the general case.
The client generates (or has generated for it) a private and
public key pair. Where client certificates are being used, the
client also has a certificate binding the name to its public key.
The certificate or public key has a corresponding TLSA record
published in the DNS, which allows it to be authenticated
directly via the DNS (using the DANE-TA or DANE-EE certificate
usage modes) or via a PKIX public CA system constraint if the
client's certificate was issued by a public CA (using the PKIX-TA
or PKIX-EE DANE usage modes).
Client Identifiers in X.509 certificates
If the TLS DANE Client Identity extension
(see ) is not being used, the
client certificate MUST have have the client's DNS name
specified in the Subject Alternative Name extension's dNSName
type.
If the TLS DANE Client Identity extension is in use, then with
DANE-EE(3), the subject name need not be present in the certificate.
Signaling the Client's DANE Identity in TLS
The client SHOULD explicitly signal that it has a DANE identity.
The most important reason is that the server may want an explicit
indication from the client that it has a DANE record, so as to
avoid unnecessary DNS queries in-band with the TLS handshake.
The DANE Client Identity TLS
extension is used for this purpose. This extension can also
be used to convey the actual DANE client identity (i.e. domain name)
that the TLS server should attempt to authenticate. This is required
when using TLS raw public key authentication, since there is no
client certificate from which to extract the client's DNS identity.
It is also helpful when the client certificate contains multiple
identities, and only a specific one has a DANE record.
An additional case where such client signaling is helpful, is
one where DANE client authentication is optional, and there is a
population of buggy client software that does not react gracefully
to receipt of a Certificate Request message from the TLS server.
This extension allows TLS servers to deal with this situation by
selectively sending a Certificate Request message only to clients
that have sent this extension.
Example TLSA records for clients
The following examples are provided in the textual presentation
format of the TLSA record.
Format 1: Service Specific Client Identity
An example TLSA record for the client "device1.example.com." and
the application "smtp-client". This record specifies the SHA-256 hash
of the subject public key component of the end-entity certificate
corresponding to the client. The certificate usage for this record
is 3 (DANE-EE) and thus is validated in accordance with section
5.1 of RFC 7671.
Format 2: DevID
An example TLSA record for the device named "sensor7" managed
by the organization "example.com" This record specifies the
SHA-512 hash of the subject public key component of an EE
certificate corresponding to the client.
Changes to Client and Server behavior
A TLS Client conforming to this specification MUST
have a signed DNS TLSA record published corresponding to
its DNS name and X.509 certificate or public key. The client
presents this certificate or public key in the TLS handshake
with the server. The client should not offer ciphersuites
that are incompatible with its certificate or public key.
If the client's certificate has a DANE record with a certificate
usage other than DANE-EE, then the presented client certificate
MUST have have the client's DNS name specified in the
Subject Alternative Name extension's dNSName type.
Additionally, when using raw public key authentication, the client
MUST send the TLS DANE
Client Identity extension in its Client Hello message. When
using X.509 certificate authentication, it SHOULD send this extension.
A TLS Server implementing this specification performs the
following steps:
- Request a client certificate in the TLS handshake (the
"Client Certificate Request" message). This could be done
unconditionally, or only when it receives the TLS DANE
Client Identity extension from the client.
- If the client has sent a non-empty DANE Client Identity extension,
then extract the client's domain name from the extension.
Otherwise, extract the client identity from the Subject Alternative
Name extension's dNSName type.
- Construct the DNS query name for the corresponding TLSA
record. If the TLS DANE client identity extension was present,
then this name should be used. Otherwise, identities from the
client certificate are used.
- Look up the TLSA record set in the DNS. The response MUST be
cryptographically validated using DNSSEC. The server could
perform the DNSSEC validation itself. It could also be
configured to trust responses obtained via a validating
resolver to which it has a secure connection.
- Extract the RDATA of the TLSA records and match them to the
presented client certificate according to the rules specified
in the DANE TLS protocol
.
If successfully matched, the client is authenticated and
the TLS session proceeds. If unsuccessful, the server MUST
treat the client as unauthenticated (e.g. it could terminate
the session, or proceed with the session giving the client
access to resources as a generic unauthenticated user).
- If there are multiple records in the TLSA record set,
then the client is authenticated as long as at least one of
the TLSA records matches, subject to RFC7671 digest agility,
which SHOULD be implemented.
If the DANE Client Identity extension is not present, and the
presented client certificate has multiple distinct reference
identifier types (e.g. a dNSName, and an rfc822Name) then
TLS servers configured to perform DANE authentication according
to this specification should only examine and authenticate the
dNSName.
If the presented client certificate has multiple dNSName
identities, then the client MUST use the TLS DANE client identity
extension to unambiguously indicate its intended name to the server.
Specific applications may be designed to require additional
validation steps. For example, a server might want to verify the
client's IP address is associated with the certificate in some
manner, e.g. by confirming that a secure reverse DNS lookup of
that address ties it back to the same domain name, or by requiring
an iPAddress component to be included in the certificate. Such
details are outside the scope of this document, and should be
outlined in other documents specific to the applications that
require this behavior.
Servers may have their own whitelisting and authorization rules
for which certificates they accept. For example a TLS server may
be configured to only allow TLS sessions from clients with
certificate identities within a specific domain or set of domains.
Raw Public Keys
When using raw public keys in TLS,
this specification requires the use of the TLS DANE Client
Identity extension. The associated DANE TLSA records employ only
certificate usage 3 (DANE-EE) and a selector value of 1 (SPKI),
as described in .
IANA Considerations
This document includes no request to IANA.
Security Considerations
This document updates RFC 6698 by defining the use of the TLSA
record for client TLS certificates. There are no security
considerations for this document beyond those described
in RFC 6698 and RFC 7671 and in the specifications for TLS and
DTLS [RFC8446], [RFC5246], [RFC6347].
References
Normative References
TLS Extension for DANE Client Identity
Informative References
PKI Certificate Identifier Format for Devices
Service Name and Transport Protocol Port Number Registry