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