idnits 2.17.1 draft-ietf-xmpp-dna-09.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 2 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 (February 16, 2015) is 3354 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-03 ** 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' == Outdated reference: A later version (-07) exists of draft-ietf-uta-xmpp-05 -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) Summary: 3 errors (**), 0 flaws (~~), 5 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: August 20, 2015 Cisco Systems, Inc. 6 P. Hancke 7 &yet 8 February 16, 2015 10 Domain Name Associations (DNA) in the Extensible Messaging and Presence 11 Protocol (XMPP) 12 draft-ietf-xmpp-dna-09 14 Abstract 16 This document improves the security of the Extensible Messaging and 17 Presence Protocol (XMPP) in two ways. First, it specifies how to 18 establish a strong association between a domain name and an XML 19 stream, using the concept of "prooftypes". Second, it describes how 20 to securely delegate a service domain name (e.g., example.com) to a 21 target server host name (e.g., hosting.example.net), which is 22 especially important in multi-tenanted environments where the same 23 target server hosts a large number of domains. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 20, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Client-to-Server (C2S) DNA . . . . . . . . . . . . . . . . . 3 62 3.1. C2S Flow . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. C2S Description . . . . . . . . . . . . . . . . . . . . . 4 64 4. Server-to-Server (S2S) DNA . . . . . . . . . . . . . . . . . 5 65 4.1. S2S Flow . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.2. A Simple S2S Scenario . . . . . . . . . . . . . . . . . . 8 67 4.3. One-Way Authentication . . . . . . . . . . . . . . . . . 9 68 4.4. Piggybacking . . . . . . . . . . . . . . . . . . . . . . 11 69 4.4.1. Assertion . . . . . . . . . . . . . . . . . . . . . . 11 70 4.4.2. Supposition . . . . . . . . . . . . . . . . . . . . . 12 71 5. Alternative Prooftypes . . . . . . . . . . . . . . . . . . . 13 72 5.1. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 5.2. POSH . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 6. Secure Delegation and Multi-Tenancy . . . . . . . . . . . . . 15 75 7. Prooftype Model . . . . . . . . . . . . . . . . . . . . . . . 16 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 77 8.1. Well-Known URI for xmpp-client Service . . . . . . . . . 17 78 8.2. Well-Known URI for xmpp-server Service . . . . . . . . . 17 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 82 10.2. Informative References . . . . . . . . . . . . . . . . . 19 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 86 1. Introduction 88 In systems that use the Extensible Messaging and Presence Protocol 89 (XMPP) [RFC6120], it is important to establish a strong association 90 between the DNS domain name of an XMPP service (e.g., example.com) 91 and the XML stream that a client or peer server initiates with that 92 service. In other words, the client or peer server needs to verify 93 the identity of the server to which it connects. Additionally, 94 servers need to verify incoming connections from other servers. 96 To date, such verification has been established based on information 97 obtained from the Domain Name System (DNS), the Public Key 98 Infrastructure (PKI), or similar sources. In relation to such 99 associations, this document does the following: 101 1. Generalizes the model currently in use so that additional 102 prooftypes can be defined if needed. 104 2. Provides a basis for modernizing some prooftypes to reflect 105 progress in underlying technologies such as DNS Security 106 [RFC4033]. 108 3. Describes the flow of operations for establishing a domain name 109 association (DNA). 111 This document also provides guidelines for secure delegation of a 112 service domain name (e.g., example.com) to a target server host name 113 (e.g., hosting.example.net). The need for secure delegation arises 114 because the process for resolving the domain name of an XMPP service 115 into the IP address at which an XML stream will be negotiated (see 116 [RFC6120]) can involve delegation of a service domain name to a 117 target server host name using technologies such as DNS SRV records 118 [RFC2782]. A more detailed description of the delegation problem can 119 be found in [I-D.ietf-xmpp-posh]. If such delegation is not done in 120 a secure manner, then the domain name association cannot be verified. 122 2. Terminology 124 This document inherits XMPP terminology from [RFC6120] and 125 [XEP-0220], DNS terminology from [RFC1034], [RFC1035], [RFC2782] and 126 [RFC4033], and security terminology from [RFC4949] and [RFC5280]. 127 The terms "reference identity", and "presented identity" are used as 128 defined in the "CertID" specification [RFC6125]. For the sake of 129 consistency with [I-D.ietf-dane-srv], this document uses the terms 130 "service domain name" and "target server host name" to refer to the 131 same entities identified by the terms "source domain" and "derived 132 domain" from [RFC6125]. 134 3. Client-to-Server (C2S) DNA 136 The client-to-server case is much simpler than the server-to-server 137 case because the client does not assert a domain name, which means 138 verification happens in only one direction. Therefore we describe 139 this case first to help the reader understand domain name 140 associations in XMPP. 142 3.1. C2S Flow 144 The following flow chart illustrates the protocol flow for 145 establishing a domain name association for an XML stream from a 146 client (C) to a server (S) using the standard PKIX prooftype 147 specified in [RFC6120]. 149 | 150 DNS RESOLUTION ETC. 151 | 152 +-----------------STREAM HEADERS---------------------+ 153 | | 154 | C: | 155 | | 156 | S: | 157 | | 158 +----------------------------------------------------+ 159 | 160 +-----------------TLS NEGOTIATION--------------------+ 161 | | 162 | S: Server Certificate | 163 | | 164 +----------------------------------------------------+ 165 | 166 (client checks certificate and 167 establishes DNA for a.example) 168 | 170 3.2. C2S Description 172 The simplified order of events (see [RFC6120] for details) in 173 establishing an XML stream from a client (user@a.exmaple) to a server 174 (a.example) is as follows: 176 1. The client resolves via DNS the service _xmpp- 177 client._tcp.a.example. 179 2. The client opens a TCP connection to the resolved IP address. 181 3. The client sends an initial stream header to the server: 183 185 4. The server sends a response stream header to the client, 186 asserting that it is a.example: 188 190 5. The parties attempt TLS negotiation, during which the XMPP server 191 (acting as a TLS server) presents a PKIX certificate proving that 192 it is a.example. 194 6. The client checks the PKIX certificate that the server provided; 195 if the proof is consistent with the XMPP profile of the matching 196 rules from [RFC6125] and the certificate is otherwise valid 197 according to [RFC5280], the client accepts that there is a strong 198 domain name association between its stream to the target server 199 and the DNS domain name of the XMPP service. 201 The certificate that the server presents might not be trusted by the 202 client. As one example, the server might be hosting multiple domains 203 and secure delegation as described in Section 6 is necessary. As 204 another example, the server might present a self-signed certificate, 205 which requires the client to apply either the fallback process 206 described in section 6.6.4 of [RFC6125] or prompt the user to accept 207 an unauthenticated connection as described in [I-D.ietf-uta-xmpp]. 209 4. Server-to-Server (S2S) DNA 211 The server-to-server case is significantly more complex than the 212 client-to-server case, and involves checking of domain name 213 associations in both directions along with other "wrinkles" described 214 in the following sections. 216 4.1. S2S Flow 218 The following flow chart illustrates the protocol flow for 219 establishing domain name associations between Server A (the 220 initiating entity) and Server B (the receiving entity), as described 221 in the remaining sections of this document. 223 | 224 (A Simple S2S Scenario) 225 | 226 DNS RESOLUTION ETC. 227 | 228 +-------------STREAM HEADERS--------------------+ 229 | | 230 | A: | 231 | | 232 | B: | 233 | | 234 +-----------------------------------------------+ 235 | 236 +-------------TLS NEGOTIATION-------------------+ 237 | | 238 | B: Server Certificate | 239 | B: Certificate Request | 240 | A: Client Certificate | 241 | | 242 +-----------------------------------------------+ 243 | 244 (A establishes DNA for b.example) 245 | 246 +-------------AUTHENTICATION--------------------+ 247 | | | 248 | {valid client certificate?} --+ | 249 | | | | 250 | | yes no | | 251 | v | | 252 | SASL EXTERNAL | | 253 | (mutual auth!) | | 254 | (B establishes DNA for a.example) | | 255 +-------------------------------------|---------+ 256 | 257 +-----------------+ 258 | B needs to establish DNA 259 | for this stream from a.example, 260 | so A asserts its identity 261 | 262 +----------DIALBACK IDENTITY ASSERTION----------+ 263 | | 264 | A: | 266 | some-dialback-key | 267 | | 268 | | 269 +-----------------------------------------------+ 270 | 271 (Section 4.3: One-Way Authentication) 272 | 273 DNS RESOLUTION ETC. 274 | 275 +-------------STREAM HEADERS--------------------+ 276 | | 277 | B: | 278 | | 279 | A: | 280 | | 281 +-----------------------------------------------+ 282 | 283 +-------------TLS NEGOTIATION-------------------+ 284 | | 285 | A: Server Certificate | 286 | | 287 +-----------------------------------------------+ 288 | 289 +----------DIALBACK IDENTITY VERIFICATION-------+ 290 | | 291 | B: | 294 | some-dialback-key | 295 | | 296 | | 297 | A: | 301 | | 302 +-----------------------------------------------+ 303 | 304 (B establishes DNA for a.example) 305 | 306 | 307 (Section 4.4.1: Piggybacking Assertion) 308 | 309 +----------DIALBACK IDENTITY ASSERTION----------+ 310 | | 311 | B: | 313 | | 314 +-----------------------------------------------+ 315 | 316 +-----------DNA DANCE AS ABOVE------------------+ 317 | | 318 | DNS RESOLUTION, STREAM HEADERS, | 319 | TLS NEGOTIATION, AUTHENTICATION | 320 | | 321 +-----------------------------------------------+ 322 | 323 +----------DIALBACK IDENTITY VERIFICATION-------+ 324 | | 325 | A: | 328 | | 329 +-----------------------------------------------+ 330 | 331 | 332 (Section 4.4.2: Piggybacking Supposition) 333 | 335 +-----------SUBSEQUENT CONNECTION---------------+ 336 | | 337 | B: | 339 | | 340 | A: | 342 | | 343 +-----------------------------------------------+ 344 | 345 +-----------DNA DANCE AS ABOVE------------------+ 346 | | 347 | DNS RESOLUTION, STREAM HEADERS, | 348 | TLS NEGOTIATION, AUTHENTICATION | 349 | | 350 +-----------------------------------------------+ 351 | 352 +-----------DIALBACK OPTIMIZATION---------------+ 353 | | 354 | B: | 356 | | 357 | B: | 360 | | 361 +-----------------------------------------------+ 362 | 364 4.2. A Simple S2S Scenario 366 To illustrate the problem, consider the simplified order of events 367 (see [RFC6120] for details) in establishing an XML stream between 368 Server A (a.example) and Server B (b.example): 370 1. Server A resolves via DNS the service _xmpp- 371 server._tcp.b.example. 373 2. Server A opens a TCP connection to the resolved IP address. 375 3. Server A sends an initial stream header to Server B, asserting 376 that it is a.example: 378 380 4. Server B sends a response stream header to Server A, asserting 381 that it is b.example: 383 385 5. The servers attempt TLS negotiation, during which Server B 386 (acting as a TLS server) presents a PKIX certificate proving that 387 it is b.example and Server A (acting as a TLS client) presents a 388 PKIX certificate proving that it is a.example. 390 6. Server A checks the PKIX certificate that Server B provided and 391 Server B checks the PKIX certificate that Server A provided; if 392 these proofs are consistent with the XMPP profile of the matching 393 rules from [RFC6125] and is otherwise valid according to 394 [RFC5280], each server accepts that there is a strong domain name 395 association between its stream to the other party and the DNS 396 domain name of the other party. 398 Several simplifying assumptions underlie the happy scenario just 399 outlined: 401 o The PKIX certificate presented by Server B during TLS negotiation 402 is trusted by Server A and matches the expected identity. 404 o The PKIX certificate presented by Server A during TLS negotiation 405 is trusted by Server B, which enables the parties to complete 406 mutual authentication. 408 o There are no additional domains associated with Server A and 409 Server B (say, a subdomain rooms.a.example on Server A or a second 410 domain c.example on Server B). 412 o The server administrators are able to obtain PKIX certificates 413 issued by a widely-accepted certificate authority (CA) in the 414 first place. 416 o The server administrators are running their own XMPP servers, 417 rather than using hosting services. 419 Let's consider each of these "wrinkles" in turn. Since Server A is 420 acting as a S2S client the behaviour is same as in the C2S case 421 described in Section 3.2. 423 4.3. One-Way Authentication 425 If the PKIX certificate presented by Server A during TLS negotiation 426 is not trusted by Server B, Server B is unable to mutually 427 authenticate Server A. Therefore, Server B needs to verify the 428 asserted identity of Server A by other means. 430 1. Server A asserts it is a.example using the Server Dialback 431 protocol: 433 some- 434 dialback-key 436 2. Server B resolves via DNS the service _xmpp- 437 server._tcp.a.example. 439 3. Server B opens a TCP connection to the resolved IP address. 441 4. Server B sends an initial stream header to Server A, asserting 442 that it is b.example: 444 446 5. Server A sends a response stream header to Server B, asserting 447 that it is a.example: 449 451 6. The servers attempt TLS negotiation, during which Server A 452 (acting as a TLS server) presents a PKIX certificate proving that 453 it is a.example. 455 7. Server B checks the PKIX certificate that Server A provided. 456 This might be the same certificate presented by Server A as a 457 client certificate in the initial connection. Even if this 458 certificate is not signed by a trusted CA (for example it could 459 be self-signed) Server B can verify that there is an association 460 between the incoming connection and the domain name a.example. 461 Note that this may be insecure unless DNSSEC [RFC4033] is used. 463 8. If the certificate provided by Server A is different from the one 464 presented in the initial connection, Server B proceeds with 465 Server Dialback in order to establish the domain name 466 association. In order to do this it sends a request for 467 verification as described in [XEP-0220]: 469 some- 470 dialback-key 472 9. Server A responds to this: 474 505 some-dialback-key 506 508 This element functions as Server B's assertion that it is (also) 509 c.example, and thus is functionally equivalent to the 'from' address 510 of an initial stream header as previously described. 512 In response to this assertion, Server A needs to obtain some kind of 513 proof that Server B really is also c.example. If the certificate 514 presented by Server B is also valid for c.example then no further 515 action is necessary. However, if not then Server A needs to do a bit 516 more work. Specifically, Server A can pursue the same strategy it 517 used before: 519 1. Server A resolves via DNS the service _xmpp- 520 server._tcp.c.example. 522 2. Server A opens a TCP connection to the resolved IP address (which 523 might be the same IP address as for b.example). 525 3. Server A sends an initial stream header to Server B, asserting 526 that it is a.example: 528 530 4. Server B sends a response stream header to Server A, asserting 531 that it is c.example: 533 535 5. The servers attempt TLS negotiation, during which Server B 536 (acting as a TLS server) presents a PKIX certificate proving that 537 it is c.example. 539 6. At this point, Server A needs to establish that, despite 540 different certificates, c.example is associated with the origin 541 of the request. This is done using Server Dialback [XEP-0220]: 543 some- 544 dialback-key 546 7. Server B responds to this: 548 557 The parties can then terminate the second connection, since it was 558 used only for Server A to associate a stream with the domain name 559 c.example (the dialback key links the original stream to the new 560 association). 562 4.4.2. Supposition 564 Piggybacking can also occur in the other direction. Consider the 565 common scenario in which Server A provides XMPP services not only for 566 a.example but also for a subdomain such as a groupchat service (e.g., 567 Multi-User Chat [XEP-0045]) at rooms.a.example. If a user from 568 c.example at Server B wishes to join a room on the groupchat sevice, 569 Server B needs to send XMPP stanzas from the domain c.example to the 570 domain rooms.a.example rather than a.example. First, Server B needs 571 to determine whether it can piggyback the domain rooms.a.example on 572 the connection to a.example: 574 1. Server B resolves vua DNS the service _xmpp- 575 server._tcp.rooms.a.example. 577 2. Server B determines this resolves to an IP address and port that 578 it is already connected to. 580 3. Server B determines that the PKIX certificate for that active 581 connection would also be valid for the rooms.a.example domain and 582 that Server A has announced support for dialback errors. 584 Server B sends a dialback key to Server A over the existing 585 connection. 587 588 some-dialback-key 589 591 Server A then informs Server B that it accepts the domain name 592 association: 594 596 5. Alternative Prooftypes 598 The foregoing protocol flows assumed that domain name associations 599 were proved using the PKI prooftype specified in [RFC6120]: that is, 600 the server's proof consists of a PKIX certificate that is checked 601 according to the XMPP profile [RFC6120] of the matching rules from 602 [RFC6125] (and the overall validation rules from [RFC5280]), the 603 client's verification material is obtained out of band in the form of 604 a trusted root, and secure DNS is not necessary. 606 However, sometimes XMPP server administrators are unable or unwilling 607 to obtain valid PKIX certificates for all of the domains they host at 608 their servers. For example: 610 o In order to issue a PKIX certificate, a CA might try to send email 611 messages to authoritative mailbox names [RFC2142], but the 612 administrator of a subsidiary service such as im.cs.podunk.example 613 cannot receive email sent to mailto:hostmaster@podunk.example. 615 o A hosting provider such as hosting.example.net might not want to 616 take on the liability of holding the certificate and private key 617 for a tenant such as example.com (or the tenant might not want the 618 hosting provider to hold its certificate and private key). 620 o Even if PKIX certificates for each tenant can be obtained, the 621 management of so many certificates can introduce a large 622 administrative load. 624 (Additional discussion can be found in [I-D.ietf-xmpp-posh].) 626 In these circumstances, prooftypes other than PKIX are desirable or 627 necessary. As described below, two alternatives have been defined so 628 far: DNS-Based Authentication of Named Entities (DANE) and PKIX Over 629 Secure HTTP (POSH). 631 5.1. DANE 633 The DANE prooftype can be defined as follows: 635 1. The server's proof consists of either a service certificate or 636 domain-issued certificate (TLSA usage PKIX-EE or DANE-EE, see 637 [RFC6698] and [RFC7218]). 639 2. The proof is checked by verifying an exact match or a hash of 640 either the SubjectPublicKeyInfo or the full certificate. 642 3. The client's verification material is obtained via secure DNS as 643 described in [I-D.ietf-dane-srv]. 645 4. Secure DNS is necessary in order to effectively establish an 646 alternative chain of trust from the service certificate or 647 domain-issued certificate to the DNS root. 649 The DANE prooftype makes use of the DNS-Based Authentication of Named 650 Entities [RFC6698], specifically the use of DANE with DNS SRV records 651 [I-D.ietf-dane-srv]. For XMPP purposes, the following rules apply: 653 o If there is no SRV resource record, pursue the fallback methods 654 described in [RFC6120]. 656 o Use the 'to' address of the initial stream header to determine the 657 domain name of the TLS client's reference identifier (since use of 658 the Server Name Indication extension (TLS SNI) [RFC6066] is purely 659 discretionary in XMPP, as mentioned in [RFC6120]). 661 5.2. POSH 663 The POSH prooftype can be defined as follows: 665 1. The server's proof consists of a PKIX certificate. 667 2. The proof is checked according to the rules from [RFC6120] and 668 [RFC6125]. 670 3. The client's verification material is obtained by retrieving a 671 hash of the PKIX certificate over HTTPS at a well-known URI 672 [RFC5785]. 674 4. Secure DNS is not necessary since the HTTPS retrieval mechanism 675 relies on the chain of trust from the public key infrastructure. 677 POSH is defined in [I-D.ietf-xmpp-posh]. For XMPP purposes, the 678 following rules apply: 680 o If no verification materials are found via POSH, pursue the 681 fallback methods described in [RFC6120]. 683 o Use the 'to' address of the initial stream header to determine the 684 domain name of the TLS client's reference identifier (since use of 685 the Server Name Indication extension (TLS SNI) [RFC6066] is purely 686 discretionary in XMPP, as mentioned in [RFC6120]). 688 The well-known URIs [RFC5785] to be used for POSH are: 690 o "/.well-known/posh._xmpp-client._tcp.json" for client-to-server 691 connections 693 o "/.well-known/posh._xmpp-server._tcp.json" for server-to-server 694 connections 696 6. Secure Delegation and Multi-Tenancy 698 One common method for deploying XMPP services is multi-tenancy: e.g., 699 XMPP services for the service domain example.com are actually hosted 700 at the target server hosting.example.net. Such an arrangement is 701 relatively convenient in XMPP given the use of DNS SRV records 702 [RFC2782], such as the following delegation from example.com to 703 hosting.example.net: 705 _xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net 707 Secure connections with multi-tenancy can work using the PKIX 708 prooftype on a small scale if the provider itself wishes to host 709 several domains (e.g., related domains such as jabber-de.example and 710 jabber-ch.example). However, in practice the security of multi- 711 tenancy has been found to be unwieldy when the provider hosts large 712 numbers of XMPP services on behalf of multiple tenants (see 713 [I-D.ietf-xmpp-posh] for a detailed description). Typically there 714 are two main reasons for this state of affairs: the service provider 715 (say, hosting.example.net) wishes to limit its liability and 716 therefore does not wish to hold the certificate and private key for 717 the tenant (say, example.com) and the tenant wishes to improve the 718 security of the service and therefore does not wish to share its 719 certificate and private key with the service provider. As a result, 720 server-to-server communications to example.com go unencrypted or the 721 communications are TLS-encrypted but the certificates are not checked 722 (which is functionally equivalent to a connection using an anonymous 723 key exchange). This is also true of client-to-server communications, 724 forcing end users to override certificate warnings or configure their 725 clients to accept or "pin" certificates for hosting.example.net 726 instead of example.com. The fundamental problem here is that if 727 DNSSEC is not used then the act of delegation via DNS SRV records is 728 inherently insecure. 730 The specification for use of SRV records with DANE 731 [I-D.ietf-dane-srv] explains how to use DNSSEC for secure delegation 732 with the DANE prooftype, and the POSH specification 733 [I-D.ietf-xmpp-posh] explains how to use HTTPS redirects for secure 734 delegation with the POSH prooftype. 736 7. Prooftype Model 738 In general, a domain name association (DNA) prooftype conforms to the 739 following definition: 741 prooftype: A mechanism for proving an association between a domain 742 name and an XML stream, where the mechanism defines (1) the nature 743 of the server's proof, (2) the matching rules for comparing the 744 client's verification material against the server's proof, (3) how 745 the client obtains its verification material, and (4) whether the 746 mechanism depends on secure DNS. 748 The PKIX, DANE, and POSH prooftypes adhere to this model. (Some 749 prooftypes depend on, or are enhanced by, secure DNS and thus also 750 need to describe how they ensure secure delegation.) 752 Other prooftypes are possible; examples might include TLS with PGP 753 keys [RFC6091], a token mechanism such as Kerberos [RFC4120] or OAuth 754 [RFC6749], and Server Dialback keys [XEP-0220]. 756 Although the PKIX prooftype reuses the syntax of the XMPP Server 757 Dialback protocol [XEP-0220] for signalling between servers, this 758 framework document does not define how the generation and validation 759 of Server Dialback keys (also specified in [XEP-0220]) is a DNA 760 prooftype. However, nothing in this document prevents the continued 761 use of Server Dialback for signaling, and a future specification (or 762 an updated version of [XEP-0220]) might define a DNA prooftype for 763 Server Dialback keys in a way that is consistent with this framework. 765 8. IANA Considerations 767 The POSH specification [I-D.ietf-xmpp-posh] provides guidelines for 768 registering the well-known URIs [RFC5785] of protocols that make use 769 of POSH. This specification registers two such URIs, for which the 770 completed registration templates follow. 772 8.1. Well-Known URI for xmpp-client Service 774 This specification registers "posh._xmpp-client._tcp.json" in the 775 Well-Known URI Registry as defined by [RFC5785]. 777 URI suffix: posh._xmpp-client._tcp.json 779 Change controller: IETF 781 Specification document(s): [[ this document ]] 783 8.2. Well-Known URI for xmpp-server Service 785 This specification registers "posh._xmpp-server._tcp.json" in the 786 Well-Known URI Registry as defined by [RFC5785]. 788 URI suffix: posh._xmpp-server._tcp.json 790 Change controller: IETF 792 Specification document(s): [[ this document ]] 794 9. Security Considerations 796 With regard to the PKIX prooftype, this document supplements but does 797 not supersede the security considerations of [RFC6120] and [RFC6125]. 799 With regard to the DANE and PKIX prooftypes, the reader is referred 800 to [I-D.ietf-dane-srv] and [I-D.ietf-xmpp-posh], respectively. 802 Any future prooftypes need to thoroughly describe how they conform to 803 the prooftype model specified in Section 7 of this document. 805 10. References 806 10.1. Normative References 808 [I-D.ietf-dane-srv] 809 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 810 Based Authentication of Named Entities (DANE) TLSA Records 811 with SRV Records", draft-ietf-dane-srv-06 (work in 812 progress), June 2014. 814 [I-D.ietf-xmpp-posh] 815 Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP 816 (POSH)", draft-ietf-xmpp-posh-03 (work in progress), 817 January 2015. 819 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 820 STD 13, RFC 1034, November 1987. 822 [RFC1035] Mockapetris, P., "Domain names - implementation and 823 specification", STD 13, RFC 1035, November 1987. 825 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 826 specifying the location of services (DNS SRV)", RFC 2782, 827 February 2000. 829 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 830 Rose, "DNS Security Introduction and Requirements", RFC 831 4033, March 2005. 833 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 834 4949, August 2007. 836 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 837 Housley, R., and W. Polk, "Internet X.509 Public Key 838 Infrastructure Certificate and Certificate Revocation List 839 (CRL) Profile", RFC 5280, May 2008. 841 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 842 Uniform Resource Identifiers (URIs)", RFC 5785, April 843 2010. 845 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 846 Protocol (XMPP): Core", RFC 6120, March 2011. 848 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 849 Verification of Domain-Based Application Service Identity 850 within Internet Public Key Infrastructure Using X.509 851 (PKIX) Certificates in the Context of Transport Layer 852 Security (TLS)", RFC 6125, March 2011. 854 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 855 of Named Entities (DANE) Transport Layer Security (TLS) 856 Protocol: TLSA", RFC 6698, August 2012. 858 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 859 Conversations about DNS-Based Authentication of Named 860 Entities (DANE)", RFC 7218, April 2014. 862 [XEP-0220] 863 Miller, J., Saint-Andre, P., and P. Hancke, "Server 864 Dialback", XSF XEP 0220, August 2014. 866 10.2. Informative References 868 [I-D.ietf-uta-xmpp] 869 Saint-Andre, P. and a. alkemade, "Use of Transport Layer 870 Security (TLS) in the Extensible Messaging and Presence 871 Protocol (XMPP)", draft-ietf-uta-xmpp-05 (work in 872 progress), January 2015. 874 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 875 FUNCTIONS", RFC 2142, May 1997. 877 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 878 Protocol (XMPP): Core", RFC 3920, October 2004. 880 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 881 Kerberos Network Authentication Service (V5)", RFC 4120, 882 July 2005. 884 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 885 Extension Definitions", RFC 6066, January 2011. 887 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 888 for Transport Layer Security (TLS) Authentication", RFC 889 6091, February 2011. 891 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 892 6749, October 2012. 894 [XEP-0045] 895 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 896 2012. 898 [XEP-0288] 899 Hancke, P. and D. Cridland, "Bidirectional Server-to- 900 Server Connections", XSF XEP 0288, September 2013. 902 Appendix A. Acknowledgements 904 Thanks to Richard Barnes, Stephen Farrell, and Jonas Lindberg for 905 contributing to earlier versions of this document. 907 Authors' Addresses 909 Peter Saint-Andre 910 &yet 912 Email: peter@andyet.com 913 URI: https://andyet.com/ 915 Matthew Miller 916 Cisco Systems, Inc. 917 1899 Wynkoop Street, Suite 600 918 Denver, CO 80202 919 USA 921 Email: mamille2@cisco.com 923 Philipp Hancke 924 &yet 926 Email: fippo@andyet.com 927 URI: https://andyet.com/