idnits 2.17.1 draft-ietf-xmpp-dna-08.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 23, 2014) is 3472 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-08 == 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 26, 2015 Cisco Systems, Inc. 6 October 23, 2014 8 Domain Name Associations (DNA) in the Extensible Messaging and Presence 9 Protocol (XMPP) 10 draft-ietf-xmpp-dna-08 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 26, 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 . . . . . . . . . . . . . . . . . . . . . 15 76 8.1. Well-Known URI for xmpp-client Service . . . . . . . . . 15 77 8.2. Well-Known URI for xmpp-server Service . . . . . . . . . 15 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 10.2. Informative References . . . . . . . . . . . . . . . . . 17 82 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 following rules apply: 587 o If no verification materials are found via POSH, pursue the 588 fallback methods described in [RFC6120]. 590 o Use the 'to' address of the initial stream header to determine the 591 domain name of the TLS client's reference identifier (since use of 592 the TLS Server Name Indication is purely discretionary in XMPP, as 593 mentioned in [RFC6120]). 595 The well-known URIs [RFC5785] to be used for POSH are: 597 o "/.well-known/posh._xmpp-client._tcp.json" for client-to-server 598 connections 600 o "/.well-known/posh._xmpp-server._tcp.json" for server-to-server 601 connections 603 6. Secure Delegation and Multi-Tenancy 605 One common method for deploying XMPP services is multi-tenancy: e.g., 606 the XMPP service for example.com is actually hosted at 607 hosting.example.net. Such an arrangement is relatively convenient in 608 XMPP given the use of DNS SRV records [RFC2782], such as the 609 following delegation from example.com to hosting.example.net: 611 _xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net 613 Secure connections with multi-tenancy can work using the PKIX 614 prooftype on a small scale if the provider itself wishes to host 615 several domains (e.g., several related domains such as jabber- 616 de.example and jabber-ch.example). However, in practice the security 617 of multi-tenancy has been found to be unwieldy when the provider 618 hosts large numbers of XMPP services on behalf of multiple tenants 619 (see [I-D.ietf-xmpp-posh] for a detailed description). Typically 620 there are two main reasons for this state of affairs: the service 621 provider (say, hosting.example.net) wishes to limit its liability and 622 therefore does not wish to hold the certificate and private key for 623 the tenant (say, example.com) and the tenant wishes to improve the 624 security of the service and therefore does not wish to share its 625 certificate and private key with service provider. As a result, 626 server-to-server communications to example.com go unencrypted or the 627 communications are TLS-encrypted but the certificates are not checked 628 (which is functionally equivalent to a connection using an anonymous 629 key exchange). This is also true of client-to-server communications, 630 forcing end users to override certificate warnings or configure their 631 clients to accept certificates for hosting.example.net instead of 632 example.com. The fundamental problem here is that if DNSSEC is not 633 used then the act of delegation via DNS SRV records is inherently 634 insecure. 636 The specification for use of SRV records with DANE 637 [I-D.ietf-dane-srv] explains how to use DNSSEC for secure delegation 638 with the DANE prooftype, and the POSH specification 639 [I-D.ietf-xmpp-posh] explains how to use HTTPS redirects for secure 640 delegation with the POSH prooftype. 642 7. Prooftype Model 644 In general, a domain name association (DNA) prooftype conforms to the 645 following definition: 647 prooftype: A mechanism for proving an association between a domain 648 name and an XML stream, where the mechanism defines (1) the nature 649 of the server's proof, (2) the matching rules for comparing the 650 client's verification material against the server's proof, (3) how 651 the client obtains its verification material, and (4) whether the 652 mechanism depends on secure DNS. 654 The PKIX, DANE, and POSH prooftypes adhere to this model. (Some 655 prooftypes depend on, or are enhanced by, secure DNS and thus also 656 need to describe how they ensure secure delegation.) 658 Other prooftypes are possible; examples might include TLS with PGP 659 keys [RFC6091], a token mechanism such as Kerberos [RFC4120] or OAuth 660 [RFC6749], and Server Dialback keys [XEP-0220]. 662 Although the PKIX prooftype reuses the syntax of the XMPP Server 663 Dialback protocol [XEP-0220] for signalling between servers, this 664 framework document does not define how the generation and validation 665 of Server Dialback keys (also specified in [XEP-0220]) is a DNA 666 prooftype. However, nothing in this document prevents the continued 667 use of server dialback, and a future specification (or an updated 668 version of [XEP-0220]) might define a DNA prooftype for dialback in a 669 way that is consistent with this framework. However, nothing in this 670 document prevents the continued use of Server Dialback on the XMPP 671 network. 673 8. IANA Considerations 675 The POSH specification [I-D.ietf-xmpp-posh] provides guidelines for 676 registering the well-known URIs [RFC5785] of protocols that make use 677 of POSH. This specification registers two such URIs, for which the 678 completed registration templates follow. 680 8.1. Well-Known URI for xmpp-client Service 682 This specification registers the well-known URI "posh._xmpp- 683 client._tcp.json" in the Well-Known URI Registry as defined by 684 [RFC5785]. 686 URI suffix: posh._xmpp-client._tcp.json 688 Change controller: IETF 690 Specification document(s): [[ this document ]] 692 8.2. Well-Known URI for xmpp-server Service 694 This specification registers the well-known URI "posh._xmpp- 695 server._tcp.json" in the Well-Known URI Registry as defined by 696 [RFC5785]. 698 URI suffix: posh._xmpp-server._tcp.json 700 Change controller: IETF 702 Specification document(s): [[ this document ]] 704 9. Security Considerations 706 This document supplements but does not supersede the security 707 considerations of [RFC6120] and [RFC6125]. Relevant security 708 considerations can also be found in [I-D.ietf-dane-srv] and 709 [I-D.ietf-xmpp-posh]. 711 10. References 713 10.1. Normative References 715 [I-D.ietf-dane-srv] 716 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 717 Based Authentication of Named Entities (DANE) TLSA records 718 with SRV and MX records.", draft-ietf-dane-srv-08 (work in 719 progress), October 2014. 721 [I-D.ietf-xmpp-posh] 722 Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP 723 (POSH)", draft-ietf-xmpp-posh-02 (work in progress), 724 October 2014. 726 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 727 STD 13, RFC 1034, November 1987. 729 [RFC1035] Mockapetris, P., "Domain names - implementation and 730 specification", STD 13, RFC 1035, November 1987. 732 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 733 specifying the location of services (DNS SRV)", RFC 2782, 734 February 2000. 736 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 737 Rose, "DNS Security Introduction and Requirements", RFC 738 4033, May 2005. 740 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 741 4949, August 2007. 743 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 744 Housley, R., and W. Polk, "Internet X.509 Public Key 745 Infrastructure Certificate and Certificate Revocation List 746 (CRL) Profile", RFC 5280, May 2008. 748 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 749 Uniform Resource Identifiers (URIs)", RFC 5785, April 750 2010. 752 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 753 Protocol (XMPP): Core", RFC 6120, March 2011. 755 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 756 Verification of Domain-Based Application Service Identity 757 within Internet Public Key Infrastructure Using X.509 758 (PKIX) Certificates in the Context of Transport Layer 759 Security (TLS)", RFC 6125, March 2011. 761 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 762 of Named Entities (DANE) Transport Layer Security (TLS) 763 Protocol: TLSA", RFC 6698, August 2012. 765 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 766 Conversations about DNS-Based Authentication of Named 767 Entities (DANE)", RFC 7218, April 2014. 769 [XEP-0220] 770 Miller, J., Saint-Andre, P., and P. Hancke, "Server 771 Dialback", XSF XEP 0220, September 2013. 773 10.2. Informative References 775 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 776 FUNCTIONS", RFC 2142, May 1997. 778 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 779 Protocol (XMPP): Core", RFC 3920, October 2004. 781 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 782 Kerberos Network Authentication Service (V5)", RFC 4120, 783 July 2005. 785 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 786 for Transport Layer Security (TLS) Authentication", RFC 787 6091, February 2011. 789 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 790 6749, October 2012. 792 [XEP-0045] 793 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 794 2012. 796 [XEP-0288] 797 Hancke, P. and D. Cridland, "Bidirectional Server-to- 798 Server Connections", XSF XEP 0288, September 2013. 800 Appendix A. Acknowledgements 802 Thanks to Philipp Hancke for his feedback. 804 Authors' Addresses 806 Peter Saint-Andre 807 &yet 809 Email: peter@andyet.com 810 URI: https://andyet.com/ 812 Matthew Miller 813 Cisco Systems, Inc. 814 1899 Wynkoop Street, Suite 600 815 Denver, CO 80202 816 USA 818 Email: mamille2@cisco.com