idnits 2.17.1 draft-ietf-xmpp-dna-07.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 (October 11, 2014) is 3482 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-07 == Outdated reference: A later version (-06) exists of draft-ietf-xmpp-posh-02 ** 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: April 14, 2015 Cisco Systems, Inc. 6 October 11, 2014 8 Domain Name Associations (DNA) in the Extensible Messaging and Presence 9 Protocol (XMPP) 10 draft-ietf-xmpp-dna-07 12 Abstract 14 This document improves the security of the Extensible Messaging and 15 Presence Protocol (XMPP) in two ways. First, it specifies how to 16 establish a strong association between a domain name and an XML 17 stream, using the concept of "prooftypes". Second, it describes how 18 to securely delegate a service domain name (e.g., example.com) to a 19 target server host name (e.g., hosting.example.net), which is 20 especially important in multi-tenanted environments where the same 21 target server hosts a large number of service associated with 22 different domains. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 14, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Client-to-Server (C2S) DNA . . . . . . . . . . . . . . . . . 3 61 3.1. C2S Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. C2S Description . . . . . . . . . . . . . . . . . . . . . 4 63 4. Server-to-Server (S2S) DNA . . . . . . . . . . . . . . . . . 5 64 4.1. S2S Flow Chart . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. A Simple S2S Scenario . . . . . . . . . . . . . . . . . . 7 66 4.3. One-Way Authentication . . . . . . . . . . . . . . . . . 8 67 4.4. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 9 68 4.4.1. Assertion . . . . . . . . . . . . . . . . . . . . . . 9 69 4.4.2. Supposition . . . . . . . . . . . . . . . . . . . . . 11 70 5. Alternative Prooftypes . . . . . . . . . . . . . . . . . . . 12 71 5.1. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.2. POSH . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 6. Secure Delegation and Multi-Tenancy . . . . . . . . . . . . . 13 74 7. Prooftype Model . . . . . . . . . . . . . . . . . . . . . . . 14 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 8.1. Well-Known URI for xmpp-client Service . . . . . . . . . 14 77 8.2. Well-Known URI for xmpp-server Service . . . . . . . . . 15 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 10.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 In systems that use the Extensible Messaging and Presence Protocol 88 (XMPP) [RFC6120], it is important to establish a strong association 89 between the DNS domain name of an XMPP service (e.g., example.com) 90 and the XML stream that a client or peer server initiates with that 91 service. In other words, the client or peer server needs to verify 92 the identity of the server to which it connects. 94 To date, such verification has been established based on information 95 obtained from the Domain Name System (DNS), the Public Key 96 Infrastructure (PKI), or similar sources. In relation to such 97 associations, this document does the following: 99 1. Generalizes the model currently in use so that additional 100 prooftypes can be defined if needed. 102 2. Provides a basis for modernizing some prooftypes to reflect 103 progress in underlying technologies such as DNS Security 104 [RFC4033]. 106 3. Describes the flow of operations for establishing a domain name 107 association (DNA). 109 This document also provides guidelines for secure delegation of a 110 service domain name (e.g., example.com) to a target server host name 111 (e.g., hosting.example.net). The need for secure delegation arises 112 because the process for resolving the domain name of an XMPP service 113 into the IP address at which an XML stream will be negotiated (see 114 [RFC6120]) can involve delegation of a service domain name to a 115 target server host name using technologies such as DNS SRV records 116 [RFC2782]. A more detailed description of the delegation problem can 117 be found in [I-D.ietf-xmpp-posh]. If such delegation is not done in 118 a secure manner, then the domain name association cannot be verified. 120 2. Terminology 122 This document inherits XMPP terminology from [RFC6120] and 123 [XEP-0220], DNS terminology from [RFC1034], [RFC1035], [RFC2782] and 124 [RFC4033], and security terminology from [RFC4949] and [RFC5280]. 125 The terms "reference identity", and "presented identity" are used as 126 defined in the "CertID" specification [RFC6125]. For the sake of 127 consistency with [I-D.ietf-dane-srv], this document uses the terms 128 "service domain name" and "target server host name" to refer to the 129 same entities identified by the terms "source domain" and "derived 130 domain" from [RFC6125]. 132 3. Client-to-Server (C2S) DNA 134 The client-to-server case is much simpler than the server-to-server 135 case because the client does not assert a domain name, the only 136 domain name that needs to be verified is that of the server, etc. 137 Therefore we describe this case first to help the reader understand 138 domain name associations in XMPP. 140 3.1. C2S Flow 142 The following flow chart illustrates the protocol flow for 143 establishing a domain name association for an XML stream from a 144 client to a server using the standard PKIX prooftype specified in 145 [RFC6120]. 147 | 148 DNS RESOLUTION ETC. 149 | 150 +-----------------STREAM HEADERS---------------------+ 151 | | 152 | A: | 153 | | 154 | B: | 155 | | 156 +----------------------------------------------------+ 157 | 158 +-----------------TLS NEGOTIATION--------------------+ 159 | | 160 | B: Server Certificate | 161 | | 162 +----------------------------------------------------+ 163 | 164 (client establishes DNA for a.example) 165 | 167 3.2. C2S Description 169 The simplified order of events (see [RFC6120] for details) in 170 establishing an XML stream from a client (user@a.exmaple) to a server 171 (a.example) is as follows: 173 1. The client resolves the DNS domain name a.example. 175 2. The client opens a TCP connection to the resolved IP address. 177 3. The client sends an initial stream header to the server. 179 181 4. The server sends a response stream header to the client, 182 asserting that it is a.example: 184 186 5. The parties attempt TLS negotiation, during which the XMPP server 187 (acting as a TLS server) presents a PKIX certificate proving that 188 it is a.example. 190 6. The client checks the PKIX certificate that the server provided; 191 if the proof is consistent with the XMPP profile of the matching 192 rules from [RFC6125], the client accepts that there is a strong 193 domain name association between its stream to the target server 194 and the DNS domain name of the XMPP service. 196 4. Server-to-Server (S2S) DNA 198 The server-to-server case is significantly more complex than the 199 client-to-server case, and involves checking of domain name 200 associations in both directions along with other "wrinkles" described 201 in the following sections. 203 4.1. S2S Flow Chart 205 The following flow chart illustrates the protocol flow for 206 establishing domain name associations between Server 1 and Server 2, 207 as described in the remaining sections of this document. 209 | 210 (Section 4.2: A Simple Scenario) 211 | 212 DNS RESOLUTION ETC. 213 | 214 +-------------STREAM HEADERS--------------------+ 215 | | 216 | A: | 217 | | 218 | B: | 219 | | 220 +-----------------------------------------------+ 221 | 222 +-------------TLS NEGOTIATION-------------------+ 223 | | 224 | B: Server Certificate | 225 | [B: Certificate Request] | 226 | [A: Client Certificate] | 227 | | 228 +-----------------------------------------------+ 229 | 230 (A establishes DNA for b.example) 231 | 232 +-------------AUTHENTICATION--------------------+ 233 | | | 234 | {client certificate?} ----+ | 235 | | | | 236 | | yes no | | 237 | v | | 238 | SASL EXTERNAL | | 239 | (mutual auth!) | | 240 +------------------------------------|----------+ 241 | 242 +----------------+ 243 | B needs to auth A 244 | 245 | 246 (Section 4.3: One-Way Authentication) 247 | 248 DNS RESOLUTION ETC. 249 | 250 +-------------STREAM HEADERS--------------------+ 251 | | 252 | B: | 253 | | 254 | A: | 255 | | 256 +-----------------------------------------------+ 257 | 258 +-------------TLS NEGOTIATION-------------------+ 259 | | 260 | A: Server Certificate | 261 | | 262 +-----------------------------------------------+ 263 | 264 (B establishes DNA for a.example) 265 | 266 | 267 (Section 4.4.1: Piggybacking Assertion) 268 | 269 +----------DIALBACK IDENTITY ASSERTION----------+ 270 | | 271 | B: | 273 | | 274 +-----------------------------------------------+ 275 | 276 +-----------DNA DANCE AS ABOVE------------------+ 277 | | 278 | DNS RESOLUTION, STREAM HEADERS, | 279 | TLS NEGOTIATION, AUTHENTICATION | 280 | | 281 +-----------------------------------------------+ 282 | 283 +----------DIALBACK IDENTITY VERIFICATION-------+ 284 | | 285 | A: | 288 | | 289 +-----------------------------------------------+ 290 | 291 | 292 (Section 4.4.2: Piggybacking Supposition) 293 | 294 +-----------SUBSEQUENT CONNECTION---------------+ 295 | | 296 | B: | 298 | | 299 | A: | 301 | | 302 +-----------------------------------------------+ 303 | 304 +-----------DNA DANCE AS ABOVE------------------+ 305 | | 306 | DNS RESOLUTION, STREAM HEADERS, | 307 | TLS NEGOTIATION, AUTHENTICATION | 308 | | 309 +-----------------------------------------------+ 310 | 311 +-----------DIALBACK OPTIMIZATION---------------+ 312 | | 313 | B: | 315 | | 316 | B: | 319 | | 320 +-----------------------------------------------+ 321 | 323 4.2. A Simple S2S Scenario 325 To illustrate the problem, consider the simplified order of events 326 (see [RFC6120] for details) in establishing an XML stream between 327 Server 1 (a.example) and Server 2 (b.example): 329 1. Server 1 resolves the DNS domain name b.example. 331 2. Server 1 opens a TCP connection to the resolved IP address. 333 3. Server 1 sends an initial stream header to Server 2, asserting 334 that it is a.example: 336 338 4. Server 2 sends a response stream header to Server 1, asserting 339 that it is b.example: 341 343 5. The servers attempt TLS negotiation, during which Server 2 344 (acting as a TLS server) presents a PKIX certificate proving that 345 it is b.example and Server 1 (acting as a TLS client) presents a 346 PKIX certificate proving that it is a.example. 348 6. Server 1 checks the PKIX certificate that Server 2 provided and 349 Server 2 checks the PKIX certificate that Server 1 provided; if 350 these proofs are consistent with the XMPP profile of the matching 351 rules from [RFC6125], each server accepts that there is a strong 352 domain name association between its stream to the other party and 353 the DNS domain name of the other party. 355 Several simplifying assumptions underlie the happy scenario just 356 outlined: 358 o Server 1 presents a PKIX certificate during TLS negotiation, which 359 enables the parties to complete mutual authentication. 361 o There are no additional domains associated with Server 1 and 362 Server 2 (say, a subdomain rooms.a.example on Server 1 or a second 363 domain c.example on Server 2). 365 o The server administrators are able to obtain PKIX certificates in 366 the first place. 368 o The server administrators are running their own XMPP servers, 369 rather than using hosting services. 371 Let's consider each of these "wrinkles" in turn. 373 4.3. One-Way Authentication 375 If Server 1 does not present its PKIX certificate during TLS 376 negotiation (perhaps because it wishes to verify the identity of 377 Server 2 before presenting its own credentials), Server 2 is unable 378 to mutually authenticate Server 1. Therefore, Server 2 needs to 379 negotiate and authenticate a stream to Server 1, just as Server 1 has 380 done: 382 1. Server 2 resolves the DNS domain name a.example. 384 2. Server 2 opens a TCP connection to the resolved IP address. 386 3. Server 2 sends an initial stream header to Server 1, asserting 387 that it is b.example: 389 391 4. Server 1 sends a response stream header to Server 2, asserting 392 that it is a.example: 394 396 5. The servers attempt TLS negotiation, during which Server 1 397 (acting as a TLS server) presents a PKIX certificate proving that 398 it is a.example. 400 6. Server 2 checks the PKIX certificate that Server 1 provided; if 401 it is consistent with the XMPP profile [RFC6120] of the matching 402 rules from [RFC6125], Server 2 accepts that there is a strong 403 domain name association between its stream to Server 1 and the 404 DNS domain name a.example. 406 At this point the servers are using two TCP connections instead of 407 one, which is somewhat wasteful. However, there are ways to tie the 408 authentication achieved on the second TCP connection to the first TCP 409 connection; see [XEP-0288] for further discussion. 411 4.4. Piggybacking 413 4.4.1. Assertion 415 Consider the common scenario in which Server 2 hosts not only 416 b.example but also a second domain c.example (a "multi-tenanted" 417 environment). If a user of Server 2 associated with c.example wishes 418 to communicate with a friend at a.example, Server 2 needs to send 419 XMPP stanzas from the domain c.example rather than b.example. 420 Although Server 2 could open an new TCP connection and negotiate new 421 XML streams for the domain pair of c.example and a.example, that too 422 is wasteful. Server 2 already has a connection to a.example, so how 423 can it assert that it would like to add a new domain pair to the 424 existing connection? 425 The traditional method for doing so is the Server Dialback protocol, 426 first specified in [RFC3920] and since moved to [XEP-0220]. Here, 427 Server 2 can send a element for the new domain pair over 428 the existing stream. 430 431 some-dialback-key 432 434 This element functions as Server 2's assertion that it is (also) 435 c.example, and thus is functionally equivalent to the 'from' address 436 of an initial stream header as previously described. 438 In response to this assertion, Server 1 needs to obtain some kind of 439 proof that Server 2 really is also c.example. It can do the same 440 thing that it did before: 442 1. Server 1 resolves the DNS domain name c.example. 444 2. Server 1 opens a TCP connection to the resolved IP address (which 445 might be the same IP address as for b.example). 447 3. Server 1 sends an initial stream header to Server 2, asserting 448 that it is a.example: 450 452 4. Server 2 sends a response stream header to Server 1, asserting 453 that it is c.example: 455 457 5. The servers attempt TLS negotiation, during which Server 2 458 (acting as a TLS server) presents a PKIX certificate proving that 459 it is c.example. 461 6. Server 1 checks the PKIX certificate that Server 2 provided; if 462 it is consistent with the XMPP profile [RFC6120] of the matching 463 rules from [RFC6125], Server 1 accepts that there is a strong 464 domain name association between its stream to Server 2 and the 465 DNS domain name c.example. 467 Now that Server 1 accepts the domain name association, it informs 468 Server 2 of that fact: 470 472 The parties can then terminate the second connection, since it was 473 used only for Server 1 to associate a stream over the same IP:port 474 combination with the domain name c.example (the dialback key links 475 the original stream to the new association). 477 4.4.2. Supposition 479 Piggybacking can also occur in the other direction. Consider the 480 common scenario in which Server 1 provides XMPP services not only for 481 a.example but also for a subdomain such as a groupchat service at 482 rooms.a.example (see [XEP-0045]). If a user from c.example at Server 483 2 wishes to join a room on the groupchat sevice, Server 2 needs to 484 send XMPP stanzas from the domain c.example to the domain 485 rooms.a.example rather than a.example. Therefore, Server 2 needs to 486 negotiate and authenticate a stream to rooms.a.example: 488 1. Server 2 resolves the DNS domain name rooms.a.example. 490 2. Server 2 opens a TCP connection to the resolved IP address. 492 3. Server 2 sends an initial stream header to Server 1 acting as 493 rooms.a.example, asserting that it is b.example: 495 497 4. Server 1 sends a response stream header to Server 2, asserting 498 that it is rooms.a.example: 500 502 5. The servers attempt TLS negotiation, during which Server 1 503 (acting as a TLS server) presents a PKIX certificate proving that 504 it is rooms.a.example. 506 6. Server 2 checks the PKIX certificate that Server 1 provided; if 507 it is consistent with the XMPP profile [RFC6120] of the matching 508 rules from [RFC6125], Server 2 accepts that there is a strong 509 domain name association between its stream to Server 1 and the 510 DNS domain name rooms.a.example. 512 As before, the parties now have two TCP connections open. So that 513 they can close the now-redundant connection, Server 2 sends a 514 dialback key to Server 1 over the new connection. 516 517 some-dialback-key 518 520 Server 1 then informs Server 2 that it accepts the domain name 521 association: 523 525 Server 2 can now close the connection over which it tested the domain 526 name association for rooms.a.example. 528 5. Alternative Prooftypes 530 The foregoing protocol flows assumed that domain name associations 531 were proved using the standard PKI prooftype specified in [RFC6120]: 532 that is, the server's proof consists of a PKIX certificate that is 533 checked according to the XMPP profile [RFC6120] of the matching rules 534 from [RFC6125], the client's verification material is obtained out of 535 band in the form of a trusted root, and secure DNS is not necessary. 537 However, sometimes XMPP server administrators are unable or unwilling 538 to obtain valid PKIX certificates for their servers. As one example, 539 in order to issue a PKIX certificate a certification authority (CA) 540 might try to send email messages to authoritative mailbox names 541 [RFC2142], but the administrator of a subsidiary service such as 542 im.cs.podunk.example cannot receive email sent to 543 mailto:hostmaster@podunk.example. As another example, a hosting 544 provider such as hosting.example.net might not want to take on the 545 liability of holding the certificate and private key for a tenant 546 such as example.com (or the tenant might not want the hosting 547 provider to hold its certificate and private key). In these 548 circumstances, prooftypes other than PKIX are desirable. As 549 described below, two alternatives have been defined so far: DNS-Based 550 Authentication of Named Entities (DANE) and PKIX Over Secure HTTP 551 (POSH). 553 5.1. DANE 555 In the DANE prooftype, the server's proof consists of either a 556 service certificate or domain-issued certificate (TLSA usage PKIX-EE 557 or DANE-EE, see [RFC6698] and [RFC7218]) that is compared as an exact 558 match or a hash of either the SubjectPublicKeyInfo or the full 559 certificate, and the client's verification material is obtained via 560 secure DNS. 562 The DANE prooftype makes use of the DNS-Based Authentication of Named 563 Entities [RFC6698], specifically the use of DANE with DNS SRV records 564 [I-D.ietf-dane-srv]. For XMPP purposes, the following rules apply: 566 o If there is no SRV resource record, pursue the fallback methods 567 described in [RFC6120]. 569 o Use the 'to' address of the initial stream header to determine the 570 domain name of the TLS client's reference identifier (since use of 571 the TLS Server Name Indication is purely discretionary in XMPP, as 572 mentioned in [RFC6120]). 574 5.2. POSH 576 In the POSH prooftype, the server's proof consists of a PKIX 577 certificate that is checked according to the rules from [RFC6120] and 578 [RFC6125], the client's verification material is obtained by 579 retrieving the PKIX certificate over HTTPS at a well-known URI 580 [RFC5785], and secure DNS is not necessary since the HTTPS retrieval 581 mechanism relies on the chain of trust from the public key 582 infrastructure. 584 POSH is defined in [I-D.ietf-xmpp-posh]. For XMPP purposes, the 585 well-known URIs [RFC5785] to be used are: 587 o "/.well-known/posh._xmpp-client._tcp.json" for client-to-server 588 connections 590 o "/.well-known/posh._xmpp-server._tcp.json" for server-to-server 591 connections 593 6. Secure Delegation and Multi-Tenancy 595 One common method for deploying XMPP services is multi-tenancy: e.g., 596 the XMPP service for example.com is actually hosted at 597 hosting.example.net. Such an arrangement is relatively convenient in 598 XMPP given the use of DNS SRV records [RFC2782], such as the 599 following delegation from example.com to hosting.example.net: 601 _xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net 603 Secure connections with multi-tenancy can work using the PKIX 604 prooftype on a small scale if the provider itself wishes to host 605 several domains (e.g., several related domains such as jabber- 606 de.example and jabber-ch.example). However, in practice the security 607 of multi-tenancy has been found to be unwieldy when the provider 608 hosts large numbers of XMPP services on behalf of multiple tenants 609 (see [I-D.ietf-xmpp-posh] for a detailed description). Typically 610 there are two main reasons for this state of affairs: the service 611 provider (say, hosting.example.net) wishes to limit its liability and 612 therefore does not wish to hold the certificate and private key for 613 the tenant (say, example.com) and the tenant wishes to improve the 614 security of the service and therefore does not wish to share its 615 certificate and private key with service provider. As a result, 616 server-to-server communications to example.com go unencrypted or the 617 communications are TLS-encrypted but the certificates are not checked 618 (which is functionally equivalent to a connection using an anonymous 619 key exchange). This is also true of client-to-server communications, 620 forcing end users to override certificate warnings or configure their 621 clients to accept certificates for hosting.example.net instead of 622 example.com. The fundamental problem here is that if DNSSEC is not 623 used then the act of delegation via DNS SRV records is inherently 624 insecure. 626 The specification for use of SRV records with DANE 627 [I-D.ietf-dane-srv] explains how to use DNSSEC for secure delegation 628 with the DANE prooftype, and the POSH specification 629 [I-D.ietf-xmpp-posh] explains how to use HTTPS redirects for secure 630 delegation with the POSH prooftype. 632 7. Prooftype Model 634 In general, a domain name association (DNA) prooftype conforms to the 635 following definition: 637 prooftype: A mechanism for proving an association between a domain 638 name and an XML stream, where the mechanism defines (1) the nature 639 of the server's proof, (2) the matching rules for comparing the 640 client's verification material against the server's proof, (3) how 641 the client obtains its verification material, and (4) whether the 642 mechanism depends on secure DNS. 644 The PKIX, DANE, and POSH prooftypes adhere to this model. In 645 addition, other prooftypes are possible (examples might include PGP 646 keys rather than PKIX certificates, or a token mechanism such as 647 Kerberos or OAuth). 649 Some prooftypes depend on (or are enhanced by) secure DNS and thus 650 also need to describe how they ensure secure delegation. 652 8. IANA Considerations 654 The POSH specification [I-D.ietf-xmpp-posh] provides guidelines for 655 registering the well-known URIs [RFC5785] of protocols that make use 656 of POSH. This specification registers two such URIs, for which the 657 completed registration templates follow. 659 8.1. Well-Known URI for xmpp-client Service 661 This specification registers the well-known URI "posh._xmpp- 662 client._tcp.json" in the Well-Known URI Registry as defined by 663 [RFC5785]. 665 URI suffix: posh._xmpp-client._tcp.json 667 Change controller: IETF 669 Specification document(s): [[ this document ]] 671 8.2. Well-Known URI for xmpp-server Service 673 This specification registers the well-known URI "posh._xmpp- 674 server._tcp.json" in the Well-Known URI Registry as defined by 675 [RFC5785]. 677 URI suffix: posh._xmpp-server._tcp.json 679 Change controller: IETF 681 Specification document(s): [[ this document ]] 683 9. Security Considerations 685 This document supplements but does not supersede the security 686 considerations of [RFC6120] and [RFC6125]. Relevant security 687 considerations can also be found in [I-D.ietf-dane-srv] and 688 [I-D.ietf-xmpp-posh]. 690 10. References 692 10.1. Normative References 694 [I-D.ietf-dane-srv] 695 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 696 Based Authentication of Named Entities (DANE) TLSA records 697 with SRV and MX records.", draft-ietf-dane-srv-07 (work in 698 progress), July 2014. 700 [I-D.ietf-xmpp-posh] 701 Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP 702 (POSH)", draft-ietf-xmpp-posh-02 (work in progress), 703 October 2014. 705 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 706 STD 13, RFC 1034, November 1987. 708 [RFC1035] Mockapetris, P., "Domain names - implementation and 709 specification", STD 13, RFC 1035, November 1987. 711 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 712 specifying the location of services (DNS SRV)", RFC 2782, 713 February 2000. 715 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 716 Rose, "DNS Security Introduction and Requirements", RFC 717 4033, May 2005. 719 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 720 4949, August 2007. 722 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 723 Housley, R., and W. Polk, "Internet X.509 Public Key 724 Infrastructure Certificate and Certificate Revocation List 725 (CRL) Profile", RFC 5280, May 2008. 727 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 728 Uniform Resource Identifiers (URIs)", RFC 5785, April 729 2010. 731 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 732 Protocol (XMPP): Core", RFC 6120, March 2011. 734 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 735 Verification of Domain-Based Application Service Identity 736 within Internet Public Key Infrastructure Using X.509 737 (PKIX) Certificates in the Context of Transport Layer 738 Security (TLS)", RFC 6125, March 2011. 740 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 741 of Named Entities (DANE) Transport Layer Security (TLS) 742 Protocol: TLSA", RFC 6698, August 2012. 744 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 745 Conversations about DNS-Based Authentication of Named 746 Entities (DANE)", RFC 7218, April 2014. 748 [XEP-0220] 749 Miller, J., Saint-Andre, P., and P. Hancke, "Server 750 Dialback", XSF XEP 0220, September 2013. 752 10.2. Informative References 754 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 755 FUNCTIONS", RFC 2142, May 1997. 757 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 758 Protocol (XMPP): Core", RFC 3920, October 2004. 760 [XEP-0045] 761 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 762 2012. 764 [XEP-0288] 765 Hancke, P. and D. Cridland, "Bidirectional Server-to- 766 Server Connections", XSF XEP 0288, September 2013. 768 Appendix A. Acknowledgements 770 Thanks to Philipp Hancke for his feedback. 772 Authors' Addresses 774 Peter Saint-Andre 775 &yet 777 Email: peter@andyet.com 778 URI: https://andyet.com/ 780 Matthew Miller 781 Cisco Systems, Inc. 782 1899 Wynkoop Street, Suite 600 783 Denver, CO 80202 784 USA 786 Email: mamille2@cisco.com