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

Sumanth Channabasappa <> Wed, 27 January 2010 05:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AAA823A6A12; Tue, 26 Jan 2010 21:42:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.463
X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T3Ou64vSCnML; Tue, 26 Jan 2010 21:42:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9479E3A6A0B; Tue, 26 Jan 2010 21:42:41 -0800 (PST)
Received: from (kyzyl []) by (8.14.3/8.14.3) with ESMTP id o0R5gqND016798; Tue, 26 Jan 2010 22:42:53 -0700
Received: from ( by (F-Secure/fsigk_smtp/303/; Tue, 26 Jan 2010 22:42:53 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/303/
Received: from ([]) by srvxchg ([]) with mapi; Tue, 26 Jan 2010 22:42:53 -0700
From: Sumanth Channabasappa <>
To: Catherine Meadows <>, "" <>, "" <>, "" <>
Date: Tue, 26 Jan 2010 22:42:50 -0700
Thread-Topic: Secdir review of draft-ietf-sipping-config-framework-16
Thread-Index: AcqTB0AeRIi9UK+9RQO2UVzuUYUAoAMCgEog
Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD37AFFA3@srvxchg>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Approved: ondar
X-Mailman-Approved-At: Tue, 26 Jan 2010 22:46:50 -0800
Subject: Re: [secdir] Secdir review of draft-ietf-sipping-config-framework-16
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Jan 2010 05:42:42 -0000


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."


"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.