idnits 2.17.1 draft-ietf-simple-msrp-sessmatch-08.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 (November 9, 2010) is 4916 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) == Missing Reference: 'RFC6043' is mentioned on line 260, but not defined -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: May 13, 2011 Ericsson AB 6 November 9, 2010 8 Session Matching Update for the Message Session Relay Protocol (MSRP) 9 draft-ietf-simple-msrp-sessmatch-08.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 May 13, 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. Session matching mechanism . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 59 5.1. MSRP URI as shared secret . . . . . . . . . . . . . . . . . 5 60 5.2. Uniqueness of the session-id . . . . . . . . . . . . . . . 5 61 5.3. Man in the middle . . . . . . . . . . . . . . . . . . . . . 6 62 5.4. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 The Message Session Relay Protocol (MSRP) [RFC4975] is designed to 73 use MSRP relays [RFC4976] as a means for Network Address Translation 74 (NAT) traversal and policy enforcement. 76 However, many Session Initiation Protocol (SIP) [RFC3261] networks, 77 in which MSRP usage is emerging, also contain generic SIP Application 78 Layer Gateways (ALGs), which anchor and controls media, perform tasks 79 such as NAT traversal, performance monitoring, lawful intercept, 80 address domain bridging, interconnect Service Layer Agreement (SLA) 81 policy enforcement, etc. An example is the 3rd Generation 82 Partnership Project (3GPP) Interconnect Border Control Function 83 (IBCF) [3GPP.23.228]. 85 An MSRP entity, compliant with RFC 4975 [RFC4975] and RFC 4976 86 [RFC4976] cannot communicate with ALGs described above, unless the 87 ALGs implement MSRP Back-To-Back User Agent (B2BUA) functionality. 88 The reason is that such MSRP entities use the MSRP URI comparison 89 mechanism defined in RFC 4975 in order to match an MSRP message to an 90 MSRP session (session matching). That requires consistency between 91 the address information in the MSRP messages and the address 92 information carried in the SDP a=path attribute. The matching will 93 fail if ALGs modify the address information of the SDP a=path 94 attribute, but do not implement MSRP B2BUA functionality and perform 95 the corresponding modification in the associated MSRP messages. 96 However, few ALGs implement MSRP B2BUA functionality, due to 97 complexity and poor scalability. 99 This specification defines an MSRP extension, sessmatch, that allows 100 MSRP entities to communicate with ALGs that do not implement MSRP 101 B2BUA functionality. MSRP entities that support the sessmatch use a 102 different mechanism for matching an MSRP message with an MSRP 103 session. Instead of using the MSRP URI comparison procedure defined 104 in RFC 4975, only the MSRP session-id part is used for the session 105 matching by entities that support the sessmatch extension. 107 If an MSRP entity that supports the sessmatch extension communicates 108 with an ALG that does not implement MSRP B2BUA functionality, there 109 are restrictions regarding the usage of TLS authentication. In case 110 TLS with name based authentication is used, ALGs need to implement 111 MSRP B2BUA functionality communicating with MSRP entities that 112 support the sessmatch extension, in order to prevent the MSRP 113 communication from failing due to a certificate missmatch. 115 The sessmatch extension is backward compatible. In the absence of 116 ALGs that do not implement MSRP B2BUA functionality, MSRP entities 117 that do not implement the sessmatch extension can interoperate with 118 entities that do implement the extension, as none of the session 119 matching mechanisms will not fail. 121 MSRP entities that do not support the sessmatch extension, and 122 communicate with ALGs that do not implement MSRP B2BUA functionality, 123 can normally not establish MSRP sessions, since the session matching 124 will fail in case the address information of the SDP a=path attribute 125 has been modified by the ALGs. 127 2. Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in BCP 14, RFC 2119 132 [RFC2119]. 134 In this specification the terminology "fingerprint based TLS 135 authentication" and "name based TLS authentication" are used to refer 136 to the two cases where: 138 1. An endpoint use a self-signed TLS certificate and sends a 139 certificate fingerprint in SDP (fingerprint based TLS 140 authentication). 142 2. An endpoint use a certificate from a well known certificate 143 authority and the other endpoint matches the hostname in the received 144 TLS communication SubjectAltName parameter towards the hostname 145 received in the MSRP URI in SDP (name based TLS authentication). 147 3. Applicability statement 149 This document defines an MSRP extension, sessmatch. Support of the 150 extension is optional. MSRP entities can implement the extension in 151 order to allow MSRP communication in networks where ALGs that might 152 modify the address information of the SDP a=path attribute, but do 153 not implement MSRP B2BUA functionality, are present. 155 4. Session matching mechanism 157 This section defines how MSRP entities that support the sessmatch 158 extension perform session matching. 160 Session matching, as defined in RFC 4975, is performed in order to 161 associate a MSRP message with a session. The passive MSRP entity 162 (the entity that does not initiate the TCP connection) of a session 163 will also, when it receives the first MSRP message, use session 164 matching in order to bind the session to the specific TCP connection, 165 in order to know on which TCP connection to send outgoing MSRP 166 messages associated with the session. 168 When a MSRP entity that supports the sessmatch extension receives an 169 MSRP message, it uses the To-Path header field MSRP URI session-id 170 part value to associate the MSRP mesage with a session. 172 In accordance wih RFC 4975, the session-id part value is compared as 173 case sensitive. If the session-id value is matched with an existing 174 session, the MSRP entity must check that the MSRP message was 175 received on the TCP connection bound to the session. If not, the 176 MSRP message is rejected with a 506 response. 178 The difference between the session matching mechanism defined in RFC 179 4975, and the mechanism defined in this specification for the 180 sessmatch extension, is that while the mechanism in RFC 4975 uses the 181 MSRI URI comparison rules for session matching, the sessmatch 182 extension only uses the MSRP URI session-id part. 184 OPEN ISSUE: It needs to be studied whether an SIP option-tag is 185 needed in order to indicate and/or negotiate support and usage of the 186 sessmatch extension. 188 5. Security Considerations 190 5.1. MSRP URI as shared secret 192 An MSRP entity that does not support the sessmatch extension uses the 193 complete MSRP URI (scheme, authority, transport, session-id) as a 194 shared secret in order to determine that an incoming transport 195 connection originates from the intended peer device. The shared 196 secret needs to be hard to guess, but in reality only the session-id 197 part with it's minimum 80 bit of randomness that is hard to guess. 198 Using only the MSRP URI session-id part as shared secret is therefore 199 roughly as good as using the complete URI. 201 5.2. Uniqueness of the session-id 203 For session matching, the session-id only needs to be unique within 204 the scope of the MSRP entity that created it. In order for an MSRP 205 entity to ensure this, there is no need to scope the session-id 206 namespace by the MSRP URI authority part. 208 As stated in the RFC4975, when using the complete URI as shared 209 secret, the secrecy is entirely provided by the 80-bit randomness of 210 the MSRP URI session-id par, so it makes no difference if only the 211 session-id part is used as shared secret. 213 5.3. Man in the middle 215 A man-in-the-middle (MiTM) that wants to insert itself in the MSRP 216 communication path, in order to modify unprotected MSRP messages, 217 needs to implement MSRP B2BUA functionality. If the MiTM 218 communicates with MSRP entities that support the sessmatch extension, 219 it does not need to modify the ToPath and FromPath header fields in 220 the MSRP messages, which is the case if it communicates with an MSRP 221 entities that do not support the extension. In both cases, however, 222 the MiTM needs to terminate the TCP/TLS connection used for the MSRP 223 communication. 225 The sessmatch extension makes it easier for a MiTM to monitor and 226 record unprotected MSRP communication, as it allows the MiTM to 227 anchor the MSRP communication even if it does not implement MSRP 228 B2BUA functionality. 230 The sessmatch extension does not make it easier for a MiTM to insert 231 itself in the SIP/SDP signaling path, neither does it make it easier 232 for a MiTM to forward MSRP messages towards malicious MSRP entities 233 (as it does not require the MiTM to anchor the MSRP communication). 235 5.4. TLS 237 The sessmatch extension does not in any way modify Transport layer 238 security (TLS) [RFC5246] security procedures as such, and in general 239 MSRP entities that support the sessmatch extension can use the TLS 240 security mechanisms defined in RFC 4975. However, as the sessmatch 241 extension makes it possible for ALGs to anchor MSRP communication, 242 without having to implement MSRP B2BUA functionality, TLS with name 243 based authentication cannot be used if MSRP entities are 244 communicating with such ALGs. In order to be able to use TLS with 245 name based authentication from failing, ALGs need to implement MSRP 246 B2BUA functionality. 248 An ALG that anchors MSRP communication modifies the MSRP routing 249 information in the associated SDP signalling. Such behavior will 250 prevent end-to-end SDP integrity. In the presence of such ALGs it 251 will therefore generally only be possible to provide hop-to-hop SDP 252 integrity, which means that malicious ALGs will be able to modify the 253 SDP information. 255 When possible, it is RECOMMENDED that MSRP entities that support the 256 sessmatch extension use TLS pre-shared key ciphersuites (TLS-PSK) 257 [RFC4279] together with a key management scheme where the key 258 security does not rely on SDP integrity protection, such as 259 Multimedia Internet KEYing (MIKEY) [RFC3830] or Ticket Based Modes of 260 Key Distribution Multimedia Internet KEYing (MIKEY-TICKET) [RFC6043]. 261 RFC 4567 [RFC4567] defines Key Management Extensions for SDP. 263 6. IANA Considerations 265 OPEN ISSUE: It needs to be studied whether an SIP option-tag is 266 needed in order to indicate and/or negotiate support and usage of the 267 sessmatch extension. 269 7. Acknowledgements 271 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 272 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, 273 Ted Hardie and Richard L Barnes for their guidance and input in order 274 to produce this document. 276 8. References 278 8.1. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 284 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 286 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 287 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 288 September 2007. 290 8.2. Informative References 292 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 293 A., Peterson, J., Sparks, R., Handley, M., and E. 294 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 295 June 2002. 297 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 298 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 299 August 2004. 301 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 302 for Transport Layer Security (TLS)", RFC 4279, 303 December 2005. 305 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 306 Carrara, "Key Management Extensions for Session 307 Description Protocol (SDP) and Real Time Streaming 308 Protocol (RTSP)", RFC 4567, July 2006. 310 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 311 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 313 [3GPP.23.228] 314 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 315 TS 23.228 10.2.0, September 2010. 317 Authors' Addresses 319 Christer Holmberg 320 Ericsson 321 Hirsalantie 11 322 Jorvas 02420 323 Finland 325 Email: christer.holmberg@ericsson.com 327 Staffan Blau 328 Ericsson AB 329 P.O Box 407 330 Sweden 332 Email: staffan.blau@ericsson.com