Skip to main content

Last Call Review of draft-ietf-sipping-config-framework-
review-ietf-sipping-config-framework-secdir-lc-meadows-2010-01-14-00

Request Review of draft-ietf-sipping-config-framework
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-12-22
Requested 2009-12-09
Authors Daniel Petrie , Sumanth Channabasappa
I-D last updated 2010-01-14
Completed reviews Secdir Last Call review of -?? by Catherine Meadows
Assignment Reviewer Catherine Meadows
State Completed
Request Last Call review on draft-ietf-sipping-config-framework by Security Area Directorate Assigned
Completed 2010-01-14
review-ietf-sipping-config-framework-secdir-lc-meadows-2010-01-14-00
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