idnits 2.17.1 draft-ietf-xmpp-dna-10.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 (March 24, 2015) is 3314 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-12 == Outdated reference: A later version (-06) exists of draft-ietf-xmpp-posh-04 ** 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: September 25, 2015 Cisco Systems, Inc. 6 P. Hancke 7 &yet 8 March 24, 2015 10 Domain Name Associations (DNA) in the Extensible Messaging and Presence 11 Protocol (XMPP) 12 draft-ietf-xmpp-dna-10 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 September 25, 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. No Mutual PKIX Authentication . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . 17 82 10.2. Informative References . . . . . . . . . . . . . . . . . 19 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 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. The Server Dialback protocol is defined 215 in [XEP-0220]. See [XEP-0344] for considerations when using it 216 together with TLS and DNSSEC. Also, [XEP-0288] provides a way to use 217 the server-to-server connections for bidirectional exchange of XML 218 stanzas which reduces the complexity of some of the processes 219 involved. 221 4.1. S2S Flow 223 The following flow chart illustrates the protocol flow for 224 establishing domain name associations between Server A (the 225 initiating entity) and Server B (the receiving entity), as described 226 in the remaining sections of this document. 228 | 229 (A Simple S2S Scenario) 230 | 231 DNS RESOLUTION ETC. 232 | 233 +-------------STREAM HEADERS--------------------+ 234 | | 235 | A: | 236 | | 237 | B: | 238 | | 239 +-----------------------------------------------+ 240 | 241 +-------------TLS NEGOTIATION-------------------+ 242 | | 243 | B: Server Certificate | 244 | B: Certificate Request | 245 | A: Client Certificate | 246 | | 247 +-----------------------------------------------+ 248 | 249 (A establishes DNA for b.example) 250 | 251 +-------------AUTHENTICATION--------------------+ 252 | | | 253 | {valid client certificate?} --+ | 254 | | | | 255 | | yes no | | 256 | v | | 257 | SASL EXTERNAL | | 258 | (mutual auth!) | | 259 | (B establishes DNA for a.example) | | 260 +-------------------------------------|---------+ 261 | 262 +-----------------+ 263 | B needs to establish DNA 264 | for this stream from a.example, 265 | so A asserts its identity 266 | 267 +----------DIALBACK IDENTITY ASSERTION----------+ 268 | | 269 | A: | 271 | some-dialback-key | 272 | | 273 | | 274 +-----------------------------------------------+ 275 | 276 (Section 4.3: No Mutual PKIX authentication) 277 | 278 DNS RESOLUTION ETC. 279 | 280 +-------------STREAM HEADERS--------------------+ 281 | | 282 | B: | 283 | | 284 | A: | 285 | | 286 +-----------------------------------------------+ 287 | 288 +-------------TLS NEGOTIATION-------------------+ 289 | | 290 | A: Server Certificate | 291 | | 292 +-----------------------------------------------+ 293 | 294 +----------DIALBACK IDENTITY VERIFICATION-------+ 295 | | 296 | B: | 299 | some-dialback-key | 300 | | 301 | | 302 | A: | 306 | | 307 +-----------------------------------------------+ 308 | 309 (B establishes DNA for a.example) 310 | 311 | 312 (Section 4.4.1: Piggybacking Assertion) 313 | 314 +----------DIALBACK IDENTITY ASSERTION----------+ 315 | | 316 | B: | 318 | | 319 +-----------------------------------------------+ 320 | 321 +-----------DNA DANCE AS ABOVE------------------+ 322 | | 323 | DNS RESOLUTION, STREAM HEADERS, | 324 | TLS NEGOTIATION, AUTHENTICATION | 325 | | 326 +-----------------------------------------------+ 327 | 328 +----------DIALBACK IDENTITY VERIFICATION-------+ 329 | | 330 | A: | 333 | | 334 +-----------------------------------------------+ 335 | 336 | 337 (Section 4.4.2: Piggybacking Supposition) 338 | 339 +-----------SUBSEQUENT CONNECTION---------------+ 340 | | 341 | B: | 343 | | 344 | A: | 346 | | 347 +-----------------------------------------------+ 348 | 349 +-----------DNA DANCE AS ABOVE------------------+ 350 | | 351 | DNS RESOLUTION, STREAM HEADERS, | 352 | TLS NEGOTIATION, AUTHENTICATION | 353 | | 354 +-----------------------------------------------+ 355 | 356 +-----------DIALBACK OPTIMIZATION---------------+ 357 | | 358 | B: | 360 | | 361 | B: | 364 | | 365 +-----------------------------------------------+ 366 | 368 4.2. A Simple S2S Scenario 370 To illustrate the problem, consider the simplified order of events 371 (see [RFC6120] for details) in establishing an XML stream between 372 Server A (a.example) and Server B (b.example): 374 1. Server A resolves via DNS the service _xmpp- 375 server._tcp.b.example. 377 2. Server A opens a TCP connection to the resolved IP address. 379 3. Server A sends an initial stream header to Server B, asserting 380 that it is a.example: 382 384 4. Server B sends a response stream header to Server A, asserting 385 that it is b.example: 387 389 5. The servers attempt TLS negotiation, during which Server B 390 (acting as a TLS server) presents a PKIX certificate proving that 391 it is b.example and Server A (acting as a TLS client) presents a 392 PKIX certificate proving that it is a.example. 394 6. Server A checks the PKIX certificate that Server B provided and 395 Server B checks the PKIX certificate that Server A provided; if 396 these proofs are consistent with the XMPP profile of the matching 397 rules from [RFC6125] and is otherwise valid according to 398 [RFC5280], each server accepts that there is a strong domain name 399 association between its stream to the other party and the DNS 400 domain name of the other party. 402 Several simplifying assumptions underlie the happy scenario just 403 outlined: 405 o The PKIX certificate presented by Server B during TLS negotiation 406 is trusted by Server A and matches the expected identity. 408 o The PKIX certificate presented by Server A during TLS negotiation 409 is trusted by Server B, which enables the parties to complete 410 mutual authentication. 412 o There are no additional domains associated with Server A and 413 Server B (say, a subdomain rooms.a.example on Server A or a second 414 domain c.example on Server B). 416 o The server administrators are able to obtain PKIX certificates 417 issued by a widely-accepted certificate authority (CA) in the 418 first place. 420 o The server administrators are running their own XMPP servers, 421 rather than using hosting services. 423 Let's consider each of these "wrinkles" in turn. Since Server A is 424 acting as a S2S client the behaviour is same as in the C2S case 425 described in Section 3.2. 427 4.3. No Mutual PKIX Authentication 429 If the PKIX certificate presented by Server A during TLS negotiation 430 is not trusted by Server B, Server B is unable to mutually 431 authenticate Server A. Therefore, Server B needs to verify the 432 asserted identity of Server A by other means. 434 1. Server A asserts it is a.example using the Server Dialback 435 protocol: 437 some- 438 dialback-key 440 2. Server B resolves via DNS the service _xmpp- 441 server._tcp.a.example. 443 3. Server B opens a TCP connection to the resolved IP address. 445 4. Server B sends an initial stream header to Server A, asserting 446 that it is b.example: 448 450 5. Server A sends a response stream header to Server B, asserting 451 that it is a.example: 453 455 6. The servers attempt TLS negotiation, during which Server A 456 (acting as a TLS server) presents a PKIX certificate proving that 457 it is a.example. 459 7. Server B checks the PKIX certificate that Server A provided. 460 This might be the same certificate presented by Server A as a 461 client certificate in the initial connection. See [XEP-0344] for 462 further discussion about skipping the subsequent steps. 464 8. Server B proceeds with Server Dialback in order to establish the 465 domain name association. In order to do this it sends a request 466 for verification as described in [XEP-0220]: 468 some- 469 dialback-key 471 9. Server A responds to this: 473 498 some-dialback-key 499 501 This element functions as Server B's assertion that it is (also) 502 c.example, and thus is functionally equivalent to the 'from' address 503 of an initial stream header as previously described. 505 In response to this assertion, Server A needs to obtain some kind of 506 proof that Server B really is also c.example. If the certificate 507 presented by Server B is also valid for c.example then no further 508 action is necessary. However, if not then Server A needs to do a bit 509 more work. Specifically, Server A can pursue the same strategy it 510 used before: 512 1. Server A resolves via DNS the service _xmpp- 513 server._tcp.c.example. 515 2. Server A opens a TCP connection to the resolved IP address (which 516 might be the same IP address as for b.example). 518 3. Server A sends an initial stream header to Server B, asserting 519 that it is a.example: 521 523 4. Server B sends a response stream header to Server A, asserting 524 that it is c.example: 526 528 5. The servers attempt TLS negotiation, during which Server B 529 (acting as a TLS server) presents a PKIX certificate proving that 530 it is c.example. 532 6. At this point, Server A needs to establish that, despite 533 different certificates, c.example is associated with the origin 534 of the request. This is done using Server Dialback [XEP-0220]: 536 some- 537 dialback-key 539 7. Server B responds to this: 541 550 The parties can then terminate the second connection, since it was 551 used only for Server A to associate a stream with the domain name 552 c.example (the dialback key links the original stream to the new 553 association). 555 4.4.2. Supposition 557 Piggybacking can also occur in the other direction. Consider the 558 common scenario in which Server A provides XMPP services not only for 559 a.example but also for a subdomain such as a groupchat service (e.g., 560 Multi-User Chat [XEP-0045]) at rooms.a.example. If a user from 561 c.example at Server B wishes to join a room on the groupchat sevice, 562 Server B needs to send XMPP stanzas from the domain c.example to the 563 domain rooms.a.example rather than a.example. First, Server B needs 564 to determine whether it can piggyback the domain rooms.a.example on 565 the connection to a.example: 567 1. Server B resolves vua DNS the service _xmpp- 568 server._tcp.rooms.a.example. 570 2. Server B determines this resolves to an IP address and port that 571 it is already connected to. 573 3. Server B determines that the PKIX certificate for that active 574 connection would also be valid for the rooms.a.example domain and 575 that Server A has announced support for dialback errors. 577 Server B sends a dialback key to Server A over the existing 578 connection. 580 581 some-dialback-key 582 584 Server A then informs Server B that it accepts the domain name 585 association: 587 589 5. Alternative Prooftypes 591 The foregoing protocol flows assumed that domain name associations 592 were proved using the PKI prooftype specified in [RFC6120]: that is, 593 the server's proof consists of a PKIX certificate that is checked 594 according to the XMPP profile [RFC6120] of the matching rules from 595 [RFC6125] (and the overall validation rules from [RFC5280]), the 596 client's verification material is obtained out of band in the form of 597 a trusted root, and secure DNS is not necessary. 599 However, sometimes XMPP server administrators are unable or unwilling 600 to obtain valid PKIX certificates for all of the domains they host at 601 their servers. For example: 603 o In order to issue a PKIX certificate, a CA might try to send email 604 messages to authoritative mailbox names [RFC2142], but the 605 administrator of a subsidiary service such as im.cs.podunk.example 606 cannot receive email sent to mailto:hostmaster@podunk.example. 608 o A hosting provider such as hosting.example.net might not want to 609 take on the liability of holding the certificate and private key 610 for a tenant such as example.com (or the tenant might not want the 611 hosting provider to hold its certificate and private key). 613 o Even if PKIX certificates for each tenant can be obtained, the 614 management of so many certificates can introduce a large 615 administrative load. 617 (Additional discussion can be found in [I-D.ietf-xmpp-posh].) 618 In these circumstances, prooftypes other than PKIX are desirable or 619 necessary. As described below, two alternatives have been defined so 620 far: DNS-Based Authentication of Named Entities (DANE) and PKIX Over 621 Secure HTTP (POSH). 623 5.1. DANE 625 The DANE prooftype can be defined as follows: 627 1. The server's proof consists of either a service certificate or 628 domain-issued certificate (TLSA usage PKIX-EE or DANE-EE, see 629 [RFC6698] and [RFC7218]). 631 2. The proof is checked by verifying an exact match or a hash of 632 either the SubjectPublicKeyInfo or the full certificate. 634 3. The client's verification material is obtained via secure DNS 635 [RFC4033] as described in [I-D.ietf-dane-srv]. 637 4. Secure DNS is necessary in order to effectively establish an 638 alternative chain of trust from the service certificate or 639 domain-issued certificate to the DNS root. 641 The DANE prooftype makes use of the DNS-Based Authentication of Named 642 Entities [RFC6698], specifically the use of DANE with DNS SRV records 643 [I-D.ietf-dane-srv]. For XMPP purposes, the following rules apply: 645 o If there is no SRV resource record, pursue the fallback methods 646 described in [RFC6120]. 648 o Use the 'to' address of the initial stream header to determine the 649 domain name of the TLS client's reference identifier (since use of 650 the Server Name Indication extension (TLS SNI) [RFC6066] is purely 651 discretionary in XMPP, as mentioned in [RFC6120]). 653 5.2. POSH 655 The POSH prooftype can be defined as follows: 657 1. The server's proof consists of a PKIX certificate. 659 2. The proof is checked according to the rules from [RFC6120] and 660 [RFC6125]. 662 3. The client's verification material is obtained by retrieving a 663 hash of the PKIX certificate over HTTPS at a well-known URI 664 [RFC5785]. 666 4. Secure DNS is not necessary since the HTTPS retrieval mechanism 667 relies on the chain of trust from the public key infrastructure. 669 POSH is defined in [I-D.ietf-xmpp-posh]. For XMPP purposes, the 670 following rules apply: 672 o If no verification materials are found via POSH, pursue the 673 fallback methods described in [RFC6120]. 675 o Use the 'to' address of the initial stream header to determine the 676 domain name of the TLS client's reference identifier (since use of 677 the Server Name Indication extension (TLS SNI) [RFC6066] is purely 678 discretionary in XMPP, as mentioned in [RFC6120]). 680 The well-known URIs [RFC5785] to be used for POSH are: 682 o "/.well-known/posh._xmpp-client._tcp.json" for client-to-server 683 connections 685 o "/.well-known/posh._xmpp-server._tcp.json" for server-to-server 686 connections 688 6. Secure Delegation and Multi-Tenancy 690 One common method for deploying XMPP services is multi-tenancy: e.g., 691 XMPP services for the service domain example.com are actually hosted 692 at the target server hosting.example.net. Such an arrangement is 693 relatively convenient in XMPP given the use of DNS SRV records 694 [RFC2782], such as the following delegation from example.com to 695 hosting.example.net: 697 _xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net 699 Secure connections with multi-tenancy can work using the PKIX 700 prooftype on a small scale if the provider itself wishes to host 701 several domains (e.g., related domains such as jabber-de.example and 702 jabber-ch.example). However, in practice the security of multi- 703 tenancy has been found to be unwieldy when the provider hosts large 704 numbers of XMPP services on behalf of multiple tenants (see 705 [I-D.ietf-xmpp-posh] for a detailed description). As a result, 706 server-to-server communications to example.com go unencrypted or the 707 communications are TLS-encrypted but the certificates are not checked 708 (which is functionally equivalent to a connection using an anonymous 709 key exchange). This is also true of client-to-server communications, 710 forcing end users to override certificate warnings or configure their 711 clients to accept or "pin" certificates for hosting.example.net 712 instead of example.com. The fundamental problem here is that if 713 DNSSEC is not used then the act of delegation via DNS SRV records is 714 inherently insecure. 716 The specification for use of SRV records with DANE 717 [I-D.ietf-dane-srv] explains how to use DNSSEC for secure delegation 718 with the DANE prooftype, and the POSH specification 719 [I-D.ietf-xmpp-posh] explains how to use HTTPS redirects for secure 720 delegation with the POSH prooftype. 722 7. Prooftype Model 724 In general, a domain name association (DNA) prooftype conforms to the 725 following definition: 727 prooftype: A mechanism for proving an association between a domain 728 name and an XML stream, where the mechanism defines (1) the nature 729 of the server's proof, (2) the matching rules for comparing the 730 client's verification material against the server's proof, (3) how 731 the client obtains its verification material, and (4) whether the 732 mechanism depends on secure DNS. 734 The PKIX, DANE, and POSH prooftypes adhere to this model. (Some 735 prooftypes depend on, or are enhanced by, secure DNS [RFC4033] and 736 thus also need to describe how they ensure secure delegation.) 738 Other prooftypes are possible; examples might include TLS with PGP 739 keys [RFC6091], a token mechanism such as Kerberos [RFC4120] or OAuth 740 [RFC6749], and Server Dialback keys [XEP-0220]. 742 Although the PKIX prooftype reuses the syntax of the XMPP Server 743 Dialback protocol [XEP-0220] for signalling between servers, this 744 framework document does not define how the generation and validation 745 of Server Dialback keys (also specified in [XEP-0220]) is a DNA 746 prooftype. However, nothing in this document prevents the continued 747 use of Server Dialback for signaling, and a future specification (or 748 an updated version of [XEP-0220]) might define a DNA prooftype for 749 Server Dialback keys in a way that is consistent with this framework. 751 8. IANA Considerations 753 The POSH specification [I-D.ietf-xmpp-posh] provides guidelines for 754 registering the well-known URIs [RFC5785] of protocols that make use 755 of POSH. This specification registers two such URIs, for which the 756 completed registration templates follow. 758 8.1. Well-Known URI for xmpp-client Service 760 This specification registers "posh._xmpp-client._tcp.json" in the 761 Well-Known URI Registry as defined by [RFC5785]. 763 URI suffix: posh._xmpp-client._tcp.json 765 Change controller: IETF 767 Specification document(s): [[ this document ]] 769 8.2. Well-Known URI for xmpp-server Service 771 This specification registers "posh._xmpp-server._tcp.json" in the 772 Well-Known URI Registry as defined by [RFC5785]. 774 URI suffix: posh._xmpp-server._tcp.json 776 Change controller: IETF 778 Specification document(s): [[ this document ]] 780 9. Security Considerations 782 With regard to the PKIX prooftype, this document supplements but does 783 not supersede the security considerations of [RFC6120] and [RFC6125]. 785 With regard to the DANE and PKIX prooftypes, the reader is referred 786 to [I-D.ietf-dane-srv] and [I-D.ietf-xmpp-posh], respectively. 788 Any future prooftypes need to thoroughly describe how they conform to 789 the prooftype model specified in Section 7 of this document. 791 10. References 793 10.1. Normative References 795 [I-D.ietf-dane-srv] 796 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 797 Based Authentication of Named Entities (DANE) TLSA Records 798 with SRV Records", draft-ietf-dane-srv-12 (work in 799 progress), March 2015. 801 [I-D.ietf-xmpp-posh] 802 Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP 803 (POSH)", draft-ietf-xmpp-posh-04 (work in progress), 804 February 2015. 806 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 807 STD 13, RFC 1034, November 1987. 809 [RFC1035] Mockapetris, P., "Domain names - implementation and 810 specification", STD 13, RFC 1035, November 1987. 812 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 813 specifying the location of services (DNS SRV)", RFC 2782, 814 February 2000. 816 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 817 Rose, "DNS Security Introduction and Requirements", RFC 818 4033, March 2005. 820 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 821 4949, August 2007. 823 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 824 Housley, R., and W. Polk, "Internet X.509 Public Key 825 Infrastructure Certificate and Certificate Revocation List 826 (CRL) Profile", RFC 5280, May 2008. 828 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 829 Uniform Resource Identifiers (URIs)", RFC 5785, April 830 2010. 832 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 833 Protocol (XMPP): Core", RFC 6120, March 2011. 835 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 836 Verification of Domain-Based Application Service Identity 837 within Internet Public Key Infrastructure Using X.509 838 (PKIX) Certificates in the Context of Transport Layer 839 Security (TLS)", RFC 6125, March 2011. 841 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 842 of Named Entities (DANE) Transport Layer Security (TLS) 843 Protocol: TLSA", RFC 6698, August 2012. 845 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 846 Conversations about DNS-Based Authentication of Named 847 Entities (DANE)", RFC 7218, April 2014. 849 [XEP-0220] 850 Miller, J., Saint-Andre, P., and P. Hancke, "Server 851 Dialback", XSF XEP 0220, August 2014. 853 10.2. Informative References 855 [I-D.ietf-uta-xmpp] 856 Saint-Andre, P. and a. alkemade, "Use of Transport Layer 857 Security (TLS) in the Extensible Messaging and Presence 858 Protocol (XMPP)", draft-ietf-uta-xmpp-05 (work in 859 progress), January 2015. 861 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 862 FUNCTIONS", RFC 2142, May 1997. 864 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 865 Protocol (XMPP): Core", RFC 3920, October 2004. 867 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 868 Kerberos Network Authentication Service (V5)", RFC 4120, 869 July 2005. 871 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 872 Extension Definitions", RFC 6066, January 2011. 874 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 875 for Transport Layer Security (TLS) Authentication", RFC 876 6091, February 2011. 878 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 879 6749, October 2012. 881 [XEP-0045] 882 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 883 2012. 885 [XEP-0288] 886 Hancke, P. and D. Cridland, "Bidirectional Server-to- 887 Server Connections", XSF XEP 0288, September 2013. 889 [XEP-0344] 890 Hancke, P. and D. Cridland, "Impact of TLS and DNSSEC on 891 Dialback", XSF XEP 0344, March 2015. 893 Appendix A. Acknowledgements 895 Thanks to Richard Barnes, Stephen Farrell, and Jonas Lindberg for 896 contributing to earlier versions of this document. 898 Authors' Addresses 900 Peter Saint-Andre 901 &yet 903 Email: peter@andyet.com 904 URI: https://andyet.com/ 906 Matthew Miller 907 Cisco Systems, Inc. 908 1899 Wynkoop Street, Suite 600 909 Denver, CO 80202 910 USA 912 Email: mamille2@cisco.com 914 Philipp Hancke 915 &yet 917 Email: fippo@andyet.com 918 URI: https://andyet.com/