[As SIMPLE co-chair] draft-ietf-simple-msrp-sessmatch has some significant additions from the version for which we originally requested publication. I implore everyone who cares one way or another about this draft to re-review it as soon as they are able.
Thanks! Ben. On Oct 15, 2010, at 5:07 AM, Gonzalo Camarillo wrote: > Hi, > > I am going to send this draft back to the SIMPLE WG so that they discuss > these issues. Once the WG reaches (rough) consensus on what to do, I > will be issuing a second IETF LC so that everybody is on the same page. > > Cheers, > > Gonzalo > > On 14/10/2010 11:27 PM, Cullen Jennings wrote: >> >> The new draft is clearer but I still don't think it addresses my concerns. I >> would say at this point they could be summarized as >> >> 1) The draft is very hard to review without doing the diffs to 4975. To try >> and help instead of just complain, I'm willing to go back patch these >> changes into the last XML for 4975 and provide a draft that we can actually >> read to see what this all means. I can't do that till after the -01 deadline. >> >> 2) As far as I can tell, this does change the security of 4975 in a pretty >> significant way in that this allows a MITM to masquerade with the wrong to >> and from path that may be in the cert. It is not clear how it work when the >> end points are not using self signed certs and changes the preferred >> deployment mode from using certs rooted in a trust anchor to self signed. >> All this seems to significantly weaken the security of 4975 which concerns >> me and I have not seen relevant discussion of all this. I am open to the >> idea that it does not making this much worse than they currently are in 4975 >> and that it is a reasonable trade off but I'd like to see concrete >> discussion of the issues and tradeoffs. How bad is it? how much worse is it? >> People says it is no worse but I and several others remain unconvinced that >> it is the same as 4975. I'd rather see a very explicitly discussion with >> people like the security reviewer about how much this changes things and if >> it is acceptable. It's n > ot easy to sort this all out - it actually might be acceptable - I'm just not > convinced yet and the "there is no problem because there is not change" form > of argument is not convincing me - clearly there is a a change and at causal > glance the point of that change seems to be to insert a MITM. >> >> 3) The backwards comparability issue seems huge. Some people have said an >> endpoint using this draft will not talk with one that only does 4975. Yet if >> this draft if published as an RFC would basically depreciate the 4975 and >> replace it with a the result of applying this diff to 4795. So if one person >> implements the pre update version, and another person the post - it's not >> clear to me how we migrate from old to new on the existing deployments. A >> flag day is obviously not going to work. The more I look at this, the more I >> think this draft needs to be recast as a backwards compatible extension to >> 4975 and not a draft that update 4975. When I look at how this changes 4975 >> it seems to mostly relax the existing security but not disallow things that >> used to work so I think it should be possible to do this. On a side note, I >> phoned a few people who I know that have MSRP implementation and none of >> them had any plans to implement this and were surprised to hear there was a >> draft t > hat would update in 4975 with a change like this. To me this combined with > the no backwards compatibility issue argues strongly for figuring out how to > make this an extension instead of a change to MSRP. >> >> 4) When I search the email lists, I find more more people who see >> significant problems with this than I find people that seem to think it is >> OK. I don't think it has consensus -I think it just has people who stopped >> care. The changes that needed to happen in IETF LC to fix this draft so it >> had any chance of working at all more or less convinced me the WG did not >> read this draft. The ietf@ietf.org list is not an ideal location for >> discussion that rewrites pretty much all of the normative text of this draft >> (which is what is happening here). >> >> Cullen >> >> >> >> On Oct 5, 2010, at 1:33 AM, Gonzalo Camarillo wrote: >> >>> Hi, >>> >>> Christer has submitted a new revision of this draft: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-sessmatch/ >>> >>> Those of you who sent IETF LC comments on this draft, could you please >>> have a look at the new version and let Christer know if he has addressed >>> your concerns? >>> >>> Thanks, >>> >>> Gonzalo >>> >>> >>> On 31/08/2010 8:39 PM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> The purpose of this e-mail is to address the secdir comments given by >>>> Richard >>>> Barnes and Ted Hardie. Due to summer vacations, standardization meetings >>>> etc it took a while to put the e-mail together, and we appologise for that. >>>> >>>> GENERAL >>>> ======= >>>> >>>> First, the draft does NOT propose any changes to the TLS authentication >>>> procedures – that will be clarified. The changes are only related to the >>>> procedure for matching an incoming MSRP message to an MSRP session that >>>> has been negotiated using SDP – once any TLS authentication procedure has >>>> already taken place. >>>> >>>> So, in case of TLS and name based authentication, if an SBC/ALG modifies >>>> the a=path MSRP URI, the TLS authentication WILL fail. That is the current >>>> behavior, and sessmatch doesn’t change that. >>>> >>>> We understand that this fact needs to be clearly indicated in the draft. >>>> >>>> Basically sessmatch allows so that, when using peer to peer MSRP, SIP SBCs >>>> and SIP aware firewalls can be in the SIP signaling path without acting as >>>> MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP relays >>>> the SBC/ALG needs to act as MSRP B2BUA, as today. >>>> >>>> Sessmatch aims to extend the usability of MSRP peer to peer communication >>>> to >>>> scenarios where simple ALGs/SBCs are used, and at least in our experience >>>> customer interest for standard MSRP has grown (from more or less zero) >>>> dramatically due to sessmatch. And, OMA, which previously used a >>>> *non-standard* >>>> version of MSRP (with no interoperability with standard MSRP), has also >>>> agreed >>>> to switch to sessmatch (even if it required a number of changes in their >>>> specifications). >>>> >>>> Second, the intention of sessmatch is not to modify the MSRP URI matching >>>> rules, >>>> but rather to not use MSRP URI matching for session matching. >>>> >>>> Please also note that when we talk about SBCs/ALGs, we refer to entities >>>> that >>>> normally do NOT have the capability to act as MSRP B2BUAs. >>>> >>>> We will comment the individual comments based on the assumptions above. >>>> >>>> >>>> Comments from Richard >>>> ===================== >>>> >>>>> 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. >>>> >>>> When an MSRP UA receives an MSRP packet it performs msrp session matching >>>> in order >>>> to verify that the msrp packet belongs to an existing SDP negotiated msrp >>>> session >>>> at the UA. RFC4975 prescribes that URI matching should be used for session >>>> matching. >>>> We argue that the namespace scoping of the session-id values that use of >>>> URI matching >>>> brings is unnecessary. The 80-bit randomness of the session-id and the >>>> fact that it >>>> was the UA itself that decided on the session-id value and can ensure that >>>> it is >>>> unique within the UA makes the session-id sufficiently unique for session >>>> matching. >>>> Sessmatch is not changing the MSRP URI matching algorithm, it is changing >>>> the session >>>> matching algorithm not to use MSRP URI matching. >>>> >>>>> I have a few significant reservations about this document: >>>>> >>>>> 1) 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. >>>> >>>> If we do not introduce the sessmatch change then the only alternative for >>>> MSRP >>>> connections to be able to be set up when SBCs or SIP aware firewalls are >>>> in the >>>> SIP signaling path is for these to introduce MSRP B2BUA support. This is >>>> probably >>>> not feasible for most SBCs and SIP aware firewalls, and if it actually were >>>> feasible then it would mean as big a security problem, or even bigger, than >>>> sessmatch. The choice is thus to not use MSRP at all in presence of such >>>> devices >>>> or to introduce sessmatch. Not to fix this probably would mean that use of >>>> MSRP >>>> will be marginalized. >>>> >>>>> 2) 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. >>>> >>>> We cannot find the terminology “name-based” authentication in RFC 4975. >>>> The RFC talks >>>> about TLS authentication using either certificates from well-known >>>> certificate >>>> authorities, or using self-signed certificates together with certificate >>>> fingerprints. >>>> >>>> Having said that, however, we DO agree that the terminology you suggest is >>>> more >>>> appropriate than what we have used and we will introduce this terminology >>>> and explain >>>> it in the Convention section of the sessmatch draft. >>>> >>>>> -- 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. >>>> >>>> A media intermediary can only do this if it is an MSRP B2BUA, and >>>> sessmatch was >>>> introduced just to avoid most SBCs and ALGs having to implement an MSRP >>>> B2BUA in order >>>> to allow standard MSRP deployment. >>>> >>>>> -- There is currently no requirement that an 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. >>>> >>>> We will explicitly mention this. >>>> >>>>> 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. >>>> >>>> That is correct, but there should be no problem for a single MSRP process >>>> (single >>>> IP address and port) to direct requests to different virtual recipients - >>>> based >>>> on the session-id instead. It is only needed for the different virtual >>>> recipients >>>> to inform the receiver process on which session-ids that are currently >>>> negotiated >>>> instead of informing it on which domain name the virtual recipient shall be >>>> associated with. >>>> >>>>> 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 a >>>>> new >>>>> version of MSRP rather than an update. >>>> >>>> It is not true that there is no backwards compatibility. If there are no >>>> SIP ALGs/SBCs in the SIP/SDP signalling path then there is no problem for >>>> MSRP >>>> implementations that do not support the sessmatch extension to receive MSRP >>>> sessions from implementations that do. >>>> >>>> MSRP implementations that do not support the sessmatch extension are >>>> however not >>>> able to establish MSRP end to end conversations if there are ALGs/SBCs in >>>> the >>>> session path (unless these implement MSRP B2BUA) and sessmatch does not >>>> change this >>>> fact – it will not work disregarding if the other endpoint supports >>>> sessmatch or not. >>>> >>>>>>> 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..." >>>>> >>>>> 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. >>>> >>>> Sessmatch does not change the fact that name based TLS authentication for >>>> MSRPS >>>> will fail if an SBC or ALG has modified the hostname value in the MSRP URI >>>> in the >>>> SDP a=path attribute without also acting as MSRP B2BUA. >>>> >>>> >>>> Comments from Ted >>>> ================= >>>> >>>>> I join Richard in believing that this document makes changes beyond that >>>>> which >>>>> could be understood as "updating" the MSRP URI scheme processing. >>>>> >>>>> ... >>>>> >>>>> 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. >>>> >>>> We will clarify what impacts there are. >>>> >>>> ------- >>>> >>>>>>> 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 section >>>> >>>> We will clarify that sessmatch conformant UAs do not use MSRP URI matching >>>> in >>>> order to perform MSRP session matching. >>>> >>>>>> 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. >>>> >>>> Sessmatch removes the URI matching as a means to do MSRP session matching, >>>> and >>>> replaces it with a pure session-id matching. There is no need to create a >>>> new >>>> URI scheme that does not re-use the authority component. We believe the >>>> minimum >>>> 80-bit randomness of the session-id, together with the fact that the UA >>>> itself >>>> generates the session-id it matches on, to be enough for the session-id to >>>> be >>>> unique in the scope of the sessions that are active at the UA. >>>> >>>> Also, the security of the matching is not particularly decreased, since it >>>> is >>>> relatively easy to find out the authority name anyway. >>>> >>>>>>> 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 ). >>>> >>>> Session matching is done when receiving MSRP packets on an already >>>> established TCP >>>> or TCP/TLS connection, and there will not be any different session >>>> matching procedure >>>> depending on if the connection uses TLS or plain TCP. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >> >> > _______________________________________________ > Simple mailing list > sim...@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
