[secdir] Secdir review of draft-ietf-sipping-config-framework-16

Catherine Meadows <catherine.meadows@nrl.navy.mil> Mon, 11 January 2010 21:42 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
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 CDA613A682E; Mon, 11 Jan 2010 13:42:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 YcDRO59nlPz4; Mon, 11 Jan 2010 13:42:03 -0800 (PST)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 9959B3A67F3; Mon, 11 Jan 2010 13:42:03 -0800 (PST)
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id o0BLfqMn020204; Mon, 11 Jan 2010 16:41:56 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id o0BLflNJ009332; Mon, 11 Jan 2010 16:41:50 -0500 (EST)
Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010011116414621424 ; Mon, 11 Jan 2010 16:41:46 -0500
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary=Apple-Mail-11--676334414
Date: Mon, 11 Jan 2010 16:43:10 -0500
Message-Id: <214A28E5-3DBD-4252-8EF6-7E18CEB441E5@nrl.navy.mil>
To: secdir@ietf.org, dan.ietf@sipez.com, sumanth2cablelabs.com@chacs.nrl.navy.mil, iesg@ietf.org
Mime-Version: 1.0 (Apple Message framework v1077)
X-Mailer: Apple Mail (2.1077)
Subject: [secdir] Secdir review of draft-ietf-sipping-config-framework-16
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: Mon, 11 Jan 2010 21:42:04 -0000

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.

This ID has to do with User Agent profile delivery in SIP.  A profile is the configuration data sent to a SIP User Agent so that it can function properly.  This information is called a profile, and in SIP the maintenance and delivery of this information is the responsibility of the Profile Delivery Server (PDS).   This ID describes the protocol used to deliver this information.

As would be expected, there are some serious security issues with respect to profile delivery.  Profiles may contain sensitive information, so they need to be protected and the User Agents to which they are sent must be properly authenticated to the PDS.  Likewise, the PDS must also be properly authenticated to the User Agent, since a fraudulent PDS could send a bogus and possibly harmful profile to the User Agent.  This ID recognizes this and describes how the mechanisms of SIP should or must be used to support user agent profile delivery.
One key issue here is the case in which a device is requesting a profile, but for various reasons (e.g. it is just being initialized), it does not have the ability to authenticate itself.  Thus some other methods must be used.  These are outlined in Section 5.3.1.

I think that this ID is in general in good shape with respect to security, but I was a little confused about some of the discussion of bootstrapping.  It is the hardest to pin down, of course, but it is also the most important to make clear, because it is the point, I believe, at which the network is most vulnerable. Specific comments follow:

1.  The first sentence of Section 5.3.1, which reads 

When requesting a profile the device can provide an identity (i.e., a
user AoR), and contain associated credentials for authentication. To
do so, the device needs to obtain this information via bootstrapping.

I wasn't quite sure what this means.   Should that "can" be a "must"?  That is, the device needs the information, but can only get it through bootstrapping.  Or is the
"contain" be "obtain", and bootstrapping is how you get it?

2.  Bootstrapping itself is never explicitly defined.  I'd suggest doing that at the beginning of 5.3.1.

3.  The discussion of bootstrapping in 5.3.1 appears to only consider the threat to the PDS.  What about the other way around?  This is mentioned as a threat in the Security Considerations section, but it's not clear to me whether 5.3.1 addresses this threat.

4.  The discussion of the security implications of bootstrapping device profiles in Section 9.2 is valuable, and helps the reader understand the rationale for the recommendations in 5.3.1 better,  A forward reference in the discussion of device profile on page 26 would be helpful.
Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil