Subject: Re: [secdir] security review of draft-ietf-pkix-rfc3280bis-09

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Dec 2007 18:00:43 -0500

At 6:13 PM -0500 12/12/07, Ran Canetti wrote:
>   *I have reviewed this document as part of the security directorate's
>   *ongoing effort to review all IETF documents being processed by the
>   *IESG.  These comments were written primarily for the benefit of the
>   *security area directors.  Document editors and WG chairs should treat
>   *these comments just like any other last call comments.
>
>
>While I have not read the document in full detail, my overall impression
>is that it is well thought out and nicely done.
>
>One aspect that I found a bit lacking though is in providing a language
>for certificates to contain inormation on what the certificate actually
>attests to. Salient options include:
>
>- Does the certificate attest that the certified owner has merely
>presented the public key to the CA?
>
>- Does the certificate attest that the certified owner of the
>public key actually has the corresponding secret key?
>
>- Does the certificate attest that the certified owner has chosen the key
>with a good/accredited/certified random number generator?
>
>There can of course be additional variants - e.g., has the CA explicitly
>seen the secret key, or was there only a "proof of ability to
>sign/decrypt"? in the latter case, what's the exact protocol used and what
>security guarantees does it carry? (e.g. was a POP out of those in RFC
>2797 performed? another protocol?)

These aspects of cert issuance criteria are represented via the CPS 
of the issue and/or the policy under which the cert is issued. The 
issuer may choose to include a policy OID in the cert policies 
extension, for the cert, and even to include policy text (or a 
reference to the text) via the UserNotice part of this extension. So, 
the bottom line is that PKIX already defines ways for CAs to convey 
this info to relying parties, although we do not mandate that CAs 
express this in the cert policies extension.

>Each of these attestations provides a different "cryptographic trust"
>guarantee. The differences can be critical to the security of protocols
>that rely on these certificates. (For instance, if a certificate only
>attests that the CA has seen the public key, then this leaves open the
>possiblity that a user has registered a public key that was copied from
>the certificate of another entity. While such behavior is harmless for the
>security of typical authentication protocols such as IPSEC,TLS etc, it
>can be disastrous in other situations.)

