RFC 6714

Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)

📅 published August 2012, from ietf

Hiii bestie 🎀 Okay, so this is RFC 6714, and it's giving connection establishment realness 💅

Title: Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP) 🦋

Authors: C. Holmberg and S. Blau from Ericsson, plus E. Burger from Georgetown University 🌸

Category: Standards Track, which means it's an official Internet standard, not just a vibe 👑

Date: August 2012 📅

ISSN: 2070-1721 ✨

This doc is published by the Internet Engineering Task Force (IETF), so it's basically the Internet's group project. 🫶

Abstract

Okay so the vibe here is that this doc defines an MSRP extension called Connection Establishment for Media Anchoring (CEMA). 🧚 Supporting it is OPTIONAL, so you do not have to, but it's a whole mood. The big win is that middleboxes can anchor the MSRP connection without having to touch the MSRP messages themselves 😭 That means secure end-to-end MSRP can still work even in networks full of middleboxes. Iconic. 💜

The doc also defines a Session Description Protocol (SDP) attribute called msrp-cema, which MSRP endpoints use to say, "hey, I support CEMA" 🎀

Status of This Memo

Real talk: this is an Internet Standards Track document. 🔥

It's a product of the IETF and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). ✨ If you want more info on Internet Standards, check Section 2 of RFC 5741 🌈

For the current status, errata, and where to send feedback, go to http://www.rfc-editor.org/info/rfc6714 💖

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🧾

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License. 💅

Table of Contents

   1. Introduction ....................................................3
   2. Conventions .....................................................5
   3. Applicability Statement .........................................6
   4. Connection Establishment for Media Anchoring Mechanism ..........7
      4.1. General ....................................................7
      4.2. MSRP SDP Offerer Procedures ................................8
      4.3. MSRP SDP Answerer Procedures ...............................9
      4.4. Address Information Matching ..............................11
      4.5. Usage with the Alternative Connection Model ...............12
   5. The SDP 'msrp-cema' Attribute ..................................12
      5.1. General ...................................................12
      5.2. Syntax ....................................................12
   6. Middlebox Assumptions ..........................................13
      6.1. General ...................................................13
      6.2. MSRP Awareness ............................................13
      6.3. TCP Connection Reuse ......................................13
      6.4. SDP Integrity .............................................14
      6.5. TLS .......................................................14
   7. Security Considerations ........................................14
      7.1. General ...................................................14
      7.2. Man-in-the-Middle (MITM) Attacks ..........................15
      7.3. TLS Usage without Middleboxes .............................16
      7.4. TLS Usage with Middleboxes ................................16
      7.5. Authentication, Credentials, and Key Management ...........16
      7.6. Endpoint Procedures for TLS Negotiation ...................17
      7.7. Fingerprint-Based Authentication ..........................18
   8. IANA Considerations ............................................19
      8.1. IANA Registration of the SDP 'msrp-cema' Attribute ........19
   9. Acknowledgements ...............................................20
   10. References ....................................................20
      10.1. Normative References .....................................20
      10.2. Informative References ...................................21

1. Introduction 🌷

So the Message Session Relay Protocol (MSRP) [RFC4975] wants to use MSRP relays [RFC4976] for Network Address Translation (NAT) traversal and policy enforcement. 🦋 The catch is that a lot of Session Initiation Protocol (SIP) [RFC3261] networks that deploy MSRP are full of middleboxes. These middleboxes anchor and control media, and they handle stuff like NAT traversal, performance monitoring, and address domain bridging. They also enforce Service Level Agreement (SLA) policies between networks, and so on 🧚 One example is the Interconnection Border Control Function (IBCF) [GPP23228], defined by the 3rd Generation Partnership Project (3GPP). The IBCF controls a media relay that handles every kind of SIP session media, like voice, video, MSRP, etc. 📞

Here's the tea ☕ MSRP, as defined in RFC 4975 [RFC4975] and RFC 4976 [RFC4976], cannot anchor through middleboxes. The reason is that MSRP messages have routing information baked right into the message. Without an extension like CEMA, middleboxes would need to read the message to change that routing info. 🙈 That happens because middleboxes modify the address:port information in the Session Description Protocol (SDP) [RFC4566] c/m-line in order to anchor media. An "active" [RFC6135] MSRP User Agent (UA) sets up the MSRP TCP or Transport Layer Security (TLS) connection based on the MSRP URI in the SDP path attribute. 💀 So the MSRP connection won't get routed through the middlebox unless the middlebox also changes the MSRP URI in the topmost SDP path attribute. In lots of scenarios, that means the MSRP connection never gets established at all 😭 Plus, if the middlebox does change the MSRP URI in the SDP path attribute, the MSRP URI comparison procedure [RFC4975] fails. That procedure needs the address info in the MSRP messages to match the address info in the MSRP URI of the SDP path attribute, and now it doesn't 💔

