Re: [pkix] Proposal for OCSP vulnerability

["Dr. Massimiliano Pala" <[e-mail]>]

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:
> 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.
>
>
>
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix