One document matched: draft-ietf-simple-msrp-cema-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc category="std" docName="draft-ietf-simple-msrp-cema-00.txt"
ipr="trust200902" obsoletes="" submissionType="IETF" updates=""
xml:lang="en">
<front>
<title abbrev="CEMA">Connection Establishment for Media Anchoring (CEMA)
for the Message Session Relay Protocol (MSRP)</title>
<author fullname="Christer Holmberg" initials="C.H." surname="Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<author fullname="Staffan Blau" initials="S.B." surname="Blau">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<code>12637</code>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>staffan.blau@ericsson.com</email>
</address>
</author>
<author fullname="Eric Burger" initials="E.W." role="editor"
surname="Burger">
<organization>Georgetown University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>37th and O Streets, NW</street>
<city>Washington</city>
<region>DC</region>
<code>20057-1232</code>
<country>United States of America</country>
</postal>
<phone></phone>
<facsimile>+1 530 267 7447</facsimile>
<email>eburger@standardstrack.com</email>
<uri>http://www.standardstrack.com</uri>
</address>
</author>
<date day="26" month="August" year="2011" />
<area>Transport</area>
<workgroup>SIMPLE Working Group</workgroup>
<keyword>MSRP</keyword>
<keyword>CEMA</keyword>
<keyword>Middlebox</keyword>
<keyword>IBCF</keyword>
<keyword>SBC</keyword>
<keyword>relay</keyword>
<abstract>
<t>This document defines an Message Session Relay Protocol (MSRP)
extension, Connection Establishment for Media Anchoring (CEMA). MSRP
endpoints implement this extension to enable secure, end-to-end MSRP
communication in networks where Middleboxes anchor the MSRP connection.
CEMA eliminates the need for Middleboxes to modify MSRP messages.
Modifying MSRP messages requires the Middlebox to read the message in
plain text, exposing the message to attack. The document also defines a
Session Description Protocol (SDP) attribute, a=msrp-cema, that MSRP
endpoints use to indicate support of the CEMA extension.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>The Message Session Relay Protocol <xref format="default"
pageno="false" target="RFC4975">(MSRP)</xref> expects to use <xref
format="default" pageno="false" target="RFC4976">MSRP relays</xref> as a
means for Network Address Translation (NAT) traversal and policy
enforcement. However, many Session Initiation Protocol <xref
format="default" pageno="false" target="RFC3261">(SIP)</xref> networks,
which deploy MSRP, contain Middleboxes. These Middleboxes anchor and
control media, perform tasks such as NAT traversal, performance
monitoring, lawful intercept, address domain bridging, interconnect
Service Layer Agreement (SLA) policy enforcement, and so on. One example
is the Interconnection Border Control Function <xref format="default"
pageno="false" target="GPP23228">(IBCF)</xref>, defined by the 3rd
Generation Partnership Project (3GPP). The IBCF controls a media relay
that handles all types of SIP session media such as voice, video, MSRP,
etc.</t>
<t>MSRP, as defined in <xref format="default" pageno="false"
target="RFC4975">RFC 4975</xref> and <xref format="default"
pageno="false" target="RFC4976">RFC 4976</xref>, cannot anchor through
Middleboxes. The reason is that MSRP messages have routing information
embedded in the message. Without an extension such as CEMA, Middleboxes
must read the message to change the routing information. This occurs
because Middleboxes modify the address:port information in the Session
Description Protocol <xref format="default" pageno="false"
target="RFC4566">(SDP)</xref> c/m-line in order to anchor media. Since
the active MSRP UA establishes the MSRP TCP connection based on the MSRP
URI of the SDP a=path attribute, this means that the MSRP connection
will not, unless the Middlebox also modifies the MSRP URI of the topmost
SDP a=path attribute, be routed through the Middlebox. In many scenarios
this will prevent the MSRP connection from being established. In
addition, if the Middlebox modifies the MSRP URI of the SDP a=path
attribute, then the MSRP URI comparison procedure <xref format="default"
pageno="false" target="RFC4975"></xref>, which requires consistency
between the address information in the MSRP messages and the address
information carried in the MSRP URI of the SDP a=path attribute, will
fail. Also the matching will fail if Middleboxes modify the address
information in the MSRP URI of the SDP a=path attribute.</t>
<t>The only way to achieve interoperability in this situation is for the
Middlebox to be a MSRP back-to-back User Agent (B2BUA). Here the MSRP
B2BUA acts as the endpoint for the MSRP signaling and media, performs
the corresponding modification in the associated MSRP messages, and
originates a new MSRP session towards the actual remote endpoint.
However, this interoperability comes at the cost of exposing the MSRP
message in clear text to the MSRP B2BUA. This is a serious violation of
the <xref target="RFC3724">end-to-end principle</xref>.</t>
<t>This specification defines an MSRP extension, Connection
Establishment for Media Anchoring (CEMA). CEMA in most cases allows MSRP
endpoints to communicate through Middleboxes without a need for the
Middleboxes to be a MSRP B2BUA. In such cases, Middleboxes that want to
anchor the MSRP connection simply modify the SDP c/m-line address
information, similar to what it does for non-MSRP media types. MSRP
endpoints that support the CEMA extension will use the SDP c/m-line
address information for establishing the TLS connection for sending and
receiving MSRP messages.</t>
<t>The CEMA extension is fully backward compatible. In scenarios where
MSRP endpoints do not support the CEMA extension, an MSRP endpoint that
supports the CEMA extension behaves in the same way as an MSRP endpoint
that does not support it. The CEMA extension only provides an
alternative mechanism for negotiating and providing address information
for the MSRP TCP connection. After the creation of the MSRP TCP
connection, an MSRP endpoint that supports the CEMA extension acts
according to the procedures for creating MSRP messages, performing
checks when receiving MSRP messages defined in RFC 4975 and, when it is
using a relay for MSRP communications, RFC 4976.</t>
</section>
<section title="Conventions" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 <xref
format="default" pageno="false" target="RFC2119"></xref>.</t>
<t>Definitions:</t>
<t><list hangIndent="5" style="hanging">
<t hangText="Fingerprint Based TLS Authentication">An MSRP endpoint
that uses a self-signed TLS certificate and sends a certificate
fingerprint in SDP.</t>
<t hangText="Name Based TLS Authentication">An MSRP endpoint that
uses a certificate from a well known certificate authority and the
other endpoint matches the hostname in the received TLS
communication SubjectAltName parameter towards the hostname received
in the MSRP URI in SDP.</t>
<t hangText="B2BUA">This is an abbreviation for back-to-back user
agent.</t>
<t hangText="MSRP B2BUA">A network element that terminates an MSRP
stream from a first MSRP endpoint and reoriginates that stream
towards a second MSRP endpoint. Note the MSRP B2BUA is distinct from
a SIP B2BUA. A SIP B2BUA terminates a SIP session and reoriginates
that session towards the SIP endpoint. In the context of MSRP, a
first SIP endpoint initiates a SIP session towards the remote SIP
endpoint. However, that INVITE may go through, for example, an
outbound Proxy or inbound Proxy to route to the remote SIP endpoint.
That SIP session negotiates a MSRP session that may or may not
follow the SIP session path. Although often the case, there is no
requirement to co-locate the SIP network elements with the MSRP
network elements.</t>
<t hangText="Middlebox">A SIP network device that modifies SDP media
address:port information in order to steer or anchor media flows
described in the SDP, including TLS connections used for MSRP
communication, through a media proxy function controlled by the SIP
endpoint. In most cases the media proxy function relays the MSRP
messages without modification, while in some circumstances it acts
as a MSRP B2BUA. Other SIP related functions, such as related to
routing, modification of SIP information etc., performed by the
Middlebox, and whether it acts a SIP B2BUA or not, is outside the
scope of this document. <xref target="S.assumption"></xref>
describes additional assumptions regarding how the Middlebox handles
MSRP in order to support the extension defined in this document.</t>
</list></t>
</section>
<section title="Applicability Statement" toc="default">
<t>This document defines an MSRP extension, Connection Establishment for
Media Anchoring (CEMA). Support of the extension is optional. MSRP
endpoints implement the extension in order to allow MSRP communication
in networks where Middleboxes anchor the MSRP connection, without the
need for the Middleboxes to decode and rewrite MSRP messages and
enabling end-to-end security. The document also defines a Session
Description Protocol (SDP) <xref format="default" pageno="false"
target="RFC4566"></xref> attribute, a=msrp-cema, that can be used by
MSRP endpoints to indicate support of the CEMA extension.</t>
<t>An important use case for CEMA are Third-Generation Partnership
Program Internet Multimedia System (3GPP IMS) SIP networks. These
networks use Middleboxes for various functions. Moreover, these networks
have the capability for all endpoints to use Name-based TLS
Authentication.</t>
<t>There is nothing special about 3GPP IMS SIP networks to indicate the
use of CEMA. Rather, CEMA is an important update to MSRP that closes a
number of existing security issues and creates a foundation for closing
other security issues in the future. Therefore, CEMA is for all MSRP
deployments that use Middleboxes. Moreover, because of the presence of
secure transport, CEMA is for all MSRP deployments, including those
without Middleboxes.</t>
<t><xref target="sec-security"></xref> describes this further.</t>
</section>
<section title="Connection Establishment for Media Anchoring Mechanism"
toc="default">
<section title="General" toc="default">
<t>This section defines how an MSRP endpoint that supports the CEMA
extension generates SDP offers and answers for MSRP, and what SDP
information elements the MSRP endpoint uses when creating the TLS
connection for the MSRP messages.</t>
</section>
<section anchor="S.offerer" title="MSRP Offer Procedures" toc="default">
<t>When a CEMA-enabled MSRP endpoint sends an SDP offer for MSRP, it
generates the SDP offer according to the procedures in RFC 4975. In
addition, the endpoint follows RFC 4976 if it is using a relay for
MSRP communication. The endpoint also performs the following additions
and modifications:</t>
<t><list style="numbers">
<t>The MSRP endpoint MUST include an SDP a=msrp-cema attribute in
the MSRP media description of the SDP offer.</t>
<t>If the MSRP endpoint is not using a relay for MSRP
communication, it MUST include an SDP a=setup attribute in the
MSRP media description of the SDP offer, according to the
procedures in <xref target="RFC6135">RFC 6135</xref>.</t>
<t>If the MSRP endpoint is using a relay for MSRP communication,
it MUST include the address information of the relay (the MSRP URI
of the topmost SDP a=path attribute), rather than the address
information of itself, in the SDP c/m-line associated with the
MSRP media description. In addition, it MUST include an SDP
a=setup:actpass attribute in the MSRP media description of the SDP
offer.</t>
</list></t>
<t>The MSRP endpoint then receives the first SDP answer to the SDP
offer above. The SDP answer indicates that the remote MSRP endpoint
accepted the offered MSRP media if the port number of the MSRP media
description is not zero. If the MSRP media description of the SDP
answer does not contain an SDP a=msrp-cema attribute, the MSRP
endpoint makes the following checks. If either or both of these checks
fails, the MSRP endpoint MUST fallback 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 a=msrp-cema
attribute.</t>
<t><list style="numbers">
<t>The SDP c/m-line address information associated with the MSRP
media description does not match the information in the MSRP URI
of the topmost SDP a=path attribute, and the MSRP media
description contains an SDP a=setup:active attribute (indicating
that the remote MSRP endpoint is "active").</t>
<t>The MSRP media description contains multiple SDP a=path
attributes, indicating the use of MSRP relays.</t>
</list></t>
<t>In the absence of the SDP a=msrp-cema attribute in the new offer,
the Middlebox MUST act as an MSRP B2BUA to anchor MSRP media. Note the
originating endpoint should reject the session if it can detect the
MSRP B2BUA is not the desired remote endpoint.</t>
<t>The MSRP endpoint can send the new offer within the existing <xref
format="default" pageno="false" target="RFC3261">early dialog</xref>,
or it can terminate the early dialog and establish a new dialog by
sending the new offer in a new initial INVITE request.</t>
<t>In all other cases, where the MSRP endpoint becomes "active", it
MUST use the SDP c/m-line for establishing the MSRP TLS connection. If
the MSRP endpoint becomes "passive", it will wait for the remote MSRP
endpoint to establish the TLS connection, according to the procedures
in RFC 4975.</t>
</section>
<section title="MSRP Answer Procedures" toc="default">
<t>If any of the criteria below are met, the MSRP endpoint MUST
fallback to RFC 4975 behavior and generate the associated SDP answer
according to the procedures in RFC 4975 and RFC 4976. The MSRP
endpoint MUST NOT insert an SDP a=msrp-cema attribute in the MSRP
media description of the SDP answer.</t>
<t><list style="numbers">
<t>Both MSRP endpoints are using relays for MSRP communication. An
endpoint can detect the remote MSRP endpoint is using a relay for
MSRP communication if the MSRP media description of the SDP offer
contains multiple SDP a=path attributes.</t>
<t>The remote MSRP endpoint uses a relay for MSRP communication,
and will become "active" either by default or if the MSRP media
description of the SDP offer contains an SDP a=setup:active
attribute. This case indicates the remote MSRP endpoint does not
support the CEMA extension. A CEMA-enabled endpoint would include
an SDP a=setup:actpass attribute in the SDP offer, as described in
<xref target="S.offerer"></xref>.</t>
<t>The MSRP endpoint uses a relay for MSRP communication and is
not able to become "passive". The indication for this is the MSRP
media description of the offer contains an SDP a=setup:passive
attribute. This will not occur with a CEMA-enabled endpoint, as it
cannot include an SDP a=setup:passive attribute in an SDP offer,
as described in RFC 6135.</t>
<t>The MSRP media description of the SDP offer does not contain an
SDP a=msrp-cema attribute, the SDP c/m-line address information
associated with the MSRP media description does not match the
information in the MSRP URI of the topmost SDP a=path attribute,
and the remote MSRP endpoint will become "active", either by
default, or if the MSRP media description of the SDP offer
contains an SDP a=setup:active attribute.</t>
</list></t>
<t>In all other cases, the MSRP endpoint generates the associated SDP
answer according to the procedures in RFC 4975 and RFC 4976, with the
following additions and modifications:</t>
<t><list style="numbers">
<t>The MSRP endpoint MUST include an SDP a=msrp-cema attribute in
the MSRP media description of the SDP answer.</t>
<t>If the MSRP endpoint is not using a relay for MSRP
communication, it MUST include an SDP a=setup attribute in the
MSRP media description of the answer, according to the procedures
in RFC 6135.</t>
<t>If the MSRP endpoint is using a relay for MSRP communication,
it MUST include the address information on the relay (the MSRP URI
of the topmost SDP a=path attribute), rather than the address
information of itself, in the SDP c/m-line associated with the
MSRP media description. In addition, it MUST include an SDP
a=setup:passive attribute in the MSRP media description of the SDP
answer.</t>
</list></t>
<t>If the MSRP endpoint included an SDP a=msrp-cema attribute in the
MSRP media description of the SDP answer, and if the MSRP endpoint
becomes "active", it MUST use the received SDP c/m-line for
establishing the MSRP TLS connection. If the MSRP endpoint becomes
"passive", it will wait for the remote MSRP endpoint to establish the
TLS connection, according to the procedures in RFC 4975.</t>
</section>
<section title="Usage With the Alternative Connection Model"
toc="default">
<t>An MSRP endpoint that supports the CEMA extension MUST support the
mechanism defined in RFC 6135, as it extends the number of scenarios
where one can use the CEMA extension. An example is where a MSRP
endpoint is using a relay for MSRP communication, and it needs to be
"passive" in order to use the CEMA extension, instead of doing a
fallback to RFC 4975 behavior.</t>
</section>
</section>
<section anchor="S.assumption" title="Middlebox Assumptions" toc="default">
<section title="General" toc="default">
<t>This document does not specify explicit Middlebox behavior, even
though Middleboxes enable some of the procedures described here.
However, as one rationale for the CEMA extension is to allow MSRP
endpoints to communicate over end-to-end secure paths in networks
where Middleboxes that want to anchor media are present, this document
makes certain assumptions regarding to how such Middleboxes
behave.</t>
</section>
<section title="MSRP Awareness" toc="default">
<t>In order to support interoperability between UAs that support the
CEMA extension and UAs that do not support the extension, the
Middlebox is MSRP aware. This means that it implements MSRP B2BUA
functionality. The Middlebox enables that functionality in cases where
the remote endpoint does not support the CEMA extension. In cases
where at least one MSRP endpoint supports the CEMA extension, the
Middlebox can simply modify the SDP c/m-line address information for
the MSRP connection.</t>
</section>
<section title="TCP Connection Reuse" toc="default">
<t>Middleboxes do not need to parse and modify the MSRP payload when
endpoints use the CEMA extension. A Middlebox that does not parse the
MSRP payload probably will not be able to reuse TCP connections for
multiple MSRP sessions. Instead, in order to associate an MSRP message
with a specific session, the Middlebox often assigns a unique local
address:port combination for each MSRP session.</t>
</section>
<section title="SDP Integrity" toc="default">
<t>This document assumes that Middleboxes are able to modify the SDP
address information associated with the MSRP media. Middleboxes cannot
be deployed in environments that require end-to-end SDP protection
using <xref format="default" pageno="false" target="RFC4916">SIP
identity</xref>.</t>
</section>
<section title="TLS" toc="default">
<t>The Middlebox relays MSRP media packets at the transport layer. The
TLS handshake and resulting security association (SA) are established
peer-to-peer between the MSRP endpoints. The Middlebox will see
encrypted MSRP media packets, but is unable to inspect the clear text
content.</t>
<!--
<t>In the second approach, the Middlebox acts as a TLS B2BUA, meaning
that separate SAs are established between the Middlebox and each MSRP
endpoint. The Middlebox decrypts MSRP media packets received from one
MSRP endpoint, and then re-encrypts them before sending them toward
the other MSRP endpoint. With this approach, the Middlebox can inspect
and modify the MSRP message content.</t>
-->
</section>
</section>
<section anchor="sec-security" title="Security Considerations"
toc="default">
<section anchor="sec-security-mitm" title="Man in the Middle"
toc="default">
<t>In some cases, the CEMA extension could make it easier for a man in
the middle (MiTM) to transparently insert itself in the communication
between MSRP endpoints in order to monitor or record unprotected MSRP
communication. Therefore, endpoints MUST use encrypted channels. For
base interoperability, a CEMA-enabled MSRP endpoint MUST implement
TLS.</t>
</section>
<section anchor="sec-security-tls" title="TLS Usage" toc="default">
<t>The CEMA extension supports the usage of name-based authentication
for TLS in the presence of Middleboxes.</t>
<t>If a Middlebox acts as a TLS B2BUA, MSRP endpoints will be able to
use fingerprint based authentication for TLS, no matter if they
support the CEMA extension or not. In such cases, as the Middlebox
acts as TLS endpoints, MSRP endpoints might be given an incorrect
impression that there is an end-to-end security association (SA)
between the MSRP endpoints.</t>
<t>If a Middlebox does not act as a TLS B2BUA, fingerprint based
authentication will not work, as the "SIP Identity" based integrity
protection of SDP will break. Therefore, in addition to the
authentication mechanisms defined in RFC 4975, an MSRP endpoint
supporting the CEMA extension MAY support an authentication mechanism
that does not rely on peer-to-peer SDP integrity.</t>
<t>It is RECOMMENDED that an MSRP endpoint support one of the
following authentication mechanisms:<list style="numbers">
<t>TLS certificates together with support of interacting with a
<xref target="RFC6072">Certificate Management Service</xref>, to
which it publishes the public version of its own self-signed
certificate and from which it fetches on demand the public
certificates of other endpoints.</t>
<t>TLS-PSK managed by MIKEY-TICKET Based Key Management and Key
Management Service<xref format="default" pageno="false"
target="RFC6043"></xref>. Note that 3GPP has specified the
MIKEY-TICKET based Key Management and Key Management Service
authentication mechanism for the IP Multimedia Subsystem (IMS).
Thus it will be available in that environment.</t>
</list></t>
<t>When an MSRP endpoint generates an SDP offer for MSRPS, in addition
to the SDP attributes associated with the TLS authentication
mechanisms described in RFC 4975, it MUST include any information
elements associated with the other authentication mechanisms that it
supports.</t>
<t>Unless the MSRP endpoints are able to use name-based
authentication, and they support a common authentication mechanism,
they MUST use that mechanism. If the MSRP endpoints do not support
such common authentication mechanism, they MUST try fingerprint-based
authentication, which will succeed if there are no Middleboxes
present. If that also fails, the MSRP endpoints MUST either:</t>
<t><list style="numbers">
<t>Consider the TLS authentication as failed, in accordance with
RFC 4975; or</t>
<t>If something like SIPS protects the SIP signaling between the
MSRP endpoints, use fingerprint based authentication without
requiring peer-to-peer SDP integrity, and thus trust the network
endpoints in the signaling path for SDP integrity.</t>
</list></t>
<t>As defined in RFC 4975, if TLS authentication fails, the user needs
to be able to decide whether to try to establish an MSRP connection in
the likely scenario of intercepted, altered, or forged connections</t>
</section>
<section title="TLS and Insecure Signaling">
<t>MSRP is the only SIP-based media transport that has a layer
violation. MSRP media includes routing information, including from and
to URIs. Other SIP-based media can have separate paths for signaling
and media and can have end-to-end integrity of the media. Except for
MSRP, SIP-based media can flow through routers, NATs, <xref
target="RFC5766">TURN servers</xref>, <xref target="RFC5389">STUN
servers</xref>, and so on without modification.</t>
<t>CEMA provides an environment necessary for end-to-end integrity of
MSRP media. CEMA makes it possible to route MSRP media without
requiring modification of the media. This is what enables end-to-end,
cryptographic integrity assurance. However, while CEMA is a necessary
prerequisite for end-to-end integrity, it is not sufficient.</t>
<t>CEMA mandates an integrity-protected media channel. At the base
level, all CEMA endpoints MUST support TLS. Unless the CEMA endpoints
negotiate a stronger communications mechanism, the endpoints MUST use
TLS, even if they happen to not use a Middlebox for routing.</t>
<t>One issue with mandating TLS is the availability of a certificate
infrastructure. Endpoints can always provide self-signed certificates.
However, this is problematic in that any endpoint can masquerade as
another, by providing a self-signed certificate with the victim's
information.</t>
<t>The reason CEMA mandates TLS in light of such an obvious
vulnerability is three-fold.</t>
<t>First, one of the target deployments for CEMA is the 3GPP IMS SIP
network. In this environment it is trivially easy for the service
provider to provide signed certificates or manage signed certificates
on behalf of their subscribers. This does require trusting the service
provider, but those issues are beyond the scope of this document.</t>
<t>Second, alternate key distribution mechanisms, such as <xref
target="DANE">DANE</xref>, <xref target="RFC6091">PGP</xref>, or some
other technology may become ubiquitous enough to solve the key
distribution problem.</t>
<t>Third, experiences with IETF protocols have been that when security
is put on as an afterthought or is optional, it rarely gets deployed.
There is a clear path over time for creating a key distribution
mechanism. Thus mandating TLS at this time removes one of the
recurring excuses to not deploy secure solutions build to Internet
security norms. Namely, that one cannot deploy a secure solution
because legacy endpoints do not have TLS capability.</t>
<t>Even with seemingly end-to-end media integrity, at the time of the
publication of this document there are other vulnerabilities in MSRP
that mean users may not have truly end-to-end security. These issues
come from vulnerabilities in the SIP signaling. If there are no
integrity protections on the SIP signaling, it is trivially easy for a
bad actor to surreptitiously insert evil Middleboxes to alter, record,
or otherwise harm the media. With insecure signaling, it can be very
difficult for an endpoint to even be aware the remote endpoint has any
relationship to the expected endpoint. Securing the SIP signaling does
not solve all problems. For example, in a SIPS environment, the
endpoints have no cryptographic way of validating that one or more SIP
Proxies in the proxy chain are not, in fact, evil.</t>
<t>In light of these vulnerabilities, why does CEMA mandate the more
resource-intensive TLS instead of TCP for MSRP connections, and why
does CEMA claim it has more security than deploying MSRP B2BUAs?</t>
<t>From a processing load perspective, the burden of TLS falls
entirely on the endpoints. CPU capability and battery life of even
low-end mobile devices are such that this is no longer a barrier for
mandating TLS. Moreover, as an added bonus, CEMA removes the
requirement for Middleboxes to decode, read, rewrite, and
re-encrypting MSRP media. This means that Middleboxes can have much
more scale and performance with CEMA.</t>
<t>From a framework perspective, the ubiquitous deployment of TLS,
while to totally ensuring integrity in all cases, does enable the
environment for further end-to-end integrity solutions. For example,
one could envision mechanisms where the endpoints create security
associations in the MSRP media stream. This, coupled with future
end-to-end integrity protected or assured SIP signaling, will provide
for true end-to-end MSRP integrity. By mandating TLS today, we
eliminate the possibility of future downgrade attacks in light of more
robust solutions.</t>
<t>This situation is comparable to <xref
target="RFC4033">DNSSEC</xref>. DNSSEC does not solve all DNS
integrity issues, but it does create an environment that immediately
solves some problems and lays the groundwork for future, more robust
solutions.</t>
</section>
<section title="Downgrade Attacks">
<t>In order to ensure interoperability, CEMA clients can chose to
conenct to non-CEMA clients. Whilst CEMA clients must use TLS, the
CEMA client may connect to a pre-CEMA, RFC 4975 client. Although RFC
4975 mandates the implementation of TLS, RFC 4975 does not mandate the
usage of TLS. Therefore, a pre-CEMA client may chose to use only TCP.
In this case, in the name of interoperability, a CEMA client MAY use a
standard RFC 4975 TCP connection.</t>
<t>The security implication is that an evil client or middlebox could
strip the CEMA information from the negotiation. In this case, the
CEMA client would believe the other end when it claims not to
implement TLS. CEMA clients SHOULD attempt to validate non-TLS
requests via mechanisms such as by using secured signaling chanels,
unless those mechansims are truly unavailable.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<section title="IANA Registration of the SDP a=msrp-cema Attribute"
toc="default">
<t>This section registers a new SDP attribute, a=msrp-cema. The
required information for this registration, as specified in RFC 4566,
is:</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
Contact name: Christer Holmberg
Contact e-mail: christer.holmberg@ericsson.com
Attribute name: a=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 XXXX. When present in an MSRP media
description of an SDP body, it indicates
that the sending UA supports the CEMA
mechanism.
Values: The attribute does not carry a value
Charset dependency: none
]]></artwork>
</figure>
</section>
</section>
<section anchor="sec-acks" title="Acknowledgements" toc="default">
<t>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, and Adrian Georgescu for their guidance and input in
order to produce this document.</t>
</section>
<section title="Change Log">
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>
<t>Changes from draft-ietf-simple-msrp-sessmatch-13<list style="symbols">
<t>Changed the draft name, as was suggested by our AD and work
group.</t>
<t>Reorient the draft from being about saving resources at a
Middlebox to being about end-to-end security.</t>
<t>Clean up language use, clarify language, and clean up editorial
and style issues.</t>
<t>TLS is mandated for all connections.</t>
<t>Describe why, even though not perfect, CEMA mandates TLS in the
Security Considerations section.</t>
<t>Formally defined a MSRP B2BUA.</t>
<t>Took out all of the TLS B2BUA language, as that is implied by an
MSRP B2BUA.</t>
<t>Describe signaling attacks in the Security Considerations
section.</t>
<t>Provide a roadmap for future work on end-to-end security.</t>
<t>Added normative reference to RFC 6072.</t>
<t>Added informative references to RFC 3724, RFC 4033, RFC 5389, RFC
5766, and RFC 6091</t>
</list></t>
<t>Changes from draft-ietf-simple-msrp-sessmatch-12 <list
style="symbols">
<t>Extension name changed to Connection Establishment for Media
Anchoring (CEMA).</t>
<t>Middlebox defintion added.</t>
<t>ALG terminology replaced with Middlebox.</t>
<t>SDP attribute name changed to a=msrp-cema.</t>
<t>Applicability Statement section expanded.</t>
<t>Re-structuring of MSRP Answerer section.</t>
<t>Changes based on comments from Saúl Ibarra Corretgé
(1406111).</t>
</list></t>
<t>Changes from draft-ietf-simple-msrp-sessmatch-11 <list
style="symbols">
<t>Modification of the sessmatch mechanism.</t>
<t>- Extension name changed to Alternative Connection Establishment
(ACE)</t>
<t>- Session matching procedure no longer updated.</t>
<t>- SDP c/m-line used for MSRP TCP connection.</t>
<t>- sessmatch option-tag removed.</t>
<t>- a=msrp-ace attribute defined.</t>
<t>- Support of RFC 6135 mandatory.</t>
</list></t>
<t>Changes from draft-ietf-simple-msrp-sessmatch-10 <list
style="symbols">
<t>Sessmatch option-tag added, based on WG discussions and
concensus.</t>
</list></t>
<t>Changes from draft-ietf-simple-msrp-sessmatch-08 <list
style="symbols">
<t>OPEN ISSUE regarding the need for a sessmatch option-tag
removed.</t>
</list></t>
<t>Changes from draft-ietf-simple-msrp-sessmatch-07 <list
style="symbols">
<t>Sessmatch defined as an MSRP extension, rather than MSRP
update</t>
<t>Additional security considerations text added</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.4975"?>
<?rfc include="reference.RFC.4976"?>
<?rfc include="reference.RFC.6072"?>
<?rfc include="reference.RFC.6135"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3724"?>
<?rfc include="reference.RFC.4033"?>
<?rfc include="reference.RFC.4916"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include="reference.RFC.5766"?>
<?rfc include="reference.RFC.6043"?>
<?rfc include="reference.RFC.6091"?>
<reference anchor="DANE">
<front>
<title>DNS-based Authentication of Named Entities Work Group</title>
<author>
<organization></organization>
</author>
<date />
</front>
<format target="https://datatracker.ietf.org/wg/dane/charter/"
type="HTML" />
</reference>
<reference anchor="GPP23228">
<front>
<title>IP Multimedia Subsystem (IMS); Stage 2</title>
<author>
<organization>3GPP</organization>
</author>
<date day="13" month="June" year="2011" />
</front>
<seriesInfo name="3GPP TS" value="23.228 10.5.0" />
<format target="http://www.3gpp.org/ftp/Specs/html-info/23228.htm"
type="HTML" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 23:57:00 |