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