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

From: Ted Hardie <[email-masked]>
Date: Wed, 1 Sep 2010 09:53:00 -0700

Hi Christer,

Thanks for your message and your consideration of the points I raised.
 Given the
scope of changes below, my first suggestion is that the author team actually
go ahead with a draft incorporating these changes, so that we can discuss
based on the actual text.  I also suspect that a second last call will
be necessary as
a result.

Some further discussion in-line.

On Tue, Aug 31, 2010 at 10:39 AM, Christer Holmberg
<[email-masked]> 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.
>

This is the key point in your message, at least from my perspective.
This basically
means that all of section 6 of RFC 4975, which clearly describes those URIs
as the session identifiers:

   URIs using the "msrp" and "msrps" schemes are used to identify a
   session of instant messages at a particular MSRP device, as well as
   to identify an MSRP relay in general.

needs to be replaced and all the logic that depends on it must be
reviewed.  The current
draft does not indicate that section 6 is being normatively updated,
and yet this is the
key point of the work.  You are moving from a namespace-scoped identifier to an
unscoped identifier, and you will require both justifications of that
(some given below)
and mechanics for that described in more detail.  In particular, I do
not believe it
is clear in the discussion so far whether the identifier may ever be
scoped by the authority section
of the URI or whether it is always treated as unscoped.  If the
latter, it is unclear to me
whether the right notion here isn't simply to create a new non-URI identifier.

> 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.
>

Please clarify in what contexts MSRP URI matching would then occur.

>>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 do not believe the document describes this scenario.  In particular,
the document
should discuss what happens when an MSRP implementation that believes it should
use MSRP URI matching interacts with an implementation that is using
this matching.

Frankly, I think this supports the idea of using a straight
token-based identifier, rather
than a portion of the URI.  The scope for confusion is much smaller.

>>>>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.
>

I still believe that this requires special-casing the MSRP URI
handling in any libraries
that are meant to parse and match URIs.  There is always a cost and risk to that
kind of special-casing, and I remain less than convinced that using a
URI here if
you are not using URI matching makes much sense.

> 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.
>

Thanks again for the clarifications,

Ted

> Regards,
> Christer

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 1 Sep 2010 15:29:07 -0700

Do these changes allow an SBC on the signaling path to change the contents of the MSRP messages without the end points being able to detect that? I'm sure it will be easier to answer this once we have a new draft. 

On Sep 1, 2010, at 9:53 , Ted Hardie wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Sep 2010 15:20:56 +0200

Hi Ted,

Comments inline.

>Given the scope of changes below, my first suggestion is that the author team actually
>based on the actual text.  I also suspect that a second last call will be necessary as
>a result.

Yes, we intend to do that.

>This basically means that all of section 6 of RFC 4975, which clearly describes those URIs
>needs to be replaced and all the logic that depends on it must be reviewed.  The current
>and yet this is the key point of the work.  You are moving from a namespace-scoped identifier to an
>unscoped identifier, and you will require both justifications of that (some given below)
>and mechanics for that described in more detail.

Section 6 does also say:

"The session-id part identifies a particular session of the participant."

...and:

"The authority component will typically not contain a userinfo
component, but MAY do so to indicate a user account for which the
session is valid.  Note that this is not the same thing as identifying the session itself."

So, I guess some additional text regarding the userinfo component might be needed. We'll look into it.

>In particular, I do not believe it is clear in the discussion so far whether the identifier may ever be scoped by the authority section
>of the URI or whether it is always treated as unscoped.  If the latter, it is unclear to me

Well, that would not be backward comaptible, would it? As we said, as long as there are no SBCs in the path, sessmatch is fully backward compatible with RFC 4975.

Of course, we could define a new MSRP message element, but wouldn't we then also need an option-tag in order to require the remote endpoint to support it?

>Please clarify in what contexts MSRP URI matching would then occur.

I am not sure whether it actually would occur :) We'll look into that.

However, in any case I think it always good to specify the matching rules for the scheme, in case it will be needed at some point.

>I do not believe the document describes this scenario.  In particular, the document

We'll put together some text about that.

>Frankly, I think this supports the idea of using a straight token-based identifier, rather

I am not arguing against that.. But, again, backward compability.

>I still believe that this requires special-casing the MSRP URI handling in any libraries
>kind of special-casing, and I remain less than convinced that using a URI here if

Backward compability...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Sep 2010 15:37:13 +0200

Hi Cullen,

>Do these changes allow an SBC on the signaling path to change the contents of the MSRP messages 
>without the end points being able to detect that? I'm sure it will be easier to answer this once we have 
>a new draft.

Sessmatch does not make it any easier for an SBC in the signalling path to change the content of the MSRP messages. 

For an SBC to do MSRP message modification it will have to implement MSRP B2BUA functionality - no matter if sessmatch is supported by the endpionts or not.

Regards,

Christer

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 03 Sep 2010 10:03:34 +0300

Hi Ted,

> based on the actual text.  I also suspect that a second last call will

