Both of them -- Adrian
On Oct 14, 2010, at 17:58, Ben Campbell <b...@estacado.net> wrote: > Hi Adrian, > > Are you referring to the COMEDIA support in msrp-acm, the session matching > change in msrp-sessmatch, or both? > > Thanks! > > Ben. > > On Oct 14, 2010, at 5:26 PM, Adrian Georgescu wrote: > >> 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 >>> >> >> _______________________________________________ >> Simple mailing list >> sim...@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > 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
