[secdir] review of draft-ietf-sipcore-reinvite-06.txt

Stephen Kent <kent@bbn.com> Thu, 21 October 2010 02:16 UTC

Return-Path: <kent@bbn.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id CA2483A68E3 for <secdir@core3.amsl.com>; Wed, 20 Oct 2010 19:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.46
X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id t9CPab3kB1+P for <secdir@core3.amsl.com>; Wed, 20 Oct 2010 19:16:13 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com []) by core3.amsl.com (Postfix) with ESMTP id 416DE3A6925 for <secdir@ietf.org>; Wed, 20 Oct 2010 19:16:13 -0700 (PDT)
Received: from dommiel.bbn.com ([]:36733 helo=[]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1P8kiv-000JYC-Rj; Wed, 20 Oct 2010 22:17:47 -0400
Mime-Version: 1.0
Message-Id: <p06240800c8e55027a17b@[]>
Date: Wed, 20 Oct 2010 22:17:29 -0400
To: secdir@ietf.org
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: gao.yang2@zte.com.cn, pkyzivat@cisco.com, Christer.Holmberg@ericsson.com, Gonzalo.Camarillo@ericsson.com, tim.polk@nist.gov, rjsparks@nostrum.com
Subject: [secdir] review of draft-ietf-sipcore-reinvite-06.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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/mail-archive/web/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>
X-List-Received-Date: Thu, 21 Oct 2010 02:16:17 -0000

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

This document (draft-ietf-sipcore-reinvite-06.txt) provides 
clarification on how to process a re-invite in SIP. The notion of a 
re-invite is defined in RFC 3261 (SIP). This document was created to 
clarify the description provided in 3261, based on feedback from 
implementers. It includes a number of examples designed to clarify. 
It is fair to say that this document not only offers clarifications, 
but also makes some changes to SIP handling of re-INVITEs. For 
example, the document notes that "Section 4.3 specifies new rules for 
the handling of target-refresh requests."

The document makes reference to "properly" authenticated requests in 
a couple of places (4.4 & 4.6), but provides no indication of what 
constitutes proper authentication. I think it would be appropriate to 
include references to whatever SIP security mechanisms are currently 
recommended for message/session authentication (as opposed to what 
3261 said 8 years ago).

The document has a trivial Security Considerations section:

    This document does not introduce any new security issue.  It just
    clarifies how certain transactions should be handled in SIP.
    Security issues related to re-INVITEs and UPDATE requests are
    discussed in RFC 3261 [RFC3261] and RFC 3311 [RFC3311].

I checked 3261 and I agree that this document provides a decent 
review of security for SIP in general, but it makes no specific 
mention of UPDATE or (re)INVITE messages and attendant security 
concerns. RFC 3311 has an almost trivial Security Considerations 
section, but at least it does specifically refer to UPDATE and 
(re-)Invite messages, briefly, and the need for authentication. I 
think it would be appropriate to add a discussion of how these 
clarifications operate in various SIP security contexts, e.g., use of 
TLS for point-to-point SIP security or use of S/MIME for end-to-end 
SIP security. A statement that the security offered for SIP when the 
initial call setup was processed cannot be undermined by a later 
re-INVITE or UPDATE would be reassuring (if accompanied by a 
rationale for that statement :).