Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
RFC 6394
|
Document |
Type |
|
RFC - Informational
(October 2011; No errata)
|
|
Author |
|
Richard Barnes
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
|
Reviews |
|
|
Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 6394 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Stephen Farrell
|
|
IESG note |
|
Ondřej Surý (ondrej.sury@nic.cz) is the Document Shepherd.
|
|
Send notices to |
|
(None)
|
Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 6394 BBN Technologies
Category: Informational October 2011
ISSN: 2070-1721
Use Cases and Requirements for DNS-Based Authentication
of Named Entities (DANE)
Abstract
Many current applications use the certificate-based authentication
features in Transport Layer Security (TLS) to allow clients to verify
that a connected server properly represents a desired domain name.
Typically, this authentication has been based on PKIX certificate
chains rooted in well-known certificate authorities (CAs), but
additional information can be provided via the DNS itself. This
document describes a set of use cases in which the DNS and DNS
Security Extensions (DNSSEC) could be used to make assertions that
support the TLS authentication process. The main focus of this
document is TLS server authentication, but it also covers TLS client
authentication for applications where TLS clients are identified by
domain names.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6394.
Barnes Informational [Page 1]
RFC 6394 DANE Use Cases October 2011
Copyright Notice
Copyright (c) 2011 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
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 ....................................................2
2. Definitions .....................................................4
3. Use Cases .......................................................4
3.1. CA Constraints .............................................5
3.2. Service Certificate Constraints ............................6
3.3. Trust Anchor Assertion and Domain-Issued Certificates ......7
3.4. Delegated Services .........................................9
4. Other Requirements .............................................10
5. Acknowledgements ...............................................11
6. Security Considerations ........................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................12
1. Introduction
Transport Layer Security (TLS) is used as the basis for security
features in many modern Internet application service protocols to
provide secure client-server connections [RFC5246]. It underlies
secure HTTP and secure email [RFC2818] [RFC2595] [RFC3207], and
provides hop-by-hop security in real-time multimedia and instant-
messaging protocols [RFC3261] [RFC6120].
Application service clients typically establish TLS connections to
application servers identified by DNS domain names. The process of
obtaining this "source" domain is application specific [RFC6125].
The name could be entered by a user or found through an automated
discovery process such as an SRV or NAPTR record. After obtaining
the address of the server via an A or AAAA DNS record, the client
conducts a TLS handshake with the server, during which the server
presents a PKIX certificate [RFC5280]. The TLS layer performs PKIX
Barnes Informational [Page 2]
RFC 6394 DANE Use Cases October 2011
validation of the certificate, including verification that the
certificate chains to one of the client's trust anchors. If this
validation is successful, then the application layer determines
whether the DNS name for the application service presented in the
Show full document text