idnits 2.17.1 draft-ietf-simple-msrp-cema-06.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 (June 26, 2012) is 4321 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE Working Group C. Holmberg 3 Internet-Draft S. Blau 4 Intended status: Standards Track Ericsson 5 Expires: December 28, 2012 E. Burger 6 Georgetown University 7 June 26, 2012 9 Connection Establishment for Media Anchoring (CEMA) for the Message 10 Session Relay Protocol (MSRP) 11 draft-ietf-simple-msrp-cema-06.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 December 28, 2012. 42 Copyright Notice 44 Copyright (c) 2012 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 . . . . . . . . . . . . . . . 7 65 4.3. MSRP SDP Answerer Procedures . . . . . . . . . . . . . . . 9 66 4.4. Address Information Matching . . . . . . . . . . . . . . . 10 67 4.5. Usage With the Alternative Connection Model . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . 12 74 6.3. TCP Connection Reuse . . . . . . . . . . . . . . . . . . . 12 75 6.4. SDP Integrity . . . . . . . . . . . . . . . . . . . . . . 12 76 6.5. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7.2. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 14 80 7.3. TLS Usage without Middleboxes . . . . . . . . . . . . . . 14 81 7.4. TLS Usage with Middleboxes . . . . . . . . . . . . . . . . 14 82 7.5. Authentication, Credentials and Key Management . . . . . . 15 83 7.6. Endpoint procedures for TLS negotiation . . . . . . . . . 16 84 7.7. Fingerprint Based Authentication . . . . . . . . . . . . . 16 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 8.1. IANA Registration of the SDP 'msrp-cema' attribute . . . . 17 87 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 88 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Introduction 96 The Message Session Relay Protocol (MSRP) [RFC4975] expects to use 97 MSRP relays [RFC4976] as a means for Network Address Translation 98 (NAT) traversal and policy enforcement. However, many Session 99 Initiation Protocol (SIP) [RFC3261] networks, which deploy MSRP, 100 contain middleboxes. These middleboxes anchor and control media, 101 perform tasks such as NAT traversal, performance monitoring, address 102 domain bridging, interconnect Service Layer Agreement (SLA) policy 103 enforcement, and so on. One example is the Interconnection Border 104 Control Function (IBCF) [GPP23228], defined by the 3rd Generation 105 Partnership Project (3GPP). The IBCF controls a media relay that 106 handles all types of SIP session media such as voice, video, MSRP, 107 etc. 109 MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], cannot 110 anchor through middleboxes. The reason is that MSRP messages have 111 routing information embedded in the message. Without an extension 112 such as CEMA, middleboxes must read the message to change the routing 113 information. This occurs because middleboxes modify the address:port 114 information in the Session Description Protocol (SDP) [RFC4566] c/m- 115 line in order to anchor media. An "active" [RFC6135] MSRP UA 116 establishes the MSRP TCP or TLS connection based on the MSRP URI of 117 the SDP 'path' attribute. This means that the MSRP connection will 118 not be routed through the middlebox, unless the middlebox also 119 modifies the MSRP URI of the topmost SDP 'path' attribute. In many 120 scenarios this will prevent the MSRP connection from being 121 established. In addition, if the middlebox modifies the MSRP URI of 122 the SDP 'path' attribute, then the MSRP URI comparison procedure 123 [RFC4975], which requires consistency between the address information 124 in the MSRP messages and the address information carried in the MSRP 125 URI of the SDP 'path' attribute, will fail. 127 The only way to achieve interoperability in this situation is for the 128 middlebox to act as an MSRP back-to-back User Agent (B2BUA). Here 129 the MSRP B2BUA acts as the endpoint for the MSRP signaling and media, 130 performs the corresponding modification in the associated MSRP 131 messages, and originates a new MSRP session towards the actual remote 132 endpoint. However, the enabling of MSRP B2BUA functionality requires 133 substantially more resource usage in the middlebox, that normally 134 result in negative performance impact. In addition, the MSRP message 135 needs to be exposed in clear text to the MSRP B2BUA, which violates 136 the end-to-end principle [RFC3724] . 138 This specification defines an MSRP extension, Connection 139 Establishment for Media Anchoring (CEMA). CEMA in most cases allows 140 MSRP endpoints to communicate through middleboxes, as defined in 141 Section 2, without a need for the middleboxes to be an MSRP B2BUA. 143 In such cases, middleboxes, that want to anchor the MSRP connection 144 simply modify the SDP c/m-line address information, similar to what 145 the middleboxes do for non-MSRP media types. MSRP endpoints that 146 support the CEMA extension will use the SDP c/m-line address 147 information for establishing the TCP or TLS connection for sending 148 and receiving MSRP messages. 150 The CEMA extension is backward compatible, meaning that CEMA-enabled 151 MSRP endpoints can communicate with non-CEMA-enabled endpoints. In 152 scenarios where MSRP endpoints do not support the CEMA extension, an 153 MSRP endpoint that supports the CEMA extension behaves in the same 154 way as an MSRP endpoint that does not support it. The CEMA extension 155 only provides an alternative mechanism for negotiating and providing 156 address information for the MSRP TCP connection. After the creation 157 of the MSRP connection, an MSRP endpoint that supports the CEMA 158 extension acts according to the procedures for creating MSRP 159 messages, performing checks when receiving MSRP messages defined in 160 RFC 4975 and, when it is using a relay for MSRP communications, RFC 161 4976. 163 2. Conventions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in BCP 14, RFC 2119 168 [RFC2119]. 170 Definitions: 172 Fingerprint Based TLS Authentication: An MSRP endpoint that uses a 173 self-signed certificate and sends a fingerprint (i.e., a hash of the 174 self-signed certificate)in SDP to the other MSRP endpoint. This 175 fingerprint binds the TLS key exchange to the signaling plane and 176 authenticates the other endpoint based on trust in the signaling 177 plane. 179 Name Based TLS Authentication: An MSRP endpoint that uses a 180 certificate which is bound to the endpoint's hostname or SIP address- 181 of-record. In the TLS session setup, the other MSRP endpoint 182 verifies that the identity associated with the certificate 183 corresponds to that of the peer (as indicated in SIP/SDP) and that 184 the binding of the identity to the public key was done by a party 185 which the endpoint trusts. This definition includes both traditional 186 certificates issued by a well-known certification authority as well 187 as self-signed certificates published via the SIP Certificate 188 Management Service [RFC6072] and other similar mechanisms. 190 B2BUA: This is an abbreviation for back-to-back user agent. 192 MSRP B2BUA: A network element that terminates an MSRP connection from 193 one MSRP endpoint and reoriginates that connection towards another 194 MSRP endpoint. Note the MSRP B2BUA is distinct from a SIP B2BUA. A 195 SIP B2BUA terminates a SIP session and reoriginates that session 196 towards another SIP endpoint. In the context of MSRP, a SIP endpoint 197 initiates a SIP session towards another SIP endpoint. However, that 198 INVITE may go through, for example, an outbound Proxy or inbound 199 Proxy to route to the remote SIP endpoint. As part of that SIP 200 session an MSRP session, that may follow the SIP session path, is 201 negotiated. However, there is no requirement to co-locate the SIP 202 network elements with the MSRP network elements. 204 TLS B2BUA: A network element that terminates security associations 205 (SAs) from endpoints, and establishes separate SAs between itself and 206 each endpoint. 208 Middlebox: A SIP network device that modifies SDP media address:port 209 information in order to steer or anchor media flows described in the 210 SDP, including TCP and TLS connections used for MSRP communication, 211 through a media proxy function controlled by the SIP endpoint. In 212 most cases the media proxy function relays the MSRP messages without 213 modification, while in some circumstances it acts as a MSRP B2BUA. 214 Other SIP related functions, such as related to routing, modification 215 of SIP information etc, performed by the Middlebox, and whether it 216 acts a SIP B2BUA or not, is outside the scope of this document. 217 Section 5 describes additional assumptions regarding how the 218 Middlebox handles MSRP in order to support the extension defined in 219 this document. 221 Media anchor: An entity that performs media anchoring inserts itself 222 in the media path of a media communication session between two 223 entities. The entity will receive, and forward, the media sent 224 between the entities. 226 This document reuses the terms answer, answerer, offer and offerer as 227 defined in RFC 3264. 229 3. Applicability Statement 231 This document defines a Message Session Relay Protocol (MSRP) 232 extension, Connection Establishment for Media Anchoring (CEMA). 233 Support of the extension is optional. The extension allows 234 Middleboxes to anchor the MSRP connection, without the need for 235 Middleboxes to modify the MSRP messages, and thus also enables a 236 secure end-to-end MSRP communication in networks where such 237 Middleboxes are deployed. The document also defines a Session 238 Description Protocol (SDP) attribute, 'msrp-cema', that MSRP 239 endpoints use to indicate support of the CEMA extension. 241 The CEMA extension is primarily intended for MSRP endpoints that 242 operate in networks in which Middleboxes that want to anchor media 243 connections are deployed, without the need for the Middleboxes to 244 enable MSRP B2BUA functionality. An example of such network is the 245 IP Multimedia Subsystem (IMS) defined by the 3rd Generation 246 Partnership Project (3GPP), which also has the capability for all 247 endpoints to use Name-based TLS Authentication. The extension is 248 also useful for other MSRP endpoints operating in other networks, but 249 that communicate with MSRP endpoints in networks with such 250 Middleboxes, unless there is a gateway between the networks that by 251 default always enable MSRP B2BUA functionality. 253 This document assumes certain behaviors on the part of Middleboxes, 254 as described in Section 6. These behaviors are not standardized. If 255 Middleboxes do not behave as assumed, then the CEMA extension does 256 not add any value over base MSRP behavior. MSRP endpoints that 257 support CEMA are required to use RFC 4975 behavior in cases where 258 they detect that the CEMA extension cannot be enabled. 260 4. Connection Establishment for Media Anchoring Mechanism 262 4.1. General 264 This section defines how an MSRP endpoint that supports the CEMA 265 extension generates SDP offers and answers for MSRP, and which SDP 266 information elements the MSRP endpoint uses when creating the TCP or 267 TLS connection for sending and receiving MSRP messages. 269 Based on the procedures described in sections 4.2 and 4.3, in the 270 following cases the CEMA extension will not be enabled, and there 271 will be a fallback to the MSRP connection establishment procedures 272 defined in RFC 4975 and RFC 4976: 274 - A non-CEMA-enabled MSRP endpoint becomes "active" [RFC6135] (no 275 matter whether it uses a relay for its MSRP communication or not), as 276 it will always establish the MSRP connection using the SDP 'path' 277 attribute, which contains the address information of the remote MSRP 278 endpoint, instead of using the SDP c/m-line which contains the 279 address information of the Middlebox. 281 - A non-CEMA-enabled MSRP endpoint that uses a relay for its MSRP 282 communication becomes "passive" [RFC6135], as it cannot be assumed 283 that the MSRP endpoint inserts the address information of the relay 284 in the SDP c/m-line. 286 - A CEMA-enabled MSRP endpoint that uses a relay for its MSRP 287 communication becomes "active", since if it adds the received SDP 288 c/m-line address information to the ToPath header field of the MSRP 289 message (in order for the relay to establish the MSRP connection 290 towards the Middlebox), the session matching [RFC4975] performed by 291 the remote MSRP endpoint will fail. 293 4.2. MSRP SDP Offerer Procedures 295 When a CEMA-enabled offerer sends an SDP offer for MSRP, it generates 296 the SDP offer according to the procedures in RFC 4975. In addition, 297 the offerer follows RFC 4976 if it is using a relay for MSRP 298 communication. The offerer also performs the following additions and 299 modifications: 301 1. The offerer MUST include an SDP 'msrp-cema' attribute in the MSRP 302 media description of the SDP offer. 304 2. If the offerer is not using a relay for MSRP communication, it 305 MUST include an SDP 'setup' attribute in the MSRP media description 306 of the SDP offer, according to the procedures in RFC 6135 [RFC6135]. 308 3. If the offerer is using a relay for MSRP communication, it MUST, 309 in addition to including the address information of the relay in the 310 topmost SDP 'path' attribute, also include the address information of 311 the relay, rather than the address information of itself, in the SDP 312 c/m-line associated with the MSRP media description. In addition, it 313 MUST include an SDP 'setup:actpass' attribute in the MSRP media 314 description of the SDP offer. 316 When the offerer receives an SDP answer, if the MSRP media 317 description of the SDP answer does not contain an SDP 'msrp-cema' 318 attribute, and if any of the following criteria below is met, the 319 offerer MUST fallback to RFC 4975 behavior, by sending a new SDP 320 offer according to the procedures in RFC 4975 and RFC 4976. The new 321 offer MUST NOT contain an SDP 'msrp-cema' attribute. 323 1. The SDP c/m-line address information associated with the MSRP 324 media description does not match Section 4.4 the information in the 325 MSRP URI of the 'path' attribute(s) (in which case is assumed that 326 the SDP c/m-line contains the address to a Middlebox), and the MSRP 327 endpoint will become "passive" (if the MSRP media description of the 328 SDP answer contains an SDP 'setup:active' attribute). 330 NOTE: If an MSRP URI contains a domain name, it needs to be resolved 331 into an IP address and port before it is checked against the SDP c/m- 332 line address information, in order to determine whether the address 333 information matches. 335 2. The offerer uses a relay for its MSRP communication, the SDP c/m- 336 line address information associated with the MSRP media description 337 does not match the information in the MSRP URI of the SDP 'path' 338 attribute(s) (in which case is assumed that the SDP c/m-line contains 339 the address to a Middlebox), and the offerer will become "active" 340 (either by default or if the MSRP media description of the SDP answer 341 contains an SDP 'setup:passive' attribute). 343 3. The remote MSRP endpoint, acting as an answerer, uses a relay for 344 its MSRP communication, the SDP c/m-line address information 345 associated with the MSRP media description does not match the 346 information in the MSRP URI of the SDP 'path' attributes (in which 347 case is assumed that the SDP c/m-line contains the address to a 348 Middlebox), and the MSRP offerer will become "active" (either by 349 default or if the MSRP media description of the SDP answer contains 350 an SDP 'setup:passive' attribute). 352 NOTE: As described in section 5, in the absence of the SDP 'msrp- 353 cema' attribute in the new offer, it is assumed that a Middlebox will 354 act as an MSRP B2BUA in order to anchor MSRP media. 356 The offerer can send the new offer within the existing early dialog 357 [RFC3261], or it can terminate the early dialog and establish a new 358 dialog by sending the new offer in a new initial INVITE request. 360 The offerer MAY choose to terminate the session establishment if it 361 can detect that a Middlebox acting as an MSRP B2BUA is not the 362 desired remote MSRP endpoint. 364 If the answerer uses a relay for its MSRP communication, and the SDP 365 c/m-line address information associated with the MSRP media 366 description matches one of the SDP 'path' attributes, it is assumed 367 that there is no Middlebox in the network. In that case the offerer 368 MUST fallback to RFC 4975 behavior, but it does not need to send a 369 new SDP offer. 371 In other cases, where none of the criteria above is met, and where 372 the MSRP offerer becomes "active", it MUST use the SDP c/m-line for 373 establishing the MSRP TCP connection. If the offerer becomes 374 "passive", it will wait for the answerer to establish the TCP 375 connection, according to the procedures in RFC 4975. 377 4.3. MSRP SDP Answerer Procedures 379 If the MSRP media description of the SDP offer does not contain an 380 SDP 'msrp-cema' attribute, and the SDP c/m-line address information 381 associated with the MSRP media description does not match the 382 information in the MSRP URI of the SDP 'path' attribute(s), the 383 answerer MUST either reject the offered MSRP connection (by using a 384 zero port value number in the generated SDP answer), or reject the 385 whole SDP offer carrying SIP request with a 488 Not Acceptable Here 386 [RFC3261] response. 388 NOTE: The reasons for the rejection is that the answerer assumes that 389 a middlebox, that do not support the CEMA extension, has modified the 390 c/m-line address information of the SDP offer, without enabling MSRP 391 B2BUA functionality. 393 NOTE: If an MSRP URI contains a domain name, it needs to be resolved 394 into an IP address and port before it is checked against the SDP c/m- 395 line address information, in order to determine whether the address 396 information matches. 398 If any of the criteria below is met, the answerer MUST fallback to 399 RFC 4975 behavior and generate the associated SDP answer according to 400 the procedures in RFC 4975 and RFC 4976. The answerer MUST NOT 401 insert an SDP 'msrp-cema' attribute in the MSRP media description of 402 the SDP answer. 404 1. Both MSRP endpoints are using relays for their MSRP 405 communication. The answerer can detect if the remote MSRP endpoint, 406 acting as an offerer, is using a relay for its MSRP communication if 407 the MSRP media description of the SDP offer contains multiple SDP 408 'path' attributes. 410 2. The offerer uses a relay for its MSRP communication, and will 411 become "active" (either by default or if the MSRP media description 412 of the SDP offer contains an SDP 'setup:active' attribute). Note 413 that a CEMA-enabled offerer would include an SDP 'setup:actpass' 414 attribute in the SDP offer, as described in Section 4.2. 416 3. The answerer uses a relay for MSRP communication and is not able 417 to become "passive" (if the MSRP media description of the offer 418 contains an SDP 'setup:passive' attribute. Note that an offerer is 419 not allowed to include an SDP 'setup:passive' attribute in an SDP 420 offer, as described in RFC 6135. 422 In all other cases, the answerer generates the associated SDP answer 423 according to the procedures in RFC 4975 and RFC 4976, with the 424 following additions and modifications: 426 1. The answerer MUST include an SDP 'msrp-cema' attribute in the 427 MSRP media description of the SDP answer. 429 2. If the answerer is not using a relay for MSRP communication, it 430 MUST include an SDP 'setup' attribute in the MSRP media description 431 of the answer, according to the procedures in RFC 6135. 433 3. If the answerer is using a relay for MSRP communication, it MUST, 434 in addition to including the address information of the relay in the 435 topmost SDP 'path' attribute, also include the address information of 436 the relay, rather than the address information of itself, in the SDP 437 c/m-line associated with the MSRP media description. In addition, 438 the answerer MUST include an SDP 'setup:passive' attribute in the 439 MSRP media description of the SDP answer. 441 If the answerer included an SDP 'msrp-cema' attribute in the MSRP 442 media description of the SDP answer, and if the answerer becomes 443 "active", it MUST use the received SDP c/m-line for establishing the 444 MSRP TCP or TLS connection. If the answerer becomes "passive", it 445 will wait for the offerer to establish the MSRP TCP or TLS 446 connection, according to the procedures in RFC 4975. 448 4.4. Address Information Matching 450 When comparing address information in the SDP c/m-line and an MSRP 451 URI, for address and port equivalence, the address and port values 452 are retrieved in the following ways: 454 - SDP c/m-line address information: The IP address is retrieved from 455 the SDP c- line, and the port from the associated SDP m- line for 456 MSRP. 458 - In case the SDP c- line contains a Fully Qualified Domain Name 459 (FQDN), the IP address is retrieved using DNS. 461 - MSRP URI address information: The IP address and port are retrieved 462 from the authority part of the MSRP URI. 464 - In case the authority part of the MSRP URI contains a Fully 465 Qualified Domain Name (FQDN), the IP address is retrieved using DNS, 466 according to the procedures in section 6.2 of RFC 4975. 468 NOTE: According to RFC 4975, the authority part of the MSRP URI must 469 always contain a port. 471 Before IPv6 addresses are compared for equivalence, they need to be 472 converted into the same representation, using the mechanism defined 473 in RFC 5952 [RFC5952]. 475 NOTE: In case the DNS returns multiple records, each needs to be 476 compared against the SDP c/m- line address information, in order to 477 find at least one match. 479 NOTE: If the authority part of the MSRP URI contains special 480 characters, they are handled according to the procedures in section 481 6.1 of RFC 4975. 483 4.5. Usage With the Alternative Connection Model 485 An MSRP endpoint that supports the CEMA extension MUST support the 486 mechanism defined in RFC 6135, as it extends the number of scenarios 487 where one can use the CEMA extension. An example is where an MSRP 488 endpoint is using a relay for MSRP communication, and it needs to be 489 "passive" in order to use the CEMA extension, instead of doing a 490 fallback to RFC 4975 behavior. 492 5. The SDP 'msrp-cema' attribute 494 5.1. General 496 The SDP 'msrp-cema' attribute is used by MSRP entities to indicate 497 support of the CEMA extension, according to the procedures in 498 Sections 4.2 and 4.3. 500 5.2. Syntax 502 This section describes the syntax extensions to the ABNF syntax 503 defined in RFC 4566 required for the SDP 'msrp-cema' attribute. The 504 ABNF defined in this specification is conformant to RFC 5234 505 [RFC5234]. 507 attribute /= msrp-cema-attr 508 ;attribute defined in RFC 4566 509 msrp-cema-attr = "msrp-cema" 511 6. Middlebox Assumptions 513 6.1. General 515 This document does not specify explicit Middlebox behavior, even 516 though Middleboxes enable some of the procedures described here. 517 However, as MSRP endpoints are expected to operate in networks where 518 Middleboxes that want to anchor media are present, this document 519 makes certain assumptions regarding to how such Middleboxes behave. 521 6.2. MSRP Awareness 523 In order to support interoperability between UAs that support the 524 CEMA extension and UAs that do not support the extension, the 525 Middlebox is MSRP aware. This means that it implements MSRP B2BUA 526 functionality. The Middlebox enables that functionality in cases 527 where the offerer does not support the CEMA extension. In cases 528 where the SDP offer indicates support of the CEMA extension, the 529 Middlebox can simply modify the SDP c/m-line address information for 530 the MSRP connection. 532 In cases where the Middlebox enables MSRP B2BUA functionality, it 533 acts as an MSRP endpoint. If it does not use the CEMA procedures it 534 will never forward the SDP 'msrp-cema' attribute in SDP offers and 535 answers. 537 If the Middlebox does not implement MSRP B2BUA functionality, or does 538 not enable it when the SDP 'msrp-cema' attribute is not present in 539 the SDP offer, CEMA-enabled MSRP endpoints will in some cases be 540 unable to interoperate with non-CEMA-enabled endpoints across the 541 Middlebox. 543 6.3. TCP Connection Reuse 545 Middleboxes do not need to parse and modify the MSRP payload when 546 endpoints use the CEMA extension. A Middlebox that does not parse 547 the MSRP payload probably will not be able to reuse TCP connections 548 for multiple MSRP sessions. Instead, in order to associate an MSRP 549 message with a specific session, the Middlebox often assigns a unique 550 local address:port combination for each MSRP session. Due to this, 551 between two Middleboxes there might be a separate connection for each 552 MSRP session. 554 If the Middlebox does not assign a unique address:port combination 555 for each MSRP session, and does not parse MSRP messages, it might end 556 up forwarding MSRP messages towards the wrong destination. 558 6.4. SDP Integrity 560 This document assumes that Middleboxes are able to modify the SDP 561 address information associated with the MSRP media. 563 NOTE: Eventhough the CEMA extension as such works with end-to-end SDP 564 protection, the main advantage of the extension is in networks where 565 Middleboxes are deployed. 567 If the Middlebox is unable to modify SDP payloads due to end-to-end 568 integrity protection, it will be unable to anchor MSRP media as the 569 SIP signaling would fail due to integrity violations. 571 6.5. TLS 573 When UAs use the CEMA extension, this document assumes that 574 Middleboxes relay MSRP media packets at the transport layer. The TLS 575 handshake and resulting security association (SA) can be established 576 peer-to-peer between the MSRP endpoints. The Middlebox will see 577 encrypted MSRP media packets, but is unable to inspect the clear text 578 content. 580 When UAs fall back to RFC 4975 behavior Middleboxes act as TLS 581 B2BUAs. The Middlebox decrypts MSRP media packets received from one 582 MSRP endpoint, and then re-encrypts them before sending them toward 583 the other MSRP endpoint. Middleboxes can inspect and modify the MSRP 584 message content. 586 7. Security Considerations 588 7.1. General 590 Unless otherwise stated, the security considerations in RFC 4975 and 591 RFC 4976 still apply. This section only describes additions and 592 changes introduced by the CEMA extension. 594 The purpose of CEMA is to enable MSRP communication over Middleboxes. 595 These Middleboxes are commonly deployed by SIP network operators, who 596 also commonly deploy firewall and routing policies that prevent media 597 sessions from working unless they traverse the Middleboxes. 599 CEMA makes it possible for Middleboxes to tunnel TLS to allow end-to- 600 end security associations between endpoints. This is an improvement 601 over the status quo, since without CEMA, the Middleboxes would be 602 forced to both read and modify the cleartext MSRP messages, which 603 would make end-to-end confidentiality and integrity protection of the 604 MSRP transport channel impossible. 606 RFC 4975 suggests two ways for MSRP endpoints to verify that the TLS 607 connection is established end-to-end. The first option is to use 608 certificates from a well known certification authority and verify 609 that the SubjectAltName matches the MSRP URI of the other side. The 610 second option is to use self-signed certificates and include a 611 fingerprint of the certificate in the SDP offer/answer. Provided the 612 signalling is integrity protected, both endpoints can verify that the 613 TLS security association is established with the correct host by 614 matching the received certificate against the received fingerprint. 616 Fingerprint based authentication is expected to be common for end 617 clients. In order to ensure the integrity of the fingerprint, RFC 618 4975 recommends using the SIP Identity mechanism [RFC4474]. However, 619 this mechanism may not be compatible with CEMA which operates under 620 the assumption that Middleboxes will modify the contents of SDP 621 offers and answers. Until a mechanism is available that enables a 622 subset of the SDP to be signed, end clients that support CEMA and use 623 fingerprint based authentication are forced to trust the entire 624 signalling path. In other words, end clients must accept the fact 625 that every signalling proxy could potentially replace the 626 fingerprints and insert a Middlebox that acts as a TLS B2BUA. 628 An alternative solution that only requires a limited trust in the 629 signaling plane is to use self-signed certificates together with the 630 SIP Certificate Management Service [RFC6072]. The security provided 631 by this solution is roughly equivalent to SIP Identity and 632 fingerprint based authentication (in fact, RFC 6072 is based on RFC 633 4474). Section 7.5 discusses this approach further. 635 In the remainder of this section we will assume that fingerprint- 636 based authentication is used without SIP Identity or similar 637 mechanisms which protects the SDP across several hops. 639 7.2. Man-in-the-Middle Attacks 641 If TLS is not used to protect MSRP, the CEMA extension might make it 642 easier for a man-in-the-middle to transparently insert itself in the 643 communication between MSRP endpoints in order to monitor or record 644 unprotected MSRP communication. This can be mitigated by the use of 645 TLS. It is therefore RECOMMENDED to use TLS [RFC5246]. It is also 646 recommended to use TLS e2e, which CEMA enables even in the case of 647 Middleboxes. According to RFC 4975, MSRP endpoints are required to 648 support TLS. This also apply to CEMA-enabled endpoints. 650 7.3. TLS Usage without Middleboxes 652 If TLS is used without Middleboxes, the security considerations in 653 RFC 4975 and RFC 4976 still apply unchanged. Note that this is not 654 the main use case for the CEMA extension. 656 7.4. TLS Usage with Middleboxes 658 This is the main use case for the CEMA extension; the endpoints 659 expect one or more Middleboxes. 661 The CEMA extension supports the usage of both name-based 662 authentication and fingerprint based authentication for TLS in the 663 presence of Middleboxes. The use of fingerprint based authentication 664 requires signaling integrity protection. This can e.g. be hop-by-hop 665 cryptographic protection or cryptographic access protection combined 666 with a suitably protected core network. As stated in section 6.4, 667 this document assumes that Middleboxes are able to modify the SDP 668 address information associated with the MSRP media. 670 If a Middlebox acts as a TLS B2BUA, the security considerations are 671 the same as without the CEMA extension. In such case the Middlebox 672 acts as TLS endpoints. 674 If a Middlebox does not act as a TLS B2BUA, TLS is e2e and the 675 Middlebox just forwards the TLS packets. This requires that both 676 peers support the CEMA extension. 678 If fingerprint based authentication is used, the MSRP endpoints might 679 not be able to decide whether the Middlebox acts as a TLS B2BUA or 680 not. But this is not an issue as the signaling network is considered 681 trusted by the endpoint (a requirement to use fingerprint based 682 authentication). 684 7.5. Authentication, Credentials and Key Management 686 One issue with usage of TLS (not specific to CEMA) is the 687 availability of a PKI. Endpoints can always provide self-signed 688 certificates and include fingerprints in the SDP offer and answer. 689 However, this relies on SDP signaling being integrity protected, 690 which may not always be the case. 692 Therefore, in addition to the authentication mechanisms defined in 693 RFC 4975, it is RECOMMENDED that a CEMA-enabled MSRP endpoint also 694 supports self-signed certificates together with the Certificate 695 Management Service [RFC6072], to which it publishes its self-signed 696 certificate and from which it fetches on demand the self-signed 697 certificates of other endpoints. 699 Alternate key distribution mechanisms, such as DANE [DANE], PGP 700 [RFC6091], MIKEY-TICKET [RFC6043] or some other technology, might 701 become ubiquitous enough to solve the key distribution problem in the 702 future. 704 One of the target deployments for CEMA is the 3GPP IMS SIP network. 705 In this environment authentication and credential management is less 706 of a problem as the SDP signaling is mostly considered trusted, 707 service providers provision signed certificates or manage signed 708 certificates on behalf of their subscribers, and MIKEY-TICKET is 709 available. Some of these options require trusting the service 710 provider, but those issues are beyond the scope of this document. 712 7.6. Endpoint procedures for TLS negotiation 714 The CEMA extension does not change the endpoint procedures for TLS 715 negotiation. As in RFC 4975, the MSRP endpoint uses the negotiation 716 mechanisms in SDP and then the TLS handshake to agree on a mechanisms 717 and algorithms that both support. The mechanisms can be divided in 718 three different security levels: 720 - MSRPS: Security Mechanisms that do not rely on trusted signaling 721 such as name based authentication 723 - MSRPS: Mechanisms that do rely on trusted signaling such as 724 fingerprint based authentication 726 - MSRP: Unprotected 728 If the endpoint uses security mechanisms that does not rely on 729 trusted signaling the endpoint can detect if a Middlebox that acts as 730 a B2BUA is inserted. It is therefore RECOMMENDED to use such a 731 mechanism. 733 If the endpoint uses security mechanisms that rely on trusted 734 signaling the endpoint may not be able to detect if a Middlebox that 735 acts as a B2BUA is inserted (by the trusted network operator). To be 736 able to eavesdrop a Middlebox must do an active "attack" on the setup 737 signaling. A Middlebox cannot insert itself at a later point. 739 If unprotected MSRP is used, the endpoint cannot detect if a 740 Middlebox that acts as a B2BUA is inserted and Middleboxes may be 741 inserted at any time during the session. 743 The mechanism in RFC 6072 [RFC6072] provides end-to-end security 744 without relying on trust in the signaling, and eases the use and 745 deployment of name based authentication. 747 The procedures for choosing and offering name based authentication, 748 fingerprint based authentication, and unprotected MSRP as described 749 in RFC 4975 still apply. 751 7.7. Fingerprint Based Authentication 753 If the endpoint cannot use a key management protocol that does not 754 rely on trust in the signaling such as name based authentication, the 755 only alternative is fingerprint based authentication. 757 The use of fingerprint based authentication requires integrity 758 protection of the signaling plane. This can e.g. be hop-by-hop 759 cryptographic protection or cryptographic access protection combined 760 with a suitably protected core network. Unless cryptographic end-to- 761 end SDP integrity protection or encryption is used this may be hard 762 for the endpoint to decide. In the end it is up to the endpoint to 763 decide whether the signaling path is trusted or not. 765 How this decision is done is implementation specific, but normally 766 signaling over the internet SHOULD NOT be trusted. Signaling over a 767 local or closed network might be trusted. Such networks can e.g. be 768 a closed enterprise network or a network operated by an operator that 769 the end user trusts. In e.g. IMS the signaling traffic in the 770 access network is integrity protected and the traffic is routed over 771 a closed network separated from the Internet. If the network is not 772 trusted the endpoints SHOULD NOT use fingerprint authentication. 774 It should however be noted that using fingerprint based 775 authentication over an insecure network increases the security 776 compared to unencrypted MSRP. In order to intercept the plaintext 777 media when fingerprint based authentication is used, the attacker is 778 required to be present on both the signaling and media paths and 779 actively modify the traffic. There is no way for the endpoints to 780 discover when such an attack is taking place though. A client using 781 DTLS-SRTP [RFC5764] for VoIP media security might wish to use 782 fingerprint based authentication also for MSRP media security. 784 MSRPS with fingerprint based authentication is vulnerable to attacks 785 due to vulnerabilities in the SIP signaling. If there are weaknesses 786 in the integrity protections on the SIP signaling, an attacker may 787 insert malicious Middleboxes to alter, record, or otherwise harm the 788 media. With insecure signaling, it can be difficult for an endpoint 789 to even be aware the remote endpoint has any relationship to the 790 expected endpoint. Securing the SIP signaling does not solve all 791 problems. For example, in a SIPS environment, the endpoints have no 792 cryptographic way of validating that one or more SIP Proxies in the 793 proxy chain are not, in fact, malicious. 795 8. IANA Considerations 797 8.1. IANA Registration of the SDP 'msrp-cema' attribute 799 This document instructs IANA to add a attribute to the 'att-field 800 (media level only)' registry of the SDP parameters registry, 801 according to the information provided in this section. 803 This section registers a new SDP attribute, 'msrp-cema'. The 804 required information for this registration, as specified in RFC 4566, 805 is: 807 Contact name: Christer Holmberg 809 Contact e-mail: christer.holmberg@ericsson.com 811 Attribute name: msrp-cema 813 Type of attribute: media level 815 Purpose: This attribute is used to indicate support of 816 the MSRP Connection Establishment for Media 817 Anchoring (CEMA) extension defined in 818 RFC XXXX. When present in an MSRP media 819 description of an SDP body, it indicates 820 that the creator of the SDP supports the CEMA 821 mechanism. 823 Values: The attribute does not carry a value 825 Charset dependency: none 827 9. Acknowledgements 829 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 830 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, 831 Ted Hardie, Richard L Barnes, Inaki Baz Castillo, Saul Ibarra 832 Corretge, Cullen Jennings, Adrian Georgescu, Miguel Garcia and Paul 833 Kyzivat for their guidance and input in order to produce this 834 document. 836 Thanks to John Mattsson, Oscar Ohlsson and Ben Campbell for their 837 help to restructure the Security Considerations section, based on the 838 feedback from IESG. 840 10. Change Log 842 [RFC EDITOR NOTE: Please remove this section when publishing] 844 Changes from draft-ietf-simple-msrp-cema-05 845 o Changes based on additional IESG comments from Stephen Farrell. 846 o Changes based on IESG comments from Sean Turner. 847 o Changes based on WGLC comments from Paul Kyzivat. 848 o Changes based on WGLC comments from Nancy Greene. 849 o Changes based on WGLC comments from Ben Campbell. 850 o - Name based TLS authentication definition enchanced. 852 o - Section 7.1 modified and enhanced. 853 o - Required support of TLS explicitly added to section 7.2. 854 o - "Physical trust" wording removed from section 7.4 and 7.7. 856 Changes from draft-ietf-simple-msrp-cema-04 857 o Changes based on additional IESG comments from Stephen Farrell. 858 o - 'Media anchor' definition added. 859 o - TLS reference made normative. 860 o - MIKEY-TICKET recommendation removed. 861 o - Editorial clarifications. 863 Changes from draft-ietf-simple-msrp-cema-03 864 o Security Considerations sections re-written based on IESG 865 comments. 866 o Changes based on IESG comments from Peter Saint-Andre. 867 o Changes based on IESG comments from Robert Sparks. 868 o Changes based on IESG comments from Stephen Farrell. 869 o Changes based on IESG comments from Pete Resnick. 871 Changes from draft-ietf-simple-msrp-cema-02 872 o Changes based on WGLC comments. 873 o - Editorial changes based on comments from Nancy Greene. 874 o - Editorial changes based on comments from Saul Ibarra Corretge. 875 o - Editorial changes based on comments from Christian Schmidt. 876 o - Editorial changes based on comments from Miguel Garcia. 877 o Changes based on MMUSIC SDP impact review. 878 o - Editorial changes based on comments from Miguel Garcia. 880 Changes from draft-ietf-simple-msrp-cema-01 881 o Changes based on comment from Ben Campbell. 882 o - TLS B2BUA added to definitions section. 883 o - Middlebox added. 884 o - Editorial changes. 886 Changes from draft-ietf-simple-msrp-sessmatch-13 887 o Changed the draft name, as was suggested by our AD and work group. 888 o Clean up language use, clarify language, and clean up editorial 889 and style issues. 890 o Formally defined an MSRP B2BUA. 892 Changes from draft-ietf-simple-msrp-sessmatch-12 893 o Extension name changed to Connection Establishment for Media 894 Anchoring (CEMA). 895 o Middlebox definition added. 896 o ALG terminology replaced with Middlebox. 897 o SDP attribute name changed to a=msrp-cema. 899 o Applicability Statement section expanded. 900 o Re-structuring of MSRP Answerer section. 901 o Changes based on comments from Saul Ibarra Corretge (1406111). 903 Changes from draft-ietf-simple-msrp-sessmatch-11 904 o Modification of the sessmatch mechanism. 905 o - Extension name changed to Alternative Connection Establishment 906 (ACE) 907 o - Session matching procedure no longer updated. 908 o - SDP c/m-line used for MSRP TCP connection. 909 o - sessmatch option-tag removed. 910 o - a=msrp-ace attribute defined. 911 o - Support of RFC 6135 mandatory. 913 Changes from draft-ietf-simple-msrp-sessmatch-10 914 o Sessmatch option-tag added, based on WG discussions and concensus. 916 Changes from draft-ietf-simple-msrp-sessmatch-08 917 o OPEN ISSUE regarding the need for a sessmatch option-tag removed. 919 Changes from draft-ietf-simple-msrp-sessmatch-07 920 o Sessmatch defined as an MSRP extension, rather than MSRP update 921 o Additional security considerations text added 923 11. References 925 11.1. Normative References 927 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 928 Requirement Levels", BCP 14, RFC 2119, March 1997. 930 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 931 A., Peterson, J., Sparks, R., Handley, M., and E. 932 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 933 June 2002. 935 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 936 Description Protocol", RFC 4566, July 2006. 938 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 939 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 941 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 942 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 943 September 2007. 945 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 946 Specifications: ABNF", STD 68, RFC 5234, January 2008. 948 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 949 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 951 [RFC6072] Jennings, C. and J. Fischl, "Certificate Management 952 Service for the Session Initiation Protocol (SIP)", 953 RFC 6072, February 2011. 955 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 956 for the Message Session Relay Protocol (MSRP)", RFC 6135, 957 February 2011. 959 11.2. Informative References 961 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 962 and the Future of End-to-End: Reflections on the Evolution 963 of the Internet Architecture", RFC 3724, March 2004. 965 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 966 Authenticated Identity Management in the Session 967 Initiation Protocol (SIP)", RFC 4474, August 2006. 969 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 970 Security (DTLS) Extension to Establish Keys for the Secure 971 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 973 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 974 Address Text Representation", RFC 5952, August 2010. 976 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 977 Modes of Key Distribution in Multimedia Internet KEYing 978 (MIKEY)", RFC 6043, March 2011. 980 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 981 for Transport Layer Security (TLS) Authentication", 982 RFC 6091, February 2011. 984 [GPP23228] 985 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 986 TS 23.228 10.5.0, June 2011. 988 [DANE] "DNS-based Authentication of Named Entities Work Group". 990 Authors' Addresses 992 Christer Holmberg 993 Ericsson 994 Hirsalantie 11 995 Jorvas 02420 996 Finland 998 Email: christer.holmberg@ericsson.com 1000 Staffan Blau 1001 Ericsson 1002 Stockholm 12637 1003 Sweden 1005 Email: staffan.blau@ericsson.com 1007 Eric Burger 1008 Georgetown University 1009 Department of Computer Science 1010 37th and O Streets, NW 1011 Washington, DC 20057-1232 1012 United States of America 1014 Phone: 1015 Fax: +1 530 267 7447 1016 Email: eburger@standardstrack.com 1017 URI: http://www.standardstrack.com