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

[Sandra Murphy <[e-mail]>]

On Mon, 26 Apr 2010, Christer Holmberg wrote:

>
> Hi Sandy,
>
>>>> 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.
>
> 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.

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


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