Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)
Extracted elements (28)
CEMA allows middleboxes to anchor MSRP by modifying only the SDP c/m-line (as they do for other media types), without needing to parse or modify MSRP messages. CEMA-enabled endpoints use the c/m-line address to establish the TCP/TLS connection rather than the 'path' attribute URI, enabling end-to-end TLS even with an anchoring middlebox.
CEMA is defined as an OPTIONAL extension with mandatory fallback to RFC 4975 behavior, ensuring that CEMA-enabled endpoints can still interoperate with the installed base of non-CEMA endpoints and relays. The extension only affects how the MSRP TCP connection address is determined; after connection establishment, RFC 4975/4976 message procedures apply unchanged.
SDP end-to-end integrity protection (e.g., SIP Identity) is incompatible with CEMA because CEMA requires middleboxes to modify the SDP c/m-line address. Until a mechanism for signing only a subset of SDP is available, endpoints using fingerprint-based authentication must accept that any signaling proxy could replace fingerprints.
Without CEMA, middleboxes cannot anchor MSRP connections without acting as MSRP B2BUAs because MSRP routing information is embedded in message headers. An active UA establishes the TCP/TLS connection using the SDP 'path' attribute URI rather than the c/m-line, so middlebox c/m-line modifications are ignored unless the middlebox also modifies the 'path' attribute, which then breaks MSRP URI comparison. This B2BUA requirement imposes high resource cost and violates end-to-end confidentiality.
Because CEMA-aware middleboxes do not parse MSRP payloads, they cannot reuse TCP connections across multiple MSRP sessions. Instead, each session typically gets a unique local address:port, which may result in a separate TCP connection per session between two middleboxes.
CEMA is backward compatible: if a non-CEMA-enabled endpoint becomes 'active', it uses the 'path' attribute URI instead of the c/m-line, causing fallback to RFC 4975 behavior. CEMA-enabled endpoints detect this and revert to base MSRP procedures when CEMA cannot be enabled.
CEMA will not be enabled (fallback to RFC 4975 occurs) when: a non-CEMA endpoint is 'active', a non-CEMA endpoint using a relay is 'passive', or a CEMA endpoint using a relay becomes 'active' (session matching would fail if c/m-line address were used in ToPath).
Middleboxes are assumed to implement MSRP B2BUA functionality as a fallback for endpoints that do not support CEMA. If a middlebox lacks B2BUA capability and the SDP offer contains no 'msrp-cema', CEMA-enabled endpoints may be unable to interoperate with non-CEMA endpoints across that middlebox.
A CEMA-enabled MSRP endpoint MUST support the alternative connection model defined in RFC 6135, which extends the scenarios where CEMA can be used (e.g., allowing a relay-using endpoint to be 'passive' instead of falling back).
A CEMA-enabled SDP offerer MUST include an SDP 'msrp-cema' attribute in the MSRP media description of the SDP offer.
An answerer using a relay MUST include the relay's address in the SDP c/m-line and MUST include 'setup:passive' in the MSRP media description of the answer.
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, according to RFC 6135 procedures.
If the offerer is using a relay, it MUST include the relay's address in the SDP c/m-line (not its own address) and MUST include an SDP 'setup:actpass' attribute in the MSRP media description of the SDP offer.
If the SDP offer contains no 'msrp-cema' attribute and the c/m-line address does not match the 'path' attribute MSRP URI, the answerer MUST either reject the MSRP connection (zero port) or reject the SIP request with 488 Not Acceptable Here.
The answerer MUST fall back to RFC 4975 behavior (without inserting 'msrp-cema') when both endpoints use relays, when the offerer uses a relay and will be 'active', or when the answerer uses a relay and cannot become 'passive'.
When CEMA is enabled and the answerer becomes 'active', it MUST use the received SDP c/m-line address to establish the MSRP TCP or TLS connection.
When CEMA is enabled, the answerer MUST include an SDP 'msrp-cema' attribute in the MSRP media description of the SDP answer, and MUST include an SDP 'setup' attribute per RFC 6135 if not using a relay.
When CEMA is successfully negotiated and the offerer becomes 'active', it MUST use the SDP c/m-line address information to establish the MSRP TCP or TLS connection, rather than the MSRP URI in the 'path' attribute.
When the offerer receives an SDP answer without an 'msrp-cema' attribute and certain mismatch conditions hold (middlebox detected in c/m-line with passive role, offerer-uses-relay with active role, or answerer-uses-relay with active offerer), the offerer MUST fall back to RFC 4975 behavior and send a new SDP offer without 'msrp-cema'.
Address information matching compares the SDP c/m-line (IP from c-line, port from m-line) against the authority part of the MSRP URI from 'path'. FQDNs are resolved via DNS; IPv6 addresses are normalized per RFC 5952 before comparison. Multiple DNS results each require comparison to find at least one match.
The SDP 'msrp-cema' attribute is a media-level, value-less SDP attribute that MSRP endpoints include in MSRP media descriptions to signal support for the CEMA extension. Its ABNF is: msrp-cema-attr = "msrp-cema", extending the attribute production from RFC 4566.
IANA registered a new media-level SDP attribute 'msrp-cema' in the 'att-field (media level only)' registry of the SDP Parameters registry. The attribute carries no value and indicates support for the CEMA extension defined in RFC 6714.
Endpoints SHOULD locally store TLS fingerprints associated with peer identities when first seen and SHOULD provide a warning when a new fingerprint is observed for what otherwise appears to be the same peer identity, since key changes should be the exception.
Fingerprint-based TLS authentication requires signaling integrity protection. Without cryptographic end-to-end SDP protection, any on-path proxy can replace fingerprints and insert a TLS B2BUA. Endpoints using fingerprint-based authentication are therefore forced to trust the entire signaling path, and signaling over the Internet SHOULD NOT be trusted for this purpose.
It is RECOMMENDED that CEMA-enabled endpoints support self-signed certificates together with the SIP Certificate Management Service (RFC 6072), publishing their own certificate and fetching peers' certificates on demand, as an alternative to relying on PKI availability or SDP signaling integrity.
MSRP endpoints using name-based authentication (certificate bound to hostname/SIP AOR and verified against a trusted CA or RFC 6072) can detect an unauthorized TLS B2BUA middlebox. It is RECOMMENDED to use such mechanisms that do not rely on trusted signaling.
When a middlebox does not act as a TLS B2BUA under CEMA, TLS is established peer-to-peer and the middlebox forwards encrypted packets without being able to inspect content. When endpoints fall back to RFC 4975 behavior, the middlebox acts as a TLS B2BUA, decrypting and re-encrypting all MSRP traffic.
Without TLS, CEMA makes it easier for a man-in-the-middle to transparently insert itself between MSRP endpoints. It is therefore RECOMMENDED that TLS be used and that it be used end to end; CEMA enables end-to-end TLS even in the presence of anchoring middleboxes.