SIMPLE Working Group C. Holmberg Internet-Draft Ericsson Updates: 4975 (if approved) S. Blau Intended status: Standards Track Ericsson AB Expires: March 26, 2011 September 22, 2010 Session Matching Update for the Message Session Relay Protocol (MSRP) draft-ietf-simple-msrp-sessmatch-07.txt Abstract This document updates the Message Session Relay Protocol (MSRP) session matching procedure of MSRP endpoints. The update extends the applicability of MSRP peer-to-peer communication to network scenarios where Application Layer Gateway (ALG) functions modify the Session Description Protcoll (SDP) MSRP address information. The update is backwards compatible. In the absence of ALGs RFC 4975 compliant MSRP User Agents (UAs) can interwork with MSRP UAs compliant with this specification. In the presence of ALGs RFC 4975 compliant MSRP UAs can normally not establish MSRP sessions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on March 26, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Holmberg & Blau Expires March 26, 2011 [Page 1] Internet-Draft MRSP September 2010 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 4 4. Normative update of RFC 4975 . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. RFC4975: 5.4 MSRP Connection Model . . . . . . . . . . . . 4 4.2.1. 5th paragraph . . . . . . . . . . . . . . . . . . . . . 4 4.2.2. 10th paragraph . . . . . . . . . . . . . . . . . . . . 5 4.3. RFC4975: 6. MSRP URIs . . . . . . . . . . . . . . . . . . . 5 4.3.1. 6th paragraph . . . . . . . . . . . . . . . . . . . . . 5 4.4. RFC4975: 6.1 MSRP URI Comparison . . . . . . . . . . . . . 5 4.4.1. 1st paragraph . . . . . . . . . . . . . . . . . . . . . 5 4.5. RFC4975: 7.3 Receiving Requests . . . . . . . . . . . . . . 6 4.5.1. 1st paragraph . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5.1. MSRP URI as shared secret . . . . . . . . . . . . . . . . . 6 5.2. Uniqueness of the session-id . . . . . . . . . . . . . . . 7 5.3. Man in the middle . . . . . . . . . . . . . . . . . . . . . 7 5.4. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Holmberg & Blau Expires March 26, 2011 [Page 2] Internet-Draft MRSP September 2010 1. Introduction The Message Session Relay Protocol (MSRP) [RFC4975] is designed to use MSRP relays [RFC4976] as a means for Network Address Translation (NAT) traversal and policy enforcement. However, many Session Initiation Protocol (SIP) [RFC3261] networks, in which MSRP usage is emerging, also contain generic Application Layer Gateways (ALGs), which might control media relays and perform tasks such as NAT traversal, performance monitoring, lawful intercept, address domain bridging, interconnect Service Layer Agreement (SLA) policy enforcement, etc. An example is the Interconnect Border Control Function (IBCF) [3GPP.23.228] defined by the 3rd Generation Partnership Project (3GPP), which controls a media relay that handles all types of SIP session media (voice, video, MSRP, etc). MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], does not work when such ALGs are present between the SIP/MSRP endpoints, unless the ALGs act as MSRP Back-To-Back User Agents (B2BUAs). The reason is that MSRP UAs, when they receive an MSRP message, use MSRP URI comparision [RFC4975] in order to match the MSRP message to an MSRP session. That requires consistency between the address information the the MSRP messages and the MSRP URI carried in the SDP a=path attribute. The matching will fail if an ALG modifies the address information of the SDP a=path attribute, but does not perform the corresponding modification in the MSRP message (which requires MSRP B2BUA functionaltiy). However, few ALGs implement MSRP B2BUA functionality, due to complexity and poor scalability. In order to allow usage of MSRP use in SIP networks where ALGs are present, this document updates the session matching procedures defined in RFC 4975. Instead of using the MSRP URI comparision procedure for matching an incoming MSRP message to an MSRP session, only the MSRP URI session-id part is used. The updated procedures defined in this specification allow the usage of non-MSRP B2BUA ALGs in MSRP peer-to-peer connections, with the restriction that TLS with name based authentication can not be used with such ALGs. TLS with fingerprint based authentication can be used with such ALGs, however. In case TLS name based authentication is used for peer-to-peer MSRP, or MSRP relays with or without TLS are used, ALGs still need to implement MSRP B2BUA functionality in order to prevent MSRP communication from failing. NOTE: Peer-to-peer MSRP, unprotected or TLS protected with fingerprint based TLS authentication, are considered to be the most common choises for MSRP communication in network environments where Holmberg & Blau Expires March 26, 2011 [Page 3] Internet-Draft MRSP September 2010 ALGs are deployed. 2. Conventions 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 BCP 14, RFC 2119 [RFC2119]. In this specification the terminology "fingerprint based TLS authentication" and "name based TLS authentication" are used to refer to the two cases where: 1 An endpoint use a self-signed TLS certificate and sends a certificate fingerprint in SDP (fingerprint based TLS authentication). 2. An endpoint use a certificate from a well known certificate authority and the other endpoint matches the hostname in the received TLS communication SubjectAltName parameter towards the hostname received in the MSRP URI in SDP (name based TLS authentication). 3. Applicability statement This document updates sections 5.4 (MSRP Connection Model) and 7.3 (Receiving Requests) of [RFC4975]. An MSRP UA MUST implement the procedures defined in this document in order to interoperate with remote MSRP UAs in a network where intermediaries might modify the address information in the MSRP URI of the SDP a=path attribute. 4. Normative update of RFC 4975 4.1. General This section replaces the text for the 5th and 10th paragraph of section 5.4 (MSRP Connection Model), the 6th paragraph of section 6 (MSRP URIs), the 1st section of section 6.1 (MSRP URI Comparison) and the first paragraph of section 7.3 (Receiving Requests), of RFC 4975. 4.2. RFC4975: 5.4 MSRP Connection Model 4.2.1. 5th paragraph The rules on certificate name matching and CA signing MAY be relaxed when using TLS peer-to-peer. In this case, a mechanism to ensure Holmberg & Blau Expires March 26, 2011 [Page 4] Internet-Draft MRSP September 2010 that the peer used a correct certificate MUST be used. See Section 14.4 for details. It is strongly RECOMMENDED that MSRP endpoints, when using peer-to-peer MSRP with TLS, use the mechanism described in section 14.4, in order to be able to establish MSRP sessions in networks where Application Layer Gateways (ALGs) are deployed. 4.2.2. 10th paragraph When the first request arrives, its To-Path header field should contain a URI with a session-id part that the listening element provided in the SDP for a session. The element that accepted the connection looks up the session-id part of the URI in the received request, and determines which session it matches. If a match exists, the node MUST assume that the host that formed the connection is the host to which this URI was given. If no match exists, the node MUST reject the request with a 481 response. The node MUST also check to make sure the session is not already in use on another connection. If the session is already in use, it MUST reject the request with a 506 response. 4.3. RFC4975: 6. MSRP URIs 4.3.1. 6th paragraph The MSRP URI authority field identifies a particular MSRP host device. If the authority field contains a numeric IP address, it MUST also contain a port. The MSRP URI session-id field identifies a particular session at the host device, and a particular value of session-id is only meaningful in the context of the particular MSRP host device that created it. An MSRP URI that does not include a session-id is a reference to an MSRP host device, not to any particular session at that device. 4.4. RFC4975: 6.1 MSRP URI Comparison 4.4.1. 1st paragraph In the context of the MSRP protocol, MSRP URI comparisons MUST be performed according to the following rules: 1. The scheme MUST match. Scheme comparison is case insensitive. 2. If the authority component contains an explicit IP address and/or port, these are compared for address and port equivalence. Percent- encoding normalization [10] applies; that is, if any percent-encoded non-reserved characters exist in the authority component, they must be decoded prior to comparison. Userinfo parts are not considered for URI comparison. Otherwise, the authority component is compared Holmberg & Blau Expires March 26, 2011 [Page 5] Internet-Draft MRSP September 2010 as a case-insensitive character string. 3. If the port exists explicitly in either URI, then it MUST match exactly. A URI with an explicit port is never equivalent to another with no port specified. 4. The session-id part is compared as case sensitive. A URI without a session-id part is never equivalent to one that includes one. 5. URIs with different "transport" parameters never match. Two URIs that are identical except for transport are not equivalent. The transport parameter is case insensitive. Path normalization [10] is not relevant for MSRP URIs. This specification does not define any usage for the MSRP URI comparison rules. However, if an extension mechanism requires MSRP URI comparison, it MUST use the rules defined in this section. NOTE: The MSRP URI comparison rules are not used to match MSRP messages with MSRP sessions. As defined in Section 4.5, only the MSRP URI session-id part is used for the session matching. 4.5. RFC4975: 7.3 Receiving Requests 4.5.1. 1st paragraph The receiving endpoint MUST first check the URI in the To-Path to make sure the request belongs to an existing session. When the request is received, the To-Path will have exactly one URI, of which the session-id part MUST map to an existing session that is associated with the connection on which the request arrived. The session-id part is compared as case sensitive. If this is not true, then the receiver MUST generate a 481 error and ignore the request. Note that if the Failure-Report header field had a value of "no", then no error report would be sent. 5. Security Considerations 5.1. MSRP URI as shared secret An MSRP UA compliant to RFC 4975 uses the complete MSRP URI (scheme, authority, transport, session-id) as a shared secret in order to determine that an incoming transport connection originates from the intended peer device. The shared secret needs to be hard to guess, but in reality only the session-id part with it's minimum 80 bit of randomness that is hard to guess. Using only the MSRP URI session-id Holmberg & Blau Expires March 26, 2011 [Page 6] Internet-Draft MRSP September 2010 part as shared secret is therfore roughly as good as using the complete URI. 5.2. Uniqueness of the session-id An MSRP URI session-id value only needs to be unique within the scope of the MSRP device that created it, so in order to make the session-id unique there is no need to scope its namespace by the MSRP URI authority part. 5.3. Man in the middle In order for a device to insert itself as a man in the middle in the MSRP communication path, it needs to be in the SIP/SDP signalling path and modify the SDP MSRP URI information associated with the MSRP session. When communicating with RFC 4975 compliant MSRP UAs, such device also needs to implement MSRP B2BUA functionality, since it needs to modify the MSRP To-Path and From-Path header fields, in order to match the SDP modification. This insertion of a man in the middle might not be detected by MSRP end devices. Due to the update in this specification a man in the middle no longer need to implement an MSRP B2BUA in order to be transparently in the MSRP communication path. However, a man in the middle that does not implement MSRP B2BUA functionality, and does not locally terminate the TCP/MSRP connection, has very limited impact on the MSRP connection. It could potentially monitor unprotected MSRP communication, but any kind of flexible fraudulent endpoint transparent modification of the MSRP communication is likely much easier done by using MSRP B2BUA functionality. 5.4. TLS This specification does not in any way modify the TLS security procedures for MSRP. TLS with fingerprint based authentication is not affected by the presence of intermediaries that modify the SDP MSRP URI information. TLS with name based authentication can only be used in presence of ALGs if these implement MSRP B2BUA functionality. Otherwise TLS authentication will fail. That applies to MSRP in general, and is not specific to the updates defined in this specification. 6. IANA Considerations This document updates 5.4, 6, 6.1 and 7.3 of [RFC4975] Holmberg & Blau Expires March 26, 2011 [Page 7] Internet-Draft MRSP September 2010 7. Acknowledgements Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, Ted Hardie and Richard L Barnes for their guidance and input in order to produce this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007. 8.2. Informative References [RFC3261] 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. [3GPP.23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 10.1.0, June 2010. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg & Blau Expires March 26, 2011 [Page 8] Internet-Draft MRSP September 2010 Staffan Blau Ericsson AB P.O Box 407 Sweden Email: staffan.blau@ericsson.com Holmberg & Blau Expires March 26, 2011 [Page 9]