idnits 2.17.1 draft-ietf-simple-message-sessions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 342: '... MUST have the value of "message". T...' RFC 2119 keyword, line 344: '...rt of this value MUST be "msrp". For M...' RFC 2119 keyword, line 345: '...rt of this field MUST take the value "...' RFC 2119 keyword, line 346: '...ocols, the field value MUST be defined...' RFC 2119 keyword, line 347: '...protocol binding. The format list MUST...' (174 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 177 has weird spacing: '...nt over relia...' == Line 563 has weird spacing: '...] query strin...' == Line 774 has weird spacing: '...line is copie...' == Line 1241 has weird spacing: '...ined by perfo...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1. Construct a session MSRP URL . This URL MUST be resolvable to the offerer. The URL SHOULD be temporary, SHOULD be hard to guess, and MUST not duplicate the URL of any other session currently hosted by the offerer. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1. Construct a new session URL . This MUST be a MSRP URL, MUST resolve to the answerer, and MUST not be the same as the session URL in the offer. The URL SHOULD be temporary, SHOULD be hard to guess, and MUST not duplicate URLs currently identifying any active sessions hosted by the answerer. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 2. If the client is authorized, construct a session MSRP URL. The URL MUST resolve to the relay. It SHOULD be temporary, and hard to guess. It MUST not duplicate URL used in any active sessions hosted by the relay. If the relay wishes the visiting endpoint to connect over a point other than the MSRP relay well-know port, it MUST explicitly add the port number to visitor URL. -- 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 (May 22, 2003) is 7638 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 1984, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 2009, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (ref. '1') (Obsoleted by RFC 4566) ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '3') ** Obsolete normative reference: RFC 2396 (ref. '4') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3369 (ref. '7') (Obsoleted by RFC 3852) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '8') -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '10') (Obsoleted by RFC 3550) == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-framework-02 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-3pcc-03 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-transfer-01 == Outdated reference: A later version (-04) exists of draft-ietf-impp-im-03 == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-05 -- Obsolete informational reference (is this intentional?): RFC 2617 (ref. '18') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 9 errors (**), 0 flaws (~~), 17 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group B. Campbell 3 Internet-Draft J. Rosenberg 4 Expires: November 20, 2003 R. Sparks 5 dynamicsoft 6 P. Kyzivat 7 Cisco Systems 8 May 22, 2003 10 Instant Message Sessions in SIMPLE 11 draft-ietf-simple-message-sessions-00 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 20, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 The SIP MESSAGE method is used to send instant messages, where each 42 message is independent of any other message. This is often called 43 pager-mode messaging, due to the fact that this model is similar to 44 that of most two-way pager devices. Another model is called 45 session-mode. In session-mode, the instant messages are part of a 46 media session that provides ordering, a security context, and other 47 functions. This media session is established using a SIP INVITE, just 48 as an audio or video session would be established. 50 This document describes the Message Session Relay Protocol (MSRP), a 51 mechanism for transmitting session-mode messages with minimalist 52 relay support. Additionally, this document describes using the SDP 53 offer/answer model to initiate such sessions. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Motivation for Session-mode Messaging . . . . . . . . . . 4 59 3. Scope of this Document . . . . . . . . . . . . . . . . . . 5 60 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 61 5. SDP Offer-Answer Exchanges for MSRP Sessions. . . . . . . 8 62 5.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 8 63 5.2 The Direction Attribute . . . . . . . . . . . . . . . . . 9 64 5.3 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 10 65 5.4 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 11 66 6. The Message Session Relay Protocol . . . . . . . . . . . . 11 67 6.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6.2 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 12 69 6.3 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 13 70 6.3.1 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . 14 71 6.4 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 14 72 6.5 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 15 73 6.6 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 16 74 6.6.1 Initiating an MSRP session . . . . . . . . . . . . . . . . 16 75 6.6.2 Handling VISIT requests . . . . . . . . . . . . . . . . . 19 76 6.6.3 Sending Instant Messages on a Session . . . . . . . . . . 20 77 6.6.4 Managing Session State and Connections . . . . . . . . . . 21 78 6.7 MSRP Relays . . . . . . . . . . . . . . . . . . . . . . . 22 79 6.7.1 Establishing Session State at a Relay . . . . . . . . . . 22 80 6.7.2 Removing Session State from a relay . . . . . . . . . . . 24 81 6.7.3 Sending IMs across an MSRP relay . . . . . . . . . . . . . 24 82 6.7.4 Relay Pairs . . . . . . . . . . . . . . . . . . . . . . . 24 83 6.8 Session State Expiration . . . . . . . . . . . . . . . . . 26 84 6.9 Digest Authentication . . . . . . . . . . . . . . . . . . 26 85 6.9.1 The MD5 Algorithm . . . . . . . . . . . . . . . . . . . . 27 86 6.10 Method Descriptions . . . . . . . . . . . . . . . . . . . 28 87 6.10.1 BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 88 6.10.2 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 89 6.10.3 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 29 90 6.11 Response Code Descriptions . . . . . . . . . . . . . . . . 29 91 6.11.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 92 6.11.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 93 6.11.3 401 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 94 6.11.4 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 95 6.11.5 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 96 6.11.6 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 97 6.11.7 500 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 98 6.11.8 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 99 6.12 Header Field Descriptions . . . . . . . . . . . . . . . . 30 100 6.12.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 30 101 6.12.2 Exp . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 6.12.3 CAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 31 103 6.12.4 SChal . . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 6.12.5 Content-Type . . . . . . . . . . . . . . . . . . . . . . . 32 105 6.12.6 S-URL . . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 7.1 No Relay . . . . . . . . . . . . . . . . . . . . . . . . . 33 108 7.2 Single Relay . . . . . . . . . . . . . . . . . . . . . . . 34 109 7.3 Two Relays . . . . . . . . . . . . . . . . . . . . . . . . 37 110 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 40 111 9. Security Considerations . . . . . . . . . . . . . . . . . 40 112 9.1 The MSRPS Scheme . . . . . . . . . . . . . . . . . . . . . 40 113 9.2 Sensitivity of the Session URL . . . . . . . . . . . . . . 41 114 9.3 End to End Protection of IMs . . . . . . . . . . . . . . . 41 115 9.4 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 42 116 10. Changes introduced in 117 draft-ietf-simple-message-sessions-00 . . . . . . . . . . 42 118 11. Changes introduced in 119 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 43 120 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 43 121 Normative References . . . . . . . . . . . . . . . . . . . 43 122 Informational References . . . . . . . . . . . . . . . . . 44 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 45 124 Intellectual Property and Copyright Statements . . . . . . 46 126 1. Introduction 128 The MESSAGE [9] extension to SIP [2] allows SIP to be used to 129 transmit instant messages. Instant messages sent using the MESSAGE 130 method are normally independent of each other. This approach is often 131 called pager-mode messaging, since it follows a model similar to that 132 used by many two-way pager devices. Pager-mode messaging makes sense 133 for instant message exchanges where a small number of messages occur. 135 There are also applications in which it is useful for instant 136 messages to be associated together in some way. For example, a user 137 may wish to join a text conference, participate in the conference for 138 some period of time, then leave the conference. This usage is 139 analogous to regular media sessions that are typically initiated, 140 managed, and terminated using SIP. We commonly refer to this model as 141 session-mode messaging. 143 One of the primary purposes of SIP and SDP (Section 5) is the 144 management of media sessions. Session-mode messaging can be thought 145 of as a media session like any other. This document describes the 146 motivations for session-mode messaging, the Message Session Relay 147 Protocol, and the use of the SDP offer/answer mechanism for managing 148 MSRP session. 150 2. Motivation for Session-mode Messaging 152 Message sessions offer several advantages over pager-mode messages. 153 For message exchanges that include more than a small number of 154 message transactions, message sessions offer a way to remove 155 messaging load from intervening SIP proxies. For example, a minimal 156 session setup and tear-down requires one INVITE/ACK transaction, and 157 one BYE transaction, for a total of 5 SIP messages. Normal SIP 158 request routing allows for all but the initial INVITE transaction to 159 bypass any intervening proxies that do not specifically request to be 160 in the path for future requests. Session-mode messages never cross 161 the SIP proxies themselves, unless proxies also act as message 162 relays. 164 Each pager mode message involves a complete SIP transaction, that is, 165 a request and a response. Any pager-mode message exchange that 166 involves more than 2 or 3 MESSAGE requests will generate more SIP 167 requests than a minimal session initiation sequence. Since MESSAGE is 168 normally used outside of a SIP dialog, these requests will typically 169 traverse the entire proxy network between the endpoints. 171 Due to network congestion concerns, the MESSAGE method has 172 significant limitations in message size, a prohibition against 173 overlapping requests, etc. Much of this has been required because of 174 perceived limitations in the congestion-avoidance features of SIP 175 itself. Work is in progress to mitigate these concerns. 177 However, session-mode messages are always sent over reliable, 178 congestion-safe transports. Therefore, there are no restrictions on 179 message sizes. There is no requirement to wait for acknowledgement, 180 so that message transactions can be overlapped. 182 Message sessions allow greater efficiency for secure message 183 exchanges. The SIP MESSAGE request inherits the S/MIME features of 184 SIP, allowing a message to be signed and/or encrypted. However, this 185 approach requires public key operations for each message. With 186 session-mode messaging, a session key can be established at the time 187 of session initiation. This key can be used to protect each message 188 that is part of the session. This requires only symmetric key 189 operations for each subsequent IM, and no additional certificate 190 exchanges are required after the initial exchange. The establishment 191 of the session key can be done using standard techniques that apply 192 to voice and video, in addition to instant messaging. 194 Finally, SIP devices can treat message sessions like any other media 195 sessions. Any SIP feature that can be applied to other sorts of media 196 sessions can equally apply to message sessions. For example, 197 conferencing [11], third party call control [12], call transfer [13], 198 QoS integration [14], and privacy [15] can all be applied to message 199 sessions. 201 Messaging sessions can also reduce the overhead in each individual 202 message. In pager-mode, each message needs to include all of the SIP 203 headers that are mandated by RFC 3261 [2]. However, many of these 204 headers are not needed once a context is established for exchanging 205 messages. As a result, messaging session mechanisms can be designed 206 with significantly less overhead. 208 3. Scope of this Document 210 This document describes the use of MSRP between endpoints, or via one 211 or two relays, where endpoints have advance knowledge of the relays. 212 It does not provide a mechanism for endpoints to determine whether a 213 relay is needed, or for endpoints to discover the presence of relays. 215 This document describes the use of MSRP over TCP. MSRP may be used 216 over other congestion-controlled protocols such as SCTP. However, the 217 specific bindings for other such protocols are outside the scope of 218 this document. 220 4. Protocol Overview 221 The Message Session Relay Protocol (MSRP) provides a mechanism for 222 transporting session-mode messages between endpoints. MSRP also 223 contains primitives to allow the use of one or two relay devices. 224 MSRP uses connection oriented, reliable network transport protocols 225 only. It is intrinsically NAT and firewall friendly, as it allows 226 participants to positively associate message sessions with specific 227 connections, and does not depend upon connection source address, 228 which may be obscured by NATs. 230 MSRP uses the following primitives: 232 SEND: Used to actually send message content from one endpoint to 233 another. 235 VISIT: Used by an endpoint to establish a session association to the 236 opposite endpoint, or to a relay that was selected by the opposite 237 endpoint. 239 BIND: Used by an endpoint to establish a session at a relay, and 240 allow the opposite endpoint to visit that relay. 242 The simplest use case for MSRP is a session that goes directly 243 between endpoints, with no intermediaries involved. Assume A is an 244 endpoint that wishes to establish a message session, and B is the 245 endpoint invited by A. A invites B to participate in a message 246 session by sending a URL that represents the session. This URL is 247 temporary, and must not duplicate the URL used for any other active 248 sessions. 250 B "visits" A by connecting to A and sending a VISIT request 251 containing the URL that A provided. This associates the connection 252 from B with the session. B then responds to the invitation, informing 253 A that B has accepted the session. A and B may now exchange messages 254 using SEND requests on the connection. 256 When either party wishes to end the session, it informs the peer 257 party with a SIP BYE request. A terminates the session by 258 invalidating associated state, and dropping the connection. 260 The end to end case looks something like the following. (Note that 261 the example shows a logical flow only; syntax will come later in this 262 document.) 264 A->B (SDP): offer (msrp://A/123) 266 B->A (MSRP): VISIT (msrp://A/123) 267 A->B (MSRP): 200 OK 269 B->A (SDP): answer(msrp://A/123) 271 A->B (MSRP): SEND 273 B->A (MSRP): 200 OK 275 B->A (MSRP): SEND 277 A->B (MSRP): 200 OK 279 The state associated with the session will expire over time, based on 280 an expiration time specified in the VISIT request. If the lifetime of 281 the session is to exceed that expiration time, the visitor must 282 update the expiration with a new VISIT request prior to expiration. 284 A slightly more complicated case involves a single relay, known about 285 in advance by one of the parties. The endpoint that has the 286 preexisting relationship with the relay uses the BIND method to 287 establish session state in the relay. The relay returns a temporary 288 URL, that identifies the session. For endpoints A and B, and relay R, 289 the flow would look like the following: 291 A->R: MSRP: BIND(msrp://r) 293 R->A: MSRP: 200 OK (msrp://r/4uye) 295 A->B (SDP): offer (msrp://r/4uye) 297 B->R (MSRP): VISIT (msrp://r/4uye) 299 R->B (MSRP): 200 OK 301 B->A (SDP): answer(msrp://r/4uye) 303 A->R (MSRP): SEND 305 R->B (MSRP): SEND 307 B->R (MSRP): 200 OK 309 R->A (MSRP): 200 OK 311 B->R (MSRP): SEND 312 R->A (MSRP): SEND 314 A->R (MSRP): 200 OK 316 R->B (MSRP): 200 OK 318 The BIND request contains an expiration time much the same as in 319 VISIT. If the life of a relay-hosted session is to exceed the 320 expiration value in the BIND request, the host endpoint will refresh 321 the expiration time with a new BIND request prior to expiration. 322 Additionally, when tearing down a session, the host endpoint 323 invalidates the session state by issuing a BIND request with an 324 expiration value of zero. 326 5. SDP Offer-Answer Exchanges for MSRP Sessions. 328 MSRP sessions will typically be initiated using the Session 329 Description Protocol (SDP) [1] offer-answer mechanism, carried in SIP 330 [2] or any other protocol supporting it. MSRP borrows the idea of the 331 direction attributes from COMEDIA [17], but does not depend on that 332 specification. 334 5.1 Use of the SDP M-line 336 The SDP m-line takes the following form: 338 m= 340 For non-RTP media sessions, The media field specifies the top level 341 MIME media type for the session. For MSRP sessions, the media field 342 MUST have the value of "message". The proto field MUST designate the 343 message session mechanism and transport protocol, separated by a "/" 344 character. For MSRP, left part of this value MUST be "msrp". For MSRP 345 over TCP, the right part of this field MUST take the value "tcp". For 346 MSRP over other transport protocols, the field value MUST be defined 347 by the specification for that protocol binding. The format list MUST 348 indicate the MIME content-types that the endpoint is willing to 349 accept in the payload of SEND requests. If any of the allowed types 350 are compound in nature, that is, they allow one or more arbitrary 351 MIME body parts to be embedded within them, then the format list MUST 352 include the content-types allowed for the embedded parts. If the 353 final entry in the format list is a "*", this indicates that the 354 endpoint is may be willing to receive other types as well, but the 355 types listed explicitly are preferred. The format list in the SDP 356 answer MUST be the same as, or a subset of, the list provided in the 357 offer. 359 A "*" in the format list indicates that the sender may attempt to 360 send messages with other media types that have not been explicitly 361 listed. If the receiver is able to process the media type, it does 362 so. If not, it will respond with a 415. Note that all explicit 363 entries in the format list should be considered preferred over any 364 non-listed types. This feature is needed as, otherwise, the format 365 list for IM devices may be prohibitively large. 367 The port field in the M-line is not used to determine the port to 368 which to connect. Rather, the actual port is determined by the 369 contents of the session URL. (Section 6.1). 371 The following example illustrates an m-line for a CPIM message 372 session, where the endpoint is willing to accept payloads of plain 373 text or HTML, which may appear at the top level of the payload, or 374 may be embedded inside a message/cpim body part. 376 m=message 49232 msrp/tcp message/cpim text/plain text/html 378 5.2 The Direction Attribute 380 Since MSRP uses connection oriented transport protocols, one goal of 381 the SDP negotiation is to determine which participant initiates the 382 transport connection. The direction attribute advertises whether the 383 offerer or answerer wishes to initiate the connection, wishes the 384 peer endpoint to initiate the connection, or doesn't care. 386 The endpoint that accepts the connection, or has a relay accept the 387 connection on its behalf, is said to "host" the session, and is known 388 as the hosting endpoint. The endpoint that initiates the connection 389 is said to "visit" the session, and is known as the visiting 390 endpoint. 392 The direction attribute is included in an SDP a-line, with a value 393 taking the following syntax: 395 direction = direction-label ":" role 396 direction-label = "direction" 397 role = active / passive / both 398 active = "active" 399 passive = "passive" 400 both = "both" 402 The values for the role field are as follows: 404 passive The endpoint wishes to host the session 406 active The endpoint wishes the peer to host the session. 408 both The endpoint is willing to act as either host or visitor. 410 The SDP offer for an MSRP session MUST contain a direction attribute, 411 which MAY take any of the defined values. If the offerer is capable 412 of hosting the session, or can arrange for a relay to host the 413 session on its behalf, then it SHOULD select "both". The endpoint 414 SHOULD NOT select "active" unless it cannot host the session under 415 any circumstances. The endpoint SHOULD NOT select "passive" unless it 416 has no option but to host the session. 418 The SDP answer also MUST contain a direction attribute, but its value 419 choices are limited based on the value in the offer. If the offer 420 contained "active", then the answerer MUST either select "passive" or 421 reject the offer. Likewise, if the offer contained "passive", then 422 the answerer MUST select"active" or reject the offer. If the offer 423 contained "both", the answerer SHOULD select "active", but MAY select 424 "passive" if local policy requires it to act as host. 426 5.3 URL Negotiations 428 An MSRP session is identified by an MSRP URL, which is determined by 429 the hosting endpoint, and negotiated in the SDP exchange. Any SDP 430 offer or answer that creates a possibility that the sender will host 431 the session, that is, contains a direction value of "passive" or 432 "both", MUST contain an MSRP URL in a session attribute. This 433 attribute has the following syntax: 435 a=session: 437 where is an MSRP or MSRPS URL as defined in Section 6.1. 439 The visitor will use the session URL established by the host both to 440 resolve the host address and port, and to identify the session when 441 connecting. For MSRP sessions, the address field in the C-line and 442 the port field in the M-line are not relevant, and MUST be ignored. 444 The following example shows an SDP offer with a session URL of 445 "msrp://example.com:7394/2s93i" 447 c=IN IP4 useless.host.name 448 m=message 7394 msrp/tcp text/plain 449 a=direction:both 450 a=session:msrp://example.com:7394/2s93i 452 The session URL MUST be a temporary URL assigned just for this 453 particular session. It MUST NOT duplicate any URL in use for any 454 other session hosted by the endpoint or relay. Further, since the 455 peer endpoint will use the session URL to identify itself when 456 connecting, it SHOULD be hard to guess, and protected from 457 eavesdroppers. This will be discussed in more detail in the Security 458 Considerations section. 460 5.4 Example SDP Exchange 462 Endpoint A wishes to invite Endpoint B to a MSRP session. A offers 463 the following session description containing the following lines: 465 c=IN IP4 alice.example.com 466 m=message 7394 msrp/tcp message/cpim text/plain text/html 467 a=direction:both 468 a=session:msrp://alice.example.com:7394/2s93i9 470 Endpoint B chooses to participate in the role of visitor, opens a TCP 471 connection to alice.example.com:7394, and successfully performs a 472 VISIT transaction passing the URL of msrp://alice.example.com:7394/ 473 2s93i9;. B indicates that it has accomplished this by answering with: 475 c=IN IP4 dontlookhere 476 m=message 7394 msrp/tcp message/cpim text/plain 477 a=direction:active 479 A may now send IMs to B by executing SEND transactions on the same 480 connection on which B sent the VISIT request. 482 6. The Message Session Relay Protocol 484 The Message Session Relay Protocol (MSRP) is a text based, message 485 oriented protocol for the transfer of instant messages in the context 486 of a session. MSRP uses the UTF8 character set. 488 MSRP messages MUST be sent over reliable, congestion-controlled, 489 connection-oriented transport protocols, such as TCP. 491 6.1 MSRP URLs 493 MSRP sessions are identified by MSRP URLs. An MSRP URL follows a 494 subset of the URL syntax in Appendix A of RFC2396 [4], with a scheme 495 of "msrp": 497 msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource] 499 resource = 1*unreserved 501 The constructions for "userinfo", "hostport", and "unreserved" are 502 detailed in RFC2396 [4]. 504 An MSRP URL server part identifies the hosting device of an MSRP 505 session. There is no default port for MSRP URLs. If the server part 506 contains a numeric IP address, it MUST also contain a port. The 507 resource part identifies a particular session at that host device. 508 The absence of the resource part indicates a reference to an MSRP 509 host device, but does not specifically refer to a particular session 510 resource. 512 Open Issue: Do we need a default port? Cullen points out it would 513 at least be useful for firewall configuration. 515 The server part will typically not contain a userinfo component, but 516 MAY do so to indicate a user account for which the session is valid. 517 Note that this is not the same thing as identifying the session 518 itself. If a userinfo component exists, MUST be constructed only from 519 "unreserved" characters, to avoid a need for escape processing. 520 Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo 521 part MUST NOT contain password information. 523 The following is an example of a typical MSRP URL: 525 msrp://host.example.com:8493/asfd34 527 6.2 MSRP URL Comparison 529 MSRP URL comparisons MUST be performed according to the following 530 rules: 532 The host part is compared as case insensitive. 534 If the port exists explicitly in either URL, then it must match 535 exactly. Since there is no default port for MSRP, a URL with an 536 explicit port is never equivalent to another with no port 537 specified. 539 The resource part is compared as case insensitive. A URL without a 540 resource part is never equivalent to one that includes a resource 541 part. 543 Userinfo parts are not considered for URL comparison. 545 Path normalization is not relevant for MSRP URLs. Escape 546 normalization is not required, since the relevant parts are limited 547 to unreserved characters. 549 6.3 Resolving MSRP Host Device 551 An MSRP host device is identified by the server part of an MSRP URL. 553 If the server part contains a numeric IP address and port, they MUST 554 be used as listed.. 556 If the server part contains a host name and a port, the connecting 557 device MUST determine a host address by doing an A or AAAA DNS query, 558 and use the port as listed. 560 If the server part contains a host name but no port, the connecting 561 device MUST perform the following steps: 563 1. Construct an SRV [6] query string by prefixing the host name 564 with the service field "_msrp" and the protocol field ("_tcp" for 565 TCP). For example, "_msrp._tcp.host.example.com". 567 2. Perform a DNS SRV query using this query string. 569 3. Select a resulting record according to the rules in RFC2782 [6]. 570 Determine the port from the chosen record. 572 4. If necessary, determine a host device address by performing an A 573 or AAAA query on the host name field in the selected SRV result 574 record. If multiple A or AAAA records are returned, the first 575 entry SHOULD be chosen for the initial connection attempt. This 576 allows any ordering created in the DNS to be preserved. 578 5. If the connection attempt fails, the device SHOULD attempt to 579 connect to the addresses returned in any additional A or AAAA 580 records, in the order the records were presented. If all of these 581 fail, the device SHOULD attempt to use any additional SRV records 582 that may have been returned, following the normal rules for SRV 583 record selection. 585 Open Issue: We need to carefully consider the rules about A RR 586 selection. I am sure there are others who understand this much 587 better than I do. Ted pointed us to RFC1794, which if I understand 588 correctly indicates that some systems may attempt to load balance 589 by controlling the order in which A RRs are presented. Attempts to 590 randomize selection by the client could distort any such control. 592 Note that in most cases, the transport protocol will be determined 593 separately from the resolution process. For example, if the MSRP URL 594 was communicated in an SDP offer or answer, the SDP M-line will 595 contain the transport protocol. When an MSRP URL is communicated 596 outside of SDP, the protocol SHOULD also be communicated. For 597 example, a client may be configured to use a particular relay that is 598 referenced with an MSRP URL. The client MUST also be told what 599 protocol to use. If a device needs to resolve an MSRP URL and does 600 not know the protocol, it SHOULD assume TCP. 602 Open Issue: Do we need to do an NAPTR query to determine the 603 protocol? 605 6.3.1 The msrps URL Scheme 607 The "msrps" URL Scheme indicates that each hop MUST be secured with 608 TLS. Otherwise, it is used identically as an MSRP URL, except that a 609 MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS 610 scheme is further discussed in the Security Considerations section. 612 6.4 MSRP messages 614 MSRP messages are either requests or responses. Requests and 615 responses are distinguished from one another by the first line. The 616 first line of a Request takes the form of the request-start entry 617 below. Likewise, the first line of a response takes the form of 618 response-start. The syntax for an MSRP message is as follows: 620 msrp-message = request-start/response-start *(header CRLF) 621 [CRLF body] 622 request-start = "MSRP" SP length SP Method CRLF 623 response-start= "MSRP" SP length SP Status-Code SP 624 Reason CRLF 625 length = 1*DIGIT ; the length of the message, exclusive of the start line. 626 Method = SEND / BIND / VISIT 627 header = Client-Authenticate / Server-Challenge / 628 Transaction-ID / Session-URL/ Content-Type / Expires 629 Status-Code = 200 ;Success 630 / 400 ;Bad Request 631 / 401 ;Authentication Required 632 / 403 ;Forbidden 633 / 415 ;Unsupported Content Type 634 / 481 ;No session 635 / 500 ;Cannot Deliver 636 / 506 ;duplicate session 637 Reason = token ; Human readable text describing status 638 Client-Authenticate = "CAuth" credentials 639 Server-Challenge = "SChal" ":" challenge 640 Transaction-ID = "Tr-ID" ":" token 641 Content-Type = "Content-Type" ":" quoted-string 642 Session-URL = "S-URL" ":" msrp_url 643 Expires = "Exp"":" delta-seconds 644 delta-seconds= 1*DIGIT ; Integer number of seconds 646 All requests and responses MUST contain at least a TR-ID header 647 field. Messages MAY contain other fields, depending on the method or 648 response code. 650 6.5 MSRP Transactions 652 An MSRP transaction consists of exactly one request and one response. 653 A response matches a transaction if it share the same TR-ID value, 654 and arrives on the same connection on which the transaction was sent. 656 BIND is always hop by hop. VISIT transactions are usually hop-by-hop, 657 but may be relayed in situations where the visiting endpoint uses a 658 relay. However, SEND transactions are end to end, meaning that under 659 normal circumstances the response is sent by the peer endpoint, even 660 if there are intervening relays. 662 Endpoints MUST select TR-ID header field values in requests so that 663 they are not repeated by the same endpoint in scope of the given 664 session. TR-ID values SHOULD be globally unique. The TR-ID space of 665 each endpoint is independent of that of its peer. Endpoints MUST NOT 666 infer any semantics from the TR-ID header field beyond what is stated 667 above. In particular, TR-ID values are not required to follow any 668 sequence. 670 MSRP Transactions complete when a response is received, or after a 671 timeout interval expires with no response. Endpoints MUST treat such 672 timeouts in exactly the same way they would treat a 500 response. The 673 size of the timeout interval is a matter of local policy. 675 6.6 MSRP Sessions 677 AN MSRP session is a context in which a series of instant messages 678 are exchanged, using SEND requests. A session has two endpoints (a 679 host and a visitor) and may have one or two relays. A session is 680 identified by an MSRP URL. 682 6.6.1 Initiating an MSRP session 684 When an endpoint wishes to engage a peer endpoint in a message 685 session, it invites the peer to communicate using an SDP offer, 686 carried over SIP or some other protocol supporting the SDP offer/ 687 answer model. For the purpose of this document, we will refer to the 688 endpoint choosing to initiate communication as the offerer, and the 689 peer being invited as the answerer. 691 The offerer SHOULD volunteer to act as the hosting endpoint if 692 allowed by policy and network topology. An endpoint is said to host a 693 session if one of two conditions are true. The host either directly 694 listens for a connection from the peer endpoint, and maintains 695 session state itself, or it uses a BIND request to initialize session 696 state at a relay that will listen for a connection from the peer. The 697 peer that is not the host is designated as the visitor. The offerer 698 MAY request the answerer to act as host if it is prevented from 699 accepting connections by network topology or policy, and is not able 700 to bind to a relay to act on its behalf. 702 If the offerer wishes to host the session directly, that is without 703 using a relay, it MUST perform the following steps: 705 1. Construct a session MSRP URL . This URL MUST be resolvable to the 706 offerer. The URL SHOULD be temporary, SHOULD be hard to guess, 707 and MUST not duplicate the URL of any other session currently 708 hosted by the offerer. 710 2. Listen for a connection from the peer. 712 3. Construct an SDP offer as described in Section 5, including the 713 list of allowed IM payload formats in the format list. The 714 offerer maps the session URL to the session attribute, as 715 described in Section 5.3. 717 4. Insert a direction attribute. This value SHOULD be "both", 718 indicating that the offerer will allow the answerer to override 719 the offerer's decision to host. The value MAY be "passive" if the 720 offerer is prevented from allowing the answerer override this 721 choice. 723 5. Send the SDP offer using the normal processing for the signaling 724 protocol. 726 If the offerer chooses to force the answerer to host the session, it 727 MUST perform the following steps instead: 729 1. Construct an SDP offer as described above, but with no session 730 attribute. 732 2. Insert a direction attribute with a value of "active". 734 3. Send the offer using normal processing for the signaling 735 protocol. 737 When the answerer receives the SDP offer and chooses to participate 738 in the session, it must choose whether of act as the host or the 739 visitor. A direction attribute value of "both" in the offer indicates 740 that the offerer wishes to host, but will allow the answerer to host, 741 in which case the answerer SHOULD act as the visitor, but MAY choose 742 to host. A value of "passive" means the offerer insists upon hosting, 743 in which case the answerer MUST act as visitor or decline the offer. 745 If the answerer chooses to participate as a visitor, it MUST perform 746 the following steps: 748 1. Determine the host address and port from the session URL, 749 following the procedures in section Section 6.1 751 2. Connect to the host address and port, using the transport 752 protocol from the M-line. 754 3. Construct a VISIT request, which MUST contain the following 755 information: 757 1. An S-URL header field containing the session URL. 759 2. A TR-ID header field containing a unique transaction ID. 761 3. An Exp header field containing the expiration time for the 762 VISIT request. 764 4. A size field containing size of the message subsequent to the 765 start-line. 767 4. Send the request and wait for a response 769 5. If the transaction succeeds, set the actual expiration time to 770 the value in the Exp header field in the response, and send a SDP 771 answer via the signaling protocol, according to the following 772 rules: 774 1. The C-line is copied unmodified from the offer. 776 2. The M-Line contains a dummy port value, the protocol field 777 from the original offer, and a format list describing the 778 SEND payload media types that the answerer is willing to 779 accept. The format list in the answer MUST be either the same 780 as the format list in the offer, or a subset. 782 3. A direction attribute containing the value "active". 784 6. If the transaction fails, the answerer MAY choose to act as host, 785 if allowed by the direction attribute of the answer. If the 786 answerer is unable or unwilling to host, then it should return an 787 error response as appropriate for the signaling protocol. 789 If the answerer chooses to host the session, it MUST perform the 790 following steps: 792 1. Construct a new session URL . This MUST be a MSRP URL, MUST 793 resolve to the answerer, and MUST not be the same as the session 794 URL in the offer. The URL SHOULD be temporary, SHOULD be hard to 795 guess, and MUST not duplicate URLs currently identifying any 796 active sessions hosted by the answerer. 798 2. Listen for a connection from the peer. 800 3. Construct an SDP answer as described in Section 5, mapping the 801 new session URL to the session attribute, and inserting a 802 direction attribute with the value of "passive". 804 4. Send the SDP offer using the normal processing for the signaling 805 protocol. 807 When the offerer receives the SDP answer, it must determine who will 808 continue to host the session. If the answer contained a direction 809 attribute value of "active", the offerer MUST continue as host. If 810 the offer contained "active" or "both" and the answer contains 811 "passive", then the offerer MUST allow the answerer to host the 812 session. 814 If the offerer chooses not to continue as host, it MUST perform the 815 following steps: 817 1. Release resources it acquired in expectation of hosting the 818 session, if any. 820 2. Determine the host address and port from the session URL of the 821 answer, following the procedures in section Section 6.1 823 3. Connect to the host address and port, using the transport 824 protocol from the M-line. 826 4. Construct a VISIT request, which MUST contain the following 827 information: 829 1. A S-URL header field containing the session URL. 831 2. A TR-ID header field containing a unique transaction ID. 833 3. An Exp header field containing the expiration time for the 834 VISIT request. 836 4. A size field containing size of the message subsequent to the 837 start-line. 839 5. Send the request and wait for a response 841 6. If the transaction succeeds, set the actual expiration time to 842 the value in the Exp header field in the response, and 843 acknowledge the answer via the signaling protocol. If either the 844 connection attempt or the VISIT transaction fail, acknowledge the 845 answer, then initiate the tear-down of the session using the 846 signaling protocol. 848 6.6.2 Handling VISIT requests 850 An MSRP endpoint that is hosting a session will receive a VISIT 851 request from the visiting endpoint. When an endpoint receives a VISIT 852 request, it MUST perform the following procedures: 854 1. Check if state exists for a session with a URL that matches the 855 S-URL of the VISIT request. If so, and if no visitor connection 856 has been associated with the session, determine the expiration 857 time according to the procedures in Section 6.8, then return a 858 200 response, and save state designating the connection on which 859 the request was received as the visitor leg of the session. 861 2. If the session exists, and the visitor connection has already 862 been established, and the request arrived on the existing visitor 863 connection, treat the request as a refresh, as described in 864 Section 6.8. If the request arrived on a different connection, 865 return a 506 response and do not change session state in any way. 867 3. If no matching session exists, return a 481 request, and do not 868 change session state in any way. 870 6.6.3 Sending Instant Messages on a Session 872 Once a MSRP session has been established, either endpoint may send 873 instant messages to its peer using the SEND method. When an endpoint 874 wishes to do so, it MUST construct a SEND request according to the 875 following process: 877 1. Insert the message payload in the body, and the media type in the 878 Content-Type header field. The media type MUST match one of the 879 types in the format list negotiated in the SDP exchange. If a "*" 880 is present in the format list, then the media type SHOULD match 881 one of the explicitly listed entries, but MAY be any other 882 arbitrary value. 884 2. Set the TR-ID header field to a unique value. 886 3. Send the request on the connection associated with the session. 888 4. If a 2xx response code is received, the transaction was 889 successful. 891 5. If a 5xx response code is received, the transaction failed, but 892 may possibly be successful if retried. The endpoint MAY retry the 893 request as a new transaction, that is, with a new TR-ID value. If 894 the endpoint receives 5xx responses more than some threshold 895 number of times in a row, it SHOULD assume the session has 896 failed, and initiate tear-down via the signaling protocol. The 897 threshold value is a matter of local policy. 899 6. If a 415 response is received, this indicates the recipient is 900 unable or unwilling to process the media type. The sender SHOULD 901 NOT attempt to send that particular media type again in the 902 context of this session. 904 7. If any other response code is received, the endpoint SHOULD 905 assume the session has failed, and initiate tear-down. 907 When an endpoint receives a SEND request, it MUST perform the 908 following steps. 910 1. Determine that it understands the media type in the body, if any 911 exists. 913 2. If it does, return a 200 response and render the message to the 914 user. The method of rendering is a matter of local policy. 916 3. If it does not understand the media type, return a 415 response. 918 6.6.3.1 Ending a Session 920 When either endpoint in an MSRP session wishes to end the session, it 921 first signals its intent using the normal processing for the 922 signaling protocol. For example, in SIP, it would send a BYE request 923 to the peer. After agreeing to end the session, the host endpoint 924 MUST release any resources acquired as part of the session. The 925 process for this differs depending on whether the session is hosted 926 directly by the host, or an a relay. 928 The host MUST destroy local state for the session. This involves 929 completely removing the state entry for this session and invalidating 930 session URL. If the host is using an MSRP relay, it MUST send a BIND 931 containing an expires value of zero. This request MUST be sent host 932 connection established by the original BIND request. This BIND 933 request MUST include the session URL in the S-URL header field. 935 Since these host actions completely destroy the session state at 936 the hosting device, the visitor is not required to take further 937 action beyond cleaning up any local state. If for some reason the 938 host fails to destroy session state, the state will be invalidated 939 anyway when either of the original BIND or VISIT requests expire. 941 6.6.4 Managing Session State and Connections 943 A MSRP session is represented by state at the host device. As mention 944 previously, session state is identified by an MSRP URL. An active 945 session also has two associated network connections. The connection 946 hosting device and the host endpoint is known as the host connection. 947 The connection with the visiting endpoint is the visiting connection. 948 Note that when the session state is hosted directly by an endpoint, 949 the host connection may not involve a physical network connection; 950 rather it is a logical connection the device maintains with itself. 952 When session state is destroyed for any reason, the hosting device 953 SHOULD drop the connection(s). 955 If a connection fails for any reason, the session hosting device MUST 956 invalidate the session state. This is true regardless of whether the 957 dropped connection is the host or visiting connection. Once a 958 connection is dropped, the associated session state MUST NOT be 959 reused. If the endpoints wish to continue to communicate after a 960 connection failure, they must initiate a new session. An endpoint 961 detecting a connection failure SHOULD attempt to tear down the 962 session using the rules of the signaling protocol. 964 It would be nice to allow sessions to be recovered after a 965 connection failure, perhaps by allowing the opposite endpoint to 966 reconnect, and send a new VISIT or BIND request. However, this 967 approach creates a race condition between the time that the 968 hosting device notices the failed connection, and the time that 969 the endpoint tries to recover the session. If the endpoint 970 attempts to reconnect prior to the hosting device noticing the 971 failure, the hosting device will interpret the recovery attempt as 972 a conflict. The only way around this would be to force the hosting 973 device to do a liveness check on the original connection, which 974 would create a lot of complexity and overhead that do not seem to 975 be worth the trouble. 977 6.7 MSRP Relays 979 6.7.1 Establishing Session State at a Relay 981 An endpoint that wishes to host a MSRP session MAY do so by 982 initiating session state at a MSRP relay, rather than hosting 983 directly. An endpoint may wish to do this because network topology or 984 local policy prevents a peer from connecting directly to the 985 endpoint. The use of a relay should not be the default case, that is, 986 a hosting endpoint that is not prevented from doing so by topology or 987 policy SHOULD host the session directly. In order to use a relay, an 988 MSRP endpoint MUST have knowledge of that relay's existence and 989 location.. 991 We previously mentioned how an endpoint wishing to host a MSRP 992 session constructs session URL. When using a relay, the endpoint 993 delegates that responsibility to the relay. 995 To establish session state at a relay, the endpoint MUST perform the 996 following steps: 998 1. Open a network connection to the relay at the relays address and 999 the well-known port for MSRP relays, or at another port if so 1000 configured. 1002 2. Construct a BIND request with a S-URL that refers to the relay. 1004 3. Set the Expire header field to a desired value. 1006 4. Send the BIND request on the connection. 1008 5. Respond to any authentication request from the relay. 1010 6. If the response has a 2xx status code, use the URL in the S-URL 1011 header field as the session URL. The endpoint uses this URL in 1012 exactly the same manner as it had constructed it itself. 1013 Additionally, accept the expires value in the response as session 1014 expiration time. 1016 A MSRP relay listens for connections to its well-known port at all 1017 times. When it receives a BIND request, it SHOULD authenticate the 1018 request, either using digest-authentication, TLS authentication, or 1019 some other authentication mechanism. If authentication succeeds, the 1020 relay performs the following steps: 1022 1. Verify the client is authorized to BIND to this relay. If not, 1023 return a 403 response and make no state change. 1025 2. If the client is authorized, construct a session MSRP URL. The 1026 URL MUST resolve to the relay. It SHOULD be temporary, and hard 1027 to guess. It MUST not duplicate URL used in any active sessions 1028 hosted by the relay. If the relay wishes the visiting endpoint to 1029 connect over a point other than the MSRP relay well-know port, it 1030 MUST explicitly add the port number to visitor URL. 1032 3. Establish the expiration time for the session according to 1033 section Section 6.8. 1035 4. Create state for the session. The relay MUST associate the 1036 connection on which the BIND request arrived as the host 1037 connection for the session. 1039 5. Return a 200 response, with the session URL in the S-URL header 1040 field, and the session expiration time in the Exp header field.. 1042 When an MSRP relay receives a VISIT request, it MUST perform the 1043 following steps: 1045 1. Check the S-URL header field value to see it matches the URL for 1046 an existing session state entry. 1048 2. If not, return a 481 response and make no state changes 1050 3. If it matches, but another connection has already been associated 1051 with the session URL, return a 506 response and make no state 1052 changes. If the session has been previously associated with this 1053 connection, treate the request as a refresh. 1055 4. If it matches, and no visiting connection has been previously 1056 associated with the session, then the VISIT succeeds. The relay 1057 assigns the connection on which it received the VISIT request as 1058 the visiting connection for the session, and returns a 200 1059 response. The visit expiration time is established as described 1060 in Section 6.8 and returned in the response. 1062 6.7.2 Removing Session State from a relay 1064 An MSRP relay SHOULD remove state for a session when any of the 1065 following conditions occur: 1067 o The expiration time for either the BIND or VISIT is reached 1068 without a respective refresh request. 1070 o The host sends a BIND refresh request matching with an expiration 1071 value of zero. 1073 o Either the host or visitor network connection fails for any 1074 reason. 1076 6.7.3 Sending IMs across an MSRP relay 1078 Once a session is established at a relay, the host and visitor may 1079 exchange IMs by sending SEND requests. Under normal circumstances, 1080 the relay does not respond to SEND requests in any way. Rather, the 1081 relay MUST forward the request to the peer connection unchanged. 1082 Likewise, if the relay receives a response it MUST forward the 1083 request unchanged on the peer connection. 1085 If a SEND request arrives on a connection that is not associated with 1086 a session, the relay MUST return a 481 response. 1088 6.7.4 Relay Pairs 1090 In rare circumstances, two relays may be required in a session. For 1091 example, two endpoints may exist in separate administrative domains, 1092 where each domain's policy insist that all sessions must cross that 1093 domain's relay. A relay operating on behalf of the visiting endpoint 1094 is known as a visiting relay. An MSRP relay MAY be capable of acting 1095 as a visiting relay. 1097 In a two relay scenario, the visitor connects to a relay operating on 1098 its behalf, rather than connecting directly to the hosting device. 1099 The visitor sends a VISIT request as it would if it had connected 1100 directly to the hosting device. The visiting relay then connect to 1101 the hosting device and performs a VISIT request on behalf of the 1102 visitor. 1104 When a relay that is capable of acting as a visiting relay receives a 1105 VISIT request, it MUST check to see if the S-URL of the request 1106 matches a domain that the relay hosts. If the URL matches, then the 1107 visitor is not requesting the relay act as a visiting relay, and it 1108 SHOULD operate normally. If the URL does not match, then the relay 1109 SHOULD perform the following steps: 1111 1. The relay SHOULD authenticate the VISIT request, using digest 1112 authentication or some other mechanism. 1114 2. Determine that the visiting endpoint is authorized to use this 1115 device as a visiting relay. If not, return a 403 response and 1116 drop the connection. 1118 3. Attempt to open a connection to the hosting device, determining 1119 the address and port from the S-URL exactly as if it were a 1120 visiting endpoint connecting directly. If this connection is 1121 successful, continue with the remaining steps. Otherwise, return 1122 a 500 response. 1124 4. Create local state to associate the connection to the host device 1125 with the connection to the visiting device. 1127 5. Relay the VISIT request unchanged to the hosting device. 1129 6. Relay the response to the VISIT request unchanged to the visiting 1130 endpoint. If the response is a 200, set the expiration time for 1131 the local session state to the value in the Exp header in the 1132 response. 1134 7. Relay all subsequent arriving on one of the associated 1135 connections to the peer connection. 1137 The preceding steps result in local session state that expires based 1138 on the expiration time negotiated between the visiting endpoint and 1139 the hosting device. The visiting endpoint will send VISIT requests on 1140 the same connection from time to time to refresh the session state 1141 expiration time. A visiting relay MUST refresh the local expiration 1142 time based on the Exp header field value in a successful response to 1143 such a VISIT request. If the local expiration time passes without a 1144 refresh, the visiting relay SHOULD invalidate the session state and 1145 SHOULD drop the associated connections. 1147 If either associated connection fails for any reason, the visiting 1148 relay SHOULD invalidate the session state, and SHOULD drop the peer 1149 connection. 1151 6.8 Session State Expiration 1153 State associated with MSRP sessions, either at the host endpoint or a 1154 host relay, is soft-state; that is, it expires over time unless 1155 refreshed. The expiration time is determined by the Expires header 1156 field in VISIT and BIND requests. All VISIT and BIND requests MUST 1157 contain an Expires header field. This field is defined as an integer 1158 number of seconds from the time that the request is received. 1160 When a hosting device (endpoint or relay) creates session state due 1161 to a successful VISIT request, it SHOULD accept the Expires value 1162 from the request, although it MAY choose a smaller value. It MUST NOT 1163 choose a larger value. The device MUST communicate the actual chosen 1164 value back to the opposite endpoint by placing the value in an 1165 expires header field in the response. 1167 Likewise, when a relay creates session state due to a successful BIND 1168 request, it SHOULD accept the expires value from the request, 1169 although it MAY choose a smaller value. It MUST NOT choose a larger 1170 value. The device MUST communicate the actual chosen value back to 1171 the opposite endpoint by placing the value in an Expires header field 1172 in the response. 1174 A visiting relay does not normally respond to a VISIT request. 1175 Rather, it relays the request to the hosting device, and relays the 1176 resulting response back to the visiting endpoint. This prevents it 1177 from being able to negotiate the expiration time in the same way as 1178 hosting devices. Therefore, a visiting relay MUST determine session 1179 expiration time from the Exp header field in any 200 response 1180 returned by the hosting device. 1182 6.9 Digest Authentication 1184 MSRP relays may use the digest authentication scheme to authenticate 1185 users. MSRP digest authentication is a simplified version of HTTP 1186 digest authentication [18], but this specification does not 1187 normatively depend on that document. MSRP digest authentication does 1188 not support the concept of a protection domain, nor does it support 1189 integrity protection. Since a user of a relay is expected to have 1190 credentials for that particular relay, it does not support the realm 1191 concept. Finally, since digest authentication is only expected for 1192 the initial BIND or VISIT request, MSRP does not support HTTP digest 1193 optimizations such as MD5-sess and preemptive credential loading by 1194 the client. 1196 Typically, a hosting user that uses a relay will have a preexisting 1197 relationship with that relay. This relationship SHOULD include 1198 authentication credentials. An MSRP relay SHOULD authenticate initial 1199 BIND requests. 1201 It is less likely that the visiting user will have an account at the 1202 hosting relay, so in many cases the authentication of VISIT requests 1203 is not useful. However a relay MAY authenticate initial VISIT 1204 requests. A visiting relay SHOULD authenticate initial VISIT 1205 requests, as it is much more likely to share credentials with the 1206 visiting user. 1208 There has been some discussion that a hosting relay SHOULD also 1209 authenticate VISIT requests. However, it will be very common for 1210 visiting users to have no preexisting relationship with the host 1211 relay. Using authentication here would require the host endpoint 1212 to send temporary credentials in the SDP exchange, perhaps as part 1213 of the session URL. However, these temporary credentials would 1214 necessarily be transferred via the same channels as the session 1215 URL itself. If the credentials are sufficiently protected in 1216 transfer, then so is the session URL. Further, since the session 1217 URL is intended for a one time use, and is expected to be hard to 1218 guess, that URL itself may be sufficient for this purpose. 1220 MSRP relays MUST NOT request authentication for any method other than 1221 BIND and VISIT. 1223 If a relay wishes to authenticate a request using digest 1224 authentication, it MAY challenge the request by responding with a 1225 401 response, which MUST include a SChal header field. 1227 If an endpoint wishes to respond to a digest authentication challenge 1228 received in a 401 response, it MAY do so by sending a new VISIT or 1229 BIND request, identical to the previous request, but with a CAuth 1230 header field containing the response to the challenge. 1232 6.9.1 The MD5 Algorithm 1234 The only digest authentication algorithm defined in this 1235 specification is MD5. [8] Other algorithms can be added as 1236 extensions. MD5 is the default algorithm if no algorithm directive is 1237 present in the challenge. 1239 The MD5 algorithm is defined as follows: 1241 Let KD(secret, data) denote the string obtained by performing the 1242 digest algorithm to the data "data" with the secret "secret". Let 1243 H(data) denote the string obtained by performing the checksum 1244 algorithm on the data "data". 1246 For the "MD5" algorithm, H(data) = MD5(data), and KD(secret,data) = 1247 H(concat(secret, ":", data) 1249 The request-digest value in a CAuth header field takes the following 1250 format. Note that unq(quoted-string) denotes the value of the string 1251 with the quotes removed. 1253 request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <"> 1254 A1 = unq(username-value) ":" shared-secret 1255 A2 = Method 1257 When the relay receives a CAuth header, it SHOULD check its validity 1258 by looking up the shared secret, or H(A1), performing the same digest 1259 operation as performed by the client, and comparing the results to 1260 the request-digest value. 1262 6.10 Method Descriptions 1264 This section summarizes the purpose of each MSRP method. All MSRP 1265 messages MUST contain the TR-ID header fields. All messages MUST 1266 contain a length field in the start line that indicates the overall 1267 length of the request, including any body, but not including the 1268 start line itself. Additional requirements exist depending on the 1269 individual method. Except where otherwise noted, all requests are hop 1270 by hop. 1272 6.10.1 BIND 1274 The BIND method is used by a host endpoint to establish or refresh 1275 session state at a hosting relay. BIND requests SHOULD be 1276 authenticated. BIND requests MUST contain the S-URL and Exp header 1277 fields and MAY contain the CAuth header fields. 1279 A successful response to a BIND request MUST contain the S-URL and 1280 Exp header fields. 1282 6.10.2 SEND 1284 The SEND method is used by both the host and visitor endpoints to 1285 send instant messages to its peer endpoint. SEND requests SHOULD 1286 contain a MIME body part. The body MUST be of a media type included 1287 in the format list negotiated in the SDP exchange. If a body is 1288 present, the request MUST contain a Content-Type header field 1289 identifying the media type of the body. 1291 Unlike other methods, SEND requests are end to end in nature. This 1292 means the request is consumed only by the opposite endpoint. Under 1293 normal conditions, any intervening relays merely forward the request 1294 on towards the peer endpoint. 1296 6.10.3 VISIT 1298 The visiting endpoint uses the VISIT method to associate a network 1299 connection with the session state at the hosting device, which could 1300 be either the host endpoint or a relay operating on behalf of the 1301 host endpoint. VISIT is also used to refresh the expiration time for 1302 the visiting connection. The request MUST contain a S-URL header 1303 matching the session URL. A VISIT request MUST contain the Expires 1304 header field. 1306 Successful responses to a VISIT request MUST contain the Expires 1307 header. 1309 There is normally no authentication operation for the VISIT 1310 request. This is because the session URL acts as a shared secret 1311 between host and the visitor. This puts certain requirements on 1312 the handling of the session URLs that are discussed in Section 9. 1313 However, if a visiting relay is used, it SHOULD authenticate 1314 initial VISIT requests, and MAY authenticate subsequent VISIT 1315 refresh requests. 1317 6.11 Response Code Descriptions 1319 This section summarizes the various response codes. Except where 1320 noted, all responses MUST contain a TR-ID header field matching the 1321 TR-ID header field of the associated request. Responses are never 1322 consumed by relays. 1324 6.11.1 200 1326 The 200 response code indicates a successful transaction. 1328 6.11.2 400 1330 A 400 response indicates a request was unintelligible. 1332 6.11.3 401 1333 A 401 response indicates authentication is required. 401 responses 1334 MUST NOT be used in response to any method other than BIND and VISIT. 1335 A 401 response MUST contain a SChal header field. 1337 6.11.4 403 1339 A 403 response indicates the user is not authorized to perform the 1340 action. 1342 6.11.5 415 1344 A 415 response indicates the SEND request contained a MIME 1345 content-type that is not understood by the receiver. 1347 6.11.6 481 1349 A 481 response indicates that no session exists for the connection. 1351 6.11.7 500 1353 A 500 response indicates that a relay was unable to deliver a SEND 1354 request to the target. 1356 6.11.8 506 1358 A 506 response indicates that a VISIT request occurred in which the 1359 S-URL indicates a session that is already associated with another 1360 connection. A 506 response MUST NOT be returned in response to any 1361 method other than VISIT. 1363 6.12 Header Field Descriptions 1365 This section summarizes the various header fields. MSRP header fields 1366 are single valued; that is, they MUST NOT occur more than once in a 1367 particular request or response. 1369 6.12.1 TR-ID 1371 The TR-ID header field contains a transaction identifier used to map 1372 a response to the corresponding request. A TR-ID value MUST be unique 1373 among all values used by a given endpoint inside a given session. 1374 MSRP elements MUST NOT assume any additional semantics for TR-ID. 1376 6.12.2 Exp 1378 The Exp header field specifies when the state associated with a BIND 1379 or VISIT request will expire. The value is specified as an integer 1380 number of seconds from the time the request is received. BIND and 1381 VISIT requests MUST contain this header field. Furthermore, 1382 successful responses to BIND or VISIT requests must also contain the 1383 Exp header. 1385 The maximum value for the Exp header field is (2**32)-1 seconds. 1387 Exp has no meaning if it occurs in MSRP messages other than BIND and 1388 VISIT requests, and responses to those requests. MSRP compliant 1389 devices SHOULD NOT use Exp in other requests or responses, unless 1390 that usage is defined in an extension to this specification. 1392 6.12.3 CAuth 1394 The CAuth header field is used by a host endpoint to respond to offer 1395 digest authentication credentials to a relay, usually in response to 1396 a digest authentication challenge. CAuth SHOULD NOT be present in a 1397 request of any method other than BIND and VISIT. 1399 The CAuth credentials adhere to the following syntax: 1401 credentials = "Digest" digest-response 1402 digest-response = 1#( username | nonce | 1403 response | [ algorithm ] | 1404 [auth-param] ) 1406 username = "username" "=" username-value 1407 username-value = quoted-string 1408 response = "response" "=" request-digest 1409 request-digest = <"> 32LHEX <"> 1410 LHEX = "0" | "1" | "2" | "3" | 1411 "4" | "5" | "6" | "7" | 1412 "8" | "9" | "a" | "b" | 1413 "c" | "d" | "e" | "f" 1415 The meaning of each value is as follows: 1417 username: The user's account name. 1419 nonce: The nonce value copied from the challenge. 1421 response: A 32 hex digit string that proves user knowledge of the 1422 shared secret. 1424 algorithm: The algorithm value copied from the challenge. 1426 auth-param: Additional parameters for the sake of extensibility. 1428 6.12.4 SChal 1430 The SChal header field is used by a relay to carry the challenge in a 1431 digest authentication attempt. Exactly one SChal header field MUST 1432 exist in a 401 response. The SChal header MUST NOT be used in any 1433 message except for a 401 response. The SChal header field value is 1434 made up of a challenge according to the following syntax: 1436 challenge= digest-scheme SP digest-challenge 1438 digest-scheme = "Digest" 1439 digest-challenge = 1#( nonce | [ algorithm ] | 1440 [auth-param] ) 1441 nonce = "nonce" "=" nonce-value 1442 nonce-value = quoted-string 1443 algorithm = "algorithm" "=" ( "MD5" | token ) 1445 The meaning of each value is as follows: 1447 digest scheme: A token to identify the particular authentication 1448 scheme. For digest, the value MUST be "Digest." This token is 1449 present for the sake of extensibility. 1451 nonce: A server-specified string, which the relay SHOULD uniquely 1452 generate each time it sends a 401 response. This string SHOULD 1453 take the form of base64 or hexadecimal data, to avoid the presence 1454 of a double-quote character, which is not allowed. 1456 algorithm: A token indicating the algorithms to be used to generate 1457 the digest and checksum. This directive exists for the sake of 1458 extensibility; the only value defined by this document is "MD5". 1459 absence of this directive indicates a value of "MD5." 1461 6.12.5 Content-Type 1463 The Content-Type header field is used to indicate the MIME media type 1464 of the body. Content-Type MUST be present if a body is present. 1466 6.12.6 S-URL 1468 The S-URL header field is used to identify the session. The S-URI 1469 header field MUST be present in a BIND request, a successful response 1470 to a BIND request, or a VISIT request. 1472 7. Examples 1473 This section shows some example message flows for various common 1474 scenarios. The examples assume SIP is used to transport the SDP 1475 exchange. Details of the SIP messages and SIP proxy infrastructure 1476 are omitted for the sake of brevity. In the examples, assume the 1477 offerer is sip:alice@atlanta.com and the answerer is 1478 sip:bob@biloxi.com. In any given MSRP message, an "xx" in the length 1479 field indicates the actual length of the rest of the message. 1481 7.1 No Relay 1483 1. Alice constructs a session URL of msrp://alicepc.atlanta.com/ 1484 iau39 and listens for a connection on TCP port 7777. 1486 2. Alice->Bob (SIP): INVITE sip:bob@biloxi.com 1488 c=IN IP4 fillername 1489 m=message 7777 msrp/tcp text/plain 1490 a=direction:both a=session:msrp://alicepc.atlanta.com/iau39:7777 1492 3. Bob->Alice: Open TCP connection to alicepc.atlanta.com:7777. 1494 4. Bob->Alice (MSRP): 1496 MSRP xx VISIT 1497 S-URL: msrp://alicepc.atlanta.com/iau39:7777 1498 Tr-ID: sie09s 1499 Exp:600 1501 5. Alice->Bob (MSRP): 1503 MSRP xx 200 OK 1504 Tr-ID: sie09s 1505 Exp:300 1507 6. Bob->Alice (SIP): 200 OK 1509 c=IN IP4 ignorefield 1510 m=message 7777 msrp/tcp text/plain 1511 a=direction:active 1513 7. Alice->Bob (SIP): ACK 1515 8. Alice->Bob (MSRP): 1517 MSRP xx SEND 1518 TR-ID: 123 1519 Content-Type: "text/plain" 1520 Hi, I'm Alice! 1522 9. Bob->Alice (MSRP): 1524 MSRP xx 200 OK 1525 TR-ID: 123 1527 10. Bob->Alice (MSRP): 1529 MSRP xx SEND 1530 TR-ID: 456 1531 Content-Type: "text/plain" 1533 Hi, Alice! I'm Bob! 1535 11. Alice->Bob (MSRP): 1537 MSRP xx 200 OK 1538 TR-ID: 456 1540 12. Alice->Bob (SIP): BYE 1542 13. Alice invalidates session and drops connection. 1544 14. Bob invalidates local state for the session. 1546 15. Bob->Alice (SIP): 200 OK 1548 7.2 Single Relay 1550 This scenario introduces an MSRP relay at relay.atlanta.com. 1552 1. Alice->Relay (MSRP): Alice opens a connection to the relay, and 1553 sends the following: 1555 MSRP xx BIND 1556 S-URL: msrp://relay.atlanta.com 1557 TR-ID: 321 1558 Exp:600 1560 2. Relay->Alice (MSRP): 1562 MSRP xx 200 OK 1563 TR-ID: 321 1564 S-URL: msrp://relay.atlanta.com:7777/iau39 1565 Exp:300 1567 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com 1569 c=IN IP4 dummyvalue 1570 m=message 7777 msrp/tcp text/plain 1571 a=direction:passive 1572 a=session:msrp://relay.atlanta.com:7777/iau39 1574 4. Bob->Alice: Open connection to relay.atlanta.com:7777. 1576 5. Bob->Relay (MSRP): 1578 MSRP xx VISIT 1579 S-URL:msrp://relay.atlanta.com:7777/iau39 1580 TR-ID: msrp:sie09s 1581 Exp:500 1583 6. Relay->Bob (MSRP): 1585 MSRP xx 200 OK 1586 TR-ID: sie09s 1587 Exp:300 1589 7. Bob->Alice (SIP): 200 OK 1591 c=IN IP4 nobodybutchickens 1592 m=message 7777 msrp/tcp text/plain 1593 a=direction:active 1595 8. Alice->Bob (SIP): ACK 1597 9. Alice->Relay (MSRP): 1599 MSRP xx SEND 1600 TR-ID: 123 1601 Content-Type: "text/plain" 1602 Hi, I'm Alice! 1604 10. Relay->Bob (MSRP): 1606 MSRP xx SEND 1607 TR-ID: 123 1608 Content-Type: "text/plain" 1609 Hi, I'm Alice! 1611 11. Bob->Relay (MSRP): 1613 MSRP xx 200 OK 1614 TR-ID: 123 1616 12. Relay->Alice (MSRP): 1618 MSRP xx 200 OK 1619 TR-ID: 123 1621 13. Bob->Relay (MSRP): 1623 MSRP xx SEND 1624 TR-ID: 456 1625 Content-Type:"text/plain" 1627 Hi, Alice! I'm Bob! 1629 14. Relay->Alice (MSRP): 1631 MSRP xx SEND 1632 TR-ID: 456 1633 Content-Type: "text/plain" 1635 Hi, Alice! I'm Bob! 1637 15. Alice->relay (MSRP): 1639 MSRP xx 200 OK 1640 TR-ID: 456 1642 16. Relay->Bob (MSRP): 1644 MSRP xx 200 OK 1645 TR-ID: 456 1647 17. Alice->Bob (SIP): BYE 1649 18. Alice->Relay (MSRP): 1651 MSRP xx BIND 1652 S-URL: msrp://relay.atlanta.com:7777/iau39 1653 TR-ID: 42 1654 Exp:0 1656 19. Relay->Alice (MSRP): (relay invalidates session state) 1658 MSRP xx 200 OK 1659 TR-ID: 42 1660 Exp:0 1662 20. Bob invalidates local state for the session. 1664 21. Bob->Alice (SIP): 200 OK 1666 7.3 Two Relays 1668 In this scenario, both Alice and Bob are each required by local 1669 policy to route all sessions through a different local relay. 1671 1. Alice->AtlantaRelay (MSRP): Alice opens a connection to the 1672 relay, and sends the following: 1674 MSRP xx BIND 1675 S-URL: msrp://relay.atlanta.com 1676 TR-ID: 321 1677 Exp:600 1679 2. AtlantaRelay->Alice (MSRP): 1681 MSRP xx 200 OK 1682 TR-ID: 321 1683 S-URL: msrp://relay.atlanta.com:7777/iau39 1684 Exp:600 1686 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com 1688 c=IN IP4 blahblahblah 1689 m=message 7777 msrp/tcp text/plain 1690 a=session:msrp://relay.atlanta.com:7777/iau39 1691 a=direction:passive 1693 4. Bob determines that, due to local policy, he must connect 1694 through his own proxy. 1696 5. Bob->BiloxiRelay (MSRP): Bob opens a connection to his relay, 1697 and sends the following: 1699 MSRP xx VISIT 1700 S-URL: msrp://relay.atlanta.com:7777/iau39 1701 TR-ID: 934 1702 Exp:600 1704 6. BiloxiRelay->AtlantaRelay (MSRP): BiloxiRelay resolves the URL, 1705 opens a connection to relay.atlanta.com:7777, and sends the 1706 following: 1708 MSRP xx VISIT 1709 S-URL: msrp://relay.atlanta.com:7777/iau39 1710 TR-ID: 934 1711 Exp:600 1713 7. AtlantaRelay->BiloxiRelay(MSRP): 1715 MSRP xx 200 OK 1716 TR-ID: 934 1717 Exp:600 1719 8. BiloxiRelay->Bob(MSRP): 1721 MSRP xx 200 OK 1722 TR-ID: 934 1723 Exp:600 1725 9. Bob->Alice (SIP): 200 OK 1727 c=IN IP4 stuff 1728 m=message 7777 msrp/tcp text/plain 1729 a=direction: active 1731 10. Alice->Bob (SIP): ACK 1732 11. Alice->AtlantaRelay (MSRP): 1734 MSRP xx SEND 1735 TR-ID: 123 1736 Content-Type: "text/plain" 1737 Hi, I'm Alice! 1739 12. AtlantaRelay ->BiloxiRelay (MSRP): 1741 MSRP xx SEND 1742 TR-ID: 123 1743 Content-Type: "text/plain" 1744 Hi, I'm Alice! 1746 13. BiloxiRelay->Bob (MSRP): 1748 MSRP xx SEND 1749 TR-ID: 123 1750 Content-Type: "text/plain" 1751 Hi, I'm Alice! 1753 14. Bob->BiloxiRelay (MSRP): 1755 MSRP xx 200 OK 1756 TR-ID: 123 1758 15. BiloxiRelay->AtlantaRelay (MSRP): 1760 MSRP xx 200 OK 1761 TR-ID: 123 1763 16. AtlantaRelay->Alice (MSRP): 1765 MSRP xx 200 OK 1766 TR-ID: 123 1768 17. Alice->Bob (SIP): BYE 1770 18. Alice->AtlantaRelay (MSRP): 1772 MSRP xx BIND 1773 S-URL: msrp://relay.atlanta.com:7777/iau39 1774 TR-ID: 42 1775 Exp:0 1777 19. Relay->Alice (MSRP): (relay invalidates session state) 1779 MSRP xx 200 OK 1780 TR-ID: 42 1781 Exp:0 1783 20. Bob->Alice (SIP): 200 OK 1785 8. IANA Considerations 1787 To Do. 1789 Do we need to register URL schemes or SDP a-line attributes? 1791 9. Security Considerations 1793 There are a number of security considerations for MSRP, some of which 1794 are mentioned elsewhere in this document. This section discusses 1795 those further, and introduces some new ones. 1797 9.1 The MSRPS Scheme 1799 The MSRPS scheme indicates that all hops in an MSRP session MUST be 1800 protected with TLS. Ensuring this implies some additional rules. An 1801 MSRP relay MUST NOT return an MSRPS URL in the S-URL header field in 1802 a response to a BIND request unless the BIND request itself was 1803 received over a TLS protected session. A VISIT request for an MSRPS 1804 URL MUST be sent over a TLS protected connection. If a visiting relay 1805 receives a VISIT request for an MSRPS URL, the connection to the 1806 hosting device MUST also be protected. 1808 There has been controversy on whether an MSRPS scheme is really 1809 needed, since there is a small limit to the total number of hops 1810 in an MSRP session. However, a mechanism is required to inform the 1811 visitor to use TLS in the first place. We could have used an SDP 1812 a-line attribute for this. However, there also needs to be a 1813 mechanism for a hosting relay to tell the host endpoint to request 1814 the visitor use TLS. The MSRPS scheme seems to best fit all of 1815 these requirements. 1817 Open Issue: There is also some controversy over how TLS should be 1818 used with MSRP. The changes in this draft version make it possible 1819 for relays to act as tunnels, where the TLS handshake is 1820 end-to-end. This is much the same way that TLS is handled by HTTPS 1821 proxies. However, this usage requires at least one endpoint to 1822 have a TLS server certificate, which may not be likely. Another 1823 approach is to make TLS usage hop-by-hop. When at least one relay 1824 is used, only the relays would need server certificates. Even if 1825 we support end-to-end TLS, we may still need a way to specify 1826 hop-by-hop TLS, because since end-to-end TLS would delay the TLS 1827 handshake until _after_ the BIND and VISIT requests, these 1828 requests would not be protected. 1830 9.2 Sensitivity of the Session URL 1832 The URL of a MSRP session is used by the visiting endpoint to 1833 identify itself to the hosting device, regardless of whether the 1834 session is directly hosted by the host endpoint, or is hosted by a 1835 relay. If an attacker were able to acquire session URL, either by 1836 guessing it or by eavesdropping, there is a window of opportunity in 1837 which the attacker could hijack the session by sending a VISIT 1838 request to the host device before the true visiting endpoint. Because 1839 of this sensitivity, the session URL SHOULD be constructed in a way 1840 to make it difficult to guess, and should be sufficiently random so 1841 that it is unlikely to be reused. All mechanisms used to transport 1842 the session URL to the visitor and back to the host SHOULD be 1843 protected from eavesdroppers and man-in-the-middle attacks. 1845 Therefore an MSRP device MUST support the use of TLS for at least the 1846 VISIT request, which by extension indicates the endpoint MUST support 1847 the use of TLS for all MSRP messages. Further, MSRP connections 1848 SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST 1849 be capable of using the security features of the signaling protocol 1850 in order to protect the SDP exchange and SHOULD actually use them on 1851 all such exchanges. End-to-end protection schemes SHOULD be preferred 1852 over hop-by-hop schemes for protection of the SDP exchange. 1854 9.3 End to End Protection of IMs 1856 Instant messages can contain very sensitive information. As a result, 1857 as specified in RFC 2779 [3], instant messaging protocols need to 1858 provide for encryption, integrity and authentication of instant 1859 messages. Therefore MSRP endpoints MUST support the end-to-end 1860 encryption and integrity of bodies sent via SEND requests using CMS 1861 [7]. 1863 Note that while each protected body could use separate keying 1864 material, this is inefficient in that it requires an independent 1865 public key operation for each message. Endpoints wishing to invoke 1866 end-to-end protection of message sessions SHOULD exchange symmetric 1867 keys in SDP k-lines, and use secret key encryption on for each MSRP 1868 message. When symmetric keys are present in the SDP, the offer-answer 1869 exchange MUST be protected from eavesdropping and tampering using the 1870 appropriate facilities of the signaling protocol. For example, if the 1871 signaling protocol is SIP, the SDP exchange MUST be protected using 1872 S/MIME. 1874 Open Issue: This subsection needs very close scrutiny for accuracy 1875 and security. In particular, do we need to say more about using 1876 secret key operations in CMS? 1878 9.4 CPIM compatibility 1880 MSRP sessions may be gatewayed to other CPIM [16]compatible 1881 protocols. If this occurs, the gateway MUST maintain session state, 1882 and MUST translate between the MSRP session semantics and CPIM 1883 semantics that do not include a concept of sessions. Furthermore, 1884 when one endpoint of the session is a CPIM gateway, instant messages 1885 SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST 1886 include "message/cpim" as the first entry in its SDP format list. 1887 MSRP endpoints sending instant messages to a peer that has included 1888 'message/cpim" as the first entry in the format list SHOULD 1889 encapsulate all instant message bodies in "message/cpim" wrappers. 1890 All MSRP endpoints SHOULD support the S/MIME features of that format. 1892 10. Changes introduced in draft-ietf-simple-message-sessions-00 1894 Name changed to reflect status as a work group item. 1896 This version no longer supports the use of multiple sessions 1897 across a single TCP session. This has several related changes: 1898 There is now a single session URI, rather than a separate one for 1899 each endpoint. The session URI is not required to be in requests 1900 other than BIND and VISIT, as the session can be determined based 1901 on the connection on which it arrives. 1903 BIND and VISIT now create soft state, eliminating the need for the 1904 RELEASE and LEAVE methods. 1906 The MSRP URL format was changed to better reflect generic URL 1907 standards. URL comparison and resolution rules were added. SRV 1908 usage added. 1910 Determination of host and visitor roles now uses a direction 1911 attribute much like the one used in COMEDIA. 1913 Format list negotiation expanded to allow a "prefer these formats 1914 but try anything" semantic 1916 Clarified handling of direction notification failures. 1918 Clarified signaling associated with session failure due to dropped 1919 connections. 1921 Clarified security related motivations for MSRP. 1923 Removed MIKEY dependency for session key exchange. Simple usage of 1924 k-lines in SDP, where the SDP exchange is protected end-to-end 1925 seems sufficient. 1927 11. Changes introduced in draft-campbell-simple-im-sessions-01 1929 Version 01 is a significant re-write. References to COMEDIA were 1930 removed, as it was determined that COMEDIA would not allow 1931 connections to be used bidirectionally in the presence of NATs. 1932 Significantly more discussion of a concrete mechanism has been added 1933 to make up for no longer using COMEDIA. Additionally, this draft and 1934 draft-campbell-cpimmsg-sessions (which would have also changed 1935 drastically) have now been combined into this single draft. 1937 12. Contributors 1939 The following people contributed substantially to this ongoing 1940 effort: 1942 Rohan Mahy 1943 Allison Mankin 1944 Jon Peterson 1945 Brian Rosen 1946 Dean Willis 1947 Adam Roach 1948 Cullen Jennings 1950 Normative References 1952 [1] Handley, M. and V. Jacobson, "SDP: Session Description 1953 Protocol", RFC 2327, April 1998. 1955 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1956 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1957 Session Initiation Protocol", RFC 3261, June 2002. 1959 [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 1960 Presence Protocol Requirements", RFC 2779, February 2000. 1962 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 1963 Identifiers (URL): Generic Syntax", RFC 2396, August 1998. 1965 [5] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging 1966 Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in 1967 progress), January 2003. 1969 [6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1970 specifying the location of services (DNS SRV)", RFC 2782, 1971 February 2000. 1973 [7] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 1974 August 2002. 1976 [8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1977 1992. 1979 Informational References 1981 [9] Campbell, B. and J. Rosenberg, "Session Initiation Protocol 1982 Extension for Instant Messaging", RFC 3428, September 2002. 1984 [10] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1985 "RTP: A Transport Protocol for Real-Time Applications", RFC 1986 1889, January 1996. 1988 [11] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D. 1989 and A. Johnston, "A Multi-party Application Framework for SIP", 1990 draft-ietf-sipping-cc-framework-02 (work in progress), May 1991 2003. 1993 [12] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, 1994 "Best Current Practices for Third Party Call Control in the 1995 Session Initiation Protocol", draft-ietf-sipping-3pcc-03 (work 1996 in progress), March 2003. 1998 [13] Sparks, R. and A. Johnston, "Session Initiation Protocol Call 1999 Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in 2000 progress), February 2003. 2002 [14] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of 2003 Resource Management and Session Initiation Protocol (SIP)", RFC 2004 3312, October 2002. 2006 [15] Peterson, J., "A Privacy Mechanism for the Session Initiation 2007 Protocol (SIP)", RFC 3323 , November 2002. 2009 [16] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", 2010 draft-ietf-impp-im-03 (work in progress), May 2003. 2012 [17] Yon, D., "Connection-Oriented Media Transport in SDP", 2013 draft-ietf-mmusic-sdp-comedia-05 (work in progress), March 2014 2003. 2016 [18] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2017 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 2018 Basic and Digest Access Authentication", RFC 2617, June 1999. 2020 Authors' Addresses 2022 Ben Campbell 2023 dynamicsoft 2024 5100 Tennyson Parkway 2025 Suite 1200 2026 Plano, TX 75024 2028 EMail: bcampbell@dynamicsoft.com 2030 Jonathan Rosenberg 2031 dynamicsoft 2032 600 Lanidex Plaza 2033 Parsippany, NJ 07054 2035 EMail: jdrosen@dynamicsoft.com 2037 Robert Sparks 2038 dynamicsoft 2039 5100 Tennyson Parkway 2040 Suite 1200 2041 Plano, TX 75024 2043 EMail: rsparks@dynamicsoft.com 2045 Paul Kyzivat 2046 Cisco Systems 2047 Mail Stop LWL3/12/2 2048 900 Chelmsford St. 2049 Lowell, MA 01851 2051 EMail: pkyzivat@cisco.com 2053 Intellectual Property Statement 2055 The IETF takes no position regarding the validity or scope of any 2056 intellectual property or other rights that might be claimed to 2057 pertain to the implementation or use of the technology described in 2058 this document or the extent to which any license under such rights 2059 might or might not be available; neither does it represent that it 2060 has made any effort to identify any such rights. Information on the 2061 IETF's procedures with respect to rights in standards-track and 2062 standards-related documentation can be found in BCP-11. Copies of 2063 claims of rights made available for publication and any assurances of 2064 licenses to be made available, or the result of an attempt made to 2065 obtain a general license or permission for the use of such 2066 proprietary rights by implementors or users of this specification can 2067 be obtained from the IETF Secretariat. 2069 The IETF invites any interested party to bring to its attention any 2070 copyrights, patents or patent applications, or other proprietary 2071 rights which may cover technology that may be required to practice 2072 this standard. Please address the information to the IETF Executive 2073 Director. 2075 Full Copyright Statement 2077 Copyright (C) The Internet Society (2003). All Rights Reserved. 2079 This document and translations of it may be copied and furnished to 2080 others, and derivative works that comment on or otherwise explain it 2081 or assist in its implementation may be prepared, copied, published 2082 and distributed, in whole or in part, without restriction of any 2083 kind, provided that the above copyright notice and this paragraph are 2084 included on all such copies and derivative works. However, this 2085 document itself may not be modified in any way, such as by removing 2086 the copyright notice or references to the Internet Society or other 2087 Internet organizations, except as needed for the purpose of 2088 developing Internet standards in which case the procedures for 2089 copyrights defined in the Internet Standards process must be 2090 followed, or as required to translate it into languages other than 2091 English. 2093 The limited permissions granted above are perpetual and will not be 2094 revoked by the Internet Society or its successors or assignees. 2096 This document and the information contained herein is provided on an 2097 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2098 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2099 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2100 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2101 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2103 Acknowledgement 2105 Funding for the RFC Editor function is currently provided by the 2106 Internet Society.