Client Certificates in DANE TLSA Records
draft-huque-dane-client-cert-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Shumon Huque , Dan James , Viktor Dukhovni | ||
| Last updated | 2015-06-27 | ||
| Replaced by | draft-ietf-dance-client-auth | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-huque-dane-client-cert-00
Internet Engineering Task Force S. Huque
Internet-Draft Verisign Labs
Updates: 6698 (if approved) D. James
Intended status: Standards Track Verisign, Inc.
Expires: December 29, 2015 V. Dukhovni
Two Sigma
June 27, 2015
Client Certificates in DANE TLSA Records
draft-huque-dane-client-cert-00
Abstract
The current DNS TLSA record format [RFC6698] describes how to specify
TLS server certificates or their public keys in the DNS. This
document makes a narrowly focused update to RFC 6698. It describes
how to additionally use the TLSA record to specify TLS client
certificates and the rules and considerations for using them.
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 http://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 December 29, 2015.
Copyright Notice
Copyright (c) 2015 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
(http://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
Huque, et al. Expires December 29, 2015 [Page 1]
Internet-Draft TLSA client certificates June 2015
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
2. Associating Client Identities in TLSA Records . . . . . . . . 2
3. Authentication Model . . . . . . . . . . . . . . . . . . . . 3
4. Client Identifiers in X.509 certificates . . . . . . . . . . 3
5. Signaling the Client's DANE Identity in TLS . . . . . . . . . 4
6. Example TLSA records for clients . . . . . . . . . . . . . . 4
7. Changes to Client and Server behavior . . . . . . . . . . . . 5
8. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . . . 7
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
12. Security Considerations . . . . . . . . . . . . . . . . . . . 7
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.1. Normative References . . . . . . . . . . . . . . . . . . 8
13.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction and Motivation
The Transport Layer Security (TLS) protocol [RFC5246] optionally
supports the authentication of clients using X.509 certificates
[RFC5280]. TLS Applications currently employing 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) 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) [RFC6347]
protocols.
2. Associating Client Identities in TLSA Records
When specifying client identities (i.e. client domain names) in TLSA
records, the owner name of the TLSA record is proposed to have one of
the two formats described below:
Format 1: The first label identifies the application service, and the
second identifies the transport protocol. The remaining labels are
Huque, et al. Expires December 29, 2015 [Page 2]
Internet-Draft TLSA client certificates June 2015
composed of the client domain name. So the form looks like
_service._transport.[client-domain-name].
Format 2: The first label is the constant string "_client" and the
second label identifies the application service. The remaining
labels are composed of the client domain name. So the form looks
like _client._service.[client-domain-name]. This form is transport
protocol agnostic, and has a constant string that can be used to
easily identify TLSA records for client certificates.
Encoding the application service name into the owner name allows the
same client domain name to have different authentication credentials
for different application services.
The _service label could be a custom string for an application, but
more commonly is expected to be service name registered in the IANA
Service Name Registry [SRVREG].
Note: The final version of this document will specify only one format
for the owner name, based on IETF working group consensus.
The RDATA or data field portion of the TLSA record is formed exactly
as specified in RFC 6698, and carries the same meaning.
3. Authentication Model
The authentication model assumed in this document is the following:
The client is assigned an identity corresponding to a DNS domain name
(which does not necessarily have any relation to its network layer
addresses). The client generates (or has generated for it) a private
and public key pair, and a certificate binding the name to its public
key. This certificate 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 usage modes) or via a PKIX public CA
system constraint (using the PKIX-TA or PKIX-EE usage modes).
4. Client Identifiers in X.509 certificates
The client certificate MUST have have the client's DNS name specified
in the Subject Alternative Name extension's dNSName type. Or, if an
application specific identity is preferred or needed, the SRV-ID
(PKIX OtherName SRVName) MUST be used to specify the application
service and the client's name, e.g. "_smtp-
client.device1.example.com". See [RFC6125] and [RFC4985] for a
discussion of application specific identifiers in X.509 certificates.
The initial revision of this document talks mainly about dNSName
identifiers, because SRV-ID has not seen much adoption in the
Huque, et al. Expires December 29, 2015 [Page 3]
Internet-Draft TLSA client certificates June 2015
Internet to date. However, with TLSA usage modes except for DANE-EE,
there may be a problem separating different client credentials with
the same underlying domain name, but distinct services unless SRV-ID
is employed.
5. Signaling the Client's DANE Identity in TLS
The protocol described in the initial version of this document
assumes either that client authentication is mandatory, or that where
it is optional, clients can handle a Client Certificate Request
message from the server without issues if they are not equipped with
client certificates. Technically, the TLS protocol specification
states that the client may respond with a Client Certificate message
with no certificate, and that the server may at its discretion
continue the handshake without client authentication. However in
practice, problems may arise. There are deployed client software
implementations that do not react gracefully when encountering a
certificate request that they did not expect.
Furthermore, a 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 for clients that don't support this.
Hence, to address this issue generally, a client identity signaling
solution will need to be devised, whereby the client indicates its
DANE identity (i.e. its domain name identity and the fact that this
identity has an associated TLSA record) to the server. Application
specific protocol enhancements are one way to achieve this, e.g. a
new SMTP command. A more general way would be to develop a new TLS
extension to convey this information.
[Another internet draft is currently being written to define such a
TLS extension to convey DANE client identity.]
6. Example TLSA records for clients
The following examples are provided in the textual presentation
format of the TLSA record.
An example TLSA record for the client "device1.example.com." and the
application "smtp-client" on transport "tcp". This record record
specifies the use of TLS, and specifies the SHA-256 hash of a PKIX CA
certificate to authenticate the client's certificate.
Format 1:
_smtp-client._tcp.device1.example.com. IN TLSA (
0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
Huque, et al. Expires December 29, 2015 [Page 4]
Internet-Draft TLSA client certificates June 2015
7983a1d16e8a410e4561cb106618e971 )
Format 2:
_client._smtp-client.device1.example.com. IN TLSA (
0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
7983a1d16e8a410e4561cb106618e971 )
An example TLSA record for the client "device2.example.com." and the
application "localsvc" on transport "udp". This record specifies the
use of DTLS, and specifies the SHA-512 hash of the subject public key
component of the client's certificate. The usage mode for this
record is 3 (DANE-EE) and hence no PKIX validation for this
certificate should be performed.
Format 1:
_localsvc._udp.device2.example.com. IN TLSA (
3 1 2 0f8b48ff5fd94117f21b6550aaee89c8
d8adbc3f433c8e587a85a14e54667b25
f4dcd8c4ae6162121ea9166984831b57
b408534451fd1b9702f8de0532ecd03c )
Format 2:
_client._localsvc.device2.example.com. IN TLSA (
3 1 2 0f8b48ff5fd94117f21b6550aaee89c8
d8adbc3f433c8e587a85a14e54667b25
f4dcd8c4ae6162121ea9166984831b57
b408534451fd1b9702f8de0532ecd03c )
7. Changes to Client and Server behavior
[Note: As the client identity signaling solution is developed, this
section will undergo enhancements to use it. A future revision of
this document will also explicitly address the use case of raw public
keys instead of X.509 certificates.]
A TLS Client conforming to this specification MUST have a signed DNS
TLSA record published corresponding to its DNS name and X.509
certificate. The client presents this certificate in the TLS
handshake with the server. The presented client certificate MUST
have have the client's DNS name specified either in the Subject
Alternative Name extension's dNSName type, or the SRVName type.
A TLS Server implementing this specification performs the following
steps:
Huque, et al. Expires December 29, 2015 [Page 5]
Internet-Draft TLSA client certificates June 2015
S1 Request a client certificate in the TLS handshake (the "Client
Certificate Request" message).
S2 Extract the client identity from the Subject Alternative Name
extension's dNSName or SRVName type in the client certificate.
(If no client certificate is provided, then the server may
terminate the connection, or at its discretion may continue the
handshake without client authentication.)
S3 Construct the DNS query name for the corresponding TLSA record,
by prepending the application service, transport protocol, and
"_client" labels according to which format is being used. See
Section 2 for the proposed owner name formats.
S4 Look up the TLSA record 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.
S5 Extract the RDATA of the TLSA record and match it to the
presented client certificate according to the rules specified in
the DANE TLS protocol [RFC6698]. If successfully matched, the
client is authenticated and the TLS session proceeds. If not,
the session is terminated with a "bad_certificate" alert message.
S6 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.
Specific applications may be designed to require more detailed
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 application specific documents.
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.
If 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 or
Huque, et al. Expires December 29, 2015 [Page 6]
Internet-Draft TLSA client certificates June 2015
SRVName identity. See [RFC6125] for a description of reference
identifiers and matching rules.
If the presented client certificate has multiple dNSName or SRVName
identities, then the client MUST use an identity signalling mechanism
to indicate the intended name to the server.
8. Raw Public Keys
This specification can also support the use of raw public keys in TLS
[RFC7250]. This use case employs only usage mode 3 (DANE-EE) and a
selector value of 1 (SPKI) in the DANE TLSA record, as described in
[DANERAW]. It requires the use of the new client identity signaling
solution discussed previously.
9. Open Issues
Should this document also consider client identities in the form of
e-mail addresses? The use case might be an SMTP client talking to an
SMTP submission server. In that case, the email address of a user
would most likely be conveyed in the certificate in a subject alt
name rfc822Name type. The corresponding TLSA record would have to
then have an owner name format similar to the OPENPGPKEY or SMIMEA
records. This use case might be best left to the SMIMEA
specification to consider.
10. Acknowledgements
This document benefited from discussions with the following people:
Duane Wessels, Allison Mankin, Casey Deccio, and Warren Kumari.
11. IANA Considerations
This document includes no request to IANA.
12. Security Considerations
This document makes a narrow update to RFC 6698 by defining the usage
of the TLSA record for client TLS certificates. There are no
security considerations for this document beyond those described in
RFC 6698 and in the specifications for TLS and DTLS [RFC5246],
[RFC6347].
Huque, et al. Expires December 29, 2015 [Page 7]
Internet-Draft TLSA client certificates June 2015
13. References
13.1. Normative References
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name",
RFC 4985, August 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
[RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
T. Kivinen, "Using Raw Public Keys in Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", RFC 7250, June 2014.
13.2. Informative References
[DANERAW] Gilmore, J., "Authenticating Raw Public Keys with DANE
TLSA", , <https://tools.ietf.org/html/draft-ietf-dane-
rawkeys-00>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
Huque, et al. Expires December 29, 2015 [Page 8]
Internet-Draft TLSA client certificates June 2015
[SRVREG] IANA, ., "Service Name and Transport Protocol Port Number
Registry", , <https://www.iana.org/assignments/service-
names-port-numbers/service-names-port-numbers.txt>.
Authors' Addresses
Shumon Huque
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
US
Email: shuque@verisign.com
Dan James
Verisign, Inc.
12061 Bluemont Way
Reston, VA 20190
US
Email: djames@verisign.com
Viktor Dukhovni
Two Sigma
Email: ietf-dane@dukhovni.org
Huque, et al. Expires December 29, 2015 [Page 9]