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
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
|
Network Working Group C. Jennings
Request for Comments: 4976 Cisco Systems, Inc.
Category: Standards Track R. Mahy
Plantronics
A. B. Roach
Estacado Systems
September 2007
Relay Extensions for the Message Session Relay Protocol (MSRP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
Two separate models for conveying instant messages have been defined.
Page-mode messages stand alone and are not part of a Session
Initiation Protocol (SIP) session, whereas session-mode messages are
set up as part of a session using SIP. The Message Session Relay
Protocol (MSRP) is a protocol for near real-time, peer-to-peer
exchanges of binary content without intermediaries, which is designed
to be signaled using a separate rendezvous protocol such as SIP.
This document introduces the notion of message relay intermediaries
to MSRP and describes the extensions necessary to use them.
Jennings, et al. Standards Track [Page 1]
^L
RFC 4976 MSRP Relays September 2007
Table of Contents
1. Introduction and Requirements ...................................3
2. Conventions and Definitions .....................................4
3. Protocol Overview ...............................................4
3.1. Authorization Overview ....................................11
4. New Protocol Elements ..........................................11
4.1. The AUTH Method ...........................................11
4.2. The Use-Path Header .......................................12
4.3. The HTTP Authentication "WWW-Authenticate" Header .........12
4.4. The HTTP Authentication "Authorization" Header ............12
4.5. The HTTP Authentication "Authentication-Info" Header ......12
4.6. Time-Related Headers ......................................12
5. Client Behavior ................................................13
5.1. Connecting to Relays Acting on Your Behalf ................13
5.2. Sending Requests ..........................................18
5.3. Receiving Requests ........................................18
5.4. Managing Connections ......................................18
6. Relay Behavior .................................................18
6.1. Handling Incoming Connections .............................18
6.2. Generic Request Behavior ..................................19
6.3. Receiving AUTH Requests ...................................19
6.4. Forwarding ................................................20
6.4.1. Forwarding SEND Requests ...........................21
6.4.2. Forwarding Non-SEND Requests .......................22
6.4.3. Handling Responses .................................22
6.5. Managing Connections ......................................23
7. Formal Syntax ..................................................23
8. Finding MSRP Relays ............................................24
9. Security Considerations ........................................25
9.1. Using HTTP Authentication .................................25
9.2. Using TLS .................................................26
9.3. Threat Model ..............................................27
9.4. Security Mechanism ........................................29
10. IANA Considerations ...........................................31
10.1. New MSRP Method ..........................................31
10.2. New MSRP Headers .........................................31
10.3. New MSRP Response Codes ..................................31
11. Example SDP with Multiple Hops ................................31
12. Acknowledgments ...............................................32
13. References ....................................................32
13.1. Normative References .....................................32
13.2. Informative References ...................................33
Appendix A. Implementation Considerations ........................34
Jennings, et al. Standards Track [Page 2]
^L
RFC 4976 MSRP Relays September 2007
1. Introduction and Requirements
There are a number of scenarios in which using a separate protocol
for bulk messaging is desirable. In particular, there is a need to
handle a sequence of messages as a session of media initiated using
SIP [8], just like any other media type. The Message Session Relay
Protocol (MSRP) [11] is used to convey a session of messages directly
between two end systems with no intermediaries. With MSRP, messages
can be arbitrarily large and all traffic is sent over reliable,
congestion-safe transports.
This document describes extensions to the core MSRP protocol to
introduce intermediaries called relays. With these extensions, MSRP
clients can communicate directly, or through an arbitrary number of
relays. Each client is responsible for identifying any relays acting
on its behalf and providing appropriate credentials. Clients that
can receive new TCP connections directly do not have to implement any
new functionality to work with these relays.
The goals of the MSRP relay extensions are listed below:
o convey arbitrary binary MIME data without modification or transfer
encoding
o continue to support client-to-client operation (no relay servers
required)
o operate through an arbitrary number of relays for policy
enforcement
o operate through relays under differing administrative control
o allow each client to control which relays are traversed on its
behalf
o prevent unsolicited messages (spam), "open relays", and Denial of
Service (DoS) amplification
o allow relays to use one or a small number of TCP or TLS [2]
connections to carry messages for multiple sessions, recipients,
and senders
o allow large messages to be sent over slow connections without
causing head-of-line blocking problems
o allow transmissions of large messages to be interrupted and
resumed in places where network connectivity is lost and later
reestablished
Jennings, et al. Standards Track [Page 3]
^L
RFC 4976 MSRP Relays September 2007
o offer notification of message failure at any intermediary
o allow relays to delete state after a short amount of time
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [9].
Below we list several definitions important to MSRP:
MSRP node: a host that implements the MSRP protocols as a client or a
relay.
MSRP client: an MSRP node that is the initial sender or final target
of messages and delivery status.
MSRP relay: an MSRP node that forwards messages and delivery status
and may provide policy enforcement. Relays can fragment and
reassemble portions of messages.
Message: arbitrary MIME [13][14] content that one client wishes to
send to another. For the purposes of this specification, a
complete MIME body as opposed to a portion of a complete message.
chunk: a portion of a complete message delivered in a SEND request.
end-to-end: delivery of data from the initiating client to the final
target client.
hop: delivery of data between one MSRP node and an adjacent node.
3. Protocol Overview
With the introduction of this extension, MSRP has the concept of both
clients and relays. Clients send messages to relays and/or other
clients. Relays forward messages and message delivery status to
clients and other relays. Clients that can open TCP connections to
each other without intervening policy restrictions can communicate
directly with each other. Clients who are behind firewalls or who
need to use intermediaries for policy reasons can use the services of
a relay. Each client is responsible for enlisting the assistance of
one or more relays for its side of the communication.
Clients that use a relay operate by first opening a TLS connection
with a relay, authenticating, and retrieving an msrps: URI (from the
relay) that the client can provide to its peers to receive messages
Jennings, et al. Standards Track [Page 4]
^L
RFC 4976 MSRP Relays September 2007
later. There are several steps for doing this. First, the client
opens a TLS connection to its first relay, and verifies that the name
in the certificate matches the name of the relay to which it is
trying to connect. Such verification is performed according to the
procedures defined in Section 9.2. After verifying that it has
connected to the proper host, the client authenticates itself to the
relay using an AUTH request containing appropriate authentication
credentials. In a successful AUTH response, the relay provides an
msrps: URI associated with the path back to the client. The client
can then give this URI to other clients for end-to-end message
delivery.
When clients wish to send a short message, they issue a SEND request
with the entire contents of the message. If any relays are required,
they are included in the To-Path header. The leftmost URI in the To-
Path header is the next hop to deliver a request or response. The
rightmost URI in the To-Path header is the final target.
SEND requests contain headers that indicate how they are acknowledged
in a hop-by-hop form and in an end-to-end form. The default is that
SEND messages are acknowledged hop-by-hop. (Each relay that receives
a SEND request acknowledges receipt of the request before forwarding
the content to the next relay or the final target.) All other
requests are acknowledged end-to-end.
With the introduction of relays, the subtle semantics of the To-Path
header and the From-Path header become more relevant. The To-Path in
both requests and responses is the list of URIs that need to be
visited in order to reach the final target of the request or
response. The From-Path is the list of URIs that indicate how to get
back to the original sender of the request or response. These
headers differ from the To and From headers in SIP, which do not
"swap" from request to response. (Note that sometimes a request is
sent to or from an intermediary directly.)
When a relay forwards a request, it removes its address from the To-
Path header and inserts it as the first URI in the From-Path header.
For example, if the path from Alice to Bob is through relays A and B,
when B receives the request it contains path headers that look like
the following. (Note that MSRP does not permit line folding. A "\"
in the examples shows a line continuation due to limitations in line
length of this document. Neither the backslash nor the extra CRLF is
included in the actual request or response.)
To-Path: msrps://B.example.com/bbb;tcp \
msrps://Bob.example.com/bob;tcp
From-Path: msrps://A.example.com/aaa;tcp \
msrps://Alice.example.com/alice;tcp
Jennings, et al. Standards Track [Page 5]
^L
RFC 4976 MSRP Relays September 2007
After forwarding the request, the path headers look like this:
To-Path: msrps://Bob.example.com/bob;tcp
From-Path: msrps://B.example.com/bbb;tcp \
msrps://A.example.com/aaa;tcp \
msrps://Alice.example.com/alice;tcp
The sending of an acknowledgment for SEND requests is controlled by
the Success-Report and Failure-Report headers and works the same way
as in the base MSRP protocol. When a relay receives a SEND request,
if the Failure-Report is set to "yes", it means that the previous hop
is running a timer and the relay needs to send a response to the
request. If the final response conveys an error, the previous hop is
responsible for constructing the error report and sending it back to
the original sender of the message. The 200 response acknowledges
receipt of the request so that the previous hop knows that it is no
longer responsible for the request. If the relay knows that it will
not be able to deliver the request and the Failure-Report is set to
any value other than "no", then it sends a REPORT to tell the sender
about the error. If the Failure-Report is set to "yes", then after
the relay is done sending the request to the next hop it starts
running a timer; if the timer expires before a response is received
from the next hop, the relay assumes that an error has happened and
sends a REPORT to the sender. If the Failure-Report is not set to
"yes", there is no need for the relay to run this timer.
The following example shows a typical MSRP session. The AUTH
requests are explained in a later section but left in the example for
call flow completeness.
Jennings, et al. Standards Track [Page 6]
^L
RFC 4976 MSRP Relays September 2007
Alice a.example.org b.example.net Bob
| | | |
|::::::::::::::::::::>| connection opened |<::::::::::::::::::::|
|--- AUTH ----------->| |<-- AUTH ------------|
|<-- 200 OK-----------| |--- 200 OK---------->|
| | | |
.... time passes ....
| | | |
|--- SEND ----------->| | |
|<-- 200 OK ----------|:::::::::::::::::::>| (slow link) |
| |--- SEND ---------->| |
| |<-- 200 OK ---------|--- SEND ----------->|
| | | ....>|
| | | ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT ----------|
| |<-- REPORT ---------| |
|<-- REPORT ----------| | |
| | | |
The SEND and REPORT messages are shown below to illustrate the To-
Path and From-Path headers. (Note that MSRP does not permit line
folding. A "\" in the examples shows a line continuation due to
limitations in line length of this document. Neither the backslash,
nor the extra CRLF is included in the actual request or response.)
MSRP 6aef SEND
To-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://alice.example.org:7965/bar;tcp
Success-Report: yes
Byte-Range: 1-*/*
Message-ID: 87652
Content-Type: text/plain
Hi Bob, I'm about to send you file.mpeg
-------6aef$
MSRP 6aef 200 OK
To-Path: msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://a.example.org:9000/kjfjan;tcp
Message-ID: 87652
-------6aef$
Jennings, et al. Standards Track [Page 7]
^L
RFC 4976 MSRP Relays September 2007
MSRP juh76 SEND
To-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
Success-Report: yes
Message-ID: 87652
Byte-Range: 1-*/*
Content-Type: text/plain
Hi Bob, I'm about to send you file.mpeg
-------juh76$
MSRP juh76 200 OK
To-Path: msrps://a.example.org:9000/kjfjan;tcp
From-Path: msrps://b.example.net:9000/aeiug;tcp
Message-ID: 87652
-------juh76$
MSRP xght6 SEND
To-Path: msrps://bob.example.net:8145/foo;tcp
From-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
Success-Report: yes
Message-ID: 87652
Byte-Range: 1-*/*
Content-Type: text/plain
Hi Bob, I'm about to send you file.mpeg
-------xght6$
MSRP xght6 200 OK
To-Path: msrps://b.example.net:9000/aeiug;tcp
From-Path: msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Jennings, et al. Standards Track [Page 8]
^L
RFC 4976 MSRP Relays September 2007
MSRP yh67 REPORT
To-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Byte-Range: 1-39/39
Status: 000 200 OK
-------yh67$
MSRP yh67 REPORT
To-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Byte-Range: 1-39/39
Status: 000 200 OK
-------yh67$
MSRP yh67 REPORT
To-Path: msrps://alice.example.org:7965/bar;tcp
From-Path: msrps://a.example.org:9000/kjfjan;tcp \
msrps://b.example.net:9000/aeiug;tcp \
msrps://bob.example.net:8145/foo;tcp
Message-ID: 87652
Byte-Range: 1-39/39
Status: 000 200 OK
-------yh67$
When sending large content, the client may split up a message into
smaller pieces; each SEND request might contain only a portion of the
complete message. For example, when Alice sends Bob a 4-GB file
called "file.mpeg", she sends several SEND requests each with a
portion of the complete message. Relays can repack message fragments
en route. As individual parts of the complete message arrive at the
final destination client, the receiving client can optionally send
REPORT requests indicating delivery status.
MSRP nodes can send individual portions of a complete message in
multiple SEND requests. As relays receive chunks, they can
reassemble or re-fragment them as long as they resend the resulting
chunks in order. (Receivers still need to be prepared to receive
out-of-order chunks, however.) If the sender has set the Success-
Report header to "yes", once a chunk or complete message arrives at
the destination client, the destination will send a REPORT request
Jennings, et al. Standards Track [Page 9]
^L
RFC 4976 MSRP Relays September 2007
indicating that a chunk arrived end-to-end. This request travels
back along the reverse path of the SEND request. Unlike the SEND
request, which can be acknowledged along every hop, REPORT requests
are never acknowledged.
The following example shows a message being re-chunked through two
relays:
Alice a.example.org b.example.net Bob
| | | |
|--- SEND 1-3 ------->| | |
|<-- 200 OK ----------| | (slow link) |
|--- SEND 4-7 ------->|--- SEND 1-5 ------>| |
|<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->|
|--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>|
|<-- 200 OK ----------|<-- 200 OK ---------| ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT 1-3 ------|
| |<-- REPORT 1-3 -----|--- SEND 4-7 ------->|
|<-- REPORT 1-3 ------| | ...>|
| | |<-- REPORT 4-7 ----->|
| |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
|<-- REPORT 4-7 ------| | ..>|
| | |<-- 200 OK ----------|
| |<-- REPORT done-----|<-- REPORT done -----|
|<-- REPORT done -----| | |
| | | |
Relays only keep transaction states for a short time for each chunk.
Delivery over each hop should take no more than 30 seconds after the
last byte of data is sent. Client applications define their own
implementation-dependent timers for end-to-end message delivery.
For client-to-client communication, the sender of a message typically
opens a new TCP connection (with or without TLS) if one is needed.
Relays reuse existing connections first, but can open new connections
(typically to other relays) to deliver requests such as SEND or
REPORT. Responses can only be sent over existing connections.
The relationship between MSRP and signaling protocols (such as SIP)
is unchanged by this document, and is as described in [11]. An
example of an SDP exchange for an MSRP session involving relays is
shown in Section 11.
Jennings, et al. Standards Track [Page 10]
^L
RFC 4976 MSRP Relays September 2007
3.1. Authorization Overview
A key element of this protocol is that it cannot introduce open
relays, with all the associated problems they create, including DoS
attacks. A message is only forwarded by a relay if it is either
going to or coming from a client that has authenticated to the relay
and been authorized for relaying messages on that particular session.
Because of this, clients use an AUTH message to authenticate to a
relay and get a URI that can be used for forwarding messages.
If a client wishes to use a relay, it sends an AUTH request to the
relay. The client authenticates the relay using the relay's TLS
certificate. The client uses HTTP Digest authentication [1] to
authenticate to the relay. When the authentication succeeds, the
relay returns a 200 response that contains the URI that the client
can use in the MSRP path for the relay.
A typical challenge response flow is shown below:
Alice a.example.org
| |
|::::::::::::::::::::>|
|--- AUTH ----------->|
|<- 401 Unauthorized -|
|--- AUTH ----------->|
|<-- 200 OK-----------|
| |
The URI that the client should use is returned in the Use-Path header
of the 200.
Note that URIs returned to the client are effectively secret tokens
that should be shared only with the other MSRP client in a session.
For that reason, the client MUST NOT reuse the same URI for multiple
sessions, and needs to protect these URIs from eavesdropping.
4. New Protocol Elements
4.1. The AUTH Method
AUTH requests are used by clients to create a handle they can use to
receive incoming requests. AUTH requests also contain credentials
used to authenticate a client and authorization policy used to block
Denial of Service attacks.
In response to an AUTH request, a successful response contains a Use-
Path header with a list of URIs that the client can give to its peers
to route responses back to the client.
Jennings, et al. Standards Track [Page 11]
^L
RFC 4976 MSRP Relays September 2007
4.2. The Use-Path Header
The Use-Path header is a list of URIs provided by an MSRP relay in
response to a successful AUTH request. This list of URIs can be used
by the MSRP client that sent the AUTH request to receive MSRP
requests and to advertise this list of URIs, for example, in a
session description. URIs in the Use-Path header MUST include a
fully qualified domain name (as opposed to a numeric IP address) and
an explicit port number.
The URIs in the Use-Path header are in the same order that the
authenticating client uses them in a To-Path header. Instructions on
forming To-Path headers and SDP [7] path attributes from information
in the Use-Path header are provided in Section 5.1.
4.3. The HTTP Authentication "WWW-Authenticate" Header
The "WWW-Authenticate" header contains a challenge token used in the
HTTP Digest authentication procedure (from RFC 2617 [1]). The usage
of HTTP Digest authentication in MSRP is described in detail in
Section 5.1.
4.4. The HTTP Authentication "Authorization" Header
The "Authorization" header contains authentication credentials for
HTTP Digest authentication (from RFC 2617 [1]). The usage of HTTP
Digest authentication in MSRP is described in detail in Section 5.1.
4.5. The HTTP Authentication "Authentication-Info" Header
The "Authentication-Info" header contains future challenges to be
used for HTTP Digest authentication (from RFC 2617 [1]). The usage
of HTTP Digest authentication in MSRP is described in detail in
Section 5.1.
4.6. Time-Related Headers
The Expires header in a request provides a relative time after which
the action implied by the method of the request is no longer of
interest. In a request, the Expires header indicates how long the
sender would like the request to remain valid. In a response, the
Expires header indicates how long the responder considers this
information relevant. Specifically, an Expires header in an AUTH
request indicates how long the provided URIs will be valid.
Jennings, et al. Standards Track [Page 12]
^L
RFC 4976 MSRP Relays September 2007
The Min-Expires header contains the minimum duration a server will
permit in an Expires header. It is sent only in 423 "Interval Out-
of-Bounds" responses. Likewise, the Max-Expires header contains the
maximum duration a server will permit in an Expires header.
5. Client Behavior
5.1. Connecting to Relays Acting on Your Behalf
Clients that want to use the services of a relay or list of relays
need to send an AUTH request to each relay that will act on their
behalf. (For example, some organizations could deploy an "intra-org"
relay and an "extra-org" relay.) The inner relay is used to tunnel
the AUTH requests to the outer relay. For example, the client will
send an AUTH to intra-org and get back a path that can be used for
forwarding through intra-org. The client would then send a second
AUTH destined to extra-org but sent through intra-org. The intra-org
relay forwards this to extra-org and extra-org returns a path that
can be used to forward messages from another destination to extra-org
to intra-org and then on to this client. Each relay authenticates
the client. The client authenticates the first relay and each relay
authenticates the next relay.
Clients can be configured (typically, through discovery or manual
provisioning) with a list of relays they need to use. They MUST be
able to form a connection to the first relay and send an AUTH command
to get a URI that can be used in a To-Path header. The client can
authenticate its first relay by looking at the relay's TLS
certificate. The client MUST authenticate itself to each of its
relays using HTTP Digest authentication [1] (see Section 9.1 for
details).
The relay returns a URI, or list of URIs, in the "Use-Path" header of
a success response. Each URI SHOULD be used for only one unique
session. These URIs are used by the client in the path attribute
that is sent in the SDP to set up the session, and in the To-Path
header of outgoing requests. To form the To-Path header for outgoing
requests, the client takes the list of URIs in the Use-Path header
after the outermost authentication and appends the list of URIs
provided in the path attribute in the peer's session description. To
form the SDP path attribute to provide to the peer, the client
reverses the list of URIs in the Use-Path header (after the outermost
authentication), and appends the client's own URI.
For example, "A" has to traverse its own relays "B" and "C", and
then relays "D" and "E" in domain2 to reach "F". Client "A" will
authenticate with its relays "B" and "C" and eventually receive a
Use-Path header containing "B C". Client "A" reverses the list
Jennings, et al. Standards Track [Page 13]
^L
RFC 4976 MSRP Relays September 2007
(now "C B") and appends its own URI (now "C B A"), and provides
this list to "F" in a path SDP attribute. Client "F" sends its
SDP path list "D E F", which client "A" appends to the Use-Path
list it received "B C". The resulting To-Path header is "B C D E
F".
domain 1 domain 2
---------------- -----------------
client relays relays client
A ----- B -- C -------- D -- E ----- F
Use-Path returned by C: B C
path: attribute generated by A: C B A
path: attribute received from F: D E F
To-Path header generated by A: B C D E F
The initial AUTH request sent to a relay by a client will generally
not contain an Authorization header, since the client has no
challenge to which it can respond. In response to an AUTH request
that does not contain an Authorization header, a relay MUST respond
with a "401 Unauthorized" response containing a WWW-Authenticate
header. The WWW-Authenticate header is formed as described in RFC
2617 [1], with the restrictions and modifications described in
Section 9.1. The realm chosen by the MSRP relay in such a challenge
is a matter of administrative policy. Because a single relay does
not have multiple protection spaces in MSRP, it is not unreasonable
to always use the relay's hostname as the realm.
Upon receiving a 401 response to a request, the client SHOULD fetch
the realm from the WWW-Authenticate header in the response and retry
the request, including an Authorization header with the correct
credentials for the realm. The Authorization header is formed as
described in RFC 2617 [1], with the restrictions and modifications
described in Section 9.1.
When a client wishes to use more than one relay, it MUST send an AUTH
request to each relay it wishes to use. Consider a client A, that
wishes messages to flow from A to the first relay, R1, then on to a
second relay, R2. This client will do a normal AUTH with R1. It
will then do an AUTH transaction with R2 that is routed through R1.
The client will form this AUTH message by setting the To-Path to
msrps://R1;tcp msrps://R2;tcp. R1 will forward this request onward
to R2.
When sending an AUTH request, the client MAY add an Expires header to
request a MSRP URI that is valid for no longer than the provided
interval (a whole number of seconds). The server will include an
Jennings, et al. Standards Track [Page 14]
^L
RFC 4976 MSRP Relays September 2007
Expires header in a successful response indicating how long its URI
from the Use-Path will be valid. Note that each server can return an
independent expiration time.
Note that MSRP does not permit line folding. A "\" in the examples
shows a line continuation due to limitations in line length of this
document. Neither the backslash nor the extra CRLF is included in
the actual request or response.
(Alice opens a TLS connection to intra.example.com and sends an AUTH
request to initiate the authentication process.)
MSRP 49fh AUTH
To-Path: msrps://alice@intra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
-------49fh$
(Alice's relay challenges the AUTH request.)
MSRP 49fh 401 Unauthorized
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://alice@intra.example.com;tcp
WWW-Authenticate: Digest realm="intra.example.com", qop="auth", \
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"
-------49fh$
(Alice responds to the challenge.)
MSRP 49fi AUTH
To-Path: msrps://alice@intra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
Authorization: Digest username="Alice",
realm="intra.example.com", \
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", \
qop=auth, nc=00000001, cnonce="0a4f113b", \
response="6629fae49393a05397450978507c4ef1"
-------49fi$
(Alice's relay confirms that Alice is an authorized user. As a
matter of local policy, it includes an "Authentication-Info" header
with a new nonce value to expedite future AUTH requests.)
Jennings, et al. Standards Track [Page 15]
^L
RFC 4976 MSRP Relays September 2007
MSRP 49fi 200 OK
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://alice@intra.example.com;tcp
Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp
Authentication-Info: nextnonce="40f2e879449675f288476d772627370a",\
rspauth="7327570c586207eca2afae94fc20903d", \
cnonce="0a4f113b", nc=00000001, qop=auth
Expires: 900
-------49fi$
(Alice now sends an AUTH request to her "external" relay through her
"internal" relay, using the URI she just obtained; the AUTH request
is challenged.)
MSRP mnbvw AUTH
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
-------mnbvw$
MSRP m2nbvw AUTH
To-Path: msrps://extra.example.com;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
-------m2nbvw$
MSRP m2nbvw 401 Unauthorized
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://extra.example.com;tcp
WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO"
-------m2nbvw$
MSRP mnbvw 401 Unauthorized
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO"
-------mnbvw$
(Alice replies to the challenge with her credentials and is then
authorized to use the "external" relay).
Jennings, et al. Standards Track [Page 16]
^L
RFC 4976 MSRP Relays September 2007
MSRP m3nbvx AUTH
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
From-Path: msrps://alice.example.com:9892/98cjs;tcp
Authorization: Digest username="Alice",
realm="extra.example.com", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \
qop=auth, nc=00000001, cnonce="85a0dca8", \
response="cb06c4a77cd90918cd7914432032e0e6"
-------m3nbvx$
MSRP m4nbvx AUTH
To-Path: msrps://extra.example.com;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
Authorization: Digest username="Alice",
realm="extra.example.com", \
nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \
qop=auth, nc=00000001, cnonce="85a0dca8", \
response="cb06c4a77cd90918cd7914432032e0e6"
-------m4nbvx$
MSRP m4nbvx 200 OK
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://extra.example.com;tcp
Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com:9000/mywdEe1233;tcp
Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \
rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \
cnonce="85a0dca8", nc=00000001, qop=auth
Expires: 1800
-------m4nbvx$
MSRP m3nbvx 200 OK
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp \
msrps://extra.example.com:9000/mywdEe1233;tcp
Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \
rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \
cnonce="85a0dca8", nc=00000001, qop=auth
Expires: 1800
-------m3nbvx$
Jennings, et al. Standards Track [Page 17]
^L
RFC 4976 MSRP Relays September 2007
5.2. Sending Requests
The procedure for forming SEND and REPORT requests is identical for
clients whether or not relays are involved. The specific procedures
are described in Section 7 of the core MSRP protocol.
As usual, once the next-hop URI is determined, the client MUST find
the appropriate address, port, and transport to use and then check if
there is already a suitable existing connection to the next-hop
target. If so, the client MUST send the request over the most
suitable connection. Suitability MAY be determined by a variety of
factors such as measured load and local policy, but in most simple
implementations a connection will be suitable if it exists and is
active.
5.3. Receiving Requests
The procedure for receiving requests is identical for clients whether
or not relays are involved.
5.4. Managing Connections
Clients should open a connection whenever they wish to deliver a
request and no suitable connection exists. For connections to
relays, the client should leave a connection up until no sessions
have used it for a locally defined period of time, which defaults to
5 minutes for foreign relays and one hour for the client's relays.
6. Relay Behavior
6.1. Handling Incoming Connections
When a relay receives an incoming connection on a port configured for
TLS, it includes a client CertificateRequest in the same record in
which it sends its ServerHello. If the TLS client provides a
certificate, the server verifies it and continues if the certificate
is valid and rooted in a trusted authority. If the TLS client does
not provide a certificate, the server assumes that the client is an
MSRP endpoint and invokes Digest authentication. Once a TCP or TLS
channel is negotiated, the server waits for up to 30 seconds to
receive an MSRP request over the channel. If no request is received
in that time, the server closes the connection. If no successful
requests are sent during this probationary period, the server closes
the connection. Likewise, if several unsuccessful requests are sent
during the probation period and no requests are sent successfully,
the server SHOULD close the connection.
Jennings, et al. Standards Track [Page 18]
^L
RFC 4976 MSRP Relays September 2007
6.2. Generic Request Behavior
Upon receiving a new request, relays first verify the validity of the
request. Relays then examine the first URI in the To-Path header and
remove this URI if it matches a URI corresponding to the relay. If
the request is not addressed to the relay, the relay immediately
drops the corresponding connection over which the request was
received.
6.3. Receiving AUTH Requests
When a relay receives an AUTH request, the first thing it does is to
authenticate and authorize the previous hop and the client at the far
end. If there are no other relays between this relay and the client,
then these are the same thing.
When the previous hop is a relay, authentication is done with TLS
using mutual authentication. If the TLS client presented a host
certificate, the relay checks that the subjectAltName in the
certificate of the TLS client matches the hostname in the first From-
Path URI. If the TLS client doesn't provide a host certificate, the
relay assumes the TLS client is an MSRP client and sends it a
challenge.
Authorization is a matter of local policy at the relay. Many relays
will choose to authorize all relays that can be authenticated,
possibly in conjunction with a blacklisting mechanism. Relays
intended to operate only within a limited federation may choose to
authorize only those relays whose identity appears in a provisioned
list. Other authorization policies may also be applied.
When the previous hop is a client, the previous hop is the same as
the identity of the client. The relay checks the credentials
(username and password) provided by the client in the Authorization
header and checks if this client is allowed to use the relay. If the
client is not authorized, the relay returns a 403 response. If the
client has requested a particular expiration time in an Expires
header, the relay needs to check that the time is acceptable to it
and, if not, return an error containing a Min-Expires or Max-Expires
header, as appropriate.
Next the relay will generate an MSRP URI that allows messages to be
forwarded to or from this previous hop. If the previous hop was a
relay authenticated by mutual TLS, then the URI MUST be valid to
route across any connection the relay has to the previous hop relay.
If the previous hop is a client, then the URI MUST only be valid to
Jennings, et al. Standards Track [Page 19]
^L
RFC 4976 MSRP Relays September 2007
route across the same connection over which the AUTH request was
received. If the client's connection is closed and then reopened,
the URI MUST be invalidated.
If the AUTH request contains an Expires header, the relay MUST ensure
that the URI is invalidated after the expiry time. The URI MUST
contain at least 64 bits of cryptographically random material so that
it is not guessable by attackers. If a relay is requested to forward
a message for which the URI is not valid, the relay MUST discard the
message and MAY send a REPORT indicating that the AUTH URI was bad.
A successful AUTH response returns a Use-Path header that contains an
MSRP URI that the client can use. It also returns an Expires header
that indicates how long the URI will be valid (expressed as a whole
number of seconds).
If a relay receives several unsuccessful AUTH requests from a client
that is directly connected to it via TLS, the relay SHOULD terminate
the corresponding connection. Similarly, if a relay forwards several
failed AUTH requests to the same destination that originate from a
client that is directly connected to it via TLS, the relay SHOULD
terminate the corresponding connection. Determination of a remote
AUTH failure can be made by observing an AUTH request containing an
Authorization header that triggers a 401 response without a
"stale=TRUE" indication. These preventive measures apply only to a
connection between a relay and a client; a relay SHOULD NOT use
excessive AUTH request failures as a reason to terminate a connection
with another relay.
6.4. Forwarding
Before any request is forwarded, the relay MUST check that the first
URI in the To-Path header corresponds to a URI that this relay has
created and handed out in the Use-Path header of an AUTH request.
Next it verifies that either 1) the next hop is the next hop back
toward the client that obtained this URI, or 2) the previous hop was
the correct previous hop coming from the client that obtained this
URI.
Since transact-id values are not allowed to conflict on a given
connection, a relay will generally need to construct a new transact-
id value for any request that it forwards.
Jennings, et al. Standards Track [Page 20]
^L
RFC 4976 MSRP Relays September 2007
6.4.1. Forwarding SEND Requests
If an incoming SEND request contains a Failure-Report header with a
value of "yes", an MSRP relay that receives that SEND request MUST
respond with a final response immediately. A 200-class response
indicates the successful receipt of a message fragment but does not
mean that the message has been forwarded on to the next hop. The
final response to the SEND MUST be sent only to the previous hop,
which could be an MSRP relay or the original sender of the SEND
request.
If the Failure-Report header is "yes", then the relay MUST run a
timer to detect if transmission to the next hop fails. The timer
starts when the last byte of the message has been sent to the next
hop. If after 30 seconds the next hop has not sent any response,
then the relay MUST construct a REPORT with a status code of 408 to
indicate a timeout error happened sending the message, and send the
REPORT to the original sender of the message.
If the Failure-Report header is "yes" or "partial", and if there is a
problem processing the SEND request or if an error response is
received for that SEND request, then the relay MUST respond with an
appropriate error response in a REPORT back to the original source of
the message.
The MSRP relay MAY further break up the message fragment received in
the SEND request into smaller fragments and forward them to the next
hop in separate SEND requests. It MAY also combine message fragments
received before or after this SEND request, and forward them out in a
single SEND request to the next hop identified in the To-Path header.
The MSRP relay MUST NOT combine message fragments from SEND requests
with different values in the Message-ID header.
The MSRP relay MAY choose whether to further fragment the message, or
combine message fragments, or send the message as is, based on some
policy that is administered, or based on the network speed to the
next hop, or any other mechanism.
If the MSRP relay has knowledge of the byte range that it will
transmit to the next hop, it SHOULD update the Byte-Range header in
the SEND request appropriately.
Before forwarding the SEND request to the next hop, the MSRP relay
MUST inspect the first URI in the To-Path header. If it indicates
this relay, the relay removes this URI from the To-Path header and
inserts this URI in the From-Path header before any other URIs. If
it does not indicate this relay, there has been an error in
Jennings, et al. Standards Track [Page 21]
^L
RFC 4976 MSRP Relays September 2007
forwarding at a previous hop. In this case, the relay SHOULD discard
the message, and if the Failure-Report header is set to "yes", the
relay SHOULD generate a failure report.
6.4.2. Forwarding Non-SEND Requests
An MSRP relay that receives any request other than a SEND request
(including new methods unknown to the relay) first follows the
validation and authorization rules for all requests. Then the relay
moves its URI from the beginning of the To-Path headers to the
beginning of the From-Path header and forwards the request on to the
next hop. If it already has a connection to the next hop, it SHOULD
use this connection and not form a new connection. If no suitable
connection exists, the relay opens a new connection.
Requests with an unknown method are forwarded as if they were REPORT
requests. An MSRP node MAY be configured to block unknown methods
for security reasons.
6.4.3. Handling Responses
Relays receiving a response first verify that the first URI in the
To-Path corresponds to itself; if not, the response SHOULD be
dropped. Likewise, if the message cannot be parsed, the relay MUST
drop the response. Next the relay determines if there are additional
URIs in the To-Path. (For responses to SEND requests there will be
no additional URIs, whereas responses to AUTH requests have
additional URIs directing the response back to the client.)
If the response matches an existing transaction, then that
transaction is completed and any timers running on it can be removed.
If the response is a non 200 response, and the original request was a
SEND request that had a Failure-Report header with a value other than
"no", then the relay MUST send a REPORT indicating the nature of the
failure. The response code received by the relay is used to form the
status line in the REPORT that the relay sends.
If there are additional URIs in the To-Path header, the relay MUST
then move its URI from the To-Path header, insert its URI in front of
any other URIs in the From-Path header, and forward the response to
the next URI in the To-Path header. The relay sends the request over
the best connection that corresponds to the next URI in the To-Path
header. If this connection has closed, then the response is silently
discarded.
Jennings, et al. Standards Track [Page 22]
^L
RFC 4976 MSRP Relays September 2007
6.5. Managing Connections
Relays should keep connections open as long as possible. If a
connection has not been used in a significant time (more than one
hour), it MAY be closed. If the relay runs out of resources and can
no longer establish new connections, it SHOULD start closing existing
connections. It MAY choose to close the connections based on a least
recently used basis.
7. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in RFC 4234 [10].
; This ABNF imports all the definitions in the ABNF of RFC 4975.
header =/ Expires / Min-Expires / Max-Expires / Use-Path /
WWW-Authenticate / Authorization / Authentication-Info
; this adds to the rule in RFC 4975
mAUTH = %x41.55.54.48 ; AUTH in caps
method =/ mAUTH
; this adds to the rule in RFC 4975
WWW-Authenticate = "WWW-Authenticate:" SP "Digest" SP digest-param
*("," SP digest-param)
digest-param = ( realm / nonce / [ opaque ] / [ stale ] / [
algorithm ] / qop-options / [auth-param] )
realm = "realm=" realm-value
realm-value = quoted-string
auth-param = token "=" ( token / quoted-string )
nonce = "nonce=" nonce-value
nonce-value = quoted-string
opaque = "opaque=" quoted-string
stale = "stale=" ( "true" / "false" )
algorithm = "algorithm=" ( "MD5" / token )
qop-options = "qop=" DQUOTE qop-list DQUOTE
qop-list = qop-value *( "," qop-value )
qop-value = "auth" / token
Authorization = "Authorization:" SP credentials
credentials = "Digest" SP digest-response
*( "," SP digest-response)
Jennings, et al. Standards Track [Page 23]
^L
RFC 4976 MSRP Relays September 2007
digest-response = ( username / realm / nonce / response / [
algorithm ] / cnonce / [opaque] / message-qop /
[nonce-count] / [auth-param] )
username = "username=" username-value
username-value = quoted-string
message-qop = "qop=" qop-value
cnonce = "cnonce=" cnonce-value
cnonce-value = nonce-value
nonce-count = "nc=" nc-value
nc-value = 8LHEX
response = "response=" request-digest
request-digest = DQUOTE 32LHEX DQUOTE
LHEX = DIGIT / %x61-66 ;lowercase a-f
Authentication-Info = "Authentication-Info:" SP ainfo
*("," ainfo)
ainfo = nextnonce / message-qop
/ response-auth / cnonce
/ nonce-count
nextnonce = "nextnonce=" nonce-value
response-auth = "rspauth=" response-digest
response-digest = DQUOTE *LHEX DQUOTE
Expires = "Expires:" SP 1*DIGIT
Min-Expires = "Min-Expires:" SP 1*DIGIT
Max-Expires = "Max-Expires:" SP 1*DIGIT
Use-Path = "Use-Path:" SP MSRP-URI *(SP MSRP-URI)
8. Finding MSRP Relays
When resolving an MSRP URI that contains an explicit port number, an
MSRP node follows the rules in Section 6 of the MSRP base
specification. MSRP URIs exchanged in SDP and in To-Path and From-
Path headers in non-AUTH requests MUST have an explicit port number.
(The only message in this specification that can have an MSRP URI
without an explicit port number is in the To-Path header in an AUTH
request.) Similarly, if the authority component of an msrps: URI
contains an IPv4 address or an IPv6 reference, a port number MUST be
present.
The following rules allow MSRP clients to discover MSRP relays more
easily in AUTH requests. If the authority component contains a
domain name and an explicit port number is provided, attempt to look
up a valid address record (A or AAAA) for the domain name. Connect
using TLS over the default transport (TCP) with the provided port
number.
Jennings, et al. Standards Track [Page 24]
^L
RFC 4976 MSRP Relays September 2007
If a domain name is provided but no port number, perform a DNS SRV
[4] lookup for the '_msrps' service and '_tcp' transport at the
domain name, and follow the Service Record (SRV) selection algorithm
defined in that specification to select the entry. (An '_msrp'
service is not defined, since AUTH requests are only sent over TLS.)
If no SRVs are found, try an address lookup (A or AAAA) for the
domain name. Connect using TLS over the default transport (TCP) with
the default port number (2855). Note that AUTH requests MUST only be
sent over a TLS-protected channel. An SRV lookup in the example.com
domain might return:
;; in example.com. Pri Wght Port Target
_msrps._tcp IN SRV 0 1 9000 server1.example.com.
_msrps._tcp IN SRV 0 2 9000 server2.example.com.
If implementing a relay farm, it is RECOMMENDED that each member of
the relay farm have an SRV entry. If any members of the farm have
multiple IP addresses (for example, an IPv4 and an IPv6 address),
each of these addresses SHOULD be registered in DNS as separate A or
AAAA records corresponding to a single target.
9. Security Considerations
This section first describes the security mechanisms available for
use in MSRP. Then the threat model is presented. Finally, we list
implementation requirements related to security.
9.1. Using HTTP Authentication
AUTH requests MUST be authenticated. The authentication mechanism
described in this specification uses HTTP Digest authentication.
HTTP Digest authentication is performed as described in RFC 2617 [1],
with the following restrictions and modifications:
o Clients MUST NOT attempt to use Basic authentication, and relays
MUST NOT request or accept Basic authentication.
o The use of a qop value of auth-int makes no sense for MSRP.
Integrity protection is provided by the use of TLS. Consequently,
MSRP relays MUST NOT indicate a qop of auth-int in a challenge.
o The interaction between the MD5-sess algorithm and the nextnonce
mechanism is underspecified in RFC 2617 [1]; consequently, MSRP
relays MUST NOT send challenges indicating the MD5-sess algorithm.
o Clients SHOULD consider the protection space within a realm to be
scoped to the authority portion of the URI, without regard to the
contents of the path portion of the URI. Accordingly, relays
Jennings, et al. Standards Track [Page 25]
^L
RFC 4976 MSRP Relays September 2007
SHOULD NOT send the "domain" parameter on the "WWW-Authenticate"
header, and clients MUST ignore it if present.
o Clients and relays MUST include a qop parameter in all "WWW-
Authenticate" and "Authorization" headers. Note that the value of
the qop parameter in a "WWW-Authenticate" header is quoted, but
the value of the qop parameter in an "Authorization" header or
"Authentication-Info" header is not quoted.
o Clients MUST send cnonce and nonce-count parameters in all
"Authorization" headers.
o The request-URI to be used in calculating H(A2) is the rightmost
URI in the To-Path header.
o Relays MUST include rspauth, cnonce, nc, and qop parameters in a
"Authentication-Info" header for all "200 OK" responses to an AUTH
request.
Note that the BNF in RFC 2617 has a number of errors. In particular,
the value of the uri parameter MUST be in quotes; further, the
parameters in the Authentication-Info header MUST be separated by
commas. The BNF in this document is correct, as are the examples in
RFC 2617 [1].
The use of the nextnonce and nc parameters is supported as described
in RFC 2617 [1], which provides guidance on how and when they should
be used. As a slight modification to the guidance provided in RFC
2617, implementors of relays should note that AUTH requests cannot be
pipelined; consequently, there is no detrimental impact on throughput
when relays use the nextnonce mechanism.
See Section 5.1 for further information on the procedures for client
authentication.
9.2. Using TLS
TLS is used to authenticate relays to senders and to provide
integrity and confidentiality for the headers being transported.
MSRP clients and relays MUST implement TLS. Clients MUST send the
TLS ClientExtendedHello extended hello information for server name
indication as described in RFC 4366 [5]. A TLS cipher-suite of
TLS_RSA_WITH_AES_128_CBC_SHA [6] MUST be supported (other cipher-
suites MAY also be supported). A relay MUST act as a TLS server and
present a certificate with its identity in the SubjectAltName using
the choice type of dnsName. Relay-to-relay connections MUST use TLS
with mutual authentication. Client-to-relay communications MUST use
TLS for AUTH requests and responses.
Jennings, et al. Standards Track [Page 26]
^L
RFC 4976 MSRP Relays September 2007
The SubjectAltName in the certificate received from a relay MUST
match the hostname part of the URI, and the certificate MUST be valid
according to RFC 3280 [12], including having a date that is valid and
being signed by an acceptable certification authority. After
validating that such is the case, the device that initiated the TLS
connection can assume that it has connected to the correct relay.
This document does not define procedures for using mutual
authentication between an MSRP client and an MSRP relay.
Authentication of clients is handled using the AUTH method via the
procedures described in Section 5.1 and Section 6.3. Other
specifications may define the use of TLS mutual authentication for
the purpose of authenticating users associated with MSRP clients.
Unless operating under such other specifications, MSRP clients SHOULD
present an empty certificate list (if one is requested by the MSRP
relay), and MSRP relays SHOULD ignore any certificates presented by
the client.
This behavior is defined specifically to allow forward-
compatibility with specifications that define the use of TLS for
client authentication.
Note: When relays are involved in a session, TCP without TLS is only
used when a user that does not use relays connects directly to the
relay of a user that is using relays. In this case, the client has
no way to authenticate the relay other than to use the URIs that form
a shared secret in the same way those URIs are used when no relays
are involved.
9.3. Threat Model
This section discusses the threat model and the broad mechanism that
needs to be in place to secure the protocol. The next section
describes the details of how the protocol mechanism meets the broad
requirements.
MSRP allows two peer-to-peer clients to exchange messages. Each peer
can select a set of relays to perform certain policy operations for
them. This combined set of relays is referred to as the route set.
A channel outside of MSRP always needs to exist, such as out-of-band
provisioning or an explicit rendezvous protocol such as SIP, that can
securely negotiate setting up the MSRP session and communicate the
route set to both clients. A client may trust a relay with certain
types of routing and policy decisions, but it might or might not
trust the relay with all the contents of the session. For example, a
relay being trusted to look for viruses would probably need to be
allowed to see all the contents of the session. A relay that helped
deal with traversal of the ISP's Network Address Translator (NAT)
Jennings, et al. Standards Track [Page 27]
^L
RFC 4976 MSRP Relays September 2007
would likely not be trusted with the contents of the session but
would be trusted to correctly forward messages.
Clients implicitly trust the relays through which they send and
receive messages to honor the routing indicated in those messages,
within the constraints of the MSRP protocol. Clients also need to
trust that the relays they use do not insert new messages on their
behalf or modify messages sent to or by the clients. It is worth
noting that some relays are in a position to cause a client to
misroute a message by maliciously modifying a Use-Path returned by a
relay further down the chain. However, this is not an additional
security threat because these same relays can also decide to misroute
a message in the first place. If the relay is trusted to route
messages, it is reasonable to trust it not to tamper with the Use-
Path header. If the relay cannot be trusted to route messages, then
it cannot be used.
Under certain circumstances, relays need to trust other relays not to
modify information between them and the client they represent. For
example, if a client is operating through Relay A to get to Relay B,
and Relay B is logging messages sent by the client, Relay B may be
required to authenticate that the messages they logged originate with
the client, and have not been modified or forged by Relay A. This
can be done by having the client sign the message.
Clients need to be able to authenticate that the relay they are
communicating with is the one they trust. Likewise, relays need to
be able to authenticate that the client is the one they are
authorized to forward information to. Clients need the option of
ensuring that information between the relay and the client is
integrity protected and confidential to elements other than the
relays and clients. To simplify the number of options, traffic
between relays is always integrity protected and encrypted regardless
of whether or not the client requests it. There is no way for the
clients to tell the relays what strength of cryptographic mechanisms
to use between relays other than to have the clients choose relays
that are administered to require an adequate level of security.
The system also needs to stop messages from being directed to relays
that are not supposed to see them. To keep the relays from being
used in Denial of Service (DoS) attacks, the relays never forward
messages unless they have a trust relationship with either the client
sending or the client receiving the message; further, they only
forward a message if it is coming from or going to the client with
which they have the trust relationship. If a relay has a trust
relationship with the client that is the destination of the message,
it should not send the message anywhere except to the client that is
the destination.
Jennings, et al. Standards Track [Page 28]
^L
RFC 4976 MSRP Relays September 2007
Some terminology used in this discussion: SClient is the client
sending a message and RClient is the client receiving a message.
SRelay is a relay the sender trusts and RRelay is a relay the
receiver trusts. The message will go from SClient to SRelay1 to
SRelay2 to RRelay2 to RRelay1 to RClient.
9.4. Security Mechanism
Confidentiality and privacy from elements not in the route set is
provided by using TLS on all the transports. Relays always use TLS.
A client can use unprotected TCP for peer-to-peer MSRP, but any time
a client communicates with its relay, it MUST use TLS.
The relays authenticate to the clients using TLS (but don't have to
do mutual TLS). Further, the use of the rspauth parameter in the
Authentication-Info header provides limited authentication of relays
to which the client is not directly connected. The clients
authenticate to the relays using HTTP Digest authentication. Relays
authenticate to each other using TLS mutual authentication.
By using Secure/Multipurpose Internet Mail Extensions (S/MIME) [3]
encryption, the clients can protect their actual message contents so
that the relays cannot see the contents. End-to-end signing is also
possible with S/MIME.
The complex part is making sure that relays cannot successfully be
instructed to send messages to a place where they should not. This
is done by having the client authenticate to the relay and having the
relay return a token. Messages that contain this token can be
relayed if they come from the client that got the token or if they
are being forwarded towards the client that got the token. The
tokens are the URIs that the relay places in the Use-Path header.
The tokens contain random material (defined in Section 6.3) so that
they are not guessable by attackers. The tokens need to be protected
so they are only ever seen by elements in the route set or other
elements that at least one of the parties trusts. If some third
party discovers the token that RRelay2 uses to forward messages to
RClient, then that third party can send as many messages as they want
to RRelay2 and it will forward them to RClient. The third party
cannot cause them to be forwarded anywhere except to RClient,
eliminating the open relay problems. SRelay1 will not forward the
message unless it contains a valid token.
When SClient goes to get a token from SRelay2, this request is
relayed through SRelay1. SRelay2 authenticates that it really is
SClient requesting the token, but it generates a token that is only
valid for forwarding messages to or from SRelay1. SRelay2 knows it
is connected to SRelay1 because of the mutual TLS.
Jennings, et al. Standards Track [Page 29]
^L
RFC 4976 MSRP Relays September 2007
The tokens are carried in the resource portion of the MSRP URIs. The
length of time the tokens are valid for is negotiated using the
Expire header in the AUTH request. Clients need to re-negotiate the
tokens using a new offer/answer [15] exchange (e.g., a SIP re-invite)
before the tokens expire.
Note that this scheme relies on relays as trusted nodes, acting on
behalf of the users authenticated to them. There is no security
mechanism to prevent relays on the path from inserting forged
messages, manipulating the contents of messages, sending messages in
a session to a party other than that specified by the sender, or from
copying them to a third party. However, the one-to-one binding
between session identifiers and sessions helps mitigate any damage
that can be caused by rogue relays by limiting the destinations to
which forged or modified messages can be sent to the two parties
involved in the session, and only for the duration of the session.
Additionally, the use of S/MIME encryption can be employed to limit
the utility of redirecting messages. Finally, clients can employ
S/MIME signatures to guarantee the authenticity of messages they
send, making it possible under some circumstances to detect relay
manipulation or the forging of messages.
Clients are not the only actors in the network who need to trust
relays to act in non-malicious ways. If a relay does not have a
direct TLS connection with the client on whose behalf it is acting
(i.e. There are one or more intervening relays), it is at the mercy
of any such intervening relays to accurately transmit the messages
sent to and from the client. If a stronger guarantee of the
authentic origin of a message is necessary (e.g. The relay is
performing logging of messages as part of a legal requirement), then
users of that relay can be instructed by their administrators to use
detached S/MIME signatures on all messages sent by their client. The
relay can enforce such a policy by returning a 415 response to any
SEND requests using a top-level MIME type other than "multipart/
signed". Such relays may choose to make policy decisions (such as
terminating sessions and/or suspending user authorization) if such
signatures fail to match the contents of the message.
Jennings, et al. Standards Track [Page 30]
^L
RFC 4976 MSRP Relays September 2007
10. IANA Considerations
10.1. New MSRP Method
This specification defines a new MSRP method, to be added to the
Methods sub-registry under the MSRP Parameters registry: AUTH. See
Section 5.1 for details on the AUTH method.
10.2. New MSRP Headers
This specification defines several new MSRP header fields, to be
added to the header-field sub-registry under the MSRP Parameters
registry:
o Expires
o Min-Expires
o Max-Expires
o Use-Path
o WWW-Authenticate
o Authorization
o Authentication-Info
10.3. New MSRP Response Codes
This specification defines one new MSRP status code, to be added to
the Status-Code sub-registry under the MSRP Parameters registry:
The 401 response indicates that an AUTH request contained no
credentials, an expired nonce value, or invalid credentials. The
response includes a "WWW-Authenticate" header containing a challenge
(among other fields); see Section 9.1 for further details. The
default response phrase for this response is "Unauthorized".
11. Example SDP with Multiple Hops
The following section shows an example SDP that could occur in a SIP
message to set up an MSRP session between Alice and Bob where Bob
uses a relay. Alice makes an offer with a path to Alice.
c=IN IP4 a.example.com
m=message 1234 TCP/MSRP *
a=accept-types: message/cpim text/plain text/html
a=path:msrp://a.example.com:1234/agic456;tcp
Jennings, et al. Standards Track [Page 31]
^L
RFC 4976 MSRP Relays September 2007
In this offer, Alice wishes to receive MSRP messages at
a.example.com. She wants to use TCP as the transport for the MSRP
session. She can accept message/cpim, text/plain, and text/html
message bodies in SEND requests. She does not need a relay to set up
the MSRP session.
To this offer, Bob's answer could look like:
c=IN IP4 bob.example.com
m=message 1234 TCP/TLS/MSRP *
a=accept-types: message/cpim text/plain
a=path:msrps://relay.example.com:9000/hjdhfha;tcp \
msrps://bob.example.com:1234/fuige;tcp
Here Bob wishes to receive the MSRP messages at bob.example.com. He
can accept only message/cpim and text/plain message bodies in SEND
requests and has rejected the text/html content offered by Alice. He
wishes to use a relay called relay.example.com for the MSRP session.
12. Acknowledgments
Many thanks to Avshalom Houri, Hisham Khartabil, Robert Sparks,
Miguel Garcia, Hans Persson, and Orit Levin, who provided detailed
proofreading and helpful text. Thanks to the following members of
the SIMPLE WG for spirited discussions on session mode: Chris
Boulton, Ben Campbell, Juhee Garg, Paul Kyzivat, Allison Mankin, Aki
Niemi, Pekka Pessi, Jon Peterson, Brian Rosen, Jonathan Rosenberg,
and Dean Willis.
13. References
13.1. Normative References
[1] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[2] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[3] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
Jennings, et al. Standards Track [Page 32]
^L
RFC 4976 MSRP Relays September 2007
[5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", RFC
4366, April 2006.
[6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[11] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The
Message Session Relay Protocol (MSRP)", RFC 4975, September
2007.
[12] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
13.2. Informative References
[13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[15] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
Jennings, et al. Standards Track [Page 33]
^L
RFC 4976 MSRP Relays September 2007
Appendix A. Implementation Considerations
This text is not necessary in order to implement MSRP in an
interoperable way, but is still useful as an implementation
discussion for the community. It is purely an implementation detail.
Note: The idea has been proposed of having a relay return a base URI
that the client can use to construct more URIs, but this allows third
parties that have had a session with the client to know URIs that the
relay will use for forwarding after the session with the third party
has ended. Effectively, this reveals the secret URIs to third
parties, which compromises the security of the solution, so this
approach is not used.
An alternative to this approach causes the relays to return a URI
that is divided into an index portion and a secret portion. The
client can encrypt its identifier and its own opaque data with the
secret portion, and concatenate this with the index portion to create
a plurality of valid URIs. When the relay receives one of these
URIs, it could use the index to look up the appropriate secret,
decrypt the client portion, and verify that it contains the client
identifier. The relay can then forward the request. The client does
not need to send an AUTH request for each URI it uses. This is an
implementation detail that is out of the scope of this document.
It is possible to implement forwarding requirements in a farm without
the relay saving any state. One possible implementation that a relay
might use is described in the rest of this section. When a relay
starts up, it could pick a cryptographically random 128-bit password
(K) and 128-bit initialization vector (IV). If the relay was
actually a farm of servers with the same DNS name, all the machines
in the farm would need to share the same K. When an AUTH request is
received, the relay forms a string that contains the expiry time of
the URI, an indication if the previous hop was mutual TLS
authenticated or not, and if it was, the name of the previous hop,
and if it was not, the identifier for the connection that received
the AUTH request. This string would be padded by appending a byte
with the value 0x80 then adding zero or more bytes with the value of
0x00 until the string length is a multiple of 16 bytes long. A new
random IV would be selected (it needs to change because it forms the
salt) and the padded string would be encrypted using AES-CBC with a
key of K. The IV and encrypted data and an SPI (security parameter
index) that changes each time K changes would be base 64 encoded and
form the resource portion of the request URI. The SPI allows the key
to be changed and for the system to know which K should be used.
Later when the relay receives this URI, it could decrypt it and check
that the current time was before the expiry time and check that the
message was coming from or going to the connection or location
Jennings, et al. Standards Track [Page 34]
^L
RFC 4976 MSRP Relays September 2007
specified in the URI. Integrity protection is not required because
it is extremely unlikely that random data that was decrypted would
result in a valid location that was the same as the one the message
was routing to or from. When implementing something like this,
implementors should be careful not to use a scheme like EBE that
would allows portions of encrypted tokens to be cut and pasted into
other URIs.
Authors' Addresses
Cullen Jennings
Cisco Systems, Inc.
170 West Tasman Dr.
MS: SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 421-9990
EMail: fluffy@cisco.com
Rohan Mahy
Plantronics
345 Encincal Street
Santa Cruz, CA 95060
USA
EMail: rohan@ekabal.com
Adam Roach
Estacado Systems
17210 Campbell Rd.
Suite 250
Dallas, TX 75252
USA
Phone: sip:adam@estacado.net
EMail: adam@estacado.net
Jennings, et al. Standards Track [Page 35]
^L
RFC 4976 MSRP Relays September 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Jennings, et al. Standards Track [Page 36]
^L
|