GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6394

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
 certificate matches the source domain name [RFC6125].  Typically, if
 the name matches, then the client proceeds with the TLS connection.
 The certificate authorities (CAs) that issue PKIX certificates are
 asserting bindings between domain names and the public keys they
 certify.  Application service clients are verifying these bindings
 and making authorization decisions -- whether to proceed with
 connections -- based on them.
 Clients thus rely on CAs to correctly assert bindings between public
 keys and domain names, in the sense that the holder of the
 corresponding private key should be the domain holder.  Today, an
 attacker can successfully authenticate as a given application service
 domain if he can obtain a "mis-issued" certificate from one of the
 widely used CAs -- a certificate containing the victim application
 service's domain name and a public key whose corresponding private
 key is held by the attacker.  If the attacker can additionally insert
 himself as a "man in the middle" between a client and server (e.g.,
 through DNS cache poisoning of an A or AAAA record), then the
 attacker can convince the client that a server of the attacker's
 choice legitimately represents the victim's application service.
 With the advent of DNSSEC [RFC4033], it is now possible for DNS name
 resolution to provide its information securely, in the sense that
 clients can verify that DNS information was provided by the domain
 operator and not tampered with in transit.  The goal of technologies
 for DNS-based Authentication of Named Entities (DANE) is to use the
 DNS and DNSSEC to provide additional information about the
 cryptographic credentials associated with a domain, so that clients
 can use this information to increase the level of assurance they
 receive from the TLS handshake process.  This document describes a
 set of use cases that capture specific goals for using the DNS in
 this way, and a set of requirements that the ultimate DANE mechanism
 should satisfy.
 Finally, it should be noted that although this document will
 frequently use HTTPS as an example application service, DANE is
 intended to apply equally to all applications that make use of TLS to
 connect to application services identified by domain names.

Barnes Informational [Page 3] RFC 6394 DANE Use Cases October 2011

2. Definitions

 This document also makes use of standard PKIX, DNSSEC, and TLS
 terminology.  See RFC 5280 [RFC5280], RFC 4033 [RFC4033], and
 RFC 5246 [RFC5246], respectively, for these terms.  In addition,
 terms related to TLS-protected application services and DNS names are
 taken from RFC 6125 [RFC6125].
 Note in particular that the term "server" in this document refers to
 the server role in TLS, rather than to a host.  Multiple servers of
 this type may be co-located on a single physical host, often using
 different ports, and each of these can use different certificates.
 This document refers several times to the notion of a "domain
 holder".  This term is understood to mean the entity that is
 authorized to control the contents of a particular zone.  For
 example, the registrants of 2nd- or 3rd-level domains are the holders
 of those domains.  The holder of a particular domain is not
 necessarily the entity that operates the zone.
 It should be noted that the presence of a valid DNSSEC signature in a
 DNS reply does not necessarily imply that the records protected by
 that signature were authorized by the domain holder.  The distinction
 between the holder of a domain and the operator of the corresponding
 zone has several security implications, which are discussed in the
 individual use cases below.

3. Use Cases

 In this section, we describe the major use cases that the DANE
 mechanism should support.  This list is not intended to represent all
 possible ways that the DNS can be used to support TLS authentication.
 Rather, it represents the specific cases that comprise the initial
 goals for DANE.
 In the use cases below, we will refer to the following dramatis
 personae:
 Alice:  The operator of a TLS-protected application service on the
    host alice.example.com, and administrator of the corresponding
    DNS zone.
 Bob:  A client connecting to alice.example.com.
 Charlie:  A well-known CA that issues certificates with domain names
    as identifiers.

Barnes Informational [Page 4] RFC 6394 DANE Use Cases October 2011

 Oscar:  An outsourcing provider that operates TLS-protected
    application services on behalf of customers.
 Trent:  A CA that issues certificates with domain names as
    identifiers, but is not generally well-known.
 These use cases are framed in terms of adding verification steps to
 TLS server identity checking on the part of application service
 clients.  In application services where the clients are also
 identified by domain names (e.g., Extensible Messaging and Presence
 Protocol (XMPP) server-to-server connections), the same
 considerations and use cases are applicable to the application
 server's checking of identities in TLS client certificates.