The only way to get interoperability in this situation is for the middlebox to act as an MSRP back-to-back User Agent (B2BUA) 🌸 The MSRP B2BUA becomes the endpoint for the MSRP signaling and media, makes the matching changes in the MSRP messages, and starts a brand-new MSRP session toward the real remote endpoint. But turning on MSRP B2BUA functionality eats up a ton of resources in the middlebox, which usually hurts performance. Also, the MSRP message has to be exposed in cleartext to the MSRP B2BUA, and that violates the end-to-end principle [RFC3724]. Not it. 🚫

This specification defines an MSRP extension called Connection Establishment for Media Anchoring (CEMA), and it's the main character here ✨ In most cases, CEMA lets MSRP endpoints talk through middleboxes (as defined in Section 2) without the middleboxes needing to be MSRP B2BUAs. 👑 In those cases, middleboxes that want to anchor the MSRP connection just modify the SDP c/m-line address information, the same way they already do for non-MSRP media types. And MSRP endpoints that support CEMA use that SDP c/m-line address information to set up the TCP or TLS connection for sending and receiving MSRP messages. 🫶

CEMA is backward compatible, which means CEMA-enabled MSRP endpoints can talk to non-CEMA-enabled endpoints. 🌈 When the other side doesn't support CEMA, a CEMA-enabled endpoint acts exactly like an endpoint that doesn't support it. CEMA only gives you a different way to negotiate and provide address info for the MSRP TCP connection. Once the MSRP connection exists, a CEMA-enabled endpoint follows the normal procedures: creating MSRP messages and running the checks on received MSRP messages defined in RFC 4975 and, when it's using a relay for MSRP communications, RFC 4976 too. 💖

2. Conventions 📖✨

okay bestie, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read the way BCP 14 and RFC 2119 [RFC2119] describe them 📚💅

Here are the definitions you need to know 🎀

Fingerprint-Based TLS Authentication: an MSRP endpoint that uses a self-signed certificate and sends a fingerprint (i.e., a hash of the self-signed certificate) in SDP to the other MSRP endpoint. The fingerprint ties the TLS key exchange to the signaling plane and authenticates the other endpoint based on trust in the signaling plane 🔐🦋

Name-Based TLS Authentication: an MSRP endpoint that uses a certificate bound to the endpoint's hostname or SIP address of record. During TLS session setup, the other MSRP endpoint checks that the identity tied to the certificate matches the peer's identity (as shown in SIP/SDP), and that the binding of the identity to the public key was done by a party the endpoint trusts. This includes traditional certificates from a well-known certification authority, plus self-signed certificates published through the SIP Certificate Management Service [RFC6072] and other similar mechanisms 🌈✨

B2BUA: short for back-to-back user agent 🍓

MSRP B2BUA: a network element that terminates an MSRP connection from one MSRP endpoint and reoriginates that connection toward another MSRP endpoint. Note that an MSRP B2BUA is different from a SIP B2BUA 👀 A SIP B2BUA terminates a SIP session and reoriginates it toward another SIP endpoint. In the MSRP world, a SIP endpoint starts a SIP session toward another SIP endpoint, but that INVITE may pass through, for example, an outbound proxy or inbound proxy to reach the remote SIP endpoint. As part of that SIP session, an MSRP session that may follow the SIP session path gets negotiated. There is, however, no requirement to put the SIP network elements in the same place as the MSRP network elements 🧚

TLS B2BUA: a network element that terminates security associations (SAs) from endpoints and sets up separate SAs between itself and each endpoint 🔁

Middlebox: a SIP network device that changes the SDP media address:port information in order to steer or anchor the media flows described in the SDP (including TCP and TLS connections used for MSRP communication) through a media proxy function controlled by the SIP endpoint. Most of the time the media proxy function relays MSRP messages without changing them, but in some situations it acts as an MSRP B2BUA. Other SIP-related functions performed by the Middlebox (such as routing, modifying SIP information, etc.), and whether it acts as a SIP B2BUA or not, are out of scope for this document. Section 6 describes the extra assumptions about how the Middlebox handles MSRP so that the extension defined here can work 🛠️

Media anchor: an entity that performs media anchoring by inserting itself into the media path of a media communication session between two entities. The media anchor receives the media sent between the entities and forwards it 📡

