ietf
[Top] [All Lists]

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

2010-07-02 03:05:22

Hi,

We have some ideas on how to address the issues and move forward, but due to 
summer vacations we will unfortunately most likely not be able reply to Ted's 
and Richard's e-mails before august.

Just to let you know.

Regards,

Christer








 

-----Original Message-----
From: Ted Hardie [mailto:ted(_dot_)ietf(_at_)gmail(_dot_)com] 
Sent: 29. kesäkuuta 2010 20:37
To: Christer Holmberg
Cc: Richard L. Barnes; secdir(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org; 
The 
IETF; draft-ietf-simple-msrp-sessmatch(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: secdir review of draft-ietf-simple-msrp-sessmatch

In-line.

On Tue, Jun 29, 2010 at 8:41 AM, Christer Holmberg 
<christer(_dot_)holmberg(_at_)ericsson(_dot_)com> wrote:

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:

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 sectio



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.

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.


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

regards,

Ted

Regards,

Christer



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

<Prev in Thread] Current Thread [Next in Thread>
  • RE: secdir review of draft-ietf-simple-msrp-sessmatch, Christer Holmberg <=