idnits 2.17.1 draft-ietf-simple-msrp-cema-01.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 (August 29, 2011) is 4617 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) 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 S. Blau 4 Intended status: Standards Track Ericsson 5 Expires: March 1, 2012 E. Burger 6 Georgetown University 7 August 29, 2011 9 Connection Establishment for Media Anchoring (CEMA) for the Message 10 Session Relay Protocol (MSRP) 11 draft-ietf-simple-msrp-cema-01.txt 13 Abstract 15 This document defines an Message Session Relay Protocol (MSRP) 16 extension, Connection Establishment for Media Anchoring (CEMA). 17 Support of the extension is optional. The extension allows 18 Middleboxes to anchor the MSRP connection, without the need for 19 Middleboxes to modify the MSRP messages, and thus also enables a 20 secure end-to-end MSRP communication in networks where such 21 Middleboxes are deployed. The document also defines a Session 22 Description Protocol (SDP) attribute, a=msrp-cema, that MSRP 23 endpoints use to indicate support of the CEMA extension. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 1, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 62 4. Connection Establishment for Media Anchoring Mechanism . . . . 5 63 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. MSRP Offer Procedures . . . . . . . . . . . . . . . . . . 6 65 4.3. MSRP Answer Procedures . . . . . . . . . . . . . . . . . . 7 66 4.4. Usage With the Alternative Connection Model . . . . . . . 9 67 5. Middlebox Assumptions . . . . . . . . . . . . . . . . . . . . 9 68 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.2. MSRP Awareness . . . . . . . . . . . . . . . . . . . . . . 9 70 5.3. TCP Connection Reuse . . . . . . . . . . . . . . . . . . . 9 71 5.4. SDP Integrity . . . . . . . . . . . . . . . . . . . . . . 9 72 5.5. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 6.1. Man in the Middle . . . . . . . . . . . . . . . . . . . . 10 75 6.2. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.3. TLS and Insecure Signaling . . . . . . . . . . . . . . . . 11 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 7.1. IANA Registration of the SDP a=msrp-cema Attribute . . . . 12 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 80 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 The Message Session Relay Protocol (MSRP) [RFC4975] expects to use 89 MSRP relays [RFC4976] as a means for Network Address Translation 90 (NAT) traversal and policy enforcement. However, many Session 91 Initiation Protocol (SIP) [RFC3261] networks, which deploy MSRP, 92 contain Middleboxes. These Middleboxes anchor and control media, 93 perform tasks such as NAT traversal, performance monitoring, lawful 94 intercept, address domain bridging, interconnect Service Layer 95 Agreement (SLA) policy enforcement, and so on. One example is the 96 Interconnection Border Control Function (IBCF) [GPP23228], defined by 97 the 3rd Generation Partnership Project (3GPP). The IBCF controls a 98 media relay that handles all types of SIP session media such as 99 voice, video, MSRP, etc. 101 MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], cannot 102 anchor through Middleboxes. The reason is that MSRP messages have 103 routing information embedded in the message. Without an extension 104 such as CEMA, Middleboxes must read the message to change the routing 105 information. This occurs because Middleboxes modify the address:port 106 information in the Session Description Protocol (SDP) [RFC4566] c/m- 107 line in order to anchor media. Since the active MSRP UA establishes 108 the MSRP TCP or TLS connection based on the MSRP URI of the SDP 109 a=path attribute, this means that the MSRP connection will not, 110 unless the Middlebox also modifies the MSRP URI of the topmost SDP 111 a=path attribute, be routed through the Middlebox. In many scenarios 112 this will prevent the MSRP connection from being established. In 113 addition, if the Middlebox modifies the MSRP URI of the SDP a=path 114 attribute, then the MSRP URI comparison procedure [RFC4975], which 115 requires consistency between the address information in the MSRP 116 messages and the address information carried in the MSRP URI of the 117 SDP a=path attribute, will fail. Also the matching will fail if 118 Middleboxes modify the address information in the MSRP URI of the SDP 119 a=path attribute. 121 The only way to achieve interoperability in this situation is for the 122 Middlebox to act as a MSRP back-to-back User Agent (B2BUA). Here the 123 MSRP B2BUA acts as the endpoint for the MSRP signaling and media, 124 performs the corresponding modification in the associated MSRP 125 messages, and originates a new MSRP session towards the actual remote 126 endpoint. However, the enabling of MSRP B2BUA functionality requires 127 substantially more resource usage in the Middlebox, that normally 128 result in negative performance impact. In addition, the MSRP message 129 needs to be exposed in clear text to the MSRP B2BUA, which violates 130 the end-to-end principle [RFC3724] . 132 This specification defines an MSRP extension, Connection 133 Establishment for Media Anchoring (CEMA). CEMA in most cases allows 134 MSRP endpoints to communicate through Middleboxes without a need for 135 the Middleboxes to be a MSRP B2BUA. In such cases, Middleboxes that 136 want to anchor the MSRP connection simply modify the SDP c/m-line 137 address information, similar to what it does for non-MSRP media 138 types. MSRP endpoints that support the CEMA extension will use the 139 SDP c/m-line address information for establishing the TCP or TLS 140 connection for sending and receiving MSRP messages. 142 The CEMA extension is fully backward compatible. In scenarios where 143 MSRP endpoints do not support the CEMA extension, an MSRP endpoint 144 that supports the CEMA extension behaves in the same way as an MSRP 145 endpoint that does not support it. The CEMA extension only provides 146 an alternative mechanism for negotiating and providing address 147 information for the MSRP TCP connection. After the creation of the 148 MSRP connection, an MSRP endpoint that supports the CEMA extension 149 acts according to the procedures for creating MSRP messages, 150 performing checks when receiving MSRP messages defined in RFC 4975 151 and, when it is using a relay for MSRP communications, RFC 4976. 153 2. Conventions 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in BCP 14, RFC 2119 158 [RFC2119]. 160 Definitions: 162 Fingerprint Based TLS Authentication: An MSRP endpoint that uses a 163 self-signed TLS certificate and sends a certificate fingerprint in 164 SDP. 166 Name Based TLS Authentication: An MSRP endpoint that uses a 167 certificate from a well known certificate authority and the other 168 endpoint matches the hostname in the received TLS communication 169 SubjectAltName parameter towards the hostname received in the MSRP 170 URI in SDP. 172 B2BUA: This is an abbreviation for back-to-back user agent. 174 MSRP B2BUA: A network element that terminates a MSRP connection from 175 one MSRP endpoint and reoriginates that connection towards another 176 MSRP endpoint. Note the MSRP B2BUA is distinct from a SIP B2BUA. A 177 SIP B2BUA terminates a SIP session and reoriginates that session 178 towards another SIP endpoint. In the context of MSRP, a SIP endpoint 179 initiates a SIP session towards another SIP endpoint. However, that 180 INVITE may go through, for example, an outbound Proxy or inbound 181 Proxy to route to the remote SIP endpoint. As part of that SIP 182 session a MSRP session, that may follow the SIP session path, is 183 negotiated. However, there is no requirement to co-locate the SIP 184 network elements with the MSRP network elements. 186 Middlebox: A SIP network device that modifies SDP media address:port 187 information in order to steer or anchor media flows described in the 188 SDP, including TCP and TLS connections used for MSRP communication, 189 through a media proxy function controlled by the SIP endpoint. In 190 most cases the media proxy function relays the MSRP messages without 191 modification, while in some circumstances it acts as a MSRP B2BUA. 192 Other SIP related functions, such as related to routing, modification 193 of SIP information etc., performed by the Middlebox, and whether it 194 acts a SIP B2BUA or not, is outside the scope of this document. 195 Section 5 describes additional assumptions regarding how the 196 Middlebox handles MSRP in order to support the extension defined in 197 this document. 199 3. Applicability Statement 201 This document defines an Message Session Relay Protocol (MSRP) 202 extension, Connection Establishment for Media Anchoring (CEMA). 203 Support of the extension is optional. The extension allows 204 Middleboxes to anchor the MSRP connection, without the need for 205 Middleboxes to modify the MSRP messages, and thus also enables a 206 secure end-to-end MSRP communication in networks where such 207 Middleboxes are deployed. The document also defines a Session 208 Description Protocol (SDP) attribute, a=msrp-cema, that MSRP 209 endpoints use to indicate support of the CEMA extension. 211 The CEMA extension is primarily intended for MSRP endpoints that 212 operate in networks in which Middleboxes that want to anchor media 213 connections are deployed, without the need for the Middleboxes to 214 enable MSRP B2BUA functionality. An example of such network is the 215 IP Multimedia Subsystem (IMS) defined by the 3rd Generation 216 Partnership Project (3GPP), which also has the capability for all 217 endpoints to use Name-based TLS Authentication. The extension is 218 also useful for other MSRP endpoints operating in other networks, but 219 that communicate with MSRP endpoints in networks with such 220 Middleboxes, unless there is a gateway between the networks that by 221 default always enable MSRP B2BUA functionality. 223 4. Connection Establishment for Media Anchoring Mechanism 224 4.1. General 226 This section defines how an MSRP endpoint that supports the CEMA 227 extension generates SDP offers and answers for MSRP, and what SDP 228 information elements the MSRP endpoint uses when creating the TCP or 229 TLS connection for the MSRP messages. 231 In the following cases, where there is a Middlebox in the network, 232 the CEMA extension can not be used, and there will be a fallback to 233 the MSRP connection establishment procedures defined in RFC 4975 and 234 RFC 4976: 236 - A non-CEMA-enabled MSRP endpoint becomes "active". 238 - A non-CEMA-enabled MSRP endpoint uses a relay for its MSRP 239 communication. 241 - A CEMA-enabled MSRP endpoint that uses a relay for its MSRP 242 communication becomes "active". 244 4.2. MSRP Offer Procedures 246 When a CEMA-enabled MSRP endpoint sends an SDP offer for MSRP, it 247 generates the SDP offer according to the procedures in RFC 4975. In 248 addition, the endpoint follows RFC 4976 if it is using a relay for 249 MSRP communication. The endpoint also performs the following 250 additions and modifications: 252 1. The MSRP endpoint MUST include an SDP a=msrp-cema attribute in 253 the MSRP media description of the SDP offer. 255 2. If the MSRP endpoint is not using a relay for MSRP communication, 256 it MUST include an SDP a=setup attribute in the MSRP media 257 description of the SDP offer, according to the procedures in RFC 6135 258 [RFC6135]. 260 3. If the MSRP endpoint is using a relay for MSRP communication, it 261 MUST include the address information of the relay (the MSRP URI of 262 the topmost SDP a=path attribute), rather than the address 263 information of itself, in the SDP c/m-line associated with the MSRP 264 media description. In addition, it MUST include an SDP a=setup: 265 actpass attribute in the MSRP media description of the SDP offer. 267 When the MSRP endpoint receives the associated SDP answer, the SDP 268 answer indicates that the remote MSRP endpoint accepted the offered 269 MSRP media if the port number of the MSRP media description is not 270 zero. 272 If the MSRP media description of the SDP answer does not contain an 273 SDP a=msrp-cema attribute, the MSRP endpoint MUST check the criteria 274 below. If either or both of the criteria is met, the MSRP endpoint 275 MUST fallback to RFC 4975 behavior, by sending a new SDP offer 276 according to the procedures in RFC 4975 and RFC 4976. The new offer 277 MUST NOT contain an SDP a=msrp-cema attribute. 279 1. The SDP c/m-line address information associated with the MSRP 280 media description does not match the information in the MSRP URI of 281 the topmost SDP a=path attribute, and the MSRP media description 282 contains an SDP a=setup:active attribute (indicating that the remote 283 MSRP endpoint is "active"). 285 2. The MSRP media description contains multiple SDP a=path 286 attributes, indicating the use of MSRP relays. 288 NOTE: In the absence of the SDP a=msrp-cema attribute in the new 289 offer, it is assumed that a Middlebox will act as an MSRP B2BUA in 290 order to anchor MSRP media. 292 The MSRP endpoint MAY choose to terminate the session establishment 293 if it can detect that a Middlebox acting as a MSRP B2BUA is not the 294 desired remote endpoint. 296 The MSRP endpoint can send the new offer within the existing early 297 dialog [RFC3261], or it can terminate the early dialog and establish 298 a new dialog by sending the new offer in a new initial INVITE 299 request. 301 In all other cases, where the MSRP endpoint becomes "active", it MUST 302 use the SDP c/m-line for establishing the MSRP TCP or TLS connection. 303 If the MSRP endpoint becomes "passive", it will wait for the remote 304 MSRP endpoint to establish the connection, according to the 305 procedures in RFC 4975. 307 4.3. MSRP Answer Procedures 309 If any of the criteria below is met, the MSRP endpoint MUST fallback 310 to RFC 4975 behavior and generate the associated SDP answer according 311 to the procedures in RFC 4975 and RFC 4976. The MSRP endpoint MUST 312 NOT insert an SDP a=msrp-cema attribute in the MSRP media description 313 of the SDP answer. 315 1. Both MSRP endpoints are using relays for MSRP communication. An 316 endpoint can detect the remote MSRP endpoint is using a relay for 317 MSRP communication if the MSRP media description of the SDP offer 318 contains multiple SDP a=path attributes. 320 2. The remote MSRP endpoint uses a relay for MSRP communication, and 321 will become "active" either by default or if the MSRP media 322 description of the SDP offer contains an SDP a=setup:active 323 attribute. Note that a CEMA-enabled endpoint would include an SDP 324 a=setup:actpass attribute in the SDP offer, as described in Section 325 4.2. 327 3. The MSRP endpoint uses a relay for MSRP communication and is not 328 able to become "passive". The indication for this is the MSRP media 329 description of the offer contains an SDP a=setup:passive attribute. 330 Note that an MSRP endpoint is now allowed to include an SDP a=setup: 331 passive attribute in an SDP offer, as described in RFC 6135. 333 4. The MSRP media description of the SDP offer does not contain an 334 SDP a=msrp-cema attribute, the SDP c/m-line address information 335 associated with the MSRP media description does not match the 336 information in the MSRP URI of the topmost SDP a=path attribute, and 337 the remote MSRP endpoint will become "active", either by default, or 338 if the MSRP media description of the SDP offer contains an SDP 339 a=setup:active attribute. 341 In all other cases, the MSRP endpoint generates the associated SDP 342 answer according to the procedures in RFC 4975 and RFC 4976, with the 343 following additions and modifications: 345 1. The MSRP endpoint MUST include an SDP a=msrp-cema attribute in 346 the MSRP media description of the SDP answer. 348 2. If the MSRP endpoint is not using a relay for MSRP communication, 349 it MUST include an SDP a=setup attribute in the MSRP media 350 description of the answer, according to the procedures in RFC 6135. 352 3. If the MSRP endpoint is using a relay for MSRP communication, it 353 MUST include the address information on the relay (the MSRP URI of 354 the topmost SDP a=path attribute), rather than the address 355 information of itself, in the SDP c/m-line associated with the MSRP 356 media description. In addition, it MUST include an SDP a=setup: 357 passive attribute in the MSRP media description of the SDP answer. 359 If the MSRP endpoint included an SDP a=msrp-cema attribute in the 360 MSRP media description of the SDP answer, and if the MSRP endpoint 361 becomes "active", it MUST use the received SDP c/m-line for 362 establishing the MSRP TLS connection. If the MSRP endpoint becomes 363 "passive", it will wait for the remote MSRP endpoint to establish the 364 TCP or TLS connection, according to the procedures in RFC 4975. 366 4.4. Usage With the Alternative Connection Model 368 An MSRP endpoint that supports the CEMA extension MUST support the 369 mechanism defined in RFC 6135, as it extends the number of scenarios 370 where one can use the CEMA extension. An example is where a MSRP 371 endpoint is using a relay for MSRP communication, and it needs to be 372 "passive" in order to use the CEMA extension, instead of doing a 373 fallback to RFC 4975 behavior. 375 5. Middlebox Assumptions 377 5.1. General 379 This document does not specify explicit Middlebox behavior, even 380 though Middleboxes enable some of the procedures described here. 381 However, as MSRP endpoints are expected to operate in networks where 382 Middleboxes that want to anchor media are present, this document 383 makes certain assumptions regarding to how such Middleboxes behave. 385 5.2. MSRP Awareness 387 In order to support interoperability between UAs that support the 388 CEMA extension and UAs that do not support the extension, the 389 Middlebox is MSRP aware. This means that it implements MSRP B2BUA 390 functionality. The Middlebox enables that functionality in cases 391 where the remote endpoint does not support the CEMA extension. In 392 cases where the SDP offer indicates support of the CEMA extension, 393 the Middlebox can simply modify the SDP c/m-line address information 394 for the MSRP connection. 396 5.3. TCP Connection Reuse 398 Middleboxes do not need to parse and modify the MSRP payload when 399 endpoints use the CEMA extension. A Middlebox that does not parse 400 the MSRP payload probably will not be able to reuse TCP connections 401 for multiple MSRP sessions. Instead, in order to associate an MSRP 402 message with a specific session, the Middlebox often assigns a unique 403 local address:port combination for each MSRP session. 405 5.4. SDP Integrity 407 This document assumes that Middleboxes are able to modify the SDP 408 address information associated with the MSRP media. Middleboxes 409 cannot be deployed in environments that require end-to-end SDP 410 protection using SIP identity [RFC4916]. 412 5.5. TLS 414 When UAs use the CEMA extension, Middleboxes relay MSRP media packets 415 at the transport layer. The TLS handshake and resulting security 416 association (SA) are established peer-to-peer between the MSRP 417 endpoints. The Middlebox will see encrypted MSRP media packets, but 418 is unable to inspect the clear text content. 420 When UAs fallback to RFC 4975 behavior Middleboxes act as TLS B2BUAs, 421 meaning that separate SAs are established between the Middlebox and 422 each MSRP endpoint. The Middlebox decrypts MSRP media packets 423 received from one MSRP endpoint, and then re-encrypts them before 424 sending them toward the other MSRP endpoint. Middleboxes can inspect 425 and modify the MSRP message content. 427 6. Security Considerations 429 6.1. Man in the Middle 431 In some cases, where MSRP B2BUA functionality does not need to be 432 enabled, the CEMA extension makes it easier for a man in the middle 433 (MiTM) to transparently insert itself in the communication between 434 MSRP endpoints in order to monitor or record unprotected MSRP 435 communication. It does not however make it easier for a MiTM to 436 monitor TLS protected MSRP, or in any significant way modify TLS 437 protected MSRP content or even find out that the packets contain MSRP 438 messages, since that would require the MiTM to implement MSRP B2BUA 439 functionality, no matter if UAs support the CEMA extension or not. 440 It would thus require the MiTM to terminate the TCP/TLS/MSRP 441 connection in both directions. MSRP endpoints SHOULD use encrypted 442 channels, if possible. For backward compability, a CEMA-enabled MSRP 443 endpoint MUST implement TLS. 445 6.2. TLS Usage 447 The CEMA extension supports the usage of name-based authentication 448 for TLS in the presence of Middleboxes. 450 If a Middlebox acts as a TLS B2BUA, MSRP endpoints will be able to 451 use fingerprint based authentication for TLS, no matter if they 452 support the CEMA extension or not. In such cases, as the Middlebox 453 acts as TLS endpoints, MSRP endpoints might be given an incorrect 454 impression that there is an end-to-end security association (SA) 455 between the MSRP endpoints. 457 If a Middlebox does not act as a TLS B2BUA, fingerprint based 458 authentication will not work, as the "SIP Identity" based integrity 459 protection of SDP will break. Therefore, in addition to the 460 authentication mechanisms defined in RFC 4975, it is RECOMMENDED that 461 a CEMA-enabled MSRP endpoint also supports an authentication 462 mechanism that does not rely on peer-to-peer SDP integrity. 464 It is RECOMMENDED that an MSRP endpoint support one of the following 465 authentication mechanisms: 467 1. TLS certificates together with support of interacting with a 468 Certificate Management Service [RFC6072], to which it publishes the 469 public version of its own self-signed certificate and from which it 470 fetches on demand the public certificates of other endpoints. 472 2. TLS-PSK managed by MIKEY-TICKET Based Key Management and Key 473 Management Service [RFC6043]. Note that 3GPP has specified the 474 MIKEY-TICKET based Key Management and Key Management Service 475 authentication mechanism for the IP Multimedia Subsystem (IMS). Thus 476 it will be available in that environment. 478 When an MSRP endpoint generates an SDP offer for MSRPS, in addition 479 to the SDP attributes associated with the TLS authentication 480 mechanisms described in RFC 4975, it MUST include any information 481 elements associated with the other authentication mechanisms that it 482 supports. 484 Unless the MSRP endpoints are able to use name-based authentication, 485 and they support a common authentication mechanism, they MUST use 486 that mechanism. If the MSRP endpoints do not support such common 487 authentication mechanism, they MUST try fingerprint-based 488 authentication, which will succeed if there are no Middleboxes 489 present. If that also fails, the MSRP endpoints MUST either: 491 1. Consider the TLS authentication as failed, in accordance with RFC 492 4975; or 494 2. If something like SIPS protects the SIP signaling between the 495 MSRP endpoints, use fingerprint based authentication without 496 requiring peer-to-peer SDP integrity, and thus trust the network 497 endpoints in the signaling path for SDP integrity. 499 As defined in RFC 4975, if TLS authentication fails, the user needs 500 to be able to decide whether to try to establish an MSRP connection 501 in the likely scenario of intercepted, altered, 503 6.3. TLS and Insecure Signaling 505 One of the side effects of relieving Middleboxes from manipulating 506 message content is CEMA provides an environment necessary for end-to- 507 end integrity of MSRP media. However, while CEMA provides a 508 prerequisite for end-to-end integrity, it is not sufficient. 510 CEMA recommends using an integrity-protected media channel, such as 511 TLS. As defined in RFC 4975, all MSRP endpoints MUST support TLS. 512 That applies also to CEMA-enabled endpoints. 514 One issue with usage of TLS is the availability of a certificate 515 infrastructure. Endpoints can always provide self-signed 516 certificates. However, this is problematic in that any endpoint can 517 masquerade as another, by providing a self-signed certificate with 518 the victim's information. 520 One of the target deployments for CEMA is the 3GPP IMS SIP network. 521 In this environment service providers provision signed certificates 522 or manage signed certificates on behalf of their subscribers. This 523 does require trusting the service provider, but those issues are 524 beyond the scope of this document. 526 Alternate key distribution mechanisms, such as DANE [DANE], PGP 527 [RFC6091], or some other technology, might become ubiquitous enough 528 to solve the key distribution problem in the future. 530 Even with seemingly end-to-end media integrity, at the time of the 531 publication of this document there are other vulnerabilities in MSRP, 532 due to vulnerabilities in the SIP signaling. If there are no 533 integrity protections on the SIP signaling, it is easy to insert 534 malicious Middleboxes to alter, record, or otherwise harm the media. 535 With insecure signaling, it can be difficult for an endpoint to even 536 be aware the remote endpoint has any relationship to the expected 537 endpoint. Securing the SIP signaling does not solve all problems. 538 For example, in a SIPS environment, the endpoints have no 539 cryptographic way of validating that one or more SIP Proxies in the 540 proxy chain are not, in fact, malicious. 542 7. IANA Considerations 544 7.1. IANA Registration of the SDP a=msrp-cema Attribute 546 This section registers a new SDP attribute, a=msrp-cema. The 547 required information for this registration, as specified in RFC 4566, 548 is: 550 Contact name: Christer Holmberg 552 Contact e-mail: christer.holmberg@ericsson.com 554 Attribute name: a=msrp-cema 556 Type of attribute: media level 558 Purpose: This attribute is used to indicate support of 559 the MSRP Connection Establishment for Media 560 Anchoring (CEMA) extension defined in 561 RFC XXXX. When present in an MSRP media 562 description of an SDP body, it indicates 563 that the sending UA supports the CEMA 564 mechanism. 566 Values: The attribute does not carry a value 568 Charset dependency: none 570 8. Acknowledgements 572 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 573 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, 574 Ted Hardie, Richard L Barnes, Inaki Baz Castillo, Saul Ibarra 575 Corretge, Cullen Jennings, and Adrian Georgescu for their guidance 576 and input in order to produce this document. 578 9. Change Log 580 [RFC EDITOR NOTE: Please remove this section when publishing] 582 Changes from draft-ietf-simple-msrp-sessmatch-13 583 o Changed the draft name, as was suggested by our AD and work group. 584 o Clean up language use, clarify language, and clean up editorial 585 and style issues. 586 o Formally defined a MSRP B2BUA. 588 Changes from draft-ietf-simple-msrp-sessmatch-12 589 o Extension name changed to Connection Establishment for Media 590 Anchoring (CEMA). 591 o Middlebox definition added. 592 o ALG terminology replaced with Middlebox. 593 o SDP attribute name changed to a=msrp-cema. 595 o Applicability Statement section expanded. 596 o Re-structuring of MSRP Answerer section. 597 o Changes based on comments from Saul Ibarra Corretge (1406111). 599 Changes from draft-ietf-simple-msrp-sessmatch-11 600 o Modification of the sessmatch mechanism. 601 o - Extension name changed to Alternative Connection Establishment 602 (ACE) 603 o - Session matching procedure no longer updated. 604 o - SDP c/m-line used for MSRP TCP connection. 605 o - sessmatch option-tag removed. 606 o - a=msrp-ace attribute defined. 607 o - Support of RFC 6135 mandatory. 609 Changes from draft-ietf-simple-msrp-sessmatch-10 610 o Sessmatch option-tag added, based on WG discussions and concensus. 612 Changes from draft-ietf-simple-msrp-sessmatch-08 613 o OPEN ISSUE regarding the need for a sessmatch option-tag removed. 615 Changes from draft-ietf-simple-msrp-sessmatch-07 616 o Sessmatch defined as an MSRP extension, rather than MSRP update 617 o Additional security considerations text added 619 10. References 621 10.1. Normative References 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, March 1997. 626 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 627 A., Peterson, J., Sparks, R., Handley, M., and E. 628 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 629 June 2002. 631 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 632 Description Protocol", RFC 4566, July 2006. 634 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 635 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 637 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 638 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 639 September 2007. 641 [RFC6072] Jennings, C. and J. Fischl, "Certificate Management 642 Service for the Session Initiation Protocol (SIP)", 643 RFC 6072, February 2011. 645 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 646 for the Message Session Relay Protocol (MSRP)", RFC 6135, 647 February 2011. 649 10.2. Informative References 651 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 652 and the Future of End-to-End: Reflections on the Evolution 653 of the Internet Architecture", RFC 3724, March 2004. 655 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 656 Protocol (SIP)", RFC 4916, June 2007. 658 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 659 Modes of Key Distribution in Multimedia Internet KEYing 660 (MIKEY)", RFC 6043, March 2011. 662 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 663 for Transport Layer Security (TLS) Authentication", 664 RFC 6091, February 2011. 666 [GPP23228] 667 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 668 TS 23.228 10.5.0, June 2011. 670 [DANE] "DNS-based Authentication of Named Entities Work Group". 672 Authors' Addresses 674 Christer Holmberg 675 Ericsson 676 Hirsalantie 11 677 Jorvas 02420 678 Finland 680 Email: christer.holmberg@ericsson.com 681 Staffan Blau 682 Ericsson 683 Stockholm 12637 684 Sweden 686 Email: staffan.blau@ericsson.com 688 Eric Burger 689 Georgetown University 690 Department of Computer Science 691 37th and O Streets, NW 692 Washington, DC 20057-1232 693 United States of America 695 Phone: 696 Fax: +1 530 267 7447 697 Email: eburger@standardstrack.com 698 URI: http://www.standardstrack.com