This document reuses the terms "answer", "answerer", "offer", and "offerer" as defined in [RFC3264] 💖

3. Applicability Statement 🌸

okay so this document defines an MSRP extension called Connection Establishment for Media Anchoring (CEMA) 💅 Supporting it is OPTIONAL 🫶 The extension lets Middleboxes anchor the MSRP connection without having to modify the MSRP messages, so it also enables secure end-to-end MSRP communication in networks where those Middleboxes are deployed 🔐✨ The document also defines a Session Description Protocol (SDP) attribute, msrp-cema, that MSRP endpoints use to show they support the CEMA extension 🎀

The CEMA extension is mainly meant for MSRP endpoints in networks where Middleboxes want to anchor media connections, without those Middleboxes needing to turn on MSRP B2BUA functionality 🦋 An example of such a network is the IP Multimedia Subsystem (IMS), defined by the 3rd Generation Partnership Project (3GPP), which also lets all endpoints use name-based TLS authentication 👑 The extension is also useful for other MSRP endpoints in other networks that talk to MSRP endpoints in networks with such Middleboxes, unless there is a gateway between those networks that always enables MSRP B2BUA functionality by default 🧚

This document assumes certain behaviors from Middleboxes, as described in Section 6. These behaviors are not standardized 🙈 If Middleboxes don't behave as assumed, then the CEMA extension adds no value over base MSRP behavior 💀 MSRP endpoints that support CEMA are required to use RFC 4975 behavior in cases where they detect that the CEMA extension cannot be enabled. 🚨

4. Connection Establishment for Media Anchoring Mechanism 🧚💖

4.1. General ✨

This section defines how an MSRP endpoint that supports the CEMA extension generates SDP offers and answers for MSRP, and which SDP information elements that endpoint uses when it creates the TCP or TLS connection for sending and receiving MSRP messages 📝

Based on the procedures in Sections 4.2 and 4.3, the CEMA extension will not be enabled in the following cases, and there will be a fallback to the MSRP connection establishment procedures defined in RFC 4975 and RFC 4976 🔁

  • A non-CEMA-enabled MSRP endpoint becomes "active" [RFC6135] (whether or not it uses a relay for its MSRP communication), because it always establishes the MSRP connection using the SDP path attribute, which holds the address information of the remote MSRP endpoint, instead of the SDP c/m-line, which holds the address information of the Middlebox 🙅‍♀️
  • A non-CEMA-enabled MSRP endpoint that uses a relay for its MSRP communication becomes "passive" [RFC6135], because it can't be assumed that the MSRP endpoint puts the address information of the relay in the SDP c/m-line 🦋
  • A CEMA-enabled MSRP endpoint that uses a relay for its MSRP communication becomes "active", since if it adds the received SDP c/m-line address information to the ToPath header field of the MSRP message (so the relay can establish the MSRP connection toward the Middlebox), the session matching [RFC4975] performed by the remote MSRP endpoint will fail 😭

4.2. MSRP SDP Offerer Procedures 💅

When a CEMA-enabled offerer sends an SDP offer for MSRP, it generates that SDP offer according to the procedures in RFC 4975 💜 On top of that, the offerer follows RFC 4976 if it is using a relay for MSRP communication. The offerer also makes the following additions and modifications 🎀

  1. The offerer MUST include an SDP msrp-cema attribute in the MSRP media description of the SDP offer 🌈
  2. If the offerer is not using a relay for MSRP communication, it MUST include an SDP setup attribute in the MSRP media description of the SDP offer, following the procedures in RFC 6135 [RFC6135] 🔧
  3. If the offerer is using a relay for MSRP communication, it MUST, in addition to including the address information of the relay in the topmost SDP path attribute, also include the address information of the relay (rather than its own address information) in the SDP c/m-line associated with the MSRP media description. Also, it MUST include an SDP setup:actpass attribute in the MSRP media description of the SDP offer 🍓

When the offerer receives an SDP answer, if the MSRP media description of that SDP answer does not contain an SDP msrp-cema attribute, and if any one or more of the criteria below are met, the offerer MUST fall back to RFC 4975 behavior by sending a new SDP offer according to the procedures in RFC 4975 and RFC 4976 😤 The new offer MUST NOT contain an SDP msrp-cema attribute 🙅‍♀️

  1. The SDP c/m-line address information associated with the MSRP media description does not match (see Section 4.4) the information in the MSRP URI of the path attribute(s) (in which case it is assumed that the SDP c/m-line contains the address of a Middlebox), and the MSRP endpoint will become "passive" (if the MSRP media description of the SDP answer contains an SDP setup: active attribute) 🕵️‍♀️

