idnits 2.17.1 draft-ietf-simple-msrp-cema-04.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 (April 17, 2012) is 4393 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 informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 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: October 19, 2012 E. Burger 6 Georgetown University 7 April 17, 2012 9 Connection Establishment for Media Anchoring (CEMA) for the Message 10 Session Relay Protocol (MSRP) 11 draft-ietf-simple-msrp-cema-04.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 October 19, 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 . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . 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. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7.2. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 13 80 7.3. TLS Usage without Middleboxes . . . . . . . . . . . . . . 13 81 7.4. TLS Usage with Middleboxes . . . . . . . . . . . . . . . . 14 82 7.5. Authentication, Credentials and Key Management . . . . . . 14 83 7.6. Endpoint procedures for TLS negotiation . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . 17 88 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 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 it does for non-MSRP media types. MSRP endpoints that support the 146 CEMA extension will use the SDP c/m-line address information for 147 establishing the TCP or TLS connection for sending and receiving MSRP 148 messages. 150 The CEMA extension is fully backward compatible. In scenarios where 151 MSRP endpoints do not support the CEMA extension, an MSRP endpoint 152 that supports the CEMA extension behaves in the same way as an MSRP 153 endpoint that does not support it. The CEMA extension only provides 154 an alternative mechanism for negotiating and providing address 155 information for the MSRP TCP connection. After the creation of the 156 MSRP connection, an MSRP endpoint that supports the CEMA extension 157 acts according to the procedures for creating MSRP messages, 158 performing checks when receiving MSRP messages defined in RFC 4975 159 and, when it is using a relay for MSRP communications, RFC 4976. 161 2. Conventions 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in BCP 14, RFC 2119 166 [RFC2119]. 168 Definitions: 170 Fingerprint Based TLS Authentication: An MSRP endpoint that uses a 171 self-signed certificate and sends a fingerprint (i.e., a hash of the 172 self-signed certificate)in SDP to the other MSRP endpoint. This 173 fingerprint binds the TLS key exchange to the signaling plane and 174 authenticates the other endpoint based on trust in the signaling 175 plane. 177 Name Based TLS Authentication: An MSRP endpoint that uses a 178 certificate from a trusted certification authority and the other 179 endpoint matches the hostname in the received TLS communication 180 SubjectAltName extension towards the hostname received in the MSRP 181 URI in SDP. 183 B2BUA: This is an abbreviation for back-to-back user agent. 185 MSRP B2BUA: A network element that terminates an MSRP connection from 186 one MSRP endpoint and reoriginates that connection towards another 187 MSRP endpoint. Note the MSRP B2BUA is distinct from a SIP B2BUA. A 188 SIP B2BUA terminates a SIP session and reoriginates that session 189 towards another SIP endpoint. In the context of MSRP, a SIP endpoint 190 initiates a SIP session towards another SIP endpoint. However, that 191 INVITE may go through, for example, an outbound Proxy or inbound 192 Proxy to route to the remote SIP endpoint. As part of that SIP 193 session an MSRP session, that may follow the SIP session path, is 194 negotiated. However, there is no requirement to co-locate the SIP 195 network elements with the MSRP network elements. 197 TLS B2BUA: A network element that terminates security associations 198 (SAs) from endpoints, and establishes separate SAs between itself and 199 each endpoint. 201 Middlebox: A SIP network device that modifies SDP media address:port 202 information in order to steer or anchor media flows described in the 203 SDP, including TCP and TLS connections used for MSRP communication, 204 through a media proxy function controlled by the SIP endpoint. In 205 most cases the media proxy function relays the MSRP messages without 206 modification, while in some circumstances it acts as a MSRP B2BUA. 207 Other SIP related functions, such as related to routing, modification 208 of SIP information etc, performed by the Middlebox, and whether it 209 acts a SIP B2BUA or not, is outside the scope of this document. 210 Section 5 describes additional assumptions regarding how the 211 Middlebox handles MSRP in order to support the extension defined in 212 this document. 214 This document reuses the terms answer, answerer, offer and offerer as 215 defined in RFC 3264. 217 3. Applicability Statement 219 This document defines a Message Session Relay Protocol (MSRP) 220 extension, Connection Establishment for Media Anchoring (CEMA). 221 Support of the extension is optional. The extension allows 222 Middleboxes to anchor the MSRP connection, without the need for 223 Middleboxes to modify the MSRP messages, and thus also enables a 224 secure end-to-end MSRP communication in networks where such 225 Middleboxes are deployed. The document also defines a Session 226 Description Protocol (SDP) attribute, 'msrp-cema', that MSRP 227 endpoints use to indicate support of the CEMA extension. 229 The CEMA extension is primarily intended for MSRP endpoints that 230 operate in networks in which Middleboxes that want to anchor media 231 connections are deployed, without the need for the Middleboxes to 232 enable MSRP B2BUA functionality. An example of such network is the 233 IP Multimedia Subsystem (IMS) defined by the 3rd Generation 234 Partnership Project (3GPP), which also has the capability for all 235 endpoints to use Name-based TLS Authentication. The extension is 236 also useful for other MSRP endpoints operating in other networks, but 237 that communicate with MSRP endpoints in networks with such 238 Middleboxes, unless there is a gateway between the networks that by 239 default always enable MSRP B2BUA functionality. 241 This document assumes certain behaviors on the part of Middleboxes, 242 as described in Section 6. These behaviors are not standardized. If 243 Middleboxes do not behave as assumed, then the CEMA extension does 244 not add any value over base MSRP behavior. MSRP endpoints that 245 support CEMA are required to use RFC 4975 behavior in cases where 246 they detect that the CEMA extension cannot be enabled. 248 4. Connection Establishment for Media Anchoring Mechanism 250 4.1. General 252 This section defines how an MSRP endpoint that supports the CEMA 253 extension generates SDP offers and answers for MSRP, and which SDP 254 information elements the MSRP endpoint uses when creating the TCP or 255 TLS connection for sending and receiving MSRP messages. 257 Based on the procedures described in sections 4.2 and 4.3, in the 258 following cases the CEMA extension will not be enabled, and there 259 will be a fallback to the MSRP connection establishment procedures 260 defined in RFC 4975 and RFC 4976: 262 - A non-CEMA-enabled MSRP endpoint becomes "active" [RFC6135] (no 263 matter whether it uses a relay for its MSRP communication or not), as 264 it will always establish the MSRP connection using the SDP 'path' 265 attribute, which contains the address information of the remote MSRP 266 endpoint, instead of using the SDP c/m-line which contains the 267 address information of the Middlebox. 269 - A non-CEMA-enabled MSRP endpoint that uses a relay for its MSRP 270 communication becomes "passive" [RFC6135], as it cannot be assumed 271 that the MSRP endpoint inserts the address information of the relay 272 in the SDP c/m-line. 274 - A CEMA-enabled MSRP endpoint that uses a relay for its MSRP 275 communication becomes "active", since if it adds the received SDP 276 c/m-line address information to the ToPath header field of the MSRP 277 message (in order for the relay to establish the MSRP connection 278 towards the Middlebox), the session matching [RFC4975] performed by 279 the remote MSRP endpoint will fail. 281 4.2. MSRP SDP Offerer Procedures 283 When a CEMA-enabled offerer sends an SDP offer for MSRP, it generates 284 the SDP offer according to the procedures in RFC 4975. In addition, 285 the offerer follows RFC 4976 if it is using a relay for MSRP 286 communication. The offerer also performs the following additions and 287 modifications: 289 1. The offerer MUST include an SDP 'msrp-cema' attribute in the MSRP 290 media description of the SDP offer. 292 2. If the offerer is not using a relay for MSRP communication, it 293 MUST include an SDP 'setup' attribute in the MSRP media description 294 of the SDP offer, according to the procedures in RFC 6135 [RFC6135]. 296 3. If the offerer is using a relay for MSRP communication, it MUST, 297 in addition to including the address information of the relay in the 298 topmost SDP 'path' attribute, also include the address information of 299 the relay, rather than the address information of itself, in the SDP 300 c/m-line associated with the MSRP media description. In addition, it 301 MUST include an SDP 'setup:actpass' attribute in the MSRP media 302 description of the SDP offer. 304 When the offerer receives an SDP answer, if the MSRP media 305 description of the SDP answer does not contain an SDP 'msrp-cema' 306 attribute, and if any of the following criteria below is met, the 307 offerer MUST fallback to RFC 4975 behavior, by sending a new SDP 308 offer according to the procedures in RFC 4975 and RFC 4976. The new 309 offer MUST NOT contain an SDP 'msrp-cema' attribute. 311 1. The SDP c/m-line address information associated with the MSRP 312 media description does not match Section 4.4 the information in the 313 MSRP URI of the 'path' attribute(s) (in which case is assumed that 314 the SDP c/m-line contains the address to a Middlebox), and the MSRP 315 endpoint will become "passive" (if the MSRP media description of the 316 SDP answer contains an SDP 'setup:active' attribute). 318 NOTE: If an MSRP URI contains a domain name, it needs to be resolved 319 into an IP address and port before it is checked against the SDP c/m- 320 line address information, in order to determine whether the address 321 information matches. 323 2. The offerer uses a relay for its MSRP communication, the SDP c/m- 324 line address information associated with the MSRP media description 325 does not match the information in the MSRP URI of the SDP 'path' 326 attribute(s) (in which case is assumed that the SDP c/m-line contains 327 the address to a Middlebox), and the offerer will become "active" 328 (either by default or if the MSRP media description of the SDP answer 329 contains an SDP 'setup:passive' attribute). 331 3. The remote MSRP endpoint, acting as an answerer, uses a relay for 332 its MSRP communication, the SDP c/m-line address information 333 associated with the MSRP media description does not match the 334 information in the MSRP URI of the SDP 'path' attributes (in which 335 case is assumed that the SDP c/m-line contains the address to a 336 Middlebox), and the MSRP offerer will become "active" (either by 337 default or if the MSRP media description of the SDP answer contains 338 an SDP 'setup:passive' attribute). 340 NOTE: As described in section 5, in the absence of the SDP 'msrp- 341 cema' attribute in the new offer, it is assumed that a Middlebox will 342 act as an MSRP B2BUA in order to anchor MSRP media. 344 The offerer can send the new offer within the existing early dialog 345 [RFC3261], or it can terminate the early dialog and establish a new 346 dialog by sending the new offer in a new initial INVITE request. 348 The offerer MAY choose to terminate the session establishment if it 349 can detect that a Middlebox acting as an MSRP B2BUA is not the 350 desired remote MSRP endpoint. 352 If the answerer uses a relay for its MSRP communication, and the SDP 353 c/m-line address information associated with the MSRP media 354 description matches one of the SDP 'path' attributes, it is assumed 355 that there is no Middlebox in the network. In that case the offerer 356 MUST fallback to RFC 4975 behavior, but it does not need to send a 357 new SDP offer. 359 In other cases, where none of the criteria above is met, and where 360 the MSRP offerer becomes "active", it MUST use the SDP c/m-line for 361 establishing the MSRP TCP connection. If the offerer becomes 362 "passive", it will wait for the answerer to establish the TCP 363 connection, according to the procedures in RFC 4975. 365 4.3. MSRP SDP Answerer Procedures 367 If the MSRP media description of the SDP offer does not contain an 368 SDP 'msrp-cema' attribute, and the SDP c/m-line address information 369 associated with the MSRP media description does not match the 370 information in the MSRP URI of the SDP 'path' attribute(s), the 371 answerer MUST either reject the offered MSRP connection (by using a 372 zero port value number in the generated SDP answer), or reject the 373 whole SDP offer carrying SIP request with a 488 Not Acceptable Here 374 [RFC3261] response. 376 NOTE: The reasons for the rejection is that the answerer assumes that 377 a middlebox, that do not support the CEMA extension, has modified the 378 c/m-line address information of the SDP offer, without enabling MSRP 379 B2BUA functionality. 381 NOTE: If an MSRP URI contains a domain name, it needs to be resolved 382 into an IP address and port before it is checked against the SDP c/m- 383 line address information, in order to determine whether the address 384 information matches. 386 If any of the criteria below is met, the answerer MUST fallback to 387 RFC 4975 behavior and generate the associated SDP answer according to 388 the procedures in RFC 4975 and RFC 4976. The answerer MUST NOT 389 insert an SDP 'msrp-cema' attribute in the MSRP media description of 390 the SDP answer. 392 1. Both MSRP endpoints are using relays for their MSRP 393 communication. The answerer can detect if the remote MSRP endpoint, 394 acting as an offerer, is using a relay for its MSRP communication if 395 the MSRP media description of the SDP offer contains multiple SDP 396 'path' attributes. 398 2. The offerer uses a relay for its MSRP communication, and will 399 become "active" (either by default or if the MSRP media description 400 of the SDP offer contains an SDP 'setup:active' attribute). Note 401 that a CEMA-enabled offerer would include an SDP 'setup:actpass' 402 attribute in the SDP offer, as described in Section 4.2. 404 3. The answerer uses a relay for MSRP communication and is not able 405 to become "passive" (if the MSRP media description of the offer 406 contains an SDP 'setup:passive' attribute. Note that an offerer is 407 not allowed to include an SDP 'setup:passive' attribute in an SDP 408 offer, as described in RFC 6135. 410 In all other cases, the answerer generates the associated SDP answer 411 according to the procedures in RFC 4975 and RFC 4976, with the 412 following additions and modifications: 414 1. The answerer MUST include an SDP 'msrp-cema' attribute in the 415 MSRP media description of the SDP answer. 417 2. If the answerer is not using a relay for MSRP communication, it 418 MUST include an SDP 'setup' attribute in the MSRP media description 419 of the answer, according to the procedures in RFC 6135. 421 3. If the answerer is using a relay for MSRP communication, it MUST, 422 in addition to including the address information of the relay in the 423 topmost SDP 'path' attribute, also include the address information of 424 the relay, rather than the address information of itself, in the SDP 425 c/m-line associated with the MSRP media description. In addition, 426 the answerer MUST include an SDP 'setup:passive' attribute in the 427 MSRP media description of the SDP answer. 429 If the answerer included an SDP 'msrp-cema' attribute in the MSRP 430 media description of the SDP answer, and if the answerer becomes 431 "active", it MUST use the received SDP c/m-line for establishing the 432 MSRP TCP or TLS connection. If the answerer becomes "passive", it 433 will wait for the offerer to establish the MSRP TCP or TLS 434 connection, according to the procedures in RFC 4975. 436 4.4. Address Information Matching 438 When comparing address information in the SDP c/m-line and an MSRP 439 URI, for address and port equivalence, the address and port values 440 are retrieved in the following ways: 442 - SDP c/m-line address information: The IP address is retrieved from 443 the SDP c- line, and the port from the associated SDP m- line for 444 MSRP. 446 - In case the SDP c- line contains a Fully Qualified Domain Name 447 (FQDN), the IP address is retrieved using DNS. 449 - MSRP URI address information: The IP address and port are retrieved 450 from the authority part of the MSRP URI. 452 - In case the authority part of the MSRP URI contains a Fully 453 Qualified Domain Name (FQDN), the IP address is retrieved using DNS, 454 according to the procedures in section 6.2 of RFC 4975. 456 NOTE: According to RFC 4975, the authority part of the MSRP URI must 457 always contain a port. 459 Before IPv6 addresses are compared for equivalence, they need to be 460 converted into the same representation, using the mechanism defined 461 in RFC 5952 [RFC5952]. 463 NOTE: In case the DNS returns multiple records, each needs to be 464 compared against the SDP c/m- line address information, in order to 465 find at least one match. 467 NOTE: If the authority part of the MSRP URI contains special 468 characters, they are handled according to the procedures in section 469 6.1 of RFC 4975. 471 4.5. Usage With the Alternative Connection Model 473 An MSRP endpoint that supports the CEMA extension MUST support the 474 mechanism defined in RFC 6135, as it extends the number of scenarios 475 where one can use the CEMA extension. An example is where an MSRP 476 endpoint is using a relay for MSRP communication, and it needs to be 477 "passive" in order to use the CEMA extension, instead of doing a 478 fallback to RFC 4975 behavior. 480 5. The SDP 'msrp-cema' attribute 482 5.1. General 484 The SDP 'msrp-cema' attribute is used by MSRP entities to indicate 485 support of the CEMA extension, according to the procedures in 486 Sections 4.2 and 4.3. 488 5.2. Syntax 490 This section describes the syntax extensions to the ABNF syntax 491 defined in RFC 4566 required for the SDP 'msrp-cema' attribute. The 492 ABNF defined in this specification is conformant to RFC 5234 493 [RFC5234]. 495 attribute /= msrp-cema-attr 496 ;attribute defined in RFC 4566 497 msrp-cema-attr = "msrp-cema" 499 6. Middlebox Assumptions 501 6.1. General 503 This document does not specify explicit Middlebox behavior, even 504 though Middleboxes enable some of the procedures described here. 505 However, as MSRP endpoints are expected to operate in networks where 506 Middleboxes that want to anchor media are present, this document 507 makes certain assumptions regarding to how such Middleboxes behave. 509 6.2. MSRP Awareness 511 In order to support interoperability between UAs that support the 512 CEMA extension and UAs that do not support the extension, the 513 Middlebox is MSRP aware. This means that it implements MSRP B2BUA 514 functionality. The Middlebox enables that functionality in cases 515 where the offerer does not support the CEMA extension. In cases 516 where the SDP offer indicates support of the CEMA extension, the 517 Middlebox can simply modify the SDP c/m-line address information for 518 the MSRP connection. 520 In cases where the Middlebox enables MSRP B2BUA functionality, it 521 acts as an MSRP endpoint. If it does not use the CEMA procedures it 522 will never forward the SDP 'msrp-cema' attribute in SDP offers and 523 answers. 525 If the Middlebox does not implement MSRP B2BUA functionality, or does 526 not enable it when the SDP 'msrp-cema' attribute is not present in 527 the SDP offer, CEMA-enabled MSRP endpoints will in some cases be 528 unable to interoperate with non-CEMA-enabled endpoints across the 529 Middlebox. 531 6.3. TCP Connection Reuse 533 Middleboxes do not need to parse and modify the MSRP payload when 534 endpoints use the CEMA extension. A Middlebox that does not parse 535 the MSRP payload probably will not be able to reuse TCP connections 536 for multiple MSRP sessions. Instead, in order to associate an MSRP 537 message with a specific session, the Middlebox often assigns a unique 538 local address:port combination for each MSRP session. Due to this, 539 between two Middleboxes there might be a separate connection for each 540 MSRP session. 542 If the Middlebox does not assign a unique address:port combination 543 for each MSRP session, and does not parse MSRP messages, it might end 544 up forwarding MSRP messages towards the wrong destination. 546 6.4. SDP Integrity 548 This document assumes that Middleboxes are able to modify the SDP 549 address information associated with the MSRP media, and that they are 550 able to modify the SDP address information associated with the MSRP 551 media. 553 NOTE: Eventhough the CEMA extension as such works with end-to-end SDP 554 protection, the main advantage of the extension is in networks where 555 Middleboxes are deployed. 557 If the Middlebox is unable to modify SDP payloads due to end-to-end 558 integrity protection, it will be unable to anchor MSRP media as the 559 SIP signaling would fail due to integrity violations. 561 6.5. TLS 563 When UAs use the CEMA extension, this document assumes that 564 Middleboxes relay MSRP media packets at the transport layer. The TLS 565 handshake and resulting security association (SA) can be established 566 peer-to-peer between the MSRP endpoints. The Middlebox will see 567 encrypted MSRP media packets, but is unable to inspect the clear text 568 content. 570 When UAs fall back to RFC 4975 behavior Middleboxes act as TLS 571 B2BUAs. The Middlebox decrypts MSRP media packets received from one 572 MSRP endpoint, and then re-encrypts them before sending them toward 573 the other MSRP endpoint. Middleboxes can inspect and modify the MSRP 574 message content. 576 7. Security Considerations 578 7.1. General 580 Unless otherwise stated, the security considerations in [RFC4975] and 581 [RFC4976] still apply. This section only describes additions and 582 changes introduced by the CEMA extension. 584 In deployments where Middleboxes are always used, which is the main 585 use case for the CEMA extension, the CEMA extension increases the 586 security by enabling the use of end-to-end TLS between the two 587 endpoints. If the key management does not depend on trust in the 588 signaling plane, this greatly increases the security. If the key 589 management depends on trust in the signaling plane, the Middlebox is 590 by definition trusted, but the security is still increased as the 591 cleartext is not available in the Middlebox. 593 7.2. Man-in-the-Middle Attacks 595 If TLS is not used to protect MSRP, the CEMA extension might make it 596 easier for a man-in-the-middle to transparently insert itself in the 597 communication between MSRP endpoints in order to monitor or record 598 unprotected MSRP communication. This can be mitigated by the use of 599 TLS. It is therefore RECOMMENDED to use TLS [RFC5246]. It is also 600 recommended to use TLS e2e, which CEMA enables even in the case of 601 Middleboxes. For backward compatibility, a CEMA-enabled MSRP 602 endpoint MUST implement TLS. 604 7.3. TLS Usage without Middleboxes 606 If TLS is use without Middleboxes, the security considerations in 607 [RFC4975] and [RFC4976] still apply unchanged. Note that this is not 608 the main use case for the CEMA extension. 610 7.4. TLS Usage with Middleboxes 612 This is the main use case for the CEMA extension; the endpoints 613 expect one or more Middlebox. 615 The CEMA extension supports the usage of both name-based 616 authentication and fingerprint based authentication for TLS in the 617 presence of Middleboxes. The use of fingerprint based authentication 618 requires signaling integrity protection. This can e.g. be hop-by-hop 619 cryptographic protection or cryptographic access protection combined 620 with physical trust in other parts of the signaling plane. As stated 621 in section 6.4 Middleboxes cannot be deployed in environments with 622 cryptographic end-to-end SDP integrity protection or encryption. 624 If a Middlebox acts as a TLS B2BUA, the security considerations are 625 the same as without the CEMA extension. In such case the Middlebox 626 acts as TLS endpoints. 628 If a Middlebox does not act as a TLS B2BUA, TLS is e2e and the 629 Middlebox just forwards the TLS packets. This requires that both 630 peers support the CEMA extension. 632 If fingerprint based authentication is used, the MSRP endpoints might 633 not be able to decide whether the Middlebox acts as a TLS B2BUA or 634 not. But this is not an issue as the signaling network is considered 635 trusted by the endpoint (a requirement to use fingerprint based 636 authentication). 638 7.5. Authentication, Credentials and Key Management 640 One issue with usage of TLS (not specific to CEMA) is the 641 availability of a PKI. Endpoints can always provide self-signed 642 certificates. However, this relies on that the SDP signaling is 643 integrity protected, which may not always be the case. 645 Therefore, in addition to the authentication mechanisms defined in 646 RFC 4975, it is RECOMMENDED that a CEMA-enabled MSRP endpoint also 647 support one of the following authentication and key management 648 mechanisms, that do not rely on integrity protected SDP signaling. 650 1. Self-signed certificates together with support of interacting 651 with a Certificate Management Service [RFC6072], to which it 652 publishes its self-signed certificate and from which it fetches on 653 demand the self-signed certificates of other endpoints. 655 2. TLS-PSK where the pre-shared key is provided by MIKEY-TICKET. 656 MIKEY-TICKET is a ticket based key management service relying on a 657 shared secret (UICC or password) between the endpoint and some AAA 658 server. MIKEY-TICKET is one of two standardized key management 659 protocols in the IP Multimedia Subsystem (IMS). 661 One of the target deployments for CEMA is the 3GPP IMS SIP network. 662 In this environment authentication and credential management is less 663 of a problem as the SDP signaling is mostly considered trusted, 664 service providers provision signed certificates or manage signed 665 certificates on behalf of their subscribers, and MIKEY-TICKET is 666 available. Some of these options require trusting the service 667 provider, but those issues are beyond the scope of this document. 669 Alternate key distribution mechanisms, such as DANE [DANE], PGP 670 [RFC6091], or some other technology, might become ubiquitous enough 671 to solve the key distribution problem in the future. 673 7.6. Endpoint procedures for TLS negotiation 675 The CEMA extension does not change the endpoint procedures for TLS 676 negotiation. As in [RFC4975] the endpoint uses the negotiation 677 mechanisms in SDP and then the TLS handshake to agree on a mechanisms 678 and algorithms that both support. The mechanisms can be divided in 679 three different security levels: 681 - MSRPS: Security Mechanisms that does not rely on trusted signaling 682 such as name based authentication and MIKEY-TICKET 684 - MSRPS: Mechanisms that do rely on trusted signaling such as 685 fingerprint based authentication 687 - MSRP: Unprotected 689 If the endpoint uses security mechanisms that does not rely on 690 trusted signaling the endpoint can detect if a Middlebox is inserted. 691 It is therefore RECOMMENDED to use such a mechanism. 693 If the endpoint uses security mechanisms that rely on trusted 694 signaling the endpoint may not be able to detect if a Middlebox is 695 inserted (by the trusted network operator). To be able to eavesdrop 696 a Middlebox must do an active "attack" on the setup signaling. A 697 Middlebox cannot insert itself at a later point. 699 If Unprotected MSRP is used, the endpoint cannot detect if a 700 Middlebox is inserted and Middleboxes may be inserted at any time 701 during the session. 703 The two new recommended mechanisms [RFC6043], [RFC6072] both give 704 end-to-end security without relying on trust in the signaling. 705 [RFC6072] eases the use and deployment of name based authentication 706 and [RFC6043] gives the same security properties and should be 707 offered in parallel with name based authentication. 709 The procedures for choosing and offering name based authentication, 710 fingerprint based authentication, and unprotected MSRP as described 711 in [RFC4975] still apply. 713 7.7. Fingerprint Based Authentication 715 If the endpoint cannot use a key management protocol that does not 716 rely on trust in the signaling such as name based authentication or 717 MIKEY-TICKET, the only alternative is fingerprint based 718 authentication. 720 The use of fingerprint based authentication requires integrity 721 protection of the signaling plane. This can e.g. be end-to-end 722 cryptographic protection, hop-by-hop cryptographic protection, or 723 cryptographic access protection combined with physical trust in other 724 parts of the signaling plane. Unless cryptographic end-to-end SDP 725 integrity protection or encryption is used this may be hard for the 726 endpoint to decide. In the end it is up to the endpoint to decide 727 whether the signaling path is trusted or not. 729 How this decision is done is implementation specific, but normally 730 signaling over the internet SHOULD NOT be trusted. Signaling over a 731 local or closed network MAY be trusted. Such networks can e.g. be a 732 closed enterprise network or a network operated by an operator that 733 the end user trusts. In e.g. IMS the signaling traffic in the 734 access network is integrity protected and the traffic is routed over 735 a closed network separated from the Internet. If the network is not 736 trusted the endpoints SHOULD NOT use fingerprint authentication. 738 It should however be noted that using fingerprint based 739 authentication over an insecure network increases the security 740 compared to unencrypted MSRP as this makes it harder to perform an 741 man-in-the-middle attack. Such an attack needs to be done to both 742 the signaling and the media plane, which may be separated. It does 743 not however give any guarantees that such a man-in-the-middle attack 744 is not taking place. A client using DTLS-SRTP [RFC5764] for VoIP 745 media security may wish to use fingerprint based authentication also 746 for MSRP media security. 748 MSRPS with fingerprint based authentication is vulnerable to attacks 749 due to vulnerabilities in the SIP signaling. If there are weaknesses 750 in the integrity protections on the SIP signaling, an attacker may 751 insert malicious middleboxes to alter, record, or otherwise harm the 752 media. With insecure signaling, it can be difficult for an endpoint 753 to even be aware the remote endpoint has any relationship to the 754 expected endpoint. Securing the SIP signaling does not solve all 755 problems. For example, in a SIPS environment, the endpoints have no 756 cryptographic way of validating that one or more SIP Proxies in the 757 proxy chain are not, in fact, malicious. 759 8. IANA Considerations 761 8.1. IANA Registration of the SDP 'msrp-cema' attribute 763 This document instructs IANA to add a attribute to the 'att-field 764 (media level only)' registry of the SDP parameters registry, 765 according to the information provided in this section. 767 This section registers a new SDP attribute, 'msrp-cema'. The 768 required information for this registration, as specified in RFC 4566, 769 is: 771 Contact name: Christer Holmberg 773 Contact e-mail: christer.holmberg@ericsson.com 775 Attribute name: msrp-cema 777 Type of attribute: media level 779 Purpose: This attribute is used to indicate support of 780 the MSRP Connection Establishment for Media 781 Anchoring (CEMA) extension defined in 782 RFC XXXX. When present in an MSRP media 783 description of an SDP body, it indicates 784 that the creator of the SDP supports the CEMA 785 mechanism. 787 Values: The attribute does not carry a value 789 Charset dependency: none 791 9. Acknowledgements 793 Thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel 794 Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, 795 Ted Hardie, Richard L Barnes, Inaki Baz Castillo, Saul Ibarra 796 Corretge, Cullen Jennings, Adrian Georgescu and Miguel Garcia for 797 their guidance and input in order to produce this document. 799 Thanks to John Mattsson for his help to restructure the Security 800 Considerations section, based on the feedback from IESG. 802 10. Change Log 804 [RFC EDITOR NOTE: Please remove this section when publishing] 806 Changes from draft-ietf-simple-msrp-cema-03 807 o Security Considerations sections re-written based on IESG 808 comments. 809 o Changes based on IESG comments from Peter Saint-Andre. 810 o Changes based on IESG comments from Robert Sparks. 811 o Changes based on IESG comments from Stephen Farrell. 812 o Changes based on IESG comments from Pete Resnick. 814 Changes from draft-ietf-simple-msrp-cema-02 815 o Changes based on WGLC comments. 816 o - Editorial changes based on comments from Nancy Greene. 817 o - Editorial changes based on comments from Saul Ibarra Corretge. 818 o - Editorial changes based on comments from Christian Schmidt. 819 o - Editorial changes based on comments from Miguel Garcia. 820 o Changes based on MMUSIC SDP impact review. 821 o - Editorial changes based on comments from Miguel Garcia. 823 Changes from draft-ietf-simple-msrp-cema-01 824 o Changes based on comment from Ben Campbell. 825 o - TLS B2BUA added to definitions section. 826 o - Middlebox added. 827 o - Editorial changes. 829 Changes from draft-ietf-simple-msrp-sessmatch-13 830 o Changed the draft name, as was suggested by our AD and work group. 831 o Clean up language use, clarify language, and clean up editorial 832 and style issues. 833 o Formally defined an MSRP B2BUA. 835 Changes from draft-ietf-simple-msrp-sessmatch-12 836 o Extension name changed to Connection Establishment for Media 837 Anchoring (CEMA). 838 o Middlebox definition added. 839 o ALG terminology replaced with Middlebox. 840 o SDP attribute name changed to a=msrp-cema. 841 o Applicability Statement section expanded. 842 o Re-structuring of MSRP Answerer section. 843 o Changes based on comments from Saul Ibarra Corretge (1406111). 845 Changes from draft-ietf-simple-msrp-sessmatch-11 846 o Modification of the sessmatch mechanism. 847 o - Extension name changed to Alternative Connection Establishment 848 (ACE) 849 o - Session matching procedure no longer updated. 850 o - SDP c/m-line used for MSRP TCP connection. 851 o - sessmatch option-tag removed. 852 o - a=msrp-ace attribute defined. 853 o - Support of RFC 6135 mandatory. 855 Changes from draft-ietf-simple-msrp-sessmatch-10 856 o Sessmatch option-tag added, based on WG discussions and concensus. 858 Changes from draft-ietf-simple-msrp-sessmatch-08 859 o OPEN ISSUE regarding the need for a sessmatch option-tag removed. 861 Changes from draft-ietf-simple-msrp-sessmatch-07 862 o Sessmatch defined as an MSRP extension, rather than MSRP update 863 o Additional security considerations text added 865 11. References 867 11.1. Normative References 869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, March 1997. 872 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 873 A., Peterson, J., Sparks, R., Handley, M., and E. 874 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 875 June 2002. 877 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 878 Description Protocol", RFC 4566, July 2006. 880 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 881 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 883 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 884 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 885 September 2007. 887 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 888 Specifications: ABNF", STD 68, RFC 5234, January 2008. 890 [RFC6072] Jennings, C. and J. Fischl, "Certificate Management 891 Service for the Session Initiation Protocol (SIP)", 892 RFC 6072, February 2011. 894 [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model 895 for the Message Session Relay Protocol (MSRP)", RFC 6135, 896 February 2011. 898 11.2. Informative References 900 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 901 and the Future of End-to-End: Reflections on the Evolution 902 of the Internet Architecture", RFC 3724, March 2004. 904 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 905 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 907 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 908 Security (DTLS) Extension to Establish Keys for the Secure 909 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 911 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 912 Address Text Representation", RFC 5952, August 2010. 914 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 915 Modes of Key Distribution in Multimedia Internet KEYing 916 (MIKEY)", RFC 6043, March 2011. 918 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 919 for Transport Layer Security (TLS) Authentication", 920 RFC 6091, February 2011. 922 [GPP23228] 923 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 924 TS 23.228 10.5.0, June 2011. 926 [DANE] "DNS-based Authentication of Named Entities Work Group". 928 Authors' Addresses 930 Christer Holmberg 931 Ericsson 932 Hirsalantie 11 933 Jorvas 02420 934 Finland 936 Email: christer.holmberg@ericsson.com 937 Staffan Blau 938 Ericsson 939 Stockholm 12637 940 Sweden 942 Email: staffan.blau@ericsson.com 944 Eric Burger 945 Georgetown University 946 Department of Computer Science 947 37th and O Streets, NW 948 Washington, DC 20057-1232 949 United States of America 951 Phone: 952 Fax: +1 530 267 7447 953 Email: eburger@standardstrack.com 954 URI: http://www.standardstrack.com