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

["Pei, Mingliang" <mpei at verisign.com>]

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