NOTE: If an MSRP URI contains a domain name, it needs to be resolved into an IP address and port before it is checked against the SDP c/m-line address information, so that the address information can be matched 🔍

  1. The offerer uses a relay for its MSRP communication, the SDP c/m-line address information associated with the MSRP media description does not match the information in the MSRP URI of the SDP path attribute(s) (in which case it is assumed that the SDP c/m-line contains the address of a Middlebox), and the offerer will become "active" (either by default or because the MSRP media description of the SDP answer contains an SDP setup:passive attribute) 🌸
  2. The remote MSRP endpoint, acting as an answerer, uses a relay for its MSRP communication, the SDP c/m-line address information associated with the MSRP media description does not match the information in the MSRP URI of the SDP path attributes (in which case it is assumed that the SDP c/m-line contains the address of a Middlebox), and the MSRP offerer will become "active" (either by default or because the MSRP media description of the SDP answer contains an SDP setup:passive attribute) 🧚

NOTE: As described in Section 6, if the new offer has no SDP msrp-cema attribute, it is assumed that a Middlebox will act as an MSRP B2BUA in order to anchor MSRP media 💀

The offerer can send the new offer within the existing early dialog [RFC3261], or it can terminate the early dialog and set up a new dialog by sending the new offer in a new initial INVITE request 🦋

The offerer MAY choose to terminate the session establishment if it can detect that a Middlebox acting as an MSRP B2BUA is not the desired remote MSRP endpoint 🛑

If the answerer uses a relay for its MSRP communication, and the SDP c/m-line address information associated with the MSRP media description matches one of the SDP path attributes, it is assumed that there is no Middlebox in the network 🙌 In that case, the offerer MUST fall back to RFC 4975 behavior, but it does not need to send a new SDP offer ✨

In other cases, where none of the criteria above are met and the MSRP offerer becomes "active", it MUST use the SDP c/m-line to establish the MSRP TCP connection 🔥 If the offerer becomes "passive", it will wait for the answerer to establish the TCP connection, following the procedures in RFC 4975 🫶

4.3. MSRP SDP Answerer Procedures ✨

okay so, if the MSRP media description in the SDP offer has no SDP msrp-cema attribute, AND the c/m-line address info tied to that MSRP media description doesn't match the info in the MSRP URI of the SDP path attribute(s), then the answerer MUST either reject the offered MSRP connection (by putting a zero port value number in the generated SDP answer) or reject the whole SIP request that carries the SDP offer with a 488 Not Acceptable Here [RFC3261] response. 🙅‍♀️

NOTE: the reason for the rejection is that the answerer assumes a middlebox that doesn't support the CEMA extension has changed the c/m-line address info of the SDP offer without turning on MSRP B2BUA functionality. 🕵️‍♀️

NOTE: if an MSRP URI has a domain name, it needs to get resolved into an IP address and port before it gets checked against the SDP c/m-line address info. That's how you figure out whether the addresses match. 🔍

If any one or more of the criteria below are met, the answerer MUST fall back to RFC 4975 behavior and generate the matching SDP answer using the procedures in RFC 4975 and RFC 4976. The answerer MUST NOT insert an SDP msrp-cema attribute in the MSRP media description of the SDP answer. 🚫

  1. Both MSRP endpoints are using relays for their MSRP communication. The answerer can tell if the remote MSRP endpoint (the offerer) is using a relay if the MSRP media description of the SDP offer has multiple SDP path attributes. 🔁
  2. The offerer uses a relay for its MSRP communication and will become "active" (either by default, or because the MSRP media description of the SDP offer has an SDP setup:active attribute). Heads up: a CEMA-enabled offerer would put an SDP setup:actpass attribute in the SDP offer, as described in Section 4.2. 🌸
  3. The answerer uses a relay for MSRP communication and is not able to become "passive" (if the MSRP media description of the offer has an SDP setup:passive attribute). An offerer isn't allowed to include an SDP setup:passive attribute in an SDP offer, as described in RFC 6135. 💅

In all other cases, the answerer generates the matching SDP answer using the procedures in RFC 4975 and RFC 4976, with the following additions and changes:

  1. The answerer MUST include an SDP msrp-cema attribute in the MSRP media description of the SDP answer. 💖
  2. If the answerer is not using a relay for MSRP communication, it MUST include an SDP setup attribute in the MSRP media description of the answer, following the procedures in RFC 6135. 🧚
  3. If the answerer is using a relay for MSRP communication, it MUST, on top of including the relay's address info in the topmost SDP path attribute, also include the relay's address info (not its own) in the SDP c/m-line tied to the MSRP media description. Also, the answerer MUST include an SDP setup:passive attribute in the MSRP media description of the SDP answer. 🦋

