Subject: secdir review of draft-ietf-simple-msrp-sessmatch

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 14 Jun 2010 13:21:55 -0400

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.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 14 Jun 2010 11:52:17 -0700

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 <[email-masked]> 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.
>
> 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.
>
> 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
> The document needs to clarify what the impacts are for authentication in
> secure modes of MSRP.  In particular:
> 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
> -- 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Jun 2010 17:41:52 +0200

Hi Ted,

>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:
> 
>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.

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."

>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..."

Regards,

Christer

> > to the "session-id" component, omitting the host, port, and 
> transport components.
> > 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.
> >
> > are only integrity-protected, then a proxy can remove the 
> integrity protection and redirect traffic without it being 
> observable to Alice.
> >
> > 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.
> > changes that assumption, and should note that these two 
> identities can differ.
> > 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.
> >

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 29 Jun 2010 12:42:48 -0400

> There are no impacts to MSRPS URIs. I assumed it would be implicitly  
> understood since MSRPS URIs are not mentioned in the draft.
>

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.

--Richard

---

From: Ted Hardie <[email-masked]>
Date: Tue, 29 Jun 2010 10:37:21 -0700

In-line.

On Tue, Jun 29, 2010 at 8:41 AM, Christer Holmberg
<[email-masked]> wrote:
> 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 sectio

>   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.

Creating a new URI scheme without re-using authority may be a better approach;
this would require more work, but it is cleaner than this appears to be.

>        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 ).

regards,

Ted