Subject: [KEYPROV] DSKPP Simplifications

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 20 Jan 2009 18:39:14 +0200

Hi all, 

At the last IETF KEYPROV meeting Andrea suggested a few proposals for
reducing the number of protocol options in response to Pasi's mail:

* Eliminate "Client certificate/key pair, used with TLS client
authentication"; this would reduce number of combinations from 25 to 8.
There is consensus from the authors that this would be acceptable for
two-pass since, e.g., most implementations find CTLS too costly/complex
to deploy.  Should consider it also for four-pass.

* Combine authentication code and PBKW since both use a one-time secret
value

* Could remove trigger nonce from <KeyProvTrigger>, and rely on manually
entered Authentication Code instead, or <KeyProvTrigger>
message could deliver an Authentication Code (instead of TriggerNonce)
and from there on the protocol would continue the same as with manually
entered authentication code 

Objections? 

Deadline for your feedback: 27th Jan. 2009

Ciao
Hannes
_______________________________________________
KEYPROV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyprov

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 23 Jan 2009 20:24:00 +0100

I hope nobody objects but here are some slightly orthogonal.thoughts on this topic:

IMHO, it is very hard to scale-up on-line key-provisioning in a reasonable way without having some kind of bootstrapping credential.
For systems capable of processing XML, device certificates seems like a perfect match.

With device certificates about 30% of the current DSKPP XML schema can be eliminated since 4-pass would not be needed.

Adding browser invocation (and thus browser authentication), relieves DSKPP from yet another 30% of XML because then protocol-based authentication support becomes redundant as well.

PSKC (when used in DSKPP NB) also shrinks some 70% by relying on device certificates.

The number of options needed would go down in a big way.

One may claim that device certificates is a steep requirement but I don't agree with that.  Adding device certificates during device manufacturing (personalization) is principally no different to adding a serial number, IMEI identifier, or similar; it is just the "generator" that differs.

The only hurdle is that some people claim that you shouldn't encrypt or sign using the same key but I don't buy into that since credential bootstrapping is a very specific scenario where the critical message payload only constitutes of cryptographically generated random numbers making any kind of correlation attacks [for practical purposes] impossible.  Why not use multiple keys you may wonder?  Because with a single key you get a unified device ID which can be expressed as a device certificate hash which in turn opens for really convenient remote enrolment procedures without having to distribute "strong passwords" and similar awkward, error-prone, and not particularly secure measures.

This concept also enables secure remote credential cloning which is an important features given the virtual explosion of portable devices we have today, not to mention how frequently devices are replaced by new better models.

Device certificates are also prerequisites for protocols supporting FIPS140-2 (in a meaningful way), by allowing issuers to discriminate between "soft containers" and "genuine" smart cards.

Anders Rundgren

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sat, 24 Jan 2009 14:11:46 +0200

Hi Anders, 
 
your proposal is interesting, although quite radical. 
I wonder what others in the group think about it? 
 
Ciao
Hannes

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Anders Rundgren
	Sent: 23 January, 2009 21:24
	To: KEYPROV
	Subject: Re: [KEYPROV] DSKPP Simplifications

	I hope nobody objects but here are some slightly
orthogonal.thoughts on this topic:
	 
	IMHO, it is very hard to scale-up on-line key-provisioning in a
reasonable way without having some kind of bootstrapping credential.
	For systems capable of processing XML, device certificates seems
like a perfect match.
	 
	With device certificates about 30% of the current DSKPP XML
schema can be eliminated since 4-pass would not be needed.
	 
	Adding browser invocation (and thus browser authentication),
relieves DSKPP from yet another 30% of XML because then protocol-based
authentication support becomes redundant as well.
	 
	PSKC (when used in DSKPP NB) also shrinks some 70% by relying on
device certificates.

	One may claim that device certificates is a steep requirement
but I don't agree with that.  Adding device certificates during device
manufacturing (personalization) is principally no different to adding a
serial number, IMEI identifier, or similar; it is just the "generator"
that differs.
	 
	The only hurdle is that some people claim that you shouldn't
encrypt or sign using the same key but I don't buy into that since
credential bootstrapping is a very specific scenario where the critical
message payload only constitutes of cryptographically generated random
numbers making any kind of correlation attacks [for practical purposes]
impossible.  Why not use multiple keys you may wonder?  Because with a
single key you get a unified device ID which can be expressed as a
device certificate hash which in turn opens for really convenient remote
enrolment procedures without having to distribute "strong passwords" and
similar awkward, error-prone, and not particularly secure measures.
	 
	This concept also enables secure remote credential cloning which
is an important features given the virtual explosion of portable devices
we have today, not to mention how frequently devices are replaced by new
better models.
	 
	Device certificates are also prerequisites for protocols
supporting FIPS140-2 (in a meaningful way), by allowing issuers to
discriminate between "soft containers" and "genuine" smart cards.
	 
	Anders Rundgren

---