If the answerer put an SDP msrp-cema attribute in the MSRP media description of the SDP answer, and the answerer becomes "active", it MUST use the received SDP c/m-line to set up the MSRP TCP or TLS connection. If the answerer becomes "passive", it will wait for the offerer to set up the MSRP TCP or TLS connection, following the procedures in RFC 4975. 🫶

4.4. Address Information Matching 🎀

when comparing address info in the SDP c/m-line and an MSRP URI (to check address and port equivalence), the address and port values get pulled out in these ways:

  • SDP c/m-line address information: the IP address comes from the SDP c-line, and the port comes from the associated SDP m-line for MSRP. 📍
  • If the SDP c-line has a Fully Qualified Domain Name (FQDN), the IP address gets looked up using DNS.
  • MSRP URI address information: the IP address and port are pulled from the authority part of the MSRP URI. 🔎
  • If the authority part of the MSRP URI has an FQDN, the IP address gets looked up using DNS, following the procedures in Section 6.2 of RFC 4975.

NOTE: according to RFC 4975, the authority part of the MSRP URI must always contain a port. 🔌

Before IPv6 addresses get compared for equivalence, they need to be converted into the same representation, using the mechanism defined in RFC 5952 [RFC5952]. 🧮

NOTE: if DNS returns multiple records, each one needs to be compared against the SDP c/m-line address info, so that at least one of them matches. 🌈

NOTE: if the authority part of the MSRP URI has special characters, they get handled according to the procedures in Section 6.1 of RFC 4975. ✨

4.5. Usage with the Alternative Connection Model 🦋

An MSRP endpoint that supports the CEMA extension MUST support the mechanism defined in RFC 6135, because it stretches the number of situations where you can use the CEMA extension. For example: an MSRP endpoint is using a relay for MSRP communication and needs to be "passive" to use the CEMA extension, instead of falling back to RFC 4975 behavior. Iconic, right? 👑

5. The SDP 'msrp-cema' Attribute 💜

5.1. General 🌷

The SDP msrp-cema attribute is how MSRP entities say "hey, I support the CEMA extension," following the procedures in Sections 4.2 and 4.3. 💬

5.2. Syntax 📜

This section describes the syntax extensions to the ABNF syntax defined in RFC 4566 that the SDP msrp-cema attribute needs. The ABNF in this spec follows RFC 5234 [RFC5234]. 🧠

      attribute          =/ msrp-cema-attr
      ;attribute defined in RFC 4566
      msrp-cema-attr     = "msrp-cema"

6. Middlebox Assumptions 🧚‍♀️

6.1. General 🌙

This document doesn't specify any explicit Middlebox behavior, even though Middleboxes make some of the procedures here possible. Still, MSRP endpoints are expected to run in networks where Middleboxes that want to anchor media are present, so this document makes certain assumptions about how those Middleboxes behave. 🤷‍♀️

6.2. MSRP Awareness 🔮

To make UAs that support the CEMA extension work with UAs that don't, the Middlebox has to be MSRP aware. That means it implements MSRP B2BUA functionality. The Middlebox turns that functionality on when the offerer doesn't support the CEMA extension. When the SDP offer says it supports the CEMA extension, the Middlebox can just change the SDP c/m-line address info for the MSRP connection. ✨

When the Middlebox turns on MSRP B2BUA functionality, it acts as an MSRP endpoint. If it doesn't use the CEMA procedures, it will never forward the SDP msrp-cema attribute in SDP offers and answers. 🙅‍♀️

If the Middlebox doesn't implement MSRP B2BUA functionality, or doesn't turn it on when the SDP msrp-cema attribute isn't in the SDP offer, then CEMA-enabled MSRP endpoints will sometimes be unable to interoperate with non-CEMA-enabled endpoints across the Middlebox. Yikes 😭

6.3. TCP Connection Reuse 🔁

Middleboxes don't need to parse and modify the MSRP payload when endpoints use the CEMA extension. A Middlebox that doesn't parse the MSRP payload probably won't be able to reuse TCP connections for multiple MSRP sessions. Instead, to match an MSRP message to a specific session, the Middlebox often gives each MSRP session its own unique local address:port combination. Because of this, there might be a separate connection between two Middleboxes for each MSRP session. 🧩

If the Middlebox doesn't give each MSRP session a unique address:port combination, and doesn't parse MSRP messages, it might end up forwarding MSRP messages to the wrong destination. 💀

