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

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Apr 2011 13:45:17 +0200

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.

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.

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

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Apr 2011 13:40:38 +0200

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Apr 2011 20:19:09 -0400

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.

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

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

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

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