Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch

[Gonzalo Camarillo <[e-mail]>]

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
>