idnits 2.17.1 draft-ietf-simple-msrp-relays-10.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 1616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1606. ** 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 580 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 (December 28, 2006) is 6329 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 ** Obsolete normative reference: RFC 3280 (ref. '12') (Obsoleted by RFC 5280) Summary: 11 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: July 1, 2007 R. Mahy 5 Plantronics 6 A. B. Roach 7 Estacado Systems 8 December 28, 2006 10 Relay Extensions for the Message Sessions Relay Protocol (MSRP) 11 draft-ietf-simple-msrp-relays-10.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 July 1, 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 . . . . . . . . . . . . . . . . . . 11 61 4. New Protocol Elements . . . . . . . . . . . . . . . . . . . . 12 62 4.1. The AUTH Method . . . . . . . . . . . . . . . . . . . . . 12 63 4.2. The Use-Path header . . . . . . . . . . . . . . . . . . . 12 64 4.3. The HTTP Authentication "WWW-Authenticate" header . . . . 13 65 4.4. The HTTP Authentication "Authorization" header . . . . . . 13 66 4.5. The HTTP Authentication "Authentication-Info" header . . . 13 67 4.6. Time-related headers . . . . . . . . . . . . . . . . . . . 13 68 5. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 13 69 5.1. Connecting to relays acting on your behalf . . . . . . . . 13 70 5.2. Sending requests . . . . . . . . . . . . . . . . . . . . . 18 71 5.3. Receiving Requests . . . . . . . . . . . . . . . . . . . . 19 72 5.4. Managing Connections . . . . . . . . . . . . . . . . . . . 19 73 6. Relay behavior . . . . . . . . . . . . . . . . . . . . . . . . 19 74 6.1. Handling Incoming Connections . . . . . . . . . . . . . . 19 75 6.2. Generic request behavior . . . . . . . . . . . . . . . . . 19 76 6.3. Receiving AUTH requests . . . . . . . . . . . . . . . . . 20 77 6.4. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 21 78 6.4.1. Forwarding SEND requests . . . . . . . . . . . . . . . 21 79 6.4.2. Forwarding non-SEND requests . . . . . . . . . . . . . 22 80 6.4.3. Handling Responses . . . . . . . . . . . . . . . . . . 23 81 6.5. Managing Connections . . . . . . . . . . . . . . . . . . . 23 82 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 23 83 8. Finding MSRP Relays . . . . . . . . . . . . . . . . . . . . . 25 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 85 9.1. Using HTTP Authentication . . . . . . . . . . . . . . . . 26 86 9.2. Using TLS . . . . . . . . . . . . . . . . . . . . . . . . 27 87 9.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 28 88 9.4. Security Mechanism . . . . . . . . . . . . . . . . . . . . 30 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 90 10.1. New MSRP Method . . . . . . . . . . . . . . . . . . . . . 31 91 10.2. New MSRP Headers . . . . . . . . . . . . . . . . . . . . . 31 92 10.3. New MSRP Response Codes . . . . . . . . . . . . . . . . . 32 93 11. Example SDP with multiple hops . . . . . . . . . . . . . . . . 32 94 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 96 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33 97 13.2. Informative References . . . . . . . . . . . . . . . . . . 34 98 Appendix A. Implementation Considerations . . . . . . . . . . . . 34 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 100 Intellectual Property and Copyright Statements . . . . . . . . . . 37 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[13][14] 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, there 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 verifies that the name 184 in the certificate matches the name of the relay that it is trying to 185 connect to. Such verification is performed according to the 186 procedures defined in Section 9.2. After verifying that it has 187 connected to the proper host, the client authenticates itself to the 188 relay using an AUTH request containing appropriate authentication 189 credentials. In a successful AUTH response, the relay provides an 190 msrps: URL associated with the path back to the client that the 191 client can give to other clients for end-to-end message delivery. 193 When clients wish to send a short message, they issue a SEND request 194 with the entire contents of the message. If any relays are required, 195 they are included in the To-Path header. The leftmost URL in the To- 196 Path header is the next hop to deliver a request or response. The 197 rightmost URL in the To-Path header is the final target. 199 SEND requests contain headers that indicate how they are acknowledged 200 in a hop-by-hop form and in an end-to-end form. The default is that 201 SEND messages are acknowledged hop-by-hop. (Each relay that receives 202 a SEND request acknowledges receipt of the request before forwarding 203 the content to the next relay or the final target.) All other 204 requests are acknowledged end-to-end. 206 With the introduction of relays, the subtle semantics of the To-Path 207 and From-Path header become more relevant. The To-Path in both 208 requests and responses is the list of URLs that need to be visited in 209 order to reach the final target of the request or response. The 210 From-Path is the list of URLs that indicate how to get back to the 211 original sender of the request or response. These headers differ 212 from the To and From headers in SIP, which do not "swap" from request 213 to response. (Note that sometimes a request is sent to or from an 214 intermediary directly.) 216 When a relay forwards a request, it removes its address from the To- 217 Path header and inserts it as the first URL in the From-Path header. 218 For example if the path from Alice to Bob is through relays A and B, 219 when B receives the request it contains path headers that look like 220 this: (Note that MSRP does not permit line folding. A "\" in the 221 examples shows a line continuation due to limitations in line length 222 of this document. Neither the backslash, nor the extra CRLF are 223 included in the actual request or response.) 225 To-Path: msrps://B.example.com/bbb;tcp \ 226 msrps://Bob.example.com/bob;tcp 227 From-Path: msrps://A.example.com/aaa;tcp \ 228 msrps://Alice.example.com/alice;tcp 230 after forwarding the request, the path headers look like this: 232 To-Path: msrps://Bob.example.com/bob;tcp 233 From-Path: msrps://B.example.com/bbb;tcp \ 234 msrps://A.example.com/aaa;tcp \ 235 msrps://Alice.example.com/alice;tcp 237 The sending of an acknowledgment for SEND requests is controlled by 238 the Success-Report and Failure-Report headers and works the same way 239 as in the base MSRP protocol. When a relay receives a SEND request, 240 if the Failure-Report is set to "yes", it means that the previous hop 241 is running a timer and the relay needs to send a response to the 242 request. If the final response conveys an error, the previous hop is 243 responsible for constructing the error report and sending it back to 244 the original sender of the message. The 200 response acknowledges 245 the receipt of the request so that the previous hop knows that it is 246 no longer responsible for the request. If the relay knows that it 247 will not be able to deliver the request and the Failure-Report is set 248 to any value other than "no", then it sends a REPORT to tell the 249 sender about the error. If the Failure-Report is set to "yes", then 250 after the relay is done sending the request to the next hop it starts 251 running a timer; if the timer expires before a response is received 252 from the next hop, the relay assumes that an error has happened and 253 sends a REPORT to the sender. If the Failure-Report is not set to 254 "yes", there is no need for the relay to run this timer. 256 The following example show a typical MSRP session. The AUTH requests 257 are explained in a later section but left in the example for call 258 flow completeness. 260 Alice a.example.org b.example.net Bob 261 | | | | 262 |::::::::::::::::::::>| connection opened |<::::::::::::::::::::| 263 |--- AUTH ----------->| |<-- AUTH ------------| 264 |<-- 200 OK-----------| |--- 200 OK---------->| 265 | | | | 266 .... time passes .... 267 | | | | 268 |--- SEND ----------->| | | 269 |<-- 200 OK ----------|:::::::::::::::::::>| (slow link) | 270 | |--- SEND ---------->| | 271 | |<-- 200 OK ---------|--- SEND ----------->| 272 | | | ....>| 273 | | | ..>| 274 | | |<-- 200 OK ----------| 275 | | |<-- REPORT ----------| 276 | |<-- REPORT ---------| | 277 |<-- REPORT ----------| | | 278 | | | | 280 The SEND and REPORT messages are shown below to illustrate the To- 281 Path and From-Path headers. (Note that MSRP does not permit line 282 folding. A "\" in the examples shows a line continuation due to 283 limitations in line length of this document. Neither the backslash, 284 nor the extra CRLF are included in the actual request or response.) 285 MSRP 6aef SEND 286 To-Path: msrps://a.example.org:9000/kjfjan;tcp \ 287 msrps://b.example.net:9000/aeiug;tcp \ 288 msrps://bob.example.net:8145/foo;tcp 289 From-Path: msrps://alice.example.org:7965/bar;tcp 290 Success-Report: yes 291 Byte-Range: 1-*/* 292 Message-ID: 87652 293 Content-Type: text/plain 295 Hi Bob, I'm about to send you file.mpeg 296 -------6aef$ 298 MSRP 6aef 200 OK 299 To-Path: msrps://alice.example.org:7965/bar;tcp 300 From-Path: msrps://a.example.org:9000/kjfjan;tcp 301 Message-ID: 87652 302 -------6aef$ 304 MSRP juh76 SEND 305 To-Path: msrps://b.example.net:9000/aeiug;tcp \ 306 msrps://bob.example.net:8145/foo;tcp 307 From-Path: msrps://a.example.org:9000/kjfjan;tcp \ 308 msrps://alice.example.org:7965/bar;tcp 309 Success-Report: yes 310 Message-ID: 87652 311 Byte-Range: 1-*/* 312 Content-Type: text/plain 314 Hi Bob, I'm about to send you file.mpeg 315 -------juh76$ 317 MSRP juh76 200 OK 318 To-Path: msrps://a.example.org:9000/kjfjan;tcp 319 From-Path: msrps://b.example.net:9000/aeiug;tcp 320 Message-ID: 87652 321 -------juh76$ 322 MSRP xght6 SEND 323 To-Path: msrps://bob.example.net:8145/foo;tcp 324 From-Path: msrps://b.example.net:9000/aeiug;tcp \ 325 msrps://a.example.org:9000/kjfjan;tcp \ 326 msrps://alice.example.org:7965/bar;tcp 327 Success-Report: yes 328 Message-ID: 87652 329 Byte-Range: 1-*/* 330 Content-Type: text/plain 332 Hi Bob, I'm about to send you file.mpeg 333 -------xght6$ 335 MSRP xght6 200 OK 336 To-Path: msrps://b.example.net:9000/aeiug;tcp 337 From-Path: msrps://bob.example.net:8145/foo;tcp 338 Message-ID: 87652 340 MSRP yh67 REPORT 341 To-Path: msrps://b.example.net:9000/aeiug;tcp \ 342 msrps://a.example.org:9000/kjfjan;tcp \ 343 msrps://alice.example.org:7965/bar;tcp 344 From-Path: msrps://bob.example.net:8145/foo;tcp 345 Message-ID: 87652 346 Byte-Range: 1-39/39 347 Status: 000 200 OK 348 -------yh67$ 350 MSRP yh67 REPORT 351 To-Path: msrps://a.example.org:9000/kjfjan;tcp \ 352 msrps://alice.example.org:7965/bar;tcp 353 From-Path: msrps://b.example.net:9000/aeiug;tcp \ 354 msrps://bob.example.net:8145/foo;tcp 355 Message-ID: 87652 356 Byte-Range: 1-39/39 357 Status: 000 200 OK 358 -------yh67$ 359 MSRP yh67 REPORT 360 To-Path: msrps://alice.example.org:7965/bar;tcp 361 From-Path: msrps://a.example.org:9000/kjfjan;tcp \ 362 msrps://b.example.net:9000/aeiug;tcp \ 363 msrps://bob.example.net:8145/foo;tcp 364 Message-ID: 87652 365 Byte-Range: 1-39/39 366 Status: 000 200 OK 367 -------yh67$ 369 When sending large content, the client may split up a message into 370 smaller pieces; each SEND request might contain only a portion of the 371 complete message. For example, when Alice sends Bob a 4GB file 372 called "file.mpeg", she sends several SEND requests each with a 373 portion of the complete message. Relays can repack message fragments 374 en-route. As individual parts of the complete message arrive at the 375 final destination client, the receiving client can optionally send 376 REPORT requests indicating delivery status. 378 MSRP nodes can send individual portions of a complete message in 379 multiple SEND requests. As relays receive chunks they can reassemble 380 or re-fragment them as long as they resend the resulting chunks in 381 order. (Receivers still need to be prepared to receive out-of-order 382 chunks however.) If the sender has set the Success-Report header to 383 yes, once a chunk or complete message arrives at the destination 384 client, the destination will send a REPORT request indicating that a 385 chunk arrived end-to-end. This request travels back along the 386 reverse path of the SEND request. Unlike the SEND request, which can 387 be acknowledged along every hop, REPORT requests are never 388 acknowledged. 390 The following example shows a message being re-chunked through two 391 relays: 393 Alice a.example.org b.example.net Bob 394 | | | | 395 |--- SEND 1-3 ------->| | | 396 |<-- 200 OK ----------| | (slow link) | 397 |--- SEND 4-7 ------->|--- SEND 1-5 ------>| | 398 |<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->| 399 |--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>| 400 |<-- 200 OK ----------|<-- 200 OK ---------| ..>| 401 | | |<-- 200 OK ----------| 402 | | |<-- REPORT 1-3 ------| 403 | |<-- REPORT 1-3 -----|--- SEND 4-7 ------->| 404 |<-- REPORT 1-3 ------| | ...>| 405 | | |<-- REPORT 4-7 ----->| 406 | |<-- REPORT 4-7 -----|--- SEND 8-10 ------>| 407 |<-- REPORT 4-7 ------| | ..>| 408 | | |<-- 200 OK ----------| 409 | |<-- REPORT done-----|<-- REPORT done -----| 410 |<-- REPORT done -----| | | 411 | | | | 413 Relays only keep transaction states for a short time for each chunk. 414 Delivery over each hop should take no more than 32 seconds after the 415 last byte of data is sent. Client applications define their own 416 implementation-dependent timers for end-to-end message delivery. 418 For client to client communication, the sender of a message typically 419 opens a new TCP connection (with or without TLS) if one is needed. 420 Relays reuse existing connections first, but can open new connections 421 (typically to other relays) to deliver requests such as SEND or 422 REPORT. Responses can only be sent over existing connections. 424 The relationship between MSRP and signaling protocols (such as SIP) 425 is unchanged by this document, and is as described in [11]. An 426 example of an SDP exchange for an MSRP session involving relays is 427 shown in Section 11. 429 3.1. Authorization Overview 431 A key element of this protocol is that it cannot introduce open 432 relays, with all the associated problems they create, including DoS 433 attacks. A message is only forwarded by a relay if it is either 434 going to or coming from a client that has authenticated to the relay 435 and been authorized for relaying messages on that particular session. 436 Because of this, clients use an AUTH message to authenticate to a 437 relay and get a URL that can be used for forwarding messages. 439 If a client wishes to use a relay, it sends an AUTH request to the 440 relay. The client authenticates the relay using the relay's TLS 441 certificate. The client uses HTTP Digest Authentication [1] to 442 authenticate to the relay. When the authentication succeeds the 443 relay returns a 200 response that contains the URL that the client 444 can use in the MSRP path for the relay. 446 A typical challenge response flow is shown below: 448 Alice a.example.org 449 | | 450 |::::::::::::::::::::>| 451 |--- AUTH ----------->| 452 |<- 401 Unauthorized -| 453 |--- AUTH ----------->| 454 |<-- 200 OK-----------| 455 | | 457 The URL that the client should use is returned in the Use-Path header 458 of the 200. 460 Note that URLs returned to the client are effectively secret tokens 461 that should be shared only with the other MSRP client in a session. 462 For that reason, the client MUST NOT reuse the same URL for multiple 463 sessions, and needs to protect these URLs from eavesdropping. 465 4. New Protocol Elements 467 4.1. The AUTH Method 469 AUTH requests are used by clients to create a handle they can use to 470 receive incoming requests. AUTH requests also contain credentials 471 used to authenticate a client and authorization policy used to block 472 Denial of Service attacks. 474 In response to an AUTH request, a successful response contains a Use- 475 Path header with a list of URLs that the Client can give to its peers 476 to route responses back to the Client. 478 4.2. The Use-Path header 480 The Use-Path header is a list of URLs provided by an MSRP Relay in 481 response to a successful AUTH request. This list of URLs can be used 482 by the MSRP Client that sent the AUTH request to receive MSRP 483 requests, and to advertise this list of URLs, for example in a 484 session description. URLs in the Use-Path header MUST include a 485 fully qualified domain name (as opposed to a numeric IP address) and 486 an explicit port number. 488 The URLs in the Use-Path header are in the same order that the 489 authenticating client uses them in a To-Path header. Instructions on 490 forming To-Path headers and SDP[7] path attributes from information 491 in the Use-Path header is discussed in Section 5.1. 493 4.3. The HTTP Authentication "WWW-Authenticate" header 495 The "WWW-Authenticate" header contains a challenge token used in HTTP 496 Digest Authentication procedure (from RFC 2617 [1]). The usage of 497 HTTP Digest authentication in MSRP is described in detail in 498 Section 5.1. 500 4.4. The HTTP Authentication "Authorization" header 502 The "Authorization" header contains authentication credentials for 503 HTTP Digest Authentication (from RFC 2617 [1]). The usage of HTTP 504 Digest authentication in MSRP is described in detail in Section 5.1. 506 4.5. The HTTP Authentication "Authentication-Info" header 508 The "Authentication-Info" header contains future challenges to be 509 used for HTTP Digest Authentication (from RFC 2617 [1]). The usage 510 of HTTP Digest authentication in MSRP is described in detail in 511 Section 5.1. 513 4.6. Time-related headers 515 The Expires header in a request provides a relative time after which 516 the action implied by the method of the request is no longer of 517 interest. In a request, the Expires header indicates how long the 518 sender would like the request to remain valid. In a response, the 519 Expires header indicates how long the responder considers this 520 information relevant. Specifically an Expires header in an AUTH 521 request indicates how long the provided URLs will be valid. 523 The Min-Expires header contains the minimum duration a server will 524 permit in an Expires header. It is sent only in 423 "Interval Out- 525 of-Bounds" responses. Likewise the Max-Expires header contains the 526 maximum duration a server will permit in an Expires header. 528 5. Client behavior 530 5.1. Connecting to relays acting on your behalf 532 Clients that want to use the services of a relay or list of relays 533 need to send an AUTH request to each relay that will act on their 534 behalf. (For example, some organizations could deploy an "intra-org" 535 relay and an "extra-org" relay.) The inner relay is used to tunnel 536 the AUTH requests to the outer relay. For example, the client will 537 send an AUTH to intra-org and get back a path that can be used for 538 forwarding through intra-org. The client would then send a second 539 AUTH destined to extra-org but sent through intra-org. The intra-org 540 relay forwards this to extra-org and extra-org returns a path that 541 can be used to forward messages from another destination to extra-org 542 to intra-org and then on to this client. Each relay authenticates 543 the client. The client authenticates the first relay and each relay 544 authenticates the next relay. 546 Clients can be configured (typically through discovery or manual 547 provisioning) with a list of relays they need to use. They MUST be 548 able to form a connection to the first relay and send an AUTH command 549 to get a URL that can be used in a To-Path header. The client can 550 authenticate its first relay by looking at the relay's TLS 551 certificate. The client MUST authenticate itself to each of its 552 relays using HTTP Digest authentication [1] (see Section 9.1 for 553 details). 555 The relay returns a URL, or list of URLs, in the "Use-Path" header of 556 a success response. Each URL SHOULD be used for only one unique 557 session. These URLs are used by the client in the path attribute 558 that is sent in the SDP to set up the session, and in the To-Path 559 header of outgoing requests. To form the To-Path header for outgoing 560 requests, the client takes the list of URLs in the Use-Path header 561 after the outermost authentication and appends the list of URLs 562 provided in the path attribute in the peer's session description. To 563 form the SDP path attribute to provide to the peer, the client 564 reverses the list of URLs in the Use-Path header (after the outermost 565 authentication), and appends the client's own URL. 567 For example, "A" has to traverse its own relays "B" and "C", and 568 then relays "D" and "E" in domain2 to reach "F". Client "A" will 569 authenticate with its relays "B" and "C" and eventually receive a 570 Use-Path header containing "B C". Client "A" reverses the list 571 (now "C B") and appends its own URL (now "C B A"), and provides 572 this list to "F" in a path SDP attribute. Client "F" sends its 573 SDP path list "D E F", which client "A" appends to the Use-Path 574 list it received "B C". The resulting To-Path header is "B C D E 575 F". 577 domain 1 domain 2 578 ---------------- ----------------- 580 client relays relays client 581 A ----- B -- C -------- D -- E ----- F 583 Use-Path returned by C: B C 584 path: attribute generated by A: C B A 585 path: attribute received from F: D E F 586 To-Path header generated by A: B C D E F 588 The initial AUTH request sent to a relay by a client will generally 589 not contain an Authorization header, since the client has no 590 challenge to which it can respond. In response to an AUTH request 591 that does not contain an Authorization header, a relay MUST respond 592 with a "401 Unauthorized" response containing a WWW-Authenticate 593 header. The WWW-Authenticate header is formed as described in RFC 594 2617 [1], with the restrictions and modifications described in 595 Section 9.1. The realm chosen by the MSRP relay in such a challenge 596 is a matter of administrative policy. Because a single relay does 597 not have multiple protection spaces in MSRP, it is not unreasonable 598 to always use the relay's hostname as the realm. 600 Upon receiving a 401 response to a request, the client SHOULD fetch 601 the realm from the WWW-Authenticate header in the response and retry 602 the request, including an Authorization header with the correct 603 credentials for the realm. The Authorization header is formed as 604 described in RFC 2617 [1], with the restrictions and modifications 605 described in Section 9.1. 607 When a client wishes to use more than one relay, it MUST send an AUTH 608 request to each relay it wishes to use. Consider a client A, that 609 wishes messages to flow from A to the first relay, R1, then on to a 610 second relay, R2. This client will do a normal AUTH with R1. It 611 will then do an AUTH transaction with R2 that is routed through R1. 612 The client will form this AUTH message by setting the To-Path to 613 msrps://R1;tcp msrps://R2;tcp. R1 will forward this request onward 614 to R2. 616 When sending an AUTH request, the client MAY add an Expires header to 617 request a MSRP URL that is valid for no longer than the provided 618 interval (a whole number of seconds). The server will include an 619 Expires header in a successful response indicating how long its URL 620 from the Use-Path will be valid. Note that each server can return an 621 independent expiration time. 623 Note that MSRP does not permit line folding. A "\" in the examples 624 shows a line continuation due to limitations in line length of this 625 document. Neither the backslash, nor the extra CRLF are included in 626 the actual request or response. 628 (Alice opens a TLS connection to intra.example.com and sends an AUTH 629 request to initiate the authentication process). 631 MSRP 49fh AUTH 632 To-Path: msrps://alice@intra.example.com;tcp 633 From-Path: msrps://alice.example.com:9892/98cjs;tcp 634 -------49fh$ 636 (Alice's relay challenges the AUTH request). 638 MSRP 49fh 401 Unauthorized 639 To-Path: msrps://alice.example.com:9892/98cjs;tcp 640 From-Path: msrps://alice@intra.example.com;tcp 641 WWW-Authenticate: Digest realm="intra.example.com", qop="auth", \ 642 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093" 643 -------49fh$ 645 (Alice responds to the challenge). 647 MSRP 49fi AUTH 648 To-Path: msrps://alice@intra.example.com;tcp 649 From-Path: msrps://alice.example.com:9892/98cjs;tcp 650 Authorization: Digest username="Alice", 651 realm="intra.example.com", \ 652 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", \ 653 qop="auth", nc=00000001, cnonce="0a4f113b", \ 654 response="6629fae49393a05397450978507c4ef1" 655 -------49fi$ 657 (Alice's relay confirms that Alice is an authorized user. As a 658 matter of local policy, it includes an "Authentication-Info" header 659 with a new nonce value to expedite future AUTH requests.) 661 MSRP 49fi 200 OK 662 To-Path: msrps://alice.example.com:9892/98cjs;tcp 663 From-Path: msrps://alice@intra.example.com;tcp 664 Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp 665 Authentication-Info: nextnonce="40f2e879449675f288476d772627370a",\ 666 rspauth="7327570c586207eca2afae94fc20903d", \ 667 cnonce="0a4f113b", nc=00000001, qop="auth" 668 Expires: 900 669 -------49fi$ 671 (Alice now sends an AUTH request to her "external" relay through her 672 "internal" relay, using the URL she just obtained; the AUTH request 673 is challenged.) 675 MSRP mnbvw AUTH 676 To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 677 msrps://extra.example.com;tcp 678 From-Path: msrps://alice.example.com:9892/98cjs;tcp 679 -------mnbvw$ 681 MSRP m2nbvw AUTH 682 To-Path: msrps://extra.example.com;tcp 683 From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 684 msrps://alice.example.com:9892/98cjs;tcp 685 -------m2nbvw$ 687 MSRP m2nbvw 401 Unauthorized 688 To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 689 msrps://alice.example.com:9892/98cjs;tcp 690 From-Path: msrps://extra.example.com;tcp 691 WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \ 692 nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO" 693 -------m2nbvw$ 695 MSRP mnbvw 401 Unauthorized 696 To-Path: msrps://alice.example.com:9892/98cjs;tcp 697 From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 698 msrps://extra.example.com;tcp 699 WWW-Authenticate: Digest realm="extra.example.com", qop="auth", \ 700 nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO" 701 -------mnbvw$ 703 (Alice replies to the challenge with her credentials and is then 704 authorized to use the "external" relay). 706 MSRP m3nbvx AUTH 707 To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 708 msrps://extra.example.com;tcp 709 From-Path: msrps://alice.example.com:9892/98cjs;tcp 710 Authorization: Digest username="Alice", 711 realm="extra.example.com", \ 712 nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \ 713 qop="auth", nc=00000001, cnonce="85a0dca8", \ 714 response="cb06c4a77cd90918cd7914432032e0e6" 715 -------m3nbvx$ 716 MSRP m4nbvx AUTH 717 To-Path: msrps://extra.example.com;tcp 718 From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 719 msrps://alice.example.com:9892/98cjs;tcp 720 Authorization: Digest username="Alice", 721 realm="extra.example.com", \ 722 nonce="Uumu8cAV38FGsEF31VLevIbNXj9HWO", \ 723 qop="auth", nc=00000001, cnonce="85a0dca8", \ 724 response="cb06c4a77cd90918cd7914432032e0e6" 725 -------m4nbvx$ 727 MSRP m4nbvx 200 OK 728 To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 729 msrps://alice.example.com:9892/98cjs;tcp 730 From-Path: msrps://extra.example.com;tcp 731 Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 732 msrps://extra.example.com:9000/mywdEe1233;tcp 733 Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \ 734 rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \ 735 cnonce="85a0dca8", nc=00000001, qop="auth" 736 Expires: 1800 737 -------m4nbvx$ 739 MSRP m3nbvx 200 OK 740 To-Path: msrps://alice.example.com:9892/98cjs;tcp 741 From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \ 742 msrps://extra.example.com;tcp 743 Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp \ 744 msrps://extra.example.com:9000/mywdEe1233;tcp 745 Authentication-Info: nextnonce="bz8V080GEA2sLyEDpITF2AZCq7gIkc", \ 746 rspauth="72f109ed2755d7ed0d0a213ec653b3f2", \ 747 cnonce="85a0dca8", nc=00000001, qop="auth" 748 Expires: 1800 749 -------m3nbvx$ 751 5.2. Sending requests 753 The procedure for forming SEND and REPORT requests is identical for 754 clients whether relays are involved or not. The specific procedures 755 are described in section 7 of the core MSRP protocol. 757 As usual, once the next-hop URL is determined, the client MUST find 758 the appropriate address, port, and transport to use and then check if 759 there is already a suitable existing connection to the next-hop 760 target. If so, the client MUST send the request over the most 761 suitable connection. Suitability MAY be determined by a variety of 762 factors such as measured load and local policy, but in most simple 763 implementations a connection will be suitable if it exists and is 764 active. 766 5.3. Receiving Requests 768 The procedure for receiving requests is identical for clients whether 769 relays are involved or not. 771 5.4. Managing Connections 773 Clients should open a connection whenever they wish to deliver a 774 request and no suitable connection exists. For connections to 775 relays, the client should leave a connection up until no sessions 776 have used it for a locally defined period of time, which defaults to 777 5 minutes for foreign relays and one hour for the client's relays. 779 6. Relay behavior 781 6.1. Handling Incoming Connections 783 When a relay receives an incoming connection on a port configured for 784 TLS, it includes a client CertificateRequest in the same record in 785 which it sends its ServerHello. If the TLS client provides a 786 certificate, the server verifies it and continues if the certificate 787 is valid and rooted in a trusted authority. If the TLS client does 788 not provide a certificate, the server assumes that the client is an 789 MSRP endpoint and invokes digest authentication. Once a TCP or TLS 790 channel is negotiated, the server waits for up to 30 seconds to 791 receive an MSRP request over the channel. If no request is received 792 in that time, the server closes the connection. If no successful 793 requests are sent during this probationary period, the server closes 794 the connection. Likewise, if several unsuccessful requests are sent 795 during the probation period and no requests are sent successfully, 796 the server SHOULD close the connection. 798 6.2. Generic request behavior 800 Upon receiving a new request, relays first verify the validity of the 801 request. Relays then examine the first URL in the To-Path header and 802 remove this URL if it matches a URL corresponding to the relay. If 803 the request is not addressed to the relay, the relay immediately 804 drops the corresponding connection over which the request was 805 received. 807 6.3. Receiving AUTH requests 809 When a relay receives an AUTH request, the first thing it does is to 810 authenticate and authorize the previous hop and the client at the far 811 end. If there are no other relays between this relay and the client, 812 then these are the same thing. 814 When the previous hop is a relay, authentication is done with TLS 815 using mutual authentication. If the TLS client presented a host 816 certificate, the relay checks that the subjectAltName in the 817 certificate of the TLS client matches the hostname in the first From- 818 Path URL. If the TLS client doesn't provide a host certificate, the 819 relay assumes the TLS client is an MSRP client and sends it a 820 challenge. 822 Authorization is a matter of local policy at the relay. Many relays 823 will choose to authorize all relays that can be authenticated, 824 possibly in conjunction with a blacklisting mechanism. Relays 825 intended to operate only within a limited federation may choose to 826 authorize only those relays whose identity appears in a provisioned 827 list. Other authorization policies may also be applied. 829 When the previous hop is a client, the previous hop is the same as 830 the identity of the client. The relay checks the credentials 831 (username and password) provided by the client in the Authorization 832 header and checks if this client is allowed to use the relay. If the 833 client is not authorized, the relay returns a 403 response. If the 834 client has requested a particular expiration time in an Expires 835 header, the relay needs to check that the time is acceptable to it 836 and, if not, return an error containing a Min-Expires or Max-Expires 837 header, as appropriate. 839 Next the relay will generate an MSRP URL which allows messages to be 840 forwarded to or from this previous hop. If the previous hop was a 841 relay authenticated by mutual TLS, then the URL MUST be valid to 842 route across any connection the relay has to the previous hop relay. 843 If the previous hop is a client, then the URL MUST only be valid to 844 route across the same connection over which the AUTH request was 845 received. If the client's connection is closed and then reopened, 846 the URL MUST be invalidated. 848 If the AUTH request contains an Expires header, the relay MUST ensure 849 that the URL is invalidated after the expiry time. The URL MUST 850 contain at least 64 bits of cryptographically random material so that 851 it is not guessable by attackers. If a relay is requested to forward 852 a message for which the URL is not valid, the relay MUST discard the 853 message and MAY send a REPORT indicating the AUTH URL was bad. 855 A successful AUTH response returns a Use-Path header which contains 856 an MSRP URL that the client can use. It also returns an Expires 857 header that indicates how long the URL will be valid (expressed as a 858 whole number of seconds). 860 If a relay receives several unsuccessful AUTH requests from a client 861 which is directly connected to it via TLS, the relay SHOULD terminate 862 the corresponding connection. Similarly, if a relay forwards several 863 failed AUTH requests to the same destination that originate from a 864 client that is directly connected to it via TLS, the relay SHOULD 865 terminate the corresponding connection. Determination of a remote 866 AUTH failure can be made by observing an AUTH request containing an 867 "Authorization" header that triggers a 401 response without a 868 "stale=TRUE" indication. These preventive measures apply only to a 869 connection between a relay and a client; a relay SHOULD NOT use 870 excessive AUTH request failures as a reason to terminate a connection 871 with another relay. 873 6.4. Forwarding 875 Before any request is forwarded, the relay MUST check that the first 876 URL in the To-Path header corresponds to a URL that this relay has 877 created and handed out in the Use-Path header of an AUTH request. 878 Next it verifies that either 1) the next hop is the next hop back 879 toward the client that obtained this URL, or 2) the previous hop was 880 the correct previous hop coming from the client that obtained this 881 URL. 883 Since transact-id values are not allowed to conflict on a given 884 connection, a relay will generally need to construct a new 885 transact-id value for any request that it forwards. 887 6.4.1. Forwarding SEND requests 889 If an incoming SEND request contains a Failure-Report header with a 890 value of "yes", an MSRP relay that receives that SEND request MUST 891 respond with a final response immediately. A 200-class response 892 indicates the successful receipt of a message fragment but does not 893 mean that the message has been forwarded on to the next hop. The 894 final response to the SEND MUST be sent only to the previous hop, 895 which could be an MSRP relay or the original sender of the SEND 896 request. 898 If there is a problem further processing the SEND request, or in the 899 response that the relay receives in sending the SEND request to the 900 next hop, and the Failure-Report header is "yes" or "partial", then 901 the relay MUST respond with an appropriate error response in a REPORT 902 back to the original source of the message. 904 If the Failure-Report header is "yes", then the relay MUST run a 905 timer to detect if transmission to the next hop fails. The timer 906 starts when the last byte of the message has been sent to the next 907 hop. If after 32 seconds, the next hop has not sent any response, 908 then the relay MUST construct a REPORT with a status code of 408 to 909 indicate a timeout error happened sending the message, and send the 910 REPORT to the original sender of the message. 912 The MSRP relay MAY further break up the message fragment received in 913 the SEND request into smaller fragments and forward them to the next 914 hop in separate SEND requests. It MAY also combine message fragments 915 received before or after this SEND request, and forward them out in a 916 single SEND request to the next hop identified in the To-Path header. 917 The MSRP relay MUST NOT combine message fragments from SEND requests 918 with different values in the Message-ID header. 920 The MSRP relay MAY choose whether to further fragment the message, or 921 combine message fragments, or send the message as is, based on some 922 policy which is administered, or based on the network speed to the 923 next hop, or any other mechanism. 925 If the MSRP relay has knowledge of the byte range that it will 926 transmit to the next hop, it SHOULD update the Byte-Range header in 927 the SEND request appropriately. 929 Before forwarding the SEND request to the next hop, the MSRP relay 930 MUST inspect the first URL in the To-Path header. If it indicates 931 this relay, the relay removes this URL from the To-Path header and 932 inserts this URL in the From-Path header before any other URLs. If 933 it does not indicate this relay, there has been an error in 934 forwarding at a previous hop. In this case the relay SHOULD discard 935 the message, and if the Failure-Report header is set to "yes", the 936 relay SHOULD generate a failure report. 938 6.4.2. Forwarding non-SEND requests 940 An MSRP relay that receives any request other than a SEND request 941 (including new methods unknown to the relay), first follows the 942 validation and authorization rules for all requests. Then the relay 943 moves its URL from the beginning of the To-Path header, to the 944 beginning of the From-Path header and forwards the request on to the 945 next hop. If it already has a connection to the next hop, it SHOULD 946 use this connection and not form a new connection. If no suitable 947 connection exists, the relay opens a new connection. 949 Requests with an unknown method are forwarded as if they were REPORT 950 requests. An MSRP node MAY be configured to block unknown methods 951 for security reasons. 953 6.4.3. Handling Responses 955 Relays receiving a response first verify that the first URL in the 956 To-Path corresponds to itself; if not, the response SHOULD be 957 dropped. Likewise if the message cannot be parsed, the relay MUST 958 drop the response. Next the relay determines if there are additional 959 URLs in the To-Path. (For responses to SEND requests there will be 960 no additional URLs, whereas responses to AUTH requests have 961 additional URLs directing the response back to the client.) 963 If the response matches an existing transaction, then that 964 transaction is completed and any timers running on it can be removed. 965 If the response is a non 200 response, and the original request was a 966 SEND request which had a Failure-Report header with a value other 967 than "no", then the relay MUST send a REPORT indicating the nature of 968 the failure. The response code received by the relay is used to form 969 the status line in the REPORT that the relay sends. 971 If there are additional URLs in the To-Path header, the relay MUST 972 then move its URL from the To-Path header, insert its URL in front of 973 any other URLs in the From-Path header, and forward the response to 974 the next URL in the To-Path header. The relay sends the request over 975 the best connection which corresponds to the next URL in the To-Path 976 header. If this connection has closed, then the response is silently 977 discarded. 979 6.5. Managing Connections 981 Relays should keep connections open as long as possible. If a 982 connection has not been used in a significant time (more than one 983 hour) it MAY be closed. If the relay runs out of resources and can 984 no longer establish new connections, it SHOULD start closing existing 985 connections. It MAY choose to close the connections based on a least 986 recently used basis. 988 7. Formal Syntax 990 The following syntax specification uses the Augmented Backus-Naur 991 Form (ABNF) as described in RFC-2234 [10]. 993 Note to RFC Editor - Please replace all the following occurrences of 994 RFC-BASE in the RFC number of [11]. 996 ; This ABNF imports all the definitions in the ABNF of RFC-BASE 998 header = Message-ID 999 / Success-Report 1000 / Failure-Report 1001 / Byte-Range 1002 / Status 1003 / Expires 1004 / Min-Expires 1005 / Max-Expires 1006 / Use-Path 1007 / WWW-Authenticate 1008 / Authorization 1009 / Authentication-Info 1010 / ext-header ; this replaces the rule in RFC-BASE 1012 mAUTH = %x41.55.54.48 ; AUTH in caps 1013 method = mSEND / mREPORT / mAUTH 1014 / other-method 1015 ; this replaces the rule in RFC-BASE 1017 WWW-Authenticate = "WWW-Authenticate:" SP "Digest" SP 1018 digest-param *("," SP digest-param) 1020 digest-param = ( realm / nonce / 1021 [ opaque ] / [ stale ] / [ algorithm ] / 1022 qop-options / [auth-param] ) 1024 realm = "realm=" realm-value 1025 realm-value = quoted-string 1027 auth-param = token "=" ( token / quoted-string ) 1029 nonce = "nonce=" nonce-value 1030 nonce-value = quoted-string 1031 opaque = "opaque=" quoted-string 1032 stale = "stale=" ( "true" / "false" ) 1033 algorithm = "algorithm=" ( "MD5" / token ) 1034 qop-options = "qop=" QUOTE qop-list QUOTE 1035 qop-list = qop-value *( "," qop-value ) 1036 qop-value = "auth" / token 1037 quoted-string = QUOTE *( %x20-21 / %x23-7E ) QUOTE 1038 QUOTE = %x22 1040 Authorization = "Authorization:" SP credentials 1042 credentials = "Digest" SP digest-response 1043 *( "," SP digest-response) 1045 digest-response = ( username / realm / nonce 1046 / response / [ algorithm ] / cnonce / 1048 [opaque] / message-qop / 1049 [nonce-count] / [auth-param] ) 1051 username = "username=" username-value 1052 username-value = quoted-string 1053 message-qop = "qop=" qop-value 1054 cnonce = "cnonce=" cnonce-value 1055 cnonce-value = nonce-value 1056 nonce-count = "nc=" nc-value 1057 nc-value = 8LHEX 1058 response = "response=" request-digest 1059 request-digest = QUOTE 32LHEX QUOTE 1060 LHEX = DIGIT / %x61-66 ;lowercase a-f 1062 Authentication-Info = "Authentication-Info:" SP ainfo 1063 *("," ainfo) 1064 ainfo = nextnonce / message-qop 1065 / response-auth / cnonce 1066 / nonce-count 1067 nextnonce = "nextnonce=" nonce-value 1068 response-auth = "rspauth=" response-digest 1069 response-digest = QUOTE *LHEX QUOTE 1071 Expires = "Expires:" SP 1*DIGIT 1072 Min-Expires = "Min-Expires:" SP 1*DIGIT 1073 Max-Expires = "Max-Expires:" SP 1*DIGIT 1075 Use-Path = "Use-Path:" SP MSRP-URL *(SP MSRP-URL) 1077 8. Finding MSRP Relays 1079 When resolving an MSRP URL which contains an explicit port number, an 1080 MSRP node follows the rules in section 6 of the MSRP base 1081 specification. MSRP URLs exchanged in SDP and in To-Path and From- 1082 Path headers in non-AUTH requests MUST have an explicit port number. 1083 (The only message in this specification that can have an MSRP URL 1084 without an explicit port number is in the To-Path header in an AUTH 1085 request.) Similarly, if the hostport of an msrps: URL is an IPv4 1086 address or an IPv6 reference, a port number MUST be present. 1088 The following rules allow MSRP clients to discover MSRP relays more 1089 easily in AUTH requests. If the hostport is a domain name and an 1090 explicit port number is provided, attempt to look up a valid address 1091 record (A or AAAA) for the domain name. Connect using TLS over the 1092 default transport (TCP) with the default port number. 1094 If a domain name is provided but no port number, perform a DNS SRV 1096 [4] lookup for the '_msrps' service and '_tcp' transport at the 1097 domain name, and follow the SRV selection algorithm defined in that 1098 specification to select the entry. (An '_msrp' service is not 1099 defined, since AUTH are only sent over TLS.) If no SRV records are 1100 found, try an address lookup (A or AAAA) using the default port 1101 number procedures described in the previous paragraph. Note that 1102 AUTH requests MUST only be sent over a TLS-protected channel. An SRV 1103 lookup in the example.com domain might return: 1105 ;; in example.com. Pri Wght Port Target 1106 _msrps._tcp IN SRV 0 1 9000 server1.example.com. 1107 _msrps._tcp IN SRV 0 2 9000 server2.example.com. 1109 If implementing a relay farm, it is RECOMMENDED that each member of 1110 the relay farm have an SRV entry. If any members of the farm have 1111 multiple IP addresses (for example an IPv4 and an IPv6 address), each 1112 of these addresses SHOULD be registered in DNS as separate A or AAAA 1113 records corresponding to a single target. 1115 9. Security Considerations 1117 This section first describes the security mechanisms available for 1118 use in MSRP. Then the threat model is presented. Finally we list 1119 implementation requirements related to security. 1121 9.1. Using HTTP Authentication 1123 AUTH requests MUST be authenticated. The authentication mechanism 1124 described in this specification uses HTTP Digest authentication. 1125 HTTP Digest authentication is performed as described in RFC 2617 [1], 1126 with the following restrictions and modifications: 1128 o Clients MUST NOT attempt to use Basic authentication, and relays 1129 MUST NOT request or accept Basic authentication. 1130 o The use of a qop value of auth-int makes no sense for MSRP. 1131 Integrity protection is provided by the use of TLS. Consequently, 1132 MSRP relays MUST NOT indicate a qop of auth-int in a challenge. 1133 o The interaction between the MD5-sess algorithm and the nextnonce 1134 mechanism is underspecified in RFC 2617 [1]; consequently, MSRP 1135 relays MUST NOT send challenges indicating the MD5-sess algorithm. 1136 o Clients SHOULD consider the protection space within a realm to be 1137 scoped to the authority portion of the URL, without regard to the 1138 contents of the path portion of the URL. Accordingly, relays 1139 SHOULD NOT send the "domain" parameter on the "WWW-Authenticate" 1140 header, and clients MUST ignore it if present. 1142 o Clients and relays MUST include a qop parameter in all "WWW- 1143 Authenticate" and "Authorization" headers. 1144 o Clients MUST send cnonce and nonce-count parameters in all 1145 "Authorization" headers. 1146 o The request-URI to be used in calculating H(A2) is the right-most 1147 URL in the To-Path header. 1148 o Relays MUST include rspauth, cnonce, nc, and qop parameters in a 1149 "Authentication-Info" header for all "200 OK" responses to an AUTH 1150 request. 1152 Note that the BNF in RFC2617 has a number of errors. In particular, 1153 the value of the uri parameter MUST be in quotes; further, the 1154 parameters in the Authentication-Info header MUST be separated by 1155 commas. The BNF in this document is correct, as are the examples in 1156 RFC 2617 [1]. 1158 The use of the nextnonce and nc parameters are supported as described 1159 in RFC 2617 [1], which provides guidance on how and when they should 1160 be used. As a slight modification to the guidance provided in RFC 1161 2617, implementors of relays should note that AUTH requests cannot be 1162 pipelined; consequently, there is no detrimental impact on throughput 1163 when relays use the nextnonce mechanism. 1165 See Section 5.1 for further information on the procedures for client 1166 authentication. 1168 9.2. Using TLS 1170 TLS is used to authenticate relays to senders and to provide 1171 integrity and confidentiality for the headers being transported. 1172 MSRP clients and relays MUST implement TLS. Clients MUST send the 1173 TLS ClientExtendedHello extended hello information for server name 1174 indication as described in RFC 3546 [5]. A TLS cipher-suite of 1175 TLS_RSA_WITH_AES_128_CBC_SHA [6] MUST be supported (other cipher- 1176 suites MAY also be supported). A relay MUST act as a TLS server and 1177 present a certificate with its identity in the SubjectAltName using 1178 the choice type of dnsName. Relay-to-relay connections MUST use TLS 1179 with mutual authentication. Client-to-relay communications MUST use 1180 TLS for AUTH requests and responses. 1182 The SubjectAltName in the certificate received from a relay MUST 1183 match the hostname part of the URI, and the certificate MUST be valid 1184 according to RFC 3280 [12], including having a date that is valid and 1185 being signed by an acceptable certification authority. After 1186 validating that such is the case, the device that initiated the TLS 1187 connection can assume that it has connected to the correct relay. 1189 This document does not define procedures for using mutual 1190 authentication between an MSRP client and an MSRP relay. 1191 Authentication of clients is handled using the the AUTH method via 1192 the procedures described in Section 5.1 and Section 6.3. Other 1193 specifications may define the use of TLS mutual authentication for 1194 the purpose of authenticating users associated with MSRP clients. 1195 Unless operating under such other specifications, MSRP clients SHOULD 1196 present an empty certificate list (if one is requested by the MSRP 1197 relay), and MSRP relays SHOULD ignore any certificates presented by 1198 the client. 1200 This behavior is defined specifically to allow forward- 1201 compatibility with specifications that define the use of TLS for 1202 client authentication. 1204 Note: When relays are involved in a session, TCP without TLS is only 1205 used when a user that does not use relays connects directly to the 1206 relay of a user that is using relays. In this case the client has no 1207 way to authenticate the relay other than to use the URLs that form a 1208 shared secret in the same way they are used when no relays are 1209 involved. 1211 9.3. Threat Model 1213 This section discusses the threat model and the broad mechanism that 1214 needs to be in place to secure the protocol. The next section 1215 describes the details of how the protocol mechanism meets the broad 1216 requirements. 1218 MSRP allows two peer-to-peer clients to exchange messages. Each peer 1219 can select a set of relays to perform certain policy operation for 1220 them. This combined set of relays is referred to as the route set. 1221 A channel outside of MSRP always needs to exist, such as out-of-band 1222 provisioning or an explicit rendezvous protocol such as SIP, that can 1223 securely negotiate setting up the MSRP session and communicate the 1224 route set to both clients. A client may trust a relay with certain 1225 types of routing and policy decisions but it might or might not trust 1226 the relay with all the contents of the session. For example, a relay 1227 being trusted to look for viruses would probably need to be allowed 1228 to see all the contents of the session. A relay that helped deal 1229 with traversal of the ISP's NAT would likely not be trusted with the 1230 contents of the session but would be trusted to correctly forward 1231 messages. 1233 Clients implicitly trust the relays through which they send and 1234 receive messages to honor the routing indicated in those messages, 1235 within the constraints of the MSRP protocol. Clients also need to 1236 trust that the relays they use do not insert new messages on their 1237 behalf or modify messages sent to or by the clients. It is worth 1238 noting that some relays are in a position to cause a client to 1239 misroute a message by maliciously modifying a Use-Path returned by a 1240 relay further down the chain. However this is not an additional 1241 security threat because these same relays can also decide to misroute 1242 a message in the first place. If the relay is trusted to route 1243 messages, it is reasonable to trust it not to tamper with the Use- 1244 Path header. If the relay can not be trusted to route messages, then 1245 it can not be used. 1247 Under certain circumstances, relays need to trust other relays not to 1248 modify information between them and the client they represent. For 1249 example, if a client is operating through Relay A to get to Relay B, 1250 and Relay B is logging messages sent by the client, Relay B may be 1251 required to authenticate that the messages they logged originate with 1252 the client, and have not been modified or forged by Relay A. This can 1253 be done by having the client sign the message. 1255 Clients need to be able to authenticate that the relay they are 1256 communicating with is the one they trust. Likewise, relays need to 1257 be able to authenticate that the client is the one they are 1258 authorized to forward information to. Clients need the option of 1259 ensuring information between the relay and the client is integrity 1260 protected and confidential to elements other than the relays and 1261 clients. To simplify the number of options, traffic between relays 1262 is always integrity protected and encrypted regardless of whether the 1263 client requests it or not. There is no way for the clients to tell 1264 the relays what strength of cryptographic mechanisms to use between 1265 relays other than to have the clients choose relays that are 1266 administered to require an adequate level of security. 1268 The system also needs to stop the messages from being directed to 1269 relays that are not supposed to see them. To keep the relays from 1270 being used in Denial of Service (DoS) attacks, the relays never 1271 forward messages unless they have a trust relationship with either 1272 the client sending or the client receiving the message; further, they 1273 only forward that message if it is coming from or going to the client 1274 with which they have the trust relationship. If a relay has a trust 1275 relationship with the client that is the destination of the message, 1276 it should not send the message anywhere except to the client that is 1277 the destination. 1279 Some terminology used in this discussion: SClient is the client 1280 sending a message and RClient is the client receiving a message. 1281 SRelay is a relay the sender trusts and RRelay is a relay the 1282 receiver trusts. The message will go from SClient to SRelay1 to 1283 SRelay2 to RRelay2 to RRelay1 to RClient. 1285 9.4. Security Mechanism 1287 Confidentiality and Privacy from elements not in the route set is 1288 provided by using TLS on all the transports. Relays always use TLS. 1289 A client can use unprotected TCP for peer-to-peer MSRP, but any time 1290 a client communicates with a relay, it MUST use TLS. 1292 The relays authenticate to the clients using TLS (but don't have to 1293 do mutual TLS). Further, the use of the rspauth parameter in the 1294 Authentication-Info header provides limited authentication of relays 1295 to which the client is not directly connected. The clients 1296 authenticate to the relays using HTTP Digest authentication. Relays 1297 authenticate to each other using TLS mutual authentication. 1299 By using S/MIME[3] encryption, the clients can protect their actual 1300 message contents so that the relays cannot see the contents. End to 1301 end signing is also possible with S/MIME. 1303 The complex part is making sure that relays cannot successfully be 1304 instructed to send messages to a place where they should not. This 1305 is done by having the client authenticate to the relay and having the 1306 relay return a token. Messages that contain this token can be 1307 relayed if they come from the client that got the token or if they 1308 are being forwarded towards the client that got the token. The 1309 tokens are the URLs that the relay places in the Use-Path header. 1310 The tokens contain random material (defined in Section 6.3) so that 1311 they are not guessable by attackers. The tokens need to be protected 1312 so they are only ever seen by elements in the route set or other 1313 elements that at least one of the parties trusts. If some 3rd party 1314 discovers the token that RRelay2 uses to forward messages to RClient, 1315 then that 3rd party can send as many messages as they want to RRelay2 1316 and it will forward them to RClient. The 3rd party cannot cause them 1317 to be forwarded anywhere except to RClient, eliminating the open 1318 relay problems. SRelay1 will not forward the message unless it 1319 contains a valid token. 1321 When SClient goes to get a token from SRelay2, this request is 1322 relayed through SRelay1. SRelay2 authenticates that it really is 1323 SClient requesting the token, but it generates a token that is only 1324 valid for forwarding messages to or from SRelay1. SRelay2 knows it 1325 is connected to SRelay1 because of the mutual TLS. 1327 The tokens are carried in the resource portion of the MSRP URLs. The 1328 length of time the tokens are valid for is negotiated using the 1329 Expire header in the AUTH request. Clients need to re-negotiate the 1330 tokens using a new offer/answer[15] exchange (e.g. a SIP re-invite) 1331 before the tokens expire. 1333 Note that this scheme relies on relays as trusted nodes, acting on 1334 behalf of the users authenticated to them. There is no security 1335 mechanism to prevent relays on the path from inserting forged 1336 messages, manipulating the contents of messages, sending messages in 1337 a session to a party other than that specified by the sender, or from 1338 copying them to a third party. However, the one-to-one binding 1339 between session identifiers and sessions helps mitigate any damage 1340 that can be caused by rogue relays by limiting the destinations to 1341 which forged or modified messages can be sent to the two parties 1342 involved in the session, and only for the duration of the session. 1343 Additionally, the use of S/MIME encryption can be employed to limit 1344 the utility of redirecting messages. Finally, clients can employ 1345 S/MIME signatures to guarantee the authenticity of messages they 1346 send, making it possible under some circumstances to detect relay 1347 manipulation or the forging of messages. 1349 Clients are not the only actors in the network who need to trust 1350 relays to act in non-malicious ways. If a relay does not have a 1351 direct TLS connection with the client on whose behalf it is acting 1352 (i.e. There are one or more intervening relays), it is at the mercy 1353 of any such intervening relays to accurately transmit the messages 1354 sent to and from the client. If a stronger guarantee of the 1355 authentic origin of a message is necessary (e.g. The relay is 1356 performing logging of messages as part of a legal requirement), then 1357 users of that relay can be instructed by their administrators to use 1358 detached S/MIME signatures on all messages sent by their client. The 1359 relay can enforce such a policy by returning a 415 response to any 1360 SEND requests using a top-level MIME type other than "multipart/ 1361 signed." Such relays may choose to make policy decisions (such as 1362 terminating sessions and/or suspending user authorization) if such 1363 signatures fail to match the contents of the message. 1365 10. IANA Considerations 1367 10.1. New MSRP Method 1369 This specification defines a new MSRP method, to be added to the 1370 Methods sub-registry under the MSRP Parameters registry: AUTH. See 1371 Section 5.1 for details on the AUTH method. 1373 10.2. New MSRP Headers 1375 This specification defines several new MSRP header fields, to be 1376 added to the header-field sub-registry under the MSRP Parameters 1377 registry: 1379 o Expires 1380 o Min-Expires 1381 o Max-Expires 1382 o Use-Path 1383 o WWW-Authenticate 1384 o Authorization 1385 o Authentication-Info 1387 10.3. New MSRP Response Codes 1389 This specification defines two new MSRP status codes, to be added to 1390 the status-code sub-registry under the MSRP Parameters registry: 1392 The 401 response indicates that an AUTH request contained no 1393 credentials, an expired nonce value, or invalid credentials. The 1394 response includes a "WWW-Authenticate" header containing a challenge 1395 (among other fields); see Section 9.1 for further details. The 1396 default response phrase for this response is "Unauthorized". 1398 The 403 response indicates that an AUTH request contained credentials 1399 sufficient to authenticate a user, but that the authenticated user is 1400 not authorized to use the relay. 1402 11. Example SDP with multiple hops 1404 The following section shows an example SDP that could occur in a SIP 1405 message to set up an MSRP session between Alice and Bob where Bob 1406 uses a relay. Alice makes an offer with a path to Alice. 1407 c=IN IP4 a.example.com 1408 m=message 1234 TCP/MSRP * 1409 a=accept-types: message/cpim text/plain text/html 1410 a=path:msrp://a.example.com:1234/agic456;tcp 1412 In this offer Alice wishes to receive MSRP messages at a.example.com. 1413 She wants to use TCP as the transport for the MSRP session. She can 1414 accept message/cpim, text/plain and text/html message bodies in SEND 1415 requests. She does not need a relay to setup the MSRP session. 1417 To this offer, Bob's answer could look like: 1418 c=IN IP4 bob.example.com 1419 m=message 1234 TCP/TLS/MSRP * 1420 a=accept-types: message/cpim text/plain 1421 a=path:msrps://relay.example.com:9000/hjdhfha;tcp \ 1422 msrps://bob.example.com:1234/fuige;tcp 1424 Here Bob wishes to receive the MSRP messages at bob.example.com. He 1425 can accept only message/cpim and text/plain message bodies in SEND 1426 requests and has rejected the text/html content offered by Alice. He 1427 wishes to use a relay called relay.example.com for the MSRP session. 1429 12. Acknowledgments 1431 Many thanks to Avshalom Houri, Hisham Khartabil, Robert Sparks, 1432 Miguel Garcia, Hans Persson, and Orit Levin, who provided detailed 1433 proof reading and helpful text. Thanks to the following members of 1434 the SIMPLE WG for spirited discussions on session mode: Chris 1435 Boulton, Ben Campbell, Juhee Garg, Paul Kyzivat, Allison Mankin, Aki 1436 Niemi, Pekka Pessi, Jon Peterson, Brian Rosen, Jonathan Rosenberg, 1437 and Dean Willis. 1439 13. References 1441 13.1. Normative References 1443 [1] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1444 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 1445 Basic and Digest Access Authentication", RFC 2617, June 1999. 1447 [2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and 1448 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 1449 January 1999. 1451 [3] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 1452 (S/MIME) Version 3.1 Message Specification", RFC 3851, 1453 July 2004. 1455 [4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1456 specifying the location of services (DNS SRV)", RFC 2782, 1457 February 2000. 1459 [5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1460 T. Wright, "Transport Layer Security (TLS) Extensions", 1461 RFC 3546, June 2003. 1463 [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1464 Transport Layer Security (TLS)", RFC 3268, June 2002. 1466 [7] Handley, M. and V. Jacobson, "SDP: Session Description 1467 Protocol", RFC 2327, April 1998. 1469 [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1470 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1471 Session Initiation Protocol", RFC 3261, June 2002. 1473 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1474 Levels", BCP 14, RFC 2119, March 1997. 1476 [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1477 Specifications: ABNF", RFC 2234, November 1997. 1479 [11] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The 1480 Message Session Relay Protocol", 1481 draft-ietf-simple-message-sessions-14 (work in progress), 1482 February 2006. 1484 [12] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1485 Public Key Infrastructure Certificate and Certificate 1486 Revocation List (CRL) Profile", RFC 3280, April 2002. 1488 13.2. Informative References 1490 [13] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1491 Extensions (MIME) Part One: Format of Internet Message Bodies", 1492 RFC 2045, November 1996. 1494 [14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1495 Extensions (MIME) Part Two: Media Types", RFC 2046, 1496 November 1996. 1498 [15] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1499 Session Description Protocol (SDP)", RFC 3264, June 2002. 1501 Appendix A. Implementation Considerations 1503 This text is not necessary in order to implement MSRP in an 1504 interoperable way, but is still useful as an implementation 1505 discussion for the community. It is purely an implementation detail. 1507 Note: The idea has been proposed of having a relay return a base URL 1508 that the client can use to construct more URLs but this allows 3rd 1509 parties that have had a session with the client to know URLs that the 1510 relay will use for forwarding after the session with the 3rd party 1511 has ended. Effectively this reveals the secret URLs to 3rd parties 1512 which compromises the security of the solution so this approach is 1513 not used. 1515 An alternative to this approach causes the relays to return a URL 1516 which is divided into an index portion and a secret portion. The 1517 client can encrypt its identifier and its own opaque data with the 1518 secret portion, and concatenate this with the index portion to create 1519 a plurality of valid URLs. When the relay receives one of these 1520 URLs, it could use the index to lookup the appropriate secret, 1521 decrypt the client portion and verify that it contains the client 1522 identifier. The relay can then forward the request. The client does 1523 not need to send an AUTH request for each URL it uses. This is an 1524 implementation detail which is out of scope of this document. 1526 It is possible to implement forwarding requirements in a farm without 1527 the relay saving any state. One possible implementation that a relay 1528 might use is described in the rest of this section. When a relay 1529 starts up it could pick a cryptographically random 128 bit password 1530 (K) and 128 bit initialization vector (IV). If the relay was 1531 actually a farm of servers with the same DNS name, all the machines 1532 in the farm would need to share the same K. When an AUTH request was 1533 received the relay forms a string that contains: the expiry time of 1534 the URL, an indication if the previous hop was mutual TLS 1535 authenticated or not and if it was, the name of the previous hop, if 1536 it was not, the identifier for the connection which received the AUTH 1537 request. This string would be padded by appending a byte with the 1538 value 0x80 then adding zero or more bytes with the value of 0x00 1539 until the string length is a multiple of 16 bytes long. A new random 1540 IV vector would be selected (it needs to change because it forms the 1541 salt) and the padded string would be encrypted using AES-CBC with a 1542 key of K. The IV and encrypted data and an SPI (security parameter 1543 index) that changes each time K changes would be base 64 encoded and 1544 form the resource portion of the request URL. The SPI allows the key 1545 to be changed and for the system to know which K should be used. 1546 Later when the relay receives this URL, it could decrypt it and check 1547 that the current time was before the expiry time and check that the 1548 messages was coming from or going to the connection or location 1549 specified in the URL. Integrity protection is not required because 1550 it is extremely unlikely that random data that was decrypted would 1551 result in a valid location that was the same as the messages was 1552 routing to or from. When implementing something like this, 1553 implementers should be careful not to use a scheme like EBE that 1554 would allows portions of encrypted tokens to be cut and pasted into 1555 other URLs. 1557 Authors' Addresses 1559 Cullen Jennings 1560 Cisco Systems, Inc. 1561 170 West Tasman Dr. 1562 MS: SJC-21/2 1563 San Jose, CA 95134 1564 USA 1566 Phone: +1 408 421-9990 1567 Email: fluffy@cisco.com 1569 Rohan Mahy 1570 Plantronics 1572 Email: rohan@ekabal.com 1574 Adam Roach 1575 Estacado Systems 1576 17210 Campbell Rd. 1577 Suite 250 1578 Dallas, TX 75252 1579 US 1581 Phone: sip:adam@estacado.net 1582 Email: adam@estacado.net 1584 Intellectual Property Statement 1586 The IETF takes no position regarding the validity or scope of any 1587 Intellectual Property Rights or other rights that might be claimed to 1588 pertain to the implementation or use of the technology described in 1589 this document or the extent to which any license under such rights 1590 might or might not be available; nor does it represent that it has 1591 made any independent effort to identify any such rights. Information 1592 on the procedures with respect to rights in RFC documents can be 1593 found in BCP 78 and BCP 79. 1595 Copies of IPR disclosures made to the IETF Secretariat and any 1596 assurances of licenses to be made available, or the result of an 1597 attempt made to obtain a general license or permission for the use of 1598 such proprietary rights by implementers or users of this 1599 specification can be obtained from the IETF on-line IPR repository at 1600 http://www.ietf.org/ipr. 1602 The IETF invites any interested party to bring to its attention any 1603 copyrights, patents or patent applications, or other proprietary 1604 rights that may cover technology that may be required to implement 1605 this standard. Please address the information to the IETF at 1606 ietf-ipr@ietf.org. 1608 Disclaimer of Validity 1610 This document and the information contained herein are provided on an 1611 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1612 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1613 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1614 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1615 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1616 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1618 Copyright Statement 1620 Copyright (C) The Internet Society (2006). This document is subject 1621 to the rights, licenses and restrictions contained in BCP 78, and 1622 except as set forth therein, the authors retain all their rights. 1624 Acknowledgment 1626 Funding for the RFC Editor function is currently provided by the 1627 Internet Society.