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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 02 July 2010 08:04 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7A63A68C0; Fri, 2 Jul 2010 01:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.861
X-Spam-Level:
X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i11r-yHHD87b; Fri, 2 Jul 2010 01:04:38 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7048B3A6863; Fri, 2 Jul 2010 01:04:37 -0700 (PDT)
X-AuditID: c1b4fb39-b7ceaae000004c90-aa-4c2d9da02ecb
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A0.B8.19600.0AD9D2C4; Fri, 2 Jul 2010 10:04:48 +0200 (CEST)
Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.94]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 2 Jul 2010 10:04:48 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Ted Hardie <ted.ietf@gmail.com>
Date: Fri, 2 Jul 2010 10:04:46 +0200
Thread-Topic: secdir review of draft-ietf-simple-msrp-sessmatch
Thread-Index: AcsXsdZJ8x4hdxgeTiaH2eToWPAxJgBjlGdg
Message-ID: <FF84A09F50A6DC48ACB6714F4666CC7468A5546862@ESESSCMS0354.eemea.ericsson.se>
References: <5A638DC0-41CF-4C0C-B00D-6793C43FB708@bbn.com> <AANLkTikyh2zkQgfnPNgW5orxXvP5fOw7KnpW03V_XFJJ@mail.gmail.com> <FF84A09F50A6DC48ACB6714F4666CC7468A54B9BC4@ESESSCMS0354.eemea.ericsson.se> <AANLkTilx4YtoejdifMC06s46xXXp6QmIOgbT5VVzJcdE@mail.gmail.com>
In-Reply-To: <AANLkTilx4YtoejdifMC06s46xXXp6QmIOgbT5VVzJcdE@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" <draft-ietf-simple-msrp-sessmatch@tools.ietf.org>, The IETF <ietf@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jul 2010 08:04:40 -0000

Hi,

We have some ideas on how to address the issues and move forward, but due to summer vacations we will unfortunately most likely not be able reply to Ted's and Richard's e-mails before august.

Just to let you know.

Regards,

Christer








 

> -----Original Message-----
> From: Ted Hardie [mailto:ted.ietf@gmail.com] 
> Sent: 29. kesäkuuta 2010 20:37
> To: Christer Holmberg
> Cc: Richard L. Barnes; secdir@ietf.org; iesg@ietf.org; The 
> IETF; draft-ietf-simple-msrp-sessmatch@tools.ietf.org
> Subject: Re: secdir review of draft-ietf-simple-msrp-sessmatch
> 
> In-line.
> 
> On Tue, Jun 29, 2010 at 8:41 AM, Christer Holmberg 
> <christer.holmberg@ericsson.com>; wrote:
> >
> > Hi Ted,
> >
> >>I join Richard in believing that this document makes changes beyond 
> >>that which could be understood as "updating" the MSRP URI scheme 
> >>processing.
> >>
> >>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 sectio
> 
> 
> >
> > 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.
> 
> Creating a new URI scheme without re-using authority may be a 
> better approach; this would require more work, but it is 
> cleaner than this appears to be.
> 
> >
> >>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 ).
> 
> regards,
> 
> Ted
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >> On Mon, Jun 14, 2010 at 10:21 AM, Richard L. Barnes 
> <rbarnes@bbn.com>; 
> >> wrote:
> >> > 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.
> >> >
> >> > I have a few significant reservations about this document:
> >> >
> >> > 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.
> >> > 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. -- 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.
> >> > -- There is currently no requirement that a 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.
> >> > 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.
> >> >
> >> > 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 an new version of MSRP rather than
> >> an update.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Ietf mailing list
> >> > Ietf@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/ietf
> >> >
> >>
>