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

[Sandra Murphy <[e-mail]>]

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
>