My two cents. Having implemented both models in Blink client (Blink is a free download if someone cares and wants to experiment with both MSRP models), I can comment that I do not like the acm model. The relay model is simply better, cleaner and more secure.
Adrian On Oct 14, 2010, at 3: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 not 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 > that 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
