Hi,
The purpose of this e-mail is to address the secdir comments given by
Richard
Barnes and Ted Hardie. Due to summer vacations, standardization meetings
etc it took a while to put the e-mail together, and we appologise for that.
GENERAL
=======
First, the draft does NOT propose any changes to the TLS authentication
procedures – that will be clarified. The changes are only related to the
procedure for matching an incoming MSRP message to an MSRP session that
has been negotiated using SDP – once any TLS authentication procedure has
already taken place.
So, in case of TLS and name based authentication, if an SBC/ALG modifies
the a=path MSRP URI, the TLS authentication WILL fail. That is the current
behavior, and sessmatch doesn’t change that.
We understand that this fact needs to be clearly indicated in the draft.
Basically sessmatch allows so that, when using peer to peer MSRP, SIP SBCs
and SIP aware firewalls can be in the SIP signaling path without acting as
MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP relays
the SBC/ALG needs to act as MSRP B2BUA, as today.
Sessmatch aims to extend the usability of MSRP peer to peer communication
to
scenarios where simple ALGs/SBCs are used, and at least in our experience
customer interest for standard MSRP has grown (from more or less zero)
dramatically due to sessmatch. And, OMA, which previously used a
*non-standard*
version of MSRP (with no interoperability with standard MSRP), has also
agreed
to switch to sessmatch (even if it required a number of changes in their
specifications).
Second, the intention of sessmatch is not to modify the MSRP URI matching
rules,
but rather to not use MSRP URI matching for session matching.
Please also note that when we talk about SBCs/ALGs, we refer to entities
that
normally do NOT have the capability to act as MSRP B2BUAs.
We will comment the individual comments based on the assumptions above.
Comments from Richard
=====================
I have reviewed this document as part of the security directorate's
ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.
Document editors and WG chairs should treat these comments just like any
other
last call comments.
This document changes the URI matching algorithm used in MSRP. MSRP
sessions
are typically initiated using SDP bodies in SIP. These SDP
bodies contain MSRP URIs that the peers use to contact each other.
When one peer receives a request to initiate a session, he verifies that
the
URI being requested is one that he initiated in SDP, thereby using the
URI as a
shared secret to authenticate that the originator of the session actually
received the SDP body in question.
According to the current SDP specification, this comparison is performed
over
the whole URI; this document restricts the comparison to the "session-id"
component, omitting the host, port, and transport components. The goal
of the
document is to facilitate a certain class of man-in-the-middle attack,
namely
to allow a signaling intermediary to insert a media intermediary. The
restriction on the URI comparison is needed in order for the media
intermediary
not to have to modify URIs in MSRP packets to reflect the modifications
to URIs
in SDP bodies performed to redirect traffic through the media
intermediary.
When an MSRP UA receives an MSRP packet it performs msrp session matching
in order
to verify that the msrp packet belongs to an existing SDP negotiated msrp
session
at the UA. RFC4975 prescribes that URI matching should be used for session
matching.
We argue that the namespace scoping of the session-id values that use of
URI matching
brings is unnecessary. The 80-bit randomness of the session-id and the
fact that it
was the UA itself that decided on the session-id value and can ensure that
it is
unique within the UA makes the session-id sufficiently unique for session
matching.
Sessmatch is not changing the MSRP URI matching algorithm, it is changing
the session
matching algorithm not to use MSRP URI matching.
I have a few significant reservations about this document:
1) This extension makes it more difficult for MSRP entities to secure
their
communications against attackers in the signaling path. The current model
provides a basic integrity protection, in that signaling intermediaries
cannot
redirect traffic to an arbitrary third party; they must at least advise
the
third party about how to modify MSRP packets. The proposed modification
would
remove even this cost.
If we do not introduce the sessmatch change then the only alternative for
MSRP
connections to be able to be set up when SBCs or SIP aware firewalls are
in the
SIP signaling path is for these to introduce MSRP B2BUA support. This is
probably
not feasible for most SBCs and SIP aware firewalls, and if it actually were
feasible then it would mean as big a security problem, or even bigger, than
sessmatch. The choice is thus to not use MSRP at all in presence of such
devices
or to introduce sessmatch. Not to fix this probably would mean that use of
MSRP
will be marginalized.
2) Moreover, it raises the cost of providing integrity protection to
messages,
since Alice must now employ both integrity and confidentiality
protections on
an end-to-end basis; if her messages are only integrity-protected, then a
proxy
can remove the integrity protection and redirect traffic without it being
observable to Alice.
The document needs to clarify what the impacts are for authentication in
secure
modes of MSRP. In particular:
-- The distinction between "self-signed" and "public" certificates is
inappropriate. The proper distinction is between the name-based
authentication
in Section 14.2 of RFC 4975 and the fingerprint-based authentication in
Section
14.4.
We cannot find the terminology “name-based” authentication in RFC 4975.
The RFC talks
about TLS authentication using either certificates from well-known
certificate
authorities, or using self-signed certificates together with certificate
fingerprints.
Having said that, however, we DO agree that the terminology you suggest is
more
appropriate than what we have used and we will introduce this terminology
and explain
it in the Convention section of the sessmatch draft.
-- In either case, changing the host name need not result in an
authentication
failure, since the media intermediary can simply authenticate as itself
to both
endpoints, having changed the respective MSRP URIs appropriately.
A media intermediary can only do this if it is an MSRP B2BUA, and
sessmatch was
introduced just to avoid most SBCs and ALGs having to implement an MSRP
B2BUA in order
to allow standard MSRP deployment.
-- There is currently no requirement that an endpoint identity in the
To-Path
URI matches the endpoint identity authenticated at the TLS layer, because
these
two are required to be the same. This document changes that assumption,
and
should note that these two identities can differ.
We will explicitly mention this.
The document also precludes any name-based multiplexing, where a single
MSRP
process (single IP address and port) directs requests to different virtual
recipients based on the domain name in the To-Path header. (In analogy to
Host-based multiplexing in HTTP, which is very widely deployed.) Since
with
this extension, the domain in the To- Path is completely unpredictable
from the
recipient's perspective, it is useless to the recipient.
That is correct, but there should be no problem for a single MSRP process
(single
IP address and port) to direct requests to different virtual recipients -
based
on the session-id instead. It is only needed for the different virtual
recipients
to inform the receiver process on which session-ids that are currently
negotiated
instead of informing it on which domain name the virtual recipient shall be
associated with.
The document has no backward-compatibility. MSRP implementations that do
not
support this extension will not be able to receive MSRP sessions from
implementations that do. In that regard, this document seems more like a
new
version of MSRP rather than an update.
It is not true that there is no backwards compatibility. If there are no
SIP ALGs/SBCs in the SIP/SDP signalling path then there is no problem for
MSRP
implementations that do not support the sessmatch extension to receive MSRP
sessions from implementations that do.
MSRP implementations that do not support the sessmatch extension are
however not
able to establish MSRP end to end conversations if there are ALGs/SBCs in
the
session path (unless these implement MSRP B2BUA) and sessmatch does not
change this
fact – it will not work disregarding if the other endpoint supports
sessmatch or not.
I also note that the security considerations, in addition to having
some fairly disingenuous language about the impact of this change,
seems to fail to mention MSRPS URIs and what, if any, impact this
would have on them.
There are no impacts to MSRPS URIs. I assumed it would be implicitly
understood since MSRPS URIs are not mentioned in the draft.
However, we could explicitly make it clear by modifying the first
sentences of section 5:
"The change of session matching procedure does not impact the
format of MSRP URIs, disregarding if the "msrp" scheme or the "msrps"
scheme
is used. However, MSRP endpoints can only check that the session-id part
of
the MSRP URI..."
The conflict here is that with MRSPS authentication, the name in the
certificate is checked against the domain name in the URI, which was OK
when
the URI in the message was required to be the same. By allowing the domain
name in the message to change, this draft removes man-in-the-middle
protection
from MSRPS.
The document notes that a SIP MitM can already direct the user to another
destination. However, if the peers use MSRPS with the current
authentication
scheme, the MitM will not be able to be a part of the resulting MSRPS
session,
since he can't authenticate as one of the endpoints. If only the session
ID is
used in comparisons, the MitM can patch himself in by changing the domain
in
the MSRPS URI. (Which actually seems to be the intended use case for this
draft.)
So the current document does introduce a new MitM vulnerability to MSRPS.
Sessmatch does not change the fact that name based TLS authentication for
MSRPS
will fail if an SBC or ALG has modified the hostname value in the MSRP URI
in the
SDP a=path attribute without also acting as MSRP B2BUA.
Comments from Ted
=================
I join Richard in believing that this document makes changes beyond that
which
could be understood as "updating" the MSRP URI scheme processing.
...
I also note that the security considerations, in addition to having some
fairly
disingenuous language about the impact of this change, seems to fail to
mention
MSRPS URIs and what, if any, impact this would have on them.
We will clarify what impacts there are.
-------
To highlight one particular aspect, RFC 4975 does not require
session-ids to be present, a fact noted both in the ABNF and in this
text:
4. The session-id part is compared as case sensitive. A URI without
a session-id part is never equivalent to one that includes one.
A matching scheme which relies on a URI section which is not
guaranteed to be present has some interesting problems ahead of it. If
this effectively makes their use mandatory, that requires a change to
the fundamental ABNF and text.
An MSRP URI in an SDP offer or answer for an MSRP session MUST include a
session-id part, so I believe the comment is
based on incorrect assumptions.
This is not indicated in the URI matching section
We will clarify that sessmatch conformant UAs do not use MSRP URI matching
in
order to perform MSRP session matching.
Section 6 of RFC 4975 says:
"The session-id part identifies a particular session of the
participant. The absence of the session-id
part indicates a reference to an MSRP host device, but does not refer to
a
particular session at that device."
The full section from which that quote is taken is:
The MSRP URI authority field identifies a participant in a particular
MSRP session. If the authority field contains a numeric IP address,
it MUST also contain a port. The session-id part identifies a
particular session of the participant. The absence of the session-id
part indicates a reference to an MSRP host device, but does not refer
to a particular session at that device. A particular value of
session-id is only meaningful in the context of the associated
authority; thus, the authority component can be thought of as
identifying the "authority" governing a namespace for the session-id.
This proposal changes the concept of a namespace authority present in the
URI
matching section of RFC 4975. I am sorry if my wry reference to this in my
previous message was hard to follow; I should have known better.
To be more plain, this proposal fundamentally changes the matching
semantics of
the URI set out in RFC 4975, by requiring a match on only a portion of
the URI.
At a bare minimum, this would require noting a normative update to
section 6
and 6.1 of RFC 4975, which this draft does not do. In reality, this is
unlikely to be sufficient, as URI matching semantics do not generally
have the
concept of ignoring the authority in providing a match (at least in my
reading
of the RFC 3986 "ladder of comparison" text). That means you'd have to
special
case the MSRP matching semantics, rather than have the URI be parsed and
compared using a standard library.
Sessmatch removes the URI matching as a means to do MSRP session matching,
and
replaces it with a pure session-id matching. There is no need to create a
new
URI scheme that does not re-use the authority component. We believe the
minimum
80-bit randomness of the session-id, together with the fact that the UA
itself
generates the session-id it matches on, to be enough for the session-id to
be
unique in the scope of the sessions that are active at the UA.
Also, the security of the matching is not particularly decreased, since it
is
relatively easy to find out the authority name anyway.
I also note that the security considerations, in addition to having
some fairly disingenuous language about the impact of this change,
seems to fail to mention MSRPS URIs and what, if any, impact this
would have on them.
There are no impacts to MSRPS URIs. I assumed it would be implicitly
understood
since MSRPS URIs are not mentioned in the draft.
However, we could explicitly make it clear by modifying the first
sentences of
section 5:
"The change of session matching procedure does not impact the format of
MSRP
URIs, disregarding if the "msrp" scheme or the "msrps" scheme is used.
However, MSRP endpoints can only check that the session-id part of the
MSRP
URI..."
This doesn't seem to me to actually work, based on Richard's comments,
unless
what you mean to say is "if MSRPS is in use, nothing in this draft can be
used". That gives you different matching semantics for MSRPS (authority
must
be present and must be matched using TLS semantics) vs MSRP (only
session-id is
checked) which is at the very least a violation of the principle of least
surprise (no other foo over TLS protocol works that way that I know of ).
Session matching is done when receiving MSRP packets on an already
established TCP
or TCP/TLS connection, and there will not be any different session
matching procedure
depending on if the connection uses TLS or plain TCP.
Regards,
Christer