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

Catherine Meadows <catherine.meadows@nrl.navy.mil> Sat, 06 February 2010 01:53 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 D44953A6FCC; Fri, 5 Feb 2010 17:53:11 -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 c8kSQpVzBE9B; Fri, 5 Feb 2010 17:53:11 -0800 (PST)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id CA30A3A6FCB; Fri, 5 Feb 2010 17:53:10 -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 o161rqFn013981; Fri, 5 Feb 2010 20:53:52 -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 o161rkmD019140; Fri, 5 Feb 2010 20:53:46 -0500 (EST)
Received: (from [IPv6:::1] [10.0.0.13]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010020520534522386 ; Fri, 05 Feb 2010 20:53:45 -0500
Message-Id: <DDD3D475-4678-4A39-9CE3-1A62076CB4BC@nrl.navy.mil>
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
To: Sumanth Channabasappa <sumanth@cablelabs.com>
In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CD37AFFA3@srvxchg>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 5 Feb 2010 20:53:45 -0500
References: <214A28E5-3DBD-4252-8EF6-7E18CEB441E5@nrl.navy.mil> <DD7DFD78-4285-4F8B-9F81-C2F8BCA77768@nrl.navy.mil> <76AC5FEF83F1E64491446437EA81A61F7CD37AFFA3@srvxchg>
X-Mailer: Apple Mail (2.936)
Cc: "iesg@ietf.org" <iesg@ietf.org>, "dan.ietf@sipez.com" <dan.ietf@sipez.com>, "secdir@ietf.org" <secdir@ietf.org>
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
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: Sat, 06 Feb 2010 01:53:11 -0000

My apologies for not replying to this earlier.  These changes look fine.

Cathy

On Jan 27, 2010, at 12:42 AM, Sumanth Channabasappa wrote:

> Catherine,
>
> Thanks again for your keen observations, and the associated  
> comments. Dan and I discussed them offline, and I am summarizing our  
> responses inline, tagged with [D&S]. Please let us know if they  
> address your questions.
>
> - Dan & Sumanth
>
> 	
> 	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?
>
> === [D&S] ===
>
> You raise a good question. Dan suggested the following to solve the  
> confusion (and I concur with him):
>
> Replace the first sentence of 5.3.1:
> "When requesting a profile the device can provide an identity (i.e.,  
> a user AoR), and contain associated credentials for authentication."
>
> with:
>
> "When requesting a profile the profile delivery server will likely  
> require the device to provide an identity (i.e., a user AoR), and  
> associated credentials for authentication."
>
> Does that help?
> ====
>
>
> 	
> 	2.  Bootstrapping itself is never explicitly defined.  I'd suggest  
> doing that at the beginning of 5.3.1.
>
> === [D&S] ===
>
> You are correct. How about the following at the beginning of 5.3.1:
>
> "Bootstrapping is the process  by which a new (or factory reset)  
> device, with no configuration or minimal "factory" pre- 
> configuration, enrolls with the PDS.  The device may use a temporary  
> identity and credentials to authenticate itself to enroll and  
> receive profiles, which may provide more permanent identities and  
> credentials for future enrollments."
>
> Alternatively, we could add this definition in Section 2  
> (Terminology).
>
> ====
> 	
>
> 	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.
>
> === [D&S] ===
> This is addressed in Section 5.2.1, for normal profile enrollment.  
> Perhaps we should add a reference to these requirements in Section  
> 5.3.1 so that it is clear that the device authenticates the PDS even  
> in the bootstrapping scenario (e.g., during digest authentication)?
> ====
>
> 	
> 	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.
> 	
> === [D&S] ===
> Good suggestion, agree.
> ====
>
>

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