As you noted above, proof of possession is part of our standard cert 
request protocols, (CMC and CMP, and is a mandatory feature of both. 
Wether the CA  demands PoP is another fact that can be expressed in 
the CP or CMS.

>It thus seems prudent that a certificate will be required to contain a
>field that describes the "semantics" of what's actually being certified
>regarding the registered public key, perhaps out of a number of standard
>options.

We agree, and PKIX addresses this issue by requiring support for the 
cert policies extension. we can't mandate what CAs put in their 
policies, or even mandate that they use the extension, just that 
compliant implementations of CA and client (RP) software know ho to 
process it.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Dec 2007 16:56:41 -0800

[[ Forwarded for Ran; not sure why it didn't get to the PKIX list. ]]

Also, it seems that this issue and the associated perils should be
discussed in the security considerations.

[Having spent only few hours with this 140+ page document, I may have
missed a discussion of this issue. In this case, my apologies... but
still, this may mean that the discussion can be made more prominent.]

Hope that I dont get the entire pkix wg running after me with axes due to
this comment... :)

Ran

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir

---

From: Ran Canetti <[email-masked]>
Date: Fri, 14 Dec 2007 00:55:55 -0500 (EST)

Thx for the clarfication.
Perhaps some language can be added to the security considerations section 
that mentiones this issue and its importance to the security of 
applications.

Ran

On Thu, 13 Dec 2007, Stephen Kent wrote:

> These aspects of cert issuance criteria are represented via the CPS of the 
> issue and/or the policy under which the cert is issued. The issuer may choose 
> to include a policy OID in the cert policies extension, for the cert, and 
> even to include policy text (or a reference to the text) via the UserNotice 
> part of this extension. So, the bottom line is that PKIX already defines ways 
> for CAs to convey this info to relying parties, although we do not mandate 
> that CAs express this in the cert policies extension.
>
> As you noted above, proof of possession is part of our standard cert request 
> protocols, (CMC and CMP, and is a mandatory feature of both. Wether the CA 
> demands PoP is another fact that can be expressed in the CP or CMS.
>
> We agree, and PKIX addresses this issue by requiring support for the cert 
> policies extension. we can't mandate what CAs put in their policies, or even 
> mandate that they use the extension, just that compliant implementations of 
> CA and client (RP) software know ho to process it.
>
> Steve
>

---

From: "Mike Henry" <[email-masked]>
Date: Fri, 14 Dec 2007 08:41:15 -0500

Paul,

" While such behavior is harmless for the
security of typical authentication protocols such as IPSEC,TLS etc, it
can be disastrous in other situations."

Could you give some examples of the disastrous situations.

Mike Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Paul Hoffman
Sent: Thursday, December 13, 2007 7:57 PM
To: [email-masked]
Cc: Ran Canetti
Subject: Re: [secdir] security review of draft-ietf-pkix-rfc3280bis-09

   *security area directors.  Document editors and WG chairs should
treat

- Does the certificate attest that the certified owner has chosen the
key
with a good/accredited/certified random number generator?

sign/decrypt"? in the latter case, what's the exact protocol used and
what

the certificate of another entity. While such behavior is harmless for
the

Hope that I dont get the entire pkix wg running after me with axes due
to
this comment... :)

Ran

Important Notice: This email message and any attachments may contain information and/or trade secrets that are private, and are meant to be delivered solely for the use of the intended recipient(s). If you are not the intended recipient, please do not read, copy, use, forward or disclose the contents of this communication to others. Interception of e-mail is a crime under the Electronic Communications Privacy Act, 18 U.S.C. 2510-2522 and 2701-2709. If you have received this email in error, please immediately notify us by return email or by telephone at [703-221-0200 Ext 51119] and promptly delete this message. Thank You.

---

From: Ran Canetti <[email-masked]>
Date: Sat, 15 Dec 2007 15:06:13 -0500 (EST)

Mike,

Any protocol that uses public keys to identify participants, and 
implicitly assumes that different participants will have 
different/unrelated public keys would be susceptible to attack if the
CA does not verify posession of the secret key (or otherwise guarantees 
that public keys are unrelated to each other).

For more concrete examples - the MQV and STS key exchange protocols break
if the CA allows parties to register public keys without proving posession 
of the secret keys. (See examples in papers by Krawczyk from 2005 or 
Kaliski from earlier on.)

In contrast, the signature mode of IKE and the ISO 9798-3 key exchange 
protocols were proven to be secure even if the CA does not verify 
posession of the secret key.

It is also possible to concoct protocols that would remain secure if it 
is guaranteed that all public keys are chosen using good random sources, 
but would break if parties are allowed to register public keys that were 
chosen in funny ways --- even if a POP is performed. I'm not aware 
though of any existing protocols out there that have this property.

Ran

---

From: "Mike Henry" <[email-masked]>
Date: Sat, 15 Dec 2007 20:06:53 -0500

Ran,
 
Thank you for the thoughtful answer.
 
I have to admit though that I thought that in all 
authentication protocols the verifier used the 
demonstrated possession of the private
key related to the public key to authenticate claimants.That is 
to say, the private key identifies the claimant.
I can obtain Ran Canetti's public key easily and
claim to be Ran Canetti but my false claim will
be detected [not prevented] when I can not apply
a valid private key corresponding to the Ran Canetti 
public key.
 
I will review the pointers you gave to the MQV
and STS key exchange issue.
 
Mike Henry

________________________________

From: Ran Canetti [mailto:[email-masked]]
Sent: Sat 12/15/2007 3:06 PM
To: Mike Henry
Cc: Paul Hoffman; [email-masked]; Ran Canetti
Subject: RE: [secdir] security review of draft-ietf-pkix-rfc3280bis-09

Mike,

Ran

---

From: Ran Canetti <[email-masked]>
Date: Sat, 15 Dec 2007 21:26:23 -0500 (EST)

> a valid private key corresponding to the Ran Canetti

Yes, this is what one would expect. But turns out that with some 
protocols you may be able to break authentication even when you dont have 
Ran Canetti's private key --- as long as the CA neglects to verify 
knowledge of secret key when you registered Ran Canetti's public key 
under your name.

This does not of course mean that a CA must always verify such knowledge.
but it should be clear, given a certificate, whether knowledge of the 
secret key was verified (and how).

Ran

> > I will review the 
pointers you gave to the MQV > and STS key exchange issue.