6.4. SDP Integrity 🔐

This document assumes that Middleboxes are able to modify the SDP address info tied to the MSRP media. 🛠️

NOTE: even though the CEMA extension works with end-to-end SDP protection, the big advantage of the extension is in networks where Middleboxes are deployed. 🌐

If the Middlebox can't modify SDP payloads because of end-to-end integrity protection, it won't be able to anchor MSRP media, since the SIP signaling would fail due to integrity violations. 🚨

6.5. TLS 🌸

When UAs use the CEMA extension, this document assumes that Middleboxes relay MSRP media packets at the transport layer. The TLS handshake and the resulting security association (SA) can be set up peer-to-peer between the MSRP endpoints. The Middlebox sees encrypted MSRP media packets but can't inspect the cleartext content. 🔒

When UAs fall back to RFC 4975 behavior, Middleboxes act as TLS B2BUAs. The Middlebox decrypts MSRP media packets received from one MSRP endpoint, then re-encrypts them before sending them toward the other MSRP endpoint. Middleboxes can inspect and modify the MSRP message content. 👀

7. Security Considerations 🔥

7.1. General 💅

Okay bestie, first things first: unless otherwise stated, the security considerations in RFC 4975 and RFC 4976 still apply 🫶 This section only covers the extra stuff and changes that CEMA brings to the table ✨

The whole point of CEMA is to let MSRP work over Middleboxes 🦋 These Middleboxes are usually run by SIP network operators, and those operators also tend to have firewall and routing policies that stop media sessions from working unless the traffic goes through the Middleboxes. Main character energy, no cap 💀

CEMA lets Middleboxes tunnel TLS so you get end-to-end SAs between endpoints 🔐 This is a glow-up compared to the status quo. Without CEMA, the Middleboxes would have to both read and modify the cleartext MSRP messages, which would make end-to-end confidentiality and integrity protection of the MSRP transport channel impossible 😭

RFC 4975 suggests two ways for MSRP endpoints to check that the TLS connection is established end to end. Option one: use certificates from a well-known certification authority and verify that the SubjectAltName matches the MSRP URI of the other side. Option two: use self-signed certificates and include a fingerprint of the certificate in the SDP offer/answer. Provided the signaling is integrity protected, both endpoints can verify that the TLS SA is established with the correct host by matching the received certificate against the received fingerprint 🎀

Fingerprint-based authentication is expected to be super common for end clients 💜 To keep the fingerprint safe, RFC 4975 recommends using the SIP Identity mechanism [RFC4474]. BUT this mechanism may not be compatible with CEMA, which operates under the assumption that Middleboxes will modify the contents of SDP offers and answers 🙈 Until there's a mechanism that lets a subset of the SDP get signed, end clients that support CEMA and use fingerprint-based authentication are forced to trust the entire signaling path. In other words, end clients have to accept that every signaling proxy could potentially replace the fingerprints and insert a Middlebox that acts as a TLS B2BUA. Yikes 💀

An alternative that only needs limited trust in the signaling plane is to use self-signed certificates together with the SIP Certificate Management Service [RFC6072]. The security this gives you is roughly equivalent to SIP Identity and fingerprint-based authentication (fun fact: RFC 6072 is based on RFC 4474 🧚). Section 7.5 discusses this approach further.

In the remainder of this section, we will assume that fingerprint-based authentication is used without SIP Identity or similar mechanisms that protect the SDP across several hops 🌸

7.2. Man-in-the-Middle (MITM) Attacks 😈

If TLS isn't used to protect MSRP, CEMA might make it easier for a MITM to sneakily insert itself between MSRP endpoints so it can monitor or record unprotected MSRP communication 👀 This can be mitigated by using TLS, so it is therefore RECOMMENDED that TLS [RFC5246] be used. It's also recommended that TLS be used end to end, which CEMA enables even when there are Middleboxes 🫶 According to RFC 4975, MSRP endpoints are required to support TLS. This also applies to CEMA-enabled endpoints.

7.3. TLS Usage without Middleboxes

If TLS is used without Middleboxes, the security considerations in RFC 4975 and RFC 4976 still apply unchanged 💖 Just note that this isn't the main use case for the CEMA extension 🌈

7.4. TLS Usage with Middleboxes

This is the main use case for the CEMA extension 👑 The endpoints expect one or more Middleboxes.

CEMA supports both name-based authentication and fingerprint-based authentication for TLS when Middleboxes are in the picture. Fingerprint-based authentication requires signaling integrity protection. That can be, for example, hop-by-hop cryptographic protection, or cryptographic access protection combined with a suitably protected core network. As stated in Section 6.4, this document assumes that Middleboxes are able to modify the SDP address information associated with the MSRP media.

