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 at nrl.navy.mil