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

[Christer Holmberg <[e-mail]>]

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:[e-mail]] 
> Sent: 29. kesäkuuta 2010 20:37
> To: Christer Holmberg
> Cc: Richard L. Barnes; [e-mail]; [e-mail]; The 
> IETF; [e-mail]
> Subject: Re: secdir review of draft-ietf-simple-msrp-sessmatch
> 
> In-line.
> 
> On Tue, Jun 29, 2010 at 8:41 AM, Christer Holmberg 
> <[e-mail]> 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 
> <[e-mail]> 
> >> 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
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/ietf
> >> >
> >>
>