If a Middlebox acts as a TLS B2BUA, the security considerations are the same as those without the CEMA extension. In that case, the Middlebox acts as a TLS endpoint.

If a Middlebox does not act as a TLS B2BUA, TLS is end to end and the Middlebox just forwards the TLS packets. This requires that both peers support the CEMA extension 🤝

If fingerprint-based authentication is used, the MSRP endpoints might not be able to decide whether or not the Middlebox acts as a TLS B2BUA. But this is not an issue, as the signaling network is considered trusted by the endpoint (a requirement to use fingerprint-based authentication) ✨

7.5. Authentication, Credentials, and Key Management 🔑

One issue with the usage of TLS (not specific to CEMA) is the availability of a PKI. Endpoints can always provide self-signed certificates and include fingerprints in the SDP offer and answer. However, this relies on SDP signaling being integrity protected, which may not always be the case 😬

Therefore, in addition to the authentication mechanisms defined in RFC 4975, it is RECOMMENDED that a CEMA-enabled MSRP endpoint also support self-signed certificates together with the Certificate Management Service [RFC6072]. It publishes its self-signed certificate there, and it fetches on demand the self-signed certificates of other endpoints from there too.

Alternate key distribution mechanisms, such as DNS-Based Authentication of Named Entities (DANE) [DANE], Pretty Good Privacy (PGP) [RFC6091], Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY-TICKET) [RFC6043], or some other technology, might become ubiquitous enough to solve the key distribution problem in the future 🔮

One of the target deployments for CEMA is the 3GPP IMS SIP network 📱 In this environment, authentication and credential management are less of a problem. The SDP signaling is mostly considered trusted, service providers provision signed certificates or manage signed certificates on behalf of their subscribers, and MIKEY-TICKET is available. Some of these options require trusting the service provider, but those issues are beyond the scope of this document 🫡

7.6. Endpoint Procedures for TLS Negotiation 🤝

The CEMA extension does not change the endpoint procedures for TLS negotiation. As in RFC 4975, the MSRP endpoint uses the negotiation mechanisms in SDP and then the TLS handshake to agree on mechanisms and algorithms that both support. The mechanisms can be divided into three different security levels:

  1. MSRPS: Security mechanisms that do not rely on trusted signaling, such as name-based authentication
  2. MSRPS: Mechanisms that do rely on trusted signaling, such as fingerprint-based authentication
  3. MSRP: Unprotected

If the endpoint uses security mechanisms that do not rely on trusted signaling, the endpoint can detect if a Middlebox that acts as a B2BUA is inserted. It is therefore RECOMMENDED that such a mechanism be used 🕵️‍♀️

If the endpoint uses security mechanisms that rely on trusted signaling, the endpoint may not be able to detect if a Middlebox that acts as a B2BUA is inserted (by the trusted network operator). To be able to eavesdrop, a Middlebox must do an active "attack" on the setup signaling. A Middlebox cannot insert itself at a later point.

If unprotected MSRP is used, the endpoint cannot detect if a Middlebox that acts as a B2BUA is inserted, and Middleboxes may be inserted at any time during the session 😱

The mechanism in RFC 6072 [RFC6072] provides end-to-end security without relying on trust in the signaling plane, and it eases the use and deployment of name-based authentication 💅

The procedures for choosing and offering name-based authentication, fingerprint-based authentication, and unprotected MSRP as described in RFC 4975 still apply 🧾

7.7. Fingerprint-Based Authentication 🧐

If the endpoint cannot use a key management protocol that does not rely on trust in the signaling plane, such as name-based authentication, the only alternative is fingerprint-based authentication 🥺

Using fingerprint-based authentication requires integrity protection of the signaling plane. That can be, for example, hop-by-hop cryptographic protection, or cryptographic access protection combined with a suitably protected core network. Unless cryptographic end-to-end SDP integrity protection or encryption is used, this may be hard for the endpoint to decide. In the end, it's up to the endpoint to decide whether the signaling path is trusted or not 🤷‍♀️

How this decision is made is implementation specific, but normally, signaling over the Internet SHOULD NOT be trusted. Signaling over a local or closed network might be trusted. Such networks can be, for example, a closed enterprise network or a network operated by an operator that the end user trusts. In IMS, for example, the signaling traffic in the access network is integrity protected and the traffic is routed over a closed network separated from the Internet. If the network is not trusted, the endpoints SHOULD NOT use fingerprint-based authentication 🚫

