Re: [secdir] secdir review of draft-ietf-sipcore-info-events

Sandra Murphy <sandra.murphy@sparta.com> Sun, 25 April 2010 07:48 UTC

Return-Path: <Sandra.Murphy@cobham.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 91BFC3A6850 for <secdir@core3.amsl.com>; Sun, 25 Apr 2010 00:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.032
X-Spam-Level:
X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_50=0.001]
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 IQqq5qywKNwE for <secdir@core3.amsl.com>; Sun, 25 Apr 2010 00:48:22 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id DF0743A684C for <secdir@ietf.org>; Sun, 25 Apr 2010 00:48:21 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3P7m4Cq029429; Sun, 25 Apr 2010 02:48:05 -0500
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o3P7m3cX025718; Sun, 25 Apr 2010 02:48:03 -0500
Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Apr 2010 03:42:00 -0400
Date: Sun, 25 Apr 2010 03:41:59 -0400 (Eastern Daylight Time)
From: Sandra Murphy <sandra.murphy@sparta.com>
To: Adam Roach <adam@nostrum.com>
In-Reply-To: <4BCDAB7A.7080208@nostrum.com>
Message-ID: <Pine.WNT.4.64.1004250334040.3436@SMURPHY-LT.columbia.ads.sparta.com>
References: <4BCD7169.9020701@cs.tcd.ie> <4BCDAB7A.7080208@nostrum.com>
X-X-Sender: sandy@nemo.columbia.sparta.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-OriginalArrivalTime: 25 Apr 2010 07:42:00.0374 (UTC) FILETIME=[CA26E560:01CAE44A]
Cc: secdir@ietf.org, draft-ietf-sipcore-info-events@tools.ietf.org, sipcore-chairs@tools.ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-sipcore-info-events
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: Sun, 25 Apr 2010 07:48:23 -0000

On Tue, 20 Apr 2010, Adam Roach wrote:

> On 4/20/10 04:18, Apr 20, Stephen Farrell wrote:
>> Hi,
>> 
>> (Sorry for the tardy review;-)
>> 
>> This specification sort-of provides a SIP-based tunnel
>> for application protocols.
>> 
>> 1: What prevents (or allows detection of) insertion of
>> bogus Info Package specifications? (e.g. by a proxy). If
>> nothing, then why is this ok?
>> 
>
> This is the general way that SIP works, and it applies to all the SIP header 
> fields. It's not great, but proxies are implicitly trusted to do the right 
> thing. If it's a problem for INFO, then it's a problem for everything that 
> has ever used or will ever use SIP.

Aye, and therein lies the rub.  ;-}

In my usual broken-record nagging, insider failures are hard to protect 
against, sometimes impossible.  But knowing just how bad things might get 
(how much damage an insider failure could potentially cause) might be a 
good idea.  It might inspire people to put strong operational controls in 
place.  Buy a bigger liability policy.  Abandon all hope ye who enter 
here.  etc.

When I made some similar comments on a different SIP draft a while back, 
there was a discussion on the sip wg list of writing down somewhere what 
the wg chair called the "please molest me" security model.  I didn't 
follow the discussion to the end, so I don't know if that ever got past 
the good intention stage and if so where the written down text ended up.

--Sandy


>
>> 2: I don't know how prevalent implementations of this are,
>> or will be, but since this calls for the user agents to
>> include a MIME parser plus parsers for whatever MIME types
>> the user agent claims to support, I'd say some guideance
>> about defensive programming (e.g. avoiding buffer overruns
>> etc.) should be given somewhere (maybe that's a more generic
>> SIP thing though).
>> 
>
> I would think that's also a general comment about the way that SIP works. 
> Such guidance would seem out of place squirreled away in a document that is 
> otherwise simply defining a new method. In fact, I would argue that it should 
> be attached to a MIME-related document, not a SIP-related one.
>
>> 3. 4.2.2. says that a UA MUST indicate which Info packages it
>> supports.  That seems a bit open-kimono - why MUST all UAs tell
>> everyone everything they support all the time? Won't that
>> expose more attack surface than is wise? Wouldn't it be better
>> to first know who the other UA is, before telling them everything
>> every time? For example, imagine a UA supported the "US Govt
>> SECRET foobar application Info Package," I'm guessing that it
>> wouldn't be ok to just say that to every UA one meets on
>> the Internet.
>> 
>
> I think that's a somewhat tortured reading of that text. The actual text is:
>
>   A UA which supports the Info Package mechanism MUST indicate, using
>   the Recv-Info header field, the set of Info Packages for which it is
>   willing to receive INFO requests.
>
>
> This leaves a lot of wiggle room around the difference between "supports" and 
> "is willing to receive."
>
>> 4. 10.10 says that if TLS is not good enough, then use S/MIME.
>> My understanding is that no UAs implement S/MIME (or CMS really)
>> and no networks support its use. So shouldn't that really say
>> "if TLS is not good enough, then just don't do it or require
>> the application to do its own security"? Same point applies to
>> section 13. I would think that securing specific applications
>> would be easier and more likely than getting S/MIME used in UAs,
>> so why not recommend that?
>> 
>
> The difficulties with getting S/MIME deployed in SIP, I think, stem from the 
> lack of a viable PKI. With the publication of draft-ietf-sip-certs-12 as an 
> RFC -- which I anticipate happening soon -- I have renewed hope that S/MIME 
> may se some deployment yet.
>
>> 5. 1st para of section 13 says that this will be an improvement
>> over RFC2976. I would think a reference to the problems with
>> that RFC or to something detailing the expected improvement is
>> warranted.
>> 
>
> So you want it to point back to section 9.2?
>
>> Non security notes:
>> 
>> s1, 2nd para: how can you prevent INFO being used to update the
>> state of a "SIP dialog or session"? Seems like it'd be more
>> accurate to say that that's the intent but that there really are
>> no guarantees. The example given in the abstract of RFC2976 seems
>> in fact to be directly related to signalling so that's confusing.
>> 
>
> SIP dialog and session state is a very specific set of information described 
> in RFC 3261. It relates to things like the route a message takes through the 
> SIP network, certain endpoint identifiers, and whether the dialog itself is 
> active or terminated. It is a very specific term of art that is generally 
> known to SIP implementors.
>
> /a
>