From: <[email-masked]>
Date: Sun, 25 Jan 2009 19:15:06 -0500

IMHO, this is worth considering as part of a separate draft of the
DSKPP.  Note that we already have support for device certificates -
implicitly - since the 2-pass allows the client to send a certificate. A
server could then check that it has been issued to a "good" device and
rely on the private key being accessible only to that device when
sending its response. This was also the reason to remove explicit device
auth: a) it was already supported per above and b) having it explicit
just complicated the protocol.   

With the simplifications I am in the process of making, we can eliminate
17 out of 25 implementation options (70% reduction) without further
pushing the date out. 

Therefore, my recommendation is that we do consider Anders' proposal
once the base DSKPP gets to WGLC.
Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Saturday, January 24, 2009 7:12 AM
To: ext Anders Rundgren; KEYPROV
Subject: Re: [KEYPROV] DSKPP Simplifications

Hi Anders, 

Ciao
Hannes

	 

	 

	 

	 
	Anders Rundgren

---

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 26 Jan 2009 19:41:15 -0800

1. Requring device certificate looks to be radical to me for DSKPP to
address the current market. I don't see that this can happen easily for
mobile phones in the time frame that we would like to have DSKPP
adopted. Putting aside whether device certificate can be cheaply put on
phones, it takes long time for many phone manufacturers to agree on this
and do something. So I won't consider device certificate as a
requirement. 

2. Yes, DSKPP should have the capability to support device certificate
in general for other kinds of devices such as TPM chips and so on.

3. We had two email threads earlier on the end-to-end security from
cryptographic module in a device to the DSKPP server. The trust anchor
support in a cryptographic module was agreed to be deferred into
separate one if needed later.

4. One of the features that can provide end-to-end key confirmation
between the device cryptographic module and service is to use the same
approach in 2-pass as that in 4-pass. The client nonce R_C is encrypted
in four pass but isn't in 2-pass. If we choose to do so also in 2-pass,
it reduces one variation. At the same time, it allows true key
confirmation to crypgraphic module in a device when R_C is sent in
confidential way. We discussed this during 73-th IETF, and would review
this along with the option reduction.

- Ming

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Sunday, January 25, 2009 4:15 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> IMHO, this is worth considering as part of a separate draft 
> of the DSKPP.  Note that we already have support for device 
> certificates - implicitly - since the 2-pass allows the 
> client to send a certificate. A server could then check that 
> it has been issued to a "good" device and rely on the private 
> key being accessible only to that device when sending its 
> response. This was also the reason to remove explicit device
> 17 out of 25 implementation options (70% reduction) without 
> further pushing the date out. 
> 
> Therefore, my recommendation is that we do consider Anders' 
> proposal once the base DSKPP gets to WGLC.
> Andrea
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tschofenig, 
> Hannes (NSN - FI/Espoo)
> 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Anders Rundgren
> 	IMHO, it is very hard to scale-up on-line 
> key-provisioning in a reasonable way without having some kind 
> of bootstrapping credential.
> 	With device certificates about 30% of the current DSKPP 
> XML schema can be eliminated since 4-pass would not be needed.
> 	 
> 	Adding browser invocation (and thus browser 
> authentication), relieves DSKPP from yet another 30% of XML 
> because then protocol-based authentication support becomes 
> redundant as well.
> 	 
> 	One may claim that device certificates is a steep 
> requirement but I don't agree with that.  Adding device 
> certificates during device manufacturing (personalization) is 
> principally no different to adding a serial number, IMEI 
> identifier, or similar; it is just the "generator"
> that differs.
> 	 
> 	The only hurdle is that some people claim that you 
> shouldn't encrypt or sign using the same key but I don't buy 
> into that since credential bootstrapping is a very specific 
> scenario where the critical message payload only constitutes 
> of cryptographically generated random numbers making any kind 
> of correlation attacks [for practical purposes] impossible.  
> Why not use multiple keys you may wonder?  Because with a 
> single key you get a unified device ID which can be expressed 
> as a device certificate hash which in turn opens for really 
> convenient remote enrolment procedures without having to 
> distribute "strong passwords" and similar awkward, 
> error-prone, and not particularly secure measures.
> 	 
> 	This concept also enables secure remote credential 
> cloning which is an important features given the virtual 
> explosion of portable devices we have today, not to mention 
> how frequently devices are replaced by new better models.
> 	 
> 	Device certificates are also prerequisites for 
> protocols supporting FIPS140-2 (in a meaningful way), by 
> allowing issuers to discriminate between "soft containers" 
> and "genuine" smart cards.
> 	 
> 	Anders Rundgren
> 	 
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 27 Jan 2009 07:32:05 -0800

Clearly we cannot require a device certificate. 
 
The question is how public key based client authentication is performed, i.e. whether there are devices out there that have a public key pair on the device that do not have a certificate.

From: [email-masked] on behalf of Pei, Mingliang
Sent: Mon 1/26/2009 10:41 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [KEYPROV] DSKPP Simplifications

- Ming