When an endpoint receives a fingerprint, that fingerprint represents a binding between the identity as established by TLS and that established via SDP. As previously noted, the fingerprint is vulnerable to an active MITM attack from any on-path proxy. Endpoints SHOULD therefore locally store fingerprints associated with the relevant identities when first seen, and they SHOULD provide a warning when a new fingerprint is seen for what otherwise appears to be the same peer identity. While there are valid reasons for keys to change from time to time, that ought to be the exception -- hence the suggested warning 🚨

It should, however, be noted that using fingerprint-based authentication over an insecure network increases the security compared to unencrypted MSRP. In order to intercept the plaintext media when fingerprint-based authentication is used, the attacker is required to be present on both the signaling and media paths and actively modify the traffic. It is very hard for the endpoints to detect when such an attack is taking place, though. A client using DTLS-SRTP (a Secure Real-time Transport Protocol (SRTP) extension for Datagram Transport Layer Security (DTLS)) [RFC5764] for Voice over IP (VoIP) media security might wish to use fingerprint-based authentication also for MSRP media security 🎧

MSRPS with fingerprint-based authentication is vulnerable to attacks due to vulnerabilities in the SIP signaling. If there are weaknesses in the integrity protections on the SIP signaling, an attacker may insert malicious Middleboxes to alter, record, or otherwise harm the media. With insecure signaling, it can be difficult for an endpoint to even be aware that the remote endpoint has any relationship to the expected endpoint. Securing the SIP signaling does not solve all problems. For example, in a SIP Secure (SIPS) environment, the endpoints have no cryptographic way of validating that one or more SIP proxies in the proxy chain are not, in fact, malicious.

🚨 Bestie, this one is serious: fingerprint-based authentication is only as strong as the signaling underneath it. If the SIP signaling can be tampered with, a malicious Middlebox can alter, record, or harm the media, and the endpoints might not even notice 😭

8. IANA Considerations 📋

8.1. IANA Registration of the SDP 'msrp-cema' Attribute ✨

okay so IANA is the org that keeps the big official lists for the internet 🌸 and they just added a brand new attribute to the 'att-field (media level only)' registry of the Session Description Protocol (SDP) Parameters registry 💅. here's the whole registration, bestie:

Contact name: Christer Holmberg 🎀

Contact email: christer.holmberg@ericsson.com 💌

Attribute name: msrp-cema 🦋

Type of attribute: media level

Purpose: this attribute is used to indicate support of the MSRP Connection Establishment for Media Anchoring (CEMA) extension defined in RFC 6714. when it shows up in an MSRP media description of an SDP body, it means the creator of the SDP supports the CEMA mechanism 🫶

Values: the attribute does not carry a value.

Charset dependency: none

9. Acknowledgements 🙏

okay the people thanked here are seriously the real MVPs 👑. thanks to Ben Campbell, Remi Denis-Courmont, Nancy Greene, Hadriel Kaplan, Adam Roach, Robert Sparks, Salvatore Loreto, Shida Schubert, Ted Hardie, Richard L. Barnes, Inaki Baz Castillo, Saul Ibarra Corretge, Cullen Jennings, Adrian Georgescu, Miguel Garcia, and Paul Kyzivat for their guidance and input in order to produce this document ✨.

and thanks to John Mattsson, Oscar Ohlsson, Ben Campbell, and Stephen Farrell for helping restructure the Security Considerations section, based on feedback from the IESG 💜. they really cleaned it up, no cap 😭.

10. References 📚

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.

[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007.

[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC6072] Jennings, C. and J. Fischl, Ed., "Certificate Management Service for the Session Initiation Protocol (SIP)", RFC 6072, February 2011.

[RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", RFC 6135, February 2011.

10.2. Informative References

[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.

[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.

[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.

[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.

[RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6043, March 2011.

[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 6091, February 2011.

[GPP23228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 11.5.0, June 2012, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.

[DANE] "DNS-Based Authentication of Named Entities (DANE) Working Group", <https://datatracker.ietf.org/wg/dane/charter/>.

Authors' Addresses 💖

Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: christer.holmberg@ericsson.com


Staffan Blau
Ericsson
Stockholm  12637
Sweden

EMail: staffan.blau@ericsson.com


Eric Burger
Georgetown University
Department of Computer Science
37th and O Streets, NW
Washington, DC  20057-1232
United States of America

Fax:   +1 530 267 7447
EMail: eburger@standardstrack.com
URI:   http://www.standardstrack.com

That's the whole RFC, bestie! 🌈🧚 Every single contact, citation, and address is right where it belongs 🫶

📦 where this page comes from