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

From: Stephen Kent <[email-masked]>
Date: Mon, 6 Feb 2012 12:22:38 -0500

At 9:22 AM +0100 1/18/12, [email-masked] wrote:
>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  

Denis,

Sorry to be so slow to reply.

In the CMC keygen context, there is a major benefit for the central 
keygen facility to have an app-level confirmation that the private 
key has been delivered successfully. I agree that this is a different 
motivation than we
envisioned for PoP originally, but it is still relevant and useful.

Steve

---

From: [email-masked]
Date: Wed, 8 Feb 2012 14:02:15 +0100

Steve, 

PoP does  not  provide "an app-level confirmation that the private 
key has been delivered successfully".

This "confirmation", whatever it is, is not mandatory. 

In any case, a rewriting of the security considerations section is needed. 

Let us see which text you propose next.

Denis

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

Denis,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 8 Feb 2012 11:24:14 -0500

>key has been delivered successfully".

PoP can be provided in various ways. For the CMC server generated key 
context, I imagine that PoP will be provided in a fashion that one 
might view as more app level, but labeling the level is not the most 
important aspect of this discussion.

>This "confirmation", whatever it is, is not mandatory.

if the doc authors propose it as mandatory, and there is WG 
consensus, the  it is.

>Let us see which text you propose next.

I'm not proposing text for this doc. I am not a coauthor. I am merely 
noting that your view of what is an and not mandatory is not shared 
by a WG chair.

Steve

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 12 Feb 2012 10:59:32 +0100

> Let us see which text you propose next.

Denis,
There are basically two use-cases for out-of-the-crypto-module generated keys.

1. Devices that have limited crypto capability.  The already widely established
   method is using key-injection during the manufacturing/personalization process.
   That doesn't require a new protocol.

2. Restore/update of encryption keys.  For that you would need a secure import
   process.  This is already established by ETSI for smart cards using a
   completely different method than CMP.

Conclusion: this draft doesn't address any real use-cases.

Anders

> Objet :        Re: [pkix] I-D Action:  draft-ietf-pkix-cmc-serverkeygeneration-00.txt
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 14 Feb 2012 22:56:28 +0100

Followup,
The section "1.2 Location of Key Generator" is at odds with
the reality.  Crypto modules seldom (ever?) speak PKIData, they can
at best produce a PKCS #1 signature.  I.e. there is one trusted path
and associated "lingo" between the Client and the RA and another between
the RA and the CA.  No PKIX enrollment protocol support E2ES.

Do you have any idea what a possible client could be?

Regarding PoP for server-generated keys it seems redundant
since the RA can verify that the key-pair is intact.

An established use-case for server-generated keys is CAs delivering
keys in PKCS #12 containers.

Anders

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 18 Feb 2012 13:46:45 -0800

Sorry for the delay, I have not been keeping current with the mailing list
like I should have been.

The POP is envisioned to make sure that the client does have the ability to
decrypt the returned key.  This is explicitly stated in the document
current.

The POP also has a secondary benefit which was not stated because while I
think it is probably there is no way to assert that it is true.  The POP
allows the server to have a fair degree of confidence that only the client
can decrypt the returned key.  This provides a strong degree of protection
against the possibility that an attacker can induce the client to use their
public key in the enrollment process.  Doing so would result in a
certificate for Alice that Alice could not use but Mallory could.

The following is based on the assumption that only one entity has control of
the private key.  If Mallory can induce Alice to accept both a public and a
private key then all bets are off on this assumption.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ
Housley
Sent: Tuesday, January 10, 2012 8:52 AM
To: [email-masked]
Cc: IETF PKIX
Subject: Re: [pkix] I-D Action:
draft-ietf-pkix-cmc-serverkeygeneration-00.txt

Denis:

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 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: Mon, 20 Feb 2012 16:52:59 +0100

Jim,

I am still unconvinced that this provides a high degree of protection and 
that it is necessary.

You said:

"This provides a strong degree of protection against the possibility that 
an attacker 
can induce the client to use their public key in the enrollment process" 

The public key is integrity protected during the exchange using shared 
secret or a certified key.
 If an attacker can change the public key, then the security is broken.

If an attacker changes the public key with a public from a key pair that 
he knows, then in the same way the security is broken.
This means that adding PoP does not add anything.

