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

Daniel Petrie <dpetrie@sipez.com> Tue, 12 January 2010 03:07 UTC

Return-Path: <dpetrie@sipez.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 542A23A6962 for <secdir@core3.amsl.com>; Mon, 11 Jan 2010 19:07:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 7ZFi10FGerXP for <secdir@core3.amsl.com>; Mon, 11 Jan 2010 19:07:26 -0800 (PST)
Received: from web37102.mail.mud.yahoo.com (web37102.mail.mud.yahoo.com [209.191.85.104]) by core3.amsl.com (Postfix) with SMTP id 2168E3A6812 for <secdir@ietf.org>; Mon, 11 Jan 2010 19:07:26 -0800 (PST)
Received: (qmail 1689 invoked by uid 60001); 12 Jan 2010 03:00:42 -0000
Message-ID: <373981.1666.qm@web37102.mail.mud.yahoo.com>
X-YMail-OSG: V9Ut2j4VM1lLIY8xUWmNJEGUeouum9Ighzgt8K87WSu26t_5In3mXLfrnpl8OpElbbdENXd1S7uxqVHVlc1iNvR.4AhJpdPbXV0Eg11g9NE5Qe1qn.unmR3lspVhue7POLziZKS59RlioUmsdqhqo9nis5_I9J9dJq4ONvTkJjlWFF9vF6MXxbZR4HcDBJeSnANnF154_vOVgCGdtkgTDWAPwOpZqu7jja2OwHCwvv1GhQc6sEoKhIY7_0v1q6FqpeiMqWf8uGw5V88ZuaXvPcg.KZvBEMH.gcczfoIwbJa8EELMVelCsos6baKp3ppxZsjwvjj4WIZlAzGRn46qbsbEmg--
Received: from [24.61.83.127] by web37102.mail.mud.yahoo.com via HTTP; Mon, 11 Jan 2010 19:00:41 PST
X-RocketYMMF: dgpetrie
X-Mailer: YahooMailClassic/9.0.20 YahooMailWebService/0.8.100.260964
Date: Mon, 11 Jan 2010 19:00:41 -0800 (PST)
From: Daniel Petrie <dpetrie@sipez.com>
To: secdir@ietf.org, dan.ietf@sipez.com, sumanth2cablelabs.com@chacs.nrl.navy.mil, iesg@ietf.org, Catherine Meadows <catherine.meadows@nrl.navy.mil>
In-Reply-To: <214A28E5-3DBD-4252-8EF6-7E18CEB441E5@nrl.navy.mil>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 11 Jan 2010 23:16:52 -0800
Subject: Re: [secdir] Secdir review of draft-ietf-sipping-config-framework-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dpetrie@sipez.com
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: Tue, 12 Jan 2010 03:07:26 -0000

Hi Catherine:
Thank you for the very constructive comments.  I very much appreciate your effort of slogging through this draft.  I have to go refresh my memory on the issues you have identified.

Cheers,
Dan

--- On Mon, 1/11/10, Catherine Meadows <catherine.meadows@nrl.navy.mil> wrote:

> From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
> Subject: Secdir review of draft-ietf-sipping-config-framework-16
> To: secdir@ietf.org, dan.ietf@sipez.com, sumanth2cablelabs.com@chacs.nrl.navy.mil, iesg@ietf.org
> Cc: "Catherine Meadows" <catherine.meadows@nrl.navy.mil>
> Date: Monday, January 11, 2010, 4:43 PM
> 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
> 
> 
>