idnits 2.17.1 draft-barnes-xmpp-dna-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 19, 2010) is 4998 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 521, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3401 (ref. '2') ** Obsolete normative reference: RFC 5246 (ref. '3') (Obsoleted by RFC 8446) == Outdated reference: A later version (-11) exists of draft-ietf-xmpp-dna-00 -- Obsolete informational reference (is this intentional?): RFC 974 (ref. '11') (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. '12') (Obsoleted by RFC 6120) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Barnes 3 Internet-Draft BBN Technologies 4 Intended status: Standards Track August 19, 2010 5 Expires: February 20, 2011 7 Domain Name Assertions 8 draft-barnes-xmpp-dna-00.txt 10 Abstract 12 Many Internet applications allow service delegation via the DNS. 13 However, in the absence of DNSSEC, these delegations are 14 unauthenticated, so clients have to authenticate the delegate as if 15 he were the original service. This situation causes several 16 operational problems. This document describes a mechanism for 17 clients to discover and validate information that authenticates DNS- 18 based service delegations, without relying on the global deployment 19 of DNSSEC. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 20, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. General Procedure . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Authenticator Discovery . . . . . . . . . . . . . . . . . . . 5 59 4.1. DNS-Based Discovery . . . . . . . . . . . . . . . . . . . 6 60 4.2. Security-Protocol Discovery . . . . . . . . . . . . . . . 7 61 4.3. Application-Layer Discovery . . . . . . . . . . . . . . . 7 62 5. Authenticator Formats and Validation . . . . . . . . . . . . . 8 63 5.1. Attribute Certificate . . . . . . . . . . . . . . . . . . 8 64 5.2. DNSSEC External Trust Anchor . . . . . . . . . . . . . . . 9 65 5.3. PKIX Certificate with SRVName . . . . . . . . . . . . . . 10 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 Many Internet applications use the DNS for service discovery and 77 delegation. The most long-standing example of this usage of the DNS 78 is of course the use of MX records to discover mail servers [11]. 79 That pattern has been re-used with modern services, having been 80 generalized through the introduction of SRV records and the Dynamic 81 Delegation Discovery System (DDDS) [1][2]. For example, XMPP and SIP 82 services are found using SRV records [12][13], while LoST and HELD 83 services use NAPTR records (i.e., they use DDDS) [14][15]. 85 Because these records direct a client from one domain to another (an 86 "source" name to a "target" name), they can create challenges for 87 server authentication. When the client ultimately connects to a 88 remote endpoint, should the client expect it to authenticate as the 89 source or the target? The answer to this question has important 90 operational impact, especially in situations where the source and 91 target domains are operated by different entities. 93 If the client cannot verify that the DNS records involved in the 94 delegation are authentic, then these records cannot be trusted. 95 Since spoofed delegation records could be used to point the client to 96 an attacker's server (e.g., to insert a man-in-the-middle), the 97 client must require the server to authenticate as the source domain. 99 For example: Let us assume that a company called Example.com wishes 100 to offload responsibility for its corporate instant messaging service 101 ("im.example.com") to a hosting provider called Apps.Example.Net 102 using XMPP. The company sets up DNS service location records that 103 point im.example.com at apps.example.net: 105 _xmpp-client._tcp.im.example.com. 90 IN SRV 0 0 5222 apps.example.net 106 _xmpp-server._tcp.im.example.com. 90 IN SRV 0 0 5269 apps.example.net 108 When a user juliet@example.com attempts to log in to the IM service 109 at im.example.com, her client discovers apps.example.net and resolves 110 that name to an IP address and port. However, Juliet wants to be 111 sure that the connection is encrypted using Transport Layer Security 112 [3] so her client checks the certificate offered by the XMPP service 113 at the resolved IP address and port. 115 Her client expects the server identity in the certificate to be 116 "im.example.com" (or perhaps "*.example.com"). But what if the 117 identity is, instead, "apps.example.net" or "*.example.net"? Now her 118 client will need to prompt Juliet to accept this certificate mismatch 119 either temporarily or permanently. Because such security warnings 120 are unnerving to end users, the owners of the company would prefer 121 that the IM service offer a certificate with an identity of 122 "im.example.com". Unfortunately, the IM server software used by the 123 hosting provider probably needs runtime access to the private key 124 associated with the certificate. This makes both the security 125 personnel at Example.com and the lawyers at Apps.Hosting.Net 126 uncomfortable. 128 If the delegation records in question are authenticated, then the 129 client can verify that the service has indeed been delegated to the 130 target domain, and can authenticate the server as the target. This 131 authentication can be provided with DNSSEC [4], but only if the 132 signatures on the delegation records chain back to a key that the 133 client accepts as a trust anchor (ideally, the root key). In the 134 current DNSSEC deployment environment, only a few domains have full 135 chains back to the root, and there is no general agreement on trust 136 anchors other than the root. 138 This document discusses an intermediate solution for authenticating 139 DNS delegation records in situations where DNSSEC cannot be used. We 140 define a general process that clients can use to determine whether to 141 use the source or target domain as the identifier that a server must 142 authenticate, then consider some specific techniques for 143 accomplishing this general procedure and their practical trade-offs. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [5]. 151 This document uses the word "delegation" to encompass several 152 different mechanisms for delegating services from one name to another 153 using the DNS, including MX records, SRV records, and the DDDS. 154 These mechanisms delegate services from one DNS name to another. We 155 call the name being delegated the "source name" or "source domain" 156 and the recipient of the delegation and the recipient of the 157 delegation the "target" name or domain. We do not distinguish the 158 case where the output of the delegation may be something other than a 159 domain name (e.g., a URI), as can happen in DDDS. 161 We generally consider these delegations in the form of a single 162 record; in cases where multiple delegations are chained together (as 163 can happen in DDDS), the techniques here may be repeated. 165 Delegation records will be authenticated using signed data objects, 166 which we generally refer to as "authenticators". Clients find these 167 data objects using an "authenticator discovery" process based on the 168 source domain whose services they are seeking. 170 3. General Procedure 172 When a client seeks to connect to a service that is located using DNS 173 delegation records, it needs to be able to authenticate the validity 174 of these records so that it knows whether to authenticate the located 175 server as the source or target domain. The general process for 176 discovering and authenticating a delegation is as follows: 178 1. The client retrieves the delegation record (e.g., MX, SRV, 179 NAPTR). 181 2. If the delegation record is protected by DNSSEC, chaining back to 182 one of the client's trust anchors, then the client matches the 183 server's authenticated identity against the target name for the 184 delegation. 186 3. The client queries for an authenticator for the delegation 187 record. 189 4. If an authenticator is present, the client validates that it 190 corresponds to the delegation record and that it is issued by a 191 trusted authority. 193 5. If the authenticator is present and valid, the client matches the 194 server's authenticated identity against the target name for the 195 delegation. 197 6. Otherwise, the client matches against the source name for the 198 delegation. 200 The specific procedures for authenticator discovery and validation 201 are discussed in Section 4 and Section 5. 203 Note that this procedure smoothly degrades as DNSSEC becomes more 204 widely available. Technically speaking, DNSSEC signatures could be 205 considered as a form of authenticator, but because of the importance 206 of transition for this mechanism (and because of some conceptual 207 differences from other authenticators), the procedure above 208 accommodates with a specific "short cut". 210 4. Authenticator Discovery 212 To allow clients to authenticators delegation records, there needs to 213 be a way for them to gain access to the signed objects or 214 "authenticators" that attest to the delegation. There are basically 215 three points in the connection process where an authenticator can be 216 provided: 218 1. Before connection establishment, as part of the DNS 220 2. During connection establishment, as part of the security protocol 222 3. After connection establishment, as part of the application 224 In the below sections, we outline how authenticators can be provided 225 in each of these cases, and discuss their relative merits. 227 4.1. DNS-Based Discovery 229 Since all of the below authenticator formats are based on digital 230 certificates, source domain operators can publish them using DNS CERT 231 records [6] under a well-known name related to the source name. For 232 example, if im.example.com is delegating its XMPP services to 233 apps.example.net, and authenticating with an X.509 certificate (to be 234 obtained from a URL), it would provision the following records: 235 _xmpp-client._tcp.im.example.com. 90 IN SRV 0 0 5222 apps.example.net 236 _dna._xmpp-client._tcp.im.example.com. 90 IN CERT 4 12345 5 237 http://example.com/im.crt 239 _xmpp-server._tcp.im.example.com. 90 IN SRV 0 0 5269 apps.example.net 240 _dna._xmpp-server._tcp.im.example.com. 90 IN CERT 4 12345 5 241 http://example.com/im.crt 243 A client can then construct the name for the delegation (the source 244 name) using any technique defined by the delegation mechanism, then 245 append the reserved label "_dna" to find the authenticator for the 246 delegation. (As a simplification, one might also consider simply 247 provisioning the CERT record under the same name as the delegation 248 record. The _dna label is useful, however, to distinguish these 249 certificates from certificates used for other purposes.) 251 This discovery mechanism has the benefit of directness. 252 Authenticators have to ultimately originate with the source domain, 253 since that is the domain that is authoritative for the delegation. 254 In the other two cases below, the authenticator has to be provided to 255 the target server, who then provides it to the client, while in this 256 case, the client can simply receive the authenticator directly from 257 the source domain. 259 Likewise, this technique is very general. It is completely agnostic 260 to the type of security protocol or application protocol being used, 261 and requires no changes to either protocol. It also applies without 262 modification to all the different record types that can be used for 263 delegation. 265 One challenge for this technique, as for the application-layer 266 discovery discussed below, is the question of how the source domain 267 can present a certificate chain to help the client validate the 268 authenticator. It may be possible to address this challenge by 269 including multiple CERT records under the same domain name. These 270 certificate can either be considered as an unordered list, leaving 271 the client to assemble them together into a certificate chain, or as 272 an sequence ordered by the preference values in the records. 274 4.2. Security-Protocol Discovery 276 Security protocols already have syntax for endpoints to provide 277 authentication credentials of enough different types to cover the 278 different authenticator formats discussed below. However, providing 279 these authenticators as part of the establishment of a secure channel 280 is generally not practical. 282 For example, at the time of session establishment, a server typically 283 has to provide authentication credentials before it knows what 284 identity the client is expecting, so a server that hosts many domains 285 would need to have a single certificate that covers all possible 286 delegations pointing to it. In addition to creating very large 287 credentials, such credentials would need to be re-issued whenever a 288 delegation changed. A server would thus need effectively the same 289 credential as if it were simply authenticating the source domain of 290 the delegation, with the same operational issues, negating any 291 benefit to authenticating the delegation. 293 4.3. Application-Layer Discovery 295 Several applications include mechanisms for protocol endpoints to 296 challenge one another for authentication credentials. In XMPP, for 297 example, one endpoint can issue a stanza indicating what 298 sort of proof is desired, and the other endpoint can reply with a 299 stanza containing the required authenticator. HTTP uses 300 the WWW-Authenticate and Authorization headers in a similar way. 302 In order to use this mechanisms to authenticate a delegated service, 303 the client would need to provisionally accept the credentials 304 presented by the server in the security protocol. It would also have 305 to make sure that no other protocol interactions occur before the 306 authenticator has been received and validated. 308 The main benefit of handling delegation authentication at the 309 application layer is that protocol interactions can be very rich. 310 Applications that incorporate the SASL framework (such as XMPP) can 311 benefit from the security semantics that it provides [7]. The 312 obvious challenge, however, is that each application that wishes to 313 benefit from authenticated delegations will have to have its own 314 extension to carry authenticators. In addition, the requirement to 315 provisionally accept a secure connection could impose additional 316 complexity and resource requirements on the client. 318 5. Authenticator Formats and Validation 320 An authenticator is a signed object that attests to the validity of a 321 given delegation by presenting a version of it that is signed by the 322 source domain. In this section we discuss three possible forms that 323 such an authenticator can take, and their relative merits. 325 In evaluating these authenticator formats, it's important to keep in 326 mind a few requirements. An authenticator must have two basic parts, 327 a representation of the delegation that is being authenticated, and 328 signature over that representation that can be verified using a 329 private key bound to the source domain. It is important that the 330 signature attesting to the validity be from the source domain, since 331 the source domain is the entity making the delegation. If another 332 entity were to attest the delegation by presenting an authenticator 333 under its signature, then there would be a need to verify that it was 334 authorized to do so by the source domain. 336 In addition to these structural requirements, there is a practical 337 requirement that the issuance and revocation of authenticators should 338 not be difficult using current certificate management software and 339 practices. Some particular usability questions that will come up are 340 whether a single authenticator can be used for multiple services, and 341 whether an authenticator can be applied to all the different kinds of 342 delegation records. 344 The basic security assumption for all of the below formats is that 345 the source domain operator has a certificate that binds the source 346 domain name to a public key, and that this certificate chains up to a 347 trust anchor recognized by the client. We will refer to this 348 certificate as the source domain's "authentication certificate" 349 below. In general, when we mention a name in a certificate, we allow 350 for this name to be provided either as a Common Name or a dNSName 351 Subject Alternative Name (the latter being preferred, but the former 352 included for backward compatibility). 354 5.1. Attribute Certificate 356 Format: An attribute certificate using the format specified in 357 [draft-ietf-xmpp-dna]. The delegation is encoded in the relationship 358 between the subject and the issuer, and in the service field of the 359 certificate. The issuer is the source, the subject is the target, 360 and the OID in the service field specifies the service being 361 delegated. The signature over the delegation is the signature on the 362 certificate. 364 Validation: The client validates the attribute certificate using the 365 public key in the source domain's authentication certificate, then 366 validates the authentication certificate. 368 Revocation: No direct revocation, only expiration of the attribute 369 cert or revocation of the authentication cert. 371 Evaluation: This mechanism is fairly straightforward to implement 372 with current commercially-available domain certificates, since 373 attribute certs are issued by end-entity certificates from a PKI. 374 With current libraries, however, support for attribute certificates 375 is limited relative to public-key certificates and DNSSEC signatures 376 (the other two cryptographic techniques used in this document); both 377 the source domain and the client would need to be able to process 378 attribute certificates. 380 Using attribute certificates also imposes some limits on the re-use 381 of certificates. Becase the service being delegated is encoded in 382 the certificate, each service delegated requires a different 383 certificate. In addition, while this approach is well-suited for SRV 384 records, it is not clear how it would work for other types of 385 delegation. 387 5.2. DNSSEC External Trust Anchor 389 Format: The original domain's authentication certificate and an RRSIG 390 record over the delegation record or an RR set containing it, using 391 the private key corresponding to the public key in the authentication 392 certificate. The delegation is encoded in the delegation record, and 393 the signature over the delegation is the RRSIG record. 395 Validation: The client validates that the RRSIG has a valid DNSSEC 396 signature over the delegation record or RR set using the public key 397 in the source domain's authentication certificate, then validates the 398 authentication certificate. 400 Revocation: Removal of the RRSIG record (or removal of the delegation 401 record from the RR set), or revocation of the authentication 402 certificate. 404 Evaluation: As with the DNS-based discovery approach described above, 405 the use of external trust anchors has the benefit of generality. 406 Because the delegation is not re-encoded in any way (e.g., by being 407 transcribed into a certificate), the signature can be applied to any 408 type of record, and no semantics are added or lost. The same key and 409 certificate can be used for several different RRSIGs or delegations. 410 Issusing authenticators of this type only requires the source domain 411 to have an end-entity certificate, not a CA certificate. 413 The major challenge for this approach is figuring out how it 414 integrates with operational practices, in particular with regard to 415 certificate management and DNS operations. Using certificates as 416 DNSSEC external trust anchors requires that the key pair used to 417 construct the RRSIG also be included in the source domain's public 418 key certificat. This should not be a problem, since the subject of a 419 certificate can choose the key that is included. Note that this 420 requirement doesn't necessarily mean that the key pair needs to be 421 used for anything other than DNSSEC; the source domain could obtain 422 separate certificates for other purposes (e.g., HTTPS). 424 The other operational concern arises with regard to the requirement 425 that the client be able to validate an RRSIG record, effectively 426 managing the set of DNSSEC trust anchors. In particular, because of 427 this need for local trust anchor management, the client cannot make 428 use of any DNSSEC support in the DNS infrastructure, e.g., validating 429 resolvers. As long as the client can retrieve the proper RRSIG 430 record, however, the process should work. (That request can of 431 course be routed through the normal DNS system, resolvers and all.) 433 5.3. PKIX Certificate with SRVName 435 Format of the authenticator: X.509 certificate containing an SRVName 436 Subject Alternative Name [8][9], issued by the source domain. The 437 delegation is encoded in the issuer and SRVName in the certificate. 438 The source domain is encoded in both the issuer's name and in the 439 SRVName (which thus must both have the same name), and the target 440 domain is encoded in the subject's name. The SRVName also contains 441 an indication of the service being delegated. 443 Validation: The client verifies that the service and names in the 444 certificate matche the service and names in the delegation, then 445 validates the certificate following the normal X.509 validation 446 algortihm. 448 Revocation: Normal X.509 revocation. 450 Evaluation: Using SRVName as a mechanism for authenticating 451 delegations leads to several deployment challenges. Because the 452 certificate needs to be issued by the source domain, the source 453 domain will need to have a CA certificate; CA certificates are 454 commonly much more costly than end-entity certificates. Certificates 455 can be re-used, with a different SRVName for each service being 456 delegated, but they clearly cannot be used for any delegation method 457 that uses a record type other than SRV. 459 6. Acknowledgements 461 We would like to thank Joe Hildebrand and Sean Turner for first 462 articulating the problem of authenticating delegated services, in the 463 context of XMPP, and Peter Saint-Andre for helping generalize that 464 discussion. 466 7. Security Considerations 468 This document defines a mechanism for authenticating DNS-based 469 delegations in support of authentication based on domain names. This 470 functionality can be provided using DNSSEC, but that requires that 471 all the parents of the delegated domain support DNSSEC as well as the 472 delegating domain itself. The mechanisms discussed in this document 473 provide a transitional step that allows the authenticity of DNS 474 records to be rooted in an alternative hierarchy, namely a hierarchy 475 of X.509 certificates. Since this mechanism is intended to be 476 transitional, it includes a specific provision that prevents its use 477 when DNSSEC is available. 479 8. IANA Considerations 481 This document currently makes no request of IANA. If DNS_based 482 discovery is used, then this document will register the label "_dna" 483 to be used for discovering certificates. 485 9. References 487 9.1. Normative References 489 [1] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 490 specifying the location of services (DNS SRV)", RFC 2782, 491 February 2000. 493 [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 494 One: The Comprehensive DDDS", RFC 3401, October 2002. 496 [3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 497 Protocol Version 1.2", RFC 5246, August 2008. 499 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 500 "DNS Security Introduction and Requirements", RFC 4033, 501 March 2005. 503 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 504 Levels", BCP 14, RFC 2119, March 1997. 506 [6] Josefsson, S., "Storing Certificates in the Domain Name System 507 (DNS)", RFC 4398, March 2006. 509 [7] Melnikov, A. and K. Zeilenga, "Simple Authentication and 510 Security Layer (SASL)", RFC 4422, June 2006. 512 [8] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, 513 R., and W. Polk, "Internet X.509 Public Key Infrastructure 514 Certificate and Certificate Revocation List (CRL) Profile", 515 RFC 5280, May 2008. 517 [9] Santesson, S., "Internet X.509 Public Key Infrastructure 518 Subject Alternative Name for Expression of Service Name", 519 RFC 4985, August 2007. 521 [10] Lindberg, J. and S. Farrell, "Domain Name Assertions", 522 draft-ietf-xmpp-dna-00 (work in progress), January 2010. 524 9.2. Informative References 526 [11] Partridge, C., "Mail routing and the domain system", RFC 974, 527 January 1986. 529 [12] Saint-Andre, P., Ed., "Extensible Messaging and Presence 530 Protocol (XMPP): Core", RFC 3920, October 2004. 532 [13] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 533 (SIP): Locating SIP Servers", RFC 3263, June 2002. 535 [14] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, 536 "LoST: A Location-to-Service Translation Protocol", RFC 5222, 537 August 2008. 539 [15] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP 540 Enabled Location Delivery (HELD)", 541 draft-ietf-geopriv-http-location-delivery-16 (work in 542 progress), August 2009. 544 Author's Address 546 Richard Barnes 547 BBN Technologies 548 9861 Broken Land Pkwy, Suite 400 549 Columbia, MD 21046 550 USA 552 Phone: +1 410 290 6169 553 Email: rbarnes@bbn.com