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

Paul Kyzivat <> Thu, 28 April 2011 00:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E234E084D; Wed, 27 Apr 2011 17:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.472
X-Spam-Status: No, score=-110.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qaot6EuCVr0n; Wed, 27 Apr 2011 17:19:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0C796E0691; Wed, 27 Apr 2011 17:19:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3461; q=dns/txt; s=iport; t=1303949950; x=1305159550; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Z/U/8KCYtMDyUzSTCAQpmlZN0MC8bNsqoXrFrvP2HAQ=; b=jYc/qyrh2ppnIoJbaYzFb8zEYBlN3P5m1oRA8wVAW7ECJyx3LIJN6Yj+ 085OKEppq+18qCSk91LJam1SQrVaBqqo9R24zXulaJnsZV63Nonb7eyh4 XjUHF2ue0aAInR5g9+VBr2YsrPFMFg/ZVvAK80tuB6jeQqGyR8dyQNW64 M=;
X-IronPort-AV: E=Sophos;i="4.64,277,1301875200"; d="scan'208";a="437767992"
Received: from ([]) by with ESMTP; 28 Apr 2011 00:19:10 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p3S0J9ht024964; Thu, 28 Apr 2011 00:19:09 GMT
Message-ID: <>
Date: Wed, 27 Apr 2011 20:19:09 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
References: <20110422114517.GA2512@elstar.local>
In-Reply-To: <20110422114517.GA2512@elstar.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 29 Apr 2011 03:03:00 -0700
Subject: Re: [secdir] secdir review of draft-ietf-sipping-sip-offeranswer-14.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Apr 2011 00:19:11 -0000


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.

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

   Section 26.3.2 Security Solutions of RFC 3261

If the participants choose to ignore those mechanisms, then again there 
are many things that a third party can do to degrade the call.