draft-ietf-dane-use-cases-03.txt   draft-ietf-dane-use-cases-04.txt 
DANE R. Barnes DANE R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational June 12, 2011 Intended status: Informational June 29, 2011
Expires: December 14, 2011 Expires: December 31, 2011
Use Cases and Requirements for DNS-based Authentication of Named Use Cases and Requirements for DNS-based Authentication of Named
Entities (DANE) Entities (DANE)
draft-ietf-dane-use-cases-03.txt draft-ietf-dane-use-cases-04.txt
Abstract Abstract
Many current applications use the certificate-based authentication Many current applications use the certificate-based authentication
features in TLS to allow clients to verify that a connected server features in TLS to allow clients to verify that a connected server
properly represents a desired domain name. Traditionally, this properly represents a desired domain name. Traditionally, this
authentication has been based on PKIX trust hierarchies, rooted in authentication has been based on PKIX trust hierarchies, rooted in
well-known CAs, but additional information can be provided via the 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 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 DNS and DNSSEC could be used to make assertions that support the TLS
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 14, 2011. This Internet-Draft will expire on December 31, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. CA Constraints . . . . . . . . . . . . . . . . . . . . . . 5 3.1. CA Constraints . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Certificate Constraints . . . . . . . . . . . . . . . . . 6 3.2. Service Certificate Constraints . . . . . . . . . . . . . 6
3.3. Domain-Issued Certificates . . . . . . . . . . . . . . . . 6 3.3. Trust Anchor Assertion and Domain-Issued Certificates . . 7
3.4. Delegated Services . . . . . . . . . . . . . . . . . . . . 8 3.4. Delegated Services . . . . . . . . . . . . . . . . . . . . 9
4. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 9 4. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Transport-Layer Security (TLS) is used as the basis for security Transport-Layer Security (TLS) is used as the basis for security
features in many modern Internet application service protocols to features in many modern Internet application service protocols to
provide secure client-server connections [RFC5246]. It underlies provide secure client-server connections [RFC5246]. It underlies
secure HTTP and secure email [RFC2818][RFC2595][RFC3207], and secure HTTP and secure email [RFC2818][RFC2595][RFC3207], and
provides hop-by-hop security in real-time multimedia and instant- provides hop-by-hop security in real-time multimedia and instant-
messaging protocols [RFC3261][RFC6120]. messaging protocols [RFC3261][RFC6120].
skipping to change at page 3, line 29 skipping to change at page 3, line 29
of the server via an A or AAAA DNS record, the client conducts a TLS 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 handshake with the server, during which the server presents a PKIX
certificate [RFC5280]. The TLS layer performs PKIX validation of the certificate [RFC5280]. The TLS layer performs PKIX validation of the
certificate, including verification that the certificate chains to a certificate, including verification that the certificate chains to a
trust anchor. If this validation is successful, then the application trust anchor. If this validation is successful, then the application
layer determines whether the DNS name for the application service layer determines whether the DNS name for the application service
presented in the certificate matches the source domain name presented in the certificate matches the source domain name
[RFC6125]. Typically, if the name matches, then the client proceeds [RFC6125]. Typically, if the name matches, then the client proceeds
with the TLS connection. with the TLS connection.
Thus the certificate authorities (CAs) that issue PKIX certificates The certificate authorities (CAs) that issue PKIX certificates are
are asserting bindings between domain names and the public keys they asserting bindings between domain names and the public keys they
certify. Application service clients are verifying these bindings certify. Application service clients are verifying these bindings
and making authorization decisions -- whether to proceed with and making authorization decisions -- whether to proceed with
connections -- based on them. 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" ciertificate 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 an 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 With the advent of DNSSEC [RFC4033], it is now possible for DNS name
resolution to provide its information securely, in the sense that resolution to provide its information securely, in the sense that
clients can verify that DNS information was provided by the domain clients can verify that DNS information was provided by the domain
holder and not tampered with in transit. The goal of technologies holder and not tampered with in transit. The goal of technologies
for DNS-based Authentication of Named Entities (DANE) is to use the for DNS-based Authentication of Named Entities (DANE) is to use the
DNS and DNSSEC to provide additional information about the DNS and DNSSEC to provide additional information about the
cryptographic credentials associated with a domain, so that clients cryptographic credentials associated with a domain, so that clients
can use this information to increase the level of assurance they can use this information to increase the level of assurance they
receive from the TLS handshake process. This document describes a receive from the TLS handshake process. This document describes a
set of use cases that capture specific goals for using the DNS in set of use cases that capture specific goals for using the DNS in
skipping to change at page 5, line 34 skipping to change at page 5, line 49
that the certificate chains to a trust anchor (possibly Charlie's CA, that the certificate chains to a trust anchor (possibly Charlie's CA,
if Bob accepts Charlie's CA as a trust anchor). if Bob accepts Charlie's CA as a trust anchor).
Alice may wish to provide similar information to an external CA Alice may wish to provide similar information to an external CA
operator Charlie. Prior to issuing a certificate for operator Charlie. Prior to issuing a certificate for
alice.example.com to someone claiming to Alice, Charlie needs to alice.example.com to someone claiming to Alice, Charlie needs to
verify that Alice is actually requesting a certificate. Alice could verify that Alice is actually requesting a certificate. Alice could
indicate her preferred CA using DANE to CAs as well as RPs. Charlie indicate her preferred CA using DANE to CAs as well as RPs. Charlie
could then check to see whether Alice said that her certificates could then check to see whether Alice said that her certificates
should be issued by Charlie or another CA. Note that this check does should be issued by Charlie or another CA. Note that this check does
not guaranteed that the precise entity requesting a certification not guarantee that the precise entity requesting a certification from
from Charlie actually represents Alice, only that Alice has Charlie actually represents Alice, only that Alice has authorized
authorized Charlie to issue certificates for her domain to properly Charlie to issue certificates for her domain to properly authorized
authorized individuals. individuals.
Because these constraints do not increase the scope of PKIX-based In principle, DANE information expressing CA constraints can be
assertions about domains, there is not a strict requirement for presented with or without DNSSEC protection. Presenting DANE
DNSSEC. Deletion of records removes the protection provided by this information without DNSSEC protection does not introduce any new
constraint, but the client is still protected by CA practices (as vulnerabilities, but neither does it add much assurance. Deletion of
now). Injected or modified false records are not useful unless the records removes the protection provided by this constraint, but the
attacker can also obtain a certificate for the target domain. In the client is still protected by CA practices (as now). Injected or
worst case, tampering with these constraints increases the risk of modified false records are not useful unless the attacker can also
false authentication to the level that is now standard. 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.
Nonetheless, using DANE in this way without also using DNSSEC Using DANE information for CA constraints without DNSSEC provides a
represents provides a very small incremental security feature. Many very small incremental security feature. Many common attacks against
common attacks against TLS connections already require the attacker TLS connections already require the attacker to inject false A or
to inject false A or AAAA records in order to steer the victim client AAAA records in order to steer the victim client to the attacker's
to the attacker's server. An attacker that can already inject false server. An attacker that can already inject false DNS records can
DNS records can also fake DANE information (without DNSSEC) by simply also provide fake DANE information (without DNSSEC) by simply
spoofing the additional records required to carry the DANE spoofing the additional records required to carry the DANE
information. information.
Injected or modified false records can be used for denial of service, Injected or modified false DANE information of this type can be used
even if the attacker does not have a certificate for the target for denial of service, even if the attacker does not have a
domain. If an attacker can modify DNS responses that a target host certificate for the target domain. If an attacker can modify DNS
receives, however, there are already much simpler ways of denying responses that a target host receives, however, there are already
service, such as providing a false A or AAAA record. In this case, much simpler ways of denying service, such as providing a false A or
DNSSEC is not helpful, since an attacker could still case a denial of AAAA record. In this case, DNSSEC is not helpful, since an attacker
service by blocking all DNS responses for the target domain. 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 Continuing to require PKIX validation also limits the degree to which
DNS operators (as distinct from the holders of domains) can interfere DNS operators (as distinct from the holders of domains) can interfere
with TLS authentication through this mechanism. As above, even if a with TLS authentication through this mechanism. As above, even if a
DNS operator falsifies DANE records, it cannot masquerade as the DNS operator falsifies DANE records, it cannot masquerade as the
target server unless it can also obtain a certificate for the target target server unless it can also obtain a certificate for the target
domain. domain.
3.2. Certificate Constraints 3.2. Service Certificate Constraints
Alice runs a website on alice.example.com and has obtained a Alice runs a website on alice.example.com and has obtained a
certificate from the well-known CA Charlie. She is concerned about certificate from the well-known CA Charlie. She is concerned about
additional, unauthorized certificates being issued by Charlie as well additional, unauthorized certificates being issued by Charlie as well
as by other CAs. She would like to provide a way for visitors to her 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 site to know that they should expect alice.example.com to present a
specific certificate issued by Charlie. In TLS terms, Alice is specific certificate. In TLS terms, Alice is letting Bob know that
letting Bob know that this specific certificate must be the first this specific certificate must be the first certificate in the server
certificate in the server Certificate message's certificate_list Certificate message's certificate_list structure [RFC5246].
structure [RFC5246].
When Bob connects to alice.example.com, he uses this mechanism to When Bob connects to alice.example.com, he uses this mechanism to
verify that that the certificate presented by the server is the verify that that the certificate presented by the server is the
correct certificate. Bob also performs the normal PKIX validation correct certificate. Bob also performs the normal PKIX validation
procedure for this certificate, in particular verifying that the procedure for this certificate, in particular verifying that the
certificate chains to a trust anchor. certificate chains to a trust anchor.
The security considerations for this case are the same as for the "CA The security implications for this case are the same as for the "CA
Constraints" case above. Constraints" case above.
3.3. Domain-Issued Certificates 3.3. Trust Anchor Assertion and Domain-Issued Certificates
Alice would like to be able to generate and use certificates for her 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. website on alice.example.com without involving an external CA at all.
Alice can generate her own certificates today, making self-signed Alice can generate her own certificates today, making self-signed
certificates and possibly certificates subordinate to those certificates and possibly certificates subordinate to those
certificates. When Bob receives such a certificate in a TLS certificates. When Bob receives such a certificate in a TLS
handshake, however, he doesn't automatically have a way to verify handshake, however, he doesn't automatically have a way to verify
that the issuer of the certificate is actually Alice, since because that the issuer of the certificate is actually Alice, because he
he doesn't necessarily possess Alice's corresponding trust anchor. doesn't necessarily possess Alice's corresponding trust anchor. This
This concerns him because an attacker could present a different concerns him because an attacker could present a different
certificate and perform a man in the middle attack. Bob would like certificate and perform a man in the middle attack. Bob would like
to protect against this. to protect against this.
Alice would thus like to have a mechanism for visitors to her site to Alice would thus like to have a mechanism for visitors to her site to
know that the certificates presented by her application services are know that the certificates presented by her application services are
legitimately hers. When Bob connects to alice.example.com, he uses legitimately hers. When Bob connects to alice.example.com, he uses
this mechanism to verify that the certificate presented by the server this mechanism to verify that the certificate presented by the server
has been issued by Alice. Since Bob can bind certificates to Alice 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 in this way, he can use Alice's CA as a trust anchor for purposes of
validating certificates for alice.example.com. Alice can validating certificates for alice.example.com. Alice can
skipping to change at page 9, line 47 skipping to change at page 10, line 22
Encapsulation: If there is DANE information for the name Encapsulation: If there is DANE information for the name
alice.example.com, it must only affect application services hosted alice.example.com, it must only affect application services hosted
at alice.example.com. at alice.example.com.
Predictability: Client behavior in response to DANE information must Predictability: Client behavior in response to DANE information must
be spelled out in the DANE specification as precisely as possible, be spelled out in the DANE specification as precisely as possible,
especially for cases where DANE information might conflict with especially for cases where DANE information might conflict with
PKIX information. PKIX information.
Opportunistic Security The DANE mechanism must allow a clients to Opportunistic Security The DANE mechanism must allow a client to
determine whether DANE information is available for a site, so determine whether DANE information is available for a site, so
that a client can provide the highest level of security possible that a client can provide the highest level of security possible
for a given application service. Clients that do not support DANE for a given application service. Clients that do not support DANE
should continue to work as if DANE information were not present. should continue to work as specified, regardless of whether DANE
information is present or not.
Combination: The DANE mechanism must allow multiple DANE statements Combination: The DANE mechanism must allow multiple DANE statements
of the above forms to be combined. For example, a domain holder of the above forms to be combined. For example, a domain holder
should be able to specify its own CA (Section Section 3.3) and should be able to specify that clients should accept a particular
require that no other be used (Section Section 3.1). certificate (Section Section 3.2) or any certificate issued by its
own CA (Section Section 3.3).
Roll-over: The DANE mechanism must allow a site to transition from Roll-over: The DANE mechanism must allow a site to transition from
using one DANE mechanism to another. For example, a domain holder using one DANE mechanism to another. For example, a domain holder
should be able to migrate from using DANE to assert a domain should be able to migrate from using DANE to assert a domain
issued certificate (Section Section 3.3) to using DANE to require issued certificate (Section Section 3.3) to using DANE to require
an external CA (Section Section 3.1), or vice versa. The DANE an external CA (Section Section 3.1), or vice versa. The DANE
mechanism must also allow roll-over between records of the same- mechanism must also allow roll-over between records of the same-
type, e.g., when changing CAs. type, e.g., when changing CAs.
Simple Key Management: DANE should have a mode in which the domain Simple Key Management: DANE should have a mode in which the domain
 End of changes. 20 change blocks. 
53 lines changed or deleted 70 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/