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.ietf@xxxxxxxxx] > Sent: 29. kesäkuuta 2010 20:37 > To: Christer Holmberg > Cc: Richard L. Barnes; secdir@xxxxxxxx; iesg@xxxxxxxx; The > IETF; draft-ietf-simple-msrp-sessmatch@xxxxxxxxxxxxxx > Subject: Re: secdir review of draft-ietf-simple-msrp-sessmatch > > In-line. > > On Tue, Jun 29, 2010 at 8:41 AM, Christer Holmberg > <christer.holmberg@xxxxxxxxxxxx> 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@xxxxxxx> > >> 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@xxxxxxxx > >> > https://www.ietf.org/mailman/listinfo/ietf > >> > > >> > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf