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

[Daniel Petrie <[e-mail]>]

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 <[e-mail]> wrote:

> From: Catherine Meadows <[e-mail]>
> Subject: Secdir review of draft-ietf-sipping-config-framework-16
> To: [e-mail], [e-mail], [e-mail], [e-mail]
> Cc: "Catherine Meadows" <[e-mail]>
> 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: [phone]
> fax: [phone]
> email: [e-mail]
> 
> 
>