SIMPLE WG C. Jennings Internet-Draft Cisco Systems, Inc. Expires: April 23, 2005 R. Mahy Airespace October 23, 2004 Relay Extensions for Message Sessions Relay Protocol (MSRP) draft-ietf-simple-msrp-relays-02.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 April 23, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The SIMPLE Working Group uses two separate models for conveying instant messages. Pager-mode messages stand alone, whereas Session-mode messages are setup as part of a session using the SIP protocol. MSRP (Message Sessions Relay Protocol) is a protocol for near-real-time, peer-to-peer exchange of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions Jennings & Mahy Expires April 23, 2005 [Page 1] Internet-Draft MSRP Relays October 2004 necessary to use them. Table of Contents 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Introduction and Requirements . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview of New Protocol Elements . . . . . . . . . . . . . . 9 4.1 The AUTH Method . . . . . . . . . . . . . . . . . . . . . 9 4.2 The Use-Path header . . . . . . . . . . . . . . . . . . . 10 4.3 Authentication headers . . . . . . . . . . . . . . . . . . 10 4.4 Time-related headers . . . . . . . . . . . . . . . . . . . 10 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 Client behavior . . . . . . . . . . . . . . . . . . . . . 11 5.1.1 Connecting to relays acting on your behalf . . . . . . 11 5.1.2 Sending requests . . . . . . . . . . . . . . . . . . . 13 5.1.3 Receiving Requests . . . . . . . . . . . . . . . . . . 14 5.1.4 Managing Connections . . . . . . . . . . . . . . . . . 14 5.2 Relay behavior . . . . . . . . . . . . . . . . . . . . . . 14 5.2.1 Handling Incoming Connections . . . . . . . . . . . . 14 5.2.2 Generic request behavior . . . . . . . . . . . . . . . 14 5.2.3 Receiving AUTH requests . . . . . . . . . . . . . . . 14 5.2.4 Forwarding SEND requests . . . . . . . . . . . . . . . 15 5.2.5 Forwarding non-SEND requests . . . . . . . . . . . . . 16 5.2.6 Forwarding Responses . . . . . . . . . . . . . . . . . 16 5.2.7 Managing Connections . . . . . . . . . . . . . . . . . 17 5.2.8 Forwarding unknown requests . . . . . . . . . . . . . 17 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Finding MSRP Servers . . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8.1 Using HTTP Authentication . . . . . . . . . . . . . . . . 20 8.2 Using TLS . . . . . . . . . . . . . . . . . . . . . . . . 20 8.3 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 20 8.4 Security Mechanism . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. Example SDP with multiple hops . . . . . . . . . . . . . . . 22 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 12.2 Informative References . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . 26 Jennings & Mahy Expires April 23, 2005 [Page 2] Internet-Draft MSRP Relays October 2004 1. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [16]. Below we list several definitions important to MSRP: MSRP node: a host that implements the MSRP protocols as a Client or a Relay. MSRP Client: an MSRP role which is the initial sender or final target of messages and delivery status. MSRP Relay: an MSRP role which forwards messages and delivery status and may provide policy enforcement. Relays can fragment and reassemble portions of messages. Message: arbitrary MIME content which one client wishes to send to another. For the purposes of this specification, a complete MIME body as opposed to a portion of a complete message. chunk: a portion of a complete message delivered in a SEND request. end-to-end: delivery of data from the initiating client to the final target client hop: delivery of data between one MSRP node and an adjacent node. 2. Introduction and Requirements The IETF SIMPLE Working Group has identified a number of scenarios where using a separate protocol for bulk messaging is desirable. In particular, the SIMPLE WG will use this facility to handle a sequence of messages as a session of media initiated using SIP [15], just like any other media type. The SIMPLE Working Group has also developed MSRP (the Message Sessions Relay Protocol) to convey sessions of messages directly between two end systems with no intermediaries. With MSRP, messages can be arbitrarily large and all traffic is sent over reliable, congestion-safe transports. This document describes extensions to the core MSRP protocol to introduce intermediaries called Relays. With these extensions MSRP clients can communicate directly, or through an arbitrary number of relays. Each client is responsible for identifying any relays acting on its behalf and providing appropriate credentials. Clients which can receive new TCP connections directly do not have to implement any new functionality to work with these relays. The Goals of the MSRP Relay extensions are listed below: o convey arbitrary binary MIME data without modification or transfer encoding o continue to support client to client operation (no relay servers required) Jennings & Mahy Expires April 23, 2005 [Page 3] Internet-Draft MSRP Relays October 2004 o operate through an arbitrary number of relays for policy enforcement o allow each client to control which relays are traversed on its behalf o prevent unsolicited messages (spam), "open relays", and denial of service amplification o allow relays to use one or a small number of TCP or TLS [2] connections to carry messages for multiple sessions, recipients, and senders o allow large messages to be sent over a slow connection without causing head-of-line blocking problems o allow transmission of a large message to be interrupted and resumed in place when network connectivity is lost and later reestablished o offer notification of message failure at any intermediary o provide notification of message storage (desirable) o allow relays to delete state after a short amount of time 3. Protocol Overview With the introduction of this extension, MSRP has the concept of both clients and relays. Clients send messages to relays and/or other clients. Relays forward messages and message delivery status to clients and other relays. Clients which can open TCP connections to each other without intervening policy restrictions, can communicate directly with each other. Clients who are behind a firewall or who need to use an intermediary for policy reasons can use the services of a relay. Each client is responsible for enlisting the assistance of one or more relays for its half of the communication. Clients which use a relay operate by first opening a TLS connection with a relay, authenticating, and retrieving an msrps: URI (from the relay) that the client can provide to its peers to receive messages later. When a client uses a relay, it first opens a TLS connection to its first relay and authenticates using an AUTH request which can contain HTTP Digest [1] Authentication credentials. In a successful AUTH response, the relay provides an msrps: URI associated with the path back to the client that the client can give to other clients for end-to-end message delivery. When clients wish to send a short message, they issue a SEND request with the entire contents of the message. If any relays are required, they are included in the To-Path header. The leftmost URI in the To-Path header is the next hop to deliver a request or response. The rightmost URI in the To-Path header is the final target. (Note that MSRP does not permit line folding. A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash, nor the extra CRLF are included in the actual Jennings & Mahy Expires April 23, 2005 [Page 4] Internet-Draft MSRP Relays October 2004 request or response.) MSRP 6aef SEND To-Path: msrps:example.org:9000/kjfjan \ msrps:example.net:9000/aeiug \ msrps:bob.example.net:8145/foo From-Path: msrps:alice.example.com:7965/bar Report-Success: yes Content-Type: text/plain Hi Bob, I'm about to send you file.mpeg -------6aef$ MSRP 6aef 200 OK To-Path: msrps:alice.example.com:7965/bar From-Path: msrps:example.org:9000/kjfjan -------6aef$ MSRP juh76 SEND To-Path: msrps:example.net:9000/aeiug \ msrps:bob.example.net:8145/foo From-Path: msrps:example.org:9000/kjfjan \ msrps:alice.example.com:7965/bar Report-Success: yes Content-Type: text/plain Hi Bob, I'm about to send you file.mpeg -------juh76$ MSRP juh76 200 OK To-Path: msrps:example.org:9000/kjfjan From-Path: msrps:example.net:9000/aeiug -------juh76$ MSRP xght6 SEND To-Path: msrps:bob.example.net:8145/foo From-Path: msrps:example.net:9000/aeiug \ msrps:example.org:9000/kjfjan \ msrps:alice.example.com:7965/bar Report-Success: yes Content-Type: text/plain Hi Bob, I'm about to send you file.mpeg -------xght6$ MSRP xght6 200 OK To-Path: msrps:example.net:9000/aeiug Jennings & Mahy Expires April 23, 2005 [Page 5] Internet-Draft MSRP Relays October 2004 From-Path: msrps:bob.example.net:8145/foo MSRP yh67 REPORT To-Path: msrps:example.net:9000/aeiug \ msrps:example.org:9000/kjfjan \ msrps:alice.example.com:7965/bar From-Path: msrps:bob.example.net:8145/foo Status: 000 200 OK Report-Failure: no -------yh67$ MSRP yh67 REPORT To-Path: msrps:example.org:9000/kjfjan \ msrps:alice.example.com:7965/bar From-Path: msrps:example.net:9000/aeiug \ msrps:bob.example.net:8145/foo From-Path: msrps:bob.example.net:8145/foo Status: 000 200 OK Report-Failure: no -------yh67$ MSRP yh67 REPORT To-Path: msrps:alice.example.com:7965/bar From-Path: msrps:example.org:9000/kjfjan \ msrps:example.net:9000/aeiug \ msrps:bob.example.net:8145/foo From-Path: msrps:bob.example.net:8145/foo Status: 000 200 OK Report-Failure: no -------yh67$ Jennings & Mahy Expires April 23, 2005 [Page 6] Internet-Draft MSRP Relays October 2004 Typical flow involving two relays Alice a.example.org b.example.net Bob | | | | |::::::::::::::::::::>| connection opened |<::::::::::::::::::::| |--- AUTH ----------->| |<-- AUTH ------------| |<-- 401 Auth---------| |--- 401 Auth-------->| |--- AUTH ----------->| |<-- AUTH ------------| |<-- 200 OK-----------| |--- 200 OK---------->| | | | | .... time passes .... | | | | |--- SEND ----------->| | | |<-- 200 OK ----------|:::::::::::::::::::>| (slow link) | | |--- SEND ---------->| | | |<-- 200 OK ---------|--- SEND ----------->| | | | ....>| | | | ..>| | | |<-- 200 OK ----------| | | |<-- REPORT ----------| | |<-- REPORT ---------| | |<-- REPORT ----------| | | | | | | SEND requests contain headers that indicate how they are acknowledged in a hop by hop form and in and end to end form. The default is that SEND message are acknowledged hop-by-hop. (Each relay that receives a SEND request acknowledges receipt of the request before forwarding the content in other SEND requests.) All other requests are sent end-to-end. With the introduction of relays, the subtle semantics of the To-Path and From-Path header becomes more relevant. The To-Path in both requests and responses is the list of URIs that need to be visited in order to reach the final target of the request. The From-Path is the list of URIs that indicate how to get back to the original sender of the request or response . This differs from the To and From headers in SIP, which do not "swap" from request to response. (Note that sometimes a request is sent to or from an intermediary directly.) When a relay forwards a request, it removes its address from the To-Path header and inserts it at as the first URI in the From-Path header. For example if the path from Alice to Bob is through relays A and B, when B receives the request it contains path headers that look like this: To-Path: msrps:B msrps:Bob From-Path: msrps:A msrps:Alice Jennings & Mahy Expires April 23, 2005 [Page 7] Internet-Draft MSRP Relays October 2004 after forwarding the request, the path headers look like this: To-Path: msrps:Bob From-Path: msrps:B msrps:A msrps:Alice The sending of acknowledgments for SEND requests is controlled by the Report-Success and Report-Failure headers and works the same ways as in the base MSRP protocol. When a relay receives a SEND request, if the Report-Failure is sent to "yes", the previous hop is running a timer and the relay must send a 200 response to the request to acknowledge it so that the pervious hop know it is not longer responsible for the request. If the relay knows it will not be able to deliver the request and the Report-Failure is not set to "no", then it send an REPORT to tell the sender of the error. In the case that Report-Failure is set to "yes", after the relay is done sending the request to the next hop, it starts running a timer and if the timer expires before an 200 is received from the next hop, the relay assumes that an error and happened and sends a REPORT to the sender. If the Report-Failure is not set to "yes", there is no need for the relay to run this timer. When sending large content the client may split up a message into smaller pieces; each SEND request might contain only a portion of the complete message. For example, when Alice sends Bob a 4GB file called "file.mpeg", she sends several SEND requests each with a portion of the complete message. Relays can repack message fragments en-route. As individual parts of the complete message arrive at the final destination client, the receiving client can optionally send REPORT requests indicating delivery status. MSRP nodes can send individual portions of a complete message in multiple SEND requests. As relays receive chunks they can reassemble or re-fragment them as long as they resend the resulting chunks in order. (Receivers still need to be prepared to receive out-of-order chunks however). If the sender set the Report-Success header to yes, once a chunk or complete message arrives at the destination client, the destination sends a REPORT request indicating that a chunk arrived end-to-end. This request travels back along the reverse path of the SEND request. Unlike the SEND request which is acknowledged along every hop, REPORT responses are never acknowledged. Jennings & Mahy Expires April 23, 2005 [Page 8] Internet-Draft MSRP Relays October 2004 Flow involving re-chunking through two relays Alice a.example.org b.example.net Bob | | | | | | | | |--- AUTH ----------->| |<-- AUTH ------------| |<-- 401 Auth---------| |--- 401 Auth-------->| |--- AUTH ----------->| |<-- AUTH ------------| |<-- 200 OK-----------| |--- 200 OK---------->| | | | | .... time passes .... | | | | |--- SEND 0-3 ------->| | | |<-- 200 OK ----------| | (slow link) | |--- SEND 4-7 ------->|--- SEND 0-5 ------>| | |<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 0-3 ------->| |--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>| |<-- 200 OK ----------|<-- 200 OK ---------| ..>| | | |<-- 200 OK ----------| | | |<-- REPORT 0-3 ------| | |<-- REPORT 0-3 -----|--- SEND 4-7 ------->| |<-- REPORT 0-3 ------| | ...>| | | |<-- REPORT 4-7 ----->| | |<-- REPORT 4-7 -----|--- SEND 8-10 ------>| |<-- REPORT 4-7 ------| | ..>| | | |<-- 200 OK ----------| | |<-- REPORT done-----|<-- REPORT done -----| |<-- REPORT done -----| | | | | | | Relays only keep transaction state for a short period of time for each chunk. Delivery over each hop should take no more than 32 seconds after the last byte of data is sent. Clients applications define their own implementation-dependent timers for end-to-end message delivery. For client to client communication, the sender of a message typically opens a new TCP connection (with or without TLS) if one is needed. Relays reuse existing connections first, but can open new connections (typically to another relay) to deliver requests such as SEND or REPORT. Responses can only be sent over existing connections. 4. Overview of New Protocol Elements 4.1 The AUTH Method AUTH requests are used by clients with ephemeral addresses to create a handle they can use to receive incoming requests. AUTH requests Jennings & Mahy Expires April 23, 2005 [Page 9] Internet-Draft MSRP Relays October 2004 can also contain credentials used to authenticate a client, and authorization policy used to block Denial of Service attacks. AUTH requests are discussed in more detail in a later section. In response to an AUTH request, a successful response contains a Use-Path header with a list of URIs that the Client can give to its peers to route responses back to the Client. 4.2 The Use-Path header The Use-Path header is a list of URIs provided by an MSRP Relay in response to a successful AUTH request. This list of URIs can be used by the MSRP Client that sent the AUTH request to receive MSRP requests, and to advertise this list of URIs, for example in a session description. 4.3 Authentication headers The Authentication-Info header provides optional information for HTTP Digest authentication. This header MAY be included in the response to an AUTH request. Semantics of the header are described in RFC 2617. The Authorization header contains authentication credentials for HTTP Digest authentication in an AUTH request. Section [x.y] . Note that the parameters of this header are separated by commas instead of semicolons. The presence of commas in this header does not imply that there is more than one header field value for this header field (only one header field value is allowed). Semantics of the header are described in RFC 2617. This header MUST NOT appear in any parcel other than an AUTH request. The WWW-Authenticate header contains an HTTP Digest challenge carried in a 401 Response. Note: Only auth, not auth-int is needed because TLS provides integrity. 4.4 Time-related headers The Expires header in a provides a relative time after which the action implied by the method of the request is no longer of interest. In a request, the Expires header indicates how long the sender would like the request to remain valid. In a response, the Expires header indicates how long the responder considers this information relevant. Specifically an Expires header in an AUTH request indicates how long the provided URIs will be valid. Jennings & Mahy Expires April 23, 2005 [Page 10] Internet-Draft MSRP Relays October 2004 The Min-Expires header contains the minimum duration a server will permit in an Expires header. It is sent only in 423 "Interval Out-of-Bounds" responses. Likewise the Max-Expires header contains the maximum duration a server will permit in an Expires header. 423 Interval Out-of-bounds. Max-Expires header 5. Procedures 5.1 Client behavior 5.1.1 Connecting to relays acting on your behalf Clients which want to use the services of a relay or list of relays, need to send an AUTH request to each relay which will act on their behalf. (For example, some organizations could deploy an "intra-org" relay and an "extra-org" relay.) Clients can be configured (typically through discovery or manual provisioning) with a list of relays they need to use. They MUST be able to form a connection to each relay and send an AUTH command to get a URI that can be used in route headers. The client can authenticate its first relay by looking at the relay's TLS certificate. Each relay MUST authenticate the client using digest authentication. The relay will return a URI, or list of URIs, in the Use-Path header of the response. These URIs are used by the client in the path attribute that is sent in the SDP to setup the session. The same URI can be used for multiple sessions to send to the client. When sending an AUTH request, the client MAY add an Expires header to request a MSRP URI that is valid for no longer that the provided interval. If an AUTH request returns a 401 Unauthorized request, the client SHOULD fetch the Digest challenge from the WWW-Authenticate header in the response and retry the AUTH request, including an Authorization header with the Digest response. Unlike in HTTP and SIP, Digest authentication in MSRP is only permitted for AUTH requests. When a client wishes to use more than one relay, they must AUTH to each relay they wish to use. Consider a client A, that wishes messages to flow from A to the first relays, R1, then on to a second relays, R2. This client with do a normal AUTH with R1. It will then do an AUTH transaction with R2 that is routed through R1. The client will form this AUTH messages by setting the To-Path to msrps:R1 msrps:R2. R1 will forward this (just like a REPORT request) on to R2. Jennings & Mahy Expires April 23, 2005 [Page 11] Internet-Draft MSRP Relays October 2004 (Alice opens a TLS connection to intra.example.com) MSRP 676sd AUTH To-Path: msrps:alice@intra.example.com From-Path: msrps:alice.example.com:9892/98cjs -------676sd$ MSRP 676sd 401 Authenticate To-Path: msrps:alice.example.com:9892/98cjs From-Path: msrps:alice@intra.example.com WWW-Authenticate: -------676sd$ MSRP 49fh AUTH To-Path: msrps:alice@intra.example.com From-Path: msrps:alice.example.com:9892/98cjs Authorization: -------49fh$ MSRP 49fh 200 OK To-Path: msrps:alice.example.com:9892/98cjs From-Path: msrps:alice@intra.example.com Use-Path: msrps:intra.example.com:9000/jui787s2f -------49fh$ (Alice now sends an AUTH request to her "external" relay through her "internal" relay, using the URI she just obtained) MSRP quiyd2 AUTH To-Path: msrps:intra.example.com:9000/jui787s2f \ msrps:extra.example.com From-Path: msrps:alice.example.com:9892/98cjs -------quiyd2$ MSRP quiyd2 AUTH To-Path: msrps:extra.example.com From-Path: msrps:intra.example.com:9000/jui787s2f \ msrps:alice.example.com:9892/98cjs -------quiyd2$ MSRP quiyd2 401 Authenticate To-Path: msrps:intra.example.com:9000/jui787s2f \ msrps:alice.example.com:9892/98cjs From-Path: msrps:extra.example.com WWW-Authenticate: -------quiyd2$ MSRP quiyd2 401 Authenticate Jennings & Mahy Expires April 23, 2005 [Page 12] Internet-Draft MSRP Relays October 2004 To-Path: msrps:intra.example.com:9000/jui787s2f From-Path: msrps:alice.example.com:9892/98cjs \ msrps:extra.example.com WWW-Authenticate: -------quiyd2$ MSRP mnbvw AUTH To-Path: msrps:intra.example.com:9000/jui787s2f \ msrps:extra.example.com From-Path: msrps:alice.example.com:9892/98cjs -------mnbvw$ MSRP mnbvw AUTH To-Path: msrps:extra.example.com From-Path: msrps:intra.example.com:9000/jui787s2f \ msrps:alice.example.com:9892/98cjs -------mnbvw$ MSRP mnbvw 200 OK To-Path: msrps:intra.example.com:9000/jui787s2f \ msrps:alice.example.com:9892/98cjs From-Path: msrps:extra.example.com Authorization: Use-Path: msrps:extra.example.com:9000/mywdEe1233 \ msrps:intra.example.com:9000/jui787s2f -------mnbvw$ MSRP mnbvw 200 OK To-Path: msrps:intra.example.com:9000/jui787s2f From-Path: msrps:alice.example.com:9892/98cjs \ msrps:extra.example.com Authorization: Use-Path: msrps:extra.example.com:9000/mywdEe1233 \ msrps:intra.example.com:9000/jui787s2f -------mnbvw$ 5.1.2 Sending requests The procedure for forming SEND and REPORT requests is identical for clients whether relays are involved or not. The specific procedures are described in section 6 of the core MSRP protocol. As usual, once the next-hop URI is determined, the client MUST find the appropriate address, port, and transport to use and then check if there is already an existing suitable connection to the next-hop target. If so, the client MUST send the request over the most Jennings & Mahy Expires April 23, 2005 [Page 13] Internet-Draft MSRP Relays October 2004 suitable connection. Suitability MAY be determined by a variety of factors such as measured load and local policy, however in most simple implementations a connection will be suitable if it exists and is in an active state. 5.1.3 Receiving Requests The procedure for receiving requests is identical for clients whether relays are involved or not. 5.1.4 Managing Connections Clients should open connection whenever they wish to deliver a request and no suitable connection exists. For client to client connections, a client should close a connection when there are no longer any sessions associated with the connection. For connections to relays, the client should leave a connection up until no sessions are using the connection for a locally defined period of time, which defaults to 5 minutes for foreign relays and one hour for the client's relays. 5.2 Relay behavior 5.2.1 Handling Incoming Connections 5.2.2 Generic request behavior Upon receiving a new request, relays first verify the validity of the request. Relays then examine the first URI in the To-Path header and remove this URI if it matches a URI corresponding to the relay. The relay performs Authorization to determine if the final target is a URI under its control or from a URI under its control. 5.2.3 Receiving AUTH requests When a relay receive an AUTH request, it must authenticate the client that sent it with digest, it must also authenticate the previous hop that send the message to it. When previous hop was a relay this is done with the mutual TLS while when the previous hop was a client mutual TLS MAY be used it is available or the client authorization from the digest is used. The relay will generate the base URI of a family of URIs, each of which allows messages to be forwarded to and from this client. If the previous hop was authenticated by mutual TLS, then the URI MUST be valid to route across any connection the relay has to the previous hop relay. If the previous hop was not authenticated by mutual TLS, then the URI MUST only be valid to route across the same connection that the AUTH was received on. If this Jennings & Mahy Expires April 23, 2005 [Page 14] Internet-Draft MSRP Relays October 2004 connection is closed then reopened, the URI MUST NOT be valid. Valid to route means that when the relay receives a messages that contains this URI, if the message it going to element that was the previous hop in the AUTH, then the relay can forward it and if the messages is coming from previous hop in the AUTH, then the relay can forward it to any location, otherwise the RELAY must discard the message and MAY send a REPORT indicating the AUTH URI was bad. If the AUTH request contains an Expires header, then the relay MUST ensure that the URI is not valid to route after the expiry time. A successful AUTH response returns a Route header which contains a base MSRP URI that the client can use to create a number of different URIs which are all associated with the current connection. It is possible to implement all of the above requirements without the relay saving any state and one possible implementation that a relay might use is described in the rest of this section. When a relay starts up it could pick a crypto random 128 bit password (K) and 128 bit initialization vector (IV). If the relay was actually a farm of servers with the same DNS name, all the machines in the farm would need to share the same K. When an AUTH request was received the relay form a string that contains: the expiry time of the URI, an indication if the previous hop was mutual TLS authenticated or not and it it was, the name of the previous hop, if it was not the identifier for the connection which received the AUTH request. This string would be padded by appending a byte with the value 0x80 then adding zero or more bytes with the value of 0x00 until the string length is a multiple of 16 bytes long. A new random IV vector would be selected (it needs to change because it forms the salt) and the padded string would be encrypted using AES-CBC with a key of K. The IV and encrypted data and an SPI (security parameter index) that changed each time K changed would be base 64 encoded and form the user portion of the request URI. The SPI allows the key to be changed and for the system to know which K should be used. Later when the relay received this URI, it could decrypt it and check the current time was before the expiry time and check that the messages was coming from or going to the connection or location specified in the URI. Integrity protection is not required because it is extremely unlikely that random data that was decrypted would result in a valid location that was the same as the messages was routing to or from. When implementing something like this, implementers should be careful not to use a scheme like EBE that would allows portion of encrypted tokens to be cut and paste into others. 5.2.4 Forwarding SEND requests If an incoming SEND request Report-Failure header with a value of "yes", a MSRP relay that receives that SEND request MUST respond with Jennings & Mahy Expires April 23, 2005 [Page 15] Internet-Draft MSRP Relays October 2004 a final response immediately. A 200-class response indicates the successful receipt of a message fragment, but does not mean that the message has been forwarded on to its next hop. The final response to the SEND MUST be sent to the previous hop, which could be a MSRP relay or the original sender of the SEND request. If there is a problem further processing the SEND request, or in the response that the relay receives in sending the SEND request to the next hop, and the Report-Success header is "yes" or "partial", then the relay MUST respond with an appropriate error response in a REPORT back to the previous hop. The MSRP relay MAY further break up the message fragment received in the SEND request into smaller fragments and forward them to the next hop in separate SEND requests. It MAY also combine message fragments received before or after this SEND request, and forward them out in a single SEND request to the next hop identified in the Hops header. The MSRP relay MUST NOT combine message fragments from SEND requests with different values in the Message-ID header. The MSRP relay MAY choose whether to further fragment the message, or combine message fragments, or send the message as is, based on some policy which is administered, or based on the network speed to the next hop, or any other mechanism. If the MSRP relay has knowledge of the byte range that it will transmit to the next hop, it SHOULD update the Byte-Range header in the SEND request appropriately. Before forwarding the SEND request to the next hop, the MSRP relay MUST inspect the first URI in the To-Path header. If it indicates this relay, the relay removes this URI from the To-Path header and inserts this URI in the From-Path header before any other URIs. 5.2.5 Forwarding non-SEND requests An MSRP relay that receives any request other than a SEND request (including new methods unknown to the relay), first follows the validation and authorization rules for all requests. Then the relay moves its URI from the beginning of the To-Path header, to the beginning of the From-Path header and forwards the request on to the next hop. If it already has a connection to the next hop, it SHOULD use this connection and not form a new connection. If no suitable connection exists, the relay opens a new connection. 5.2.6 Forwarding Responses Relays receiving a response, first check the transaction of the Jennings & Mahy Expires April 23, 2005 [Page 16] Internet-Draft MSRP Relays October 2004 response. If the response is a 200 response, and the relay is unaware of this transaction, the response MUST be dropped. Likewise if the message can not be parsed, the relay MUST drop the response. The relay MUST verify that the first URI in the To-Path corresponds to it and if not, the response SHOULD be dropped. If the response matches an existing transaction, the transaction state is deleted and any timers running on it are removed. If the response is a non 200 response response, and the original request had the a Report-Failure header value that was not no, then the relay MUST send a REPORT indicating the nature of the failure. If there are additional URIs in the To-Path header, the relay can then move its URI from the list To-Path header, insert its URI in front of any other URIs in the From-Path header, and forward the response to the next URI in the To-Path header. The relay sends the request over the best connection which corresponds to the next URI in the To-Path header. If this connection has closed, then the response is silently discarded. 5.2.7 Managing Connections Relays should keep connection open as long as possible. If a connection has not been used in a significant time (many minutes) it could be closed. If the relay runs out of resource and must close connections, it should first stop accepting new connections from clients then start closing connections on a least recently used basis. 5.2.8 Forwarding unknown requests Requests with an unknown method are forwarded as if they were REPORT requests. 6. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [18]. AUTHm = %x41.55.54.48 ; AUTH in caps Method = SENDm / REPORTm / AUTHm / ext-method Authentication-Info = "Authentication-Info" HCOLON ainfo *(COMMA ainfo) ainfo = nextnonce / message-qop Jennings & Mahy Expires April 23, 2005 [Page 17] Internet-Draft MSRP Relays October 2004 / response-auth / cnonce / nonce-count nextnonce = "nextnonce" EQUAL nonce-value response-auth = "rspauth" EQUAL response-digest response-digest = LDQUOT *LHEX RDQUOT Authorization = "Authorization" HCOLON credentials credentials = ("Digest" LWS digest-response) / other-response digest-response = dig-resp *(COMMA dig-resp) dig-resp = username / realm / nonce / digest-uri / dresponse / algorithm / cnonce / opaque / message-qop / nonce-count / auth-param username = "username" EQUAL username-value username-value = quoted-string digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT digest-uri-value = rquest-uri ; Equal to request-uri as specified by HTTP/1.1 message-qop = "qop" EQUAL qop-value cnonce = "cnonce" EQUAL cnonce-value cnonce-value = nonce-value nonce-count = "nc" EQUAL nc-value nc-value = 8LHEX dresponse = "response" EQUAL request-digest request-digest = LDQUOT 32LHEX RDQUOT auth-param = auth-param-name EQUAL ( token / quoted-string ) auth-param-name = token other-response = auth-scheme LWS auth-param *(COMMA auth-param) auth-scheme = token LHEX = DIGIT / %x61-66 ;lowercase a-f ; Some elements (authentication) force hex alphas to be lower case. WWW-Authenticate = "WWW-Authenticate" HCOLON challenge challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge other-challenge = auth-scheme LWS auth-param *(COMMA auth-param) digest-cln = realm / domain / nonce / opaque / stale / algorithm / qop-options / auth-param realm = "realm" EQUAL realm-value realm-value = quoted-string domain = "domain" EQUAL LDQUOT URI *( 1*SP URI ) RDQUOT URI = MSRP-URI / anyURI Jennings & Mahy Expires April 23, 2005 [Page 18] Internet-Draft MSRP Relays October 2004 nonce = "nonce" EQUAL nonce-value nonce-value = quoted-string opaque = "opaque" EQUAL quoted-string stale = "stale" EQUAL ( "true" / "false" ) algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess" / token ) qop-options = "qop" EQUAL LDQUOT qop-value *("," qop-value) RDQUOT qop-value = "auth" / token Expires = "Expires" ":" SP 1*DIGIT Use-Path = "Use-Path" ":" SP URI *(SP URI) 7. Finding MSRP Servers When resolving a an MSRP URI which contains an explicit port number, an MSRP node follows the rules in section 4.4 of MSRP. MSRP URIs exchanged in SDP and in To-Path and From-Path headers in non-AUTH requests MUST have an explicit port number. The following rules allow MSRP clients to discover MSRP relays more easily in AUTH requests. If the hostport of an msrps: URI is an IPv4 address or an IPv6 reference and no port number is provided, use the default port number assigned by IANA. If the hostport is a domain name and an explicit port number is provided, attempt to lookup a valid address record (A or AAAA) for the domain name. Connect using the TLS over the default transport (TCP) with the default port number. If a domain name is provided, but no port number, perform a DNS SRV [7] lookup for and select the entry with the highest weight. If no SRV records are found, try an address lookup (A or AAAA) using the default port number procedures described in the previous paragraph. Note that AUTH requests MUST only be sent over a TLS-protected channel. An SRV lookup in the example.com domain might return: ;; in example.com. Pri Wght Port Target _msrps._tcp IN SRV 0 1 9000 server1.example.com. _msrps._tcp IN SRV 0 2 9000 server2.example.com. If implementing a relay farm, it is RECOMMENDED that each member of the relay farm have an SRV entry. If any members of the farm have multiple IP addresses (for example an IPv4 and an IPv6 address), each of these addresses SHOULD be registered in DNS as separate A or AAAA records corresponding to a single target. Jennings & Mahy Expires April 23, 2005 [Page 19] Internet-Draft MSRP Relays October 2004 8. Security Considerations This section first describes the security mechanisms available for use in MSRP. Then the threat model is presented. Finally we list implementation requirements related to security. 8.1 Using HTTP Authentication AUTH requests MUST be authenticated using HTTP authentication. HTTP authentication is done as described in [RFC 2617], with the following exceptions. Basic authentication MUST NOT be used. A qop value of auth-int MUST NOT be used as the AUTH requests are integrity protected by TLS and there is no body to protect. Note that unlike in some usages of HTTP Authentication (for example, SIP), the uri parameter in the Authorize header is the same as the Request-URI in the request line of the MSRP parcel of the AUTH request. Note the BNF in RFC-2617 has an error--the value of the uri parameter MUST be in quotes. The BNF in this document is correct, as are the examples in RFC 2617. 8.2 Using TLS TLS is used to authenticate relays to senders and to provide integrity and confidentiality for the headers being transported. MSRP client and relays MUST support TLS. Clients and relays MUST support the TLS ClientExtendedHello extended hello information for server name indication as described in RFC 3546 [8]. A TLS cipher-suite of TLS_RSA_WITH_AES_128_CBC_SHA [9] MUST be supported (other cipher-suites MAY also be suported). Relays must act as TLS servers and present a certificate with their identity in the SubjectAltName using the choice type of dnsName. Relay to relay connections MUST use TLS and client to relay communications MUST use TLS for AUTH requests and responses. Note: When relays are involved in a session, TCP without TLS is only used when a relay of one user connects directly to an MSRP endpoint of another user who does not use relays. 8.3 Threat Model This section discuses the threat model and the broad mechanism that must come into place to secure the protocol. The next section describes the details of how the protocol mechanism meet the broad requirements. MSRP allows two peer to peer clients to exchange messages. Each peer can select a set of relays to perform certain policy operation for them. This combined set of relays is referred to as the route set. Jennings & Mahy Expires April 23, 2005 [Page 20] Internet-Draft MSRP Relays October 2004 There often exists a channel outside of MSRP, such as out-of-band provisioning or an explicit rendezvous protocol such as SIP, that can securely negotiate setting up the MSRP session and communicate the route set to both clients. A client may trust a relay with certain types of routing and policy decisions but it might or might not trust the relay with all the contents of the session. For example, a relay being trusted to look for viruses would probably need to be allowed to see all the contents of the session. A relay that helped deal with firewall traversal of the ISPs firewall would likely not be trusted with the contents of the session but would be trusted to correctly forward information. Clients need to be able to authenticate that the relay they are communicating with is the one they trust. Likewise, relays need to be able to authenticate the client is the authorized client for them to forward information to. Clients need the option of ensuring information between the relay and the client is integrity protected and confidential to elements other than the relays and clients. To simplify the number of options, traffic between relays must always be integrity protected and encrypted regardless of if the client request it or not. There is no way for the clients to tell the relays what strength of crypto to use between relays other than the clients to choose to use relays that are operated by people requiring an adequate level of security. The system also need to stop the messages from being directed to relays that are not supposed to see them. To keep the relays from being used in DDoS attacks, the relays must not forward messages unless they have a trust relationship with either the client sending or receiving the message and that they only forward that message if it is coming from or going to the client they have the trust relationship with. If a relay has a trust relationship with the client that is the destination of the message, it should not send the message anywhere except the client that is the destination. Some terminology used in this discussion is SClient is the client sending a message and RClient is the client receiving a message. SRelay is a relay the sender trusts and RRelay is a relay the receiver trusts. The message will go from SClient to SRelay1 to SRelay2 to RRelay2 to RRelay1 to RClient. 8.4 Security Mechanism Confidentiality and Privacy from elements not in the route set is provided by using TLS on all the transports. If a client decided to not use TLS that is it's choice but relays must use TLS. Clients must implement TLS. Jennings & Mahy Expires April 23, 2005 [Page 21] Internet-Draft MSRP Relays October 2004 The relays authenticate to the clients using TLS (but don't have to do mutual TLS). The clients authenticate to the relays using HTTP Digest inside of TLS. Relays authenticate to each other using mutual TLS. The clients can protect the contents so that the relays can not see them by using S/MIME encryption. End to end signing is also possible with S/MIME. The complex part is making sure that relays do not send messages place where they should not. This is done by having the client authenticate to the relay and having the relay return a token. Messages that contain this token can be relayed if they come from the client that got the token or if they are being forwarded towards the client that got the token. The tokens must only ever be seen by things in the route set or other elements that at least one of the parties trusts. If some 3rd party discovers the token that RRelay2 uses to forward messages to RClient, then that 3rd party can send as many messages as they want to RRelay2 and it will forward them to RClient. The 3rd party can not cause them to be forwarded anywhere except to RClient eliminating the open relay problems. SRelay1 will not forward the message unless it contains a valid token. When SClient goes to get a token from SRelay2, this request is relayed through SRelay1. SRelay authenticates that it really is SClient requesting the token but it generates a token that is only valid for forwarding messages to or from SRelay1. SRelay two knows it is connected to SRelay1 because of the mutual TLS. The tokens are carried in the user portion of the MSRP URLs. The length of time the tokens are valid for is negotiated using the Expire header in the AUTH request. Clients need to renegotiate the tokens using a SIP reinvite for the session before they tokens expire. TODO talk about example from client to client and from Client A, then to a relay that A uses, RA, then on to client B. 9. IANA Considerations This document introduces no requirements for IANA. 10. Example SDP with multiple hops A sample SDP offer for a MSRP session could look like: c=IN IP4 invalid.none m=message 9 msrp * Jennings & Mahy Expires April 23, 2005 [Page 22] Internet-Draft MSRP Relays October 2004 a=accept-types: message/cpim text/plain text/html a=path:msrp:a.example.com:1234/agic456;tcp In this offer Alice wishes to receive MSRP messages at a.example.com. She wants to use TCP as the transport for the MSRP session. She can accept message/cpim, text/plain and text/html message bodies in SEND requests. She does not need a relay to setup the MSRP session. To this offer, Bob's answer could look like: c=IN IP4 invalid.none m=message 9 msrp * a=accept-types: message/cpim text/plain a=path:msrps:relay.example.com:9000/hjdhfha;tcp \ msrps:bob.example.com:1234/fuige;tcp Here Bob wishes to receive the MSRP messages at bob@bob.example.com. He can accept only message/cpim and text/plain message bodies in SEND requests and has rejected text/html offer made by Alice. He wishes to use a relays for the MSRP session - relay.example.com. 11. Acknowledgments Many thanks to the following members of the SIMPLE WG for spirited discussions on session mode: Ben Campbell, Jonathan Rosenberg, Robert Sparks, Paul Kyzivat, Allison Mankin, Jon Peterson, Brian Rosen, Dean Willis, Adam Roach, Aki Niemi, Hisham Khartabil, Juhee Garg, Pekka Pessi, and Chris Boulton. 12. References 12.1 Normative References [1] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Jennings & Mahy Expires April 23, 2005 [Page 23] Internet-Draft MSRP Relays October 2004 Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [5] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [7] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [8] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [9] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [10] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [11] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [12] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [14] Burger, E., Candell, E., Eliot, C. and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003. [15] 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. [16] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [17] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Jennings & Mahy Expires April 23, 2005 [Page 24] Internet-Draft MSRP Relays October 2004 [18] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [19] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-09 (work in progress), October 2004. 12.2 Informative References [20] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004. [21] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [22] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. [23] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [24] Resnick, P., "Internet Message Format", RFC 2822, April 2001. Authors' Addresses Cullen Jennings Cisco Systems, Inc. 170 West Tasman Dr. MS: SJC-21/2 San Jose, CA 95134 USA Phone: +1 408 421-9990 EMail: fluffy@cisco.com Rohan Mahy Airespace 110 Nortech Parkway San Jose, CA 95134 USA EMail: rohan@ekabal.com Jennings & Mahy Expires April 23, 2005 [Page 25] Internet-Draft MSRP Relays October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jennings & Mahy Expires April 23, 2005 [Page 26]