To make a parallel, in a TSL exchange do we ask the web server to prove 
that it knows the private key when it sends its certificate?
The answer is no. So why should we do it in that case ?

The only very little advantage would be : if the client makes a mistake of 
its own, then the server will notice it immediately, 
rather that the client on the next round. Adding protocol elements for 
that specific error case which might only happen in practice 
during a debugging phase is not worth the effort.

Now, if some people want to perform unnecessary computations and add 
elements to the protocol that are not strictly needed, that is fine for 
them.

Why should they have a simple protocol when it can be made more 
complicated ? 
:-)

However, these people should not force other people to add unnecessary 
protocol elements.

Denis

De :    "Jim Schaad" <[email-masked]>
A :     <[email-masked]>
Cc :    "'IETF PKIX'" <[email-masked]>
Date :  18/02/2012 23:08
Objet : RE: [pkix] I-D Action: 
draft-ietf-pkix-cmc-serverkeygeneration-00.txt

The POP is envisioned to make sure that the client does have the ability 
to decrypt the returned key.  This is explicitly stated in the document 
current.
 
The POP also has a secondary benefit which was not stated because while I 
think it is probably there is no way to assert that it is true.  The POP 
allows the server to have a fair degree of confidence that only the client 
can decrypt the returned key.  This provides a strong degree of protection 
against the possibility that an attacker can induce the client to use 
their public key in the enrollment process.  Doing so would result in a 
certificate for Alice that Alice could not use but Mallory could.
 
The following is based on the assumption that only one entity has control 
of the private key.  If Mallory can induce Alice to accept both a public 
and a private key then all bets are off on this assumption.
 
Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Russ Housley
 
Denis:
 
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 

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: Tue, 21 Feb 2012 11:57:34 +0100

Anders,

I agree with you  that the trust model does not make sense.

Indeed, the problem is that the draft  is proposed for "standard track".
If it were pushed for experimental or for informational, this would be no 
problem.

Denis

PS. I  sent 12 comments on January 10, 2012 and only one of them (n° 3) 
has/is  being  discussed : POP.
The list of comments is copied again below .

===========================================================================================

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.

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.

De :    Anders Rundgren <[email-masked]>
A :     [email-masked]
Cc :    Jim Schaad <[email-masked]>
Date :  20/02/2012 20:53
Objet : Re: [pkix] I-D Action: 
draft-ietf-pkix-cmc-serverkeygeneration-00.txt

Denis,
This discussion is redundant; the issues have already been
addressed by the smart card industry years ago.  With Google's
wallet they are becoming ubiquitous.

The described trust model doesn't match the reality.  If NSA
wants to create a scheme that

  - is at odds withe the industry
  - will cost the USG a fortune

it seems that they should create a private standard for that.

Anders

On 2012-02-20 16:52, [email-masked] wrote:
> Jim,
> 
> I am still unconvinced that this provides a high degree of protection 
and that it is necessary.
> 
> You said:
> 
> "This provides a strong degree of protection against the possibility 
that an attacker
> The only very little advantage would be : if the client makes a mistake 
of its own, then the server will notice it immediately,
complicated ?
protocol elements.
> 
> 
> 
> Sorry for the delay, I have not been keeping current with the mailing 
list like I should have been.
> 
> The POP also has a secondary benefit which was not stated because while 
I think it is probably there is no way to assert that it is true.  The POP 
allows the server to have a fair degree of confidence
> that only the client can decrypt the returned key.  This provides a 
strong degree of protection against the possibility that an attacker can 
induce the client to use their public key in the enrollment
> process.  Doing so would result in a certificate for Alice that Alice 
could not use but Mallory could.
> 
> The following is based on the assumption that only one entity has 
control of the private key.  If Mallory can induce Alice to accept both a 
public and a private key then all bets are off on this
> assumption.
> 
> Jim
> 
> 
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf 
Of *Russ Housley*
> Sent:* Tuesday, January 10, 2012 8:52 AM*
> To:* [email-masked]*
> Cc:* IETF PKIX*
> Subject:* Re: [pkix] I-D Action: 
important”.
decrypt the private key
> and thus there is no harm. IMO, POP is unnecessary. This will lead to 
many simplifications on the document.
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
> 
> 
>