the plan is to give the authors some time to discuss with all of you who
sent comments on the draft so that the authors understand how to address
them. Depending on the nature of the changes needed, we may need to IETF
LC it again (as you suggest above) or even let the WG have an additional
look at it.

But for now, thanks for following this up.

Cheers,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Sep 2010 09:13:18 +0200

Hi,

I think Ben gave my clarification :)

Regards,

Christer

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]] 
> Sent: 9. syyskuuta 2010 1:15
> To: Christer Holmberg; Cullen Jennings
> Cc: [email-masked]; Ted 
> Hardie; IESG IESG; The IETF; [email-masked]
> Subject: Re: secdir review of draft-ietf-simple-msrp-sessmatch
> 
> (as individual)
> 
> On Sep 2, 2010, at 8:37 AM, Christer Holmberg wrote:
> 
> > Hi Cullen,
> > 
> >> Do these changes allow an SBC on the signaling path to change the 
> >> contents of the MSRP messages without the end points being able to 
> >> detect that? I'm sure it will be easier to answer this 
> once we have a new draft.
> > 
> > Sessmatch does not make it any easier for an SBC in the 
> signalling path to change the content of the MSRP messages. 
> > 
> > For an SBC to do MSRP message modification it will have to 
> implement MSRP B2BUA functionality - no matter if sessmatch 
> is supported by the endpionts or not.
> 
> I'm going to have to push on this one a little bit:
> 
> I think it _does_ make it easier for an SBC to change MSRP 
> messages because it makes it easier for the SBC to put itself 
> into the media path in the first place. This is no different 
> than for any other sort of media.
> 
> The need to implement MSRP b2bUA functionality exists if the 
> SBC changes the To-Path and From-Path headers. It may or may 
> not be required if it wants to change _bodies_, depending on 
> whether that change requires chunk-reassembly or changes the 
> length of the body. And assuming, of course, there is no 
> end-to-end protection on the MSRP messages in the first 
> place--and we all know that in practice there probably won't be.
> 
> I think what Christer is talking about is, if sessmatch did 
> not exist, then if an SBC were to insert itself into the MSRP 
> media path, it would be _forced_ then to rewrite the To-Path 
> and From-Path in each MSRP request to match the change it 
> made in the SDP. If it did not do so, the endpoints would 
> detect the change and treat it as an error. That is, 
> sessmatch does not enable the insertion in the first 
> place--it just makes things cheaper from a processing perspective.
> 
> Note that any end-to-end integrity protection on the SDP, 
> such as RFC4474 or s/mime, will prevent SBC insertion, with 
> or without sessmatch. Just like for any other media.
> 
> 
> > 
> > Regards,
> > 
> > Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 8 Sep 2010 16:36:48 -0500

I wanted to make a quick response to one part of this discussion--see below:

> order to perform MSRP session matching.

In fact, RFC4975 does require an MSRP URI in and SDP offer or answer to include a session ID part. Unfortunately, it does so rather obliquely.

Section 6 contains the following language:

>    to a particular session at that device.  

Section 8.2, in the last paragraph, says the following about the rightmost URI placed in a path attribute in the SDP (Note that 4975 does not specify MSRP relay behavior, so only the rightmost URI is in scope)

> It MUST be assigned for this particular session, and MUST NOT duplicate
>    any URI in use for any other session in which the endpoint is
>    currently participating.  It SHOULD be hard to guess, and protected
>    from eavesdroppers.  This is discussed in more detail in 
> Section 14.
> 

This, taken together, create a requirement for a session-ID for MSRP URIs used to identify a session in the SDP. I agree this should have been more strongly worded. An errata entry is probably in order. 

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 8 Sep 2010 17:15:05 -0500

(as individual)

I think it _does_ make it easier for an SBC to change MSRP messages because it makes it easier for the SBC to put itself into the media path in the first place. This is no different than for any other sort of media.

The need to implement MSRP b2bUA functionality exists if the SBC changes the To-Path and From-Path headers. It may or may not be required if it wants to change _bodies_, depending on whether that change requires chunk-reassembly or changes the length of the body. And assuming, of course, there is no end-to-end protection on the MSRP messages in the first place--and we all know that in practice there probably won't be.

I think what Christer is talking about is, if sessmatch did not exist, then if an SBC were to insert itself into the MSRP media path, it would be _forced_ then to rewrite the To-Path and From-Path in each MSRP request to match the change it made in the SDP. If it did not do so, the endpoints would detect the change and treat it as an error. That is, sessmatch does not enable the insertion in the first place--it just makes things cheaper from a processing perspective.

Note that any end-to-end integrity protection on the SDP, such as RFC4474 or s/mime, will prevent SBC insertion, with or without sessmatch. Just like for any other media.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Sep 2010 11:26:18 +0200

Hi,

Based on the secdir comments/discussions regarding sessmatch, we have submitted a new version of the draft (-07).

The major changes are:

-	It is clarified that the MSRP URI comparison rules are not changed, and that the rules are not used for session matching
-	It is clarified that the draft does not change the TLS authentication mechanisms, and that there are some existing usage restrictions that the draft does not solve.

Regards,

Christer