[secdir] secdir review of draft-ietf-sipping-sip-offeranswer-10.txt

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 02 February 2009 16:19 UTC

Return-Path: <secdir-bounces@ietf.org>
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFAFB3A6BA7; Mon, 2 Feb 2009 08:19:51 -0800 (PST)
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A23C3A6B28; Mon, 2 Feb 2009 08:19:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.18
X-Spam-Level:
X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqTNdacHwfdE; Mon, 2 Feb 2009 08:19:44 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 63A5D3A6828; Mon, 2 Feb 2009 08:19:44 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24D76C0004; Mon, 2 Feb 2009 17:19:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TNtpxIZubPDi; Mon, 2 Feb 2009 17:19:19 +0100 (CET)
Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9511C000B; Mon, 2 Feb 2009 17:19:18 +0100 (CET)
Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id 6C0E395B9D0; Mon, 2 Feb 2009 17:19:17 +0100 (CET)
Date: Mon, 02 Feb 2009 17:19:17 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Takuya Sawada <tu-sawada@kddi.com>, "Paul H. Kyzivat" <pkyzivat@cisco.com>
Message-ID: <20090202161917.GA25638@elstar.iuhb02.iu-bremen.de>
Mail-Followup-To: Takuya Sawada <tu-sawada@kddi.com>, "Paul H. Kyzivat" <pkyzivat@cisco.com>, iesg@ietf.org, secdir@ietf.org, sipping-chairs@tools.ietf.org
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.19 (2009-01-05)
Cc: iesg@ietf.org, sipping-chairs@tools.ietf.org, secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-sipping-sip-offeranswer-10.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: j.schoenwaelder@jacobs-university.de
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

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.

The goal of the document is to document the offer/answer exchanges
used in the SIP framework to establish and update multimedia sessions.
This informational document does not define new protocol exchanges;
its goal is to clarify what can be found in various RFCs. The text in
the security considerations says:

   There are not any security issues beyond the referenced RFCs.

While this might be true, I would have preferred to have a somewhat
more explicit discussion and more precise pointers which parts of the
security considerations in the "referenced RFCs" (really all?) apply.
The document describes some offer/answer interactions where the
correct behaviour is not clear and it would be good to spell out
whether any of the described offer/answer scenarios can be exploited.
If not, having a statement that they can't be exploited and why would
be nice to have. (For example, spell out whether SIP integrity
protection and authentication are sufficient to mitigate any possible
attacks.)

Editorial:

- It would be nice for readers who are not too deeply involved with
  SIP if all acronyms (UAC, UAS, 3ppc, ...) are expanded on first
  usage.

/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/>
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir