Subject: [KEYPROV] DSKPP stateful 4-pass support and a variant to make it stateless

From: "Pei, Mingliang" <[email-masked]>
Date: Tue, 28 Apr 2009 09:56:26 -0700

One of the properties of DSKPP 4-pass is that the protocol is stateful.
Ideally a stateless protocol is the best for a web service. The 2-pass
version of DSKPP is stateless, which I consider perfect. In order to
support the 4-pass state, namely R_S sent in the 2nd pass
KeyProvServerHello in the use of the 4-th pass KeyProvServerFinished, I
have the following suggestions.
 
1. Suggest that we add some context in the DSKPP.
 
With HTTP binding, it is recommended that a client keeps use of the same
HTTP connection for the 4-pass. When a service side provides
provisioning server in multiple sites, the client should help the server
to reduce state replication across servers or sites.
 
Note that there are cases where a client has no control on the same
connection, for example, a request message is sent over the air where a
proxy in carrier or web may forward it to a different server other than
the one for the first round trip.
 
2. There is a way to make 4-pass DSKPP stateless for a popular use case:
 
Use case: DSKPP server has a RSA certificate but the client device and
the server have no preloaded encryption key. This is a typical use case
for mobile device and TPM chips in order to acquire a credential from a
server and ensure end-to-end security where a credential is only known
to the device and the server.
 
Stateless 4-pass protocol variation:
 
Instead of using mutual key generation, the KeyProvServerFinished
returns the server generated key as that in the 2-pass DSKPP variant.
The key encryption key is the R_C that is currently produced and used
for key derivation.
 
By doing this, the 2nd pass is independent of the first pass where R_S
is removed.
 
The variation of this profile is the following minor changes in schema
and specification:
 
   * KeyProvClientHello and the KeyProvServerHello remains the same. In
the KeyProvServerHello message, the server's public is sent as the
encryption key to transport client generated encryption key R_C.
   * The client is going to generate R_C as an encryption key instead of
half-key for the final key derivation.
   * KeyProvClientNonce remains the same. Optionally device information
can be sent in this request instead of KeyProvClientHello. The R_C is
encrypted with the server's public key as the current draft does.
   * KeyProvServerFinished schema remains the same. Only the
KeyContainer will include the secret key value as in the 2-pass case.
The secret will be encrypted with R_C. Currently the secret is derived
from R_C, R_S, and the server's public key.
 
The pros of this extension is that it makes the protocol stateless.
Moreover, it makes the protocol simpler and consistent with 2-pass
provisioning. The cons is that it is subject to man-in-the-middle
attack. A MITM may send its own certificate for a client to encrypt and
therefore gets a copy of secret sent between the client and the server.
Note that existing protocol is subject to MITM too; only MITM cannot
fool a server to generate a desired secret. With SSL transport layer and
additional authentication data we have placed in the protocol, this can
be mitigated. There is use case where additional device authentication
data may be available to mitigate MITM.
 
Thoughts? Thank you,
 
- Ming