Subject: Re: [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt

From: Sean Turner <[email-masked]>
Date: Fri, 01 Jun 2012 15:24:53 -0400

Denis,

Apologies for taking forever to get back to this.  I hope to have the 
next version out soon.

spt

On 1/10/12 11:43 AM, [email-masked] wrote:
> 12 comments on draft-ietf-pkix-cmc-serverkeygeneration-00.txt
> CMC Extensions: Server Key Generation
>
>
> 1) A vulnerability analysis is missing and thus security requirements
> are missing.

Always interesting trying to answer this kind of comment :)  I'll 
readily admit the security considerations need to be beefed up.  I've 
added some text in my working copy that will hopefully address this.

> 2) The advantages and disadvantages of each method is not discussed or
> explained before the methods are introduced.

In my working copy there's about an additional page of text to go over 
some of the advantages and disadvantages of each method.

> 3) The security considerations section states: “POP is extremely
> important”.
> However, the text placed after does not provide a rational:
>
> “However, POP here is different than in
> client-generated key certification requests in that the POP is
> necessary to prove to the server that the client has possession of
> the private key necessary to decrypt the server-generated private key
> rather than possess the private key associated with the public key in
> the request.
>
> If the client does not possess the private key, he will not be able to
> decrypt the private key
> and thus there is no harm. IMO, POP is unnecessary. This will lead to
> many simplifications on the document.

I think Jim and Russ answered this one.  I've worked up a bunch of text 
to explain that the POP we were talking about is not POP for the key 
returned from the server.  If you're going to do POP for the 
server-generated key an additional roundtrip is required.

I also now tend to agree that the POP we were talking is more as you 
characterize.  However, I want to keep the option for CAs to require 
that clients show they've got the private key needed to decrypt the key. 
  In my working copy, I've got aome text to address this.

> 4) How replay protection of the messages is achieved is not explained,
> even in the security considerations section.

We'll add some text.

> 5) The text states in section 1.1.1:
>
> “The shared secret allows the server to authenticate the client and
> allows the server to encrypt
> the server-side generated key for the client”.
>
> This is not very secure. If the shared key is discovered, then all
> previous private keys may be decrypted.
> There should be a static key derived from the shared key to be used for
> authentication and
> an ephemeral key derived from the shared key and from a random (thus the
> encryption key is different
> for every private key). The derivation function should be one way. The
> derivation methods should be part
> of the specification.

We did point this out as an issue in the security considerations (last 
paragraph).  The problem is that if you use a shared secret to provide 
the security, it doesn't matter how many different ways we derive the 
key if the master is disclosed.  This is one of the reasons you'd use 
the public key option.

> 6) The text states in section 1.1.1:
>
> “The shared secret allows the server to authenticate the client and
> allows the server to encrypt
> the server-side generated key for the client. The shared secret is
> distributed via an out-of-band
> mechanism that is out-of-scope of this document”.
>
> This is insufficient. There is a need to distribute IDs and shared
> secrets so that the server
> may select the right key when it receives a request. The ID must be part
> of the request.

You're right we'll add that the IDs need to be distributed and we'll add 
it in the requests.

> 7) The text states in section 1.1.1:
>
> “The client can validate that the response came from the CA by
> validating the digital signature on the SignedData to a Trust Anchor
> (TA)”.
>
> No. The client must validate that the response came from the CA using
> the authentication key.

I disagree on this.  There's a chance the key was actually generated by 
the RA and verifying the authentication key wouldn't tell you it came 
from the CA.

> 8) The text states in section 1.1.2:
>
> “POP is necessary because the client would like the
> response encrypted with a public key and the server must determine
> that the client actually has the private key associated with the
> public key.”
>
> POP is not necessary. See above.

Hopefully, I'll have this all fixed up in the next version.

> 9) Typo on page 7, last line before the end of the page.
> Replace “date” by “data”.

fixed in my working copy

> 10) The text states in section 2.1 on page 14:
>
> “When this method is used with the certificate option, the server MUST
> validate the certificate back to a trust anchor. Further, the server
> MUST check that the client provided certificate belongs to the same
> client that authenticated the certificate request (e.g. the
> certificate subjects match, or the client provided certificate
> belongs to the same entity as the authentication shared secret). If
> either of these checks fails, then the server MUST return a
> CMCFailInfo with the value of badCertificate, which is defined in
> Section 5”.
>
> This is not necessary. This paragraph should be deleted.

I think validating back to a trust anchor is a valuable step. 
Otherwise, why wouldn't you just use the uncertified public key.

> 11) The text states in section 2.2 on page 15:
>
> “In general, while it
> is expected that the same identity token and shared secret used to do
> the identity authentication are used to derive the key encryption key
> this is not required”.
>
> As stated earlier, the use of the same key shall not be possible.

This text doesn't state that the same key is derived.

> 12) The text states in section 6 on page 20:
>
> “Cryptographic algorithms and keys used to protect the private key
> should be at least as strong as the private key's intended strength”.
>
> A separate discussion on the strength of the authentication key and of
> the encryption key is needed.

How about we point to RFC 3766 and maybe NIST SP800-57?

Again, apologies for taking too long to get to this.