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 | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 6394 (Informational) | |
Action Holders |
(None)
|
||
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 theShow full document text