Re: [secdir] secdir review of draft-ietf-sipping-sip-offeranswer-14.txt

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Apr 27, 2011 at 08:19:09PM -0400, Paul Kyzivat wrote:

> >However, these references raise a procedural question. It seems all
> >these relevant specifications are on the standards track while this
> >clarification, which tries to handle situations that can lead to
> >"failed or degraded calls", is submitted as an Informational document.
> >Should this not be standards track, formerly updating the relevant
> >RFCs? I see in the IESG writeup that this has been discussed before,
> >the proposed move to publish this as Informational still sounds
> >surprising to me as an outsider. If there is consensus to resolve the
> >ambiguities as described in the document, then why not via a
> >standards-track action?  Or is the idea that this resolution simply
> >can be ignored or that something very different might be invented?
> >That latter would more speak for Experimental then.
> 
> We have been around this track several times. We decided this
> approach was the most appropriate one for these issues. The
> following message is part of one of the more recent threads on the
> topic.
> 
> http://www.ietf.org/mail-archive/web/rai/current/msg00833.html

I followed the URL but all I could see was that this question was
raised and discussed before. I still miss the convincing argument why
this should be Informational and not standards-track or Experimental.
Perhaps you have another pointer where this becomes clear?
 
> >Getting back to security considerations, if the intention is not to
> >require implementations to follow the disambiguation described in the
> >document (that is not moving to standards-track), can malware exploit
> >the fact that the underlying RFCs allow for ambiguities to cause
> >"failed or degraded calls"?
> 
> The participants in the SIP offer/answer exchange presumably *want*
> the exchange to succeed. If not, there are a multitude of things
> they can do to make the call fail or degrade.

This sounds a bit like "a not well behaving client has other ways to
cause damage, so we do not have to worry much about this way to cause
damage", which I find not a very convincing approach. Anyway, I am
probably a bit picky here since this document is intended to be
informational, so any standards compliant implementation can ignore
this specification and hence use standards track compliant mechanisms
to cause failed or degraded calls.

> SIP already provides mechanisms to protect the offer/answer exchange
> from tampering by 3rd parties. For instance:
> 
>   Enhancements for Authenticated Identity Management
>   in the Session Initiation Protocol (SIP)
>   http://tools.ietf.org/html/rfc4474
> 
>   Section 26.3.2 Security Solutions of RFC 3261
>   http://datatracker.ietf.org/doc/rfc3261/
> 
> If the participants choose to ignore those mechanisms, then again
> there are many things that a third party can do to degrade the call.

Then this should probably be mentioned in the Security Considerations.
Right now, there is no reference to RFC 4474 at all. So if that one is
relevant to prevent tampering by 3rd parties, I would rather have this
spelled out and a reference included.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>