Subject: [pkix] OCSP - revoked stte for non-issued certificates

From: "Erik Andersen" <[email-masked]>
Date: Tue, 1 Apr 2014 10:50:52 +0200

Hi Folk,

In the last paragraph of section 5 of RFC 6960, it is mentioned a possible
threat when  the status "revoked" is issued for a certificate alter to be
issued.

How can an attacker utilize this situation?

The answer is probably buried somewhere in the hundreds of emails on
2560bis.

Erik

---

From: Denis <[email-masked]>
Date: Tue, 01 Apr 2014 12:02:16 +0200

Hi Erik

RFC 6960 was supposed to be better than RFC 2560. Unfortunately this is 
not the case.
I still consider RFC 2560 (which unclear on many points) better than RFC 
6960, since it added text
that is incompatible with the documents from the CAB (CA Browser Forum).

Would you be able to quote the sentence that you don't fully understand ?

Denis

> Hi Folk,
>
> In the last paragraph of section 5 of RFC 6960, it is mentioned a 
> possible threat when  the status "revoked" is issued for a certificate 
> alter to be issued.
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 1 Apr 2014 12:51:23 +0200

Hi Denis,

Did you change your email address?

The start of the last paragraph of section 5 says:

Responding with a "revoked" state to a certificate that has never

been issued may enable someone to obtain a revocation response for a

certificate that is not yet issued, but soon will be issued, if the

certificate serial number of the certificate that will be issued can

be predicted or guessed by the requestor.

So, assume I am  bad guy. I have gotten hold of a OCSP response saying
"revoked" for  certificate about to be issued. How can I use that response
to do nasty things?

Regards,

Erik

From: pkix [mailto:[email-masked]] On Behalf Of Denis
Sent: Tuesday, April 01, 2014 12:02 PM
To: [email-masked]
Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates

Hi Erik

RFC 6960 was supposed to be better than RFC 2560. Unfortunately this is not
the case.
I still consider RFC 2560 (which unclear on many points) better than RFC
6960, since it added text 
that is incompatible with the documents from the CAB (CA Browser Forum).

Denis

Hi Folk,

Erik

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

---

From: Denis <[email-masked]>
Date: Tue, 01 Apr 2014 14:37:43 +0200

Hi Erik,

I have some difficulties to think that you might be a bad guy ... so you 
will play the role of the good guy.

Suppose that you (as an honest client), don't use the nonce extension 
and that the OCSP server uses
pre-computed responses. Let us suppose that OCSP responses are valid for 
12 hours.

Some one else (the bad guy) has guessed in advance the serial number of 
a certificate that will be issued.
He makes an OCSP request and gets back a revoked status. The OCSP server 
places that response in a cache,
in case someone else would make the same request. It happens that you 
are that "some one else".

It is likely that you might get that cached pre-computed response, since 
the text is silent about the way
cached responses and pre-computed responses are managed.

Rather than getting a good status, you will get a revoked status.

Some one else could say that the third paragraph from the same section 
addresses the concern.

Let us first quote that paragraph:

    The use of precomputed responses allows replay attacks in which an
    old (good) response is replayed prior to its expiration date but
    after the certificate has been revoked.  Deployments of OCSP should
    carefully evaluate the benefit of precomputed responses against the
    probability of a replay attack and the costs associated with its
    successful execution.

The text comes from RFC 2560 and has not been updated.

The case described above is the replay of an old (revoked) response, 
which is not addressed
in the paragraph quoted above, since it only addresses the case of an 
old (good) response.

Erik, you are right to notice that the security considerations section 
is missing to provide sufficient guidance.

Denis

> "revoked" for certificate about to be issued. How can I use that 
> response to do nasty things?
>
> Regards,
>
> Erik
>
> *From:*pkix [mailto:[email-masked]] *On Behalf Of *Denis
> *Sent:* Tuesday, April 01, 2014 12:02 PM
> *To:* [email-masked]
> *Subject:* Re: [pkix] OCSP - revoked stte for non-issued certificates
>
> Hi Erik
>
> RFC 6960 was supposed to be better than RFC 2560. Unfortunately this 
> is not the case.
> I still consider RFC 2560 (which unclear on many points) better than 
> RFC 6960, since it added text
>     possible threat when  the status "revoked" is issued for a
>     certificate alter to be issued.
>
>     The answer is probably buried somewhere in the hundreds of emails
>     on 2560bis.
>
>     Erik
>
>
>
>

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 1 Apr 2014 14:46:05 +0200

