idnits 2.17.1 draft-ietf-xmpp-dna-06.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2014) is 3591 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) == Outdated reference: A later version (-14) exists of draft-ietf-dane-srv-06 == Outdated reference: A later version (-06) exists of draft-ietf-xmpp-posh-01 ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0220' -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft &yet 4 Intended status: Standards Track M. Miller 5 Expires: December 23, 2014 Cisco Systems, Inc. 6 June 21, 2014 8 Domain Name Associations (DNA) in the Extensible Messaging and Presence 9 Protocol (XMPP) 10 draft-ietf-xmpp-dna-06 12 Abstract 14 This document improves the security of the Extensible Messaging and 15 Presence Protocol (XMPP) in two ways. First, it specifies how 16 "prooftypes" can establish a strong association between a domain name 17 and an XML stream. Second, it describes how to securely delegate a 18 source domain to a derived domain, which is especially important in 19 multi-tenanted environments. 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 December 23, 2014. 38 Copyright Notice 40 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Client-to-Server (C2S) DNA . . . . . . . . . . . . . . . . . 3 58 3.1. C2S Flow . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. C2S Description . . . . . . . . . . . . . . . . . . . . . 4 60 4. Server-to-Server (S2S) DNA . . . . . . . . . . . . . . . . . 5 61 4.1. S2S Flow Chart . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. A Simple S2S Scenario . . . . . . . . . . . . . . . . . . 7 63 4.3. One-Way Authentication . . . . . . . . . . . . . . . . . 8 64 4.4. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 9 65 4.4.1. Assertion . . . . . . . . . . . . . . . . . . . . . . 9 66 4.4.2. Supposition . . . . . . . . . . . . . . . . . . . . . 10 67 5. Alternative Prooftypes . . . . . . . . . . . . . . . . . . . 12 68 5.1. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 5.2. POSH . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 6. Secure Delegation and Multi-Tenancy . . . . . . . . . . . . . 13 71 7. Prooftype Model . . . . . . . . . . . . . . . . . . . . . . . 14 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 8.1. Well-Known URI for xmpp-client Service . . . . . . . . . 14 74 8.2. Well-Known URI for xmpp-server Service . . . . . . . . . 14 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 10.2. Informative References . . . . . . . . . . . . . . . . . 16 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 The need to establish a strong association between a domain name and 85 an XML stream arises in both client-to-server and server-to-server 86 communication using the Extensible Messaging and Presence Protocol 87 (XMPP) [RFC6120]. Because XMPP servers are typically identified by 88 DNS domain names, a client or peer server needs to verify the 89 identity of a server to which it connects. 91 To date, such verification has been established based on information 92 obtained from the Domain Name System (DNS), the Public Key 93 Infrastructure (PKI), or similar sources. In relation to such 94 associations, this document does the following: 96 1. Generalizes the model currently in use so that additional 97 prooftypes can be defined 99 2. Provides a basis for modernizing some prooftypes to reflect 100 progress in underlying technologies such as DNS Security 101 [RFC4033] 103 3. Describes the flow of operations for establishing a domain name 104 association (DNA) 106 This document also provides guidelines for secure delegation. The 107 need for secure delegation arises because the process for resolving 108 the domain name of an XMPP service into the IP address at which an 109 XML stream will be negotiated (see [RFC6120]) can involve delegation 110 of a source domain (say, example.com) to a derived domain (say, 111 hosting.example.net) using technologies such as DNS SRV records 112 [RFC2782]. If such delegation is not done in a secure manner, then 113 the domain name association cannot be authenticated. 115 2. Terminology 117 This document inherits XMPP terminology from [RFC6120] and 118 [XEP-0220], DNS terminology from [RFC1034], [RFC1035], [RFC2782] and 119 [RFC4033], and security terminology from [RFC4949] and [RFC5280]. 120 The terms "source domain", "derived domain", "reference identity", 121 and "presented identity" are used as defined in the "CertID" 122 specification [RFC6125]. 124 3. Client-to-Server (C2S) DNA 126 The client-to-server case is much simpler than the server-to-server 127 case (the client does not assert a domain name, only the server's 128 domain name needs to be verified, etc.). Therefore we describe it 129 first to help the reader understand domain name associations in XMPP. 131 3.1. C2S Flow 133 The following flow chart illustrates the protocol flow for 134 establishing a domain name association for an XML stream from a 135 client to a server. 137 | 138 DNS RESOLUTION ETC. 139 | 140 +-----------------STREAM HEADERS---------------------+ 141 | | 142 | A: | 143 | | 144 | B: | 145 | | 146 +----------------------------------------------------+ 147 | 148 +-----------------TLS NEGOTIATION--------------------+ 149 | | 150 | B: Server Certificate | 151 | | 152 +----------------------------------------------------+ 153 | 154 (client establishes DNA for a.example) 155 | 157 3.2. C2S Description 159 The simplified order of events (see [RFC6120] for details) in 160 establishing an XML stream from a client (user@a.exmaple) to a server 161 (a.example) is as follows: 163 1. The client resolves the DNS domain name a.example. 165 2. The client opens a TCP connection to the resolved IP address. 167 3. The client sends an initial stream header to the server. 169 171 4. The server sends a response stream header to the client, 172 asserting that it is a.example: 174 176 5. The parties attempt TLS negotiation, during which the XMPP server 177 (acting as a TLS server) presents a PKIX certificate proving that 178 it is a.example. 180 6. The client checks the PKIX certificate that the server provided; 181 if the proof is consistent with the XMPP profile of the matching 182 rules from [RFC6125], the client accepts that there is a strong 183 domain name association between its stream to the server and the 184 DNS domain name of the server. 186 4. Server-to-Server (S2S) DNA 188 The server-to-server case is much more complex than the client-to- 189 server case, and involves checking of domain name associations in 190 both directions along with other "wrinkles" described in the 191 following sections. 193 4.1. S2S Flow Chart 195 The following flow chart illustrates the protocol flow for 196 establishing domain name associations between Server 1 and Server 2, 197 as described in the remaining sections of this document. 199 | 200 (Section 4.2: A Simple Scenario) 201 | 202 DNS RESOLUTION ETC. 203 | 204 +-------------STREAM HEADERS--------------------+ 205 | | 206 | A: | 207 | | 208 | B: | 209 | | 210 +-----------------------------------------------+ 211 | 212 +-------------TLS NEGOTIATION-------------------+ 213 | | 214 | B: Server Certificate | 215 | [B: Certificate Request] | 216 | [A: Client Certificate] | 217 | | 218 +-----------------------------------------------+ 219 | 220 (A establishes DNA for b.example) 221 | 222 +-------------AUTHENTICATION--------------------+ 223 | | | 224 | {client certificate?} ----+ | 225 | | | | 226 | | yes no | | 227 | v | | 228 | SASL EXTERNAL | | 229 | (mutual auth!) | | 230 +------------------------------------|----------+ 231 | 232 +----------------+ 233 | B needs to auth A 234 | 235 | 236 (Section 4.3: One-Way Authentication) 237 | 238 DNS RESOLUTION ETC. 239 | 240 +-------------STREAM HEADERS--------------------+ 241 | | 242 | B: | 243 | | 244 | A: | 245 | | 246 +-----------------------------------------------+ 247 | 248 +-------------TLS NEGOTIATION-------------------+ 249 | | 250 | A: Server Certificate | 251 | | 252 +-----------------------------------------------+ 253 | 254 (B establishes DNA for a.example) 255 | 256 | 257 (Section 4.4.1: Piggybacking Assertion) 258 | 259 +----------DIALBACK IDENTITY ASSERTION----------+ 260 | | 261 | B: | 263 | | 264 +-----------------------------------------------+ 265 | 266 +-----------DNA DANCE AS ABOVE------------------+ 267 | | 268 | DNS RESOLUTION, STREAM HEADERS, | 269 | TLS NEGOTIATION, AUTHENTICATION | 270 | | 271 +-----------------------------------------------+ 272 | 273 +----------DIALBACK IDENTITY VERIFICATION-------+ 274 | | 275 | A: | 278 | | 279 +-----------------------------------------------+ 280 | 281 | 283 (Section 4.4.2: Piggybacking Supposition) 284 | 285 +-----------SUBSEQUENT CONNECTION---------------+ 286 | | 287 | B: | 289 | | 290 | A: | 292 | | 293 +-----------------------------------------------+ 294 | 295 +-----------DNA DANCE AS ABOVE------------------+ 296 | | 297 | DNS RESOLUTION, STREAM HEADERS, | 298 | TLS NEGOTIATION, AUTHENTICATION | 299 | | 300 +-----------------------------------------------+ 301 | 302 +-----------DIALBACK OPTIMIZATION---------------+ 303 | | 304 | B: | 306 | | 307 | B: | 310 | | 311 +-----------------------------------------------+ 312 | 314 4.2. A Simple S2S Scenario 316 To illustrate the problem, consider the simplified order of events 317 (see [RFC6120] for details) in establishing an XML stream between 318 Server 1 (a.example) and Server 2 (b.example): 320 1. Server 1 resolves the DNS domain name b.example. 322 2. Server 1 opens a TCP connection to the resolved IP address. 324 3. Server 1 sends an initial stream header to Server 2, asserting 325 that it is a.example: 327 329 4. Server 2 sends a response stream header to Server 1, asserting 330 that it is b.example: 332 334 5. The servers attempt TLS negotiation, during which Server 2 335 (acting as a TLS server) presents a PKIX certificate proving that 336 it is b.example and Server 1 (acting as a TLS client) presents a 337 PKIX certificate proving that it is a.example. 339 6. Server 1 checks the PKIX certificate that Server 2 provided and 340 Server 2 checks the PKIX certificate that Server 1 provided; if 341 these proofs are consistent with the XMPP profile of the matching 342 rules from [RFC6125], each server accepts that there is a strong 343 domain name association between its stream to the other party and 344 the DNS domain name of the other party. 346 Several simplifying assumptions underlie the happy scenario just 347 outlined: 349 o Server 1 presents a PKIX certificate during TLS negotiation, which 350 enables the parties to complete mutual authentication. 352 o There are no additional domains associated with Server 1 and 353 Server 2 (say, a subdomain rooms.a.example on Server 1 or a second 354 domain c.example on Server 2). 356 o The server administrators are able to obtain PKIX certificates in 357 the first place. 359 o The server administrators are running their own XMPP servers, 360 rather than using hosting services. 362 Let's consider each of these "wrinkles" in turn. 364 4.3. One-Way Authentication 366 If Server 1 does not present its PKIX certificate during TLS 367 negotiation (perhaps because it wishes to verify the identity of 368 Server 2 before presenting its own credentials), Server 2 is unable 369 to mutually authenticate Server 1. Therefore, Server 2 needs to 370 negotiate and authenticate a stream to Server 1, just as Server 1 has 371 done: 373 1. Server 2 resolves the DNS domain name a.example. 375 2. Server 2 opens a TCP connection to the resolved IP address. 377 3. Server 2 sends an initial stream header to Server 1, asserting 378 that it is b.example: 380 382 4. Server 1 sends a response stream header to Server 2, asserting 383 that it is a.example: 385 387 5. The servers attempt TLS negotiation, during which Server 1 388 (acting as a TLS server) presents a PKIX certificate proving that 389 it is a.example. 391 6. Server 2 checks the PKIX certificate that Server 1 provided; if 392 it is consistent with the XMPP profile [RFC6120] of the matching 393 rules from [RFC6125], Server 2 accepts that there is a strong 394 domain name association between its stream to Server 1 and the 395 DNS domain name a.example. 397 At this point the servers are using two TCP connections instead of 398 one, which is somewhat wasteful. However, there are ways to tie the 399 authentication achieved on the second TCP connection to the first TCP 400 connection; see [XEP-0288] for further discussion. 402 4.4. Piggybacking 404 4.4.1. Assertion 406 Consider the common scenario in which Server 2 hosts not only 407 b.example but also a second domain c.example (a "multi-tenanted" 408 environment). If a user of Server 2 associated with c.example wishes 409 to communicate with a friend at a.example, Server 2 needs to send 410 XMPP stanzas from the domain c.example rather than b.example. 411 Although Server 2 could open an new TCP connection and negotiate new 412 XML streams for the domain pair of c.example and a.example, that too 413 is wasteful. Server 2 already has a connection to a.example, so how 414 can it assert that it would like to add a new domain pair to the 415 existing connection? 417 The traditional method for doing so is the Server Dialback protocol, 418 first specified in [RFC3920] and since moved to [XEP-0220]. Here, 419 Server 2 can send a element for the new domain pair over 420 the existing stream. 422 423 some-dialback-key 424 426 This element functions as Server 2's assertion that it is (also) 427 c.example, and thus is functionally equivalent to the 'from' address 428 of an initial stream header as previously described. 430 In response to this assertion, Server 1 needs to obtain some kind of 431 proof that Server 2 really is also c.example. It can do the same 432 thing that it did before: 434 1. Server 1 resolves the DNS domain name c.example. 436 2. Server 1 opens a TCP connection to the resolved IP address (which 437 might be the same IP address as for b.example). 439 3. Server 1 sends an initial stream header to Server 2, asserting 440 that it is a.example: 442 444 4. Server 2 sends a response stream header to Server 1, asserting 445 that it is c.example: 447 449 5. The servers attempt TLS negotiation, during which Server 2 450 (acting as a TLS server) presents a PKIX certificate proving that 451 it is c.example. 453 6. Server 1 checks the PKIX certificate that Server 2 provided; if 454 it is consistent with the XMPP profile [RFC6120] of the matching 455 rules from [RFC6125], Server 1 accepts that there is a strong 456 domain name association between its stream to Server 2 and the 457 DNS domain name c.example. 459 Now that Server 1 accepts the domain name association, it informs 460 Server 2 of that fact: 462 464 The parties can then terminate the second connection, since it was 465 used only for Server 1 to associate a stream over the same IP:port 466 combination with the domain name c.example (the dialback key links 467 the original stream to the new association). 469 4.4.2. Supposition 471 Piggybacking can also occur in the other direction. Consider the 472 common scenario in which Server 1 provides XMPP services not only for 473 a.example but also for a subdomain such as a groupchat service at 474 rooms.a.example (see [XEP-0045]). If a user from c.example at Server 475 2 wishes to join a room on the groupchat sevice, Server 2 needs to 476 send XMPP stanzas from the domain c.example to the domain 477 rooms.a.example rather than a.example. Therefore, Server 2 needs to 478 negotiate and authenticate a stream to rooms.a.example: 480 1. Server 2 resolves the DNS domain name rooms.a.example. 482 2. Server 2 opens a TCP connection to the resolved IP address. 484 3. Server 2 sends an initial stream header to Server 1 acting as 485 rooms.a.example, asserting that it is b.example: 487 489 4. Server 1 sends a response stream header to Server 2, asserting 490 that it is rooms.a.example: 492 494 5. The servers attempt TLS negotiation, during which Server 1 495 (acting as a TLS server) presents a PKIX certificate proving that 496 it is rooms.a.example. 498 6. Server 2 checks the PKIX certificate that Server 1 provided; if 499 it is consistent with the XMPP profile [RFC6120] of the matching 500 rules from [RFC6125], Server 2 accepts that there is a strong 501 domain name association between its stream to Server 1 and the 502 DNS domain name rooms.a.example. 504 As before, the parties now have two TCP connections open. So that 505 they can close the now-redundant connection, Server 2 sends a 506 dialback key to Server 1 over the new connection. 508 509 some-dialback-key 510 512 Server 1 then informs Server 2 that it accepts the domain name 513 association: 515 517 Server 2 can now close the connection over which it tested the domain 518 name association for rooms.a.example. 520 5. Alternative Prooftypes 522 The foregoing protocol flows assumed that domain name associations 523 were proved using the standard PKI prooftype specified in [RFC6120]: 524 that is, the server's proof consists of a PKIX certificate that is 525 checked according to the XMPP profile [RFC6120] of the matching rules 526 from [RFC6125], the client's verification material is obtained out of 527 band in the form of a trusted root, and secure DNS is not necessary. 529 However, sometimes XMPP server administrators are unable or unwilling 530 to obtain valid PKIX certificates for their servers. As one example, 531 a certificate authority (CA) might try to send email messages to 532 authoritative mailbox names [RFC2142], but the administrator of a 533 subsidiary service such as im.cs.podunk.example can't receive email 534 sent to mailto:hostmaster@podunk.example. As another example, a 535 hosting provider such as hosting.example.net might not want to take 536 on the liability of holding the certificate and private key for a 537 tenant such as example.com (or the tenant might not want the hosting 538 provider to hold its certificate and private key). In these 539 circumstances, prooftypes other than PKIX are desirable. As 540 described below, two alternatives have been defined so far: DNS-Based 541 Authentication of Named Entities (DANE) and and PKIX Over Secure HTTP 542 (POSH). 544 5.1. DANE 546 In the DANE prooftype, the server's proof consists of a PKIX 547 certificate that is compared as an exact match or a hash of either 548 the SubjectPublicKeyInfo or the full certificate, and the client's 549 verification material is obtained via secure DNS. 551 The DANE prooftype makes use of the DNS-Based Authentication of Named 552 Entities [RFC6698], specifically the use of DANE with DNS SRV records 553 [I-D.ietf-dane-srv]. For XMPP purposes, the following rules apply: 555 o If there is no SRV resource record, pursue the fallback methods 556 described in [RFC6120]. 558 o Use the 'to' address of the initial stream header to determine the 559 domain name of the TLS client's reference identifier (since use of 560 the TLS Server Name Indication is purely discretionary in XMPP, as 561 mentioned in [RFC6120]). 563 5.2. POSH 565 In the POSH prooftype, the server's proof consists of a PKIX 566 certificate that is checked according to the rules from [RFC6120] and 567 [RFC6125], the client's verification material is obtained by 568 retrieving the PKIK certificate over HTTPS at a well-known URI 569 [RFC5785], and secure DNS is not necessary since the HTTPS retrieval 570 mechanism relies on the chain of trust from the public key 571 infrastructure. 573 POSH is defined in [I-D.ietf-xmpp-posh]. For XMPP purposes, the 574 well-known URIs [RFC5785] to be used are: 576 o "/.well-known/posh._xmpp-client._tcp.json" for client-to-server 577 connections 579 o "/.well-known/posh._xmpp-server._tcp.json" for server-to-server 580 connections 582 6. Secure Delegation and Multi-Tenancy 584 One common method for deploying XMPP services is multi-tenancy: e.g., 585 the XMPP service for example.com is actually hosted at 586 hosting.example.net. Such an arrangement is relatively convenient in 587 XMPP given the use of DNS SRV records [RFC2782], such as the 588 following pointer from example.com to hosting.example.net: 590 _xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net 592 Secure connections with multi-tenancy can work using the PKIX 593 prooftype on a small scale if the provider itself wishes to host 594 several domains (e.g., several related domains such as jabber- 595 de.example and jabber-ch.example). However, in practice the security 596 of multi-tenancy has been found to be unwieldy when the provider 597 hosts large numbers of XMPP services on behalf of multiple tenants. 598 Typically there are two main reasons for this state of affairs: the 599 service provider (say, hosting.example.net) wishes to limit its 600 liability and therefore does not wish to hold the certificate and 601 private key for the tenant (say, example.com) and the tenant wishes 602 to improve the security of the service and therefore does not wish to 603 share its certificate and private key with service provider. As a 604 result, server-to-server communications to example.com go unencrypted 605 or the communications are TLS-encrypted but the certificates are not 606 checked (which is functionally equivalent to a connection using an 607 anonymous key exchange). This is also true of client-to-server 608 communications, forcing end users to override certificate warnings or 609 configure their clients to accept certificates for 610 hosting.example.net instead of example.com. The fundamental problem 611 here is that if DNSSEC is not used then the act of delegation via DNS 612 SRV records is inherently insecure. 614 The specification for use of SRV and MX records with DANE 615 [I-D.ietf-dane-srv] explains how to use DNSSEC for secure delegation 616 with the DANE prooftype, and the POSH specification 617 [I-D.ietf-xmpp-posh] explains how to use HTTPS redirects for secure 618 delegation with the POSH prooftype. 620 7. Prooftype Model 622 In general, a domain name association (DNA) prooftype conforms to the 623 following definition: 625 prooftype: A mechanism for proving an association between a domain 626 name and an XML stream, where the mechanism defines (1) the nature 627 of the server's proof, (2) the matching rules for comparing the 628 client's verification material against the server's proof, (3) how 629 the client obtains its verification material, and (4) whether the 630 mechanism depends on secure DNS. 632 The PKI, DANE, and POSH prooftypes adhere to this model. In 633 addition, other prooftypes are possible (examples might include PGP 634 keys rather than PKIX certificates, or a token mechanism such as 635 Kerberos or OAuth). 637 Some prooftypes depend on (or are enhanced by) secure DNS and thus 638 also need to describe how they ensure secure delegation. 640 8. IANA Considerations 642 The POSH specification [I-D.ietf-xmpp-posh] provides guidelines for 643 registering the well-known URIs [RFC5785] of protocols that make use 644 of POSH. This specification registers two such URIs, for which the 645 completed registration templates follow. 647 8.1. Well-Known URI for xmpp-client Service 649 This specification registers the well-known URI "posh._xmpp- 650 client._tcp.json" in the Well-Known URI Registry as defined by 651 [RFC5785]. 653 URI suffix: posh._xmpp-client._tcp.json 655 Change controller: IETF 657 Specification document(s): [[ this document ]] 659 8.2. Well-Known URI for xmpp-server Service 661 This specification registers the well-known URI "posh._xmpp- 662 server._tcp.json" in the Well-Known URI Registry as defined by 663 [RFC5785]. 665 URI suffix: posh._xmpp-server._tcp.json 667 Change controller: IETF 669 Specification document(s): [[ this document ]] 671 9. Security Considerations 673 This document supplements but does not supersede the security 674 considerations of [RFC6120] and [RFC6125]. Relevant security 675 considerations can also be found in [I-D.ietf-dane-srv] and 676 [I-D.ietf-xmpp-posh]. 678 10. References 680 10.1. Normative References 682 [I-D.ietf-dane-srv] 683 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 684 Based Authentication of Named Entities (DANE) TLSA records 685 with SRV and MX records.", draft-ietf-dane-srv-06 (work in 686 progress), June 2014. 688 [I-D.ietf-xmpp-posh] 689 Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP 690 (POSH)", draft-ietf-xmpp-posh-01 (work in progress), June 691 2014. 693 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 694 STD 13, RFC 1034, November 1987. 696 [RFC1035] Mockapetris, P., "Domain names - implementation and 697 specification", STD 13, RFC 1035, November 1987. 699 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 700 specifying the location of services (DNS SRV)", RFC 2782, 701 February 2000. 703 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 704 Rose, "DNS Security Introduction and Requirements", RFC 705 4033, May 2005. 707 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 708 4949, August 2007. 710 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 711 Housley, R., and W. Polk, "Internet X.509 Public Key 712 Infrastructure Certificate and Certificate Revocation List 713 (CRL) Profile", RFC 5280, May 2008. 715 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 716 Uniform Resource Identifiers (URIs)", RFC 5785, April 717 2010. 719 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 720 Protocol (XMPP): Core", RFC 6120, March 2011. 722 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 723 Verification of Domain-Based Application Service Identity 724 within Internet Public Key Infrastructure Using X.509 725 (PKIX) Certificates in the Context of Transport Layer 726 Security (TLS)", RFC 6125, March 2011. 728 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 729 of Named Entities (DANE) Transport Layer Security (TLS) 730 Protocol: TLSA", RFC 6698, August 2012. 732 [XEP-0220] 733 Miller, J., Saint-Andre, P., and P. Hancke, "Server 734 Dialback", XSF XEP 0220, September 2013. 736 10.2. Informative References 738 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 739 FUNCTIONS", RFC 2142, May 1997. 741 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 742 Protocol (XMPP): Core", RFC 3920, October 2004. 744 [XEP-0045] 745 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 746 2012. 748 [XEP-0288] 749 Hancke, P. and D. Cridland, "Bidirectional Server-to- 750 Server Connections", XSF XEP 0288, September 2013. 752 Appendix A. Acknowledgements 754 Thanks to Philipp Hancke for his feedback. 756 Authors' Addresses 758 Peter Saint-Andre 759 &yet 760 P.O. Box 787 761 Parker, CO 80134 762 USA 764 Email: peter@andyet.com 766 Matthew Miller 767 Cisco Systems, Inc. 768 1899 Wynkoop Street, Suite 600 769 Denver, CO 80202 770 USA 772 Email: mamille2@cisco.com