idnits 2.17.1 draft-ietf-simple-msrp-relays-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1585. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1575. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 573 has weird spacing: '... client rel...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2006) is 6497 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2617 (ref. '1') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3851 (ref. '3') (Obsoleted by RFC 5751) ** Obsolete normative reference: RFC 3546 (ref. '5') (Obsoleted by RFC 4366) ** Obsolete normative reference: RFC 3268 (ref. '6') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 2327 (ref. '7') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2234 (ref. '10') (Obsoleted by RFC 4234) == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-14 Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems, Inc. 4 Expires: January 14, 2007 R. Mahy 5 Plantronics 6 A. Roach 7 Estacado Systems 8 July 13, 2006 10 Relay Extensions for the Message Sessions Relay Protocol (MSRP) 11 draft-ietf-simple-msrp-relays-08.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 14, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 Two separate models for conveying instant messages have been defined. 45 Page-mode messages stand alone and are not part of a SIP (Session 46 Initiation Protocol) session, whereas Session-mode messages are set 47 up as part of a session using the SIP protocol. MSRP (Message 48 Session Relay Protocol) is a protocol for near real-time, peer-to- 49 peer exchanges of binary content without intermediaries, which is 50 designed to be signaled using a separate rendezvous protocol such as 51 SIP. This document introduces the notion of message relay 52 intermediaries to MSRP and describes the extensions necessary to use 53 them. 55 Table of Contents 57 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 58 2. Introduction and Requirements . . . . . . . . . . . . . . . . 4 59 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1 Authorization Overview . . . . . . . . . . . . . . . . . . 10 61 4. New Protocol Elements . . . . . . . . . . . . . . . . . . . . 11 62 4.1 The AUTH Method . . . . . . . . . . . . . . . . . . . . . 11 63 4.2 The Use-Path header . . . . . . . . . . . . . . . . . . . 11 64 4.3 The HTTP Authentication "WWW-Authenticate" header . . . . 12 65 4.4 The HTTP Authentication "Authorization" header . . . . . . 12 66 4.5 The HTTP Authentication "Authentication-Info" header . . . 12 67 4.6 Time-related headers . . . . . . . . . . . . . . . . . . . 12 68 5. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 12 69 5.1 Connecting to relays acting on your behalf . . . . . . . . 13 70 5.2 Sending requests . . . . . . . . . . . . . . . . . . . . . 17 71 5.3 Receiving Requests . . . . . . . . . . . . . . . . . . . . 18 72 5.4 Managing Connections . . . . . . . . . . . . . . . . . . . 18 73 6. Relay behavior . . . . . . . . . . . . . . . . . . . . . . . . 18 74 6.1 Handling Incoming Connections . . . . . . . . . . . . . . 18 75 6.2 Generic request behavior . . . . . . . . . . . . . . . . . 18 76 6.3 Receiving AUTH requests . . . . . . . . . . . . . . . . . 19 77 6.4 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 20 78 6.4.1 Forwarding SEND requests . . . . . . . . . . . . . . . 20 79 6.4.2 Forwarding non-SEND requests . . . . . . . . . . . . . 21 80 6.4.3 Handling Responses . . . . . . . . . . . . . . . . . . 22 81 6.5 Managing Connections . . . . . . . . . . . . . . . . . . . 22 82 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 22 83 8. Finding MSRP Relays . . . . . . . . . . . . . . . . . . . . . 24 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 85 9.1 Using HTTP Authentication . . . . . . . . . . . . . . . . 25 86 9.2 Using TLS . . . . . . . . . . . . . . . . . . . . . . . . 26 87 9.3 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 26 88 9.4 Security Mechanism . . . . . . . . . . . . . . . . . . . . 28 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 90 10.1 New MSRP Method . . . . . . . . . . . . . . . . . . . . . 30 91 10.2 New MSRP Headers . . . . . . . . . . . . . . . . . . . . . 30 92 10.3 New MSRP Response Codes . . . . . . . . . . . . . . . . . 30 93 11. Example SDP with multiple hops . . . . . . . . . . . . . . . 30 94 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 96 13.1 Normative References . . . . . . . . . . . . . . . . . . . 31 97 13.2 Informative References . . . . . . . . . . . . . . . . . . 32 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33 99 A. Implementation Considerations . . . . . . . . . . . . . . . . 33 100 Intellectual Property and Copyright Statements . . . . . . . . 35 102 1. Conventions and Definitions 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC-2119 [9]. 108 Below we list several definitions important to MSRP: 109 MSRP node: a host that implements the MSRP protocols as a Client or a 110 Relay. 111 MSRP Client: an MSRP node which is the initial sender or final target 112 of messages and delivery status. 113 MSRP Relay: an MSRP node which forwards messages and delivery status 114 and may provide policy enforcement. Relays can fragment and 115 reassemble portions of messages. 116 Message: arbitrary MIME[12][13] content which one client wishes to 117 send to another. For the purposes of this specification, a 118 complete MIME body as opposed to a portion of a complete message. 119 chunk: a portion of a complete message delivered in a SEND request. 120 end-to-end: delivery of data from the initiating client to the final 121 target client. 122 hop: delivery of data between one MSRP node and an adjacent node. 124 2. Introduction and Requirements 126 There are a number of scenarios in which using a separate protocol 127 for bulk messaging is desirable. In particular, their is a need to 128 handle a sequence of messages as a session of media initiated using 129 SIP [8], just like any other media type. The Message Session Relay 130 Protocol (MSRP) [11] is used to convey a session of messages directly 131 between two end systems with no intermediaries. With MSRP, messages 132 can be arbitrarily large and all traffic is sent over reliable, 133 congestion-safe transports. 135 This document describes extensions to the core MSRP protocol to 136 introduce intermediaries called Relays. With these extensions MSRP 137 clients can communicate directly, or through an arbitrary number of 138 relays. Each client is responsible for identifying any relays acting 139 on its behalf and providing appropriate credentials. Clients which 140 can receive new TCP connections directly do not have to implement any 141 new functionality to work with these relays. 143 The Goals of the MSRP Relay extensions are listed below: 144 o convey arbitrary binary MIME data without modification or transfer 145 encoding 146 o continue to support client to client operation (no relay servers 147 required) 149 o operate through an arbitrary number of relays for policy 150 enforcement 151 o operate through relays under differing administrative control 152 o allow each client to control which relays are traversed on its 153 behalf 154 o prevent unsolicited messages (SPAM), "open relays", and denial of 155 service amplification 156 o allow relays to use one or a small number of TCP or TLS [2] 157 connections to carry messages for multiple sessions, recipients, 158 and senders 159 o allow large messages to be sent over slow connections without 160 causing head-of-line blocking problems 161 o allow transmissions of large messages to be interrupted and 162 resumed in places where network connectivity is lost and later 163 reestablished 164 o offer notification of message failure at any intermediary 165 o allow relays to delete state after a short amount of time 167 3. Protocol Overview 169 With the introduction of this extension, MSRP has the concept of both 170 clients and relays. Clients send messages to relays and/or other 171 clients. Relays forward messages and message delivery status to 172 clients and other relays. Clients that can open TCP connections to 173 each other without intervening policy restrictions can communicate 174 directly with each other. Clients who are behind firewalls or who 175 need to use intermediaries for policy reasons can use the services of 176 a relay. Each client is responsible for enlisting the assistance of 177 one or more relays for its side of the communication. 179 Clients that use a relay operate by first opening a TLS connection 180 with a relay, authenticating, and retrieving an msrps: URL (from the 181 relay) that the client can provide to its peers to receive messages 182 later. There are several steps for doing this. First, the client 183 opens a TLS connection to its first relay and authenticates using an 184 AUTH request containing appropriate authentication credentials. In a 185 successful AUTH response, the relay provides an msrps: URL associated 186 with the path back to the client that the client can give to other 187 clients for end-to-end message delivery. 189 When clients wish to send a short message, they issue a SEND request 190 with the entire contents of the message. If any relays are required, 191 they are included in the To-Path header. The leftmost URL in the To- 192 Path header is the next hop to deliver a request or response. The 193 rightmost URL in the To-Path header is the final target. 195 SEND requests contain headers that indicate how they are acknowledged 196 in a hop-by-hop form and in an end-to-end form. The default is that 197 SEND message are acknowledged hop-by-hop. (Each relay that receives 198 a SEND request acknowledges receipt of the request before forwarding 199 the content to the next relay or the final target.) All other 200 requests are sent end-to-end. 202 With the introduction of relays, the subtle semantics of the To-Path 203 and From-Path header become more relevant. The To-Path in both 204 requests and responses is the list of URLs that need to be visited in 205 order to reach the final target of the request or response. The 206 From-Path is the list of URLs that indicate how to get back to the 207 original sender of the request or response. These headers differ 208 from the To and From headers in SIP, which do not "swap" from request 209 to response. (Note that sometimes a request is sent to or from an 210 intermediary directly.) 212 When a relay forwards a request, it removes its address from the To- 213 Path header and inserts it as the first URL in the From-Path header. 214 For example if the path from Alice to Bob is through relays A and B, 215 when B receives the request it contains path headers that look like 216 this: (Note that MSRP does not permit line folding. A "\" in the 217 examples shows a line continuation due to limitations in line length 218 of this document. Neither the backslash, nor the extra CRLF are 219 included in the actual request or response.) 221 To-Path: msrps://B.example.com/bbb;tcp \ 222 msrps://Bob.example.com/bob;tcp 223 From-Path: msrps://A.example.com/aaa;tcp \ 224 msrps://Alice.example.com/alice;tcp 226 after forwarding the request, the path headers look like this: 228 To-Path: msrps://Bob.example.com/bob;tcp 229 From-Path: msrps://B.example.com/bbb;tcp \ 230 msrps://A.example.com/aaa;tcp \ 231 msrps://Alice.example.com/alice;tcp 233 The sending of an acknowledgment for SEND requests is controlled by 234 the Success-Report and Failure-Report headers and works the same way 235 as in the base MSRP protocol. When a relay receives a SEND request, 236 if the Failure-Report is set to "yes", it means that the previous hop 237 is running a timer and the relay needs to send a response to the 238 request. If the final response conveys an error, the previous hop is 239 responsible for constructing the error report and sending it back to 240 the original sender of the message. The 200 response acknowledges 241 the receipt of the request so that the previous hop knows that it is 242 no longer responsible for the request. If the relay knows that it 243 will not be able to deliver the request and the Failure-Report is set 244 to any value other than "no", then it sends a REPORT to tell the 245 sender about the error. If the Failure-Report is set to "yes", then 246 after the relay is done sending the request to the next hop it starts 247 running a timer; if the timer expires before a response is received 248 from the next hop, the relay assumes that an error has happened and 249 sends a REPORT to the sender. If the Failure-Report is not set to 250 "yes", there is no need for the relay to run this timer. 252 The following example show a typical MSRP session. The AUTH requests 253 are explained in a later section but left in the example for call 254 flow completeness. 256 Alice a.example.org b.example.net Bob 257 | | | | 258 |::::::::::::::::::::>| connection opened |<::::::::::::::::::::| 259 |--- AUTH ----------->| |<-- AUTH ------------| 260 |<-- 200 OK-----------| |--- 200 OK---------->| 261 | | | | 262 .... time passes .... 263 | | | | 264 |--- SEND ----------->| | | 265 |<-- 200 OK ----------|:::::::::::::::::::>| (slow link) | 266 | |--- SEND ---------->| | 267 | |<-- 200 OK ---------|--- SEND ----------->| 268 | | | ....>| 269 | | | ..>| 270 | | |<-- 200 OK ----------| 271 | | |<-- REPORT ----------| 272 | |<-- REPORT ---------| | 273 |<-- REPORT ----------| | | 274 | | | | 276 The SEND and REPORT messages are shown below to illustrate the To- 277 Path and From-Path headers. (Note that MSRP does not permit line 278 folding. A "\" in the examples shows a line continuation due to 279 limitations in line length of this document. Neither the backslash, 280 nor the extra CRLF are included in the actual request or response.) 282 MSRP 6aef SEND 283 To-Path: msrps://a.example.org:9000/kjfjan;tcp \ 284 msrps://b.example.net:9000/aeiug;tcp \ 285 msrps://bob.example.net:8145/foo;tcp 286 From-Path: msrps://alice.example.org:7965/bar;tcp 287 Success-Report: yes 288 Byte-Range: 1-*/* 289 Message-ID: 87652 290 Content-Type: text/plain 292 Hi Bob, I'm about to send you file.mpeg 293 -------6aef$ 295 MSRP 6aef 200 OK 296 To-Path: msrps://alice.example.org:7965/bar;tcp 297 From-Path: msrps://a.example.org:9000/kjfjan;tcp 298 Message-ID: 87652 299 -------6aef$ 301 MSRP juh76 SEND 302 To-Path: msrps://b.example.net:9000/aeiug;tcp \ 303 msrps://bob.example.net:8145/foo;tcp 304 From-Path: msrps://a.example.org:9000/kjfjan;tcp \ 305 msrps://alice.example.org:7965/bar;tcp 306 Success-Report: yes 307 Message-ID: 87652 308 Byte-Range: 1-*/* 309 Content-Type: text/plain 311 Hi Bob, I'm about to send you file.mpeg 312 -------juh76$ 314 MSRP juh76 200 OK 315 To-Path: msrps://a.example.org:9000/kjfjan;tcp 316 From-Path: msrps://b.example.net:9000/aeiug;tcp 317 Message-ID: 87652 318 -------juh76$ 320 MSRP xght6 SEND 321 To-Path: msrps://bob.example.net:8145/foo;tcp 322 From-Path: msrps://b.example.net:9000/aeiug;tcp \ 323 msrps://a.example.org:9000/kjfjan;tcp \ 324 msrps://alice.example.org:7965/bar;tcp 325 Success-Report: yes 326 Message-ID: 87652 327 Byte-Range: 1-*/* 328 Content-Type: text/plain 330 Hi Bob, I'm about to send you file.mpeg 331 -------xght6$ 333 MSRP xght6 200 OK 334 To-Path: msrps://b.example.net:9000/aeiug;tcp 335 From-Path: msrps://bob.example.net:8145/foo;tcp 336 Message-ID: 87652 338 MSRP yh67 REPORT 339 To-Path: msrps://b.example.net:9000/aeiug;tcp \ 340 msrps://a.example.org:9000/kjfjan;tcp \ 341 msrps://alice.example.org:7965/bar;tcp 342 From-Path: msrps://bob.example.net:8145/foo;tcp 343 Message-ID: 87652 344 Byte-Range: 1-39/39 345 Status: 000 200 OK 346 -------yh67$ 348 MSRP yh67 REPORT 349 To-Path: msrps://a.example.org:9000/kjfjan;tcp \ 350 msrps://alice.example.org:7965/bar;tcp 351 From-Path: msrps://b.example.net:9000/aeiug;tcp \ 352 msrps://bob.example.net:8145/foo;tcp 353 Message-ID: 87652 354 Byte-Range: 1-39/39 355 Status: 000 200 OK 356 -------yh67$ 358 MSRP yh67 REPORT 359 To-Path: msrps://alice.example.org:7965/bar;tcp 360 From-Path: msrps://a.example.org:9000/kjfjan;tcp \ 361 msrps://b.example.net:9000/aeiug;tcp \ 362 msrps://bob.example.net:8145/foo;tcp 363 Message-ID: 87652 364 Byte-Range: 1-39/39 365 Status: 000 200 OK 366 -------yh67$ 368 When sending large content, the client may split up a message into 369 smaller pieces; each SEND request might contain only a portion of the 370 complete message. For example, when Alice sends Bob a 4GB file 371 called "file.mpeg", she sends several SEND requests each with a 372 portion of the complete message. Relays can repack message fragments 373 en-route. As individual parts of the complete message arrive at the 374 final destination client, the receiving client can optionally send 375 REPORT requests indicating delivery status. 377 MSRP nodes can send individual portions of a complete message in 378 multiple SEND requests. As relays receive chunks they can reassemble 379 or re-fragment them as long as they resend the resulting chunks in 380 order. (Receivers still need to be prepared to receive out-of-order 381 chunks however.) If the sender has set the Success-Report header to 382 yes, once a chunk or complete message arrives at the destination 383 client, the destination will send a REPORT request indicating that a 384 chunk arrived end-to-end. This request travels back along the 385 reverse path of the SEND request. Unlike the SEND request, which can 386 be acknowledged along every hop, REPORT requests are never 387 acknowledged. 389 The following example shows a message being re-chunked through two 390 relays: 392 Alice a.example.org b.example.net Bob 393 | | | | 394 |--- SEND 1-3 ------->| | | 395 |<-- 200 OK ----------| | (slow link) | 396 |--- SEND 4-7 ------->|--- SEND 1-5 ------>| | 397 |<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->| 398 |--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>| 399 |<-- 200 OK ----------|<-- 200 OK ---------| ..>| 400 | | |<-- 200 OK ----------| 401 | | |<-- REPORT 1-3 ------| 402 | |<-- REPORT 1-3 -----|--- SEND 4-7 ------->| 403 |<-- REPORT 1-3 ------| | ...>| 404 | | |<-- REPORT 4-7 ----->| 405 | |<-- REPORT 4-7 -----|--- SEND 8-10 ------>| 406 |<-- REPORT 4-7 ------| | ..>| 407 | | |<-- 200 OK ----------| 408 | |<-- REPORT done-----|<-- REPORT done -----| 409 |<-- REPORT done -----| | | 410 | | | | 412 Relays only keep transaction states for a short time for each chunk. 413 Delivery over each hop should take no more than 32 seconds after the 414 last byte of data is sent. Client applications define their own 415 implementation-dependent timers for end-to-end message delivery. 417 For client to client communication, the sender of a message typically 418 opens a new TCP connection (with or without TLS) if one is needed. 419 Relays reuse existing connections first, but can open new connections 420 (typically to other relays) to deliver requests such as SEND or 421 REPORT. Responses can only be sent over existing connections. 423 3.1 Authorization Overview 425 A key element of this protocol is that it cannot introduce open 426 relays, with all the associated problems they create, including DoS 427 attacks. A message is only forwarded by a relay if it is either 428 going to or coming from a client that has authenticated to the relay 429 and been authorized for relaying messages on that particular session. 430 Because of this, clients use an AUTH message to authenticate to a 431 relay and get a URL that can be used for forwarding messages. 433 If a client wishes to use a relay, it sends an AUTH request to the 434 relay. The client authenticates the relay using the relay's TLS 435 certificate. The client uses HTTP Digest Authentication [1] to 436 authenticate to the relay. When the authentication succeeds the 437 relay returns a 200 response that contains the URL that the client 438 can use in the MSRP path for the relay. 440 A typical challenge response flow is shown below: 442 Alice a.example.org 443 | | 444 |::::::::::::::::::::>| 445 |--- AUTH ----------->| 446 |<- 401 Unauthorized -| 447 |--- AUTH ----------->| 448 |<-- 200 OK-----------| 449 | | 451 The URL that the client should use is returned in the Use-Path header 452 of the 200. 454 Note that URLs returned to the client are effectively secret tokens 455 that should be shared only with the other MSRP client in a session. 456 For that reason, the client MUST NOT reuse the same URL for multiple 457 sessions, and needs to protect these URLs from eavesdropping. 459 4. New Protocol Elements 461 4.1 The AUTH Method 463 AUTH requests are used by clients to create a handle they can use to 464 receive incoming requests. AUTH requests also contain credentials 465 used to authenticate a client and authorization policy used to block 466 Denial of Service attacks. 468 In response to an AUTH request, a successful response contains a Use- 469 Path header with a list of URLs that the Client can give to its peers 470 to route responses back to the Client. 472 4.2 The Use-Path header 474 The Use-Path header is a list of URLs provided by an MSRP Relay in 475 response to a successful AUTH request. This list of URLs can be used 476 by the MSRP Client that sent the AUTH request to receive MSRP 477 requests, and to advertise this list of URLs, for example in a 478 session description. URLs in the Use-Path header MUST include a 479 fully qualified domain name (as opposed to a numeric IP address) and 480 an explicit port number. 482 The URLs in the Use-Path header are in the same order that the 483 authenticating client uses them in a To-Path header. Instructions on 484 forming To-Path headers and SDP[7] path attributes from information 485 in the Use-Path header is discussed in Section 5.1. 487 4.3 The HTTP Authentication "WWW-Authenticate" header 489 The "WWW-Authenticate" header contains a challenge token used in HTTP 490 Digest Authentication procedure (from RFC 2617 [1]). The usage of 491 HTTP Digest authentication in MSRP is described in detail in 492 Section 5.1. 494 4.4 The HTTP Authentication "Authorization" header 496 The "Authorization" header contains authentication credentials for 497 HTTP Digest Authentication (from RFC 2617 [1]). The usage of HTTP 498 Digest authentication in MSRP is described in detail in Section 5.1. 500 4.5 The HTTP Authentication "Authentication-Info" header 502 The "Authentication-Info" header contains future challenges to be 503 used for HTTP Digest Authentication (from RFC 2617 [1]). The usage 504 of HTTP Digest authentication in MSRP is described in detail in 505 Section 5.1. 507 4.6 Time-related headers 509 The Expires header in a request provides a relative time after which 510 the action implied by the method of the request is no longer of 511 interest. In a request, the Expires header indicates how long the 512 sender would like the request to remain valid. In a response, the 513 Expires header indicates how long the responder considers this 514 information relevant. Specifically an Expires header in an AUTH 515 request indicates how long the provided URLs will be valid. 517 The Min-Expires header contains the minimum duration a server will 518 permit in an Expires header. It is sent only in 423 "Interval Out- 519 of-Bounds" responses. Likewise the Max-Expires header contains the 520 maximum duration a server will permit in an Expires header. 522 5. Client behavior 523 5.1 Connecting to relays acting on your behalf 525 Clients that want to use the services of a relay or list of relays 526 need to send an AUTH request to each relay that will act on their 527 behalf. (For example, some organizations could deploy an "intra-org" 528 relay and an "extra-org" relay.) The inner relay is used to tunnel 529 the AUTH requests to the outer relay. For example, the client will 530 send an AUTH to intra-org and get back a path that can be used for 531 forwarding through intra-org. The client would then send a second 532 AUTH destined to extra-org but sent through intra-org. The intra-org 533 relay forwards this to extra-org and extra-org returns a path that 534 can be used to forward messages from another destination to extra-org 535 to intra-org and then on to this client. Each relay authenticates 536 the client. The client authenticates the first relay and each relay 537 authenticates the next relay. 539 Clients can be configured (typically through discovery or manual 540 provisioning) with a list of relays they need to use. They MUST be 541 able to form a connection to the first relay and send an AUTH command 542 to get a URL that can be used in a To-Path header. The client can 543 authenticate its first relay by looking at the relay's TLS 544 certificate. The client MUST authenticate itself to each of its 545 relays using HTTP Digest authentication [1] (see Section 9.1 for 546 details). 548 The relay returns a URL, or list of URLs, in the "Use-Path" header of 549 a success response. Each URL SHOULD be used for only one unique 550 session. These URLs are used by the client in the path attribute 551 that is sent in the SDP to set up the session, and in the To-Path 552 header of outgoing requests. To form the To-Path header for outgoing 553 requests, the client takes the list of URLs in the Use-Path header 554 after the outermost authentication and appends the list of URLs 555 provided in the path attribute in the peer's session description. To 556 form the SDP path attribute to provide to the peer, the client 557 reverses the list of URLs in the Use-Path header (after the outermost 558 authentication), and appends the client's own URL. 560 For example, "A" has to traverse its own relays "B" and "C", and 561 then relays "D" and "E" in domain2 to reach "F". Client "A" will 562 authenticate with its relays "B" and "C" and eventually receive a 563 Use-Path header containing "B C". Client "A" reverses the list 564 (now "C B") and appends its own URL (now "C B A"), and provides 565 this list to "F" in a path SDP attribute. Client "F" sends its 566 SDP path list "D E F", which client "A" appends to the Use-Path 567 list it received "B C". The resulting To-Path header is "B C D E 568 F". 570 domain 1 domain 2 571 ---------------- ----------------- 573 client relays relays client 574 A ----- B -- C -------- D -- E ----- F 576 Use-Path returned by C: B C 577 path: attribute generated by A: C B A 578 path: attribute received from F: D E F 579 To-Path header generated by A: B C D E F 581 The initial AUTH request sent to a relay by a client will generally 582 not contain an Authorization header, since the client has no 583 challenge to which it can respond. In response to an AUTH request 584 that does not contain an Authorization header, a relay MUST respond 585 with a "401 Unauthorized" response containing a WWW-Authenticate 586 header. The WWW-Authenticate header is formed as described in RFC 587 2617 [1], with the restrictions and modifications described in 588 Section 9.1. The realm chosen by the MSRP relay in such a challenge 589 is a matter of administrative policy. Because a single relay does 590 not have multiple protection spaces in MSRP, it is not unreasonable 591 to always use the relay's hostname as the realm. 593 Upon receiving a 401 response to a request, the client SHOULD fetch 594 the realm from the WWW-Authenticate header in the response and retry 595 the request, including an Authorization header with the correct 596 credentials for the realm. The Authorization header is formed as 597 described in RFC 2617 [1], with the restrictions and modifications 598 described in Section 9.1. 600 When a client wishes to use more than one relay, it MUST send an AUTH 601 request to each relay it wishes to use. Consider a client A, that 602 wishes messages to flow from A to the first relay, R1, then on to a 603 second relay, R2. This client will do a normal AUTH with R1. It 604 will then do an AUTH transaction with R2 that is routed through R1. 605 The client will form this AUTH message by setting the To-Path to 606 msrps://R1;tcp msrps://R2;tcp. R1 will forward this request onward 607 to R2. 609 When sending an AUTH request, the client MAY add an Expires header to 610 request a MSRP URL that is valid for no longer than the provided 611 interval (a whole number of seconds). The server will include an 612 Expires header in a successful response indicating how long its URL 613 from the Use-Path will be valid. Note that each server can return an 614 independent expiration time. 616 Note that MSRP does not permit line folding. A "\" in the examples 617 shows a line continuation due to limitations in line length of this 618 document. Neither the backslash, nor the extra CRLF are included in 619 the actual request or response. 621 (Alice opens a TLS connection to intra.example.com and sends an AUTH 622 request to initiate the authentication process). 624 MSRP 49fh AUTH 625 To-Path: msrps://alice@intra.example.com;tcp 626 From-Path: msrps://alice.example.com:9892/98cjs;tcp 627 -------49fh$ 629 (Alice's relay challenges the AUTH request). 631 MSRP 49fh 401 Unauthorized 632 To-Path: msrps://alice.example.com:9892/98cjs;tcp 633 From-Path: msrps://alice@intra.example.com;tcp 634 WWW-Authenticate: Digest realm="intra.example.com", qop="auth", \ 635 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093" 636 -------49fh$ 638 (Alice responds to the challenge). 640 MSRP 49fi AUTH 641 To-Path: msrps://alice@intra.example.com;tcp 642 From-Path: msrps://alice.example.com:9892/98cjs;tcp 643 Authorization: Digest username="Alice", 644 realm="intra.example.com", \ 645 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", \ 646 qop="auth", nc=00000001, cnonce="0a4f113b", \ 647 response="6629fae49393a05397450978507c4ef1" 648 -------49fi$ 650 (Alice's relay confirms that Alice is an authorized user. As a 651 matter of local policy, it includes an "Authentication-Info" header 652 with a new nonce value to expedite future AUTH requests.) 654 MSRP 49fi 200 OK 655 To-Path: msrps://alice.example.com:9892/98cjs;tcp 656 From-Path: msrps://alice@intra.example.com;tcp 657 Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp 658 Authentication-Info: nextnonce="40f2e879449675f288476d772627370a",\ 659 rspauth="7327570c586207eca2afae94fc20903d", \ 660 cnonce="0a4f113b", nc=00000001, qop="auth" 661 Expires: 900 662 -------49fi$ 664 (Alice now sends an AUTH request to her "external" relay through her 665 "internal" relay, using the URL she just obtained; the AUTH request 666 is challenged.) 668 MSRP mnbvw AUTH 669 To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 670 msrps://extra.example.com;tcp 671 From-Path: msrps://alice.example.com:9892/98cjs;tcp 672 -------mnbvw$ 674 MSRP m2nbvw AUTH 675 To-Path: msrps://extra.example.com;tcp 676 From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 677 msrps://alice.example.com:9892/98cjs;tcp 678 -------m2nbvw$ 680 MSRP m2nbvw 401 Unauthorized 681 To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 682 msrps://alice.example.com:9892/98cjs;tcp 683 From-Path: msrps://extra.example.com;tcp 684 WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \ 685 nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO" 686 -------m2nbvw$ 688 MSRP mnbvw 401 Unauthorized 689 To-Path: msrps://alice.example.com:9892/98cjs;tcp 690 From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 691 msrps://extra.example.com;tcp 692 WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \ 693 nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO" 694 -------mnbvw$ 696 (Alice replies to the challenge with her credentials and is then 697 authorized to use the "external" relay). 699 MSRP m3nbvx AUTH 700 To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 701 msrps://extra.example.com;tcp 702 From-Path: msrps://alice.example.com:9892/98cjs;tcp 703 Authorization: Digest username="Alice", 704 realm="extra.example.com", \ 705 nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \ 706 qop="auth", nc=00000001, cnonce="85a0dca8", \ 707 response="cb06c4a77cd90918cd7914432032e0e6" 708 -------m3nbvx$ 709 MSRP m4nbvx AUTH 710 To-Path: msrps://extra.example.com;tcp 711 From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 712 msrps://alice.example.com:9892/98cjs;tcp 713 Authorization: Digest username="Alice", 714 realm="extra.example.com", \ 715 nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \ 716 qop="auth", nc=00000001, cnonce="85a0dca8", \ 717 response="cb06c4a77cd90918cd7914432032e0e6" 718 -------m4nbvx$ 720 MSRP m4nbvx 200 OK 721 To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 722 msrps://alice.example.com:9892/98cjs;tcp 723 From-Path: msrps://extra.example.com;tcp 724 Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 725 msrps://extra.example.com:9000/mywdEe1233;tcp 726 Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \ 727 rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \ 728 cnonce="85a0dca8", nc=00000001, qop="auth" 729 Expires: 1800 730 -------m4nbvx$ 732 MSRP m3nbvx 200 OK 733 To-Path: msrps://alice.example.com:9892/98cjs;tcp 734 From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 735 msrps://extra.example.com;tcp 736 Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp \ 737 msrps://extra.example.com:9000/mywdEe1233;tcp 738 Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \ 739 rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \ 740 cnonce="85a0dca8", nc=00000001, qop="auth" 741 Expires: 1800 742 -------m3nbvx$ 744 5.2 Sending requests 746 The procedure for forming SEND and REPORT requests is identical for 747 clients whether relays are involved or not. The specific procedures 748 are described in section 7 of the core MSRP protocol. 750 As usual, once the next-hop URL is determined, the client MUST find 751 the appropriate address, port, and transport to use and then check if 752 there is already a suitable existing connection to the next-hop 753 target. If so, the client MUST send the request over the most 754 suitable connection. Suitability MAY be determined by a variety of 755 factors such as measured load and local policy, but in most simple 756 implementations a connection will be suitable if it exists and is 757 active. 759 5.3 Receiving Requests 761 The procedure for receiving requests is identical for clients whether 762 relays are involved or not. 764 5.4 Managing Connections 766 Clients should open a connection whenever they wish to deliver a 767 request and no suitable connection exists. For connections to 768 relays, the client should leave a connection up until no sessions 769 have used it for a locally defined period of time, which defaults to 770 5 minutes for foreign relays and one hour for the client's relays. 772 6. Relay behavior 774 6.1 Handling Incoming Connections 776 When a relay receives an incoming connection on a port configured for 777 TLS, it includes a client CertificateRequest in the same record in 778 which it sends its ServerHello. If the TLS client provides a 779 certificate, the server verifies it and continues if the certificate 780 is valid and rooted in a trusted authority. If the TLS client does 781 not provide a certificate, the server assumes that the client is an 782 MSRP endpoint and invokes digest authentication. Once a TCP or TLS 783 channel is negotiated, the server waits for up to 30 seconds to 784 receive an MSRP request over the channel. If no request is received 785 in that time, the server closes the connection. If no successful 786 requests are sent during this probationary period, the server closes 787 the connection. Likewise, if several unsuccessful requests are sent 788 during the probation period and no requests are sent successfully, 789 the server SHOULD close the connection. 791 6.2 Generic request behavior 793 Upon receiving a new request, relays first verify the validity of the 794 request. Relays then examine the first URL in the To-Path header and 795 remove this URL if it matches a URL corresponding to the relay. If 796 the request is not addressed to the relay, the relay immediately 797 drops the corresponding connection over which the request was 798 received. 800 6.3 Receiving AUTH requests 802 When a relay receives an AUTH request, the first thing it does is to 803 authenticate and authorize the previous hop and the client at the far 804 end. If there are no other relays between this relay and the client, 805 then these are the same thing. 807 When the previous hop is a relay, authentication is done with TLS 808 using mutual authentication. If the TLS client presented a host 809 certificate, the relay checks that the subjectAltName in the 810 certificate of the TLS client matches the hostname in the first From- 811 Path URL. If the TLS client doesn't provide a host certificate, the 812 relay assumes the TLS client is an MSRP client and sends it a 813 challenge. 815 Authorization is a matter of local policy at the relay. Many relays 816 will choose to authorize all relays that can be authenticated, 817 possibly in conjunction with a blacklisting mechanism. Relays 818 intended to operate only within a limited federation may choose to 819 authorize only those relays whose identity appears in a provisioned 820 list. Other authorization policies may also be applied. 822 When the previous hop is a client, the previous hop is the same as 823 the identity of the client. The relay checks the credentials 824 (username and password) provided by the client in the Authorization 825 header and checks if this client is allowed to use the relay. If the 826 client is not authorized, the relay returns a 403 response. If the 827 client has requested a particular expiration time in an Expires 828 header, the relay needs to check that the time is acceptable to it 829 and, if not, return an error containing a Min-Expires or Max-Expires 830 header, as appropriate. 832 Next the relay will generate an MSRP URL which allows messages to be 833 forwarded to or from this previous hop. If the previous hop was a 834 relay authenticated by mutual TLS, then the URL MUST be valid to 835 route across any connection the relay has to the previous hop relay. 836 If the previous hop is a client, then the URL MUST only be valid to 837 route across the same connection over which the AUTH request was 838 received. If the client's connection is closed and then reopened, 839 the URL MUST be invalidated. 841 If the AUTH request contains an Expires header, the relay MUST ensure 842 that the URL is invalidated after the expiry time. The URL MUST 843 contain at least 64 bits of crypto random material so that it is not 844 guessable by attackers. If a relay is requested to forward a message 845 for which the URL is not valid, the relay MUST discard the message 846 and MAY send a REPORT indicating the AUTH URL was bad. 848 A successful AUTH response returns a Use-Path header which contains 849 an MSRP URL that the client can use. It also returns an Expires 850 header that indicates how long the URL will be valid (expressed as a 851 whole number of seconds). 853 If a relay receives several unsuccessful AUTH requests from a client 854 which is directly connected to it via TLS, the relay SHOULD terminate 855 the corresponding connection. Similarly, if a relay forwards several 856 failed AUTH requests to the same destination that originate from a 857 client that is directly connected to it via TLS, the relay SHOULD 858 terminate the corresponding connection. Determination of a remote 859 AUTH failure can be made by observing an AUTH request containing an 860 "Authorization" header that triggers a 401 response without a 861 "stale=TRUE" indication. These preventive measures apply only to a 862 connection between a relay and a client; a relay SHOULD NOT use 863 excessive AUTH request failures as a reason to terminate a connection 864 with another relay. 866 6.4 Forwarding 868 Before any request is forwarded, the relay MUST check that the first 869 URL in the To-Path header corresponds to a URL that this relay has 870 created and handed out in the Use-Path header of an AUTH request. 871 Next it verifies that either 1) the next hop is the next hop back 872 toward the client that obtained this URL, or 2) the previous hop was 873 the correct previous hop coming from the client that obtained this 874 URL. 876 Since transact-id values are not allowed to conflict on a given 877 connection, a relay will generally need to construct a new 878 transact-id value for any request that it forwards. 880 6.4.1 Forwarding SEND requests 882 If an incoming SEND request contains a Failure-Report header with a 883 value of "yes", an MSRP relay that receives that SEND request MUST 884 respond with a final response immediately. A 200-class response 885 indicates the successful receipt of a message fragment but does not 886 mean that the message has been forwarded on to the next hop. The 887 final response to the SEND MUST be sent only to the previous hop, 888 which could be an MSRP relay or the original sender of the SEND 889 request. 891 If there is a problem further processing the SEND request, or in the 892 response that the relay receives in sending the SEND request to the 893 next hop, and the Failure-Report header is "yes" or "partial", then 894 the relay MUST respond with an appropriate error response in a REPORT 895 back to the original source of the message. 897 If the Failure-Report header is "yes", then the relay MUST run a 898 timer to detect if transmission to the next hop fails. The timer 899 starts when the last byte of the message has been sent to the next 900 hop. If after 32 seconds, the next hop has not sent any response, 901 then the relay MUST construct a REPORT with a status code of 408 to 902 indicate a timeout error happened sending the message, and send the 903 REPORT to the original sender of the message. 905 The MSRP relay MAY further break up the message fragment received in 906 the SEND request into smaller fragments and forward them to the next 907 hop in separate SEND requests. It MAY also combine message fragments 908 received before or after this SEND request, and forward them out in a 909 single SEND request to the next hop identified in the To-Path header. 910 The MSRP relay MUST NOT combine message fragments from SEND requests 911 with different values in the Message-ID header. 913 The MSRP relay MAY choose whether to further fragment the message, or 914 combine message fragments, or send the message as is, based on some 915 policy which is administered, or based on the network speed to the 916 next hop, or any other mechanism. 918 If the MSRP relay has knowledge of the byte range that it will 919 transmit to the next hop, it SHOULD update the Byte-Range header in 920 the SEND request appropriately. 922 Before forwarding the SEND request to the next hop, the MSRP relay 923 MUST inspect the first URL in the To-Path header. If it indicates 924 this relay, the relay removes this URL from the To-Path header and 925 inserts this URL in the From-Path header before any other URLs. If 926 it does not indicate this relay, there has been an error in 927 forwarding at a previous hop. In this case the relay SHOULD discard 928 the message, and if the Failure-Report header is set to "yes", the 929 relay SHOULD generate a failure report. 931 6.4.2 Forwarding non-SEND requests 933 An MSRP relay that receives any request other than a SEND request 934 (including new methods unknown to the relay), first follows the 935 validation and authorization rules for all requests. Then the relay 936 moves its URL from the beginning of the To-Path header, to the 937 beginning of the From-Path header and forwards the request on to the 938 next hop. If it already has a connection to the next hop, it SHOULD 939 use this connection and not form a new connection. If no suitable 940 connection exists, the relay opens a new connection. 942 Requests with an unknown method are forwarded as if they were REPORT 943 requests. An MSRP node MAY be configured to block unknown methods 944 for security reasons. 946 6.4.3 Handling Responses 948 Relays receiving a response first verify that the first URL in the 949 To-Path corresponds to itself; if not, the response SHOULD be 950 dropped. Likewise if the message cannot be parsed, the relay MUST 951 drop the response. Next the relay determines if there are additional 952 URLs in the To-Path. (For responses to SEND requests there will be 953 no additional URLs, whereas responses to AUTH requests have 954 additional URLs directing the response back to the client.) 956 If the response matches an existing transaction, then that 957 transaction is completed and any timers running on it can be removed. 958 If the response is a non 200 response, and the original request was a 959 SEND request which had a Failure-Report header with a value other 960 than "no", then the relay MUST send a REPORT indicating the nature of 961 the failure. The response code received by the relay is used to form 962 the status line in the REPORT that the relay sends. 964 If there are additional URLs in the To-Path header, the relay MUST 965 then move its URL from the To-Path header, insert its URL in front of 966 any other URLs in the From-Path header, and forward the response to 967 the next URL in the To-Path header. The relay sends the request over 968 the best connection which corresponds to the next URL in the To-Path 969 header. If this connection has closed, then the response is silently 970 discarded. 972 6.5 Managing Connections 974 Relays should keep connections open as long as possible. If a 975 connection has not been used in a significant time (more than one 976 hour) it MAY be closed. If the relay runs out of resources and can 977 no longer establish new connections, it SHOULD start closing existing 978 connections. It MAY choose to close the connections based on a least 979 recently used basis. 981 7. Formal Syntax 983 The following syntax specification uses the Augmented Backus-Naur 984 Form (ABNF) as described in RFC-2234 [10]. 986 Note to RFC Editor - Please replace all the following occurrences of 987 RFC-BASE in the RFC number of [11]. 989 ; This ABNF imports all the definitions in the ABNF of RFC-BASE 991 header = Message-ID 992 / Success-Report 993 / Failure-Report 994 / Byte-Range 995 / Status 996 / Expires 997 / Min-Expires 998 / Max-Expires 999 / Use-Path 1000 / WWW-Authenticate 1001 / Authorization 1002 / Authentication-Info 1003 / ext-header ; this replaces the rule in RFC-BASE 1005 mAUTH = %x41.55.54.48 ; AUTH in caps 1006 method = mSEND / mREPORT / mAUTH 1007 / other-method 1008 ; this replaces the rule in RFC-BASE 1010 WWW-Authenticate = "WWW-Authenticate" ":" SP "Digest" SP 1011 digest-param *("," SP digest-param) 1013 digest-param = ( realm / nonce / 1014 [ opaque ] / [ stale ] / [ algorithm ] / 1015 qop-options / [auth-param] ) 1017 realm = "realm" "=" realm-value 1018 realm-value = quoted-string 1020 auth-param = token "=" ( token / quoted-string ) 1022 nonce = "nonce" "=" nonce-value 1023 nonce-value = quoted-string 1024 opaque = "opaque" "=" quoted-string 1025 stale = "stale" "=" ( "true" / "false" ) 1026 algorithm = "algorithm" "=" ( "MD5" / token ) 1027 qop-options = "qop" "=" QUOTE qop-list QUOTE 1028 qop-list = qop-value *( "," qop-value ) 1029 qop-value = "auth" / token 1030 quoted-string = QUOTE *( %x20-21 / %x23-7E ) QUOTE 1031 QUOTE = %x22 1033 Authorization = "Authorization" ":" SP credentials 1035 credentials = "Digest" SP digest-response 1036 *( "," SP digest-response) 1038 digest-response = ( username / realm / nonce 1039 / response / [ algorithm ] / cnonce / 1040 [opaque] / message-qop / 1042 [nonce-count] / [auth-param] ) 1044 username = "username" "=" username-value 1045 username-value = quoted-string 1046 message-qop = "qop" "=" qop-value 1047 cnonce = "cnonce" "=" cnonce-value 1048 cnonce-value = nonce-value 1049 nonce-count = "nc" "=" nc-value 1050 nc-value = 8LHEX 1051 response = "response" "=" request-digest 1052 request-digest = QUOTE 32LHEX QUOTE 1053 LHEX = DIGIT / %x61-66 ;lowercase a-f 1055 Authentication-Info = "Authentication-Info" ":" SP ainfo 1056 *("," ainfo) 1057 ainfo = nextnonce / message-qop 1058 / response-auth / cnonce 1059 / nonce-count 1060 nextnonce = "nextnonce" "=" nonce-value 1061 response-auth = "rspauth" "=" response-digest 1062 response-digest = QUOTE *LHEX QUOTE 1064 Expires = "Expires" ":" SP 1*DIGIT 1065 Min-Expires = "Min-Expires" ":" SP 1*DIGIT 1066 Max-Expires = "Max-Expires" ":" SP 1*DIGIT 1068 Use-Path = "Use-Path" ":" SP MSRP-URL *(SP MSRP-URL) 1070 8. Finding MSRP Relays 1072 When resolving an MSRP URL which contains an explicit port number, an 1073 MSRP node follows the rules in section 6 of the MSRP base 1074 specification. MSRP URLs exchanged in SDP and in To-Path and From- 1075 Path headers in non-AUTH requests MUST have an explicit port number. 1076 (The only message in this specification that can have an MSRP URL 1077 without an explicit port number is in the To-Path header in an AUTH 1078 request.) 1080 The following rules allow MSRP clients to discover MSRP relays more 1081 easily in AUTH requests. If the hostport of an msrps: URL is an IPv4 1082 address or an IPv6 reference and no port number is provided, use the 1083 default port number assigned by IANA. If the hostport is a domain 1084 name and an explicit port number is provided, attempt to look up a 1085 valid address record (A or AAAA) for the domain name. Connect using 1086 TLS over the default transport (TCP) with the default port number. 1088 If a domain name is provided but no port number, perform a DNS SRV 1090 [4] lookup for the '_msrps' service and '_tcp' transport at the 1091 domain name, and follow the SRV selection algorithm defined in that 1092 specification to select the entry. (An '_msrp' service is not 1093 defined, since AUTH are only sent over TLS.) If no SRV records are 1094 found, try an address lookup (A or AAAA) using the default port 1095 number procedures described in the previous paragraph. Note that 1096 AUTH requests MUST only be sent over a TLS-protected channel. An SRV 1097 lookup in the example.com domain might return: 1099 ;; in example.com. Pri Wght Port Target 1100 _msrps._tcp IN SRV 0 1 9000 server1.example.com. 1101 _msrps._tcp IN SRV 0 2 9000 server2.example.com. 1103 If implementing a relay farm, it is RECOMMENDED that each member of 1104 the relay farm have an SRV entry. If any members of the farm have 1105 multiple IP addresses (for example an IPv4 and an IPv6 address), each 1106 of these addresses SHOULD be registered in DNS as separate A or AAAA 1107 records corresponding to a single target. 1109 9. Security Considerations 1111 This section first describes the security mechanisms available for 1112 use in MSRP. Then the threat model is presented. Finally we list 1113 implementation requirements related to security. 1115 9.1 Using HTTP Authentication 1117 AUTH requests MUST be authenticated. The authentication mechanism 1118 described in this specification uses HTTP Digest authentication. 1119 HTTP Digest authentication is performed as described in RFC 2617 [1], 1120 with the following restrictions and modifications: 1122 o Clients MUST NOT attempt to use Basic authentication, and relays 1123 MUST NOT request or accept Basic authentication. 1124 o The use of a qop value of auth-int makes no sense for MSRP. 1125 Integrity protection is provided by the use of TLS. Consequently, 1126 MSRP relays MUST NOT indicate a qop of auth-int in a challenge. 1127 o The interaction between the MD5-sess algorithm and the nextnonce 1128 mechanism is underspecified in RFC 2617 [1]; consequently, MSRP 1129 relays MUST NOT send challenges indicating the MD5-sess algorithm. 1130 o Clients SHOULD consider the protection space within a realm to be 1131 scoped to the authority portion of the URL, without regard to the 1132 contents of the path portion of the URL. Accordingly, relays 1133 SHOULD NOT send the "domain" parameter on the "WWW-Authenticate" 1134 header, and clients MUST ignore it if present. 1135 o Clients and relays MUST include a qop parameter in all "WWW- 1136 Authenticate" and "Authorization" headers. 1138 o Clients MUST send cnonce and nonce-count parameters in all 1139 "Authorization" headers. 1140 o The request-URI to be used in calculating H(A2) is the right-most 1141 URL in the To-Path header. 1142 o Relays MUST include rspauth, cnonce, nc, and qop parameters in a 1143 "Authentication-Info" header for all "200 OK" responses to an AUTH 1144 request. 1146 Note that the BNF in RFC2617 has a number of errors. In particular, 1147 the value of the uri parameter MUST be in quotes; further, the 1148 parameters in the Authentication-Info header MUST be separated by 1149 commas. The BNF in this document is correct, as are the examples in 1150 RFC 2617 [1]. 1152 The use of the nextnonce and nc parameters are supported as described 1153 in RFC 2617 [1], which provides guidance on how and when they should 1154 be used. As a slight modification to the guidance provided in RFC 1155 2617, implementors of relays should note that AUTH requests cannot be 1156 pipelined; consequently, there is no detrimental impact on throughput 1157 when relays use the nextnonce mechanism. 1159 See Section 5.1 for further information on the procedures for client 1160 authentication. 1162 9.2 Using TLS 1164 TLS is used to authenticate relays to senders and to provide 1165 integrity and confidentiality for the headers being transported. 1166 MSRP clients and relays MUST implement TLS. Clients MUST send the 1167 TLS ClientExtendedHello extended hello information for server name 1168 indication as described in RFC 3546 [5]. A TLS cipher-suite of 1169 TLS_RSA_WITH_AES_128_CBC_SHA [6] MUST be supported (other cipher- 1170 suites MAY also be supported). A relay MUST act as a TLS server and 1171 present a certificate with its identity in the SubjectAltName using 1172 the choice type of dnsName. Relay to relay connections MUST use TLS 1173 with mutual authentication. Client to relay communications MUST use 1174 TLS for AUTH requests and responses. 1176 Note: When relays are involved in a session, TCP without TLS is only 1177 used when a user that does not use relays connects directly to the 1178 relay of a user that is using relays. In this case the client has no 1179 way to authenticate the relay other than to use the URLs that form a 1180 shared secret in the same way they are used when no relays are 1181 involved. 1183 9.3 Threat Model 1185 This section discusses the threat model and the broad mechanism that 1186 needs to be in place to secure the protocol. The next section 1187 describes the details of how the protocol mechanism meets the broad 1188 requirements. 1190 MSRP allows two peer to peer clients to exchange messages. Each peer 1191 can select a set of relays to perform certain policy operation for 1192 them. This combined set of relays is referred to as the route set. 1193 A channel outside of MSRP always needs to exist, such as out-of-band 1194 provisioning or an explicit rendezvous protocol such as SIP, that can 1195 securely negotiate setting up the MSRP session and communicate the 1196 route set to both clients. A client may trust a relay with certain 1197 types of routing and policy decisions but it might or might not trust 1198 the relay with all the contents of the session. For example, a relay 1199 being trusted to look for viruses would probably need to be allowed 1200 to see all the contents of the session. A relay that helped deal 1201 with traversal of the ISP's NAT would likely not be trusted with the 1202 contents of the session but would be trusted to correctly forward 1203 messages. 1205 Clients implicitly trust the relays through which they send and 1206 receive messages to honor the routing indicated in those messages, 1207 within the constraints of the MSRP protocol. Clients also need to 1208 trust that the relays they use do not insert new messages on their 1209 behalf or modify messages sent to or by the clients. It is worth 1210 noting that some relays are in a position to cause a client to 1211 misroute a message by maliciously modifying a Use-Path returned by a 1212 relay further down the chain. However this is not an additional 1213 security threat because these same relays can also decide to misroute 1214 a message in the first place. If the relay is trusted to route 1215 messages, it is reasonable to trust it not to tamper with the Use- 1216 Path header. If the relay can not be trusted to route messages, then 1217 it can not be used. 1219 Under certain circumstances, relays need to trust other relays not to 1220 modify information between them and the client they represent. For 1221 example, if a client is operating through Relay A to get to Relay B, 1222 and Relay B is logging messages sent by the client, Relay B may be 1223 required to authenticate that the messages they logged originate with 1224 the client, and have not been modified or forged by Relay A. This can 1225 be done by having the client sign the message. 1227 Clients need to be able to authenticate that the relay they are 1228 communicating with is the one they trust. Likewise, relays need to 1229 be able to authenticate that the client is the one they are 1230 authorized to forward information to. Clients need the option of 1231 ensuring information between the relay and the client is integrity 1232 protected and confidential to elements other than the relays and 1233 clients. To simplify the number of options, traffic between relays 1234 is always integrity protected and encrypted regardless of whether the 1235 client requests it or not. There is no way for the clients to tell 1236 the relays what strength of crypto to use between relays other than 1237 to have the clients choose relays that are administered to require an 1238 adequate level of security. 1240 The system also needs to stop the messages from being directed to 1241 relays that are not supposed to see them. To keep the relays from 1242 being used in Denial of Service (DoS) attacks, the relays never 1243 forward messages unless they have a trust relationship with either 1244 the client sending or the client receiving the message; further, they 1245 only forward that message if it is coming from or going to the client 1246 with which they have the trust relationship. If a relay has a trust 1247 relationship with the client that is the destination of the message, 1248 it should not send the message anywhere except to the client that is 1249 the destination. 1251 Some terminology used in this discussion: SClient is the client 1252 sending a message and RClient is the client receiving a message. 1253 SRelay is a relay the sender trusts and RRelay is a relay the 1254 receiver trusts. The message will go from SClient to SRelay1 to 1255 SRelay2 to RRelay2 to RRelay1 to RClient. 1257 9.4 Security Mechanism 1259 Confidentiality and Privacy from elements not in the route set is 1260 provided by using TLS on all the transports. Relays always use TLS. 1261 A client can use unprotected TCP for peer-to-peer MSRP, but any time 1262 a client communicates with a relay, it MUST use TLS. 1264 The relays authenticate to the clients using TLS (but don't have to 1265 do mutual TLS). Further, the use of the rspauth parameter in the 1266 Authentication-Info header provides limited authentication of relays 1267 to which the client is not directly connected. The clients 1268 authenticate to the relays using HTTP Digest authentication. Relays 1269 authenticate to each other using TLS mutual authentication. 1271 By using S/MIME[3] encryption, the clients can protect their actual 1272 message contents so that the relays cannot see the contents. End to 1273 end signing is also possible with S/MIME. 1275 The complex part is making sure that relays cannot successfully be 1276 instructed to send messages to a place where they should not. This 1277 is done by having the client authenticate to the relay and having the 1278 relay return a token. Messages that contain this token can be 1279 relayed if they come from the client that got the token or if they 1280 are being forwarded towards the client that got the token. The 1281 tokens are the URLs that the relay places in the Use-Path header. 1283 The tokens contain random material (defined in Section 6.3) so that 1284 they are not guessable by attackers. The tokens need to be protected 1285 so they are only ever seen by elements in the route set or other 1286 elements that at least one of the parties trusts. If some 3rd party 1287 discovers the token that RRelay2 uses to forward messages to RClient, 1288 then that 3rd party can send as many messages as they want to RRelay2 1289 and it will forward them to RClient. The 3rd party cannot cause them 1290 to be forwarded anywhere except to RClient, eliminating the open 1291 relay problems. SRelay1 will not forward the message unless it 1292 contains a valid token. 1294 When SClient goes to get a token from SRelay2, this request is 1295 relayed through SRelay1. SRelay2 authenticates that it really is 1296 SClient requesting the token, but it generates a token that is only 1297 valid for forwarding messages to or from SRelay1. SRelay2 knows it 1298 is connected to SRelay1 because of the mutual TLS. 1300 The tokens are carried in the resource portion of the MSRP URLs. The 1301 length of time the tokens are valid for is negotiated using the 1302 Expire header in the AUTH request. Clients need to re-negotiate the 1303 tokens using a new offer/answer[14] exchange (e.g. a SIP re-invite) 1304 before the tokens expire. 1306 Note that this scheme relies on relays as trusted nodes, acting on 1307 behalf of the users authenticated to them. There is no security 1308 mechanism to prevent relays on the path from inserting forged 1309 messages, manipulating the contents of messages, sending messages in 1310 a session to a party other than that specified by the sender, or from 1311 copying them to a third party. However, the one-to-one binding 1312 between session identifiers and sessions helps mitigate any damage 1313 that can be caused by rogue relays by limiting the destinations to 1314 which forged or modified messages can be sent to the two parties 1315 involved in the session, and only for the duration of the session. 1316 Additionally, the use of S/MIME encryption can be employed to limit 1317 the utility of redirecting messages. Finally, clients can employ 1318 S/MIME signatures to guarantee the authenticity of messages they 1319 send, making it possible under some circumstances to detect relay 1320 manipulation or the forging of messages. 1322 Clients are not the only actors in the network who need to trust 1323 relays to act in non-malicious ways. If a relay does not have a 1324 direct TLS connection with the client on whose behalf it is acting 1325 (i.e. There are one or more intervening relays), it is at the mercy 1326 of any such intervening relays to accurately transmit the messages 1327 sent to and from the client. If a stronger guarantee of the 1328 authentic origin of a message is necessary (e.g. The relay is 1329 performing logging of messages as part of a legal requirement), then 1330 users of that relay can be instructed by their administrators to use 1331 detached S/MIME signatures on all messages sent by their client. The 1332 relay can enforce such a policy by returning a 415 response to any 1333 SEND requests using a top-level MIME type other than "multipart/ 1334 signed." Such relays may choose to make policy decisions (such as 1335 terminating sessions and/or suspending user authorization) if such 1336 signatures fail to match the contents of the message. 1338 10. IANA Considerations 1340 10.1 New MSRP Method 1342 This specification defines a new MSRP method, to be added to the 1343 Methods sub-registry under the MSRP Parameters registry: AUTH. See 1344 Section 5.1 for details on the AUTH method. 1346 10.2 New MSRP Headers 1348 This specification defines several new MSRP header fields, to be 1349 added to the header-field sub-registry under the MSRP Parameters 1350 registry: 1351 o Expires 1352 o Min-Expires 1353 o Max-Expires 1354 o Use-Path 1355 o WWW-Authenticate 1356 o Authorization 1357 o Authentication-Info 1359 10.3 New MSRP Response Codes 1361 This specification defines two new MSRP status codes, to be added to 1362 the status-code sub-registry under the MSRP Parameters registry: 1364 The 401 response indicates that an AUTH request contained no 1365 credentials, an expired nonce value, or invalid credentials. The 1366 response includes a "WWW-Authenticate" header containing a challenge 1367 (among other fields); see Section 9.1 for further details. The 1368 default response phrase for this response is "Unauthorized". 1370 The 403 response indicates that an AUTH request contained credentials 1371 sufficient to authenticate a user, but that the authenticated user is 1372 not authorized to use the relay. 1374 11. Example SDP with multiple hops 1376 The following section shows an example SDP that could occur in a SIP 1377 message to set up an MSRP session between Alice and Bob where Bob 1378 uses a relay. Alice makes an offer with a path to Alice. 1380 c=IN IP4 a.example.com 1381 m=message 1234 TCP/MSRP * 1382 a=accept-types: message/cpim text/plain text/html 1383 a=path:msrp://a.example.com:1234/agic456;tcp 1385 In this offer Alice wishes to receive MSRP messages at a.example.com. 1386 She wants to use TCP as the transport for the MSRP session. She can 1387 accept message/cpim, text/plain and text/html message bodies in SEND 1388 requests. She does not need a relay to setup the MSRP session. 1390 To this offer, Bob's answer could look like: 1391 c=IN IP4 bob.example.com 1392 m=message 1234 TCP/TLS/MSRP * 1393 a=accept-types: message/cpim text/plain 1394 a=path:msrps://relay.example.com:9000/hjdhfha;tcp \ 1395 msrps://bob.example.com:1234/fuige;tcp 1397 Here Bob wishes to receive the MSRP messages at bob.example.com. He 1398 can accept only message/cpim and text/plain message bodies in SEND 1399 requests and has rejected the text/html content offered by Alice. He 1400 wishes to use a relay called relay.example.com for the MSRP session. 1402 12. Acknowledgments 1404 Many thanks to Avshalom Houri, Hisham Khartabil, Robert Sparks, 1405 Miguel Garcia, Hans Persson, and Orit Levin, who provided detailed 1406 proof reading and helpful text. Thanks to the following members of 1407 the SIMPLE WG for spirited discussions on session mode: Chris 1408 Boulton, Ben Campbell, Juhee Garg, Paul Kyzivat, Allison Mankin, Aki 1409 Niemi, Pekka Pessi, Jon Peterson, Brian Rosen, Jonathan Rosenberg, 1410 and Dean Willis. 1412 13. References 1414 13.1 Normative References 1416 [1] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1417 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 1418 Basic and Digest Access Authentication", RFC 2617, June 1999. 1420 [2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and 1421 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 1422 January 1999. 1424 [3] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 1425 (S/MIME) Version 3.1 Message Specification", RFC 3851, 1426 July 2004. 1428 [4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1429 specifying the location of services (DNS SRV)", RFC 2782, 1430 February 2000. 1432 [5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1433 T. Wright, "Transport Layer Security (TLS) Extensions", 1434 RFC 3546, June 2003. 1436 [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1437 Transport Layer Security (TLS)", RFC 3268, June 2002. 1439 [7] Handley, M. and V. Jacobson, "SDP: Session Description 1440 Protocol", RFC 2327, April 1998. 1442 [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1443 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1444 Session Initiation Protocol", RFC 3261, June 2002. 1446 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1447 Levels", BCP 14, RFC 2119, March 1997. 1449 [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1450 Specifications: ABNF", RFC 2234, November 1997. 1452 [11] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The 1453 Message Session Relay Protocol", 1454 draft-ietf-simple-message-sessions-14 (work in progress), 1455 February 2006. 1457 13.2 Informative References 1459 [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1460 Extensions (MIME) Part One: Format of Internet Message Bodies", 1461 RFC 2045, November 1996. 1463 [13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1464 Extensions (MIME) Part Two: Media Types", RFC 2046, 1465 November 1996. 1467 [14] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1468 Session Description Protocol (SDP)", RFC 3264, June 2002. 1470 Authors' Addresses 1472 Cullen Jennings 1473 Cisco Systems, Inc. 1474 170 West Tasman Dr. 1475 MS: SJC-21/2 1476 San Jose, CA 95134 1477 USA 1479 Phone: +1 408 421-9990 1480 Email: fluffy@cisco.com 1482 Rohan Mahy 1483 Plantronics 1485 Email: rohan@ekabal.com 1487 Adam Roach 1488 Estacado Systems 1489 17210 Campbell Rd. 1490 Suite 250 1491 Dallas, TX 75252 1492 US 1494 Phone: sip:adam@estacado.net 1495 Email: adam@estacado.net 1497 Appendix A. Implementation Considerations 1499 This text is not necessary in order to implement MSRP in an 1500 interoperable way, but is still useful as an implementation 1501 discussion for the community. It is purely an implementation detail. 1503 Note: The idea has been proposed of having a relay return a base URL 1504 that the client can use to construct more URLs but this allows 3rd 1505 parties that have had a session with the client to know URLs that the 1506 relay will use for forwarding after the session with the 3rd party 1507 has ended. Effectively this reveals the secret URLs to 3rd parties 1508 which compromises the security of the solution so this approach is 1509 not used. 1511 An alternative to this approach causes the relays to return a URL 1512 which is divided into an index portion and a secret portion. The 1513 client can encrypt its identifier and its own opaque data with the 1514 secret portion, and concatenate this with the index portion to create 1515 a plurality of valid URLs. When the relay receives one of these 1516 URLs, it could use the index to lookup the appropriate secret, 1517 decrypt the client portion and verify that it contains the client 1518 identifier. The relay can then forward the request. The client does 1519 not need to send an AUTH request for each URL it uses. This is an 1520 implementation detail which is out of scope of this document. 1522 It is possible to implement forwarding requirements in a farm without 1523 the relay saving any state. One possible implementation that a relay 1524 might use is described in the rest of this section. When a relay 1525 starts up it could pick a crypto random 128 bit password (K) and 128 1526 bit initialization vector (IV). If the relay was actually a farm of 1527 servers with the same DNS name, all the machines in the farm would 1528 need to share the same K. When an AUTH request was received the relay 1529 forms a string that contains: the expiry time of the URL, an 1530 indication if the previous hop was mutual TLS authenticated or not 1531 and if it was, the name of the previous hop, if it was not, the 1532 identifier for the connection which received the AUTH request. This 1533 string would be padded by appending a byte with the value 0x80 then 1534 adding zero or more bytes with the value of 0x00 until the string 1535 length is a multiple of 16 bytes long. A new random IV vector would 1536 be selected (it needs to change because it forms the salt) and the 1537 padded string would be encrypted using AES-CBC with a key of K. The 1538 IV and encrypted data and an SPI (security parameter index) that 1539 changes each time K changes would be base 64 encoded and form the 1540 resource portion of the request URL. The SPI allows the key to be 1541 changed and for the system to know which K should be used. Later 1542 when the relay receives this URL, it could decrypt it and check that 1543 the current time was before the expiry time and check that the 1544 messages was coming from or going to the connection or location 1545 specified in the URL. Integrity protection is not required because 1546 it is extremely unlikely that random data that was decrypted would 1547 result in a valid location that was the same as the messages was 1548 routing to or from. When implementing something like this, 1549 implementers should be careful not to use a scheme like EBE that 1550 would allows portions of encrypted tokens to be cut and pasted into 1551 other URLs. 1553 Intellectual Property Statement 1555 The IETF takes no position regarding the validity or scope of any 1556 Intellectual Property Rights or other rights that might be claimed to 1557 pertain to the implementation or use of the technology described in 1558 this document or the extent to which any license under such rights 1559 might or might not be available; nor does it represent that it has 1560 made any independent effort to identify any such rights. Information 1561 on the procedures with respect to rights in RFC documents can be 1562 found in BCP 78 and BCP 79. 1564 Copies of IPR disclosures made to the IETF Secretariat and any 1565 assurances of licenses to be made available, or the result of an 1566 attempt made to obtain a general license or permission for the use of 1567 such proprietary rights by implementers or users of this 1568 specification can be obtained from the IETF on-line IPR repository at 1569 http://www.ietf.org/ipr. 1571 The IETF invites any interested party to bring to its attention any 1572 copyrights, patents or patent applications, or other proprietary 1573 rights that may cover technology that may be required to implement 1574 this standard. Please address the information to the IETF at 1575 ietf-ipr@ietf.org. 1577 Disclaimer of Validity 1579 This document and the information contained herein are provided on an 1580 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1581 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1582 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1583 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1584 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1585 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1587 Copyright Statement 1589 Copyright (C) The Internet Society (2006). This document is subject 1590 to the rights, licenses and restrictions contained in BCP 78, and 1591 except as set forth therein, the authors retain all their rights. 1593 Acknowledgment 1595 Funding for the RFC Editor function is currently provided by the 1596 Internet Society.