idnits 2.17.1 draft-ietf-simple-msrp-sessmatch-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 9, 2010) is 4877 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track S. Blau 5 Expires: June 12, 2011 Ericsson AB 6 December 9, 2010 8 Session Matching Update for the Message Session Relay Protocol (MSRP) 9 draft-ietf-simple-msrp-sessmatch-10.txt 11 Abstract 13 This document defines an extension, sessmatch, for the Message 14 Session Relay Protocol (MSRP) session matching procedure of MSRP 15 entities. The extension extends the applicability of MSRP 16 communication to network scenarios where Application Layer Gateway 17 (ALG) functions modify the Session Description Protocol (SDP) MSRP 18 address information. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 12, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Applicability statement . . . . . . . . . . . . . . . . . . . . 4 57 4. Sessmatch mechanism . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Session matching . . . . . . . . . . . . . . . . . . . . . 4 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 5.1. MSRP URI as shared secret . . . . . . . . . . . . . . . . . 5 62 5.2. Uniqueness of the session-id . . . . . . . . . . . . . . . 6 63 5.3. Man in the middle . . . . . . . . . . . . . . . . . . . . . 6 64 5.4. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The Message Session Relay Protocol (MSRP) [RFC4975] is designed to 76 use MSRP relays [RFC4976] as a means for Network Address Translation 77 (NAT) traversal and policy enforcement. 79 However, many Session Initiation Protocol (SIP) [RFC3261] networks, 80 in which MSRP usage is emerging, also contain SIP Application Layer 81 Gateways (ALGs), which anchor and controls media, perform tasks such 82 as NAT traversal, performance monitoring, lawful intercept, address 83 domain bridging, interconnect Service Layer Agreement (SLA) policy 84 enforcement, etc. An example is the Interconnect Border Control 85 Function (IBCF) [3GPP.23.228] defined by the 3rd Generation 86 Partnership Project (3GPP), which controls a media relay that handles 87 all types of SIP session media (voice, video, MSRP, etc). 89 MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], does 90 not work when an MSRP entities communicate with such ALGs, unless the 91 ALGs implement MSRP Back-To-Back User Agent (B2BUA) functionality. 92 The reason is that entities use the MSRP URI comparison [RFC4975] 93 procedure in order to match an MSRP message to an MSRP session. That 94 requires consistency between the address information in the MSRP 95 messages and the address information carried in the SDP a=path 96 attribute. The matching will fail if ALGs modify the address 97 information of the SDP a=path attribute, but do not implement MSRP 98 B2BUA functionality and perform the corresponding modification in the 99 associated MSRP messages. However, few ALGs implement MSRP B2BUA 100 functionality, due to complexity and poor scalability. 102 This specification defines an MSRP extension, sessmatch, that allows 103 MSRP entities to communicate with ALGs that do not implement MSRP 104 B2BUA functionality. MSRP entities that support the sessmatch use a 105 different mechanism for matching an MSRP message with an MSRP 106 session, called session matching. Instead of using the MSRP URI 107 comparison procedure defined in RFC 4975, only the MSRP session-id 108 part is used for the session matching by entities that support the 109 sessmatch extension. 111 In case TLS with name based authentication is used, ALGs need to 112 implement MSRP B2BUA functionality also when communicating with MSRP 113 entities that support the sessmatch extension, in order to prevent 114 the MSRP communication from failing due to a certificate mismatch. 116 The sessmatch extension is backward compatible. In the absence of 117 ALGs, MSRP entities that do not implement the sessmatch extension can 118 interoperate with entities that do implement it. The reason is that 119 the matching of an MSRP message to an ongoing session will not fail. 120 MSRP entities that do not implement the sessmatch extension, and 121 communicate with ALGs that do not implement MSRP B2BUA functionality, 122 can normally not establish MSRP sessions, since the session matching 123 will fail in case the address information of the SDP a=path attribute 124 has been modified by the ALGs. 126 2. Conventions 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in BCP 14, RFC 2119 131 [RFC2119]. 133 In this specification the terminology "fingerprint based TLS 134 authentication" and "name based TLS authentication" are used to refer 135 to the two cases where: 137 1. An endpoint use a self-signed TLS certificate and sends a 138 certificate fingerprint in SDP (fingerprint based TLS 139 authentication). 141 2. An endpoint use a certificate from a well known certificate 142 authority and the other endpoint matches the hostname in the received 143 TLS communication SubjectAltName parameter towards the hostname 144 received in the MSRP URI in SDP (name based TLS authentication). 146 3. Applicability statement 148 This document defines an MSRP extension, sessmatch. Support of the 149 extension is optional. MSRP entities can implement the extension in 150 order to allow MSRP communication in networks where ALGs that might 151 modify the address information of the SDP a=path attribute, but do 152 not implement MSRP B2BUA functionality, are present. 154 4. Sessmatch mechanism 156 4.1. General 158 This section defines how an MSRP entity that supports the sessmatch 159 extension performs session matching, i.e. matches an incoming MSRP 160 message to an MSRP session. 162 4.2. Session matching 164 The difference between the session matching mechanism in RFC 4975, 165 and the one defined in this specification for the sessmatch 166 extension, is that while the mechanism in RFC 4975 uses the MSRP URI 167 comparison rules for session matching, the sessmatch extension only 168 uses the session-id part of the MSRP URI. 170 When an MSRP entity that receives the first MSRP request for an MSRP 171 session, the To-Path header field of the request should contain a URI 172 with a session-id part that was provided in the SDP associated with 173 the MSRP session. The entity that accepted the connection looks up 174 the session-id part of the MSRP URI in the received requests, in 175 order to determine which session it matches. The session-id part is 176 compared as case sensitive. If a match exists, the entity MUST 177 assume that the host that formed the connection is the host to which 178 this URI was given. If no match exists, the entity MUST reject the 179 request with a 481 response. The entity MUST also check to make sure 180 the session is not already in use on another connection. If the 181 session is already in use, it MUST reject the request with a 506 182 response. 184 NOTE: As the sessmatch extension, in a peer to peer session, is 185 backward compatible with the RFC 4975 mechanism, the SIMPLE WG did 186 not see a need to define a SIP option-tag associated with the 187 sessmatch extension. In case the session path contains an 188 intermediary that modifies the SDP MSRP routing information, MSRP 189 session establishments that contain RFC 4975 entities will fail. 190 However, that is the case even without the sessmatch extension. 191 Also, an intermediary will normally make a decision whether to insert 192 itself in the session path when it receives the SDP offer. However, 193 it will not be aware about whether the MSRP endpoint acting as SDP 194 answerer supports the sessmatch extension until it receives the SDP 195 answer. 197 5. Security Considerations 199 5.1. MSRP URI as shared secret 201 An MSRP entity that does not support the sessmatch extension uses the 202 complete MSRP URI (scheme, authority, transport, session-id) as a 203 shared secret in order to determine that an incoming transport 204 connection originates from the intended peer device. The shared 205 secret needs to be hard to guess, but in reality only the session-id 206 part with it's minimum 80 bit of randomness is hard to guess. Using 207 only the MSRP URI session-id part as shared secret is therefore 208 roughly as good as using the complete URI. 210 5.2. Uniqueness of the session-id 212 The value of the MSRP URI session-id part only needs to be unique 213 within the scope of the MSRP entity that created it, so in order to 214 make the session-id unique there is no need to scope its namespace by 215 the MSRP URI authority part. 217 5.3. Man in the middle 219 A man-in-the-middle (MiTM) that wants to insert itself in the MSRP 220 communication path, in order to modify unprotected MSRP messages, 221 needs to implement MSRP B2BUA functionality. If the MiTM 222 communicates with MSRP entities that support the sessmatch extension, 223 it does not need to modify the To-Path and From-Path header fields in 224 the MSRP messages, which is the case if it communicates with an MSRP 225 entity that do not support the extension. In both cases, however, 226 the MiTM needs to terminate the TCP/TLS connection used for the MSRP 227 communication. 229 The sessmatch extension makes it easier for a MiTM to monitor and 230 record unprotected MSRP communication, as it allows the MiTM to 231 anchor the MSRP communication even if it does not implement MSRP 232 B2BUA functionality. 234 The sessmatch extension does not make it easier for a MiTM to insert 235 itself in the SIP/SDP signaling path, neither does it make it easier 236 for a MiTM to forward MSRP messages towards malicious MSRP entities 237 (as it does not require the MiTM to anchor the MSRP communication). 239 5.4. TLS 241 This specification does not in any way modify TLS security procedures 242 as such. The sessmatch extension allows the usage of ALGs that do 243 not implement MSRP B2BUA functionality in MSRP communications, unless 244 TLS with name based authentication is used, and unless MSRP relays 245 are used. In such cases ALGs need to implement MSRP B2BUA 246 functionality, to prevent the MSRP communication from failing. That 247 applies to MSRP in general, and is not specific to the extension 248 defined in this specification. 250 In case TLS with fingerprint based authentication is used, the 251 sessmatch extension allows usage of ALGs that modify the address 252 information of the SDP a=path attribute, but no not implement MSRP 253 B2BUA functionality, to communicate with MSRP entities. In order to 254 use fingerprint authentication, the SDP that carries the fingerprint 255 information needs to be integrity protected. In case an ALG needs to 256 be able to modify SDP information, however, it will not be possible 257 to provide full end-to-end SDP integrity protection of the SDP. 259 Integrity protection can still be provided between MSRP entities and 260 ALGs, however. 262 6. IANA Considerations 264 None. 266 7. Acknowledgements 268 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 269 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, 270 Ted Hardie and Richard L Barnes for their guidance and input in order 271 to produce this document. 273 8. Change Log 275 [RFC EDITOR NOTE: Please remove this section when publishing] 277 Changes from draft-ietf-simple-msrp-sessmatch-08 278 o OPEN ISSUE regarding the need for a sessmatch option-tag removed. 280 Changes from draft-ietf-simple-msrp-sessmatch-07 281 o Sessmatch defined as an MSRP extension, rather than MSRP update 282 o Additional security considerations text added 284 9. References 286 9.1. Normative References 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 292 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 294 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 295 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 296 September 2007. 298 9.2. Informative References 300 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 301 A., Peterson, J., Sparks, R., Handley, M., and E. 302 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 303 June 2002. 305 [3GPP.23.228] 306 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 307 TS 23.228 10.2.0, September 2010. 309 Authors' Addresses 311 Christer Holmberg 312 Ericsson 313 Hirsalantie 11 314 Jorvas 02420 315 Finland 317 Email: christer.holmberg@ericsson.com 319 Staffan Blau 320 Ericsson AB 321 P.O Box 407 322 Sweden 324 Email: staffan.blau@ericsson.com