Subject: [pkix] Proposal for OCSP vulnerability

From: Koichi Sugimoto <[email-masked]>
Date: Tue, 4 Nov 2014 19:08:39 +0900

Hello.

I am considering about vulnerability of OCSP.
Do you have any ideas for the following?

Introduction:

OCSP is a vulnerable protocol because client can send OCSP request WITHOUT
digital signature, on the other hand, server has to send back the
corresponding response WITH digital signature.
OCSP server has to generate digital signature every time creating OCSP
response if OCSP caching scheme cannot be applicable.
This kind of biased processing between client and server would make server
load becomes high, it makes easy for attacker to force OCSP server down as
DOS.
Indeed OCSP caching described in RFC 5019 can reduce the load of OCSP
server, but, OCSP responses for non-issued certificates cannot be cached,
if the attacker generates random serial number and put it in the OCSP
request, such caching logic will be collapsed.
This proposal is one of the solutions to cope with this kind of attack.

Overview of idea:

If client (relying party) sends actual certificate to be validated, then,
it has signature created by the CA.
By validating the signature, OCSP responder knows whether the certificate
was acutally issued by the CA or not.
The number of certificates is limited, the OCSP responder can cache the all
ocsp responses (if no nonce).
If the OCSP responder does not know the status of the certificate, the OCSP
responder can conclude such certificate was unreasonably issued or missed
from CA.
On the other hand, the client only needs to know the status of certificate
that owned by the client.
In this way, if OCSP is defined by existing of actual certificate, DOS
attack like above can be avoidable.
Validating certificate signature also need public key operation, we can
introduce more light operation like cryptographic hash algorithm.

Detailed example for proposal:

[X.509 V3 extension]
strictCollationExtension = any collation value generated by CA.
ex) strictCollationExtension = HASH( certificateSerialNumber || secretValue
owned by CA)
, where || means concatenation operation.

[Precondition]
Client to send OCSP request has EE certificate to be validated.

[Client responsibility]
Client has to send OCSP request with strictCollationExtension value if it
needs OCSP response even for unreasonable certificate.
Such extension value should be embedded into OCSP request extension.

[OCSP server responsibility]
OCSP server has to send back the corresponding OCSP response by collating
the extension value.
If the extension value matches the calculated value, OCSP server has to
send strict status value good/revoked/unknown.
If the extension value does not match to calculated value, OCSP server can
send error such as malformedRequest / unauthorized.

Consideration on server side:

OCSP server can cache (even pre-generate) OCSP responses for known
certificates.
Even if the target certificate information was not in the database, the
number of such certificates seems to small, the operation load must not
high. After creating OCSP response(s), such information can be cached.

Matching operation for the strictCollationExtension is very light, the load
of OCSP server is low.

If the extension value does not match to the calculated value, the OCSP
server does not need to sign the response, the load is also low.

Consideration on client side:

If client received signed response, by validating the signature, client
knows whether the response is reliable or not.
If the response is reliable, the client can judge the actual certificate
staus including unreasonable certificate.
If the client received unsigned response such as malformedRequest /
unauthorized, the response was either from unauthorized OCSP responder
or the strictCollationExtension value was invalid (may be hacked by some
attacker).

Regards,
Koichi Sugimoto.

---

From: "Dr. Massimiliano Pala" <[email-masked]>
Date: Mon, 10 Nov 2014 16:36:06 -1000

Hi Koichi, all,

Personally I do not consider this to be a real issue.

Indeed, although it is true that there might be a lack of symmetry about 
signatures in requests and responses, most of today's OCSP responses are 
pre-computed and provided via CDNs. Also, other mechanisms are being 
deployed (OCSP stapling) that reduce the dependency over the OCSP 
server. Additionally, other proposals exists that would provide OCSP 
over other transport mechanisms (like DNS).

Just my 2 cents...

Cheers,
Max

On 11/4/14, 12:08 AM, Koichi Sugimoto wrote:
> OCSP is a vulnerable protocol because client can send OCSP request 
> WITHOUT digital signature, on the other hand, server has to send back 
> the corresponding response WITH digital signature.
> This kind of biased processing between client and server would make 
> server load becomes high, it makes easy for attacker to force OCSP 
> server down as DOS.
> server, but, OCSP responses for non-issued certificates cannot be 
> cached, if the attacker generates random serial number and put it in 
> the OCSP request, such caching logic will be collapsed.
> If client (relying party) sends actual certificate to be validated, 
> then, it has signature created by the CA.
> By validating the signature, OCSP responder knows whether the 
> certificate was acutally issued by the CA or not.
> The number of certificates is limited, the OCSP responder can cache 
> the all ocsp responses (if no nonce).
> If the OCSP responder does not know the status of the certificate, the 
> OCSP responder can conclude such certificate was unreasonably issued 
> or missed from CA.
> On the other hand, the client only needs to know the status of 
> certificate that owned by the client.
> Validating certificate signature also need public key operation, we 
> can introduce more light operation like cryptographic hash algorithm.
>
>
> ex) strictCollationExtension = HASH( certificateSerialNumber || 
> secretValue owned by CA)
> Client has to send OCSP request with strictCollationExtension value if 
> it needs OCSP response even for unreasonable certificate.
> OCSP server has to send back the corresponding OCSP response by 
> collating the extension value.
> If the extension value matches the calculated value, OCSP server has 
> to send strict status value good/revoked/unknown.
> If the extension value does not match to calculated value, OCSP server 
> can send error such as malformedRequest / unauthorized.
>
>
> Even if the target certificate information was not in the database, 
> the number of such certificates seems to small, the operation load 
> must not high. After creating OCSP response(s), such information can 
> be cached.
>
> Matching operation for the strictCollationExtension is very light, the 
> load of OCSP server is low.
>
> If the extension value does not match to the calculated value, the 
> OCSP server does not need to sign the response, the load is also low.
>
>
> If client received signed response, by validating the signature, 
> client knows whether the response is reliable or not.
> If the response is reliable, the client can judge the actual 
> certificate staus including unreasonable certificate.
> or the strictCollationExtension value was invalid (may be hacked by 
> some attacker).
>
>
> Regards,
> Koichi Sugimoto.
>
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix