I join Richard in believing that this document makes changes beyond that
which could be understood as "updating" the MSRP URI scheme
processing.
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.
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.
regards,
Ted Hardie
On Mon, Jun 14, 2010 at 10:21 AM, Richard L. Barnes
<rbarnes(_at_)bbn(_dot_)com> wrote:
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.
I have a few significant reservations about this document:
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. 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. -- 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.
-- There is currently no requirement that a 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.
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.
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 an
new version of MSRP rather than an update.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf