-
Notifications
You must be signed in to change notification settings - Fork 5
/
rfc7712.xml
1193 lines (1025 loc) · 49.2 KB
/
rfc7712.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 SYSTEM "reference.RFC.1034.xml">
<!ENTITY rfc1035 SYSTEM "reference.RFC.1035.xml">
<!ENTITY rfc2142 SYSTEM "reference.RFC.2142.xml">
<!ENTITY rfc2782 SYSTEM "reference.RFC.2782.xml">
<!ENTITY rfc3920 SYSTEM "reference.RFC.3920.xml">
<!ENTITY rfc4033 SYSTEM "reference.RFC.4033.xml">
<!ENTITY rfc4120 SYSTEM "reference.RFC.4120.xml">
<!ENTITY rfc4422 SYSTEM "reference.RFC.4422.xml">
<!ENTITY rfc4949 SYSTEM "reference.RFC.4949.xml">
<!ENTITY rfc5280 SYSTEM "reference.RFC.5280.xml">
<!ENTITY rfc5785 SYSTEM "reference.RFC.5785.xml">
<!ENTITY rfc6066 SYSTEM "reference.RFC.6066.xml">
<!ENTITY rfc6091 SYSTEM "reference.RFC.6091.xml">
<!ENTITY rfc6120 SYSTEM "reference.RFC.6120.xml">
<!ENTITY rfc6125 SYSTEM "reference.RFC.6125.xml">
<!ENTITY rfc6698 SYSTEM "reference.RFC.6698.xml">
<!ENTITY rfc6749 SYSTEM "reference.RFC.6749.xml">
<!ENTITY rfc7218 SYSTEM "reference.RFC.7218.xml">
<!ENTITY rfc7590 SYSTEM "reference.RFC.7590.xml">
<!ENTITY rfc7673 SYSTEM "reference.RFC.7673.xml">
]>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<rfc category="std" number="7712" ipr="trust200902" submissionType="IETF" consensus="yes">
<front>
<title abbrev="XMPP DNA">Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>&yet</organization>
<address>
<email>[email protected]</email>
<uri>https://andyet.com/</uri>
</address>
</author>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>United States</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="P." surname="Hancke" fullname="Philipp Hancke">
<organization>&yet</organization>
<address>
<email>[email protected]</email>
<uri>https://andyet.com/</uri>
</address>
</author>
<date month="November" year="2015"/>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>federation</keyword>
<keyword>delegation</keyword>
<keyword>security</keyword>
<abstract>
<t>This document improves the security of the Extensible Messaging and
Presence Protocol (XMPP) in two ways. First, it specifies how to
establish a strong association between a domain name and an XML stream,
using the concept of "prooftypes". Second, it describes how to securely
delegate a service domain name (e.g., example.com) to a target server
hostname (e.g., hosting.example.net); this is especially important in
multi-tenanted environments where the same target server hosts a large
number of domains.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>In systems that use the Extensible Messaging and Presence Protocol
(XMPP) <xref target='RFC6120'/>, it is important to establish a strong
association between the DNS domain name of an XMPP service (e.g.,
example.com) and the XML stream that a client or peer server initiates
with that service. In other words, the client or peer server needs to
verify the identity of the server to which it connects. Additionally,
servers need to verify incoming connections from other servers.</t>
<t>To date, such verification has been established based on information
obtained from the Domain Name System (DNS), the Public Key
Infrastructure (PKI), or similar sources. In particular, XMPP as
defined in <xref target='RFC6120'/> assumed that Domain Name
Associations (DNA) are to be proved using the "PKIX prooftype";
that is, the server's proof consists of a PKIX certificate that is
checked according to the XMPP profile of the matching rules from
<xref target='RFC6125'/> (and the overall validation rules from
<xref target='RFC5280'/>), the client's verification material is
obtained out of band in the form of a trusted root, and secure DNS
is not necessary.</t>
<t>By extending the concept of a domain name association within XMPP,
this document does the following:</t>
<t>
<list style='numbers'>
<t>Generalizes the model currently in use so that additional
prooftypes can be defined if needed.</t>
<t>Provides a basis for modernizing some prooftypes to reflect
progress in underlying technologies such as DNS Security <xref
target="RFC4033"/>.</t>
<t>Describes the flow of operations for establishing a domain name
association.</t>
</list>
</t>
<t>This document also provides guidelines for secure delegation of a
service domain name (e.g., example.com) to a target server hostname
(e.g., hosting.example.net). The need for secure delegation arises
because the process for resolving the domain name of an XMPP service
into the IP address at which an XML stream will be negotiated (see <xref
target='RFC6120'/>) can involve delegation of a service domain name to a
target server hostname using technologies such as DNS SRV records <xref
target='RFC2782'/>. A more detailed description of the delegation
problem can be found in <xref target='RFC7711'/>. The domain
name association can be verified only if the delegation is done in a
secure manner.</t>
</section>
<section title="Terminology" anchor="terms">
<t>This document inherits XMPP terminology from <xref target="RFC6120"/>
and <xref target="XEP-0220"/>; DNS terminology from <xref
target="RFC1034"/>, <xref target="RFC1035"/>, <xref target="RFC2782"/>,
and <xref target="RFC4033"/>; and security terminology from <xref
target="RFC4949"/> and <xref target="RFC5280"/>. The terms "reference
identity" and "presented identity" are used as defined in the "CertID"
specification <xref target="RFC6125"/>. For the sake of consistency
with <xref target='RFC7673'/>, this document uses the terms
"service domain name" and "target server hostname" to refer to the same
entities identified by the terms "source domain" and "derived domain"
from <xref target='RFC6125'/>.</t>
</section>
<section title="Client-to-Server (C2S) DNA" anchor="c2s">
<t>The client-to-server case is much simpler than the server-to-server
case because the client does not assert a domain name; this means
that verification happens in only one direction. Therefore, we
describe this case first to help the reader understand
domain name associations in XMPP.</t>
<section title="C2S Flow" anchor="c2s-flow">
<t>The following flow chart illustrates the protocol flow for
establishing a domain name association for an XML stream from a client
(C) to a server (S) using the standard PKIX prooftype specified in
<xref target="RFC6120"/>.</t>
<figure>
<artwork><![CDATA[
|
DNS RESOLUTION ETC.
|
+-----------------STREAM HEADERS---------------------+
| |
| C: <stream to='a.example'> |
| |
| S: <stream from='a.example'> |
| |
+----------------------------------------------------+
|
+-----------------TLS NEGOTIATION--------------------+
| |
| S: Server Certificate |
| |
+----------------------------------------------------+
|
(client checks certificate and
establishes DNA for a.example)
]]></artwork>
</figure>
</section>
<section title="C2S Description" anchor="c2s-description">
<t>The simplified order of events (see <xref target='RFC6120'/> for
details) in establishing an XML stream from a client ([email protected])
to a server (a.example) is as follows:</t>
<t>
<list style='numbers'>
<t>The client resolves via DNS the service
<vspace/>
_xmpp-client._tcp.a.example.</t>
<t>The client opens a TCP connection to the resolved IP
address.</t>
<t>
The client sends an initial stream header to the server:
<vspace blankLines='1'/>
<stream:stream to='a.example'>
</t>
<t>
The server sends a response stream header to the client,
asserting that it is a.example:
<vspace blankLines='1'/>
<stream:stream from='a.example'>
</t>
<t>The parties attempt TLS negotiation, during which the XMPP
server (acting as a TLS server) presents a PKIX certificate
proving that it is a.example.</t>
<t>The client checks the PKIX certificate that the server
provided; if the proof is consistent with the XMPP profile of the
matching rules from <xref target='RFC6125'/> and the certificate
is otherwise valid according to <xref target='RFC5280'/>, the
client accepts that there is a strong domain name association
between its stream to the target server and the DNS domain name of
the XMPP service.</t>
</list>
</t>
<t>The certificate that the server presents might not be acceptable to
the client. As one example, the server might be hosting multiple
domains and secure delegation as described in <xref
target='delegation'/> is necessary. As another example, the server
might present a self-signed certificate, which requires the client to
either (1) apply the fallback process described in
Section 6.6.4 of <xref target='RFC6125'/> or (2) prompt
the user to accept an unauthenticated connection as described in
Section 3.4 of <xref target='RFC7590'/>.</t>
</section>
</section>
<section title="Server-to-Server (S2S) DNA" anchor="s2s">
<t>The server-to-server case is significantly more complex than the
client-to-server case, and it involves the checking of
domain name associations in both directions along with other
"wrinkles" described in the following sections. In some parts of
the flow, server-to-server communications use the Server Dialback
protocol first specified in (the now obsolete) <xref target='RFC3920'/>
and since moved to <xref target='XEP-0220'/>. See "Impact of TLS
and DNSSEC on Dialback" <xref target='XEP-0344'/> for considerations
when using it together with TLS and DNSSEC. Also, "Bidirectional
Server-to-Server Connections" <xref target='XEP-0288'/> provides a
way to use the server-to-server connections for bidirectional
exchange of XML stanzas, which reduces the complexity of some of
the processes involved.</t>
<section title="S2S Flow" anchor="s2s-flow">
<t>The following flow charts illustrate the protocol flow for
establishing domain name associations between Server 1 (the initiating
entity) and Server 2 (the receiving entity), as described in the
remaining sections of this document.</t>
<t>A simple S2S scenario would be as follows:</t>
<figure>
<artwork><![CDATA[
|
DNS RESOLUTION ETC.
|
+-------------STREAM HEADERS--------------------+
| |
| A: <stream from='a.example' to='b.example'> |
| |
| B: <stream from='b.example' to='a.example'> |
| |
+-----------------------------------------------+
|
+-------------TLS NEGOTIATION-------------------+
| |
| B: Server Certificate |
| B: Certificate Request |
| A: Client Certificate |
| |
+-----------------------------------------------+
|
(A establishes DNA for b.example)
|
]]></artwork>
</figure>
<t>After the domain name association has been established in one
direction, it is possible to perform mutual authentication using
the Simple Authentication and Security Layer (SASL) <xref
target='RFC4422'/> and thus establish domain name associations in
both directions.</t>
<figure>
<artwork><![CDATA[
|
+-------------AUTHENTICATION--------------------+
| | |
| {valid client certificate?} --+ |
| | | |
| | yes no | |
| v | |
| SASL EXTERNAL | |
| (mutual auth) | |
| (B establishes DNA for a.example) | |
+-------------------------------------|---------+
|
]]></artwork>
</figure>
<t>However, if mutual authentication cannot be completed using SASL,
the receiving server needs to establish a domain name association in
another way. This scenario is described in <xref
target='s2s-notsimple'/>.</t>
<figure>
<artwork><![CDATA[
|
+-----------------+
|
(Section 4.3: No Mutual PKIX Authentication)
|
| B needs to establish DNA
| for this stream from a.example,
| so A asserts its identity
|
+----------DIALBACK IDENTITY ASSERTION----------+
| |
| A: <db:result from='a.example' |
| to='b.example'> |
| some-dialback-key |
| </db:result> |
| |
+-----------------------------------------------+
|
DNS RESOLUTION ETC.
|
+-------------STREAM HEADERS--------------------+
| |
| B: <stream from='b.example' to='a.example'> |
| |
| A: <stream from='a.example' to='b.example'> |
| |
+-----------------------------------------------+
|
+-------------TLS NEGOTIATION-------------------+
| |
| A: Server Certificate |
| |
+-----------------------------------------------+
|
+----------DIALBACK IDENTITY VERIFICATION-------+
| |
| B: <db:verify from='b.example' |
| to='a.example' |
| id='...'> |
| some-dialback-key |
| </db:verify> |
| |
| A: <db:verify from='a.example' |
| to='b.example' |
| type='valid' |
| id='...'> |
| |
+-----------------------------------------------+
|
(B establishes DNA for a.example)
|
]]></artwork>
</figure>
<t>If one of the servers hosts additional service names (e.g., Server
2 might host c.example in addition to b.example and Server 1 might
host rooms.a.example in addition to a.example), then the servers can
use Server Dialback "piggybacking" to establish additional domain name
associations for the stream, as described in <xref
target='s2s-piggybacking'/>.</t>
<t>There are two varieties of piggybacking. The first is here called
"assertion".</t>
<figure>
<artwork><![CDATA[
|
(Section 4.4.1: Piggybacking Assertion)
|
+----------DIALBACK IDENTITY ASSERTION----------+
| |
| B: <db:result from='c.example' |
| to='a.example'/> |
| |
+-----------------------------------------------+
|
+-------DNA ESTABLISHMENT AS ABOVE--------------+
| |
| DNS RESOLUTION, STREAM HEADERS, |
| TLS NEGOTIATION, AUTHENTICATION |
| |
+-----------------------------------------------+
|
+----------DIALBACK IDENTITY VERIFICATION-------+
| |
| A: <db:result from='a.example' |
| to='c.example' |
| type='valid'/> |
| |
+-----------------------------------------------+
|
]]></artwork>
</figure>
<t>The second variety of piggybacking is here called "supposition".</t>
<figure>
<artwork><![CDATA[
|
(Section 4.4.2: Piggybacking Supposition)
|
+-----------SUBSEQUENT CONNECTION---------------+
| |
| B: <stream from='c.example' |
| to='rooms.a.example'> |
| |
| A: <stream from='rooms.a.example' |
| to='c.example'> |
| |
+-----------------------------------------------+
|
+-------DNA ESTABLISHMENT AS ABOVE--------------+
| |
| DNS RESOLUTION, STREAM HEADERS, |
| TLS NEGOTIATION, AUTHENTICATION |
| |
+-----------------------------------------------+
|
+-----------DIALBACK OPTIMIZATION---------------+
| |
| B: <db:result from='c.example' |
| to='rooms.a.example'/> |
| |
| B: <db:result from='rooms.a.example' |
| to='c.example' |
| type='valid'/> |
| |
+-----------------------------------------------+
]]></artwork>
</figure>
</section>
<section title="A Simple S2S Scenario" anchor="s2s-simple">
<t>To illustrate the problem, consider the simplified order of events
(see <xref target='RFC6120'/> for details) in establishing an XML
stream between Server 1 (a.example) and Server 2 (b.example):</t>
<t>
<list style='numbers'>
<t>Server 1 resolves via DNS the service
<vspace/>
_xmpp-server._tcp.b.example.</t>
<t>Server 1 opens a TCP connection to the resolved IP address.</t>
<t>
Server 1 sends an initial stream header to Server 2, asserting
that it is a.example:
<vspace blankLines='1'/>
<stream:stream from='a.example' to='b.example'>
</t>
<t>
Server 2 sends a response stream header to Server 1, asserting
that it is b.example:
<vspace blankLines='1'/>
<stream:stream from='b.example' to='a.example'>
</t>
<t>The servers attempt TLS negotiation, during which Server 2
(acting as a TLS server) presents a PKIX certificate proving that
it is b.example and Server 1 (acting as a TLS client) presents a
PKIX certificate proving that it is a.example.</t>
<t>Server 1 checks the PKIX certificate that Server 2 provided,
and Server 2 checks the PKIX certificate that Server 1 provided;
if these proofs are consistent with the XMPP profile of the
matching rules from <xref target='RFC6125'/> and are otherwise
valid according to <xref target='RFC5280'/>, each server accepts
that there is a strong domain name association between its
stream to the other party and the DNS domain name of the other
party (i.e., mutual authentication is achieved).</t>
</list>
</t>
<t>Several simplifying assumptions underlie the "happy path" scenario
just outlined:</t>
<t>
<list style='symbols'>
<t>The PKIX certificate presented by Server 2 during TLS
negotiation is acceptable to Server 1 and matches the expected
identity.</t>
<t>The PKIX certificate presented by Server 1 during TLS
negotiation is acceptable to Server 2; this enables the parties
to complete mutual authentication.</t>
<t>There are no additional domains associated with Server 1 and
Server 2 (say, a sub&nbhy;domain rooms.a.example on Server 1
or a second domain c.example on Server 2).</t>
<t>The server administrators are able to obtain PKIX certificates
issued by a widely accepted Certification Authority (CA) in the
first place.</t>
<t>The server administrators are running their own XMPP servers,
rather than using hosting services.</t>
</list>
</t>
<t>Let's consider each of these "wrinkles" in turn.
</t>
</section>
<section title="No Mutual PKIX Authentication" anchor="s2s-notsimple">
<t>If the PKIX certificate presented by Server 1 during TLS
negotiation is not acceptable to Server 2, Server 2 is unable to
mutually authenticate Server 1. Therefore, Server 2 needs to verify
the asserted identity of Server 1 by other means.</t>
<t>
<list style='numbers'>
<t>
Server 1 asserts that it is a.example using the Server Dialback
protocol:
<figure><artwork><![CDATA[
<db:result from='a.example' to='b.example'>
some-dialback-key</db:result>
]]></artwork></figure>
</t>
<t>Server 2 resolves via DNS the service
<vspace/>
_xmpp-server._tcp.a.example.</t>
<t>Server 2 opens a TCP connection to the resolved IP address.</t>
<t>
Server 2 sends an initial stream header to Server 1, asserting
that it is b.example:
<vspace blankLines='1'/>
<stream:stream from='b.example' to='a.example'>
</t>
<t>
Server 1 sends a response stream header to Server 2, asserting
that it is a.example:
<vspace blankLines='1'/>
<stream:stream from='a.example' to='b.example'>
</t>
<t>The servers attempt TLS negotiation, during which Server 1
(acting as a TLS server) presents a PKIX certificate.</t>
<t>Server 2 checks the PKIX certificate that Server 1 provided
(this might be the same certificate presented by Server 1 as a
client certificate in the initial connection). However, Server 2
does not accept this certificate as proving that Server 1 is
authorized as a.example and therefore uses another method (here,
the Server Dialback protocol) to establish the domain name
association.</t>
<t>
Server 2 proceeds with Server Dialback in order to establish the
domain name association. In order to do this, it sends a request
for verification as described in <xref target='XEP-0220'/>:
<figure><artwork><![CDATA[
<db:verify from='b.example' to='a.example'
id='...'>some-dialback-key</db:verify>
]]></artwork></figure>
</t>
<t>
Server 1 responds to this:
<vspace blankLines='1'/>
<db:verify from='a.example' to='b.example' id='...'
type='valid/>
<vspace blankLines='1'/>
allowing Server 2 to establish the domain name association.
</t>
</list>
</t>
<t>In some situations (e.g., if the Authoritative Server in Server
Dialback presents the same certificate as the Originating Server), it
is the practice of some XMPP server implementations to skip steps 8
and 9. These situations are discussed in "Impact of TLS and DNSSEC on
Dialback" <xref target='XEP-0344'/>.</t>
</section>
<section title="Piggybacking" anchor="s2s-piggybacking">
<section title="Assertion" anchor="s2s-piggybacking-assertion">
<t>Consider the common scenario in which Server 2 hosts not only
b.example but also a second domain c.example (often called a
"multi&nbhy;tenanted" environment). If a user of Server 2 associated
with c.example wishes to communicate with a friend at a.example,
Server 2 needs to send XMPP stanzas from the domain c.example rather
than b.example. Although Server 2 could open a new TCP connection
and negotiate new XML streams for the domain pair of c.example and
a.example, that is wasteful (especially if Server 2 hosts a large
number of domains). Server 2 already has a connection to a.example,
so how can it assert that it would like to add a new domain pair to
the existing connection?</t>
<t>The traditional method for doing so is the Server Dialback
protocol <xref target='XEP-0220'/>. Here, Server 2 can send a
<db:result/> element for the new domain pair over the existing
stream.</t>
<figure>
<artwork><![CDATA[
<db:result from='c.example' to='a.example'>
some-dialback-key
</db:result>
]]></artwork>
</figure>
<t>This <db:result/> element functions as Server 2's
assertion that it is (also) c.example (thus, the element is
functionally equivalent to the 'from' address of an initial
stream header as previously described).</t>
<t>In response to this assertion, Server 1 needs to obtain some kind
of proof that Server 2 really is also c.example. If the certificate
presented by Server 2 is also valid for c.example, then no further
action is necessary. However, if not, then Server 1 needs to do a
bit more work. Specifically, Server 1 can pursue the same strategy
it used before:</t>
<t>
<list style='numbers'>
<t>Server 1 resolves via DNS the service
<vspace/>
_xmpp-server._tcp.c.example.</t>
<t>Server 1 opens a TCP connection to the resolved IP address
(which might be the same IP address as for b.example).</t>
<t>
Server 1 sends an initial stream header to Server 2, asserting
that it is a.example:
<vspace blankLines='1'/>
<stream:stream from='a.example' to='c.example'>
</t>
<t>
Server 2 sends a response stream header to Server 1, asserting
that it is c.example:
<vspace blankLines='1'/>
<stream:stream from='c.example' to='a.example'>
</t>
<t>The servers attempt TLS negotiation, during which Server 2
(acting as a TLS server) presents a PKIX certificate proving
that it is c.example.</t>
<t>
At this point, Server 1 needs to establish that, despite
different certificates, c.example is associated with the
origin of the request. This is done using Server Dialback
<xref target='XEP-0220'/>:
<figure><artwork><![CDATA[
<db:verify from='a.example' to='c.example'
id='...'>some-dialback-key</db:verify>
]]></artwork></figure>
</t>
<t>
Server 2 responds to this:
<vspace blankLines='1'/>
<db:verify from='c.example' to='a.example' id='...'
type='valid/>
<vspace blankLines='1'/>
allowing Server 1 to establish the domain name association.
</t>
</list>
</t>
<t>Now that Server 1 accepts the domain name association, it informs
Server 2 of that fact:</t>
<figure>
<artwork><![CDATA[
<db:result from='a.example' to='c.example' type='valid'/>
]]></artwork>
</figure>
<t>The parties can then terminate the second connection, because it
was used only for Server 1 to associate a stream with the domain
name c.example (the dialback key links the original stream to the
new association).</t>
</section>
<section title="Supposition" anchor="s2s-piggybacking-supposition">
<t>Piggybacking can also occur in the other direction. Consider the
common scenario in which Server 1 provides XMPP services not only
for a.example but also for a sub&nbhy;domain such as a
Multi&nbhy;User Chat <xref target='XEP-0045'/> service at
rooms.a.example. If a user from c.example at Server 2 wishes to
join a room on the groupchat service, Server 2 needs to send
XMPP stanzas from the domain c.example to the domain
rooms.a.example rather than a.example.</t>
<t>First, Server 2 needs to determine whether it can
piggyback the domain rooms.a.example on the connection to
a.example:</t>
<t>
<list style='numbers'>
<t>Server 2 resolves via DNS the service
<vspace/>
_xmpp-server._tcp.rooms.a.example.</t>
<t>Server 2 determines that this resolves to an IP address
and port to which it is already connected.</t>
<t>Server 2 determines that the PKIX certificate for that active
connection would also be valid for the rooms.a.example domain
and that Server 1 has announced support for dialback errors.</t>
</list>
</t>
<t>Server 2 sends a dialback key to Server 1 over the existing
connection:</t>
<figure>
<artwork><![CDATA[
<db:result from='c.example' to='rooms.a.example'>
some-dialback-key
</db:result>
]]></artwork>
</figure>
<t>Server 1 then informs Server 2 that it accepts the domain name
association:</t>
<figure>
<artwork><![CDATA[
<db:result from='rooms.a.example' to='c.example' type='valid'/>
]]></artwork>
</figure>
</section>
</section>
</section>
<section title="Alternative Prooftypes" anchor="alternatives">
<t>The foregoing protocol flows assumed that domain name associations
were proved using the PKIX prooftype. However, sometimes XMPP server
administrators are unable or unwilling to obtain valid PKIX certificates
for all of the domains they host at their servers. For example:</t>
<t>
<list style='symbols'>
<t>In order to issue a PKIX certificate, a CA might try to send
email messages to authoritative mailbox names <xref
target='RFC2142'/>, but the administrator of a subsidiary service
such as im.cs.podunk.example cannot receive email sent to
[email protected].</t>
<t>A hosting provider such as hosting.example.net might not want to
take on the liability of holding the certificate and private key for
a tenant such as example.com (or the tenant might not want the
hosting provider to hold its certificate and private key).</t>
<t>Even if PKIX certificates for each tenant can be obtained, the
management of so many certificates can introduce a large
administrative load.</t>
</list>
</t>
<t>(Additional discussion can be found in <xref
target='RFC7711'/>.)</t>
<t>In these circumstances, prooftypes other than PKIX are desirable or
necessary. As described below, two alternatives have been defined so
far: DNS-Based Authentication of Named Entities (DANE) and PKIX over
Secure HTTP (POSH).</t>
<section title="DANE" anchor="alternatives-dane">
<t>The DANE prooftype is defined as follows:</t>
<t>
<list style='numbers'>
<t>The server's proof consists of either a service certificate or
domain-issued certificate (TLSA usage PKIX-EE or DANE-EE; see
<xref target='RFC6698'/> and <xref target='RFC7218'/>).</t>
<t>The proof is checked by verifying an exact match or a hash of
either the SubjectPublicKeyInfo or the full certificate.</t>
<t>The client's verification material is obtained via secure DNS
<xref target="RFC4033"/> as described in <xref
target='RFC7673'/>.</t>
<t>Secure DNS is necessary in order to effectively establish an
alternative chain of trust from the service certificate or
domain-issued certificate to the DNS root.</t>
</list>
</t>
<t>The DANE prooftype makes use of DNS-Based Authentication of Named
Entities <xref target='RFC6698'/>, specifically the use of DANE with
DNS SRV records <xref target='RFC7673'/>. For XMPP
purposes, the following rules apply:</t>
<t>
<list style='symbols'>
<t>If there is no SRV resource record, pursue the fallback methods
described in <xref target='RFC6120'/>.</t>
<t>Use the 'to' address of the initial stream header to determine
the domain name of the TLS client's reference identifier (because
the use of the Server Name Indication extension (TLS SNI) <xref
target='RFC6066'/> is purely discretionary in XMPP, as mentioned
in <xref target='RFC6120'/>).</t>
</list>
</t>
</section>
<section title="POSH" anchor="alternatives-posh">
<t>The POSH prooftype is defined as follows:</t>
<t>
<list style='numbers'>
<t>The server's proof consists of a PKIX certificate.</t>
<t>The proof is checked according to the rules from <xref
target='RFC6120'/> and <xref target='RFC6125'/>.</t>
<t>The client's verification material is obtained by retrieving a
hash of the PKIX certificate over HTTPS at a well-known URI <xref
target='RFC5785'/>.</t>
<t>Secure DNS is not necessary, because the HTTPS retrieval
mechanism relies on the chain of trust from the public key
infrastructure.
</t>
</list>
</t>
<t>POSH is defined in <xref target='RFC7711'/>. For XMPP purposes,
the following rules apply:</t>
<t>
<list style='symbols'>
<t>If no verification material is found via POSH, pursue the
fallback methods described in <xref target='RFC6120'/>.</t>
<t>Use the 'to' address of the initial stream header to determine
the domain name of the TLS client's reference identifier
(because the use of TLS SNI <xref target='RFC6066'/> is purely
discretionary in XMPP, as mentioned in
<xref target='RFC6120'/>).</t>
</list>
</t>
<t>The well-known URIs <xref target='RFC5785'/> to be used for POSH
are:</t>
<t>
<list style='symbols'>
<t>"/.well-known/posh/xmpp-client.json" for client-to-server
connections</t>
<t>"/.well-known/posh/xmpp-server.json" for server-to-server
connections</t>
</list>
</t>
</section>
</section>
<section title="Secure Delegation and Multi-Tenancy" anchor="delegation">
<t>One common method for deploying XMPP services is multi-tenancy: e.g.,
XMPP services for the service domain name example.com are actually
hosted at the target server hosting.example.net. Such an arrangement is
relatively convenient in XMPP given the use of DNS SRV records <xref
target='RFC2782'/>, such as the following delegation from example.com to
hosting.example.net:</t>
<figure>
<artwork><![CDATA[
_xmpp-server._tcp.example.com. 0 IN SRV 0 0 5269 hosting.example.net
]]></artwork>
</figure>
<t>Secure connections with multi-tenancy can work using the PKIX
prooftype on a small scale if the provider itself wishes to host several
domains (e.g., related domains such as jabber-de.example and
jabber-ch.example). However, in practice the security of
multi&nbhy;tenancy has been found to be unwieldy when the provider
hosts large numbers of XMPP services on behalf of multiple tenants
(see <xref target='RFC7711'/> for a detailed description). There
are two possible results: either (1) server-to-server
communications to example.com are unencrypted or (2) the
communications are TLS&nbhy;encrypted but the certificates are not
checked (which is functionally equivalent to a connection using an
anonymous key exchange). This is also true of client-to-server communications,
forcing end users to override certificate warnings or configure their
clients to accept or "pin" certificates for hosting.example.net instead
of example.com. The fundamental problem here is that if DNSSEC is not
used, then the act of delegation via DNS SRV records is inherently
insecure.</t>
<t>The specification for the use of SRV records with DANE <xref
target='RFC7673'/> explains how to use DNSSEC for secure
delegation with the DANE prooftype, and the POSH specification <xref
target='RFC7711'/> explains how to use HTTPS redirects for
secure delegation with the POSH prooftype.</t>
</section>
<section title="Prooftype Model" anchor="model">
<t>In general, a Domain Name Association (DNA) prooftype conforms to the
following definition:</t>
<t><list style="hanging">
<t hangText="prooftype:">A mechanism for proving an association
between a domain name and an XML stream, where the mechanism defines
(1) the nature of the server's proof, (2) the matching rules for
comparing the client's verification material against the server's
proof, (3) how the client obtains its verification material, and
(4) whether or not the mechanism depends on secure DNS.</t>
</list></t>
<t>The PKIX, DANE, and POSH prooftypes adhere to this model. (Some
prooftypes depend on, or are enhanced by, secure DNS <xref
target="RFC4033"/> and thus also need to describe how they ensure secure
delegation.)</t>
<t>Other prooftypes are possible; examples might include TLS with
Pretty Good Privacy (PGP) keys <xref target='RFC6091'/>,
a token mechanism such as Kerberos <xref target='RFC4120'/> or
OAuth <xref target='RFC6749'/>, and Server Dialback
keys <xref target='XEP-0220'/>.</t>
<t>Although the PKIX prooftype reuses the syntax of the XMPP Server
Dialback protocol <xref target='XEP-0220'/> for signaling between
servers, this framework document does not define how the generation
and validation of Server Dialback keys (also specified in <xref
target='XEP-0220'/>) constitute a DNA prooftype. However, nothing in
this document prevents the continued use of Server Dialback for
signaling, and a future specification (or an updated version of <xref
target='XEP-0220'/>) might define a DNA prooftype for Server Dialback
keys in a way that is consistent with this framework.</t>
</section>
<section title="Guidance for Server Operators" anchor="ops">
<t>This document introduces the concept of a prooftype in order to
explain and generalize the approach to establishing a strong association
between the DNS domain name of an XMPP service and the XML stream that a
client or peer server initiates with that service.</t>
<t>The operations and management implications of DNA prooftypes will
depend on the particular prooftypes that an operator supports. For
example:</t>
<t>
<list style='symbols'>
<t>To support the PKIX prooftype <xref target='RFC6120'/>, an
operator needs to obtain certificates for the XMPP server from a
Certification Authority (CA). However, DNS Security is not
required.</t>
<t>To support the DANE prooftype <xref target='RFC7673'/>,
an operator can generate its own certificates for the XMPP server or
obtain them from a CA. In addition, DNS Security is required.</t>
<t>To support the POSH prooftype <xref
target='RFC7711'/>, an operator can generate its own
certificates for the XMPP server or obtain them from a CA, but in
addition needs to deploy the web server for POSH files with
certificates obtained from a CA. However, DNS Security is not
required.</t>
</list>
</t>
<t>Considerations for the use of the foregoing prooftypes are
explained in the relevant specifications. See in particular
Section 13.7 of <xref target='RFC6120'/>,
Section 6 of <xref target='RFC7673'/>, and
Section 7 of <xref target='RFC7711'/>.</t>