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

[Paul Kyzivat <[e-mail]>]

Juergen,

Thank you for your careful review. (This has been a long slog for everyone.)

I'm sorry to be tardy in responding to you.
I started to prepare a response in a timely way and then got side 
tracked. :-(

Responses inline.

On 4/22/2011 7:45 AM, Juergen Schoenwaelder wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> I reviewed earlier versions of this I-D in Feburary 2009 and in
> December 2010. This revision has more explicit text in the security
> considerations, which essentially states that the clarifications on
> offer/answer exchanges do not add any new security issues. It took me
> some time to parse the sentences, perhaps a simpler wording could have
> been used (e.g. s/exclude from use/exclude). I appreciate the more
> explicit text and the concrete pointers to the relevant RFCs.

The wording was done carefully in order to get the intended level of 
precision. I agree that your suggested substitution ( s/exclude from 
use/exclude ) would be fine.

If you wish I can make that change.

> 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

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

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.

	Thanks,
	Paul