idnits 2.17.1 draft-ietf-simple-msrp-sessmatch-11.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 20 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 12, 2011) is 4727 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: 1 error (**), 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: November 13, 2011 Ericsson AB 6 May 12, 2011 8 Session Matching Update for the Message Session Relay Protocol (MSRP) 9 draft-ietf-simple-msrp-sessmatch-11.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. The document also defines a Session Initiation 19 Protocol (SIP) option-tag, sessmatch, that is used by MSRP entities 20 to indicate support of the sessmatch extension. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 13, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Applicability statement . . . . . . . . . . . . . . . . . . . 4 59 4. Sessmatch mechanism . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. Session matching . . . . . . . . . . . . . . . . . . . . . 4 62 4.3. Usage of 'sessmatch' option-tag . . . . . . . . . . . . . 5 63 4.4. Uniqueness of the session-id . . . . . . . . . . . . . . . 6 64 5. ALG assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.2. MSRP awareness . . . . . . . . . . . . . . . . . . . . . . 6 67 5.3. TCP connection reuse . . . . . . . . . . . . . . . . . . . 6 68 5.4. SDP integrity . . . . . . . . . . . . . . . . . . . . . . 7 69 5.5. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 6.1. MSRP URI as shared secret . . . . . . . . . . . . . . . . 7 72 6.2. Man in the middle . . . . . . . . . . . . . . . . . . . . 7 73 6.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 7.1. IANA Registration of the sessmatch Option Tag . . . . . . 9 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 77 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 The Message Session Relay Protocol (MSRP) [RFC4975] is designed to 86 use MSRP relays [RFC4976] as a means for Network Address Translation 87 (NAT) traversal and policy enforcement. 89 However, many Session Initiation Protocol (SIP) [RFC3261] networks, 90 in which MSRP usage is emerging, also contain SIP Application Layer 91 Gateways (ALGs), which anchor and controls media, perform tasks such 92 as NAT traversal, performance monitoring, lawful intercept, address 93 domain bridging, interconnect Service Layer Agreement (SLA) policy 94 enforcement, etc. An example is the Interconnect Border Control 95 Function (IBCF) [3GPP.23.228] defined by the 3rd Generation 96 Partnership Project (3GPP), which controls a media relay that handles 97 all types of SIP session media (voice, video, MSRP, etc). 99 MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], does 100 not work when an MSRP entities communicate with such ALGs, unless the 101 ALGs implement MSRP Back-To-Back User Agent (B2BUA) functionality. 102 The reason is that entities use the MSRP URI comparison [RFC4975] 103 procedure in order to match an MSRP message to an MSRP session. That 104 requires consistency between the address information in the MSRP 105 messages and the address information carried in the SDP a=path 106 attribute. The matching will fail if ALGs modify the address 107 information of the SDP a=path attribute, but do not implement MSRP 108 B2BUA functionality and perform the corresponding modification in the 109 associated MSRP messages. However, few ALGs implement MSRP B2BUA 110 functionality, due to complexity and poor scalability. 112 This specification defines an MSRP extension, sessmatch, that allows 113 MSRP entities to communicate with ALGs that do not implement MSRP 114 B2BUA functionality. MSRP entities that support the sessmatch 115 extension use a different mechanism for matching an MSRP message with 116 an MSRP session, called session matching. Instead of using the MSRP 117 URI comparison procedure defined in RFC 4975, only the MSRP 118 session-id part is used for the session matching. 120 The sessmatch extension is backward compatible. In the absence of 121 ALGs, MSRP entities that do not implement the sessmatch extension can 122 interoperate with entities that do implement it. The reason is that 123 the matching of an MSRP message to an ongoing session will not fail. 124 MSRP entities that do not implement the sessmatch extension, and 125 communicate with ALGs that do not implement MSRP B2BUA functionality, 126 can normally not establish MSRP sessions, since the session matching 127 will fail in case the address information of the SDP a=path attribute 128 has been modified by the ALGs. 130 2. Conventions 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in BCP 14, RFC 2119 135 [RFC2119]. 137 In this specification the terminology "fingerprint based TLS 138 authentication" and "name based TLS authentication" are used to refer 139 to the two cases where: 141 1. An endpoint use a self-signed TLS certificate and sends a 142 certificate fingerprint in SDP (fingerprint based TLS 143 authentication). 145 2. An endpoint use a certificate from a well known certificate 146 authority and the other endpoint matches the hostname in the received 147 TLS communication SubjectAltName parameter towards the hostname 148 received in the MSRP URI in SDP (name based TLS authentication). 150 3. Applicability statement 152 This document defines an MSRP extension, sessmatch. Support of the 153 extension is optional. MSRP entities can implement the extension in 154 order to allow MSRP communication in networks where ALGs that might 155 modify the address information of the SDP a=path attribute, but do 156 not implement MSRP B2BUA functionality, are present. 158 4. Sessmatch mechanism 160 4.1. General 162 This section defines how an MSRP entity that supports the sessmatch 163 extension performs session matching, i.e. matches an incoming MSRP 164 message to an MSRP session. 166 4.2. Session matching 168 The difference between the session matching mechanism in RFC 4975, 169 and the one defined in this specification for the sessmatch 170 extension, is that while the mechanism in RFC 4975 uses the MSRP URI 171 comparison rules for session matching, the sessmatch extension only 172 uses the session-id part of the MSRP URI. 174 When an MSRP entity that receives the first MSRP request for an MSRP 175 session, the To-Path header field of the request should contain a URI 176 with a session-id part that was provided in the SDP associated with 177 the MSRP session. The entity that accepted the connection looks up 178 the session-id part of the MSRP URI in the received requests, in 179 order to determine which session it matches. The session-id part is 180 compared as case sensitive. If a match exists, the entity MUST 181 assume that the host that formed the connection is the host to which 182 this URI was given. If no match exists, the entity MUST reject the 183 request with a 481 response. The entity MUST also check to make sure 184 the session is not already in use on another connection. If the 185 session is already in use, it MUST reject the request with a 506 186 response. 188 4.3. Usage of 'sessmatch' option-tag 190 This section describes how an MSRP entity that supports the sessmatch 191 extension uses the sessmatch option-tag. 193 An MSRP entity that supports the sessmatch extension, and is not 194 located behind an MSRP relay, MUST insert the 'sessmatch' option-tag 195 in the Supported header field of the initial INVITE request for a 196 session that contains MSRP media. If at least one reliably sent 197 successful response to the intial INVITE request contains the 198 'sessmatch' option-tag in the Supported header field of the response, 199 the MSRP entity MUST use the session matching procedures defined in 200 this specification during the session. Otherwise, if the MSRP entity 201 wants the MSRP session to proceed, the MSRP entity MUST use the 202 procedures defined in RFC 4975. 204 If an MSRP entity that supports the sessmatch extension receives an 205 initial INVITE request that contains the 'sessmatch' option-tag in 206 the Supported or Require header field of the request, and if it is 207 not located behind an MSRP relay, it MUST insert the 'sessmatch' 208 option-tag in the Supported header field of at least one reliably 209 sent successful response to the intial INVITE request, and it MUST 210 use the session matching procedures defined in this specification 211 during the session. Otherwise, if the MSRP entity wants the MSRP 212 session to proceed, the MSRP entity MUST NOT insert the 'sessmatch' 213 option-tag in a successful response to the initial INVITE request, 214 and it MUST use the session matching procedures defined in RFC 4975. 216 In addition to inserting the 'sessmatch' option-tag in the Supported 217 header field of the INVITE request, if an entity is performing MSRP 218 related procedures that require the remote MSRP entity to support the 219 sessmatch extension in order to enable MSRP media, it MUST also 220 insert the 'sessmatch' option-tag in the Require header field. 222 NOTE: An example of a scenarios where an entity needs to insert the 223 'sessmatch' option-tag in the Require header field, is when it acts 224 as an intermediary entity that modifies the SDP a=path attribute 225 address information, in order to anchor and forward MSRP traffic, but 226 will not be able to perform the corresponding address information 227 changes in the associated MSRP messages. The actions taken by such 228 entity in case the remote MSRP entity does not support the sessmatch 229 extension, and therfore sends a 420 (Not Supported) response to the 230 INVITE request, is outside the scope of this specification. 232 4.4. Uniqueness of the session-id 234 The session-id used to perform session matching is retrieved from the 235 To-Path header field MSRP URI of a received MSRP message. The 236 session-id has been generated by the receiving MSRP entity itself. 237 The MSRP entity MUST ensure that the session-id is unique among the 238 other session-ids generated by that MSRP entity. 240 5. ALG assumptions 242 5.1. General 244 This document does not specify ALG behavior. However, as the main 245 reason behind the sessmatch extension is to allow MSRP entities to 246 communicate in networks where ALGs are present, this document makes 247 certain assumptions regarding to how such ALGs behave. 249 5.2. MSRP awareness 251 This document assumes that an ALG is MSRP aware, meaning that it 252 modifies the address information in the SDP a=path attribute in order 253 to anchor the MSRP communication, but that the ALG does not perform 254 the associated modification in the To-Path and From-Path header 255 fields of MSRP messages. 257 NOTE: Other types of media traffic are normally routed using the SDP 258 c/m-lines, which an ALG can modify in order to anchor such media 259 communication. 261 5.3. TCP connection reuse 263 When the sessmatch extension is used, ALGs are not required to parse 264 and modify the MSRP payload. An ALG that does not parse the MSRP 265 payload might not enable re-usage of TCP connections for multiple 266 MSRP sessions. Instead, in order to associate an MSRP message with a 267 specific session, the ALG often assigns a unique local address:port 268 combination for each MSRP session. 270 5.4. SDP integrity 272 This document assumes that an ALG, in order to anchor the MSRP 273 communication, modifies the address and port information in the SDP 274 a=path attribute, and therefor can not be deployed in environments 275 that require SIP identity based peer-to-peer SDP protection. 277 5.5. TLS 279 This document considers two approaches how an ALG handles TLS 280 protected MSRP connections. 282 In the first approach, the ALG relays the MSRP media packages at the 283 transport layer. The TLS handshake and resulting security 284 association (SA) are established peer-to-peer between the MSRP 285 endpoints. The ALG will see encrypted MSRP media pacakges, but is 286 unable to inspect the cleartext content. 288 In the second approach, the ALG acts as a TLS B2BUA, meaning that 289 separate SAs are established between the ALG and each MSRP endpoint. 290 The ALG decrypts MSRP media packages received from one MSRP endpoint, 291 and then re-encrypts them before sending them toward the other MSRP 292 endpoint. With this approach, the ALG can inspect and modify the 293 cleartext content. 295 6. Security Considerations 297 6.1. MSRP URI as shared secret 299 An MSRP entity that does not support the sessmatch extension uses the 300 complete MSRP URI (scheme, authority, transport, session-id) as a 301 shared secret in order to determine that an incoming transport 302 connection originates from the intended endpoint device. The shared 303 secret needs to be hard to guess, but in reality only the session-id 304 part with it's minimum 80 bit of randomness is hard to guess. Using 305 only the MSRP URI session-id part as shared secret is therefore 306 roughly as good as using the complete URI. 308 6.2. Man in the middle 310 The sessmatch extension makes it easier for a man in the middle 311 (MiTM) to transparently insert itself in the communication between 312 MSRP endpoints in order to monitor or record unproteted MSRP 313 communication. It does not however enable a MiTM to monitor TLS 314 protected MSRP or to in any significant way modify the MSRP 315 communication content. That would require the MiTM to terminate the 316 TCP/MSRP or TCP/TLS/MSRP connection in both directions, eventhough it 317 would not need to allign the address information in the TCP/IP header 318 of the media packets with the modification in the associated SDP 319 a=path attribute. 321 6.3. TLS 323 If an ALG relays TLS connections, MSRP endpoints will not be able to 324 use name based authentication nor fingerprint based authentication 325 for TLS. 327 With name based authentication the problem is that each MSRP endpoint 328 would present a certificate associated to its the hostname, which 329 would match the authority part of the MSRP URI inserted in the SDP 330 a=path attribute of the offer or answer. However, when the ALG 331 modifies the MSRP URI in the SDP a=path attribute, the resulting 332 authority part will no long match, and the TLS handshake will fail. 334 With fingerprint based authentication the problem is instead that the 335 "SIP Identity" based integrity protection of SDP will break. 337 If an ALG acts as a TLS B2BUA, MSRP endpoints will be able to use 338 both name based and fingerprint based authentication for TLS, as the 339 ALG acts as a TLS endpoint. As the ALG acts as a TLS endpoints, MSRP 340 endpoint might be given an incorrect impression that there is an end- 341 to-end SA between the MSRP endpoints. 343 Considering the issues above, in order for MSRP endpoints to be able 344 to authenticate TLS in a secure manner in a network where ALGs are 345 present, an MSRP endpoint supporting the sessmatch extension SHOULD, 346 in addition to the authentication mechanisms described in RFC 4975, 347 support an authentication mechanism that does not rely on the a=path 348 attribute value being transported unchanged peer-to-peer. It is 349 RECOMMENDED that an MSRP endpoint supporting the sessmatch extension 350 supports one of the following authentication mechanisms: 352 1) TLS certificates together with support of interacting with a 353 Certificate Management Service [ref to draft-ietf-sip-certs], to 354 which it publishes the public version of its own self-signed 355 certificate and from which it fetches on need the public certificates 356 of other endpoints; or 358 2) TLS-PSK managed e.g by MIKEY-TICKET based Key Management and Key 359 Management Service [RFC6043]. 361 An MSRP endpoint that supports the sessmatch extension and one of the 362 mechanisms above SHALL, when it creates an SDP offer for MSRPS, in 363 addition to including the SDP attributes associated with the TLS 364 authentication mechanisms described in RFC 4975, include the SDP 365 attributes associated with the supported authentication mechanism 366 above. If both MSRP endpoints support the same authentication 367 mechanism based on pre-shared secrets, that mechanism SHALL be used, 368 rather than a mechanism defined in RFC 4975. 370 NOTE: 3GPP has specified usage of the MIKEY-TICKET based Key 371 Management and Key Management Service authentication mechanism for 372 the IP Multimedia Subsystem (IMS). 374 If MSRP endpoints supporting sessmatch do not support a common TLS 375 authentication based on a pre-shared secret, and neither MSRP 376 endpoint is located behind an MSRP relay, they SHALL either (based on 377 local policy or configuration): 379 1) Use a TLS authenctication mechanism defined in RFC 4975, which 380 will succeed if there are no ALGs in the MSRP path; or 382 2) When support of the sessmatch extension is indicated in a request 383 or response received from the other MSRP endpoint, use fingerprint 384 based authentication without performing SIP Identity based integrity 385 check, and thus trust the network entities in the signaling path. 387 NOTE: The second alternative is needed, in networks where ALGs are 388 present, if the user whishes to establish a TLS based communication 389 even if one of the MSRP endpoint, or the network, does not support a 390 common TLS authentication mechanism based on a pre-shared secret. As 391 defined in RFC 4975, if TLS autentication fails, users need to be 392 able to decide whether to try to establish an MSRP connection without 393 TLS protection. 395 7. IANA Considerations 397 This section registers a new SIP option-tag, according to the 398 procedures of RFC 3261. 400 7.1. IANA Registration of the sessmatch Option Tag 402 This section registers a new SIP option tag, sessmatch. The required 403 information for this registration, as specified in RFC 3261, is: 405 Name: sessmatch 407 Description: This option tag is for indicating support of the MSRP session 408 matching mechanism defined in RFC XXXX. When present in a Supported header 409 field, it indicates that the sending UA supports the session matching 410 mechanism. When present in a Require header field of a request, it indicates 411 that the reciving UA MUST support the session matching mechanism. 413 8. Acknowledgements 415 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 416 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, 417 Ted Hardie and Richard L Barnes for their guidance and input in order 418 to produce this document. 420 9. Change Log 422 [RFC EDITOR NOTE: Please remove this section when publishing] 424 Changes from draft-ietf-simple-msrp-sessmatch-10 425 o Sessmatch option-tag added, based on WG discussions and concensus. 427 Changes from draft-ietf-simple-msrp-sessmatch-08 428 o OPEN ISSUE regarding the need for a sessmatch option-tag removed. 430 Changes from draft-ietf-simple-msrp-sessmatch-07 431 o Sessmatch defined as an MSRP extension, rather than MSRP update 432 o Additional security considerations text added 434 10. References 436 10.1. Normative References 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 442 A., Peterson, J., Sparks, R., Handley, M., and E. 443 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 444 June 2002. 446 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 447 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 449 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 450 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 451 September 2007. 453 10.2. Informative References 455 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 456 Modes of Key Distribution in Multimedia Internet KEYing 457 (MIKEY)", RFC 6043, March 2011. 459 [3GPP.23.228] 460 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 461 TS 23.228 10.4.0, March 2011. 463 Authors' Addresses 465 Christer Holmberg 466 Ericsson 467 Hirsalantie 11 468 Jorvas 02420 469 Finland 471 Email: christer.holmberg@ericsson.com 473 Staffan Blau 474 Ericsson AB 475 Stockholm 12637 476 Sweden 478 Email: staffan.blau@ericsson.com