idnits 2.17.1 draft-ietf-simple-msrp-cema-02.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 (September 14, 2011) is 4608 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 17, 2012 E. Burger 6 Georgetown University 7 September 14, 2011 9 Connection Establishment for Media Anchoring (CEMA) for the Message 10 Session Relay Protocol (MSRP) 11 draft-ietf-simple-msrp-cema-02.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 17, 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 . . . . 6 63 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. MSRP Offer Procedures . . . . . . . . . . . . . . . . . . 6 65 4.3. MSRP Answer Procedures . . . . . . . . . . . . . . . . . . 8 66 4.4. Usage With the Alternative Connection Model . . . . . . . 9 67 5. Middlebox Assumptions . . . . . . . . . . . . . . . . . . . . 10 68 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.2. MSRP Awareness . . . . . . . . . . . . . . . . . . . . . . 10 70 5.3. TCP Connection Reuse . . . . . . . . . . . . . . . . . . . 10 71 5.4. SDP Integrity . . . . . . . . . . . . . . . . . . . . . . 10 72 5.5. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 6.1. Man in the Middle . . . . . . . . . . . . . . . . . . . . 11 75 6.2. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.3. TLS and Insecure Signaling . . . . . . . . . . . . . . . . 13 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 7.1. IANA Registration of the SDP a=msrp-cema Attribute . . . . 14 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 80 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 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. 119 The only way to achieve interoperability in this situation is for the 120 middlebox to act as a MSRP back-to-back User Agent (B2BUA). Here the 121 MSRP B2BUA acts as the endpoint for the MSRP signaling and media, 122 performs the corresponding modification in the associated MSRP 123 messages, and originates a new MSRP session towards the actual remote 124 endpoint. However, the enabling of MSRP B2BUA functionality requires 125 substantially more resource usage in the middlebox, that normally 126 result in negative performance impact. In addition, the MSRP message 127 needs to be exposed in clear text to the MSRP B2BUA, which violates 128 the end-to-end principle [RFC3724] . 130 This specification defines an MSRP extension, Connection 131 Establishment for Media Anchoring (CEMA). CEMA in most cases allows 132 MSRP endpoints to communicate through middleboxes, as defined in 133 Section 2, without a need for the middleboxes to be a MSRP B2BUA. In 134 such cases, middleboxes, that want to anchor the MSRP connection 135 simply modify the SDP c/m-line address information, similar to what 136 it does for non-MSRP media types. MSRP endpoints that support the 137 CEMA extension will use the SDP c/m-line address information for 138 establishing the TCP or TLS connection for sending and receiving MSRP 139 messages. 141 The CEMA extension is fully backward compatible. In scenarios where 142 MSRP endpoints do not support the CEMA extension, an MSRP endpoint 143 that supports the CEMA extension behaves in the same way as an MSRP 144 endpoint that does not support it. The CEMA extension only provides 145 an alternative mechanism for negotiating and providing address 146 information for the MSRP TCP connection. After the creation of the 147 MSRP connection, an MSRP endpoint that supports the CEMA extension 148 acts according to the procedures for creating MSRP messages, 149 performing checks when receiving MSRP messages defined in RFC 4975 150 and, when it is using a relay for MSRP communications, RFC 4976. 152 2. Conventions 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in BCP 14, RFC 2119 157 [RFC2119]. 159 Definitions: 161 Fingerprint Based TLS Authentication: An MSRP endpoint that uses a 162 self-signed TLS certificate and sends a certificate fingerprint in 163 SDP. 165 Name Based TLS Authentication: An MSRP endpoint that uses a 166 certificate from a well known certificate authority and the other 167 endpoint matches the hostname in the received TLS communication 168 SubjectAltName parameter towards the hostname received in the MSRP 169 URI in SDP. 171 B2BUA: This is an abbreviation for back-to-back user agent. 173 MSRP B2BUA: A network element that terminates a MSRP connection from 174 one MSRP endpoint and reoriginates that connection towards another 175 MSRP endpoint. Note the MSRP B2BUA is distinct from a SIP B2BUA. A 176 SIP B2BUA terminates a SIP session and reoriginates that session 177 towards another SIP endpoint. In the context of MSRP, a SIP endpoint 178 initiates a SIP session towards another SIP endpoint. However, that 179 INVITE may go through, for example, an outbound Proxy or inbound 180 Proxy to route to the remote SIP endpoint. As part of that SIP 181 session a MSRP session, that may follow the SIP session path, is 182 negotiated. However, there is no requirement to co-locate the SIP 183 network elements with the MSRP network elements. 185 TLS B2BUA: A network element that terminates security associations 186 (SAs) from endpoints, and establishes separate SAs between itself and 187 each endpoint. 189 Middlebox: A SIP network device that modifies SDP media address:port 190 information in order to steer or anchor media flows described in the 191 SDP, including TCP and TLS connections used for MSRP communication, 192 through a media proxy function controlled by the SIP endpoint. In 193 most cases the media proxy function relays the MSRP messages without 194 modification, while in some circumstances it acts as a MSRP B2BUA. 195 Other SIP related functions, such as related to routing, modification 196 of SIP information etc, performed by the Middlebox, and whether it 197 acts a SIP B2BUA or not, is outside the scope of this document. 198 Section 5 describes additional assumptions regarding how the 199 Middlebox handles MSRP in order to support the extension defined in 200 this document. 202 3. Applicability Statement 204 This document defines an Message Session Relay Protocol (MSRP) 205 extension, Connection Establishment for Media Anchoring (CEMA). 206 Support of the extension is optional. The extension allows 207 Middleboxes to anchor the MSRP connection, without the need for 208 Middleboxes to modify the MSRP messages, and thus also enables a 209 secure end-to-end MSRP communication in networks where such 210 Middleboxes are deployed. The document also defines a Session 211 Description Protocol (SDP) attribute, a=msrp-cema, that MSRP 212 endpoints use to indicate support of the CEMA extension. 214 The CEMA extension is primarily intended for MSRP endpoints that 215 operate in networks in which Middleboxes that want to anchor media 216 connections are deployed, without the need for the Middleboxes to 217 enable MSRP B2BUA functionality. An example of such network is the 218 IP Multimedia Subsystem (IMS) defined by the 3rd Generation 219 Partnership Project (3GPP), which also has the capability for all 220 endpoints to use Name-based TLS Authentication. The extension is 221 also useful for other MSRP endpoints operating in other networks, but 222 that communicate with MSRP endpoints in networks with such 223 Middleboxes, unless there is a gateway between the networks that by 224 default always enable MSRP B2BUA functionality. 226 This document assumes certain behaviors on the part of Middleboxes, 227 as described in Section 5. These behaviors are not standardized. If 228 Middleboxes do not behave as assumed, then the CEMA extension does 229 not add any value over base MSRP behavior. MSRP endpoints that 230 support CEMA are required to use RFC 4975 behavior in cases where 231 they detect that the CEMA extension cannot be enabled. 233 4. Connection Establishment for Media Anchoring Mechanism 235 4.1. General 237 This section defines how an MSRP endpoint that supports the CEMA 238 extension generates SDP offers and answers for MSRP, and what SDP 239 information elements the MSRP endpoint uses when creating the TCP or 240 TLS connection for the MSRP messages. 242 In the following cases, where there is a Middlebox in the network, 243 the CEMA extension can not be used, and there will be a fallback to 244 the MSRP connection establishment procedures defined in RFC 4975 and 245 RFC 4976: 247 - A non-CEMA-enabled MSRP endpoint becomes "active" (no matter 248 whether it uses a relay for its MSRP communication or not), as it 249 will always establish the MSRP connection using the SDP a=path 250 attribute, which contains the address information of the remote MSRP 251 endpoint, instead of using the SDP c/m-line which contains the 252 address information of the Middlebox. 254 - A non-CEMA-enabled MSRP endpoint that uses a relay for its MSRP 255 communication becomes "passive", as it can not be assumed that the 256 MSRP endpoint inserts the address information of the relay in the SDP 257 c/m-line. 259 - A CEMA-enabled MSRP endpoint that uses a relay for its MSRP 260 communication becomes "active", since if it adds the received SDP 261 c/m-line address information to the ToPath header field of the MSRP 262 message (in order for the relay to establish the MSRP connection 263 towards the Middlebox), the session matching performed by the remote 264 MSRP endpoint will fail. 266 4.2. MSRP Offer Procedures 268 When a CEMA-enabled MSRP endpoint sends an SDP offer for MSRP, it 269 generates the SDP offer according to the procedures in RFC 4975. In 270 addition, the endpoint follows RFC 4976 if it is using a relay for 271 MSRP communication. The endpoint also performs the following 272 additions and modifications: 274 1. The MSRP endpoint MUST include an SDP a=msrp-cema attribute in 275 the MSRP media description of the SDP offer. 277 2. If the MSRP endpoint is not using a relay for MSRP communication, 278 it MUST include an SDP a=setup attribute in the MSRP media 279 description of the SDP offer, according to the procedures in RFC 6135 280 [RFC6135]. 282 3. If the MSRP endpoint is using a relay for MSRP communication, it 283 MUST include the address information of the relay (the MSRP URI of 284 the topmost SDP a=path attribute), rather than the address 285 information of itself, in the SDP c/m-line associated with the MSRP 286 media description. In addition, it MUST include an SDP a=setup: 287 actpass attribute in the MSRP media description of the SDP offer. 289 If the MSRP media description of the SDP answer does not contain an 290 SDP a=msrp-cema attribute, the MSRP endpoint MUST check the criteria 291 below. If either or all of the criteria is met, the MSRP endpoint 292 MUST fallback to RFC 4975 behavior, by sending a new SDP offer 293 according to the procedures in RFC 4975 and RFC 4976. The new offer 294 MUST NOT contain an SDP a=msrp-cema attribute. 296 1. The SDP c/m-line address information associated with the MSRP 297 media description does not match the information in the MSRP URI of 298 the a=path attribute(s) (in which case is assumed that the SDP c/m- 299 line contains the address to a Middlebox), and the MSRP endpoint will 300 become "passive" (if the MSRP media description of the SDP answer 301 contains an SDP a=setup:active attribute). 303 2. The MSRP endpoint uses a relay for its MSRP communication, the 304 SDP c/m-line address information associated with the MSRP media 305 description does not match the information in the MSRP URI of the SDP 306 a=path attribute(s) (in which case is assumed that the SDP c/m-line 307 contains the address to a Middlebox), and the MSRP endpoint will 308 become "active" (either by default or if the MSRP media description 309 of the SDP answer contains an SDP a=setup:passive attribute). 311 3. The remote MSRP endpoint uses a relay for its MSRP communication, 312 the SDP c/m-line address information associated with the MSRP media 313 description does not match the information in the MSRP URI of the SDP 314 a=path attributes (in which case is assumed that the SDP c/m-line 315 contains the address to a Middlebox), and the MSRP endpoint will 316 become "active" (either by default or if the MSRP media description 317 of the SDP answer contains an SDP a=setup:passive attribute). 319 NOTE: As described in section 5, in the absence of the SDP a=msrp- 320 cema attribute in the new offer, it is assumed that a Middlebox will 321 act as an MSRP B2BUA in order to anchor MSRP media. 323 The MSRP endpoint MAY choose to terminate the session establishment 324 if it can detect that a Middlebox acting as a MSRP B2BUA is not the 325 desired remote endpoint. 327 The MSRP endpoint can send the new offer within the existing early 328 dialog [RFC3261], or it can terminate the early dialog and establish 329 a new dialog by sending the new offer in a new initial INVITE 330 request. 332 If the remote MSRP endpoint uses a relay for its MSRP communication, 333 and the SDP c/m-line address information associated with the MSRP 334 media description matches one of the SDP a=path attributes, it is 335 assumed that there is no Middlebox in the network. In that case the 336 MSRP endpoint MUST fallback to RFC 4975 behavior, but it does not 337 need to send a new SDP offer. 339 In other cases, where none of the criteria above is met, and where 340 the MSRP endpoint becomes "active", it MUST use the SDP c/m-line for 341 establishing the MSRP TCP connection. If the MSRP endpoint becomes 342 "passive", it will wait for the remote MSRP endpoint to establish the 343 TCP connection, according to the procedures in RFC 4975. 345 4.3. MSRP Answer Procedures 347 If the MSRP media description of the SDP offer does not contain an 348 SDP a=msrp-cema attribute, and the SDP c/m-line address information 349 associated with the MSRP media description does not match the 350 information in the MSRP URI of the SDP a=path attribute(s), the MSRP 351 endpoint MUST either reject the offered MSRP connection (by using a 352 zero port value number in the generated SDP answer), or reject the 353 whole SDP offer carrying SIP request with a 488 Not Acceptable Here 354 [RFC3261] response. 356 If any of the criteria below is met, the MSRP endpoint MUST fallback 357 to RFC 4975 behavior and generate the associated SDP answer according 358 to the procedures in RFC 4975 and RFC 4976. The MSRP endpoint MUST 359 NOT insert an SDP a=msrp-cema attribute in the MSRP media description 360 of the SDP answer. 362 1. Both MSRP endpoints are using relays for their MSRP 363 communication. The MSRP endpoint can detect if the remote MSRP 364 endpoint is using a relay for its MSRP communication if the MSRP 365 media description of the SDP offer contains multiple SDP a=path 366 attributes. 368 2. The remote MSRP endpoint uses a relay for its MSRP communication, 369 and will become "active" (either by default or if the MSRP media 370 description of the SDP offer contains an SDP a=setup:active 371 attribute). Note that a CEMA-enabled endpoint would include an SDP 372 a=setup:actpass attribute in the SDP offer, as described in Section 373 4.2. 375 3. The MSRP endpoint uses a relay for MSRP communication and is not 376 able to become "passive" (if the MSRP media description of the offer 377 contains an SDP a=setup:passive attribute. Note that an MSRP 378 endpoint is now allowed to include an SDP a=setup:passive attribute 379 in an SDP offer, as described in RFC 6135. 381 In all other cases, the MSRP endpoint generates the associated SDP 382 answer according to the procedures in RFC 4975 and RFC 4976, with the 383 following additions and modifications: 385 1. The MSRP endpoint MUST include an SDP a=msrp-cema attribute in 386 the MSRP media description of the SDP answer. 388 2. If the MSRP endpoint is not using a relay for MSRP communication, 389 it MUST include an SDP a=setup attribute in the MSRP media 390 description of the answer, according to the procedures in RFC 6135. 392 3. If the MSRP endpoint is using a relay for MSRP communication, it 393 MUST include the address information on the relay (the MSRP URI of 394 the topmost SDP a=path attribute), rather than the address 395 information of itself, in the SDP c/m-line associated with the MSRP 396 media description. In addition, it MUST include an SDP a=setup: 397 passive attribute in the MSRP media description of the SDP answer. 399 If the MSRP endpoint included an SDP a=msrp-cema attribute in the 400 MSRP media description of the SDP answer, and if the MSRP endpoint 401 becomes "active", it MUST use the received SDP c/m-line for 402 establishing the MSRP TCP or TLS connection. If the MSRP endpoint 403 becomes "passive", it will wait for the remote MSRP endpoint to 404 establish the MSRP TCP or TLS connection, according to the procedures 405 in RFC 4975. 407 4.4. Usage With the Alternative Connection Model 409 An MSRP endpoint that supports the CEMA extension MUST support the 410 mechanism defined in RFC 6135, as it extends the number of scenarios 411 where one can use the CEMA extension. An example is where a MSRP 412 endpoint is using a relay for MSRP communication, and it needs to be 413 "passive" in order to use the CEMA extension, instead of doing a 414 fallback to RFC 4975 behavior. 416 5. Middlebox Assumptions 418 5.1. General 420 This document does not specify explicit Middlebox behavior, even 421 though Middleboxes enable some of the procedures described here. 422 However, as MSRP endpoints are expected to operate in networks where 423 Middleboxes that want to anchor media are present, this document 424 makes certain assumptions regarding to how such Middleboxes behave. 426 5.2. MSRP Awareness 428 In order to support interoperability between UAs that support the 429 CEMA extension and UAs that do not support the extension, the 430 Middlebox is MSRP aware. This means that it implements MSRP B2BUA 431 functionality. The Middlebox enables that functionality in cases 432 where the SDP offerer does not support the CEMA extension. In cases 433 where the SDP offer indicates support of the CEMA extension, the 434 Middlebox can simply modify the SDP c/m-line address information for 435 the MSRP connection. 437 If the Middlebox does not implement MSRP B2BUA functionality, or does 438 not enable it when the SDP a=msrp-cema attribute is not present in 439 the SDP offer, CEMA-enabled MSRP endpoints will is some cases be 440 unable to interoperate with non-CEMA-enabled endpoints across the 441 Middlebox. 443 5.3. TCP Connection Reuse 445 Middleboxes do not need to parse and modify the MSRP payload when 446 endpoints use the CEMA extension. A Middlebox that does not parse 447 the MSRP payload probably will not be able to reuse TCP connections 448 for multiple MSRP sessions. Instead, in order to associate an MSRP 449 message with a specific session, the Middlebox often assigns a unique 450 local address:port combination for each MSRP session. Due to this, 451 between two Middleboxes there might be a separate connection for each 452 MSRP session. 454 If the Middlebox does not assign a unique address:port combination 455 for each MSRP session, and does not parse MSRP messages, it might end 456 up forwarding MSRP messages towards the wrong destination. 458 5.4. SDP Integrity 460 This document assumes that Middleboxes are able to modify the SDP 461 address information associated with the MSRP media. Middleboxes 462 cannot be deployed in environments that require end-to-end SDP 463 protection using SIP identity [RFC4916]. 465 If the Middlebox is unable to modify SDP payloads due to end-to-end 466 integrity protection, it will be either unable to anchor MSRP media, 467 or the SIP signaling might fail due to integrity violations. 469 5.5. TLS 471 When UAs use the CEMA extension, this document assumes that 472 Middleboxes relay MSRP media packets at the transport layer. The TLS 473 handshake and resulting security association (SA) can be established 474 peer-to-peer between the MSRP endpoints. The Middlebox will see 475 encrypted MSRP media packets, but is unable to inspect the clear text 476 content. 478 When UAs fallback to RFC 4975 behavior Middleboxes act as TLS B2BUAs. 479 The Middlebox decrypts MSRP media packets received from one MSRP 480 endpoint, and then re-encrypts them before sending them toward the 481 other MSRP endpoint. Middleboxes can inspect and modify the MSRP 482 message content. As CEMA does not require a Middlebox to modify the 483 MSRP content, this can be prevented if TLS is used for the MSRP 484 communication, assuming that the SIP signalling channel is end-to-end 485 integrity protected. 487 6. Security Considerations 489 6.1. Man in the Middle 491 In some cases, where MSRP B2BUA functionality does not need to be 492 enabled, the CEMA extension makes it easier for a man in the middle 493 (MiTM) to transparently insert itself in the communication between 494 MSRP endpoints in order to monitor or record unprotected MSRP 495 communication. It does not however make it easier for a MiTM to 496 monitor TLS protected MSRP, or in any significant way modify TLS 497 protected MSRP content or even find out that the packets contain MSRP 498 messages, since that would require the MiTM to implement MSRP B2BUA 499 functionality, no matter if UAs support the CEMA extension or not. 500 It would thus require the MiTM to terminate the TCP/TLS/MSRP 501 connection in both directions. MSRP endpoints SHOULD use encrypted 502 channels, if possible. For backward compability, a CEMA-enabled MSRP 503 endpoint MUST implement TLS. 505 6.2. TLS Usage 507 The CEMA extension supports the usage of name-based authentication 508 for TLS in the presence of Middleboxes. 510 If a Middlebox acts as a TLS B2BUA, MSRP endpoints will be able to 511 use fingerprint based authentication and name-based authentication 512 for TLS, no matter if they support the CEMA extension or not. In 513 such cases, as the Middlebox acts as TLS endpoints, MSRP endpoints 514 might be given an incorrect impression that there is an end-to-end 515 security association (SA) between the MSRP endpoints. 517 If a Middlebox does not act as a TLS B2BUA, fingerprint based 518 authentication will not work, as the "SIP Identity" based integrity 519 protection of SDP will break. Therefore, in addition to the 520 authentication mechanisms defined in RFC 4975, it is RECOMMENDED that 521 a CEMA-enabled MSRP endpoint also supports one of the following 522 authentication mechanisms, that do not rely on peer-to-peer SDP 523 integrity: 525 1. TLS certificates together with support of interacting with a 526 Certificate Management Service [RFC6072], to which it publishes the 527 public version of its own self-signed certificate and from which it 528 fetches on demand the public certificates of other endpoints. 530 2. TLS-PSK managed by MIKEY-TICKET Based Key Management and Key 531 Management Service [RFC6043]. Note that 3GPP has specified the 532 MIKEY-TICKET based Key Management and Key Management Service 533 authentication mechanism for the IP Multimedia Subsystem (IMS). Thus 534 it will be available in that environment. 536 When an MSRP endpoint generates an SDP offer for MSRPS, in addition 537 to the SDP attributes associated with the TLS authentication 538 mechanisms described in RFC 4975, it MUST include any information 539 elements associated with the other authentication mechanisms that it 540 supports. 542 If possible, MSRP endpoints MUST use name-based authentication. If 543 not possible, if the MSRP endpoints support a common authentication 544 mechanism, they MUST use that mechanism. If the MSRP endpoints do 545 not support such common authentication mechanism, they MUST try 546 fingerprint-based authentication, which will succeed if there are no 547 Middleboxes present. If that also fails, the MSRP endpoints MUST 548 either: 550 1. Consider the TLS authentication as failed, in accordance with RFC 551 4975; or 553 2. If the SIP signaling is integrity protected between the endpoint 554 and network elements on a hop-by-hop basis, typically through use of 555 IPsec or TLS transport, then an endpoint can depending on local 556 policy chose to trust the network endpoints in the signalling path 557 for SDP integrity and accept fingerprint based TLS authentication 558 without requiring end-to-end SDP integrity. 560 NOTE: As defined in RFC 4975, if TLS authentication fails, the user 561 need to be able to decide whether to try to anyway establish a 562 connection with unprotected MSRP media. 564 6.3. TLS and Insecure Signaling 566 One of the side effects of relieving Middleboxes from manipulating 567 message content is CEMA provides an environment necessary for end-to- 568 end integrity of MSRP media. 570 CEMA recommends using an integrity-protected media channel, such as 571 TLS. As defined in RFC 4975, all MSRP endpoints MUST support TLS. 572 That applies also to CEMA-enabled endpoints. 574 One issue with usage of TLS is the availability of a certificate 575 infrastructure. Endpoints can always provide self-signed 576 certificates. However, this is problematic in that any endpoint can 577 masquerade as another, by providing a self-signed certificate with 578 the victim's information. 580 One of the target deployments for CEMA is the 3GPP IMS SIP network. 581 In this environment service providers provision signed certificates 582 or manage signed certificates on behalf of their subscribers. This 583 does require trusting the service provider, but those issues are 584 beyond the scope of this document. 586 Alternate key distribution mechanisms, such as DANE [DANE], PGP 587 [RFC6091], or some other technology, might become ubiquitous enough 588 to solve the key distribution problem in the future. 590 Even with seemingly end-to-end media integrity, at the time of the 591 publication of this document there are other vulnerabilities in MSRP, 592 due to vulnerabilities in the SIP signaling. If there are no 593 integrity protections on the SIP signaling, it is easy to insert 594 malicious middleboxes to alter, record, or otherwise harm the media. 595 With insecure signaling, it can be difficult for an endpoint to even 596 be aware the remote endpoint has any relationship to the expected 597 endpoint. Securing the SIP signaling does not solve all problems. 598 For example, in a SIPS environment, the endpoints have no 599 cryptographic way of validating that one or more SIP Proxies in the 600 proxy chain are not, in fact, malicious. 602 7. IANA Considerations 603 7.1. IANA Registration of the SDP a=msrp-cema Attribute 605 This section registers a new SDP attribute, a=msrp-cema. The 606 required information for this registration, as specified in RFC 4566, 607 is: 609 Contact name: Christer Holmberg 611 Contact e-mail: christer.holmberg@ericsson.com 613 Attribute name: a=msrp-cema 615 Type of attribute: media level 617 Purpose: This attribute is used to indicate support of 618 the MSRP Connection Establishment for Media 619 Anchoring (CEMA) extension defined in 620 RFC XXXX. When present in an MSRP media 621 description of an SDP body, it indicates 622 that the sending UA supports the CEMA 623 mechanism. 625 Values: The attribute does not carry a value 627 Charset dependency: none 629 8. Acknowledgements 631 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 632 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, 633 Ted Hardie, Richard L Barnes, Inaki Baz Castillo, Saul Ibarra 634 Corretge, Cullen Jennings, and Adrian Georgescu for their guidance 635 and input in order to produce this document. 637 9. Change Log 639 [RFC EDITOR NOTE: Please remove this section when publishing] 641 Changes from draft-ietf-simple-msrp-cema-01 642 o Changes based on comment from Ben Campbell. 643 o - TLS B2BUA added to definitions section. 644 o - Middlebox added. 645 o - Editorial changes. 647 Changes from draft-ietf-simple-msrp-sessmatch-13 648 o Changed the draft name, as was suggested by our AD and work group. 649 o Clean up language use, clarify language, and clean up editorial 650 and style issues. 651 o Formally defined a MSRP B2BUA. 653 Changes from draft-ietf-simple-msrp-sessmatch-12 654 o Extension name changed to Connection Establishment for Media 655 Anchoring (CEMA). 656 o Middlebox definition added. 657 o ALG terminology replaced with Middlebox. 658 o SDP attribute name changed to a=msrp-cema. 659 o Applicability Statement section expanded. 660 o Re-structuring of MSRP Answerer section. 661 o Changes based on comments from Saul Ibarra Corretge (1406111). 663 Changes from draft-ietf-simple-msrp-sessmatch-11 664 o Modification of the sessmatch mechanism. 665 o - Extension name changed to Alternative Connection Establishment 666 (ACE) 667 o - Session matching procedure no longer updated. 668 o - SDP c/m-line used for MSRP TCP connection. 669 o - sessmatch option-tag removed. 670 o - a=msrp-ace attribute defined. 671 o - Support of RFC 6135 mandatory. 673 Changes from draft-ietf-simple-msrp-sessmatch-10 674 o Sessmatch option-tag added, based on WG discussions and concensus. 676 Changes from draft-ietf-simple-msrp-sessmatch-08 677 o OPEN ISSUE regarding the need for a sessmatch option-tag removed. 679 Changes from draft-ietf-simple-msrp-sessmatch-07 680 o Sessmatch defined as an MSRP extension, rather than MSRP update 681 o Additional security considerations text added 683 10. References 685 10.1. Normative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, March 1997. 690 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 691 A., Peterson, J., Sparks, R., Handley, M., and E. 692 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 693 June 2002. 695 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 696 Description Protocol", RFC 4566, July 2006. 698 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 699 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 701 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 702 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 703 September 2007. 705 [RFC6072] Jennings, C. and J. Fischl, "Certificate Management 706 Service for the Session Initiation Protocol (SIP)", 707 RFC 6072, February 2011. 709 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 710 for the Message Session Relay Protocol (MSRP)", RFC 6135, 711 February 2011. 713 10.2. Informative References 715 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 716 and the Future of End-to-End: Reflections on the Evolution 717 of the Internet Architecture", RFC 3724, March 2004. 719 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 720 Protocol (SIP)", RFC 4916, June 2007. 722 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 723 Modes of Key Distribution in Multimedia Internet KEYing 724 (MIKEY)", RFC 6043, March 2011. 726 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 727 for Transport Layer Security (TLS) Authentication", 728 RFC 6091, February 2011. 730 [GPP23228] 731 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 732 TS 23.228 10.5.0, June 2011. 734 [DANE] "DNS-based Authentication of Named Entities Work Group". 736 Authors' Addresses 738 Christer Holmberg 739 Ericsson 740 Hirsalantie 11 741 Jorvas 02420 742 Finland 744 Email: christer.holmberg@ericsson.com 746 Staffan Blau 747 Ericsson 748 Stockholm 12637 749 Sweden 751 Email: staffan.blau@ericsson.com 753 Eric Burger 754 Georgetown University 755 Department of Computer Science 756 37th and O Streets, NW 757 Washington, DC 20057-1232 758 United States of America 760 Phone: 761 Fax: +1 530 267 7447 762 Email: eburger@standardstrack.com 763 URI: http://www.standardstrack.com