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

From: Catherine Meadows <[email-masked]>
Date: Mon, 11 Jan 2010 16:43:10 -0500

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: [email-masked]

---

From: Daniel Petrie <[email-masked]>
Date: Mon, 11 Jan 2010 19:00:41 -0800 (PST)

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 <[email-masked]> wrote:

> From: Catherine Meadows <[email-masked]>
> Subject: Secdir review of draft-ietf-sipping-config-framework-16
> To: [email-masked], [email-masked], [email-masked], [email-masked]
> Cc: "Catherine Meadows" <[email-masked]>
> Date: Monday, January 11, 2010, 4:43 PM
> I have reviewed this
> document as part of the
> 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:
> 
> 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
> 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

---

From: Sumanth Channabasappa <[email-masked]>
Date: Tue, 26 Jan 2010 22:42:50 -0700

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

	

=== [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?
====

=== [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).

====

=== [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)?
====

=== [D&S] ===
Good suggestion, agree.
====