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

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Wed, 27 October 2010 12:19 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
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 458A63A684A for <secdir@core3.amsl.com>; Wed, 27 Oct 2010 05:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.478
X-Spam-Level:
X-Spam-Status: No, score=-106.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 dbe3jB41-fTC for <secdir@core3.amsl.com>; Wed, 27 Oct 2010 05:19:40 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 8B3523A67CF for <secdir@ietf.org>; Wed, 27 Oct 2010 05:19:35 -0700 (PDT)
X-AuditID: c1b4fb39-b7b54ae000003464-da-4cc81944cac2
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.38.13412.44918CC4; Wed, 27 Oct 2010 14:21:24 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Oct 2010 14:21:23 +0200
Received: from [131.160.126.178] ([131.160.126.178]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Oct 2010 14:21:23 +0200
Message-ID: <4CC81942.3060502@ericsson.com>
Date: Wed, 27 Oct 2010 15:21:22 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
References: <p06240800c8e55027a17b@[128.89.89.159]>
In-Reply-To: <p06240800c8e55027a17b@[128.89.89.159]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Oct 2010 12:21:23.0696 (UTC) FILETIME=[784A9700:01CB75D1]
X-Brightmail-Tracker: AAAAAA==
Cc: "secdir@ietf.org" <secdir@ietf.org>, "gao.yang2@zte.com.cn" <gao.yang2@zte.com.cn>, "pkyzivat@cisco.com" <pkyzivat@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>, "tim.polk@nist.gov" <tim.polk@nist.gov>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>
Subject: Re: [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: Wed, 27 Oct 2010 12:19:41 -0000

Hi Stephen,

thanks for your review. My answers inline:

On 21/10/2010 5:17 AM, Stephen Kent wrote:
> 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).

I suggest adding the following text in both places: "(see Section 26.2
of RFC 3261)".

http://tools.ietf.org/html/rfc3261#section-26.2

The way user agents authenticate incoming requests has not changed much
since RFC 3261 was published.

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

I suggest adding the following text to the Security Considerations
Section. Feel free to edit the text if you wish:

"In particular, in order not to reduce the security level for a given
session, re-INVITEs and UPDATE requests SHOULD be secured in a similar
or stronger manner as the initial INVITE request that created the
session. For example, if the initial INVITE request was end-to-end
integrity protected or encrypted, subsequent re-INVITEs and UPDATE
requests should also be so."

A discussion on which security mechanisms should be applied in different
contexts in outside the scope of this document, IMHO. SIP has been and
is being deployed in so different environments that we would need a
whole document (or more likely a set of them) to discuss all relevant
issues.

Thanks,

Gonzalo