draft-ietf-dane-use-cases-04.txt   draft-ietf-dane-use-cases-05.txt 
DANE R. Barnes DANE R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational June 29, 2011 Intended status: Informational July 28, 2011
Expires: December 31, 2011 Expires: January 29, 2012
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-04.txt draft-ietf-dane-use-cases-05.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. Typically, this
authentication has been based on PKIX trust hierarchies, rooted in authentication has been based on PKIX certificate chains 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
authentication process. 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 Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 31, 2011. This Internet-Draft will expire on January 29, 2012.
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 3, line 16 skipping to change at page 3, line 16
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].
Application service clients typically establish TLS connections to Application service clients typically establish TLS connections to
application servers identified by DNS domain names. The process of application servers identified by DNS domain names. The process of
obtaining this "source" domain is application specific. The name obtaining this "source" domain is application specific [RFC6125].
could be entered by a user or found through an automated discovery The name could be entered by a user or found through an automated
process such as an SRV or NAPTR record. After obtaining the address discovery process such as an SRV or NAPTR record. After obtaining
of the server via an A or AAAA DNS record, the client conducts a TLS the address of the server via an A or AAAA DNS record, the client
handshake with the server, during which the server presents a PKIX conducts a TLS handshake with the server, during which the server
certificate [RFC5280]. The TLS layer performs PKIX validation of the presents a PKIX certificate [RFC5280]. The TLS layer performs PKIX
certificate, including verification that the certificate chains to a validation of the certificate, including verification that the
trust anchor. If this validation is successful, then the application certificate chains to one of the client's trust anchors. If this
layer determines whether the DNS name for the application service validation is successful, then the application layer determines
presented in the certificate matches the source domain name whether the DNS name for the application service presented in the
[RFC6125]. Typically, if the name matches, then the client proceeds certificate matches the source domain name [RFC6125]. Typically, if
with the TLS connection. the name matches, then the client proceeds with the TLS connection.
The certificate authorities (CAs) that issue PKIX certificates are The certificate authorities (CAs) that issue PKIX certificates 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 Clients thus rely on CAs to correctly assert bindings between public
keys and domain names, in the sense that the holder of the keys and domain names, in the sense that the holder of the
corresponding private key should be the domain holder. Today, an corresponding private key should be the domain holder. Today, an
skipping to change at page 4, line 36 skipping to change at page 4, line 36
the server role in TLS, rather than to a host. Multiple servers of the server role in TLS, rather than to a host. Multiple servers of
this type may be co-located on a single physical host, using this type may be co-located on a single physical host, using
different ports, and each of these can use different certificates. different ports, and each of these can use different certificates.
3. Use Cases 3. Use Cases
In this section, we describe the major use cases that the DANE In this section, we describe the major use cases that the DANE
mechanism should support. This list is not intended to represent all mechanism should support. This list is not intended to represent all
possible ways that the DNS can be used to support TLS authentication. possible ways that the DNS can be used to support TLS authentication.
Rather it represents the specific cases that comprise the initial Rather it represents the specific cases that comprise the initial
goal for DANE. goals for DANE.
In the below use cases, we will refer to the following dramatis In the below use cases, we will refer to the following dramatis
personae: personae:
Alice: The operator of a TLS-protected application service on the Alice: The operator of a TLS-protected application service on the
host alice.example.com, and administrator of the corresponding DNS host alice.example.com, and administrator of the corresponding DNS
zone. zone.
Bob: A client connecting to alice.example.com Bob: A client connecting to alice.example.com
Charlie: A well-known CA that issues certificates with domain names Charlie: A well-known CA that issues certificates with domain names
skipping to change at page 5, line 17 skipping to change at page 5, line 17
Oscar: An outsourcing provider that operates TLS-protected Oscar: An outsourcing provider that operates TLS-protected
application services on behalf of customers application services on behalf of customers
Trent: A CA that issues certificates with domain names as Trent: A CA that issues certificates with domain names as
identifiers, but is not generally well-known. identifiers, but is not generally well-known.
These use cases are framed in terms of adding verification steps to These use cases are framed in terms of adding verification steps to
TLS server identity checking on the part of application service TLS server identity checking on the part of application service
clients. In application services where the clients are also clients. In application services where the clients are also
identified by domain names (e.g., XMPP server-to-server connections), identified by domain names (e.g., XMPP server-to-server connections),
the same considerations and use cases can applied to the application the same considerations and use cases are applicable to the
server's checking of identities in TLS client certificates. application server's checking of identities in TLS client
certificates.
3.1. CA Constraints 3.1. CA 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 that certificate from the well-known CA Charlie. She is concerned that
other well-known CAs might issue certificates for alice.example.com other well-known CAs might issue certificates for alice.example.com
without her authorization, which clients would accept. Alice would without her authorization, which clients would accept. Alice would
like to provide a mechanism for visitors to her site to know that like to provide a mechanism for visitors to her site to know that
they should expect alice.example.com to use a certificate issued they should expect alice.example.com to use a certificate issued
under the CA that she uses (Charlie) and not another CA. That is, under the CA that she uses (Charlie) and not another CA. That is,
skipping to change at page 5, line 44 skipping to change at page 5, line 45
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 was issued verify that that the certificate presented by the server was issued
under the proper CA, Charlie. Bob also performs the normal PKIX under the proper CA, Charlie. Bob also performs the normal PKIX
validation procedure for this certificate, in particular verifying validation procedure for this certificate, in particular verifying
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 be 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 relying
could then check to see whether Alice said that her certificates parties. Charlie could then check to see whether Alice said that her
should be issued by Charlie or another CA. Note that this check does certificates should be issued by Charlie or another CA. Note that
not guarantee that the precise entity requesting a certification from this check does not guarantee that the precise entity requesting a
Charlie actually represents Alice, only that Alice has authorized certification from Charlie actually represents Alice, only that Alice
Charlie to issue certificates for her domain to properly authorized has authorized Charlie to issue certificates for her domain to
individuals. properly authorized individuals.
In principle, DANE information expressing CA constraints can be In principle, DANE information expressing CA constraints can be
presented with or without DNSSEC protection. Presenting DANE presented with or without DNSSEC protection. Presenting DANE
information without DNSSEC protection does not introduce any new information without DNSSEC protection does not introduce any new
vulnerabilities, but neither does it add much assurance. Deletion of vulnerabilities, but neither does it add much assurance. Deletion of
records removes the protection provided by this constraint, but the records removes the protection provided by this constraint, but the
client is still protected by CA practices (as now). Injected or client is still protected by CA practices (as now). Injected or
modified false records are not useful unless the attacker can also modified false records are not useful unless the attacker can also
obtain a certificate for the target domain. Thus, In the worst case, obtain a certificate for the target domain. Thus, In the worst case,
tampering with these constraints increases the risk of false tampering with these constraints increases the risk of false
skipping to change at page 7, line 28 skipping to change at page 7, line 29
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, because he that the issuer of the certificate is actually Alice, because he
doesn't necessarily possess Alice's corresponding trust anchor. This doesn't necessarily possess Alice's corresponding trust anchor. 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 publish information so that visitors to her
know that the certificates presented by her application services are site can know that the certificates presented by her application
legitimately hers. When Bob connects to alice.example.com, he uses services are legitimately hers. When Bob connects to
this mechanism to verify that the certificate presented by the server alice.example.com, he uses this information to verify that the
has been issued by Alice. Since Bob can bind certificates to Alice certificate presented by the server has been issued by Alice. Since
in this way, he can use Alice's CA as a trust anchor for purposes of Bob can bind certificates to Alice in this way, he can use Alice's CA
validating certificates for alice.example.com. Alice can as a trust anchor for purposes of validating certificates for
additionally recommend that clients accept only her certificates alice.example.com. Alice can additionally recommend that clients
using the CA constraints described above. accept only her certificates using the CA constraints described
above.
As in Section Section 3.1 above, Alice may wish to represent this As in Section Section 3.1 above, Alice may wish to represent this
information to potential third-party CAs (Charlie) as well as to information to potential third-party CAs (Charlie) as well as to
relying parties (Bob). Since publishing a certificate in a DANE relying parties (Bob). Since publishing a certificate in a DANE
record of this form authorizes the holder of the corresponding record of this form authorizes the holder of the corresponding
private key to represent alice.example.com, a CA that has received a 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 request to issue a certificate from alice.example.com could use the
DANE information to verify the requestor's authorization to receive a DANE information to verify the requestor's authorization to receive a
certificate for that domain. For example, a CA might choose to issue 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 a certificate for a given domain name and public key only when the
skipping to change at page 9, line 29 skipping to change at page 9, line 29
2. Alice refers to Oscar's DNS by delegating a sub-domain name to 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 Oscar, and has no control over the A/AAAA, DANE or any other
pieces under Oscar's control. pieces under Oscar's control.
3. Alice can put DANE records into her DNS server, but delegate the 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 address records to Oscar's DNS server. This means that Alice can
control the usage of certificates but Oscar is free to move the control the usage of certificates but Oscar is free to move the
servers around as needed. The only coordination needed is when servers around as needed. The only coordination needed is when
the certificates change, and then it would depend on how the DANE the certificates change, and then it would depend on how the DANE
record is set up (i.e. a CA or an EE certificate pointer). 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 Which of these deployment patterns is used in a given deployment will
determine what sort of constraints can be made. In cases where Alice determine what sort of constraints can be expressed by which actors.
controls DANE records (1 and 3), she can use CA and certificate In cases where Alice controls DANE records (1 and 3), she can use CA
constraints to control what certificates Oscar presents for Alice's and certificate constraints to control what certificates Oscar
application services. For instance, Alice might require Oscar to use presents for Alice's application services. For instance, Alice might
certificates under a given set of CAs. This control, however, require Oscar to use certificates under a given set of CAs. This
requires that Alice update DANE records when Oscar needs to change control, however, requires that Alice update DANE records when Oscar
certificates. Cases where Oscar controls DANE records allow Oscar to needs to change certificates. Cases where Oscar controls DANE
maintain more autonomy from Alice, but by the same token, Alice records allow Oscar to maintain more autonomy from Alice, but by the
cannot enforce any requirements on the certificates that Oscar same token, Alice cannot enforce any requirements on the certificates
presents in TLS handshakes. that Oscar presents in TLS handshakes.
4. Other Requirements 4. Other Requirements
In addition to supporting the above use cases, the DANE mechanism In addition to supporting the above use cases, the DANE mechanism
must satisfy several lower-level operational and protocol must satisfy several lower-level operational and protocol
requirements and goals. requirements and goals.
Multiple Ports: DANE should be able to support multiple application Multiple Ports: DANE should be able to support multiple application
services with different credentials on the same named host, services with different credentials on the same named host,
distinguished by port number. distinguished by port number.
No Downgrade: An attacker who can tamper with DNS responses must not 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 be able to make a DANE-compliant client treat a site that has
deployed DANE and DNSSEC like a site that has deployed neither. deployed DANE and DNSSEC like a site that has deployed neither.
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 defined 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 client 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 specified, regardless of whether DANE should continue to work as specified, regardless of whether DANE
information is present or not. 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 that clients should accept a particular should be able to specify that clients should accept a particular
certificate (Section Section 3.2) or any certificate issued by its certificate (Section Section 3.2) as well as any certificate
own CA (Section Section 3.3). issued by its own CA (Section 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 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
skipping to change at page 11, line 14 skipping to change at page 11, line 14
Minimal Options: Ideally, DANE should have only one operating mode. Minimal Options: Ideally, DANE should have only one operating mode.
Practically, DANE should have as few operating modes as possible. Practically, DANE should have as few operating modes as possible.
Wild Cards: The mechanism for distributing DANE information should Wild Cards: The mechanism for distributing DANE information should
allow the use of DNS wild card labels (*) for setting DANE allow the use of DNS wild card labels (*) for setting DANE
information for all names within a wild card expansion. information for all names within a wild card expansion.
Redirection: The mechanism for distributing DANE information should Redirection: The mechanism for distributing DANE information should
work when the application service name is the result of following work when the application service name is the result of following
a DNS redirection time (e.g., via CNAME or DNAME). a DNS redirection chain (e.g., via CNAME or DNAME).
5. Acknowledgements 5. Acknowledgements
Thanks to Eric Rescorla for the initial formulation of the use cases, Thanks to Eric Rescorla for the initial formulation of the use cases,
Zack Weinberg and Phillip Hallam-Baker for contributing other Zack Weinberg and Phillip Hallam-Baker for contributing other
requirements, and the whole DANE working group for helpful comments requirements, and the whole DANE working group for helpful comments
on the mailing list. on the mailing list.
6. IANA Considerations 6. IANA Considerations
skipping to change at page 12, line 8 skipping to change at page 12, line 8
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[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.
8.2. Informative References 8.2. Informative References
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999. RFC 2595, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. Transport Layer Security", RFC 3207, February 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. 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 Author's Address
Richard Barnes Richard Barnes
BBN Technologies BBN Technologies
9861 Broken Land Parkway 9861 Broken Land Parkway
Columbia, MD 21046 Columbia, MD 21046
US US
Phone: +1 410 290 6169 Phone: +1 410 290 6169
Email: rbarnes@bbn.com Email: rbarnes@bbn.com
 End of changes. 18 change blocks. 
60 lines changed or deleted 66 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/