idnits 2.17.1 draft-ietf-simple-msrp-cema-03.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 (October 5, 2011) is 4587 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: April 7, 2012 E. Burger 6 Georgetown University 7 October 5, 2011 9 Connection Establishment for Media Anchoring (CEMA) for the Message 10 Session Relay Protocol (MSRP) 11 draft-ietf-simple-msrp-cema-03.txt 13 Abstract 15 This document defines a 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, '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 April 7, 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 SDP Offerer Procedures . . . . . . . . . . . . . . . 6 65 4.3. MSRP SDP Answerer Procedures . . . . . . . . . . . . . . . 8 66 4.4. Address Information Matching . . . . . . . . . . . . . . . 10 67 4.5. Usage With the Alternative Connection Model . . . . . . . 10 68 5. The SDP 'msrp-cema' attribute . . . . . . . . . . . . . . . . 11 69 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 6. Middlebox Assumptions . . . . . . . . . . . . . . . . . . . . 11 72 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6.2. MSRP Awareness . . . . . . . . . . . . . . . . . . . . . . 11 74 6.3. TCP Connection Reuse . . . . . . . . . . . . . . . . . . . 12 75 6.4. SDP Integrity . . . . . . . . . . . . . . . . . . . . . . 12 76 6.5. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 7.1. Man in the Middle . . . . . . . . . . . . . . . . . . . . 13 79 7.2. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . 13 80 7.3. TLS and Insecure Signaling . . . . . . . . . . . . . . . . 14 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 82 8.1. IANA Registration of the SDP 'msrp-cema' attribute . . . . 15 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 84 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 The Message Session Relay Protocol (MSRP) [RFC4975] expects to use 93 MSRP relays [RFC4976] as a means for Network Address Translation 94 (NAT) traversal and policy enforcement. However, many Session 95 Initiation Protocol (SIP) [RFC3261] networks, which deploy MSRP, 96 contain middleboxes. These middleboxes anchor and control media, 97 perform tasks such as NAT traversal, performance monitoring, lawful 98 intercept, address domain bridging, interconnect Service Layer 99 Agreement (SLA) policy enforcement, and so on. One example is the 100 Interconnection Border Control Function (IBCF) [GPP23228], defined by 101 the 3rd Generation Partnership Project (3GPP). The IBCF controls a 102 media relay that handles all types of SIP session media such as 103 voice, video, MSRP, etc. 105 MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], cannot 106 anchor through middleboxes. The reason is that MSRP messages have 107 routing information embedded in the message. Without an extension 108 such as CEMA, middleboxes must read the message to change the routing 109 information. This occurs because middleboxes modify the address:port 110 information in the Session Description Protocol (SDP) [RFC4566] c/m- 111 line in order to anchor media. An "active" [RFC6135] MSRP UA 112 establishes the MSRP TCP or TLS connection based on the MSRP URI of 113 the SDP 'path' attribute. This means that the MSRP connection will 114 not be routed through the middlebox, unless the middlebox also 115 modifies the MSRP URI of the topmost SDP 'path' attribute. In many 116 scenarios this will prevent the MSRP connection from being 117 established. In addition, if the middlebox modifies the MSRP URI of 118 the SDP 'path' attribute, then the MSRP URI comparison procedure 119 [RFC4975], which requires consistency between the address information 120 in the MSRP messages and the address information carried in the MSRP 121 URI of the SDP 'path' attribute, will fail. 123 The only way to achieve interoperability in this situation is for the 124 middlebox to act as an MSRP back-to-back User Agent (B2BUA). Here 125 the MSRP B2BUA acts as the endpoint for the MSRP signaling and media, 126 performs the corresponding modification in the associated MSRP 127 messages, and originates a new MSRP session towards the actual remote 128 endpoint. However, the enabling of MSRP B2BUA functionality requires 129 substantially more resource usage in the middlebox, that normally 130 result in negative performance impact. In addition, the MSRP message 131 needs to be exposed in clear text to the MSRP B2BUA, which violates 132 the end-to-end principle [RFC3724] . 134 This specification defines an MSRP extension, Connection 135 Establishment for Media Anchoring (CEMA). CEMA in most cases allows 136 MSRP endpoints to communicate through middleboxes, as defined in 137 Section 2, without a need for the middleboxes to be an MSRP B2BUA. 139 In such cases, middleboxes, that want to anchor the MSRP connection 140 simply modify the SDP c/m-line address information, similar to what 141 it does for non-MSRP media types. MSRP endpoints that support the 142 CEMA extension will use the SDP c/m-line address information for 143 establishing the TCP or TLS connection for sending and receiving MSRP 144 messages. 146 The CEMA extension is fully backward compatible. In scenarios where 147 MSRP endpoints do not support the CEMA extension, an MSRP endpoint 148 that supports the CEMA extension behaves in the same way as an MSRP 149 endpoint that does not support it. The CEMA extension only provides 150 an alternative mechanism for negotiating and providing address 151 information for the MSRP TCP connection. After the creation of the 152 MSRP connection, an MSRP endpoint that supports the CEMA extension 153 acts according to the procedures for creating MSRP messages, 154 performing checks when receiving MSRP messages defined in RFC 4975 155 and, when it is using a relay for MSRP communications, RFC 4976. 157 2. Conventions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in BCP 14, RFC 2119 162 [RFC2119]. 164 Definitions: 166 Fingerprint Based TLS Authentication: An MSRP endpoint that uses a 167 self-signed TLS certificate and sends a certificate fingerprint in 168 SDP. 170 Name Based TLS Authentication: An MSRP endpoint that uses a 171 certificate from a well known certificate authority and the other 172 endpoint matches the hostname in the received TLS communication 173 SubjectAltName parameter towards the hostname received in the MSRP 174 URI in SDP. 176 B2BUA: This is an abbreviation for back-to-back user agent. 178 MSRP B2BUA: A network element that terminates an MSRP connection from 179 one MSRP endpoint and reoriginates that connection towards another 180 MSRP endpoint. Note the MSRP B2BUA is distinct from a SIP B2BUA. A 181 SIP B2BUA terminates a SIP session and reoriginates that session 182 towards another SIP endpoint. In the context of MSRP, a SIP endpoint 183 initiates a SIP session towards another SIP endpoint. However, that 184 INVITE may go through, for example, an outbound Proxy or inbound 185 Proxy to route to the remote SIP endpoint. As part of that SIP 186 session an MSRP session, that may follow the SIP session path, is 187 negotiated. However, there is no requirement to co-locate the SIP 188 network elements with the MSRP network elements. 190 TLS B2BUA: A network element that terminates security associations 191 (SAs) from endpoints, and establishes separate SAs between itself and 192 each endpoint. 194 Middlebox: A SIP network device that modifies SDP media address:port 195 information in order to steer or anchor media flows described in the 196 SDP, including TCP and TLS connections used for MSRP communication, 197 through a media proxy function controlled by the SIP endpoint. In 198 most cases the media proxy function relays the MSRP messages without 199 modification, while in some circumstances it acts as a MSRP B2BUA. 200 Other SIP related functions, such as related to routing, modification 201 of SIP information etc, performed by the Middlebox, and whether it 202 acts a SIP B2BUA or not, is outside the scope of this document. 203 Section 5 describes additional assumptions regarding how the 204 Middlebox handles MSRP in order to support the extension defined in 205 this document. 207 This document reuses the terms answer, answerer, offer and offerer as 208 defined in RFC 3264. 210 3. Applicability Statement 212 This document defines a Message Session Relay Protocol (MSRP) 213 extension, Connection Establishment for Media Anchoring (CEMA). 214 Support of the extension is optional. The extension allows 215 Middleboxes to anchor the MSRP connection, without the need for 216 Middleboxes to modify the MSRP messages, and thus also enables a 217 secure end-to-end MSRP communication in networks where such 218 Middleboxes are deployed. The document also defines a Session 219 Description Protocol (SDP) attribute, 'msrp-cema', that MSRP 220 endpoints use to indicate support of the CEMA extension. 222 The CEMA extension is primarily intended for MSRP endpoints that 223 operate in networks in which Middleboxes that want to anchor media 224 connections are deployed, without the need for the Middleboxes to 225 enable MSRP B2BUA functionality. An example of such network is the 226 IP Multimedia Subsystem (IMS) defined by the 3rd Generation 227 Partnership Project (3GPP), which also has the capability for all 228 endpoints to use Name-based TLS Authentication. The extension is 229 also useful for other MSRP endpoints operating in other networks, but 230 that communicate with MSRP endpoints in networks with such 231 Middleboxes, unless there is a gateway between the networks that by 232 default always enable MSRP B2BUA functionality. 234 This document assumes certain behaviors on the part of Middleboxes, 235 as described in Section 6. These behaviors are not standardized. If 236 Middleboxes do not behave as assumed, then the CEMA extension does 237 not add any value over base MSRP behavior. MSRP endpoints that 238 support CEMA are required to use RFC 4975 behavior in cases where 239 they detect that the CEMA extension cannot be enabled. 241 4. Connection Establishment for Media Anchoring Mechanism 243 4.1. General 245 This section defines how an MSRP endpoint that supports the CEMA 246 extension generates SDP offers and answers for MSRP, and which SDP 247 information elements the MSRP endpoint uses when creating the TCP or 248 TLS connection for sending and receiving MSRP messages. 250 In the following cases, where there is a Middlebox in the network, 251 the CEMA extension cannot be used, and there will be a fallback to 252 the MSRP connection establishment procedures defined in RFC 4975 and 253 RFC 4976: 255 - A non-CEMA-enabled MSRP endpoint becomes "active" [RFC6135] (no 256 matter whether it uses a relay for its MSRP communication or not), as 257 it will always establish the MSRP connection using the SDP 'path' 258 attribute, which contains the address information of the remote MSRP 259 endpoint, instead of using the SDP c/m-line which contains the 260 address information of the Middlebox. 262 - A non-CEMA-enabled MSRP endpoint that uses a relay for its MSRP 263 communication becomes "passive" [RFC6135], as it cannot be assumed 264 that the MSRP endpoint inserts the address information of the relay 265 in the SDP c/m-line. 267 - A CEMA-enabled MSRP endpoint that uses a relay for its MSRP 268 communication becomes "active", since if it adds the received SDP 269 c/m-line address information to the ToPath header field of the MSRP 270 message (in order for the relay to establish the MSRP connection 271 towards the Middlebox), the session matching [RFC4975] performed by 272 the remote MSRP endpoint will fail. 274 4.2. MSRP SDP Offerer Procedures 276 When a CEMA-enabled offerer sends an SDP offer for MSRP, it generates 277 the SDP offer according to the procedures in RFC 4975. In addition, 278 the offerer follows RFC 4976 if it is using a relay for MSRP 279 communication. The offerer also performs the following additions and 280 modifications: 282 1. The offerer MUST include an SDP 'msrp-cema' attribute in the MSRP 283 media description of the SDP offer. 285 2. If the offerer is not using a relay for MSRP communication, it 286 MUST include an SDP 'setup' attribute in the MSRP media description 287 of the SDP offer, according to the procedures in RFC 6135 [RFC6135]. 289 3. If the offerer is using a relay for MSRP communication, it MUST, 290 in addition to including the address information of the relay in the 291 topmost SDP 'path' attribute, also include the address information of 292 the relay, rather than the address information of itself, in the SDP 293 c/m-line associated with the MSRP media description. In addition, it 294 MUST include an SDP 'setup:actpass' attribute in the MSRP media 295 description of the SDP offer. 297 When the offerer receives an SDP answer, if the MSRP media 298 description of the SDP answer does not contain an SDP 'msrp-cema' 299 attribute, the offerer MUST check the criteria below. If either or 300 all of the criteria is met, the offerer MUST fallback to RFC 4975 301 behavior, by sending a new SDP offer according to the procedures in 302 RFC 4975 and RFC 4976. The new offer MUST NOT contain an SDP 'msrp- 303 cema' attribute. 305 1. The SDP c/m-line address information associated with the MSRP 306 media description does not match Section 4.4 the information in the 307 MSRP URI of the 'path' attribute(s) (in which case is assumed that 308 the SDP c/m-line contains the address to a Middlebox), and the MSRP 309 endpoint will become "passive" (if the MSRP media description of the 310 SDP answer contains an SDP 'setup:active' attribute). 312 NOTE: If an MSRP URI contains a domain name, it needs to be resolved 313 into an IP address and port before it is checked against the SDP c/m- 314 line address information, in order to determine whether there address 315 information matches. 317 2. The offerer uses a relay for its MSRP communication, the SDP c/m- 318 line address information associated with the MSRP media description 319 does not match the information in the MSRP URI of the SDP 'path' 320 attribute(s) (in which case is assumed that the SDP c/m-line contains 321 the address to a Middlebox), and the offerer will become "active" 322 (either by default or if the MSRP media description of the SDP answer 323 contains an SDP 'setup:passive' attribute). 325 3. The remote MSRP endpoint, acting as an answerer, uses a relay for 326 its MSRP communication, the SDP c/m-line address information 327 associated with the MSRP media description does not match the 328 information in the MSRP URI of the SDP 'path' attributes (in which 329 case is assumed that the SDP c/m-line contains the address to a 330 Middlebox), and the MSRP offerer will become "active" (either by 331 default or if the MSRP media description of the SDP answer contains 332 an SDP 'setup:passive' attribute). 334 NOTE: As described in section 5, in the absence of the SDP 'msrp- 335 cema' attribute in the new offer, it is assumed that a Middlebox will 336 act as an MSRP B2BUA in order to anchor MSRP media. 338 The offerer can send the new offer within the existing early dialog 339 [RFC3261], or it can terminate the early dialog and establish a new 340 dialog by sending the new offer in a new initial INVITE request. 342 The offerer MAY choose to terminate the session establishment if it 343 can detect that a Middlebox acting as an MSRP B2BUA is not the 344 desired remote MSRP endpoint. 346 If the answerer uses a relay for its MSRP communication, and the SDP 347 c/m-line address information associated with the MSRP media 348 description matches one of the SDP 'path' attributes, it is assumed 349 that there is no Middlebox in the network. In that case the offerer 350 MUST fallback to RFC 4975 behavior, but it does not need to send a 351 new SDP offer. 353 In other cases, where none of the criteria above is met, and where 354 the MSRP offerer becomes "active", it MUST use the SDP c/m-line for 355 establishing the MSRP TCP connection. If the offerer becomes 356 "passive", it will wait for the answerer to establish the TCP 357 connection, according to the procedures in RFC 4975. 359 4.3. MSRP SDP Answerer Procedures 361 If the MSRP media description of the SDP offer does not contain an 362 SDP 'msrp-cema' attribute, and the SDP c/m-line address information 363 associated with the MSRP media description does not match the 364 information in the MSRP URI of the SDP 'path' attribute(s), the 365 answerer MUST either reject the offered MSRP connection (by using a 366 zero port value number in the generated SDP answer), or reject the 367 whole SDP offer carrying SIP request with a 488 Not Acceptable Here 368 [RFC3261] response. 370 NOTE: The reasons for the rejection is that the answerer assumes that 371 a middlebox, that do not support the CEMA extension, has modified the 372 c/m-line address information of the SDP offer, without enabling MSRP 373 B2BUA functionality. 375 NOTE: If an MSRP URI contains a domain name, it needs to be resolved 376 into an IP address and port before it is checked against the SDP c/m- 377 line address information, in order to determine whether there address 378 information matches. 380 If any of the criteria below is met, the answerer MUST fallback to 381 RFC 4975 behavior and generate the associated SDP answer according to 382 the procedures in RFC 4975 and RFC 4976. The answerer MUST NOT 383 insert an SDP 'msrp-cema' attribute in the MSRP media description of 384 the SDP answer. 386 1. Both MSRP endpoints are using relays for their MSRP 387 communication. The answerer can detect if the remote MSRP endpoint, 388 acting as an offerer, is using a relay for its MSRP communication if 389 the MSRP media description of the SDP offer contains multiple SDP 390 'path' attributes. 392 2. The offerer uses a relay for its MSRP communication, and will 393 become "active" (either by default or if the MSRP media description 394 of the SDP offer contains an SDP 'setup:active' attribute). Note 395 that a CEMA-enabled offerer would include an SDP 'setup:actpass' 396 attribute in the SDP offer, as described in Section 4.2. 398 3. The answerer uses a relay for MSRP communication and is not able 399 to become "passive" (if the MSRP media description of the offer 400 contains an SDP 'setup:passive' attribute. Note that an offerer is 401 not allowed to include an SDP 'setup:passive' attribute in an SDP 402 offer, as described in RFC 6135. 404 In all other cases, the answerer generates the associated SDP answer 405 according to the procedures in RFC 4975 and RFC 4976, with the 406 following additions and modifications: 408 1. The answerer MUST include an SDP 'msrp-cema' attribute in the 409 MSRP media description of the SDP answer. 411 2. If the answerer is not using a relay for MSRP communication, it 412 MUST include an SDP 'setup' attribute in the MSRP media description 413 of the answer, according to the procedures in RFC 6135. 415 3. If the answerer is using a relay for MSRP communication, it MUST, 416 in addition to including the address information of the relay in the 417 topmost SDP 'path' attribute, also include the address information of 418 the relay, rather than the address information of itself, in the SDP 419 c/m-line associated with the MSRP media description. In addition, 420 the answerer MUST include an SDP 'setup:passive' attribute in the 421 MSRP media description of the SDP answer. 423 If the answerer included an SDP 'msrp-cema' attribute in the MSRP 424 media description of the SDP answer, and if the answerer becomes 425 "active", it MUST use the received SDP c/m-line for establishing the 426 MSRP TCP or TLS connection. If the answerer becomes "passive", it 427 will wait for the offerer to establish the MSRP TCP or TLS 428 connection, according to the procedures in RFC 4975. 430 4.4. Address Information Matching 432 When comparing address information in the SDP c/m-line and an MSRP 433 URI, for address and port equivalence, the address and port values 434 are retrieved in the following ways: 436 - SDP c/m-line address information: The IP address is retrieved from 437 the SDP c- line, and the port from the associated SDP m- line for 438 MSRP. 440 - In case the SDP c- line contains a Fully Qualified Domain Name 441 (FQDN), the IP address is retrieved using DNS. 443 - MSRP URI address information: The IP address and port are retrieved 444 from the authority part of the MSRP URI. 446 - In case the authority part of the MSRP URI contains a Fully 447 Qualified Domain Name (FQDN), the IP address is retrieved using DNS, 448 according to the procedures in section 6.2 of RFC 4975. 450 NOTE: According to RFC 4975, the authority part of the MSRP URI must 451 always contain a port. 453 NOTE: Before IPv6 addresses are compared for equivalence, they need 454 to be converted into the same representation, e.g. using the 455 mechanism defined in RFC 5952 [RFC5952]. 457 NOTE: In case the DNS returns multiple records, each needs to be 458 compared against the SDP c/m- line address information. 460 NOTE: If the authority part of the MSRP URI contains special 461 characters, they are handled according to the procedures in section 462 6.1 of RFC 4975. 464 4.5. Usage With the Alternative Connection Model 466 An MSRP endpoint that supports the CEMA extension MUST support the 467 mechanism defined in RFC 6135, as it extends the number of scenarios 468 where one can use the CEMA extension. An example is where an MSRP 469 endpoint is using a relay for MSRP communication, and it needs to be 470 "passive" in order to use the CEMA extension, instead of doing a 471 fallback to RFC 4975 behavior. 473 5. The SDP 'msrp-cema' attribute 475 5.1. General 477 The SDP 'msrp-cema' attribute is used by MSRP entities to indicate 478 support of the CEMA extension, according to the procedures in 479 Sections 4.2 and 4.3. 481 5.2. Syntax 483 This section describes the syntax extensions to the ABNF syntax 484 defined in RFC 4566 required for the SDP 'msrp-cema' attribute. The 485 ABNF defined in this specification is conformant to RFC 5234 486 [RFC5234]. 488 attribute /= msrp-cema-attr 489 ;attribute defined in RFC 4566 490 msrp-cema-attr = "msrp-cema" 492 6. Middlebox Assumptions 494 6.1. General 496 This document does not specify explicit Middlebox behavior, even 497 though Middleboxes enable some of the procedures described here. 498 However, as MSRP endpoints are expected to operate in networks where 499 Middleboxes that want to anchor media are present, this document 500 makes certain assumptions regarding to how such Middleboxes behave. 502 6.2. MSRP Awareness 504 In order to support interoperability between UAs that support the 505 CEMA extension and UAs that do not support the extension, the 506 Middlebox is MSRP aware. This means that it implements MSRP B2BUA 507 functionality. The Middlebox enables that functionality in cases 508 where the offerer does not support the CEMA extension. In cases 509 where the SDP offer indicates support of the CEMA extension, the 510 Middlebox can simply modify the SDP c/m-line address information for 511 the MSRP connection. 513 In cases where the Middlebox enables MSRP B2BUA functionality, it 514 acts as an MSRP endpoint. If it does not use the CEMA procedures it 515 will never forward the SDP 'msrp-cema' attribute in SDP offers and 516 answers. 518 If the Middlebox does not implement MSRP B2BUA functionality, or does 519 not enable it when the SDP 'msrp-cema' attribute is not present in 520 the SDP offer, CEMA-enabled MSRP endpoints will in some cases be 521 unable to interoperate with non-CEMA-enabled endpoints across the 522 Middlebox. 524 6.3. TCP Connection Reuse 526 Middleboxes do not need to parse and modify the MSRP payload when 527 endpoints use the CEMA extension. A Middlebox that does not parse 528 the MSRP payload probably will not be able to reuse TCP connections 529 for multiple MSRP sessions. Instead, in order to associate an MSRP 530 message with a specific session, the Middlebox often assigns a unique 531 local address:port combination for each MSRP session. Due to this, 532 between two Middleboxes there might be a separate connection for each 533 MSRP session. 535 If the Middlebox does not assign a unique address:port combination 536 for each MSRP session, and does not parse MSRP messages, it might end 537 up forwarding MSRP messages towards the wrong destination. 539 6.4. SDP Integrity 541 This document assumes that Middleboxes are able to modify the SDP 542 address information associated with the MSRP media. Middleboxes 543 cannot be deployed in environments that require end-to-end SDP 544 integrity protection or SDP encryption. 546 NOTE: Eventhough the CEMA extension as such works with end-to-end SDP 547 protection, the main advantage of the extension is in networks where 548 Middleboxes are deployed. 550 If the Middlebox is unable to modify SDP payloads due to end-to-end 551 integrity protection, it will be either unable to anchor MSRP media, 552 or the SIP signaling might fail due to integrity violations. 554 6.5. TLS 556 When UAs use the CEMA extension, this document assumes that 557 Middleboxes relay MSRP media packets at the transport layer. The TLS 558 handshake and resulting security association (SA) can be established 559 peer-to-peer between the MSRP endpoints. The Middlebox will see 560 encrypted MSRP media packets, but is unable to inspect the clear text 561 content. 563 When UAs fall back to RFC 4975 behavior Middleboxes act as TLS 564 B2BUAs. The Middlebox decrypts MSRP media packets received from one 565 MSRP endpoint, and then re-encrypts them before sending them toward 566 the other MSRP endpoint. Middleboxes can inspect and modify the MSRP 567 message content. As CEMA does not require a Middlebox to modify the 568 MSRP content, this can be prevented if TLS is used for the MSRP 569 communication, assuming that the SIP signalling channel is end-to-end 570 integrity protected. 572 7. Security Considerations 574 7.1. Man in the Middle 576 In some cases, where MSRP B2BUA functionality does not need to be 577 enabled, the CEMA extension makes it easier for a man in the middle 578 (MiTM) to transparently insert itself in the communication between 579 MSRP endpoints in order to monitor or record unprotected MSRP 580 communication. It does not however make it easier for a MiTM to 581 monitor TLS protected MSRP, or in any significant way modify TLS 582 protected MSRP content or even find out that the packets contain MSRP 583 messages, since that would require the MiTM to implement MSRP B2BUA 584 functionality, no matter if UAs support the CEMA extension or not. 585 It would thus require the MiTM to terminate the TCP/TLS/MSRP 586 connection in both directions. MSRP endpoints SHOULD use encrypted 587 channels, if possible. For backward compability, a CEMA-enabled MSRP 588 endpoint MUST implement TLS. 590 7.2. TLS Usage 592 The CEMA extension supports the usage of name-based authentication 593 for TLS in the presence of Middleboxes. 595 If a Middlebox acts as a TLS B2BUA, MSRP endpoints will be able to 596 use fingerprint based authentication and name-based authentication 597 for TLS, no matter if they support the CEMA extension or not. In 598 such cases, as the Middlebox acts as TLS endpoints, MSRP endpoints 599 might be given an incorrect impression that there is an end-to-end 600 security association (SA) between the MSRP endpoints. 602 If a Middlebox does not act as a TLS B2BUA, fingerprint based 603 authentication will not work, as the "SIP Identity" based integrity 604 protection of SDP will break. Therefore, in addition to the 605 authentication mechanisms defined in RFC 4975, it is RECOMMENDED that 606 a CEMA-enabled MSRP endpoint also support one one of the following 607 authentication mechanisms, that do not rely on peer-to-peer SDP 608 integrity: 610 1. TLS certificates together with support of interacting with a 611 Certificate Management Service [RFC6072], to which it publishes the 612 public version of its own self-signed certificate and from which it 613 fetches on demand the public certificates of other endpoints. 615 2. TLS-PSK managed by MIKEY-TICKET Based Key Management and Key 616 Management Service [RFC6043]. Note that 3GPP has specified the 617 MIKEY-TICKET based Key Management and Key Management Service 618 authentication mechanism for the IP Multimedia Subsystem (IMS). Thus 619 it will be available in that environment. 621 When an MSRP endpoint generates an SDP offer for MSRPS, in addition 622 to the SDP attributes associated with the TLS authentication 623 mechanisms described in RFC 4975, it MUST include any information 624 elements associated with the other authentication mechanisms that it 625 supports. 627 If possible, MSRP endpoints MUST use name-based authentication. If 628 not possible, if the MSRP endpoints support a common authentication 629 mechanism, they MUST use that mechanism. If the MSRP endpoints do 630 not support such common authentication mechanism, they MUST try 631 fingerprint-based authentication, which will succeed if there are no 632 Middleboxes present. If that also fails, the MSRP endpoints MUST 633 either: 635 1. Consider the TLS authentication as failed, in accordance with RFC 636 4975; or 638 2. If the SIP signaling is integrity protected between the endpoint 639 and network elements on a hop-by-hop basis, typically through use of 640 IPsec or TLS transport, then an endpoint can depending on local 641 policy choose to trust the network endpoints in the signalling path 642 for SDP integrity and accept fingerprint based TLS authentication 643 without requiring end-to-end SDP integrity. 645 NOTE: As defined in RFC 4975, if TLS authentication fails, the user 646 needs to be able to decide whether to try anyway to establish a 647 connection with unprotected MSRP media. 649 7.3. TLS and Insecure Signaling 651 One of the side effects of relieving Middleboxes from manipulating 652 message content in CEMA provides an environment necessary for end-to- 653 end integrity of MSRP media. 655 CEMA recommends using an integrity-protected media channel, such as 656 TLS. As defined in RFC 4975, all MSRP endpoints MUST support TLS. 657 That applies also to CEMA-enabled endpoints. 659 One issue with usage of TLS is the availability of a certificate 660 infrastructure. Endpoints can always provide self-signed 661 certificates. However, this is problematic in that any endpoint can 662 masquerade as another, by providing a self-signed certificate with 663 the victim's information. 665 One of the target deployments for CEMA is the 3GPP IMS SIP network. 666 In this environment service providers provision signed certificates 667 or manage signed certificates on behalf of their subscribers. This 668 does require trusting the service provider, but those issues are 669 beyond the scope of this document. 671 Alternate key distribution mechanisms, such as DANE [DANE], PGP 672 [RFC6091], or some other technology, might become ubiquitous enough 673 to solve the key distribution problem in the future. 675 Even with seemingly end-to-end media integrity, at the time of the 676 publication of this document there are other vulnerabilities in MSRP, 677 due to vulnerabilities in the SIP signaling. If there are no 678 integrity protections on the SIP signaling, it is easy to insert 679 malicious middleboxes to alter, record, or otherwise harm the media. 680 With insecure signaling, it can be difficult for an endpoint to even 681 be aware the remote endpoint has any relationship to the expected 682 endpoint. Securing the SIP signaling does not solve all problems. 683 For example, in a SIPS environment, the endpoints have no 684 cryptographic way of validating that one or more SIP Proxies in the 685 proxy chain are not, in fact, malicious. 687 8. IANA Considerations 689 8.1. IANA Registration of the SDP 'msrp-cema' attribute 691 This document instructs IANA to add a attribute to the 'att-field 692 (media level only)' registry of the SDP parameters registry, 693 according to the information provided in this section. 695 This section registers a new SDP attribute, 'msrp-cema'. The 696 required information for this registration, as specified in RFC 4566, 697 is: 699 Contact name: Christer Holmberg 701 Contact e-mail: christer.holmberg@ericsson.com 703 Attribute name: msrp-cema 705 Type of attribute: media level 707 Purpose: This attribute is used to indicate support of 708 the MSRP Connection Establishment for Media 709 Anchoring (CEMA) extension defined in 710 RFC XXXX. When present in an MSRP media 711 description of an SDP body, it indicates 712 that the creator of the SDP supports the CEMA 713 mechanism. 715 Values: The attribute does not carry a value 717 Charset dependency: none 719 9. Acknowledgements 721 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 722 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, 723 Ted Hardie, Richard L Barnes, Inaki Baz Castillo, Saul Ibarra 724 Corretge, Cullen Jennings, Adrian Georgescu and Miguel Garcia for 725 their guidance and input in order to produce this document. 727 10. Change Log 729 [RFC EDITOR NOTE: Please remove this section when publishing] 731 Changes from draft-ietf-simple-msrp-cema-02 732 o Changes based on WGLC comments. 733 o - Editorial changes based on comments from Nancy Greene. 734 o - Editorial changes based on comments from Saul Ibarra Corretge. 735 o - Editorial changes based on comments from Christian Schmidt. 736 o - Editorial changes based on comments from Miguel Garcia. 737 o Changes based on MMUSIC SDP impact review. 738 o - Editorial changes based on comments from Miguel Garcia. 740 Changes from draft-ietf-simple-msrp-cema-01 741 o Changes based on comment from Ben Campbell. 742 o - TLS B2BUA added to definitions section. 744 o - Middlebox added. 745 o - Editorial changes. 747 Changes from draft-ietf-simple-msrp-sessmatch-13 748 o Changed the draft name, as was suggested by our AD and work group. 749 o Clean up language use, clarify language, and clean up editorial 750 and style issues. 751 o Formally defined an MSRP B2BUA. 753 Changes from draft-ietf-simple-msrp-sessmatch-12 754 o Extension name changed to Connection Establishment for Media 755 Anchoring (CEMA). 756 o Middlebox definition added. 757 o ALG terminology replaced with Middlebox. 758 o SDP attribute name changed to a=msrp-cema. 759 o Applicability Statement section expanded. 760 o Re-structuring of MSRP Answerer section. 761 o Changes based on comments from Saul Ibarra Corretge (1406111). 763 Changes from draft-ietf-simple-msrp-sessmatch-11 764 o Modification of the sessmatch mechanism. 765 o - Extension name changed to Alternative Connection Establishment 766 (ACE) 767 o - Session matching procedure no longer updated. 768 o - SDP c/m-line used for MSRP TCP connection. 769 o - sessmatch option-tag removed. 770 o - a=msrp-ace attribute defined. 771 o - Support of RFC 6135 mandatory. 773 Changes from draft-ietf-simple-msrp-sessmatch-10 774 o Sessmatch option-tag added, based on WG discussions and concensus. 776 Changes from draft-ietf-simple-msrp-sessmatch-08 777 o OPEN ISSUE regarding the need for a sessmatch option-tag removed. 779 Changes from draft-ietf-simple-msrp-sessmatch-07 780 o Sessmatch defined as an MSRP extension, rather than MSRP update 781 o Additional security considerations text added 783 11. References 785 11.1. Normative References 787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 788 Requirement Levels", BCP 14, RFC 2119, March 1997. 790 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 791 A., Peterson, J., Sparks, R., Handley, M., and E. 792 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 793 June 2002. 795 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 796 Description Protocol", RFC 4566, July 2006. 798 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 799 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 801 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 802 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 803 September 2007. 805 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 806 Specifications: ABNF", STD 68, RFC 5234, January 2008. 808 [RFC6072] Jennings, C. and J. Fischl, "Certificate Management 809 Service for the Session Initiation Protocol (SIP)", 810 RFC 6072, February 2011. 812 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 813 for the Message Session Relay Protocol (MSRP)", RFC 6135, 814 February 2011. 816 11.2. Informative References 818 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 819 and the Future of End-to-End: Reflections on the Evolution 820 of the Internet Architecture", RFC 3724, March 2004. 822 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 823 Address Text Representation", RFC 5952, August 2010. 825 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 826 Modes of Key Distribution in Multimedia Internet KEYing 827 (MIKEY)", RFC 6043, March 2011. 829 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 830 for Transport Layer Security (TLS) Authentication", 831 RFC 6091, February 2011. 833 [GPP23228] 834 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 835 TS 23.228 10.5.0, June 2011. 837 [DANE] "DNS-based Authentication of Named Entities Work Group". 839 Authors' Addresses 841 Christer Holmberg 842 Ericsson 843 Hirsalantie 11 844 Jorvas 02420 845 Finland 847 Email: christer.holmberg@ericsson.com 849 Staffan Blau 850 Ericsson 851 Stockholm 12637 852 Sweden 854 Email: staffan.blau@ericsson.com 856 Eric Burger 857 Georgetown University 858 Department of Computer Science 859 37th and O Streets, NW 860 Washington, DC 20057-1232 861 United States of America 863 Phone: 864 Fax: +1 530 267 7447 865 Email: eburger@standardstrack.com 866 URI: http://www.standardstrack.com