idnits 2.17.1 draft-hildebrand-dna-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 158: '...hosting provider MUST be able to servi...' RFC 2119 keyword, line 160: '...except for initial handshakes) MUST be...' RFC 2119 keyword, line 162: '...ections between hosting providers MUST...' RFC 2119 keyword, line 165: '... 4. Connections MUST be usable in eit...' RFC 2119 keyword, line 167: '...he hosted domain MUST NOT be required ...' (84 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2009) is 5302 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hildebrand 3 Internet-Draft Cisco 4 Intended status: Standards Track S. Turner 5 Expires: April 22, 2010 IECA, Inc. 6 October 19, 2009 8 Domain Name Assertions 9 draft-hildebrand-dna-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 22, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 An application-level approach to asserting and proving the delegated 48 ownership of a domain name for XMPP. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Generic Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Assertions . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.3. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.4. Requesting proof with a challenge . . . . . . . . . . . . 6 60 4.5. No proof possible . . . . . . . . . . . . . . . . . . . . 6 61 4.6. Proving a challenge . . . . . . . . . . . . . . . . . . . 7 62 5. Attribute Certificate Proof . . . . . . . . . . . . . . . . . 7 63 5.1. Attribute Certificate Issuer Profile . . . . . . . . . . . 7 64 5.2. Attribute Certificate Profile . . . . . . . . . . . . . . 8 65 5.3. Access Identity Values . . . . . . . . . . . . . . . . . . 8 66 5.3.1. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.4. Attribute Certificate Signature Algorithms . . . . . . . . 9 68 5.5. Proof Encoding . . . . . . . . . . . . . . . . . . . . . . 9 69 6. DNA for XMPP Federation . . . . . . . . . . . . . . . . . . . 9 70 6.1. DNS SRV lookups . . . . . . . . . . . . . . . . . . . . . 10 71 6.2. Certificates during Start-TLS . . . . . . . . . . . . . . 10 72 6.3. Discovering Support . . . . . . . . . . . . . . . . . . . 11 73 6.4. Turning on DNA . . . . . . . . . . . . . . . . . . . . . . 11 74 6.5. Asserting new domains . . . . . . . . . . . . . . . . . . 12 75 6.6. Proactive challenges . . . . . . . . . . . . . . . . . . . 12 76 6.7. Proactive validation . . . . . . . . . . . . . . . . . . . 12 77 6.8. Reusing streams . . . . . . . . . . . . . . . . . . . . . 13 78 6.9. Implementation notes . . . . . . . . . . . . . . . . . . . 13 79 7. DNA for XMPP client connections . . . . . . . . . . . . . . . 13 80 7.1. Announcing Support . . . . . . . . . . . . . . . . . . . . 14 81 7.2. Client challenges for proof . . . . . . . . . . . . . . . 14 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 8.1. XML Namespace Name for DNA . . . . . . . . . . . . . . . . 14 84 8.2. URN space for standard DNA Proof Types . . . . . . . . . . 14 85 8.3. DNA Proof Registry . . . . . . . . . . . . . . . . . . . . 15 86 8.4. Object Identifiers . . . . . . . . . . . . . . . . . . . . 15 87 9. Internationalization Considerations . . . . . . . . . . . . . 15 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 11. Normative References . . . . . . . . . . . . . . . . . . . . . 15 90 Appendix A. RELAX NG XML Schema . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 As large hosting providers begin providing XMPP services for multiple 96 domains, several issues with previous mechanisms for server-to-server 97 federation have become apparent. 99 A large number of sockets are currently required between hosting 100 providers. Although servers may attempt to piggyback whenever 101 possible, the possibility exists that 2*N*M sockets will be created 102 (where N is the number of domains on one hosting provider, and M is 103 the number of domains on another hosting provider). The goal would 104 be that the number of sockets was dependent on load or deployment 105 considerations. 107 In order to enable or require encryption, the hosting provider must 108 create a separate socket for each hostname pair and have access to a 109 X.509 certificate that is signed by a widely-trusted CA and includes 110 both the public and private keys. Customers of hosting providers 111 might be uncomfortable with the level of trust this requires. 113 This document lays out an approach known as Domain Name Assertions 114 (DNA) that allows providers to effectively host XMPP services on 115 behalf of other companies, and might be expanded later to support 116 other protocols. 118 2. Glossary 120 Hosted domain An XMPP domain whose network services are delegated to 121 a third party. 122 Hosting provider A business entity that provides services for one or 123 more domains that it does not directly and fully control. 124 Self-hosted domain A domain whose owner acts as its hosting 125 provider. 126 Delegation A ceremony that acts as proof of the intent of the owner 127 of a hosted domain to cede control to a hosting provider for a 128 given protocol. 129 Widely-trusted CA For open communities, a Certificate Authority 130 whose certificate that is trusted by multiple web browsers by 131 default. For closed communities, a Certificate Authority that is 132 trusted by all members of that community. 133 Sender Domain The domain associated with the 'from' address on a 134 stanza to be sent across a federation boundary. 135 Target Domain The domain associated with the 'to' address on a 136 stanza to be sent across a federation boundary. 138 Originating Server The machine that wants to send a message from an 139 entity at the Sender Domain to an entity at the Target Domain and 140 thus is attempting to establish a connection between the two 141 servers. 142 Receiving Server The machine to which the Originating Server has 143 opened a connection for the purpose of sending a message from the 144 Sender Domain to the Target Domain. 145 Asserting Entity A system element (such as a server) asserting a 146 given domain name as an identity. 147 Validating Entity A system element (such as a client or server) that 148 checks a given identity asserted by an asserting entity. 149 Asserted Domain A domain name asserted by either side of a 150 conversation. validating entities may require assertions to be 151 backed up with proof. 152 Proof A secure mechanism through which a validating entity can 153 ascertain that an asserting entity has authority for the asserted 154 domain, either directly or indirectly (by delegation). 156 3. Requirements 158 1. A hosting provider MUST be able to service domains for which it 159 cannot obtain certificates signed by a widely-trusted CA. 160 2. All network traffic (except for initial handshakes) MUST be 161 encrypted in a manner not subject to man-in-the-middle attacks. 162 3. The number of socket connections between hosting providers MUST 163 NOT be a function of the number of domains hosted by either 164 provider. 165 4. Connections MUST be usable in either direction, if allowed by 166 policy and deployment considerations. 167 5. The owners of the hosted domain MUST NOT be required to give out 168 private keying material associated with any certificate they own 169 that has been signed by a widely-trusted CA. 170 6. The owners of the hosted domain MUST be allowed to choose the 171 frequency with which they wish to perform the delegation 172 ceremony. 173 7. The owners of the hosted domain MUST be allowed to revoke their 174 delegation at any time. 175 8. Multiple mechanisms for proving delegation MUST be possible. 176 9. It MUST be possible for new assertions to be added to a stream at 177 any point after the stream is fully established, but before the 178 stream is closed 180 4. Generic Use Cases 182 The DNA mechanism can be used for multiple different protocols. In 183 particular, client-to-server XMPP and server-to-server XMPP are 184 discussed herein, but the general approach could be used for non-XMPP 185 protocols such as SMTP or IMAP. As such, the protocol syntax offered 186 here is normative for XMPP, but merely illustrative for other 187 protocols, which will need their own protocol bindings. 189 The following domain names are used in the examples in this section: 190 asserted.tld The domain name being asserted. 192 4.1. Assertions 194 The asserting entity asserts a domain name through the use of an 195 "assert" element. Assertions MUST contain a "from" attribute naming 196 the domain name that is being asserted. 197 199 4.2. Validation 201 When the validating entity has been satisified that the asserting 202 entity is authoritative for the domain name asserted, it MUST send a 203 "valid" element. At this point, the asserting entity MAY send 204 stanzas to the validating entity containing from addresses in the 205 asserted and validated domain. 207 Validating entities SHOULD respond to a domain name assertion without 208 asking for further proof when the domain name asserted is represented 209 in the certificate offered by the asserting entity according to the 210 rules set out in [rfc3920bis]. 212 Validating entities MAY respond to a domain name assertion without 213 asking for further proof when the domain name asserted is known to be 214 associated with the asserting entity through some other secure means 215 such as DNSSEC, caching, or local knowledge. In the DNSSEC case, the 216 server hostname in the SRV record used to connect SHOULD be looked 217 for in the certificate offered by the asserting entity, according to 218 the rules set out in [rfc3920bis]. 219 221 4.3. Invalidation 223 When the validating entity does not accept proof offered by the 224 asserting entity, or it no longer trusts the proof (for example due 225 to the proof timing out or being revoked), it sends the asserting 226 entity an "invalid" element. The asserting entity MUST NOT send any 227 stanzas to the validating entity containing from addresses in the 228 invalidated domain without performing another validation. 230 Invalid responses MAY be given in direct response to an assertion if 231 the validating entity has reason to believe that no proof is 232 possible. Examples that would cause this response include a blocking 233 list or a negative cache. 234 236 4.4. Requesting proof with a challenge 238 If an assertion cannot be validated immediately, the validating 239 entity may ask for further proof. Inside the "challenge" element, at 240 least one form of proof that will be acceptable MUST be given to the 241 asserting entity. If an acceptable proof format is not available for 242 the asserted domain, the validating entity MUST return an invalid 243 response proactively. 245 A "proof" element designates a type of proof that would be acceptable 246 to the verifying entity. The "type" attribute of the "proof" element 247 MUST be a valid URI. A registry of proof types will be created with 248 the IANA (see Section 8). Standard proof types will begin with 249 "urn:ietf:params:dna:proof:". Custom proofs should be signaled with 250 a "type" attribute value containing a full URI under the control of 251 the defining party. Proof types MUST be compared for equality using 252 the rules for comparing URIs. 254 Some proof types MAY require information or nonces from the 255 validating entity. If so, the specification for that proof type MUST 256 specify extensions to the "proof" element in a new namespace. 258 In some protocols, a challenge MAY be sent without an assertion, if 259 the validating entity has reason to believe that the entity with 260 which it is talking is authoritative for a given domain. 261 262 263 < type='http://example.com/proof/custom'/> 264 266 4.5. No proof possible 268 If the validating entity requires proof, but will not accept proof by 269 a means that the asserting entity has available for the asserted 270 domain, the asserting entity MUST respond with an "impossible" 271 element. The validating entity MUST NOT send a "valid" or "invalid" 272 element in response, and MUST NOT accept stanzas from the asserted 273 domain on this connection unless some other assertion works in the 274 future. 276 The "impossible" element MAY be sent after full validation, if the 277 asserting entity would like to retract the assertion. 278 280 4.6. Proving a challenge 282 If an asserting entity thinks it can prove a given assertion when 283 challenged, it sends that proof in a "proof" element. The REQUIRED 284 "type" attribute specifies the chosen proof type, and the REQUIRED 285 "from" attribute specifies the domain being proved. Each proof type 286 MUST specify the format of the contents of the "proof" element. 287 Suggestions for formats include Base64-encoded binary as character 288 data or structured XML in a new namespace. 289 292 (Base64-encoded attribute certificate) 293 295 5. Attribute Certificate Proof 297 When an asserting entity has been delegated responsibility for 298 hosting a given domain, an Attribute Certificate MUST be used to 299 prove the delegation. The proof type URI associated with attribute 300 certificates SHALL be 'urn:ietf:params:dna:proof:attribute-cert' 301 (EDITOR'S NOTE: We will work with IANA to come up with a good URN. 302 This is just a placeholder.) 304 The certificate that signed the attribute certificate MUST have been 305 acceptable as proof of ownership of a given domain for the protocol 306 in question, according to the rules in [rfc3920bis]. Validating 307 entities SHOULD try prepending the asserted domain with "www." and 308 re-checking for name matches before rejecting the signing 309 certificate, in order to allow for easier deployments using existing 310 web certificates as proof. 312 Each protocol that is delegated will be assigned its own OID to 313 identify a service and whether the entity can act as a server or 314 client. These values will be included in the Access Identifier 315 attribute, from [I-D.ietf-pkix-3281update]. This document defines 316 the OIDs for XMPP. Other documents may specify additional OIDs. 318 The remaining paragraphs in this section profile the attribute 319 certificate issuers public key certificate and the attribute 320 certificate. 322 5.1. Attribute Certificate Issuer Profile 324 The following is a profile of the attribute certificate issuer's 325 public key certificate, which is as per [I-D.ietf-pkix-3281update]: 327 o The issuer's certificate MUST conform to [RFC5280]. 328 o The issuer's certificate MUST have a keyUsage extension with the 329 digitalSignature bit set. 330 o The issuer's certificate MUST NOT have a basicConstraints 331 extension with the cA BOOLEAN set to TRUE. 333 In addition to the [I-D.ietf-pkix-3281update] requirements, the 334 subject name MUST be non-NULL in the attribute certificate issuer's 335 public key certificate. 337 5.2. Attribute Certificate Profile 339 The attribute certificate issued MUST conform to 340 [I-D.ietf-pkix-3281update]. There are options in that profile and 341 the following profiles those options: 342 o The holder field MUST be the baseCertificateID. 343 o The attributes field MUST include the Access Identity attribute, 344 as specified in Section 4.4.2 of [I-D.ietf-pkix-3281update]. Both 345 the service and ident fields' GeneralName choice MUST be 346 registeredID. The service and ident fields MUST be as defined in 347 Section 5.3. Other attributes MAY be included. 348 o The extensions field MUST include the non-critical noRevAvail 349 extension, as defined in Section 4.3.6 of 350 [I-D.ietf-pkix-3281update], to indicate that no revocation 351 information is available from the attribute certificate issuer. 352 o The extensions field MAY include: 353 * The authorityKeyIdentifier extension if the issuer has more 354 than one key pair. 355 * The issuerAltName extension if the issuer's certificate 356 includes the subjectAltName extension. If included 357 issuerAltName MUST be marked non-critical. 359 5.3. Access Identity Values 361 The following paragraphs define the service and ident values for the 362 delegated protocols. Currently, only values for XMPP are defined. A 363 later version of this document or another document may specify 364 additional values for other protocols. 366 5.3.1. XMPP 368 When XMPP is delegated the following procedures MUST be followed. 370 The service field MUST be id-xmpp. The following object identifier 371 identifies that the AC holder supports XMPP: 372 id-xmpp OBJECT IDENTIFIER ::= { TBD } 374 The ident field MUST be either id-xmpp-client or id-xmpp-server. 376 Both id-xmpp-client and id-xmpp-server MAY appear in the same 377 attribute certificate. Note that the Access Identity attribute will 378 be multi-valued when both id-xmpp-client and id-xmpp-server are 379 present. 381 The following object identifier identifies the AC holder as the XMPP 382 client: 383 id-xmpp-client OBJECT IDENTIFIER ::= { id-xmpp 0 } 385 The following object identifier identifies the AC holder as the XMPP 386 server: 387 id-xmpp-server OBJECT IDENTIFIER ::= { id-xmpp 1 } 389 5.4. Attribute Certificate Signature Algorithms 391 The issuer MUST support signing attribute certificate with the PKCS 392 #1 version 1.5 signature algorithm with SHA-256, as specified in 393 [RFC4055]. 395 5.5. Proof Encoding 397 The attribute certificate, the issuer's certificate, and all of the 398 CA certificates in the trust chain of the signing certificate back to 399 the trust anchor are encoded as a "certs-only" SMIME message, as per 400 [I-D.ietf-smime-3851bis] (i.e, a degenerate SignedData with no 401 content just certificates). The resulting message is then Base64 402 encoded, as per Section 6.8 of [RFC2045]. The end result is then 403 transmitted as the character data of a "proof" element. 405 6. DNA for XMPP Federation 407 Two XMPP servers, each of which hosts multiple domains that they do 408 not directly control, desire to connect in order to exchange traffic 409 for at least two of those domains (one on either side). 411 The following domain names are used in the examples: 412 target.tld The domain portion of the JID in the to address of the 413 stanza that caused this connection to be initiated. 414 othertarget.tld The domain portion of the JID in the to address of a 415 stanza being sent across a stream that was originally started to 416 talk to target.tld. 417 targetprovider.tld The hosting provider for target.tld. 418 server.targetprovider.tld A server with XMPP federation services at 419 the target's hosting provider. 421 originator.tld The domain portion of the JID in the from address of 422 the stanza that caused this connection to be initiated. 423 originatingprovider.tld The hosting provider for target.tld. 424 server.originatingprovider.tld A server with XMPP federation 425 services at the originator's hosting provider. 427 6.1. DNS SRV lookups 429 In a delegated hosting scenario, DNS SRV records are REQUIRED, since 430 otherwise the hosting provider will never be contacted for the target 431 domain. As specified by [rfc3920bis] the originating server looks up 432 the target domain to find a list of receiving servers. If the 433 originating server already has a connection to the IP address 434 represented by one of these servers (perhaps because it is 435 communicating with another domain hosted by this provider), it MAY 436 reuse that stream (see Stream Reuse). If the originating server does 437 not have a connection it wants to reuse, it performs the SRV 438 algorithm to select an SRV record and makes a TCP connection to the 439 server and port specified by the selected SRV record. 441 Unless assured by a mechanism such as DNSSEC, the originating server 442 MUST NOT trust the information received from the DNS SRV as proof 443 that the target domain has been delegated to the receiving server. 444 % dig +short -t SRV _xmpp-server._tcp.target.tld 445 0 1 5269 server.targetprovider.tld 447 6.2. Certificates during Start-TLS 449 The first step during stream negotiation MUST be Start-TLS. The 450 receiving server MUST offer a certificate signed by a widely-trusted 451 CA. The receiving server MUST require a client certificate. The 452 certificate offered by the originating server MUST be signed be a 453 widely-trusted CA. Both sides MUST check the certificate offered to 454 it for validity (e.g. time period, signatures, and trust anchor), but 455 MUST NOT disconnect when the certificate received does not contain a 456 name matching its expectations. 458 The names on these certificates SHOULD be associated with the 459 relevant hosting provider, and need not be related to the domains 460 being hosted. If the certificates have the name of the server 461 offered in the SRV record, it MAY be possible to use DNSSEC for proof 462 in the future. 463 CN=server.targetprovider.tld 464 CN=server.originatingprovider.tld 466 6.3. Discovering Support 468 To and from addresses are REQUIRED in the stream:stream tag. These 469 represent the first domain pair associated with this stream, and are 470 the domain names from the stanza that caused this connection to be 471 established. 473 To announce its support for DNA, the receiving server asserts its 474 identity in the stream features following TLS negotiation. 475 476 477 479 6.4. Turning on DNA 481 If the originating server supports DNA, it looks for an assertion in 482 the stream features. If it finds none, it MAY fall back on another 483 means of verifying the identiy of the target server, if allowed by 484 local policy. 486 Originating servers that support DNA talking to target servers that 487 declare support for DNA MUST NOT send protocol other than DNA 488 negotations until they are able to validate the assertion offered by 489 the target server in the stream features. The first validation 490 proves to the originating server that it is talking to a server 491 authoritative for the target domain, so that it is safe to use this 492 domain in "to" addresses on this stream. 494 Once an originating server completes this first validation it signals 495 that it is willing and able to participate in bi-directional XMPP 496 federation traffic, as long as all of the domains required have been 497 asserted and validated at least once on this stream. 499 If the originating server does not require more proof (due to a 500 certificate match or DNSSEC-verified delegation), it may send a 501 "valid" element without requesting proof first, as in all DNA 502 interactions. 503 504 505 507 510 (Base64-encoded attribute certificate) 511 512 514 6.5. Asserting new domains 516 Before either side sends stanzas on a given stream, it MUST ensure 517 that the other side will accept those stanzas by asserting the domain 518 in the "from" attribute of those stanzas, and waiting for a "valid" 519 response before sending the stanzas in question. 521 The originating server MUST therefore send its own assertion after 522 accepting the target domain's assertion. 523 525 6.6. Proactive challenges 527 Before either side sends stanzas on a given stream, it MUST ensure 528 that the other side is authoriative for the domain in the "to" 529 attribute on those stanzas. If the sender has already accepted an 530 assertion on this stream, and that assertion has not been revoked 531 with an "impossible" element, no action is required. Otherwise, the 532 sender can proactively request proof for that domain by sending a 533 challenge even though the other side has not sent an assertion for 534 that domain yet. 535 536 537 539 6.7. Proactive validation 541 When two hosting providers connect, they may have previous knowledge 542 (perhaps from a cache) of which domains they will trust on the new 543 connection. If so, either side MAY send as many "valid" elements as 544 desired, even though the other side has not sent assertions for those 545 domain. 547 The server receiving these proactive validations MUST NOT change its 548 self-image (which domains it thinks it is authoritative for), but 549 SHOULD NOT send assertions for these domains on this stream. If the 550 server receiving a proactive validation is no long authoritative for 551 a given domain, it MUST send an "impossible" element, at which point 552 the sender MUST remove the receiver from any cache and not send any 553 stanzas on this stream to the given domain. 555 Any cache of DNA information SHOULD be associated with the 556 certificate offerred by the relevant server, and SHOULD be checked 557 for revocation if possible, according to local policy. 558 559 560 562 6.8. Reusing streams 564 DNA streams are bi-directional, and may have an aribtrary number of 565 domains validated in either direction, at any point in the lifetime 566 of the stream. Before sending a stanza on a given stream, the sender 567 MUST ensure that "valid" elements have been exchanged according to 568 the above rules for both the "to" and "from" address, and that no 569 "invalid" or "impossible" element has revoked an assertion. 571 An "impossible" or "invalid" element SHOULD NOT cause the rest of the 572 stream to become invalidated in either directions. When these 573 elements are seen, they SHOULD merely change the list of domains that 574 are valid on that stream. If no domains are valid on the stream, the 575 stream MAY be closed immediately, or MAY be left open if desired. If 576 left open, the stream MUST NOT be used for stanza traffic until 577 domains are asserted as needed for the desired domains. 579 Domains that are marked as "invalid" or "impossible" SHOULD NOT be 580 retried on the same stream unless new information has become 581 available, in order to prevent assertion storms. 583 6.9. Implementation notes 585 If the first server-to-server validation exchange fails, the parties 586 MAY keep the connection open (perhaps for a shorter than is usual) in 587 case another domain pair would need a connection between these 588 servers. 590 Ensure that only one challenge is outstanding on a given connection 591 for a given domain. Ensure that only one assertion or one proof is 592 outstanding on a given connection for a given domain. 594 7. DNA for XMPP client connections 596 Hosting providers have a similar problem for client to server 597 connections. Clients need to ensure that they are talking to an 598 authoritative server for the domain they intend to log in to. 599 Typically, this is done by examining the certificate offered by the 600 server during TLS negotiation, according to the rules in 601 [rfc3920bis]. However, hosting providers will typically not have 602 access to a valid certificate for the target domain and its 603 associated private key. DNA can be used for the hosting provider to 604 prove that hosting services have been delegated to it. 606 7.1. Announcing Support 608 To announce its support for DNA, the server asserts its identity in 609 the stream features following TLS negotiation. The server MUST offer 610 the identity of the domain specified in the client's stream header 611 "to" attribute. 612 613 614 616 7.2. Client challenges for proof 618 To utilize the server's DNA assertion, the client performs Start-TLS 619 per [rfc3920bis], however, if the client does not find a name match 620 on the offered certificate, it does not disconnect immediately. 621 Instead, if the server offers an assertion, it can use the name from 622 that assertion to ask the server for proof of delegation. 624 Subsequent protocol follows the generic use cases above, with the 625 exception that alternate or additional domain names MUST NOT be 626 asserted. If the server returns an "impossible" element, the server 627 MUST terminate the stream. If the client sends an "invalid" element, 628 the client MUST terminate the stream. 629 630 631 633 8. IANA Considerations 635 8.1. XML Namespace Name for DNA 637 A URN sub-namespace for Domain Name Assertion (DNA) negotiation data 638 in the Extensible Messaging and Presence Protocol (XMPP) is defined 639 as follows. (This namespace name adheres to the format defined in .) 641 URI: urn:ietf:params:xml:ns:dna 642 Specification: XXXX 643 Description: This is the XML namespace name for Domain Name 644 Assertion (DNA) negotiation data in the Extensible Messaging and 645 Presence Protocol (XMPP) as defined by XXXX. 646 Registrant Contact: IETF, XMPP Working Group, 648 8.2. URN space for standard DNA Proof Types 650 A URN sub-namespace for DNA is defined as follows. (This namespace 651 name adheres to the format defined in .) 652 URI: urn:ietf:params:dna:proof 653 Specification: XXXX 654 Description: This is the sub-namespace for standardized Domain Name 655 Assertion (DNA) proof types as defined by XXXX. 656 Registrant Contact: IETF, XMPP Working Group, 658 8.3. DNA Proof Registry 660 The URNs inside urn:ietf:params:dna:proof 662 8.4. Object Identifiers 664 The following OIDs are defined in Section 5.3 of this document: 665 o id-xmpp 666 o id-xmpp-client 667 o id-xmpp-server 669 9. Internationalization Considerations 671 The domains offered MUST conform to all of the rules for "Domain 672 Identitifiers", as specified in &rfc3920bis;, including (but not 673 limited to) the rules for syntax, cannonicalization and comparison. 675 10. Security Considerations 677 TBD. 679 11. Normative References 681 [rfc3920bis] 682 Saint-Andre, P., "Extensible Messaging and Presence 683 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-02 (work 684 in progress), September 2009. 686 [I-D.ietf-pkix-3281update] 687 Housley, R., Farrell, S., and S. Turner, "An Internet 688 Attribute Certificate Profile for Authorization", 689 draft-ietf-pkix-3281update-05 (work in progress), 690 April 2009. 692 [I-D.ietf-smime-3851bis] 693 Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 694 Mail Extensions (S/MIME) Version 3.2 Message 695 Specification", draft-ietf-smime-3851bis-11 (work in 696 progress), May 2009. 698 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 699 Extensions (MIME) Part One: Format of Internet Message 700 Bodies", RFC 2045, November 1996. 702 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 703 Algorithms and Identifiers for RSA Cryptography for use in 704 the Internet X.509 Public Key Infrastructure Certificate 705 and Certificate Revocation List (CRL) Profile", RFC 4055, 706 June 2005. 708 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 709 Housley, R., and W. Polk, "Internet X.509 Public Key 710 Infrastructure Certificate and Certificate Revocation List 711 (CRL) Profile", RFC 5280, May 2008. 713 Appendix A. RELAX NG XML Schema 715 default namespace = "urn:ietf:params:xml:ns:dna" 717 # Intent: Internationalized Domain Name (simplisitic view) 718 domain = xsd:string { pattern = "(\p{L}|\p{N})(\p{L}|\p{N}|\p{M}|-)*" 719 "(\.(\p{L}|\p{N})(\p{L}|\p{N}|\p{M}|-)*)*"} 721 assert = element assert { 722 attribute from { domain } 723 } 725 valid = element valid { 726 attribute to { domain } 727 } 729 invalid = element valid { 730 attribute to { domain } 731 } 733 proof = element proof { 734 attribute type { xsd:anyURI }, 735 attribute from { domain }?, 736 text? 737 } 739 challenge = element challenge { 740 proof+ 741 } 743 start = assert | valid | invalid | proof | challenge 745 Authors' Addresses 747 Joe Hildebrand 748 Cisco 750 Email: jhildebr@cisco.com 752 Sean Turner 753 IECA, Inc. 755 Email: turners@ieca.com