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

[Catherine Meadows <[e-mail]>]

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: [phone]
fax: [phone]
email: [e-mail]