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

[Adam Roach <[e-mail]>]

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.

> 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