idnits 2.17.1 draft-ietf-dane-use-cases-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 28, 2011) is 4650 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DANE R. Barnes 3 Internet-Draft BBN Technologies 4 Intended status: Informational July 28, 2011 5 Expires: January 29, 2012 7 Use Cases and Requirements for DNS-based Authentication of Named 8 Entities (DANE) 9 draft-ietf-dane-use-cases-05.txt 11 Abstract 13 Many current applications use the certificate-based authentication 14 features in TLS to allow clients to verify that a connected server 15 properly represents a desired domain name. Typically, this 16 authentication has been based on PKIX certificate chains rooted in 17 well-known CAs, but additional information can be provided via the 18 DNS itself. This document describes a set of use cases in which the 19 DNS and DNSSEC could be used to make assertions that support the TLS 20 authentication process. The main focus of this document is TLS 21 server authentication, but it also covers TLS client authentication 22 for applications where TLS clients are identified by domain names. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 29, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. CA Constraints . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. Service Certificate Constraints . . . . . . . . . . . . . 6 63 3.3. Trust Anchor Assertion and Domain-Issued Certificates . . 7 64 3.4. Delegated Services . . . . . . . . . . . . . . . . . . . . 9 65 4. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 9 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 Transport-Layer Security (TLS) is used as the basis for security 77 features in many modern Internet application service protocols to 78 provide secure client-server connections [RFC5246]. It underlies 79 secure HTTP and secure email [RFC2818][RFC2595][RFC3207], and 80 provides hop-by-hop security in real-time multimedia and instant- 81 messaging protocols [RFC3261][RFC6120]. 83 Application service clients typically establish TLS connections to 84 application servers identified by DNS domain names. The process of 85 obtaining this "source" domain is application specific [RFC6125]. 86 The name could be entered by a user or found through an automated 87 discovery process such as an SRV or NAPTR record. After obtaining 88 the address of the server via an A or AAAA DNS record, the client 89 conducts a TLS handshake with the server, during which the server 90 presents a PKIX certificate [RFC5280]. The TLS layer performs PKIX 91 validation of the certificate, including verification that the 92 certificate chains to one of the client's trust anchors. If this 93 validation is successful, then the application layer determines 94 whether the DNS name for the application service presented in the 95 certificate matches the source domain name [RFC6125]. Typically, if 96 the name matches, then the client proceeds with the TLS connection. 98 The certificate authorities (CAs) that issue PKIX certificates are 99 asserting bindings between domain names and the public keys they 100 certify. Application service clients are verifying these bindings 101 and making authorization decisions -- whether to proceed with 102 connections -- based on them. 104 Clients thus rely on CAs to correctly assert bindings between public 105 keys and domain names, in the sense that the holder of the 106 corresponding private key should be the domain holder. Today, an 107 attacker can successfully authenticate as a given application service 108 domain if he can obtain a "mis-issued" ciertificate from one of the 109 widely-used CAs -- a certificate containing the victim application 110 service's domain name and a public key whose corresponding private 111 key is held by the attacker. If the attacker can additionally insert 112 himself as a man in the middle between an client and server (e.g., 113 through DNS cache poisoning of an A or AAAA record), then the 114 attacker can convince the client that a server of the attacker's 115 choice legitimately represents the victim's application service. 117 With the advent of DNSSEC [RFC4033], it is now possible for DNS name 118 resolution to provide its information securely, in the sense that 119 clients can verify that DNS information was provided by the domain 120 holder and not tampered with in transit. The goal of technologies 121 for DNS-based Authentication of Named Entities (DANE) is to use the 122 DNS and DNSSEC to provide additional information about the 123 cryptographic credentials associated with a domain, so that clients 124 can use this information to increase the level of assurance they 125 receive from the TLS handshake process. This document describes a 126 set of use cases that capture specific goals for using the DNS in 127 this way, and a set of requirements that the ultimate DANE mechanism 128 should satisfy. 130 Finally, it should be noted that although this document will 131 frequently use HTTPS as an example application service, DANE is 132 intended to apply equally to all applications that make use of TLS to 133 connect to application services named by domain names. 135 2. Definitions 137 This document also makes use of standard PKIX, DNSSEC, and TLS 138 terminology. See RFC 5280 [RFC5280], RFC 4033 [RFC4033], and RFC 139 5246 [RFC5246], respectively, for these terms. In addition, terms 140 related to TLS-protected application services and DNS names are taken 141 from RFC 6125 [RFC6125]. 143 Note in particular that the term "server" in this document refers to 144 the server role in TLS, rather than to a host. Multiple servers of 145 this type may be co-located on a single physical host, using 146 different ports, and each of these can use different certificates. 148 3. Use Cases 150 In this section, we describe the major use cases that the DANE 151 mechanism should support. This list is not intended to represent all 152 possible ways that the DNS can be used to support TLS authentication. 153 Rather it represents the specific cases that comprise the initial 154 goals for DANE. 156 In the below use cases, we will refer to the following dramatis 157 personae: 159 Alice: The operator of a TLS-protected application service on the 160 host alice.example.com, and administrator of the corresponding DNS 161 zone. 163 Bob: A client connecting to alice.example.com 164 Charlie: A well-known CA that issues certificates with domain names 165 as identifiers 167 Oscar: An outsourcing provider that operates TLS-protected 168 application services on behalf of customers 170 Trent: A CA that issues certificates with domain names as 171 identifiers, but is not generally well-known. 173 These use cases are framed in terms of adding verification steps to 174 TLS server identity checking on the part of application service 175 clients. In application services where the clients are also 176 identified by domain names (e.g., XMPP server-to-server connections), 177 the same considerations and use cases are applicable to the 178 application server's checking of identities in TLS client 179 certificates. 181 3.1. CA Constraints 183 Alice runs a website on alice.example.com and has obtained a 184 certificate from the well-known CA Charlie. She is concerned that 185 other well-known CAs might issue certificates for alice.example.com 186 without her authorization, which clients would accept. Alice would 187 like to provide a mechanism for visitors to her site to know that 188 they should expect alice.example.com to use a certificate issued 189 under the CA that she uses (Charlie) and not another CA. That is, 190 Alice is recommending that the client verify that there is a valid 191 certificate chain from the server certificate to Charlie before 192 accepting the server certificate. (For example, in the TLS 193 handshake, the server might include Charlie's certificate in the 194 server Certificate message's certificate_list structure [RFC5246]). 196 When Bob connects to alice.example.com, he uses this mechanism to 197 verify that that the certificate presented by the server was issued 198 under the proper CA, Charlie. Bob also performs the normal PKIX 199 validation procedure for this certificate, in particular verifying 200 that the certificate chains to a trust anchor (possibly Charlie's CA, 201 if Bob accepts Charlie's CA as a trust anchor). 203 Alice may wish to provide similar information to an external CA 204 operator Charlie. Prior to issuing a certificate for 205 alice.example.com to someone claiming to be Alice, Charlie needs to 206 verify that Alice is actually requesting a certificate. Alice could 207 indicate her preferred CA using DANE to CAs as well as relying 208 parties. Charlie could then check to see whether Alice said that her 209 certificates should be issued by Charlie or another CA. Note that 210 this check does not guarantee that the precise entity requesting a 211 certification from Charlie actually represents Alice, only that Alice 212 has authorized Charlie to issue certificates for her domain to 213 properly authorized individuals. 215 In principle, DANE information expressing CA constraints can be 216 presented with or without DNSSEC protection. Presenting DANE 217 information without DNSSEC protection does not introduce any new 218 vulnerabilities, but neither does it add much assurance. Deletion of 219 records removes the protection provided by this constraint, but the 220 client is still protected by CA practices (as now). Injected or 221 modified false records are not useful unless the attacker can also 222 obtain a certificate for the target domain. Thus, In the worst case, 223 tampering with these constraints increases the risk of false 224 authentication to the level that is now standard. 226 Using DANE information for CA constraints without DNSSEC provides a 227 very small incremental security feature. Many common attacks against 228 TLS connections already require the attacker to inject false A or 229 AAAA records in order to steer the victim client to the attacker's 230 server. An attacker that can already inject false DNS records can 231 also provide fake DANE information (without DNSSEC) by simply 232 spoofing the additional records required to carry the DANE 233 information. 235 Injected or modified false DANE information of this type can be used 236 for denial of service, even if the attacker does not have a 237 certificate for the target domain. If an attacker can modify DNS 238 responses that a target host receives, however, there are already 239 much simpler ways of denying service, such as providing a false A or 240 AAAA record. In this case, DNSSEC is not helpful, since an attacker 241 could still case a denial of service by blocking all DNS responses 242 for the target domain. 244 Continuing to require PKIX validation also limits the degree to which 245 DNS operators (as distinct from the holders of domains) can interfere 246 with TLS authentication through this mechanism. As above, even if a 247 DNS operator falsifies DANE records, it cannot masquerade as the 248 target server unless it can also obtain a certificate for the target 249 domain. 251 3.2. Service Certificate Constraints 253 Alice runs a website on alice.example.com and has obtained a 254 certificate from the well-known CA Charlie. She is concerned about 255 additional, unauthorized certificates being issued by Charlie as well 256 as by other CAs. She would like to provide a way for visitors to her 257 site to know that they should expect alice.example.com to present a 258 specific certificate. In TLS terms, Alice is letting Bob know that 259 this specific certificate must be the first certificate in the server 260 Certificate message's certificate_list structure [RFC5246]. 262 When Bob connects to alice.example.com, he uses this mechanism to 263 verify that that the certificate presented by the server is the 264 correct certificate. Bob also performs the normal PKIX validation 265 procedure for this certificate, in particular verifying that the 266 certificate chains to a trust anchor. 268 The security implications for this case are the same as for the "CA 269 Constraints" case above. 271 3.3. Trust Anchor Assertion and Domain-Issued Certificates 273 Alice would like to be able to generate and use certificates for her 274 website on alice.example.com without involving an external CA at all. 275 Alice can generate her own certificates today, making self-signed 276 certificates and possibly certificates subordinate to those 277 certificates. When Bob receives such a certificate in a TLS 278 handshake, however, he doesn't automatically have a way to verify 279 that the issuer of the certificate is actually Alice, because he 280 doesn't necessarily possess Alice's corresponding trust anchor. This 281 concerns him because an attacker could present a different 282 certificate and perform a man in the middle attack. Bob would like 283 to protect against this. 285 Alice would thus like to publish information so that visitors to her 286 site can know that the certificates presented by her application 287 services are legitimately hers. When Bob connects to 288 alice.example.com, he uses this information to verify that the 289 certificate presented by the server has been issued by Alice. Since 290 Bob can bind certificates to Alice in this way, he can use Alice's CA 291 as a trust anchor for purposes of validating certificates for 292 alice.example.com. Alice can additionally recommend that clients 293 accept only her certificates using the CA constraints described 294 above. 296 As in Section Section 3.1 above, Alice may wish to represent this 297 information to potential third-party CAs (Charlie) as well as to 298 relying parties (Bob). Since publishing a certificate in a DANE 299 record of this form authorizes the holder of the corresponding 300 private key to represent alice.example.com, a CA that has received a 301 request to issue a certificate from alice.example.com could use the 302 DANE information to verify the requestor's authorization to receive a 303 certificate for that domain. For example, a CA might choose to issue 304 a certificate for a given domain name and public key only when the 305 holder of the domain name has provisioned DANE information with a 306 certificate containing the public key. 308 Note that this use case is functionally equivalent to the case where 309 Alice doesn't issue her own certificates, but uses Trent's CA, which 310 is not well-known. In this case, Alice would be advising Bob that he 311 should treat Trent as a trust anchor for purposes of validating 312 Alice's certificates, rather than a CA operated by Alice herself. 313 Bob would thus need a way to securely obtain Trent's trust anchor 314 information, namely through DANE information. 316 Alice's advertising of trust anchor material in this way does not 317 guarantee that Bob will accept the advertised trust anchor. For 318 example, Bob might have out-of-band information (such as a pre- 319 existing local policy) that indicates that the CA advertised by Alice 320 (Trent's CA) is not trustworthy, which would lead him to decide not 321 to accept Trent as a TA, and thus to reject Alice's certificate if it 322 is issued under Trent's CA. 324 Providing trust anchor material in this way clearly requires DNSSEC, 325 since corrupted or injected records could be used by an attacker to 326 cause clients to trust an attacker's certificate (assuming that the 327 attacker's certificate is not rejected by some other local policy). 328 Deleted records will only result in connection failure and denial of 329 service, although this could result in clients re-connecting without 330 TLS (a downgrade attack), depending on the application. Therefore, 331 in order for this use case to be safe, applications must forbid 332 clients from falling back to unsecured channels when records appear 333 to have been deleted (e.g., when a missing record has no NSEC or 334 NSEC3 record). 336 By the same token, this use case puts the most power in the hands of 337 DNS operators. Since the operator of the appropriate DNS zone has de 338 facto control over the content and signing of the zone, he can create 339 false DANE records that bind a malicious party's certificate to a 340 domain. This risk is especially important to keep in mind in cases 341 where the operator of a DNS zone is a different entity than the 342 holder of the domain, as in DNS hosting/outsourcing arrangements, 343 since in these cases the DNS operator might be able to make changes 344 to a domain that are not authorized by the holder of the domain. 346 It should be noted that DNS operators already have the ability to 347 obtain certificates for domains under their control, under certain CA 348 policies. In the current system, CAs need to verify that an entity 349 requesting a certificate for a domain is actually the legitimate 350 holder of that domain. Typically this is done using information 351 published about that domain, such as WHOIS email addresses or special 352 records inserted into a domain. By manipulating these values, it is 353 possible for DNS operators to obtain certificates from some well- 354 known certificate authorities today without authorization from the 355 true domain holder. 357 3.4. Delegated Services 359 In addition to guarding against CA mis-issue, CA constraints and 360 certificate constraints can also be used to constrain the set of 361 certificates that can be used by an outsourcing provider. Suppose 362 that Oscar operates alice.example.com on behalf of Alice. In 363 particular, Oscar then has de facto control over what certificates to 364 present in TLS handshakes for alice.example.com. In such cases, 365 there are few ways that DNS-based information about TLS certificates 366 could be configured, for example: 368 1. Alice has the A/AAAA records in her DNS and can sign them along 369 with the DANE record, but Oscar and Alice now need to have tight 370 coordination if the addresses and/or the certificates change. 372 2. Alice refers to Oscar's DNS by delegating a sub-domain name to 373 Oscar, and has no control over the A/AAAA, DANE or any other 374 pieces under Oscar's control. 376 3. Alice can put DANE records into her DNS server, but delegate the 377 address records to Oscar's DNS server. This means that Alice can 378 control the usage of certificates but Oscar is free to move the 379 servers around as needed. The only coordination needed is when 380 the certificates change, and then it would depend on how the DANE 381 record is set up (i.e. a CA or an end entity certificate 382 pointer). 384 Which of these deployment patterns is used in a given deployment will 385 determine what sort of constraints can be expressed by which actors. 386 In cases where Alice controls DANE records (1 and 3), she can use CA 387 and certificate constraints to control what certificates Oscar 388 presents for Alice's application services. For instance, Alice might 389 require Oscar to use certificates under a given set of CAs. This 390 control, however, requires that Alice update DANE records when Oscar 391 needs to change certificates. Cases where Oscar controls DANE 392 records allow Oscar to maintain more autonomy from Alice, but by the 393 same token, Alice cannot enforce any requirements on the certificates 394 that Oscar presents in TLS handshakes. 396 4. Other Requirements 398 In addition to supporting the above use cases, the DANE mechanism 399 must satisfy several lower-level operational and protocol 400 requirements and goals. 402 Multiple Ports: DANE should be able to support multiple application 403 services with different credentials on the same named host, 404 distinguished by port number. 406 No Downgrade: An attacker who can tamper with DNS responses must not 407 be able to make a DANE-compliant client treat a site that has 408 deployed DANE and DNSSEC like a site that has deployed neither. 410 Encapsulation: If there is DANE information for the name 411 alice.example.com, it must only affect application services hosted 412 at alice.example.com. 414 Predictability: Client behavior in response to DANE information must 415 be defined in the DANE specification as precisely as possible, 416 especially for cases where DANE information might conflict with 417 PKIX information. 419 Opportunistic Security The DANE mechanism must allow a client to 420 determine whether DANE information is available for a site, so 421 that a client can provide the highest level of security possible 422 for a given application service. Clients that do not support DANE 423 should continue to work as specified, regardless of whether DANE 424 information is present or not. 426 Combination: The DANE mechanism must allow multiple DANE statements 427 of the above forms to be combined. For example, a domain holder 428 should be able to specify that clients should accept a particular 429 certificate (Section Section 3.2) as well as any certificate 430 issued by its own CA (Section Section 3.3). The precise types of 431 combination allowed will be defined by the DANE protocol. 433 Roll-over: The DANE mechanism must allow a site to transition from 434 using one DANE mechanism to another. For example, a domain holder 435 should be able to migrate from using DANE to assert a domain 436 issued certificate (Section Section 3.3) to using DANE to require 437 an external CA (Section Section 3.1), or vice versa. The DANE 438 mechanism must also allow roll-over between records of the same- 439 type, e.g., when changing CAs. 441 Simple Key Management: DANE should have a mode in which the domain 442 holder only needs to maintain a single long-lived public/private 443 key pair. 445 Minimal Dependencies: It should be possible for a site to deploy 446 DANE without also deploying anything else, except DNSSEC. 448 Minimal Options: Ideally, DANE should have only one operating mode. 449 Practically, DANE should have as few operating modes as possible. 451 Wild Cards: The mechanism for distributing DANE information should 452 allow the use of DNS wild card labels (*) for setting DANE 453 information for all names within a wild card expansion. 455 Redirection: The mechanism for distributing DANE information should 456 work when the application service name is the result of following 457 a DNS redirection chain (e.g., via CNAME or DNAME). 459 5. Acknowledgements 461 Thanks to Eric Rescorla for the initial formulation of the use cases, 462 Zack Weinberg and Phillip Hallam-Baker for contributing other 463 requirements, and the whole DANE working group for helpful comments 464 on the mailing list. 466 6. IANA Considerations 468 This document makes no request of IANA. 470 7. Security Considerations 472 The primary focus of this document is the enhancement of TLS 473 authentication procedures using the DNS. The general effect of such 474 mechanisms is to increase the role of DNS operators in authentication 475 processes, either in place of or in addition to traditional third- 476 party actors such as commercial certificate authorities. The 477 specific security implications of the respective use cases are 478 discussed in their respective sections above. 480 8. References 482 8.1. Normative References 484 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 485 Rose, "DNS Security Introduction and Requirements", 486 RFC 4033, March 2005. 488 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 489 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 491 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 492 Housley, R., and W. Polk, "Internet X.509 Public Key 493 Infrastructure Certificate and Certificate Revocation List 494 (CRL) Profile", RFC 5280, May 2008. 496 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 497 Verification of Domain-Based Application Service Identity 498 within Internet Public Key Infrastructure Using X.509 499 (PKIX) Certificates in the Context of Transport Layer 500 Security (TLS)", RFC 6125, March 2011. 502 8.2. Informative References 504 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 505 RFC 2595, June 1999. 507 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 509 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 510 Transport Layer Security", RFC 3207, February 2002. 512 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 513 A., Peterson, J., Sparks, R., Handley, M., and E. 514 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 515 June 2002. 517 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 518 Protocol (XMPP): Core", RFC 6120, March 2011. 520 Author's Address 522 Richard Barnes 523 BBN Technologies 524 9861 Broken Land Parkway 525 Columbia, MD 21046 526 US 528 Phone: +1 410 290 6169 529 Email: rbarnes@bbn.com