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

Sandra Murphy <> Sun, 25 April 2010 07:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91BFC3A6850 for <>; Sun, 25 Apr 2010 00:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.032
X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IQqq5qywKNwE for <>; Sun, 25 Apr 2010 00:48:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DF0743A684C for <>; Sun, 25 Apr 2010 00:48:21 -0700 (PDT)
Received: from ( []) by (8.13.5/8.13.5) with ESMTP id o3P7m4Cq029429; Sun, 25 Apr 2010 02:48:05 -0500
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id o3P7m3cX025718; Sun, 25 Apr 2010 02:48:03 -0500
Received: from ([]) by 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
From: Sandra Murphy <>
To: Adam Roach <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
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]
Subject: Re: [secdir] secdir review of draft-ietf-sipcore-info-events
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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