Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=windows-1252
From: Adrian Georgescu <ag@ag-projects.com>
In-Reply-To: <496424A9-378C-4B47-9BA9-0F3EA5B1E499@cisco.com>
Date: Thu, 14 Oct 2010 17:26:50 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <572332FE-BFD1-41B0-AE9E-8ECB96D2FB05@ag-projects.com>
References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se>
 <4CAAD4B0.2080807@gmail.com> <496424A9-378C-4B47-9BA9-0F3EA5B1E499@cisco.com>
To: Cullen Jennings <fluffy@cisco.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, The IETF <ietf@ietf.org>, secdir@ietf.org,
 Gonzalo Camarillo <gcamaril@gmail.com>,
 draft-ietf-simple-msrp-sessmatch@tools.ietf.org, IESG IESG <iesg@ietf.org>,
 simple@ietf.org
Subject: Re: [secdir] [Simple] secdir review of
 draft-ietf-simple-msrp-sessmatch
Precedence: list

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:

>=20
> 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=20
>=20
> 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.=20
>=20
> 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.=20=

>=20
> 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.=20
>=20
> 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).=20
>=20
> Cullen
>=20
>=20
>=20
> On Oct 5, 2010, at 1:33 AM, Gonzalo Camarillo wrote:
>=20
>> Hi,
>>=20
>> Christer has submitted a new revision of this draft:
>>=20
>> https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-sessmatch/
>>=20
>> 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?
>>=20
>> Thanks,
>>=20
>> Gonzalo
>>=20
>>=20
>> On 31/08/2010 8:39 PM, Christer Holmberg wrote:
>>> Hi,
>>>=20
>>> 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.
>>>=20
>>> GENERAL
>>> =3D=3D=3D=3D=3D=3D=3D
>>>=20
>>> First, the draft does NOT propose any changes to the TLS =
authentication
>>> procedures =96 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 =96 once any TLS authentication =
procedure has
>>> already taken place.
>>>=20
>>> So, in case of TLS and name based authentication, if an SBC/ALG =
modifies
>>> the a=3Dpath MSRP URI, the TLS authentication WILL fail. That is the =
current
>>> behavior, and sessmatch doesn=92t change that.
>>>=20
>>> We understand that this fact needs to be clearly indicated in the =
draft.
>>>=20
>>> 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.
>>>=20
>>> 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).
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> We will comment the individual comments based on the assumptions =
above.
>>>=20
>>>=20
>>> Comments from Richard
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>>> I have a few significant reservations about this document:
>>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>=20
>>> We cannot find the terminology =93name-based=94 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.
>>>=20
>>> 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.
>>>=20
>>>> -- 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.
>>>=20
>>> 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.
>>>=20
>>>> -- 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.
>>>=20
>>> We will explicitly mention this.
>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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 =96 it will not work disregarding if the other endpoint =
supports sessmatch or not.
>>>=20
>>>>>> 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.
>>>>>=20
>>>>> There are no impacts to MSRPS URIs. I assumed it would be =
implicitly
>>>>> understood since MSRPS URIs are not mentioned in the draft.
>>>>>=20
>>>>> However, we could explicitly make it clear by modifying the first
>>>>> sentences of section 5:
>>>>>=20
>>>>> "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..."
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.)
>>>>=20
>>>> So the current document does introduce a new MitM vulnerability to =
MSRPS.
>>>=20
>>> 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=3Dpath attribute without also acting as MSRP B2BUA.
>>>=20
>>>=20
>>> Comments from Ted
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>>> I join Richard in believing that this document makes changes beyond =
that which
>>>> could be understood as "updating" the MSRP URI scheme processing.
>>>>=20
>>>> ...
>>>>=20
>>>> 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.
>>>=20
>>> We will clarify what impacts there are.
>>>=20
>>> -------
>>>=20
>>>>>> 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:
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>=20
>>>> This is not indicated in the URI matching section
>>>=20
>>> We will clarify that sessmatch conformant UAs do not use MSRP URI =
matching in
>>> order to perform MSRP session matching.
>>>=20
>>>>> Section 6 of RFC 4975 says:
>>>>>=20
>>>>> "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."
>>>>>=20
>>>>=20
>>>> The full section from which that quote is taken is:
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Also, the security of the matching is not particularly decreased, =
since it is
>>> relatively easy to find out the authority name anyway.
>>>=20
>>>>>> 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.
>>>>>=20
>>>>> There are no impacts to MSRPS URIs. I assumed it would be =
implicitly understood
>>>>> since MSRPS URIs are not mentioned in the draft.
>>>>>=20
>>>>> However, we could explicitly make it clear by modifying the first =
sentences of
>>>>> section 5:
>>>>>=20
>>>>> "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..."
>>>>>=20
>>>> 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 ).
>>>=20
>>> 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.
>>>=20
>>> Regards,
>>>=20
>>> Christer
>>>=20
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>=20
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple
>=20