Hi Denis,

Thanks for your response. It was useful.

It looks like an additional reason for using non-sequential sequence
numbers.

Regards,

Erik

From: pkix [mailto:[email-masked]] On Behalf Of Denis
Sent: Tuesday, April 01, 2014 2:38 PM
To: [email-masked]
Subject: Re: [pkix] OCSP - revoked state for non-issued certificates

Hi Erik,

Suppose that you (as an honest client), don't use the nonce extension and
that the OCSP server uses 
pre-computed responses. Let us suppose that OCSP responses are valid for 12
hours.

Some one else (the bad guy) has guessed in advance the serial number of a
certificate that will be issued.
He makes an OCSP request and gets back a revoked status. The OCSP server
places that response in a cache, 
in case someone else would make the same request. It happens that you are
that "some one else". 

It is likely that you might get that cached pre-computed response, since the
text is silent about the way 
cached responses and pre-computed responses are managed. 

The case described above is the replay of an old (revoked) response, which
is not addressed 
in the paragraph quoted above, since it only addresses the case of an old
(good) response.

Erik, you are right to notice that the security considerations section is
missing to provide sufficient guidance.

Denis

Hi Denis,

Regards,

Erik

From: pkix [mailto:[email-masked]] On Behalf Of Denis
Sent: Tuesday, April 01, 2014 12:02 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [pkix] OCSP - revoked stte for non-issued certificates

Hi Erik

Denis

Hi Folk,

Erik

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 1 Apr 2014 13:49:56 +0000

An attacker with the ability to replay OCSP responses to a victim can collect "revoked" responses (assuming no nonce) for not-yet-issued serial numbers and then replay them to a victim after those certificates are issued causing the victim to reject those certificates.  

At the lowest impact, this is simply disruptive.  

At medium impacts, it could be used as a DoS against the PKI or Subscribers.  

At worst I could conceivably use this as part of a key rollover attack, where I convince the victim that the legitimate certificate is revoked and open the door for the victim to accept a fraudulent certificate as valid--permitting future mischief.  This would be an interesting way to attack systems that use certificate pinning.

-- T

>-----Original Message-----
>From: pkix [mailto:[email-masked]] On Behalf Of Erik Andersen
>Sent: Tuesday, April 01, 2014 5:51 AM
>To: [email-masked]
>"revoked" for  certificate about to be issued. How can I use that response to
>do nasty things?
>
>
>
>Regards,
>
>
>
>Erik
>
>
>
>I still consider RFC 2560 (which unclear on many points) better than RFC 6960,
>since it added text
>possible threat when  the status "revoked" is issued for a certificate alter to
>be issued.
>
>
>

---

From: "Erik Andersen" <[email-masked]>
Date: Tue, 1 Apr 2014 16:13:18 +0200

Hi T,

Thanks for the information. Also very useful.

Regards,

Erik

-----Original Message-----
From: Miller, Timothy J. [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2014 3:50 PM
To: 'Erik Andersen'; [email-masked]
Subject: RE: [pkix] OCSP - revoked stte for non-issued certificates

An attacker with the ability to replay OCSP responses to a victim can
collect "revoked" responses (assuming no nonce) for not-yet-issued serial
numbers and then replay them to a victim after those certificates are issued
causing the victim to reject those certificates.  

At worst I could conceivably use this as part of a key rollover attack,
where I convince the victim that the legitimate certificate is revoked and
open the door for the victim to accept a fraudulent certificate as
valid--permitting future mischief.  This would be an interesting way to
attack systems that use certificate pinning.

-- T

>RFC 6960, since it added text that is incompatible with the documents 
>from the CAB (CA Browser Forum).
>