SIMPLE Working Group B. Campbell Internet-Draft J. Rosenberg Expires: November 20, 2003 R. Sparks dynamicsoft P. Kyzivat Cisco Systems May 22, 2003 Instant Message Sessions in SIMPLE draft-ietf-simple-message-sessions-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 20, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The SIP MESSAGE method is used to send instant messages, where each message is independent of any other message. This is often called pager-mode messaging, due to the fact that this model is similar to that of most two-way pager devices. Another model is called session-mode. In session-mode, the instant messages are part of a media session that provides ordering, a security context, and other functions. This media session is established using a SIP INVITE, just as an audio or video session would be established. Campbell, et al. Expires November 20, 2003 [Page 1] Internet-Draft SIMPLE IM Sessions May 2003 This document describes the Message Session Relay Protocol (MSRP), a mechanism for transmitting session-mode messages with minimalist relay support. Additionally, this document describes using the SDP offer/answer model to initiate such sessions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation for Session-mode Messaging . . . . . . . . . . 4 3. Scope of this Document . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 5. SDP Offer-Answer Exchanges for MSRP Sessions. . . . . . . 8 5.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 8 5.2 The Direction Attribute . . . . . . . . . . . . . . . . . 9 5.3 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 10 5.4 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 11 6. The Message Session Relay Protocol . . . . . . . . . . . . 11 6.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 12 6.3 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 13 6.3.1 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . 14 6.4 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 14 6.5 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 15 6.6 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 16 6.6.1 Initiating an MSRP session . . . . . . . . . . . . . . . . 16 6.6.2 Handling VISIT requests . . . . . . . . . . . . . . . . . 19 6.6.3 Sending Instant Messages on a Session . . . . . . . . . . 20 6.6.4 Managing Session State and Connections . . . . . . . . . . 21 6.7 MSRP Relays . . . . . . . . . . . . . . . . . . . . . . . 22 6.7.1 Establishing Session State at a Relay . . . . . . . . . . 22 6.7.2 Removing Session State from a relay . . . . . . . . . . . 24 6.7.3 Sending IMs across an MSRP relay . . . . . . . . . . . . . 24 6.7.4 Relay Pairs . . . . . . . . . . . . . . . . . . . . . . . 24 6.8 Session State Expiration . . . . . . . . . . . . . . . . . 26 6.9 Digest Authentication . . . . . . . . . . . . . . . . . . 26 6.9.1 The MD5 Algorithm . . . . . . . . . . . . . . . . . . . . 27 6.10 Method Descriptions . . . . . . . . . . . . . . . . . . . 28 6.10.1 BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.10.2 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.10.3 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.11 Response Code Descriptions . . . . . . . . . . . . . . . . 29 6.11.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.11.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.11.3 401 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.11.4 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.11.5 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.11.6 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.11.7 500 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Campbell, et al. Expires November 20, 2003 [Page 2] Internet-Draft SIMPLE IM Sessions May 2003 6.11.8 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.12 Header Field Descriptions . . . . . . . . . . . . . . . . 30 6.12.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.12.2 Exp . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.12.3 CAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.12.4 SChal . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.12.5 Content-Type . . . . . . . . . . . . . . . . . . . . . . . 32 6.12.6 S-URL . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1 No Relay . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.2 Single Relay . . . . . . . . . . . . . . . . . . . . . . . 34 7.3 Two Relays . . . . . . . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . 40 9.1 The MSRPS Scheme . . . . . . . . . . . . . . . . . . . . . 40 9.2 Sensitivity of the Session URL . . . . . . . . . . . . . . 41 9.3 End to End Protection of IMs . . . . . . . . . . . . . . . 41 9.4 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 42 10. Changes introduced in draft-ietf-simple-message-sessions-00 . . . . . . . . . . 42 11. Changes introduced in draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 43 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 43 Normative References . . . . . . . . . . . . . . . . . . . 43 Informational References . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . 46 Campbell, et al. Expires November 20, 2003 [Page 3] Internet-Draft SIMPLE IM Sessions May 2003 1. Introduction The MESSAGE [9] extension to SIP [2] allows SIP to be used to transmit instant messages. Instant messages sent using the MESSAGE method are normally independent of each other. This approach is often called pager-mode messaging, since it follows a model similar to that used by many two-way pager devices. Pager-mode messaging makes sense for instant message exchanges where a small number of messages occur. There are also applications in which it is useful for instant messages to be associated together in some way. For example, a user may wish to join a text conference, participate in the conference for some period of time, then leave the conference. This usage is analogous to regular media sessions that are typically initiated, managed, and terminated using SIP. We commonly refer to this model as session-mode messaging. One of the primary purposes of SIP and SDP (Section 5) is the management of media sessions. Session-mode messaging can be thought of as a media session like any other. This document describes the motivations for session-mode messaging, the Message Session Relay Protocol, and the use of the SDP offer/answer mechanism for managing MSRP session. 2. Motivation for Session-mode Messaging Message sessions offer several advantages over pager-mode messages. For message exchanges that include more than a small number of message transactions, message sessions offer a way to remove messaging load from intervening SIP proxies. For example, a minimal session setup and tear-down requires one INVITE/ACK transaction, and one BYE transaction, for a total of 5 SIP messages. Normal SIP request routing allows for all but the initial INVITE transaction to bypass any intervening proxies that do not specifically request to be in the path for future requests. Session-mode messages never cross the SIP proxies themselves, unless proxies also act as message relays. Each pager mode message involves a complete SIP transaction, that is, a request and a response. Any pager-mode message exchange that involves more than 2 or 3 MESSAGE requests will generate more SIP requests than a minimal session initiation sequence. Since MESSAGE is normally used outside of a SIP dialog, these requests will typically traverse the entire proxy network between the endpoints. Due to network congestion concerns, the MESSAGE method has significant limitations in message size, a prohibition against overlapping requests, etc. Much of this has been required because of Campbell, et al. Expires November 20, 2003 [Page 4] Internet-Draft SIMPLE IM Sessions May 2003 perceived limitations in the congestion-avoidance features of SIP itself. Work is in progress to mitigate these concerns. However, session-mode messages are always sent over reliable, congestion-safe transports. Therefore, there are no restrictions on message sizes. There is no requirement to wait for acknowledgement, so that message transactions can be overlapped. Message sessions allow greater efficiency for secure message exchanges. The SIP MESSAGE request inherits the S/MIME features of SIP, allowing a message to be signed and/or encrypted. However, this approach requires public key operations for each message. With session-mode messaging, a session key can be established at the time of session initiation. This key can be used to protect each message that is part of the session. This requires only symmetric key operations for each subsequent IM, and no additional certificate exchanges are required after the initial exchange. The establishment of the session key can be done using standard techniques that apply to voice and video, in addition to instant messaging. Finally, SIP devices can treat message sessions like any other media sessions. Any SIP feature that can be applied to other sorts of media sessions can equally apply to message sessions. For example, conferencing [11], third party call control [12], call transfer [13], QoS integration [14], and privacy [15] can all be applied to message sessions. Messaging sessions can also reduce the overhead in each individual message. In pager-mode, each message needs to include all of the SIP headers that are mandated by RFC 3261 [2]. However, many of these headers are not needed once a context is established for exchanging messages. As a result, messaging session mechanisms can be designed with significantly less overhead. 3. Scope of this Document This document describes the use of MSRP between endpoints, or via one or two relays, where endpoints have advance knowledge of the relays. It does not provide a mechanism for endpoints to determine whether a relay is needed, or for endpoints to discover the presence of relays. This document describes the use of MSRP over TCP. MSRP may be used over other congestion-controlled protocols such as SCTP. However, the specific bindings for other such protocols are outside the scope of this document. 4. Protocol Overview Campbell, et al. Expires November 20, 2003 [Page 5] Internet-Draft SIMPLE IM Sessions May 2003 The Message Session Relay Protocol (MSRP) provides a mechanism for transporting session-mode messages between endpoints. MSRP also contains primitives to allow the use of one or two relay devices. MSRP uses connection oriented, reliable network transport protocols only. It is intrinsically NAT and firewall friendly, as it allows participants to positively associate message sessions with specific connections, and does not depend upon connection source address, which may be obscured by NATs. MSRP uses the following primitives: SEND: Used to actually send message content from one endpoint to another. VISIT: Used by an endpoint to establish a session association to the opposite endpoint, or to a relay that was selected by the opposite endpoint. BIND: Used by an endpoint to establish a session at a relay, and allow the opposite endpoint to visit that relay. The simplest use case for MSRP is a session that goes directly between endpoints, with no intermediaries involved. Assume A is an endpoint that wishes to establish a message session, and B is the endpoint invited by A. A invites B to participate in a message session by sending a URL that represents the session. This URL is temporary, and must not duplicate the URL used for any other active sessions. B "visits" A by connecting to A and sending a VISIT request containing the URL that A provided. This associates the connection from B with the session. B then responds to the invitation, informing A that B has accepted the session. A and B may now exchange messages using SEND requests on the connection. When either party wishes to end the session, it informs the peer party with a SIP BYE request. A terminates the session by invalidating associated state, and dropping the connection. The end to end case looks something like the following. (Note that the example shows a logical flow only; syntax will come later in this document.) A->B (SDP): offer (msrp://A/123) B->A (MSRP): VISIT (msrp://A/123) Campbell, et al. Expires November 20, 2003 [Page 6] Internet-Draft SIMPLE IM Sessions May 2003 A->B (MSRP): 200 OK B->A (SDP): answer(msrp://A/123) A->B (MSRP): SEND B->A (MSRP): 200 OK B->A (MSRP): SEND A->B (MSRP): 200 OK The state associated with the session will expire over time, based on an expiration time specified in the VISIT request. If the lifetime of the session is to exceed that expiration time, the visitor must update the expiration with a new VISIT request prior to expiration. A slightly more complicated case involves a single relay, known about in advance by one of the parties. The endpoint that has the preexisting relationship with the relay uses the BIND method to establish session state in the relay. The relay returns a temporary URL, that identifies the session. For endpoints A and B, and relay R, the flow would look like the following: A->R: MSRP: BIND(msrp://r) R->A: MSRP: 200 OK (msrp://r/4uye) A->B (SDP): offer (msrp://r/4uye) B->R (MSRP): VISIT (msrp://r/4uye) R->B (MSRP): 200 OK B->A (SDP): answer(msrp://r/4uye) A->R (MSRP): SEND R->B (MSRP): SEND B->R (MSRP): 200 OK R->A (MSRP): 200 OK B->R (MSRP): SEND Campbell, et al. Expires November 20, 2003 [Page 7] Internet-Draft SIMPLE IM Sessions May 2003 R->A (MSRP): SEND A->R (MSRP): 200 OK R->B (MSRP): 200 OK The BIND request contains an expiration time much the same as in VISIT. If the life of a relay-hosted session is to exceed the expiration value in the BIND request, the host endpoint will refresh the expiration time with a new BIND request prior to expiration. Additionally, when tearing down a session, the host endpoint invalidates the session state by issuing a BIND request with an expiration value of zero. 5. SDP Offer-Answer Exchanges for MSRP Sessions. MSRP sessions will typically be initiated using the Session Description Protocol (SDP) [1] offer-answer mechanism, carried in SIP [2] or any other protocol supporting it. MSRP borrows the idea of the direction attributes from COMEDIA [17], but does not depend on that specification. 5.1 Use of the SDP M-line The SDP m-line takes the following form: m= For non-RTP media sessions, The media field specifies the top level MIME media type for the session. For MSRP sessions, the media field MUST have the value of "message". The proto field MUST designate the message session mechanism and transport protocol, separated by a "/" character. For MSRP, left part of this value MUST be "msrp". For MSRP over TCP, the right part of this field MUST take the value "tcp". For MSRP over other transport protocols, the field value MUST be defined by the specification for that protocol binding. The format list MUST indicate the MIME content-types that the endpoint is willing to accept in the payload of SEND requests. If any of the allowed types are compound in nature, that is, they allow one or more arbitrary MIME body parts to be embedded within them, then the format list MUST include the content-types allowed for the embedded parts. If the final entry in the format list is a "*", this indicates that the endpoint is may be willing to receive other types as well, but the types listed explicitly are preferred. The format list in the SDP answer MUST be the same as, or a subset of, the list provided in the offer. Campbell, et al. Expires November 20, 2003 [Page 8] Internet-Draft SIMPLE IM Sessions May 2003 A "*" in the format list indicates that the sender may attempt to send messages with other media types that have not been explicitly listed. If the receiver is able to process the media type, it does so. If not, it will respond with a 415. Note that all explicit entries in the format list should be considered preferred over any non-listed types. This feature is needed as, otherwise, the format list for IM devices may be prohibitively large. The port field in the M-line is not used to determine the port to which to connect. Rather, the actual port is determined by the contents of the session URL. (Section 6.1). The following example illustrates an m-line for a CPIM message session, where the endpoint is willing to accept payloads of plain text or HTML, which may appear at the top level of the payload, or may be embedded inside a message/cpim body part. m=message 49232 msrp/tcp message/cpim text/plain text/html 5.2 The Direction Attribute Since MSRP uses connection oriented transport protocols, one goal of the SDP negotiation is to determine which participant initiates the transport connection. The direction attribute advertises whether the offerer or answerer wishes to initiate the connection, wishes the peer endpoint to initiate the connection, or doesn't care. The endpoint that accepts the connection, or has a relay accept the connection on its behalf, is said to "host" the session, and is known as the hosting endpoint. The endpoint that initiates the connection is said to "visit" the session, and is known as the visiting endpoint. The direction attribute is included in an SDP a-line, with a value taking the following syntax: direction = direction-label ":" role direction-label = "direction" role = active / passive / both active = "active" passive = "passive" both = "both" The values for the role field are as follows: Campbell, et al. Expires November 20, 2003 [Page 9] Internet-Draft SIMPLE IM Sessions May 2003 passive The endpoint wishes to host the session active The endpoint wishes the peer to host the session. both The endpoint is willing to act as either host or visitor. The SDP offer for an MSRP session MUST contain a direction attribute, which MAY take any of the defined values. If the offerer is capable of hosting the session, or can arrange for a relay to host the session on its behalf, then it SHOULD select "both". The endpoint SHOULD NOT select "active" unless it cannot host the session under any circumstances. The endpoint SHOULD NOT select "passive" unless it has no option but to host the session. The SDP answer also MUST contain a direction attribute, but its value choices are limited based on the value in the offer. If the offer contained "active", then the answerer MUST either select "passive" or reject the offer. Likewise, if the offer contained "passive", then the answerer MUST select"active" or reject the offer. If the offer contained "both", the answerer SHOULD select "active", but MAY select "passive" if local policy requires it to act as host. 5.3 URL Negotiations An MSRP session is identified by an MSRP URL, which is determined by the hosting endpoint, and negotiated in the SDP exchange. Any SDP offer or answer that creates a possibility that the sender will host the session, that is, contains a direction value of "passive" or "both", MUST contain an MSRP URL in a session attribute. This attribute has the following syntax: a=session: where is an MSRP or MSRPS URL as defined in Section 6.1. The visitor will use the session URL established by the host both to resolve the host address and port, and to identify the session when connecting. For MSRP sessions, the address field in the C-line and the port field in the M-line are not relevant, and MUST be ignored. The following example shows an SDP offer with a session URL of "msrp://example.com:7394/2s93i" c=IN IP4 useless.host.name m=message 7394 msrp/tcp text/plain a=direction:both a=session:msrp://example.com:7394/2s93i Campbell, et al. Expires November 20, 2003 [Page 10] Internet-Draft SIMPLE IM Sessions May 2003 The session URL MUST be a temporary URL assigned just for this particular session. It MUST NOT duplicate any URL in use for any other session hosted by the endpoint or relay. Further, since the peer endpoint will use the session URL to identify itself when connecting, it SHOULD be hard to guess, and protected from eavesdroppers. This will be discussed in more detail in the Security Considerations section. 5.4 Example SDP Exchange Endpoint A wishes to invite Endpoint B to a MSRP session. A offers the following session description containing the following lines: c=IN IP4 alice.example.com m=message 7394 msrp/tcp message/cpim text/plain text/html a=direction:both a=session:msrp://alice.example.com:7394/2s93i9 Endpoint B chooses to participate in the role of visitor, opens a TCP connection to alice.example.com:7394, and successfully performs a VISIT transaction passing the URL of msrp://alice.example.com:7394/ 2s93i9;. B indicates that it has accomplished this by answering with: c=IN IP4 dontlookhere m=message 7394 msrp/tcp message/cpim text/plain a=direction:active A may now send IMs to B by executing SEND transactions on the same connection on which B sent the VISIT request. 6. The Message Session Relay Protocol The Message Session Relay Protocol (MSRP) is a text based, message oriented protocol for the transfer of instant messages in the context of a session. MSRP uses the UTF8 character set. MSRP messages MUST be sent over reliable, congestion-controlled, connection-oriented transport protocols, such as TCP. 6.1 MSRP URLs MSRP sessions are identified by MSRP URLs. An MSRP URL follows a subset of the URL syntax in Appendix A of RFC2396 [4], with a scheme of "msrp": msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource] resource = 1*unreserved Campbell, et al. Expires November 20, 2003 [Page 11] Internet-Draft SIMPLE IM Sessions May 2003 The constructions for "userinfo", "hostport", and "unreserved" are detailed in RFC2396 [4]. An MSRP URL server part identifies the hosting device of an MSRP session. There is no default port for MSRP URLs. If the server part contains a numeric IP address, it MUST also contain a port. The resource part identifies a particular session at that host device. The absence of the resource part indicates a reference to an MSRP host device, but does not specifically refer to a particular session resource. Open Issue: Do we need a default port? Cullen points out it would at least be useful for firewall configuration. The server part will typically not contain a userinfo component, but MAY do so to indicate a user account for which the session is valid. Note that this is not the same thing as identifying the session itself. If a userinfo component exists, MUST be constructed only from "unreserved" characters, to avoid a need for escape processing. Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo part MUST NOT contain password information. The following is an example of a typical MSRP URL: msrp://host.example.com:8493/asfd34 6.2 MSRP URL Comparison MSRP URL comparisons MUST be performed according to the following rules: The host part is compared as case insensitive. If the port exists explicitly in either URL, then it must match exactly. Since there is no default port for MSRP, a URL with an explicit port is never equivalent to another with no port specified. The resource part is compared as case insensitive. A URL without a resource part is never equivalent to one that includes a resource part. Userinfo parts are not considered for URL comparison. Path normalization is not relevant for MSRP URLs. Escape normalization is not required, since the relevant parts are limited to unreserved characters. Campbell, et al. Expires November 20, 2003 [Page 12] Internet-Draft SIMPLE IM Sessions May 2003 6.3 Resolving MSRP Host Device An MSRP host device is identified by the server part of an MSRP URL. If the server part contains a numeric IP address and port, they MUST be used as listed.. If the server part contains a host name and a port, the connecting device MUST determine a host address by doing an A or AAAA DNS query, and use the port as listed. If the server part contains a host name but no port, the connecting device MUST perform the following steps: 1. Construct an SRV [6] query string by prefixing the host name with the service field "_msrp" and the protocol field ("_tcp" for TCP). For example, "_msrp._tcp.host.example.com". 2. Perform a DNS SRV query using this query string. 3. Select a resulting record according to the rules in RFC2782 [6]. Determine the port from the chosen record. 4. If necessary, determine a host device address by performing an A or AAAA query on the host name field in the selected SRV result record. If multiple A or AAAA records are returned, the first entry SHOULD be chosen for the initial connection attempt. This allows any ordering created in the DNS to be preserved. 5. If the connection attempt fails, the device SHOULD attempt to connect to the addresses returned in any additional A or AAAA records, in the order the records were presented. If all of these fail, the device SHOULD attempt to use any additional SRV records that may have been returned, following the normal rules for SRV record selection. Open Issue: We need to carefully consider the rules about A RR selection. I am sure there are others who understand this much better than I do. Ted pointed us to RFC1794, which if I understand correctly indicates that some systems may attempt to load balance by controlling the order in which A RRs are presented. Attempts to randomize selection by the client could distort any such control. Note that in most cases, the transport protocol will be determined separately from the resolution process. For example, if the MSRP URL was communicated in an SDP offer or answer, the SDP M-line will contain the transport protocol. When an MSRP URL is communicated outside of SDP, the protocol SHOULD also be communicated. For Campbell, et al. Expires November 20, 2003 [Page 13] Internet-Draft SIMPLE IM Sessions May 2003 example, a client may be configured to use a particular relay that is referenced with an MSRP URL. The client MUST also be told what protocol to use. If a device needs to resolve an MSRP URL and does not know the protocol, it SHOULD assume TCP. Open Issue: Do we need to do an NAPTR query to determine the protocol? 6.3.1 The msrps URL Scheme The "msrps" URL Scheme indicates that each hop MUST be secured with TLS. Otherwise, it is used identically as an MSRP URL, except that a MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS scheme is further discussed in the Security Considerations section. 6.4 MSRP messages MSRP messages are either requests or responses. Requests and responses are distinguished from one another by the first line. The first line of a Request takes the form of the request-start entry below. Likewise, the first line of a response takes the form of response-start. The syntax for an MSRP message is as follows: Campbell, et al. Expires November 20, 2003 [Page 14] Internet-Draft SIMPLE IM Sessions May 2003 msrp-message = request-start/response-start *(header CRLF) [CRLF body] request-start = "MSRP" SP length SP Method CRLF response-start= "MSRP" SP length SP Status-Code SP Reason CRLF length = 1*DIGIT ; the length of the message, exclusive of the start line. Method = SEND / BIND / VISIT header = Client-Authenticate / Server-Challenge / Transaction-ID / Session-URL/ Content-Type / Expires Status-Code = 200 ;Success / 400 ;Bad Request / 401 ;Authentication Required / 403 ;Forbidden / 415 ;Unsupported Content Type / 481 ;No session / 500 ;Cannot Deliver / 506 ;duplicate session Reason = token ; Human readable text describing status Client-Authenticate = "CAuth" credentials Server-Challenge = "SChal" ":" challenge Transaction-ID = "Tr-ID" ":" token Content-Type = "Content-Type" ":" quoted-string Session-URL = "S-URL" ":" msrp_url Expires = "Exp"":" delta-seconds delta-seconds= 1*DIGIT ; Integer number of seconds All requests and responses MUST contain at least a TR-ID header field. Messages MAY contain other fields, depending on the method or response code. 6.5 MSRP Transactions An MSRP transaction consists of exactly one request and one response. A response matches a transaction if it share the same TR-ID value, and arrives on the same connection on which the transaction was sent. BIND is always hop by hop. VISIT transactions are usually hop-by-hop, but may be relayed in situations where the visiting endpoint uses a relay. However, SEND transactions are end to end, meaning that under normal circumstances the response is sent by the peer endpoint, even if there are intervening relays. Endpoints MUST select TR-ID header field values in requests so that they are not repeated by the same endpoint in scope of the given session. TR-ID values SHOULD be globally unique. The TR-ID space of each endpoint is independent of that of its peer. Endpoints MUST NOT infer any semantics from the TR-ID header field beyond what is stated Campbell, et al. Expires November 20, 2003 [Page 15] Internet-Draft SIMPLE IM Sessions May 2003 above. In particular, TR-ID values are not required to follow any sequence. MSRP Transactions complete when a response is received, or after a timeout interval expires with no response. Endpoints MUST treat such timeouts in exactly the same way they would treat a 500 response. The size of the timeout interval is a matter of local policy. 6.6 MSRP Sessions AN MSRP session is a context in which a series of instant messages are exchanged, using SEND requests. A session has two endpoints (a host and a visitor) and may have one or two relays. A session is identified by an MSRP URL. 6.6.1 Initiating an MSRP session When an endpoint wishes to engage a peer endpoint in a message session, it invites the peer to communicate using an SDP offer, carried over SIP or some other protocol supporting the SDP offer/ answer model. For the purpose of this document, we will refer to the endpoint choosing to initiate communication as the offerer, and the peer being invited as the answerer. The offerer SHOULD volunteer to act as the hosting endpoint if allowed by policy and network topology. An endpoint is said to host a session if one of two conditions are true. The host either directly listens for a connection from the peer endpoint, and maintains session state itself, or it uses a BIND request to initialize session state at a relay that will listen for a connection from the peer. The peer that is not the host is designated as the visitor. The offerer MAY request the answerer to act as host if it is prevented from accepting connections by network topology or policy, and is not able to bind to a relay to act on its behalf. If the offerer wishes to host the session directly, that is without using a relay, it MUST perform the following steps: 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. 2. Listen for a connection from the peer. 3. Construct an SDP offer as described in Section 5, including the list of allowed IM payload formats in the format list. The offerer maps the session URL to the session attribute, as Campbell, et al. Expires November 20, 2003 [Page 16] Internet-Draft SIMPLE IM Sessions May 2003 described in Section 5.3. 4. Insert a direction attribute. This value SHOULD be "both", indicating that the offerer will allow the answerer to override the offerer's decision to host. The value MAY be "passive" if the offerer is prevented from allowing the answerer override this choice. 5. Send the SDP offer using the normal processing for the signaling protocol. If the offerer chooses to force the answerer to host the session, it MUST perform the following steps instead: 1. Construct an SDP offer as described above, but with no session attribute. 2. Insert a direction attribute with a value of "active". 3. Send the offer using normal processing for the signaling protocol. When the answerer receives the SDP offer and chooses to participate in the session, it must choose whether of act as the host or the visitor. A direction attribute value of "both" in the offer indicates that the offerer wishes to host, but will allow the answerer to host, in which case the answerer SHOULD act as the visitor, but MAY choose to host. A value of "passive" means the offerer insists upon hosting, in which case the answerer MUST act as visitor or decline the offer. If the answerer chooses to participate as a visitor, it MUST perform the following steps: 1. Determine the host address and port from the session URL, following the procedures in section Section 6.1 2. Connect to the host address and port, using the transport protocol from the M-line. 3. Construct a VISIT request, which MUST contain the following information: 1. An S-URL header field containing the session URL. 2. A TR-ID header field containing a unique transaction ID. 3. An Exp header field containing the expiration time for the VISIT request. Campbell, et al. Expires November 20, 2003 [Page 17] Internet-Draft SIMPLE IM Sessions May 2003 4. A size field containing size of the message subsequent to the start-line. 4. Send the request and wait for a response 5. If the transaction succeeds, set the actual expiration time to the value in the Exp header field in the response, and send a SDP answer via the signaling protocol, according to the following rules: 1. The C-line is copied unmodified from the offer. 2. The M-Line contains a dummy port value, the protocol field from the original offer, and a format list describing the SEND payload media types that the answerer is willing to accept. The format list in the answer MUST be either the same as the format list in the offer, or a subset. 3. A direction attribute containing the value "active". 6. If the transaction fails, the answerer MAY choose to act as host, if allowed by the direction attribute of the answer. If the answerer is unable or unwilling to host, then it should return an error response as appropriate for the signaling protocol. If the answerer chooses to host the session, it MUST perform the following steps: 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. 2. Listen for a connection from the peer. 3. Construct an SDP answer as described in Section 5, mapping the new session URL to the session attribute, and inserting a direction attribute with the value of "passive". 4. Send the SDP offer using the normal processing for the signaling protocol. When the offerer receives the SDP answer, it must determine who will continue to host the session. If the answer contained a direction attribute value of "active", the offerer MUST continue as host. If the offer contained "active" or "both" and the answer contains "passive", then the offerer MUST allow the answerer to host the Campbell, et al. Expires November 20, 2003 [Page 18] Internet-Draft SIMPLE IM Sessions May 2003 session. If the offerer chooses not to continue as host, it MUST perform the following steps: 1. Release resources it acquired in expectation of hosting the session, if any. 2. Determine the host address and port from the session URL of the answer, following the procedures in section Section 6.1 3. Connect to the host address and port, using the transport protocol from the M-line. 4. Construct a VISIT request, which MUST contain the following information: 1. A S-URL header field containing the session URL. 2. A TR-ID header field containing a unique transaction ID. 3. An Exp header field containing the expiration time for the VISIT request. 4. A size field containing size of the message subsequent to the start-line. 5. Send the request and wait for a response 6. If the transaction succeeds, set the actual expiration time to the value in the Exp header field in the response, and acknowledge the answer via the signaling protocol. If either the connection attempt or the VISIT transaction fail, acknowledge the answer, then initiate the tear-down of the session using the signaling protocol. 6.6.2 Handling VISIT requests An MSRP endpoint that is hosting a session will receive a VISIT request from the visiting endpoint. When an endpoint receives a VISIT request, it MUST perform the following procedures: 1. Check if state exists for a session with a URL that matches the S-URL of the VISIT request. If so, and if no visitor connection has been associated with the session, determine the expiration time according to the procedures in Section 6.8, then return a 200 response, and save state designating the connection on which Campbell, et al. Expires November 20, 2003 [Page 19] Internet-Draft SIMPLE IM Sessions May 2003 the request was received as the visitor leg of the session. 2. If the session exists, and the visitor connection has already been established, and the request arrived on the existing visitor connection, treat the request as a refresh, as described in Section 6.8. If the request arrived on a different connection, return a 506 response and do not change session state in any way. 3. If no matching session exists, return a 481 request, and do not change session state in any way. 6.6.3 Sending Instant Messages on a Session Once a MSRP session has been established, either endpoint may send instant messages to its peer using the SEND method. When an endpoint wishes to do so, it MUST construct a SEND request according to the following process: 1. Insert the message payload in the body, and the media type in the Content-Type header field. The media type MUST match one of the types in the format list negotiated in the SDP exchange. If a "*" is present in the format list, then the media type SHOULD match one of the explicitly listed entries, but MAY be any other arbitrary value. 2. Set the TR-ID header field to a unique value. 3. Send the request on the connection associated with the session. 4. If a 2xx response code is received, the transaction was successful. 5. If a 5xx response code is received, the transaction failed, but may possibly be successful if retried. The endpoint MAY retry the request as a new transaction, that is, with a new TR-ID value. If the endpoint receives 5xx responses more than some threshold number of times in a row, it SHOULD assume the session has failed, and initiate tear-down via the signaling protocol. The threshold value is a matter of local policy. 6. If a 415 response is received, this indicates the recipient is unable or unwilling to process the media type. The sender SHOULD NOT attempt to send that particular media type again in the context of this session. 7. If any other response code is received, the endpoint SHOULD assume the session has failed, and initiate tear-down. Campbell, et al. Expires November 20, 2003 [Page 20] Internet-Draft SIMPLE IM Sessions May 2003 When an endpoint receives a SEND request, it MUST perform the following steps. 1. Determine that it understands the media type in the body, if any exists. 2. If it does, return a 200 response and render the message to the user. The method of rendering is a matter of local policy. 3. If it does not understand the media type, return a 415 response. 6.6.3.1 Ending a Session When either endpoint in an MSRP session wishes to end the session, it first signals its intent using the normal processing for the signaling protocol. For example, in SIP, it would send a BYE request to the peer. After agreeing to end the session, the host endpoint MUST release any resources acquired as part of the session. The process for this differs depending on whether the session is hosted directly by the host, or an a relay. The host MUST destroy local state for the session. This involves completely removing the state entry for this session and invalidating session URL. If the host is using an MSRP relay, it MUST send a BIND containing an expires value of zero. This request MUST be sent host connection established by the original BIND request. This BIND request MUST include the session URL in the S-URL header field. Since these host actions completely destroy the session state at the hosting device, the visitor is not required to take further action beyond cleaning up any local state. If for some reason the host fails to destroy session state, the state will be invalidated anyway when either of the original BIND or VISIT requests expire. 6.6.4 Managing Session State and Connections A MSRP session is represented by state at the host device. As mention previously, session state is identified by an MSRP URL. An active session also has two associated network connections. The connection hosting device and the host endpoint is known as the host connection. The connection with the visiting endpoint is the visiting connection. Note that when the session state is hosted directly by an endpoint, the host connection may not involve a physical network connection; rather it is a logical connection the device maintains with itself. When session state is destroyed for any reason, the hosting device Campbell, et al. Expires November 20, 2003 [Page 21] Internet-Draft SIMPLE IM Sessions May 2003 SHOULD drop the connection(s). If a connection fails for any reason, the session hosting device MUST invalidate the session state. This is true regardless of whether the dropped connection is the host or visiting connection. Once a connection is dropped, the associated session state MUST NOT be reused. If the endpoints wish to continue to communicate after a connection failure, they must initiate a new session. An endpoint detecting a connection failure SHOULD attempt to tear down the session using the rules of the signaling protocol. It would be nice to allow sessions to be recovered after a connection failure, perhaps by allowing the opposite endpoint to reconnect, and send a new VISIT or BIND request. However, this approach creates a race condition between the time that the hosting device notices the failed connection, and the time that the endpoint tries to recover the session. If the endpoint attempts to reconnect prior to the hosting device noticing the failure, the hosting device will interpret the recovery attempt as a conflict. The only way around this would be to force the hosting device to do a liveness check on the original connection, which would create a lot of complexity and overhead that do not seem to be worth the trouble. 6.7 MSRP Relays 6.7.1 Establishing Session State at a Relay An endpoint that wishes to host a MSRP session MAY do so by initiating session state at a MSRP relay, rather than hosting directly. An endpoint may wish to do this because network topology or local policy prevents a peer from connecting directly to the endpoint. The use of a relay should not be the default case, that is, a hosting endpoint that is not prevented from doing so by topology or policy SHOULD host the session directly. In order to use a relay, an MSRP endpoint MUST have knowledge of that relay's existence and location.. We previously mentioned how an endpoint wishing to host a MSRP session constructs session URL. When using a relay, the endpoint delegates that responsibility to the relay. To establish session state at a relay, the endpoint MUST perform the following steps: 1. Open a network connection to the relay at the relays address and the well-known port for MSRP relays, or at another port if so Campbell, et al. Expires November 20, 2003 [Page 22] Internet-Draft SIMPLE IM Sessions May 2003 configured. 2. Construct a BIND request with a S-URL that refers to the relay. 3. Set the Expire header field to a desired value. 4. Send the BIND request on the connection. 5. Respond to any authentication request from the relay. 6. If the response has a 2xx status code, use the URL in the S-URL header field as the session URL. The endpoint uses this URL in exactly the same manner as it had constructed it itself. Additionally, accept the expires value in the response as session expiration time. A MSRP relay listens for connections to its well-known port at all times. When it receives a BIND request, it SHOULD authenticate the request, either using digest-authentication, TLS authentication, or some other authentication mechanism. If authentication succeeds, the relay performs the following steps: 1. Verify the client is authorized to BIND to this relay. If not, return a 403 response and make no state change. 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. 3. Establish the expiration time for the session according to section Section 6.8. 4. Create state for the session. The relay MUST associate the connection on which the BIND request arrived as the host connection for the session. 5. Return a 200 response, with the session URL in the S-URL header field, and the session expiration time in the Exp header field.. When an MSRP relay receives a VISIT request, it MUST perform the following steps: 1. Check the S-URL header field value to see it matches the URL for an existing session state entry. Campbell, et al. Expires November 20, 2003 [Page 23] Internet-Draft SIMPLE IM Sessions May 2003 2. If not, return a 481 response and make no state changes 3. If it matches, but another connection has already been associated with the session URL, return a 506 response and make no state changes. If the session has been previously associated with this connection, treate the request as a refresh. 4. If it matches, and no visiting connection has been previously associated with the session, then the VISIT succeeds. The relay assigns the connection on which it received the VISIT request as the visiting connection for the session, and returns a 200 response. The visit expiration time is established as described in Section 6.8 and returned in the response. 6.7.2 Removing Session State from a relay An MSRP relay SHOULD remove state for a session when any of the following conditions occur: o The expiration time for either the BIND or VISIT is reached without a respective refresh request. o The host sends a BIND refresh request matching with an expiration value of zero. o Either the host or visitor network connection fails for any reason. 6.7.3 Sending IMs across an MSRP relay Once a session is established at a relay, the host and visitor may exchange IMs by sending SEND requests. Under normal circumstances, the relay does not respond to SEND requests in any way. Rather, the relay MUST forward the request to the peer connection unchanged. Likewise, if the relay receives a response it MUST forward the request unchanged on the peer connection. If a SEND request arrives on a connection that is not associated with a session, the relay MUST return a 481 response. 6.7.4 Relay Pairs In rare circumstances, two relays may be required in a session. For example, two endpoints may exist in separate administrative domains, where each domain's policy insist that all sessions must cross that domain's relay. A relay operating on behalf of the visiting endpoint Campbell, et al. Expires November 20, 2003 [Page 24] Internet-Draft SIMPLE IM Sessions May 2003 is known as a visiting relay. An MSRP relay MAY be capable of acting as a visiting relay. In a two relay scenario, the visitor connects to a relay operating on its behalf, rather than connecting directly to the hosting device. The visitor sends a VISIT request as it would if it had connected directly to the hosting device. The visiting relay then connect to the hosting device and performs a VISIT request on behalf of the visitor. When a relay that is capable of acting as a visiting relay receives a VISIT request, it MUST check to see if the S-URL of the request matches a domain that the relay hosts. If the URL matches, then the visitor is not requesting the relay act as a visiting relay, and it SHOULD operate normally. If the URL does not match, then the relay SHOULD perform the following steps: 1. The relay SHOULD authenticate the VISIT request, using digest authentication or some other mechanism. 2. Determine that the visiting endpoint is authorized to use this device as a visiting relay. If not, return a 403 response and drop the connection. 3. Attempt to open a connection to the hosting device, determining the address and port from the S-URL exactly as if it were a visiting endpoint connecting directly. If this connection is successful, continue with the remaining steps. Otherwise, return a 500 response. 4. Create local state to associate the connection to the host device with the connection to the visiting device. 5. Relay the VISIT request unchanged to the hosting device. 6. Relay the response to the VISIT request unchanged to the visiting endpoint. If the response is a 200, set the expiration time for the local session state to the value in the Exp header in the response. 7. Relay all subsequent arriving on one of the associated connections to the peer connection. The preceding steps result in local session state that expires based on the expiration time negotiated between the visiting endpoint and the hosting device. The visiting endpoint will send VISIT requests on the same connection from time to time to refresh the session state expiration time. A visiting relay MUST refresh the local expiration Campbell, et al. Expires November 20, 2003 [Page 25] Internet-Draft SIMPLE IM Sessions May 2003 time based on the Exp header field value in a successful response to such a VISIT request. If the local expiration time passes without a refresh, the visiting relay SHOULD invalidate the session state and SHOULD drop the associated connections. If either associated connection fails for any reason, the visiting relay SHOULD invalidate the session state, and SHOULD drop the peer connection. 6.8 Session State Expiration State associated with MSRP sessions, either at the host endpoint or a host relay, is soft-state; that is, it expires over time unless refreshed. The expiration time is determined by the Expires header field in VISIT and BIND requests. All VISIT and BIND requests MUST contain an Expires header field. This field is defined as an integer number of seconds from the time that the request is received. When a hosting device (endpoint or relay) creates session state due to a successful VISIT request, it SHOULD accept the Expires value from the request, although it MAY choose a smaller value. It MUST NOT choose a larger value. The device MUST communicate the actual chosen value back to the opposite endpoint by placing the value in an expires header field in the response. Likewise, when a relay creates session state due to a successful BIND request, it SHOULD accept the expires value from the request, although it MAY choose a smaller value. It MUST NOT choose a larger value. The device MUST communicate the actual chosen value back to the opposite endpoint by placing the value in an Expires header field in the response. A visiting relay does not normally respond to a VISIT request. Rather, it relays the request to the hosting device, and relays the resulting response back to the visiting endpoint. This prevents it from being able to negotiate the expiration time in the same way as hosting devices. Therefore, a visiting relay MUST determine session expiration time from the Exp header field in any 200 response returned by the hosting device. 6.9 Digest Authentication MSRP relays may use the digest authentication scheme to authenticate users. MSRP digest authentication is a simplified version of HTTP digest authentication [18], but this specification does not normatively depend on that document. MSRP digest authentication does not support the concept of a protection domain, nor does it support integrity protection. Since a user of a relay is expected to have Campbell, et al. Expires November 20, 2003 [Page 26] Internet-Draft SIMPLE IM Sessions May 2003 credentials for that particular relay, it does not support the realm concept. Finally, since digest authentication is only expected for the initial BIND or VISIT request, MSRP does not support HTTP digest optimizations such as MD5-sess and preemptive credential loading by the client. Typically, a hosting user that uses a relay will have a preexisting relationship with that relay. This relationship SHOULD include authentication credentials. An MSRP relay SHOULD authenticate initial BIND requests. It is less likely that the visiting user will have an account at the hosting relay, so in many cases the authentication of VISIT requests is not useful. However a relay MAY authenticate initial VISIT requests. A visiting relay SHOULD authenticate initial VISIT requests, as it is much more likely to share credentials with the visiting user. There has been some discussion that a hosting relay SHOULD also authenticate VISIT requests. However, it will be very common for visiting users to have no preexisting relationship with the host relay. Using authentication here would require the host endpoint to send temporary credentials in the SDP exchange, perhaps as part of the session URL. However, these temporary credentials would necessarily be transferred via the same channels as the session URL itself. If the credentials are sufficiently protected in transfer, then so is the session URL. Further, since the session URL is intended for a one time use, and is expected to be hard to guess, that URL itself may be sufficient for this purpose. MSRP relays MUST NOT request authentication for any method other than BIND and VISIT. If a relay wishes to authenticate a request using digest authentication, it MAY challenge the request by responding with a 401 response, which MUST include a SChal header field. If an endpoint wishes to respond to a digest authentication challenge received in a 401 response, it MAY do so by sending a new VISIT or BIND request, identical to the previous request, but with a CAuth header field containing the response to the challenge. 6.9.1 The MD5 Algorithm The only digest authentication algorithm defined in this specification is MD5. [8] Other algorithms can be added as extensions. MD5 is the default algorithm if no algorithm directive is present in the challenge. Campbell, et al. Expires November 20, 2003 [Page 27] Internet-Draft SIMPLE IM Sessions May 2003 The MD5 algorithm is defined as follows: Let KD(secret, data) denote the string obtained by performing the digest algorithm to the data "data" with the secret "secret". Let H(data) denote the string obtained by performing the checksum algorithm on the data "data". For the "MD5" algorithm, H(data) = MD5(data), and KD(secret,data) = H(concat(secret, ":", data) The request-digest value in a CAuth header field takes the following format. Note that unq(quoted-string) denotes the value of the string with the quotes removed. request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <"> A1 = unq(username-value) ":" shared-secret A2 = Method When the relay receives a CAuth header, it SHOULD check its validity by looking up the shared secret, or H(A1), performing the same digest operation as performed by the client, and comparing the results to the request-digest value. 6.10 Method Descriptions This section summarizes the purpose of each MSRP method. All MSRP messages MUST contain the TR-ID header fields. All messages MUST contain a length field in the start line that indicates the overall length of the request, including any body, but not including the start line itself. Additional requirements exist depending on the individual method. Except where otherwise noted, all requests are hop by hop. 6.10.1 BIND The BIND method is used by a host endpoint to establish or refresh session state at a hosting relay. BIND requests SHOULD be authenticated. BIND requests MUST contain the S-URL and Exp header fields and MAY contain the CAuth header fields. A successful response to a BIND request MUST contain the S-URL and Exp header fields. 6.10.2 SEND The SEND method is used by both the host and visitor endpoints to send instant messages to its peer endpoint. SEND requests SHOULD contain a MIME body part. The body MUST be of a media type included Campbell, et al. Expires November 20, 2003 [Page 28] Internet-Draft SIMPLE IM Sessions May 2003 in the format list negotiated in the SDP exchange. If a body is present, the request MUST contain a Content-Type header field identifying the media type of the body. Unlike other methods, SEND requests are end to end in nature. This means the request is consumed only by the opposite endpoint. Under normal conditions, any intervening relays merely forward the request on towards the peer endpoint. 6.10.3 VISIT The visiting endpoint uses the VISIT method to associate a network connection with the session state at the hosting device, which could be either the host endpoint or a relay operating on behalf of the host endpoint. VISIT is also used to refresh the expiration time for the visiting connection. The request MUST contain a S-URL header matching the session URL. A VISIT request MUST contain the Expires header field. Successful responses to a VISIT request MUST contain the Expires header. There is normally no authentication operation for the VISIT request. This is because the session URL acts as a shared secret between host and the visitor. This puts certain requirements on the handling of the session URLs that are discussed in Section 9. However, if a visiting relay is used, it SHOULD authenticate initial VISIT requests, and MAY authenticate subsequent VISIT refresh requests. 6.11 Response Code Descriptions This section summarizes the various response codes. Except where noted, all responses MUST contain a TR-ID header field matching the TR-ID header field of the associated request. Responses are never consumed by relays. 6.11.1 200 The 200 response code indicates a successful transaction. 6.11.2 400 A 400 response indicates a request was unintelligible. 6.11.3 401 Campbell, et al. Expires November 20, 2003 [Page 29] Internet-Draft SIMPLE IM Sessions May 2003 A 401 response indicates authentication is required. 401 responses MUST NOT be used in response to any method other than BIND and VISIT. A 401 response MUST contain a SChal header field. 6.11.4 403 A 403 response indicates the user is not authorized to perform the action. 6.11.5 415 A 415 response indicates the SEND request contained a MIME content-type that is not understood by the receiver. 6.11.6 481 A 481 response indicates that no session exists for the connection. 6.11.7 500 A 500 response indicates that a relay was unable to deliver a SEND request to the target. 6.11.8 506 A 506 response indicates that a VISIT request occurred in which the S-URL indicates a session that is already associated with another connection. A 506 response MUST NOT be returned in response to any method other than VISIT. 6.12 Header Field Descriptions This section summarizes the various header fields. MSRP header fields are single valued; that is, they MUST NOT occur more than once in a particular request or response. 6.12.1 TR-ID The TR-ID header field contains a transaction identifier used to map a response to the corresponding request. A TR-ID value MUST be unique among all values used by a given endpoint inside a given session. MSRP elements MUST NOT assume any additional semantics for TR-ID. 6.12.2 Exp The Exp header field specifies when the state associated with a BIND or VISIT request will expire. The value is specified as an integer number of seconds from the time the request is received. BIND and Campbell, et al. Expires November 20, 2003 [Page 30] Internet-Draft SIMPLE IM Sessions May 2003 VISIT requests MUST contain this header field. Furthermore, successful responses to BIND or VISIT requests must also contain the Exp header. The maximum value for the Exp header field is (2**32)-1 seconds. Exp has no meaning if it occurs in MSRP messages other than BIND and VISIT requests, and responses to those requests. MSRP compliant devices SHOULD NOT use Exp in other requests or responses, unless that usage is defined in an extension to this specification. 6.12.3 CAuth The CAuth header field is used by a host endpoint to respond to offer digest authentication credentials to a relay, usually in response to a digest authentication challenge. CAuth SHOULD NOT be present in a request of any method other than BIND and VISIT. The CAuth credentials adhere to the following syntax: credentials = "Digest" digest-response digest-response = 1#( username | nonce | response | [ algorithm ] | [auth-param] ) username = "username" "=" username-value username-value = quoted-string response = "response" "=" request-digest request-digest = <"> 32LHEX <"> LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" The meaning of each value is as follows: username: The user's account name. nonce: The nonce value copied from the challenge. response: A 32 hex digit string that proves user knowledge of the shared secret. algorithm: The algorithm value copied from the challenge. auth-param: Additional parameters for the sake of extensibility. Campbell, et al. Expires November 20, 2003 [Page 31] Internet-Draft SIMPLE IM Sessions May 2003 6.12.4 SChal The SChal header field is used by a relay to carry the challenge in a digest authentication attempt. Exactly one SChal header field MUST exist in a 401 response. The SChal header MUST NOT be used in any message except for a 401 response. The SChal header field value is made up of a challenge according to the following syntax: challenge= digest-scheme SP digest-challenge digest-scheme = "Digest" digest-challenge = 1#( nonce | [ algorithm ] | [auth-param] ) nonce = "nonce" "=" nonce-value nonce-value = quoted-string algorithm = "algorithm" "=" ( "MD5" | token ) The meaning of each value is as follows: digest scheme: A token to identify the particular authentication scheme. For digest, the value MUST be "Digest." This token is present for the sake of extensibility. nonce: A server-specified string, which the relay SHOULD uniquely generate each time it sends a 401 response. This string SHOULD take the form of base64 or hexadecimal data, to avoid the presence of a double-quote character, which is not allowed. algorithm: A token indicating the algorithms to be used to generate the digest and checksum. This directive exists for the sake of extensibility; the only value defined by this document is "MD5". absence of this directive indicates a value of "MD5." 6.12.5 Content-Type The Content-Type header field is used to indicate the MIME media type of the body. Content-Type MUST be present if a body is present. 6.12.6 S-URL The S-URL header field is used to identify the session. The S-URI header field MUST be present in a BIND request, a successful response to a BIND request, or a VISIT request. 7. Examples Campbell, et al. Expires November 20, 2003 [Page 32] Internet-Draft SIMPLE IM Sessions May 2003 This section shows some example message flows for various common scenarios. The examples assume SIP is used to transport the SDP exchange. Details of the SIP messages and SIP proxy infrastructure are omitted for the sake of brevity. In the examples, assume the offerer is sip:alice@atlanta.com and the answerer is sip:bob@biloxi.com. In any given MSRP message, an "xx" in the length field indicates the actual length of the rest of the message. 7.1 No Relay 1. Alice constructs a session URL of msrp://alicepc.atlanta.com/ iau39 and listens for a connection on TCP port 7777. 2. Alice->Bob (SIP): INVITE sip:bob@biloxi.com c=IN IP4 fillername m=message 7777 msrp/tcp text/plain a=direction:both a=session:msrp://alicepc.atlanta.com/iau39:7777 3. Bob->Alice: Open TCP connection to alicepc.atlanta.com:7777. 4. Bob->Alice (MSRP): MSRP xx VISIT S-URL: msrp://alicepc.atlanta.com/iau39:7777 Tr-ID: sie09s Exp:600 5. Alice->Bob (MSRP): MSRP xx 200 OK Tr-ID: sie09s Exp:300 6. Bob->Alice (SIP): 200 OK c=IN IP4 ignorefield m=message 7777 msrp/tcp text/plain a=direction:active 7. Alice->Bob (SIP): ACK 8. Alice->Bob (MSRP): Campbell, et al. Expires November 20, 2003 [Page 33] Internet-Draft SIMPLE IM Sessions May 2003 MSRP xx SEND TR-ID: 123 Content-Type: "text/plain" Hi, I'm Alice! 9. Bob->Alice (MSRP): MSRP xx 200 OK TR-ID: 123 10. Bob->Alice (MSRP): MSRP xx SEND TR-ID: 456 Content-Type: "text/plain" Hi, Alice! I'm Bob! 11. Alice->Bob (MSRP): MSRP xx 200 OK TR-ID: 456 12. Alice->Bob (SIP): BYE 13. Alice invalidates session and drops connection. 14. Bob invalidates local state for the session. 15. Bob->Alice (SIP): 200 OK 7.2 Single Relay This scenario introduces an MSRP relay at relay.atlanta.com. 1. Alice->Relay (MSRP): Alice opens a connection to the relay, and sends the following: MSRP xx BIND S-URL: msrp://relay.atlanta.com TR-ID: 321 Exp:600 Campbell, et al. Expires November 20, 2003 [Page 34] Internet-Draft SIMPLE IM Sessions May 2003 2. Relay->Alice (MSRP): MSRP xx 200 OK TR-ID: 321 S-URL: msrp://relay.atlanta.com:7777/iau39 Exp:300 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com c=IN IP4 dummyvalue m=message 7777 msrp/tcp text/plain a=direction:passive a=session:msrp://relay.atlanta.com:7777/iau39 4. Bob->Alice: Open connection to relay.atlanta.com:7777. 5. Bob->Relay (MSRP): MSRP xx VISIT S-URL:msrp://relay.atlanta.com:7777/iau39 TR-ID: msrp:sie09s Exp:500 6. Relay->Bob (MSRP): MSRP xx 200 OK TR-ID: sie09s Exp:300 7. Bob->Alice (SIP): 200 OK c=IN IP4 nobodybutchickens m=message 7777 msrp/tcp text/plain a=direction:active 8. Alice->Bob (SIP): ACK 9. Alice->Relay (MSRP): MSRP xx SEND TR-ID: 123 Content-Type: "text/plain" Hi, I'm Alice! Campbell, et al. Expires November 20, 2003 [Page 35] 10. Relay->Bob (MSRP): MSRP xx SEND TR-ID: 123 Content-Type: "text/plain" Hi, I'm Alice! 11. Bob->Relay (MSRP): MSRP xx 200 OK TR-ID: 123 12. Relay->Alice (MSRP): MSRP xx 200 OK TR-ID: 123 13. Bob->Relay (MSRP): MSRP xx SEND TR-ID: 456 Content-Type:"text/plain" Hi, Alice! I'm Bob! 14. Relay->Alice (MSRP): MSRP xx SEND TR-ID: 456 Content-Type: "text/plain" Hi, Alice! I'm Bob! 15. Alice->relay (MSRP): MSRP xx 200 OK TR-ID: 456 16. Relay->Bob (MSRP): MSRP xx 200 OK TR-ID: 456 Campbell, et al. Expires November 20, 2003 [Page 36] Internet-Draft SIMPLE IM Sessions May 2003 17. Alice->Bob (SIP): BYE 18. Alice->Relay (MSRP): MSRP xx BIND S-URL: msrp://relay.atlanta.com:7777/iau39 TR-ID: 42 Exp:0 19. Relay->Alice (MSRP): (relay invalidates session state) MSRP xx 200 OK TR-ID: 42 Exp:0 20. Bob invalidates local state for the session. 21. Bob->Alice (SIP): 200 OK 7.3 Two Relays In this scenario, both Alice and Bob are each required by local policy to route all sessions through a different local relay. 1. Alice->AtlantaRelay (MSRP): Alice opens a connection to the relay, and sends the following: MSRP xx BIND S-URL: msrp://relay.atlanta.com TR-ID: 321 Exp:600 2. AtlantaRelay->Alice (MSRP): MSRP xx 200 OK TR-ID: 321 S-URL: msrp://relay.atlanta.com:7777/iau39 Exp:600 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com c=IN IP4 blahblahblah m=message 7777 msrp/tcp text/plain Campbell, et al. Expires November 20, 2003 [Page 37] Internet-Draft SIMPLE IM Sessions May 2003 a=session:msrp://relay.atlanta.com:7777/iau39 a=direction:passive 4. Bob determines that, due to local policy, he must connect through his own proxy. 5. Bob->BiloxiRelay (MSRP): Bob opens a connection to his relay, and sends the following: MSRP xx VISIT S-URL: msrp://relay.atlanta.com:7777/iau39 TR-ID: 934 Exp:600 6. BiloxiRelay->AtlantaRelay (MSRP): BiloxiRelay resolves the URL, opens a connection to relay.atlanta.com:7777, and sends the following: MSRP xx VISIT S-URL: msrp://relay.atlanta.com:7777/iau39 TR-ID: 934 Exp:600 7. AtlantaRelay->BiloxiRelay(MSRP): MSRP xx 200 OK TR-ID: 934 Exp:600 8. BiloxiRelay->Bob(MSRP): MSRP xx 200 OK TR-ID: 934 Exp:600 9. Bob->Alice (SIP): 200 OK c=IN IP4 stuff m=message 7777 msrp/tcp text/plain a=direction: active 10. Alice->Bob (SIP): ACK Campbell, et al. Expires November 20, 2003 [Page 38] 11. Alice->AtlantaRelay (MSRP): MSRP xx SEND TR-ID: 123 Content-Type: "text/plain" Hi, I'm Alice! 12. AtlantaRelay ->BiloxiRelay (MSRP): MSRP xx SEND TR-ID: 123 Content-Type: "text/plain" Hi, I'm Alice! 13. BiloxiRelay->Bob (MSRP): MSRP xx SEND TR-ID: 123 Content-Type: "text/plain" Hi, I'm Alice! 14. Bob->BiloxiRelay (MSRP): MSRP xx 200 OK TR-ID: 123 15. BiloxiRelay->AtlantaRelay (MSRP): MSRP xx 200 OK TR-ID: 123 16. AtlantaRelay->Alice (MSRP): MSRP xx 200 OK TR-ID: 123 17. Alice->Bob (SIP): BYE 18. Alice->AtlantaRelay (MSRP): MSRP xx BIND S-URL: msrp://relay.atlanta.com:7777/iau39 TR-ID: 42 Campbell, et al. Expires November 20, 2003 [Page 39] Internet-Draft SIMPLE IM Sessions May 2003 Exp:0 19. Relay->Alice (MSRP): (relay invalidates session state) MSRP xx 200 OK TR-ID: 42 Exp:0 20. Bob->Alice (SIP): 200 OK 8. IANA Considerations To Do. Do we need to register URL schemes or SDP a-line attributes? 9. Security Considerations There are a number of security considerations for MSRP, some of which are mentioned elsewhere in this document. This section discusses those further, and introduces some new ones. 9.1 The MSRPS Scheme The MSRPS scheme indicates that all hops in an MSRP session MUST be protected with TLS. Ensuring this implies some additional rules. An MSRP relay MUST NOT return an MSRPS URL in the S-URL header field in a response to a BIND request unless the BIND request itself was received over a TLS protected session. A VISIT request for an MSRPS URL MUST be sent over a TLS protected connection. If a visiting relay receives a VISIT request for an MSRPS URL, the connection to the hosting device MUST also be protected. There has been controversy on whether an MSRPS scheme is really needed, since there is a small limit to the total number of hops in an MSRP session. However, a mechanism is required to inform the visitor to use TLS in the first place. We could have used an SDP a-line attribute for this. However, there also needs to be a mechanism for a hosting relay to tell the host endpoint to request the visitor use TLS. The MSRPS scheme seems to best fit all of these requirements. Open Issue: There is also some controversy over how TLS should be used with MSRP. The changes in this draft version make it possible Campbell, et al. Expires November 20, 2003 [Page 40] Internet-Draft SIMPLE IM Sessions May 2003 for relays to act as tunnels, where the TLS handshake is end-to-end. This is much the same way that TLS is handled by HTTPS proxies. However, this usage requires at least one endpoint to have a TLS server certificate, which may not be likely. Another approach is to make TLS usage hop-by-hop. When at least one relay is used, only the relays would need server certificates. Even if we support end-to-end TLS, we may still need a way to specify hop-by-hop TLS, because since end-to-end TLS would delay the TLS handshake until _after_ the BIND and VISIT requests, these requests would not be protected. 9.2 Sensitivity of the Session URL The URL of a MSRP session is used by the visiting endpoint to identify itself to the hosting device, regardless of whether the session is directly hosted by the host endpoint, or is hosted by a relay. If an attacker were able to acquire session URL, either by guessing it or by eavesdropping, there is a window of opportunity in which the attacker could hijack the session by sending a VISIT request to the host device before the true visiting endpoint. Because of this sensitivity, the session URL SHOULD be constructed in a way to make it difficult to guess, and should be sufficiently random so that it is unlikely to be reused. All mechanisms used to transport the session URL to the visitor and back to the host SHOULD be protected from eavesdroppers and man-in-the-middle attacks. Therefore an MSRP device MUST support the use of TLS for at least the VISIT request, which by extension indicates the endpoint MUST support the use of TLS for all MSRP messages. Further, MSRP connections SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST be capable of using the security features of the signaling protocol in order to protect the SDP exchange and SHOULD actually use them on all such exchanges. End-to-end protection schemes SHOULD be preferred over hop-by-hop schemes for protection of the SDP exchange. 9.3 End to End Protection of IMs Instant messages can contain very sensitive information. As a result, as specified in RFC 2779 [3], instant messaging protocols need to provide for encryption, integrity and authentication of instant messages. Therefore MSRP endpoints MUST support the end-to-end encryption and integrity of bodies sent via SEND requests using CMS [7]. Note that while each protected body could use separate keying material, this is inefficient in that it requires an independent public key operation for each message. Endpoints wishing to invoke Campbell, et al. Expires November 20, 2003 [Page 41] Internet-Draft SIMPLE IM Sessions May 2003 end-to-end protection of message sessions SHOULD exchange symmetric keys in SDP k-lines, and use secret key encryption on for each MSRP message. When symmetric keys are present in the SDP, the offer-answer exchange MUST be protected from eavesdropping and tampering using the appropriate facilities of the signaling protocol. For example, if the signaling protocol is SIP, the SDP exchange MUST be protected using S/MIME. Open Issue: This subsection needs very close scrutiny for accuracy and security. In particular, do we need to say more about using secret key operations in CMS? 9.4 CPIM compatibility MSRP sessions may be gatewayed to other CPIM [16]compatible protocols. If this occurs, the gateway MUST maintain session state, and MUST translate between the MSRP session semantics and CPIM semantics that do not include a concept of sessions. Furthermore, when one endpoint of the session is a CPIM gateway, instant messages SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST include "message/cpim" as the first entry in its SDP format list. MSRP endpoints sending instant messages to a peer that has included 'message/cpim" as the first entry in the format list SHOULD encapsulate all instant message bodies in "message/cpim" wrappers. All MSRP endpoints SHOULD support the S/MIME features of that format. 10. Changes introduced in draft-ietf-simple-message-sessions-00 Name changed to reflect status as a work group item. This version no longer supports the use of multiple sessions across a single TCP session. This has several related changes: There is now a single session URI, rather than a separate one for each endpoint. The session URI is not required to be in requests other than BIND and VISIT, as the session can be determined based on the connection on which it arrives. BIND and VISIT now create soft state, eliminating the need for the RELEASE and LEAVE methods. The MSRP URL format was changed to better reflect generic URL standards. URL comparison and resolution rules were added. SRV usage added. Determination of host and visitor roles now uses a direction attribute much like the one used in COMEDIA. Campbell, et al. Expires November 20, 2003 [Page 42] Internet-Draft SIMPLE IM Sessions May 2003 Format list negotiation expanded to allow a "prefer these formats but try anything" semantic Clarified handling of direction notification failures. Clarified signaling associated with session failure due to dropped connections. Clarified security related motivations for MSRP. Removed MIKEY dependency for session key exchange. Simple usage of k-lines in SDP, where the SDP exchange is protected end-to-end seems sufficient. 11. Changes introduced in draft-campbell-simple-im-sessions-01 Version 01 is a significant re-write. References to COMEDIA were removed, as it was determined that COMEDIA would not allow connections to be used bidirectionally in the presence of NATs. Significantly more discussion of a concrete mechanism has been added to make up for no longer using COMEDIA. Additionally, this draft and draft-campbell-cpimmsg-sessions (which would have also changed drastically) have now been combined into this single draft. 12. Contributors The following people contributed substantially to this ongoing effort: Rohan Mahy Allison Mankin Jon Peterson Brian Rosen Dean Willis Adam Roach Cullen Jennings Normative References [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Campbell, et al. Expires November 20, 2003 [Page 43] Internet-Draft SIMPLE IM Sessions May 2003 Presence Protocol Requirements", RFC 2779, February 2000. [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URL): Generic Syntax", RFC 2396, August 1998. [5] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in progress), January 2003. [6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [7] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002. [8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. Informational References [9] Campbell, B. and J. Rosenberg, "Session Initiation Protocol Extension for Instant Messaging", RFC 3428, September 2002. [10] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [11] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D. and A. Johnston, "A Multi-party Application Framework for SIP", draft-ietf-sipping-cc-framework-02 (work in progress), May 2003. [12] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, "Best Current Practices for Third Party Call Control in the Session Initiation Protocol", draft-ietf-sipping-3pcc-03 (work in progress), March 2003. [13] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in progress), February 2003. [14] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [15] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323 , November 2002. Campbell, et al. Expires November 20, 2003 [Page 44] Internet-Draft SIMPLE IM Sessions May 2003 [16] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", draft-ietf-impp-im-03 (work in progress), May 2003. [17] Yon, D., "Connection-Oriented Media Transport in SDP", draft-ietf-mmusic-sdp-comedia-05 (work in progress), March 2003. [18] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. Authors' Addresses Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: bcampbell@dynamicsoft.com Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 EMail: jdrosen@dynamicsoft.com Robert Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: rsparks@dynamicsoft.com Paul Kyzivat Cisco Systems Mail Stop LWL3/12/2 900 Chelmsford St. Lowell, MA 01851 EMail: pkyzivat@cisco.com Campbell, et al. Expires November 20, 2003 [Page 45] Internet-Draft SIMPLE IM Sessions May 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Campbell, et al. Expires November 20, 2003 [Page 46] Internet-Draft SIMPLE IM Sessions May 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Campbell, et al. Expires November 20, 2003 [Page 47]