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

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Apr 2010 10:18:33 +0100

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?

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

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.

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?

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.

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.

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.

Nits/Typos:

10.10: s/certain level/a certain level/

Stephen.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Apr 2010 15:19:07 +0200

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

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.

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

-------

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

-------

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

Fixed it will be.

Thank You!

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Apr 2010 08:26:18 -0500

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

> etc.) should be given somewhere (maybe that's a more generic

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.

> wouldn't be ok to just say that to every UA one meets on

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

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

> that RFC or to something detailing the expected improvement is

So you want it to point back to section 9.2?

> 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

---

From: Sandra Murphy <[email-masked]>
Date: Sun, 25 Apr 2010 03:41:59 -0400 (Eastern Daylight Time)

On Tue, 20 Apr 2010, Adam Roach wrote:

> 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

> 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.
>
> This leaves a lot of wiggle room around the difference between "supports" and 
> "is willing to receive."
>
> 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.
>
> 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
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Apr 2010 14:43:31 +0200

Hi Sandy, 

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

I guess Adam can comment on the status about that.

However, I see that as a generic work, and not something that should be done in the Info-Events draft.

Section 10.10 talks about the usage of some security mechanism in order to protect the data, and I am not sure what more we could say in this draft.

Regards,

Christer

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 27 Apr 2010 16:52:36 -0400 (Eastern Daylight Time)

> However, I see that as a generic work, and not something that should be done in the Info-Events draft.

I wasn't intending to comment strictly on the info draft.  I was agreeing 
with Adam's comment that this problem was common to all of SIP.  If the 
sip wg did work or is doing work on cautionary tales about proxies in 
general, then that work could and should be noted in the info draft. 
That's the scope of impact on the info draft.

--Sandy

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Apr 2010 08:04:36 +0200

Hi Sandy, 

>>>> 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.
>>>
>>> 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.
>>
>I wasn't intending to comment strictly on the info draft.  I 
>was agreeing with Adam's comment that this problem was common 
>to all of SIP.  If the sip wg did work or is doing work on 
>cautionary tales about proxies in general, then that work 
>could and should be noted in the info draft. 

AFAIK the sipcore wg is currently not doing such work.

Regards,

Christer