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

[Christer Holmberg <[e-mail]>]

Hi Stephen, 

Thanks for your review! Comments inline.

-------

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

Unless you somehow secure your SIP signalling, evil proxies can insert/modify/remove more or less whatever information elements in the messages. It's not specific to INFO.

-------

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

It is not necessarily the SIP stack of the user agent itself that needs to include the parser, but the application using the Info Package.

Also, I belive you would have the same issue for event packages.

Having said that, the trend today seem to be using XML, so probably there will not be a need for too many parsers.

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

The intention is to say that a UA MUST indicate which Info Packages it is willing to support for a specific session.

So, maybe something like:

"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 for a specific session."

-------

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

I don't think 10.10 says "then use S/MIME". It only says that one way to achieve end-to-end application security is to use S/MIME. Section 13 doesn't mention S/MIME.

And, the text DOES say that the Info Package specification needs to specify what kind of security is required.

-------

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

I guess a reference to section 9.2 could be added:

"By eliminating multiple usages of INFO messages without adequate
community review and by eliminating the possibility for rogue SIP UAs
from confusing another UA by purposely sending unrelated INFO
requests, as described in section 9.2, we expect this document's 
clarification of the use of INFO to improve the security of the Internet."

-------

>6. How and why would one "filter for approved Info Packages" 
>as stated in section 13? It seems like that single sentence 
>is either too much or too little, so maybe delete it or 
>expand upon it, so that an implementer might know what's 
>reasonable filtering.

Maybe the text could be modified to:

"Whilst rogue UAs can still send unrelated INFO requests, this mechanism provides mechanisms for
which the UAS and other security devices can associate INFO requests with Info Packages that have
been negotiated for a session."

-------

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

The purpose of the expert review is to ensure that an Info Package does not update the state.

Of course, an application that receives an Info Package may trigger actions that updates the session state.

-------

>Nits/Typos:
> 
>10.10: s/certain level/a certain level/

Fixed it will be.

Thank You!

Regards,

Christer