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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
|
<pre>Internet Engineering Task Force (IETF) N. Cam-Winget, Ed.
Request for Comments: 8600 S. Appala
Category: Standards Track S. Pope
ISSN: 2070-1721 Cisco Systems
P. Saint-Andre
Mozilla
June 2019
<span class="h1">Using Extensible Messaging and Presence Protocol (XMPP)</span>
<span class="h1">for Security Information Exchange</span>
Abstract
This document describes how to use the Extensible Messaging and
Presence Protocol (XMPP) to collect and distribute security incident
reports and other security-relevant information between network-
connected devices, primarily for the purpose of communication among
Computer Security Incident Response Teams and associated entities.
To illustrate the principles involved, this document describes such a
usage for the Incident Object Description Exchange Format (IODEF).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8600">https://www.rfc-editor.org/info/rfc8600</a>.
<span class="grey">Cam-Winget, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Architecture . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Service Discovery . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6">6</a>. Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8.1">8.1</a>. Trust Model . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8.2">8.2</a>. Threat Model . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-8.3">8.3</a>. Countermeasures . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-8.4">8.4</a>. Summary . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-9">9</a>. Privacy Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
<a href="#section-10">10</a>. Operations and Management Considerations . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-11.1">11.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-11.2">11.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
<span class="grey">Cam-Winget, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document defines an architecture, i.e., "XMPP-Grid", as a method
for using the Extensible Messaging and Presence Protocol (XMPP)
[<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] to collect and distribute security incident reports and
other security-relevant information among network platforms,
endpoints, and any other network-connected device, primarily for the
purpose of communication among Computer Security Incident Response
Teams and associated entities. In effect, this document specifies an
Applicability Statement (<a href="./rfc2026#section-3.2">[RFC2026], Section 3.2</a>) that defines how to
use XMPP for the exchange of security notifications on a controlled-
access network among authorized entities.
Among other things, XMPP provides a publish-subscribe service
[<a href="#ref-XEP-0060" title=""Publish- Subscribe"">XEP-0060</a>] that acts as a broker, enabling control-plane functions by
which entities can discover available information to be published or
consumed. Although such information can take the form of any
structured data (XML, JSON, etc.), this document illustrates the
principles of XMPP-Grid with examples that use the Incident Object
Description Exchange Format (IODEF) [<a href="./rfc7970" title=""The Incident Object Description Exchange Format Version 2"">RFC7970</a>]. That is, while other
security information formats can be shared using XMPP, this document
uses IODEF as one such example format that can be published and
consumed using XMPP.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
This document uses XMPP terminology defined in [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] and
[<a href="#ref-XEP-0060" title=""Publish- Subscribe"">XEP-0060</a>]. Because the intended audience for this document is those
who implement and deploy security reporting systems, mappings are
provided for the benefit of XMPP developers and operators.
Broker: A specific type of controller containing control-plane
functions; as used here, the term refers to an XMPP publish-
subscribe service.
Broker Flow: A method by which security incident reports and other
security-relevant information are published and consumed in a
mediated fashion through a Broker. In this flow, the Broker
handles authorization of Consumers and Providers to Topics,
receives messages from Providers, and delivers published messages
to Consumers.
Consumer: An entity that contains functions to receive information
from other components; as used here, the term refers to an XMPP
publish-subscribe Subscriber.
<span class="grey">Cam-Winget, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
Controller: A component containing control-plane functions that
manage and facilitate information sharing or execute on security
functions; as used here, the term refers to an XMPP server, which
provides core message delivery [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] used by publish-subscribe
entities.
Node: The XMPP term for a Topic.
Platform: Any entity that connects to the XMPP-Grid in order to
publish or consume security-relevant information.
Provider: An entity that contains functions to provide information
to other components; as used here, the term refers to an XMPP
publish-subscribe Publisher.
Topic: A contextual information channel created on a Broker on which
messages generated by a Provider are propagated in real time to
one or more Consumers. Each Topic is limited to a specific type
and format of security data (e.g., IODEF namespace) and provides
an XMPP interface by which the data can be obtained.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="grey">Cam-Winget, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Architecture</span>
The following figure illustrates the architecture of XMPP-Grid.
+--------------------------------------+
| +--------------------------------------+
| | +--------------------------------------+
| | | |
+-| | Platforms |
+-| |
+--------------------------------------+
/ \ / \ / \
/ C \ / \ / \
- o - - d - - -
||n||A | a |B | |C
||t|| | t | | |
- r - - a - | |
\ o / \ / | |
\ l / \ / | |
/|---------------------|\ | |
/|----/ \--------| d |--|\
/ / Controller \ ctrl | a | \
\ \ & Broker / plane | t | /
\|----\ /--------| a |--|/
\|---------------------|/ | |
/ \ / \ | |
/ C \ / \ | |
- o - - d - | |
||n||A | a |B | |C
||t|| | t | | |
- r - - a - - -
\ o / \ / \ /
\ l / \ / \ /
+------------------------------------+
| |-+
| Platforms | |
| | |-+
+------------------------------------+ | |
+------------------------------------+ |
+------------------------------------+
Figure 1: XMPP-Grid Architecture
Platforms connect to the Controller (XMPP server) to authenticate and
then establish appropriate authorizations to be a Provider or
Consumer of topics of interest at the Broker. The control-plane
messaging is established through XMPP and is shown as "A" (control-
plane interface) in Figure 1. Authorized Platforms can then share
<span class="grey">Cam-Winget, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
data either through the Broker (shown as "B" in Figure 1) or, in some
cases, directly (shown as "C" in Figure 1). This document focuses
primarily on the Broker Flow for information sharing ("direct flow"
interactions can be used for specialized purposes, such as bulk data
transfer, but methods for doing so are outside the scope of this
document).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Workflow</span>
Implementations of XMPP-Grid adhere to the following workflow:
a. A Platform with a source of security data requests connection to
the XMPP-Grid via a Controller.
b. The Controller authenticates the Platform.
c. The Platform establishes authorized privileges (e.g., privilege
to publish and/or subscribe to one or more Topics) with a Broker.
d. The Platform can publish security incident reports and other
security-relevant information to a Topic, subscribe to a Topic,
query a Topic, or perform any combination of these operations.
e. A Provider unicasts its Topic updates to the Grid in real time
through a Broker. The Broker handles replication and
distribution of the Topic to Consumers. A Provider can publish
the same or different data to multiple Topics.
f. Any Platform on the Grid can subscribe to any Topic published to
the Grid (as permitted by the authorization policy) and (as
Consumers) will then receive a continual, real-time stream of
updates from the Topics to which it is subscribed.
The general workflow is summarized in the figure below.
<span class="grey">Cam-Winget, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
+--------------+ +------------+ +---------------+
| IODEF Client | | Controller | | IODEF Service |
| (Consumer) | | & Broker | | (Provider) |
+--------------+ +------------+ +---------------+
| | |
| Establish XMPP | |
| Client Session | |
| (<a href="./rfc6120">RFC 6120</a>) | |
|--------------------->| |
| | Establish XMPP |
| | Client Session |
| | (<a href="./rfc6120">RFC 6120</a>) |
| |<------------------------|
| | Request Topic Creation |
| | (XEP-0060) |
| |<------------------------|
| | Topic Creation Success |
| | (XEP-0060) |
| |------------------------>|
| Request Topic List | |
| (XEP-0030) | |
|--------------------->| |
| Return Topic List | |
| (XEP-0030) | |
|<---------------------| |
| | |
| Query Each Topic | |
| (XEP-0030) | |
|--------------------->| |
| Return Topic Data | |
| Including Topic Type | |
| (XEP-0030) | |
|<---------------------| |
| | |
| Subscribe to IODEF | |
| Topic (XEP-0060) | |
|--------------------->| |
| Subscription Success | |
| (XEP-0060) | |
|<---------------------| |
| | Publish IODEF Incident |
| | (XEP-0060) |
| Receive IODEF |<------------------------|
| Incident (XEP-0060) | |
|<---------------------| |
| | |
Figure 2: IODEF Example Workflow
<span class="grey">Cam-Winget, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
XMPP-Grid implementations MUST adhere to the mandatory-to-implement
and mandatory-to-negotiate features as defined in [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>].
Similarly, implementations MUST implement the publish-subscribe
extension [<a href="#ref-XEP-0060" title=""Publish- Subscribe"">XEP-0060</a>] to facilitate the asynchronous sharing of
information. Implementations SHOULD implement Service Discovery as
defined in [<a href="#ref-XEP-0030" title=""Service Discovery"">XEP-0030</a>] to facilitate the means to dynamically discover
the available information and namespaces (Topics) to be published or
consumed. Care should be taken with implementations if their
deployments allow for a large number of Topics. The result set
management as defined in [<a href="#ref-XEP-0059" title=""Result Set Management"">XEP-0059</a>] SHOULD be used to allow the
requesting entity to explicitly request Service Discovery result sets
to be returned in pages or a limited size, if the discovery results
are larger in size. Note that the control plane may optionally also
implement [<a href="#ref-XEP-0203" title=""Delayed Delivery"">XEP-0203</a>] to facilitate delayed delivery of messages to
the connected consumer as described in [<a href="#ref-XEP-0060" title=""Publish- Subscribe"">XEP-0060</a>]. Since information
may be timely and sensitive, capability providers should communicate
to the Controller whether its messages can be cached for delayed
delivery during configuration; such a function is out of scope for
this document.
The following sections provide protocol examples for the service
discovery and publish-subscribe parts of the workflow.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Service Discovery</span>
Using the XMPP service discovery extension [<a href="#ref-XEP-0030" title=""Service Discovery"">XEP-0030</a>], a Controller
enables Platforms to discover what information can be consumed
through the Broker and at which Topics. Platforms could use
[<a href="#ref-XEP-0059" title=""Result Set Management"">XEP-0059</a>] to restrict the size of the result sets the Controller
returns in a Service Discovery response. As an example, the
Controller at 'security-grid.example' might provide a Broker at
'broker.security-grid.example', which hosts a number of Topics. A
Platform at 'xmpp-grid-client@mile-host.example' would query the
Broker about its available Topics by sending an XMPP "disco#items"
request to the Broker:
<iq type='get'
from='xmpp-grid-client@mile-host.example/2EBE702A97D6'
to='broker.security-grid.example'
id='B3C17F7B-B9EF-4ABA-B08D-805DA9F34626'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
<span class="grey">Cam-Winget, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
The Broker responds with the Topics it hosts:
<iq type='result'
from='broker.security-grid.example'
to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
id='B3C17F7B-B9EF-4ABA-B08D-805DA9F34626'>
<query xmlns='http://jabber.org/protocol/disco#items'>
<item node='NEA1'
name='Endpoint Posture Information'
jid='broker.security-grid.example'/>
<item node='MILEHost'
name='MILE Host Data'
jid='broker.security-grid.example'/>
</query>
</iq>
In order to determine the exact nature of each Topic (i.e., in order
to find Topics that publish incidents in the IODEF format), a
Platform would send an XMPP "disco#info" request to each Topic:
<iq type='get'
from='xmpp-grid-client@mile-host.example/2EBE702A97D6'
to='broker.security-grid.example'
id='D367D4ED-2795-489C-A83E-EAAFA07A0356'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='MILEHost'/>
</iq>
<span class="grey">Cam-Winget, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
The Broker responds with the "disco#info" description, which MUST
include an XMPP data form [<a href="#ref-XEP-0004" title=""Data Forms"">XEP-0004</a>] with a 'pubsub#type' field that
specifies the supported namespace (in this example, the IODEF
namespace defined in [<a href="./rfc7970" title=""The Incident Object Description Exchange Format Version 2"">RFC7970</a>]):
<iq type='result'
from='broker.security-grid.example'
to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
id='D367D4ED-2795-489C-A83E-EAAFA07A0356'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='MILEHost'>
<identity category='pubsub' type='leaf'/>
<feature var='http://jabber.org/protocol/pubsub'/>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#meta-data</value>
</field>
<field var='pubsub#type' label='Payload type' type='text-single'>
<value>urn:ietf:params:xml:ns:iodef-2.0</value>
</field>
</x>
</query>
</iq>
The Platform discovers the Topics by obtaining the Broker's response
and obtaining the namespaces returned in the "pubsub#type" field (in
the foregoing example, IODEF 2.0).
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Publish-Subscribe</span>
Using the XMPP publish-subscribe extension [<a href="#ref-XEP-0060" title=""Publish- Subscribe"">XEP-0060</a>], a Consumer
subscribes to a Topic, and a Provider publishes information to that
Topic, which the Broker then distributes to all subscribed Consumers.
First, a Provider would create a Topic as follows:
<iq type='set'
from='datasource@provider.example/F12C2EFC9BB0'
to='broker.security-grid.example'
id='A67507DF-2F22-4937-8D30-88D2F7DBA279'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='MILEHost'/>
</pubsub>
</iq>
Note: The foregoing example is the minimum protocol needed to create
a Topic with the default node configuration on the XMPP publish-
subscribe service specified in the 'to' address of the creation
<span class="grey">Cam-Winget, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
request stanza. Depending on security requirements, the Provider
might need to request a non-default configuration for the node; see
[<a href="#ref-XEP-0060" title=""Publish- Subscribe"">XEP-0060</a>] for detailed examples. To also help with the Topic
configuration, the Provider may also optionally include configuration
parameters such as:
<configure>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#node_config</value>
</field>
<field var='pubsub#access_model'><value>authorize</value></field>
<field var='pubsub#persist_items'><value>1</value></field>
<field var='pubsub#send_last_published_item'>
<value>never</value>
</field>
</x>
</configure>
The above configuration indicates the Topic is configured so that the
Broker will a) explicitly approve subscription requests, b)
persistently store all messages posted to the Topic, and c) not
deliver the most recently published when an entity initially
subscribes to the Topic. Please refer to [<a href="#ref-XEP-0060" title=""Publish- Subscribe"">XEP-0060</a>] for a more
detailed description of this configuration and other available
configuration options.
Unless an error occurs (see [<a href="#ref-XEP-0060" title=""Publish- Subscribe"">XEP-0060</a>] for various error flows), the
Broker responds with success:
<iq type='result'
from='broker.security-grid.example'
to='datasource@provider.example/F12C2EFC9BB0'
id='A67507DF-2F22-4937-8D30-88D2F7DBA279'/>
Second, a Consumer would subscribe as follows:
<iq type='set'
from='xmpp-grid-client@mile-host.example/2EBE702A97D6'
to='broker.security-grid.example'
id='9C6EEE9E-F09A-4418-8D68-3BA6AF852522'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='MILEHost'
jid='xmpp-grid-client@mile-host.example'/>
</pubsub>
</iq>
<span class="grey">Cam-Winget, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
Unless an error occurs (see [<a href="#ref-XEP-0060" title=""Publish- Subscribe"">XEP-0060</a>] for various error flows), the
Broker makes an appropriate authorization decision. If access is
granted, it responds with success:
<iq type='result'
from='broker.security-grid.example'
to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
id='9C6EEE9E-F09A-4418-8D68-3BA6AF852522'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscription
node='MILEHost'
jid='xmpp-grid-client@mile-host.example'
subscription='subscribed'/>
</pubsub>
</iq>
Third, a Provider would publish an incident to the Broker using the
MILEHost Topic as follows:
<iq type='set'
from='datasource@provider.example/F12C2EFC9BB0'
to='broker.security-grid.example'
id='2A17D283-0DAE-4A6C-85A9-C10B1B40928C'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='MILEHost'>
<item id='8bh1g27skbga47fh9wk7'>
<IODEF-Document version="2.00" xml:lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"<a href="http://www.iana.org/assignments/xml-registry/schema/iodef-2.0.xsd">http://www.iana.org/assignments/xml-registry/</a>
<a href="http://www.iana.org/assignments/xml-registry/schema/iodef-2.0.xsd">schema/iodef-2.0.xsd</a>">
<Incident purpose="reporting" restriction="private">
<IncidentID name="csirt.example.com">492382</IncidentID>
<GenerationTime>2015-07-18T09:00:00-05:00</GenerationTime>
<Contact type="organization" role="creator">
<Email>
<EmailTo>contact@csirt.example.com</EmailTo>
</Email>
</Contact>
</Incident>
</IODEF-Document>
</item>
</publish>
</pubsub>
</iq>
<span class="grey">Cam-Winget, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
(The payload in the foregoing example is from [<a href="./rfc7970" title=""The Incident Object Description Exchange Format Version 2"">RFC7970</a>]; payloads for
additional use cases can be found in [<a href="./rfc8274" title=""Incident Object Description Exchange Format Usage Guidance"">RFC8274</a>].)
The Broker would then deliver that incident report to all Consumers
who are subscribed to the Topic:
<message
from='broker.security-grid.example'
to='xmpp-grid-client@mile-host.example/2EBE702A97D6'
id='37B3921D-4F7F-450F-A589-56119A88BC2E'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='MILEHost'>
<item id='iah37s61s964gquqy47aksbx9453ks77'>
<IODEF-Document version="2.00" xml:lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"<a href="http://www.iana.org/assignments/xml-registry/schema/iodef-2.0.xsd">http://www.iana.org/assignments/xml-registry/</a>
<a href="http://www.iana.org/assignments/xml-registry/schema/iodef-2.0.xsd">schema/iodef-2.0.xsd</a>">
<Incident purpose="reporting" restriction="private">
<IncidentID name="csirt.example.com">492382</IncidentID>
<GenerationTime>2015-07-18T09:00:00-05:00</GenerationTime>
<Contact type="organization" role="creator">
<Email>
<EmailTo>contact@csirt.example.com</EmailTo>
</Email>
</Contact>
</Incident>
</IODEF-Document>
</item>
</items>
</event>
</message>
Note that [<a href="#ref-XEP-0060" title=""Publish- Subscribe"">XEP-0060</a>] uses the XMPP "<message />" stanza for delivery
of content. To ensure that messages are delivered to the Consumer
even if the Consumer is not online at the same time that the
Publisher generates the message, an XMPP-Grid Controller MUST support
"offline messaging" delivery semantics as specified in [<a href="./rfc6121" title=""Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence"">RFC6121</a>], the
best practices of which are further explained in [<a href="#ref-XEP-0160" title=""Best Practices for Handling Offline Messages"">XEP-0160</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
This document has no actions for IANA.
<span class="grey">Cam-Winget, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
An XMPP-Grid Controller serves as a controlling broker for XMPP-Grid
Platforms such as enforcement points, policy servers, Configuration
Management Databases (CMDBs), and sensors, using a publish-subscribe-
search model of information exchange and lookup. By increasing the
ability of XMPP-Grid Platforms to learn about and respond to security
incident reports and other security-relevant information, XMPP-Grid
can improve the timeliness and utility of the security system.
However, this integrated security system can also be exploited by
attackers if they can compromise it. Therefore, strong security
protections for XMPP-Grid are essential.
As XMPP is the core of this document, the security considerations of
[<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] apply. In addition, as XMPP-Grid defines a specific
instance, this section provides a security analysis of the XMPP-Grid
data transfer protocol and the architectural elements that employ it,
specifically with respect to their use of this protocol. Three
subsections define the trust model (which elements are trusted to do
what), the threat model (attacks that can be mounted on the system),
and the countermeasures (ways to address or mitigate the threats
previously identified).
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Trust Model</span>
The first step in analyzing the security of the XMPP-Grid transport
protocol is to describe the trust model and list what each
architectural element is trusted to do. The items listed here are
assumptions, but provisions are made in "Threat Model" (<a href="#section-8.2">Section 8.2</a>)
and "Countermeasures" (<a href="#section-8.3">Section 8.3</a>) for elements that fail to perform
as they were trusted to do.
<span class="h4"><a class="selflink" id="section-8.1.1" href="#section-8.1.1">8.1.1</a>. Network</span>
The network used to carry XMPP-Grid messages (i.e., the underlying
network transport layer over which XMPP runs) is trusted to:
o Perform best-effort delivery of network traffic
The network used to carry XMPP-Grid messages is not expected
(trusted) to:
o Provide confidentiality or integrity protection for messages sent
over it
o Provide timely or reliable service
<span class="grey">Cam-Winget, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
<span class="h4"><a class="selflink" id="section-8.1.2" href="#section-8.1.2">8.1.2</a>. XMPP-Grid Platforms</span>
Authorized XMPP-Grid Platforms are trusted to:
o Preserve the confidentiality of sensitive data retrieved via the
XMPP-Grid Controller
<span class="h4"><a class="selflink" id="section-8.1.3" href="#section-8.1.3">8.1.3</a>. XMPP-Grid Controller</span>
The XMPP-Grid Controller (including its associated Broker) is trusted
to:
o Broker requests for data and enforce authorization of access to
this data throughout its lifecycle
o Perform service requests in a timely and accurate manner
o Create and maintain accurate operational attributes
o Only reveal data to and accept service requests from authorized
parties
o Preserve the integrity (and confidentiality against unauthorized
parties) of the data flowing through it.
The XMPP-Grid Controller is not expected (trusted) to:
o Verify the truth (correctness) of data
<span class="h4"><a class="selflink" id="section-8.1.4" href="#section-8.1.4">8.1.4</a>. Certification Authority</span>
To allow XMPP-Grid Platforms to mutually authenticate with XMPP-Grid
Controllers, it is expected that a Certification Authority (CA) is
employed to issue certificates. Such a CA (or each CA, if there are
several) is trusted to:
o Ensure that only proper certificates are issued and that all
certificates are issued in accordance with the CA's policies
o Revoke certificates previously issued when necessary
o Regularly and securely distribute certificate revocation
information
o Promptly detect and report any violations of this trust so that
they can be handled
<span class="grey">Cam-Winget, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
The CA is not expected (trusted) to:
o Issue certificates that go beyond the XMPP-Grid needs or other
constraints imposed by a relying party.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Threat Model</span>
To secure the XMPP-Grid data transfer protocol and the architectural
elements that implement it, this section identifies the attacks that
can be mounted against the protocol and elements.
<span class="h4"><a class="selflink" id="section-8.2.1" href="#section-8.2.1">8.2.1</a>. Network Attacks</span>
A variety of attacks can be mounted using the network. For the
purposes of this subsection, the phrase "network traffic" can be
taken to mean messages and/or parts of messages. Any of these
attacks can be mounted by network elements, by parties who control
network elements, and (in many cases) by parties who control network-
attached devices.
o Network traffic can be passively monitored to glean information
from any unencrypted traffic
o Even if all traffic is encrypted, valuable information can be
gained by traffic analysis (volume, timing, source and destination
addresses, etc.)
o Network traffic can be modified in transit
o Previously transmitted network traffic can be replayed
o New network traffic can be added
o Network traffic can be blocked, perhaps selectively
o A man-in-the-middle (MITM) attack can be mounted where an attacker
interposes itself between two communicating parties and
impersonates the other end to either or both parties
o Undesired network traffic can be sent in an effort to overload an
architectural component, thus mounting a denial-of-service attack
<span class="h4"><a class="selflink" id="section-8.2.2" href="#section-8.2.2">8.2.2</a>. XMPP-Grid Platforms</span>
An unauthorized XMPP-Grid Platform (one that is not recognized by the
XMPP-Grid Controller or is recognized but not authorized to perform
any actions) cannot mount any attacks other than those listed in
"Network Attacks" (<a href="#section-8.2.1">Section 8.2.1</a>).
<span class="grey">Cam-Winget, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
An authorized XMPP-Grid Platform, on the other hand, can mount many
attacks. These attacks might occur because the XMPP-Grid Platform is
controlled by a malicious, careless, or incompetent party (whether
because its owner is malicious, careless, or incompetent or because
the XMPP-Grid Platform has been compromised and is now controlled by
a party other than its owner). They might also occur because the
XMPP-Grid Platform is running malicious software, the XMPP-Grid
Platform is running buggy software (which can fail in a state that
floods the network with traffic), or the XMPP-Grid Platform has been
configured improperly. From a security standpoint, it generally
makes no difference why an attack is initiated. The same
countermeasures can be employed in any case.
Here is a list of attacks that can be mounted by an authorized XMPP-
Grid Platform:
o Cause many false alarms or otherwise overload the XMPP-Grid
Controller or other elements in the network security system
(including human administrators), leading to a denial of service
or parts of the network security system being disabled.
o Omit important actions (such as posting incriminating data),
resulting in incorrect access.
o Use confidential information obtained from the XMPP-Grid
Controller to enable further attacks (such as using endpoint
health check results to exploit vulnerable endpoints).
o Advertise data crafted to exploit vulnerabilities in the XMPP-Grid
Controller or in other XMPP-Grid Platforms with the goal of
compromising those systems.
o Issue a search request or set up a subscription that matches an
enormous result, leading to resource exhaustion on the XMPP-Grid
Controller, the publishing XMPP-Grid Platform, and/or the network.
o Establish a communication channel using another XMPP-Grid
Platform's session-id.
o Advertise false data that leads to incorrect (e.g., potentially
attacker-controlled or -induced) behavior of XMPP-Grid Platforms
by virtue of applying correct procedures to the falsified input.
Dependencies or vulnerabilities of authorized XMPP-Grid Platforms can
be exploited to effect these attacks. Another way to effect these
attacks is to gain the ability to impersonate an XMPP-Grid Platform
(through theft of the XMPP-Grid Platform's identity credentials or
<span class="grey">Cam-Winget, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
through other means). Even a clock skew between the XMPP-Grid
Platform and XMPP-Grid Controller can cause problems if the XMPP-Grid
Platform assumes that old XMPP-Grid Platform data should be ignored.
<span class="h4"><a class="selflink" id="section-8.2.3" href="#section-8.2.3">8.2.3</a>. XMPP-Grid Controllers</span>
An unauthorized XMPP-Grid Controller (one that is not trusted by
XMPP-Grid Platforms) cannot mount any attacks other than those listed
in "Network Attacks" (<a href="#section-8.2.1">Section 8.2.1</a>).
An authorized XMPP-Grid Controller can mount many attacks. Similar
to the XMPP-Grid Platform case described above, these attacks might
occur because the XMPP-Grid Controller is controlled by a malicious,
careless, or incompetent party (either an XMPP-Grid Controller
administrator or an attacker who has seized control of the XMPP-Grid
Controller). They might also occur because the XMPP-Grid Controller
is running malicious software, the XMPP-Grid Controller is running
buggy software (which can fail in a state that corrupts data or
floods the network with traffic), or the XMPP-Grid Controller has
been configured improperly.
All of the attacks listed for XMPP-Grid Platform above can be mounted
by the XMPP-Grid Controller. Detection of these attacks will be more
difficult since the XMPP-Grid Controller can create false operational
attributes and/or logs that imply some other party created any bad
data.
Additional XMPP-Grid Controller attacks can include:
o Exposing different data to different XMPP-Grid Platforms to
mislead investigators or cause inconsistent behavior.
o Mounting an even more effective denial-of-service attack than a
single XMPP-Grid Platform could; some mechanisms include inducing
many platforms to perform the same operation in an amplification-
style attack, completely refusing to pass any traffic at all, or
sending floods of traffic to (certain) platforms or other targets.
o Obtaining and caching XMPP-Grid Platform credentials so they can
be used to impersonate XMPP-Grid Platforms even after a breach of
the XMPP-Grid Controller is repaired. Some Simple Authentication
and Security Layer (SASL) mechanisms (including the mandatory-to-
implement SCRAM and EXTERNAL with TLS mutual certificate-based
authentication) do not admit this class of attack, but others
(such as PLAIN) are susceptible.
<span class="grey">Cam-Winget, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
o Obtaining and caching XMPP-Grid Controller administrator
credentials so they can be used to regain control of the XMPP-Grid
Controller after the breach of the XMPP-Grid Controller is
repaired.
o Eavesdropping, injecting, or modifying the data being transferred
between Provider and Consumer.
Dependencies or vulnerabilities of the XMPP-Grid Controller can be
exploited to obtain control of the XMPP-Grid Controller and effect
these attacks.
<span class="h4"><a class="selflink" id="section-8.2.4" href="#section-8.2.4">8.2.4</a>. Certification Authority</span>
A Certification Authority trusted to issue certificates for the XMPP-
Grid Controller and/or XMPP-Grid Platforms can mount several attacks:
o Issue certificates for unauthorized parties, enabling them to
impersonate authorized parties such as the XMPP-Grid Controller or
an XMPP-Grid Platform. This can lead to all the threats that can
be mounted by the certificate's subject.
o Issue certificates without following all of the CA's policies.
Because this can result in issuing certificates that can be used
to impersonate authorized parties, this can lead to all the
threats that can be mounted by the certificate's subject.
o Fail to revoke previously issued certificates that need to be
revoked. This can lead to undetected impersonation of the
certificate's subject or failure to revoke authorization of the
subject and therefore can lead to all of the threats that can be
mounted by that subject.
o Fail to regularly and securely distribute certificate revocation
information. This can cause a relying party to accept a revoked
certificate, leading to undetected impersonation of the
certificate's subject or failure to revoke authorization of the
subject and therefore can lead to all of the threats that can be
mounted by that subject. It can also cause a relying party to
refuse to proceed with a transaction because timely revocation
information is not available, even though the transaction should
be permitted to proceed.
o Allow the CA's private key to be revealed to an unauthorized
party. This can lead to all the threats above. Even worse, the
actions taken with the private key will not be known to the CA.
<span class="grey">Cam-Winget, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
o Fail to promptly detect and report errors and violations of trust
so that relying parties can be promptly notified. This can cause
the threats listed earlier in this section to persist longer than
necessary, leading to many knock-on effects.
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Countermeasures</span>
Below are countermeasures for specific attack scenarios to the XMPP-
Grid infrastructure.
<span class="h4"><a class="selflink" id="section-8.3.1" href="#section-8.3.1">8.3.1</a>. Securing the XMPP-Grid Data Transfer Protocol</span>
To address network attacks, the XMPP-Grid data transfer protocol
described in this document requires that the XMPP-Grid messages MUST
be carried over TLS (minimally TLS 1.2 and preferably TLS 1.3
[<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>]) as described in [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] and updated by [<a href="./rfc7590" title=""Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)"">RFC7590</a>]. The
XMPP-Grid Controller and XMPP-Grid Platforms SHOULD mutually
authenticate. The XMPP-Grid Platform MUST verify the XMPP-Grid
Controller's certificate and determine whether the XMPP-Grid
Controller is trusted by this XMPP-Grid Platform before completing
the TLS handshake. To ensure interoperability, implementations MUST
implement at least either the SASL EXTERNAL mechanism [<a href="./rfc4422" title=""Simple Authentication and Security Layer (SASL)"">RFC4422</a>] or
the SASL SCRAM mechanism. When using the SASL SCRAM mechanism, the
SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256
variant, and SHA-256 variants [<a href="./rfc7677" title=""SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms"">RFC7677</a>] SHOULD be preferred over
SHA-1 variants [<a href="./rfc5802" title=""Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms"">RFC5802</a>]). XMPP-Grid Platforms and XMPP-Grid
Controllers using certificate-based authentication SHOULD each verify
the revocation status of the other party's certificate. The
selection of the XMPP-Grid Platform authentication technique to use
in any particular deployment is left to the administrator.
These protocol security measures provide protection against all the
network attacks listed in <a href="#section-8.2">Section 8.2</a> except denial-of-service
attacks. If protection against these denial-of-service attacks is
desired, ingress filtering, rate limiting per source IP address, and
other denial-of-service mitigation measures can be employed. In
addition, an XMPP-Grid Controller MAY automatically disable a
misbehaving XMPP-Grid Platform.
<span class="h4"><a class="selflink" id="section-8.3.2" href="#section-8.3.2">8.3.2</a>. Securing XMPP-Grid Platforms</span>
XMPP-Grid Platforms can be deployed in locations that are susceptible
to physical attacks. Physical security measures can be taken to
avoid compromise of XMPP-Grid Platforms, but these are not always
practical or completely effective. An alternative measure is to
configure the XMPP-Grid Controller to provide read-only access for
such systems. The XMPP-Grid Controller SHOULD also include a full
authorization model so that individual XMPP-Grid Platforms can be
<span class="grey">Cam-Winget, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
configured to have only the privileges that they need. The XMPP-Grid
Controller MAY provide functional templates so that the administrator
can configure a specific XMPP-Grid Platform as a DHCP [<a href="./rfc2131" title=""Dynamic Host Configuration Protocol"">RFC2131</a>]
server and authorize only the operations and metadata types needed by
a DHCP server to be permitted for that XMPP-Grid Platform. These
techniques can reduce the negative impacts of a compromised XMPP-Grid
Platform without diminishing the utility of the overall system.
To handle attacks within the bounds of this authorization model, the
XMPP-Grid Controller MAY also include rate limits and alerts for
unusual XMPP-Grid Platform behavior. XMPP-Grid Controllers SHOULD
make it easy to revoke an XMPP-Grid Platform's authorization when
necessary. The XMPP-Grid Controller SHOULD include auditable logs of
XMPP-Grid Platform activities.
To avoid compromise of XMPP-Grid Platforms, they SHOULD be hardened
against attack and minimized to reduce their attack surface. They
should be well managed to minimize vulnerabilities in the underlying
platform and in systems upon which the XMPP-Grid Platform depends.
Personnel with administrative access should be carefully screened and
monitored to detect problems as soon as possible.
<span class="h4"><a class="selflink" id="section-8.3.3" href="#section-8.3.3">8.3.3</a>. Securing XMPP-Grid Controllers</span>
Because of the serious consequences of XMPP-Grid Controller
compromise, XMPP-Grid Controllers need to be especially well hardened
against attack and minimized to reduce their attack surface. They
need to be well managed to minimize vulnerabilities in the underlying
platform and in systems upon which the XMPP-Grid Controller depends.
Network security measures such as firewalls or intrusion detection
systems can be used to monitor and limit traffic to and from the
XMPP-Grid Controller. Personnel with administrative access ought to
be carefully screened and monitored to detect problems as soon as
possible. Administrators SHOULD NOT use password-based
authentication but SHOULD instead use non-reusable credentials and
multi-factor authentication (where available). Physical security
measures ought to be employed to prevent physical attacks on XMPP-
Grid Controllers.
To ease detection of XMPP-Grid Controller compromise should it occur,
XMPP-Grid Controller behavior should be monitored to detect unusual
behavior (such as a reboot, a large increase in traffic, or different
views of an information repository for similar XMPP-Grid Platforms).
It is a matter of local policy whether XMPP-Grid Platforms log and/or
notify administrators when peculiar XMPP-Grid Controller behavior is
detected and whether read-only audit logs of security-relevant
information (especially administrative actions) are maintained;
however, such behavior is encouraged to aid in forensic analysis.
<span class="grey">Cam-Winget, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
Furthermore, if compromise of an XMPP-Grid Controller is detected, a
careful analysis should be performed, and any reusable credentials
that could have been compromised should be reissued.
To address the potential for the XMPP-Grid Controller to eavesdrop,
modify or inject data, it would be desirable to deploy end-to-end
encryption between the Provider and the Consumer(s). Unfortunately,
because there is no standardized method for encryption of one-to-many
messages within XMPP, techniques for enforcing end-to-end encryption
are out of scope for this specification.
<span class="h4"><a class="selflink" id="section-8.3.4" href="#section-8.3.4">8.3.4</a>. Broker Access Models for Topics</span>
The XMPP publish-subscribe specification [<a href="#ref-XEP-0060" title=""Publish- Subscribe"">XEP-0060</a>] defines five
access models for subscribing to Topics at a Broker: open, presence,
roster, authorize, and whitelist. The first model allows
uncontrolled access, and the next two models are appropriate only in
instant-messaging applications. Therefore, a Broker SHOULD support
only the authorize model (under which the Topic owner needs to
approve all subscription requests and only subscribers can retrieve
data items) and the whitelist model (under which only preconfigured
Platforms can subscribe or retrieve data items). In order to ease
the deployment burden, subscription approvals and whitelist
management can be automated (e.g., the Topic "owner" can be a policy
server). The choice between "authorize" and "whitelist" as the
default access model is a matter for local service policy.
<span class="h4"><a class="selflink" id="section-8.3.5" href="#section-8.3.5">8.3.5</a>. Limit on Search Result Size</span>
While XMPP-Grid is designed for high scalability to hundreds of
thousands of Platforms, an XMPP-Grid Controller MAY establish a limit
to the amount of data it is willing to return in search or
subscription results. Platforms could use [<a href="#ref-XEP-0059" title=""Result Set Management"">XEP-0059</a>] to restrict the
size of the result sets the Controller returns in search or
subscription results or topics' service discovery. This mitigates
the threat of an XMPP-Grid Platform causing resource exhaustion by
issuing a search or subscription that leads to an enormous result.
<span class="h4"><a class="selflink" id="section-8.3.6" href="#section-8.3.6">8.3.6</a>. Securing the Certification Authority</span>
As noted above, compromise of a Certification Authority (CA) trusted
to issue certificates for the XMPP-Grid Controller and/or XMPP-Grid
Platforms is a major security breach. Many guidelines for proper CA
security have been developed: the CA/Browser Forum's Baseline
Requirements, the American Institute of Certified Public Accountants
(AICPA) / Canadian Institute of Chartered Accountants (CICA) Trust
<span class="grey">Cam-Winget, et al. Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
Service Principles, the IETF's Certificate Transparency [<a href="./rfc6962" title=""Certificate Transparency"">RFC6962</a>],
etc. The CA operator and relying parties should agree on
appropriately rigorous security practices to be used.
Even with the most rigorous security practices, a CA can be
compromised. If this compromise is detected quickly, relying parties
can remove the CA from their list of trusted CAs, and other CAs can
revoke any certificates issued to the CA. However, CA compromise may
go undetected for some time, and there's always the possibility that
a CA is being operated improperly or in a manner that is not in the
interests of the relying parties. For this reason, relying parties
may wish to "pin" a small number of particularly critical
certificates (such as the certificate for the XMPP-Grid Controller).
Once a certificate has been pinned, the relying party will not accept
another certificate in its place unless the Administrator explicitly
commands it to do so. This does not mean that the relying party will
not check the revocation status of pinned certificates. However, the
Administrator can still be consulted if a pinned certificate is
revoked, since the CA and revocation process are not completely
trusted. By "pinning" one or a small set of certificates, the
relying party has identified the effective XMPP-Grid Controller(s)
authorized for connection.
<span class="h4"><a class="selflink" id="section-8.3.7" href="#section-8.3.7">8.3.7</a>. End-to-End Encryption of Messages</span>
Because it is expected that there will be a relatively large number
of Consumers for every Topic, for the purposes of content discovery
and scaling, this document specifies a "one-to-many" communications
pattern using the XMPP Publish-Subscribe extension. Unfortunately,
there is no standardized technology for end-to-end encryption of one-
to-many messages in XMPP. This implies that messages can be subject
to eavesdropping, data injection, and data modification attacks
within a Broker or Controller. If it is necessary to mitigate
against such attacks, implementers would need to select a messaging
pattern other than [<a href="#ref-XEP-0060" title=""Publish- Subscribe"">XEP-0060</a>], most likely the basic "instant
messaging" pattern specified in [<a href="./rfc6121" title=""Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence"">RFC6121</a>] with a suitable XMPP
extension for end-to-end encryption. The description of such an
approach is out of scope for this document.
<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>. Summary</span>
XMPP-Grid's considerable value as a broker for security-sensitive
data exchange distribution also makes the protocol and the network
security elements that implement it a target for attack. Therefore,
strong security has been included as a basic design principle within
the XMPP-Grid design process.
<span class="grey">Cam-Winget, et al. Standards Track [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
The XMPP-Grid data transfer protocol provides strong protection
against a variety of different attacks. In the event that an XMPP-
Grid Platform or XMPP-Grid Controller is compromised, the effects of
this compromise are reduced and limited with the recommended role-
based authorization model and other provisions, and best practices
for managing and protecting XMPP-Grid systems have been described.
Taken together, these measures should provide protection commensurate
with the threat to XMPP-Grid systems, thus ensuring that they fulfill
their promise as a network security clearinghouse.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Privacy Considerations</span>
XMPP-Grid Platforms can publish information about endpoint health,
network access, events (which can include information about which
services an endpoint is accessing), roles and capabilities, and the
identity of the end user operating the endpoint. Any of this
published information can be queried by other XMPP-Grid Platforms and
could potentially be used to correlate network activity to a
particular end user.
Dynamic and static information brokered by an XMPP-Grid Controller,
ostensibly for the purposes of correlation by XMPP-Grid Platforms for
intrusion detection, could be misused by a broader set of XMPP-Grid
Platforms that hitherto have been performing specific roles with a
strict, well-defined separation of duties.
Care needs to be taken by deployers of XMPP-Grid to ensure that the
information published by XMPP-Grid Platforms does not violate
agreements with end users or local and regional laws and regulations.
This can be accomplished either by configuring XMPP-Grid Platforms to
not publish certain information or by restricting access to sensitive
data to trusted XMPP-Grid Platforms. That is, the easiest means to
ensure privacy or protect sensitive data is to omit or not share it
at all.
Similarly, care must be taken by deployers and XMPP-Grid Controller
implementations as they implement the appropriate auditing tools. In
particular, any information, such as logs, must be sensitive to the
type of information stored to ensure that the information does not
violate privacy and agreements with end users or local and regional
laws and regulations.
Another consideration for deployers is to enable end-to-end
encryption to ensure the data is protected while in transit between
data layers and thus protected from the transport layer. The means
to achieve end-to-end encryption is beyond the scope of this
document.
<span class="grey">Cam-Winget, et al. Standards Track [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Operations and Management Considerations</span>
In order to facilitate the management of Providers and the onboarding
of Consumers, it is helpful to generate the following ahead of time:
o Agreement between the operators of Provider services and the
implementers of Consumer software regarding identifiers for common
Topics (e.g., these could be registered with the XMPP Software
Foundation's registry of well-known nodes for service discovery
and publish-subscribe, located at <<a href="https://xmpp.org/registrar/nodes.html">https://xmpp.org/registrar/</a>
<a href="https://xmpp.org/registrar/nodes.html">nodes.html</a>>).
o Security certificates (including appropriate certificate chains)
for Controllers, including identification of any Providers
associated with the Controllers (which might be located at
subdomains).
o Consistent and secure access control policies for publishing and
subscribing to Topics.
These matters are out of scope for this document but ought to be
addressed by the XMPP-Grid community.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-RFC2026">RFC2026</a>] Bradner, S., "The Internet Standards Process -- Revision
3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>, <a href="./rfc2026">RFC 2026</a>, DOI 10.17487/RFC2026, October 1996,
<<a href="https://www.rfc-editor.org/info/rfc2026">https://www.rfc-editor.org/info/rfc2026</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC4422">RFC4422</a>] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", <a href="./rfc4422">RFC 4422</a>,
DOI 10.17487/RFC4422, June 2006,
<<a href="https://www.rfc-editor.org/info/rfc4422">https://www.rfc-editor.org/info/rfc4422</a>>.
[<a id="ref-RFC5802">RFC5802</a>] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", <a href="./rfc5802">RFC 5802</a>,
DOI 10.17487/RFC5802, July 2010,
<<a href="https://www.rfc-editor.org/info/rfc5802">https://www.rfc-editor.org/info/rfc5802</a>>.
<span class="grey">Cam-Winget, et al. Standards Track [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
[<a id="ref-RFC6120">RFC6120</a>] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", <a href="./rfc6120">RFC 6120</a>, DOI 10.17487/RFC6120,
March 2011, <<a href="https://www.rfc-editor.org/info/rfc6120">https://www.rfc-editor.org/info/rfc6120</a>>.
[<a id="ref-RFC6121">RFC6121</a>] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
<a href="./rfc6121">RFC 6121</a>, DOI 10.17487/RFC6121, March 2011,
<<a href="https://www.rfc-editor.org/info/rfc6121">https://www.rfc-editor.org/info/rfc6121</a>>.
[<a id="ref-RFC7590">RFC7590</a>] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
Security (TLS) in the Extensible Messaging and Presence
Protocol (XMPP)", <a href="./rfc7590">RFC 7590</a>, DOI 10.17487/RFC7590, June
2015, <<a href="https://www.rfc-editor.org/info/rfc7590">https://www.rfc-editor.org/info/rfc7590</a>>.
[<a id="ref-RFC7677">RFC7677</a>] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
Authentication and Security Layer (SASL) Mechanisms",
<a href="./rfc7677">RFC 7677</a>, DOI 10.17487/RFC7677, November 2015,
<<a href="https://www.rfc-editor.org/info/rfc7677">https://www.rfc-editor.org/info/rfc7677</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-XEP-0004">XEP-0004</a>] Eatmon, R., Hildebrand, J., Miller, J., Muldowney, T., and
P. Saint-Andre, "Data Forms", XSF XEP 0004, August 2007,
<<a href="https://xmpp.org/extensions/xep-0004.html">https://xmpp.org/extensions/xep-0004.html</a>>.
[<a id="ref-XEP-0030">XEP-0030</a>] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
Andre, "Service Discovery", XSF XEP 0030, October 2017,
<<a href="https://xmpp.org/extensions/xep-0030.html">https://xmpp.org/extensions/xep-0030.html</a>>.
[<a id="ref-XEP-0059">XEP-0059</a>] Paterson, I., Saint-Andre, P., Mercier, V., and J.
Seguineau, "Result Set Management", XSF XEP 0059,
September 2006,
<<a href="https://xmpp.org/extensions/xep-0059.html">https://xmpp.org/extensions/xep-0059.html</a>>.
[<a id="ref-XEP-0060">XEP-0060</a>] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
Subscribe", XSF XEP 0060, January 2019,
<<a href="https://xmpp.org/extensions/xep-0060.html">https://xmpp.org/extensions/xep-0060.html</a>>.
[<a id="ref-XEP-0203">XEP-0203</a>] Saint-Andre, P., "Delayed Delivery", XSF XEP 0203,
September 2009,
<<a href="https://xmpp.org/extensions/xep-0203.html">https://xmpp.org/extensions/xep-0203.html</a>>.
<span class="grey">Cam-Winget, et al. Standards Track [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-RFC2131">RFC2131</a>] Droms, R., "Dynamic Host Configuration Protocol",
<a href="./rfc2131">RFC 2131</a>, DOI 10.17487/RFC2131, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2131">https://www.rfc-editor.org/info/rfc2131</a>>.
[<a id="ref-RFC6962">RFC6962</a>] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", <a href="./rfc6962">RFC 6962</a>, DOI 10.17487/RFC6962, June 2013,
<<a href="https://www.rfc-editor.org/info/rfc6962">https://www.rfc-editor.org/info/rfc6962</a>>.
[<a id="ref-RFC7970">RFC7970</a>] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", <a href="./rfc7970">RFC 7970</a>, DOI 10.17487/RFC7970,
November 2016, <<a href="https://www.rfc-editor.org/info/rfc7970">https://www.rfc-editor.org/info/rfc7970</a>>.
[<a id="ref-RFC8274">RFC8274</a>] Kampanakis, P. and M. Suzuki, "Incident Object Description
Exchange Format Usage Guidance", <a href="./rfc8274">RFC 8274</a>,
DOI 10.17487/RFC8274, November 2017,
<<a href="https://www.rfc-editor.org/info/rfc8274">https://www.rfc-editor.org/info/rfc8274</a>>.
[<a id="ref-RFC8446">RFC8446</a>] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", <a href="./rfc8446">RFC 8446</a>, DOI 10.17487/RFC8446, August 2018,
<<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>>.
[<a id="ref-XEP-0160">XEP-0160</a>] Saint-Andre, P., "Best Practices for Handling Offline
Messages", XSF XEP 0160, October 2016,
<<a href="https://xmpp.org/extensions/xep-0160.html">https://xmpp.org/extensions/xep-0160.html</a>>.
Acknowledgements
The authors would like to acknowledge the contributions, authoring
and/or editing of the following people: Joseph Salowey, Lisa
Lorenzin, Clifford Kahn, Henk Birkholz, Jessica Fitzgerald-McKay,
Steve Hanna, and Steve Venema. In addition, we want to thank Takeshi
Takahashi, Panos Kampanakis, Adam Montville, Chris Inacio, and Dave
Cridland for reviewing and providing valuable comments.
<span class="grey">Cam-Winget, et al. Standards Track [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc8600">RFC 8600</a> XMPP Grid June 2019</span>
Authors' Addresses
Nancy Cam-Winget (editor)
Cisco Systems
3550 Cisco Way
San Jose, CA 95134
United States of America
Email: ncamwing@cisco.com
Syam Appala
Cisco Systems
3550 Cisco Way
San Jose, CA 95134
United States of America
Email: syam1@cisco.com
Scott Pope
Cisco Systems
5400 Meadows Road
Suite 300
Lake Oswego, OR 97035
United States of America
Email: scottp@cisco.com
Peter Saint-Andre
Mozilla
Email: stpeter@mozilla.com
Cam-Winget, et al. Standards Track [Page 28]
</pre>
|
