DANE                                                           R. Barnes
Internet-Draft                                          BBN Technologies
Intended status: Informational                            April 19, 22, 2011
Expires: October 21, 24, 2011

    Use Cases and Requirements for DNS-based Authentication of Named
                            Entities
                    draft-ietf-dane-use-cases-00.txt (DANE)
                    draft-ietf-dane-use-cases-01.txt

Abstract

   Many current applications use the certificate-based authentication
   features in TLS to allow clients to verify that a connected server
   properly represents a desired domain name.  Traditionally, this
   authentication has been based on PKIX trust hierarchies, rooted in
   well-known CAs, but additional information can be provided via the
   DNS itself.  This document describes a set of use cases in which the
   DNS and DNSSEC could be used to make assertions that support the TLS
   authentication process.

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 October 21, 24, 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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3
     3.1.  CA Constraints  . . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Certificate Constraints . . . . . . . . . . . . . . . . . . 5
     3.3.  Domain-Issued Certificates  . . . . . . . . . . . . . . . . 5
   4.  Other Requirements  . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8 9

1.  Introduction

   Transport-Layer Security or TLS is used as the basis for security
   features in many modern Internet applications [RFC5246].  It is used
   as the basis for
   underlies secure HTTP and secure email [RFC2818][RFC2595][RFC3207],
   and provides hop-by-hop security in real-time multimedia and instant-messaging instant-
   messaging protocols [RFC3261][RFC6120].

   One feature that is common to most uses of TLS is the use of
   certificates to authenticate domain names for services.  The TLS
   client begins the TLS connection process with the goal of connecting
   to a server with a specific domain name.  After locating the server
   via an A or AAAA record, the client conducts a TLS handshake with the
   server, during which the server presents a PKIX certificate for
   itself [RFC5280].  Based on this certificate, the client decides
   whether the server properly represents the desired domain name, and
   thus whether to proceed with the TLS connection or not.

   In most current applications, this decision process is based on PKIX
   validation and name matching.  The client validates that the
   certificate chains to a trust anchor [RFC5280], and that the desired
   domain name is contained in the certificate [RFC6125].  Within this
   framework, bindings between public keys and domain names are asserted
   by PKIX CAs.  Authentication decisions based on these bindings rely
   on the authority of these CAs.

   The DNS is built to provide information about domain names, and with
   the advent of DNSSEC [RFC1034][RFC4033], it is possible for this
   information to be provided securely (in securely, in the sense that clients can
   verify that DNS information was provided by the domain owner).  One owner.  The
   goal of the goals technologies for DNS-based Authentication of the current DANE working group Named Entities
   (DANE) is to develop
   technologies for using use the DNS and DNSSEC to provide additional information
   to inform the TLS domain authentication 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.

2.  Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   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.

3.  Use Cases

   In this section, we describe the two 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
   goal for DANE.

   In the below use cases, we will refer to the following dramatis
   personae:

   Alice  The operator of a TLS-based TLS-protected 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

   These use cases are framed in terms of adding protections to TLS
   server certificates, since the use of these certificates to
   authenticate server domain names is very common.  In applications
   where TLS clients are also identified by domain names (e.g., XMPP
   server-to-server connections), the same considerations and use cases
   can also be applied to 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 about
   mis-issued that
   other well-known CAs might issue certificates and 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 by
   under the CA that she uses (Charlie) and not another CA.

   When Bob connects to alice.example.com, he uses this mechanism to
   verify that that the certificate presented by the server was issued
   by
   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.

   Because these constraints do not increase the scope of PKIX-based
   assertions about domains, there is not a strict requirement for
   DNSSEC.  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 an unauthorized certificate. a certificate for the target domain.  In the
   worst case, tampering with these constraints degrades security increases the risk of
   false authentication to the level that is now standard.

   Injected or modified false records 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 case 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 owners 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
   an unauthorized certificate. a certificate for the target
   domain.

3.2.  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 the
   specific certificate issued by Charlie.

   When Bob connects to alice.example.com, he uses this mechanism to
   verify that 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 considerations for this case are the same as for the "CA
   Constraints" case above.

3.3.  Domain-Issued Certificates

   Alice would like to be able to use 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, however, he
   doesn't have a way to verify that the issuer of the certificate is
   actually Alice.  This concerns him as 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 have a mechanism for visitors to her site to
   know that the certificates she issues are actually hers.  When Bob
   connects to alice.example.com, he uses this mechanism to verify that
   the certificate presented by the server was 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.

   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.  Deleted records
   will only result in connection failure and denial of service,
   although this could result on a bid-down to an unsecured protocol, 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 owner
   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 owner of the domain.

   This is not a significant incremental risk risk, however, relative to the
   current PKIX-based system.  In the current system, however, since 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 domain DNS operators to obtain certificates for domains under
   from some well-known certificate authorities today. today without
   authorization from the true domain owner.

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 services
      with different credentials on the same named host, distinguished
      by port number.

   Simple Key Management:  DANE must have a mode in which the domain
      owner only needs to maintain a single long-lived public/private
      key pair.

   Hard Failure:  Clients

   No Downgrade:  An attacker who can tamper with DNS responses must not
      be required to refuse able to proceed with make a
      connection to DANE-compliant client treat a site if that has
      deployed DANE indicates and DNSSEC like a security error. site that has deployed neither.

   Encapsulation:  If there is a DANE record information for the name
      alice.example.com, it must only affect services hosted at
      alice.example.com.

   Predictability:  Client behavior in response to DANE records information must
      be spelled out in the DANE specification as precisely as possible. possible,
      especially for cases where DANE information might conflict with
      PKIX information.

   Simple Key Management:  DANE should have a mode in which the domain
      owner only needs to maintain a single long-lived public/private
      key pair.

   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.

   Wild Cards and CNAME:  The mechanism for distributing DANE record distribution
      information should be compatible with the use of DNS wild cards
      and CNAME records for setting default properties for domains and
      redirecting services.

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.  IANA Considerations

   This document makes no request of IANA.

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

8.  References

8.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

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

Author's Address

   Richard Barnes
   BBN Technologies
   9861 Broken Land Parkway
   Columbia, MD  21046
   US

   Phone: +1 410 290 6169
   Email: rbarnes@bbn.com