3.1. CA Constraints

 Alice runs a website on alice.example.com and has obtained a
 certificate from the well-known CA Charlie.  She is concerned that
 other well-known CAs might issue certificates for alice.example.com
 without her authorization, which clients would accept.  Alice would
 like to provide a mechanism for visitors to her site to know that
 they should expect alice.example.com to use a certificate issued
 under the CA that she uses (Charlie) and not another CA.  That is,
 Alice is recommending that the client verify that there is a valid
 certificate chain from the server certificate to Charlie before
 accepting the server certificate.  (For example, in the TLS
 handshake, the server might include Charlie's certificate in the
 server Certificate message's certificate_list structure [RFC5246]).
 When Bob connects to alice.example.com, he uses this mechanism to
 verify that the certificate presented by the server was issued under
 the proper CA, Charlie.  Bob also performs the normal PKIX validation
 procedure for this certificate, in particular verifying that the
 certificate chains to a trust anchor (possibly Charlie's CA, if Bob
 accepts Charlie's CA as a trust anchor).
 Alice may wish to provide similar information to an external CA
 operator, Charlie.  Prior to issuing a certificate for
 alice.example.com to someone claiming to be Alice, Charlie needs to
 verify that Alice is actually requesting a certificate.  Alice could
 indicate her preferred CA using DANE to CAs as well as relying
 parties.  Charlie could then check to see whether Alice said that her
 certificates should be issued by Charlie or another CA.  Note that
 this check does not guarantee that the precise entity requesting a
 certification from Charlie actually represents Alice -- only that
 Alice has authorized Charlie to issue certificates for her domain to
 properly authorized individuals.

Barnes Informational [Page 5] RFC 6394 DANE Use Cases October 2011

 In principle, DANE information expressing CA constraints can be
 presented with or without DNSSEC protection.  Presenting DANE
 information without DNSSEC protection does not introduce any new
 vulnerabilities, but neither does it add much assurance.  Deletion of
 records removes the protection provided by this constraint, but the
 client is still protected by CA practices (as now).  Injected or
 modified false records are not useful unless the attacker can also
 obtain a certificate for the target domain.  Thus, in the worst case,
 tampering with these constraints increases the risk of false
 authentication to the level that is now standard.
 Using DANE information for CA constraints without DNSSEC provides a
 very small incremental security feature.  Many common attacks against
 TLS connections already require the attacker to inject false A or
 AAAA records in order to steer the victim client to the attacker's
 server.  An attacker that can already inject false DNS records can
 also provide fake DANE information (without DNSSEC) by simply
 spoofing the additional records required to carry the DANE
 information.
 Injected or modified false DANE information of this type can be used
 for denial of service, even if the attacker does not have a
 certificate for the target domain.  If an attacker can modify DNS
 responses that a target host receives, however, there are already
 much simpler ways of denying service, such as providing a false A or
 AAAA record.  In this case, DNSSEC is not helpful, since an attacker
 could still cause a denial of service by blocking all DNS responses
 for the target domain.
 Continuing to require PKIX validation also limits the degree to which
 DNS operators (as distinct from the holders of domains) can interfere
 with TLS authentication through this mechanism.  As above, even if a
 DNS operator falsifies DANE records, it cannot masquerade as the
 target server unless it can also obtain a certificate for the target
 domain.

3.2. Service Certificate Constraints

 Alice runs a website on alice.example.com and has obtained a
 certificate from the well-known CA Charlie.  She is concerned about
 additional, unauthorized certificates being issued by Charlie as well
 as by other CAs.  She would like to provide a way for visitors to her
 site to know that they should expect alice.example.com to present a
 specific certificate.  In TLS terms, Alice is letting Bob know that
 this specific certificate must be the first certificate in the server
 Certificate message's certificate_list structure [RFC5246].

Barnes Informational [Page 6] RFC 6394 DANE Use Cases October 2011

 When Bob connects to alice.example.com, he uses this mechanism to
 verify that the certificate presented by the server is the correct
 certificate.  Bob also performs the normal PKIX validation procedure
 for this certificate, in particular verifying that the certificate
 chains to a trust anchor.
 The security implications for this case are the same as for the "CA
 Constraints" case above.

3.3. Trust Anchor Assertion and Domain-Issued Certificates

 Alice would like to be able to generate and use certificates for her
 website on alice.example.com without involving an external CA at all.
 Alice can generate her own certificates today, making self-signed
 certificates and possibly certificates subordinate to those
 certificates.  When Bob receives such a certificate in a TLS
 handshake, however, he doesn't automatically have a way to verify
 that the issuer of the certificate is actually Alice, because he
 doesn't necessarily possess Alice's corresponding trust anchor.  This
 concerns him because an attacker could present a different
 certificate and perform a man-in-the-middle attack.  Bob would like
 to protect against this.
 Alice would thus like to publish information so that visitors to her
 site can know that the certificates presented by her application
 services are legitimately hers.  When Bob connects to
 alice.example.com, he uses this information to verify that the
 certificate presented by the server has been issued by Alice.  Since
 Bob can bind certificates to Alice in this way, he can use Alice's CA
 as a trust anchor for purposes of validating certificates for
 alice.example.com.  Alice can additionally recommend that clients
 accept only her certificates using the CA constraints described
 above.
 As in Section 3.1 above, Alice may wish to represent this information
 to potential third-party CAs (Charlie) as well as to relying parties
 (Bob).  Since publishing a certificate in a DANE record of this form
 authorizes the holder of the corresponding private key to represent
 alice.example.com, a CA that has received a request to issue a
 certificate from alice.example.com could use the DANE information to
 verify the requestor's authorization to receive a certificate for
 that domain.  For example, a CA might choose to issue a certificate
 for a given domain name and public key only when the holder of the
 domain name has provisioned DANE information with a certificate
 containing the public key.

Barnes Informational [Page 7] RFC 6394 DANE Use Cases October 2011

 Note that this use case is functionally equivalent to the case where
 Alice doesn't issue her own certificates, but uses Trent's CA, which
 is not well-known.  In this case, Alice would be advising Bob that he
 should treat Trent as a trust anchor for purposes of validating
 Alice's certificates, rather than a CA operated by Alice herself.
 Bob would thus need a way to securely obtain Trent's trust anchor
 information, namely through DANE information.
 Alice's advertising of trust anchor material in this way does not
 guarantee that Bob will accept the advertised trust anchor.  For
 example, Bob might have out-of-band information (such as a
 pre-existing local policy) that indicates that the CA advertised by
 Alice (Trent's CA) is not trustworthy, which would lead him to decide
 not to accept Trent as a trust anchor, and thus to reject Alice's
 certificate if it is issued under Trent's CA.
 Providing trust anchor material in this way clearly requires DNSSEC,
 since corrupted or injected records could be used by an attacker to
 cause clients to trust an attacker's certificate (assuming that the
 attacker's certificate is not rejected by some other local policy).
 Deleted records will only result in connection failure and denial of
 service, although this could result in clients re-connecting without
 TLS (a downgrade attack), depending on the application.  Therefore,
 in order for this use case to be safe, applications must forbid
 clients from falling back to unsecured channels when records appear
 to have been deleted (e.g., when a missing record has no NSEC or
 NSEC3 record).
 By the same token, this use case puts the most power in the hands of
 DNS operators.  Since the operator of the appropriate DNS zone has
 de facto control over the content and signing of the zone, he can
 create false DANE records that bind a malicious party's certificate
 to a domain.  This risk is especially important to keep in mind in
 cases where the operator of a DNS zone is a different entity than the
 holder of the domain, as in DNS hosting/outsourcing arrangements,
 since in these cases the DNS operator might be able to make changes
 to a domain that are not authorized by the holder of the domain.
 It should be noted that DNS operators already have the ability to
 obtain certificates for domains under their control, under certain CA
 policies.  In the current system, CAs need to verify that an entity
 requesting a certificate for a domain is actually the legitimate
 holder of that domain.  Typically, this is done using information
 published about that domain, such as WHOIS email addresses or special
 records inserted into a domain.  By manipulating these values, it is
 possible for DNS operators to obtain certificates from some well-
 known certificate authorities today without authorization from the
 true domain holder.

Barnes Informational [Page 8] RFC 6394 DANE Use Cases October 2011

3.4. Delegated Services

 In addition to guarding against CA mis-issue, CA constraints and
 certificate constraints can also be used to constrain the set of
 certificates that can be used by an outsourcing provider.  Suppose
 that Oscar operates alice.example.com on behalf of Alice.  In
 particular, Oscar then has de facto control over what certificates to
 present in TLS handshakes for alice.example.com.  In such cases,
 there are a few ways that DNS-based information about TLS
 certificates could be configured; for example:
 1.  Alice has the A/AAAA records in her DNS and can sign them along
     with the DANE record, but Oscar and Alice now need to have tight
     coordination if the addresses and/or the certificates change.
 2.  Alice refers to Oscar's DNS by delegating a sub-domain name to
     Oscar, and has no control over the A/AAAA, DANE, or any other
     pieces under Oscar's control.
 3.  Alice can put DANE records into her DNS server but delegate the
     address records to Oscar's DNS server.  This means that Alice can
     control the usage of certificates, but Oscar is free to move the
     servers around as needed.  The only coordination needed is when
     the certificates change, and then it would depend on how the DANE
     record is set up (i.e., a CA or an end-entity certificate
     pointer).
 Which of these deployment patterns is used in a given deployment will
 determine what sort of constraints can be expressed by which actors.
 In cases where Alice controls DANE records (1 and 3), she can use CA
 and certificate constraints to control what certificates Oscar
 presents for Alice's application services.  For instance, Alice might
 require Oscar to use certificates under a given set of CAs.  This
 control, however, requires that Alice update DANE records when Oscar
 needs to change certificates.  Cases where Oscar controls DANE
 records allow Oscar to maintain more autonomy from Alice, but by the
 same token, Alice cannot enforce any requirements on the certificates
 that Oscar presents in TLS handshakes.

Barnes Informational [Page 9] RFC 6394 DANE Use Cases October 2011

4. Other Requirements

 In addition to supporting the above use cases, the DANE mechanism
 must satisfy several lower-level operational and protocol
 requirements and goals.
 Multiple Ports:  DANE should be able to support multiple application
    services with different credentials on the same named host,
    distinguished by port number.
 No Downgrade:  An attacker who can tamper with DNS responses must not
    be able to make a DANE-compliant client treat a site that has
    deployed DANE and DNSSEC like a site that has deployed neither.
 Encapsulation:  If there is DANE information for the name
    alice.example.com, it must only affect application services hosted
    at alice.example.com.
 Predictability:  Client behavior in response to DANE information must
    be defined in the DANE specification as precisely as possible,
    especially for cases where DANE information might conflict with
    PKIX information.
 Opportunistic Security:  The DANE mechanism must allow a client to
    determine whether DANE information is available for a site, so
    that a client can provide the highest level of security possible
    for a given application service.  Clients that do not support DANE
    should continue to work as specified, regardless of whether DANE
    information is present or not.
 Combination:  The DANE mechanism must allow multiple DANE statements
    of the above forms to be combined.  For example, a domain holder
    should be able to specify that clients should accept a particular
    certificate (Section 3.2) as well as any certificate issued by its
    own CA (Section 3.3).  The precise types of combination allowed
    will be defined by the DANE protocol.
 Roll-over:  The DANE mechanism must allow a site to transition from
    using one DANE mechanism to another.  For example, a domain holder
    should be able to migrate from using DANE to assert a domain-
    issued certificate (Section 3.3) to using DANE to require an
    external CA (Section 3.1), or vice versa.  The DANE mechanism must
    also allow roll-over between records of the same type, e.g., when
    changing CAs.
 Simple Key Management:  DANE should have a mode in which the domain
    holder only needs to maintain a single long-lived public/private
    key pair.

Barnes Informational [Page 10] RFC 6394 DANE Use Cases October 2011

 Minimal Dependencies:  It should be possible for a site to deploy
    DANE without also deploying anything else, except DNSSEC.
 Minimal Options:  Ideally, DANE should have only one operating mode.
    Practically, DANE should have as few operating modes as possible.
 Wildcards:  The mechanism for distributing DANE information should
    allow the use of DNS wildcard labels (*) for setting DANE
    information for all names within a wildcard expansion.
 Redirection:  The mechanism for distributing DANE information should
    work when the application service name is the result of following
    a DNS redirection chain (e.g., via CNAME or DNAME).

5. Acknowledgements

 Thanks to Eric Rescorla for the initial formulation of the use cases,
 Zack Weinberg and Phillip Hallam-Baker for contributing other
 requirements, and the whole DANE working group for helpful comments
 on the mailing list.

6. Security Considerations

 The primary focus of this document is the enhancement of TLS
 authentication procedures using the DNS.  The general effect of such
 mechanisms is to increase the role of DNS operators in authentication
 processes, either in place of or in addition to traditional third-
 party actors such as commercial certificate authorities.  The
 specific security implications of the respective use cases are
 discussed in their respective sections above.

7. References

7.1. Normative References

 [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "DNS Security Introduction and Requirements",
            RFC 4033, March 2005.
 [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.

Barnes Informational [Page 11] RFC 6394 DANE Use Cases October 2011

 [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.

7.2. Informative References

 [RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP",
            RFC 2595, June 1999.
 [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
 [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
            Transport Layer Security", RFC 3207, February 2002.
 [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP: Session Initiation Protocol", RFC 3261,
            June 2002.
 [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
            Protocol (XMPP): Core", RFC 6120, March 2011.

Author's Address

 Richard Barnes
 BBN Technologies
 9861 Broken Land Parkway
 Columbia, MD  21046
 US
 Phone: +1 410 290 6169
 EMail: rbarnes@bbn.com

Barnes Informational [Page 12]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6394.txt · Last modified: 2011/10/26 22:38 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki