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

From: [email-masked]
Date: Tue, 03 Jan 2012 12:00:25 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : CMC Extensions: Server Key Generation
	Author(s)       : Jim Schaad
                          Sean Turner
                          Paul Timmel
	Filename        : draft-ietf-pkix-cmc-serverkeygeneration-00.txt
	Pages           : 22
	Date            : 2012-01-02

   This document defines a set of extensions to the Certificate
   Management over CMS (CMC) protocol that addresses the desire to
   support server-side generation of keys.  This service is provided by
   the definition of additional control statements within the CMC
   architecture.  Additional CMC errors are also defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-serverkeygeneration-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-cmc-serverkeygeneration-00.txt

---

From: [email-masked]
Date: Tue, 10 Jan 2012 17:43:56 +0100

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.

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

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.

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

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.

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.

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.

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.

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

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.

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.

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.

Denis

De :    [email-masked]
A :     [email-masked]
Cc :    [email-masked]
Date :  03/01/2012 21:01
Objet : [pkix] I-D Action: draft-ietf-pkix-cmc-serverkeygeneration-00.txt
Envoyé par :    [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories. This draft is a work item of the Public-Key Infrastructure 
(X.509) Working Group of the IETF.

                 Title           : CMC Extensions: Server Key Generation
                 Author(s)       : Jim Schaad
                          Sean Turner
                          Paul Timmel
                 Filename        : 
draft-ietf-pkix-cmc-serverkeygeneration-00.txt
                 Pages           : 22
                 Date            : 2012-01-02

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 Jan 2012 11:51:54 -0500

Denis:

> 3) The security considerations section states: “POP is extremely important”. 
> 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 do agree that there is no exposure if the private key cannot be unwrapped (assuming the use of good algorithms and such).  However, the way I read it, the authors want proof that the private key could be unwrapped and used.  This seems like a good feature.

Russ

---

From: [email-masked]
Date: Wed, 11 Jan 2012 09:46:16 +0100

Russ,

The cost of POP has to be balanced with the very little advantage you 
mention.

POP is costly and cannot be easily done with any algorithm. For the sake 
of simplification,
(less options means greater interoperability), POP should be suppressed, 
even as an option.

Denis

De :    Russ Housley <[email-masked]>
A :     [email-masked]
Cc :    IETF PKIX <[email-masked]>
Date :  10/01/2012 18:19
Objet : Re: [pkix] I-D Action: 
draft-ietf-pkix-cmc-serverkeygeneration-00.txt

Denis:

I do agree that there is no exposure if the private key cannot be 
unwrapped (assuming the use of good algorithms and such).  However, the 
way I read it, the authors want proof that the private key could be 
unwrapped and used.  This seems like a good feature.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Jan 2012 15:14:40 -0500

At 9:46 AM +0100 1/11/12, [email-masked] wrote:
>Russ,
>
>The cost of POP has to be balanced with the very little advantage you mention.
>
>POP is costly and cannot be easily done with any algorithm. For the 
>sake of simplification,
>(less options means greater interoperability), POP should be 
>suppressed, even as an option.
>
>Denis
>

Denis,

POP is easy for any alg that is capable of sigs. I would expect that most
certs are issued for keys that can be used for sigs, not just for key 
agreement. In the cases where signature functionality is not 
intrinsic for the key
being put in a cert, we have described (in prior docs) ways to deal 
with the problem. So, I don't think it is reasonable to say that POP 
is hard, in general, nor
should we consider advocating against it.

Steve

---

From: [email-masked]
Date: Wed, 18 Jan 2012 09:22:09 +0100

Steve,

In this case, POP does not counter a threat. Saying in the security 
considerations section it is important and necessary 
does not make sense. It is certainly possible add controls which are not 
necessary. 

If you really want to maintain for whatever reason (already existing 
implementation ?), then it, it should clearly be an option 
that any compliant implementation is NOT mandated to implement.

Denis 

De :    Stephen Kent <[email-masked]>
A :     [email-masked]
Cc :    Russ Housley <[email-masked]>, IETF PKIX <[email-masked]>
Date :  17/01/2012 22:20
Objet : Re: [pkix] I-D Action: 
draft-ietf-pkix-cmc-serverkeygeneration-00.txt

mention.

Denis,

Steve

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Jan 2012 09:57:40 -0500

Denis:

> If you really want to maintain for whatever reason (already existing implementation ?), then it, it should clearly be an option 

I can imagine environments where there are sufficient physical and procedural controls that POP is not needed.  However, from my experience, these are not the norm.  And, as Steve Kent has already commented, POP processing is not hard.  As I said before, positive confirmation that the intended recipient was able to unwrap the private key is very valuable.

I do not understand the environment you describe where the CA does not care whether the intended recipient is able to unwrap the private key.  You say that there is no harm if the key cannot be unwrapped by the intended recipient.  I disagree.  The harm is that the CA thinks there is an active subscriber when there is not.

Russ