> > >> Let me try hard to think intelligent: We have a PKI. All people
> > >> share the same time (i.e. using NTP). Our CA generates
> > >> OCSP-responses for its 10 Sub-CAs every 2 minutes with a
> > >> "nextUpdate" interval of 2 minutes. As OCSP-Responses for Sub-CAs
> > >> are used very frequently they will be distributed all over our
> > >> company every 2 Minutes to 30-50 central webservers that answer
> > >> OCSP-responses.
> >
> > > Those are *your* conditions. You might as well get responses that
> > > have "nextUpdate" intervals of an hour!
> >
> > His point, I think, is that under these conditions the OCSP responders
> > *can't* include the client nonce. (They don't sign the responses
> > themselves.)
> >
>
> Then why can't it send the nonce for inclusion to whatever does sign the
> response?
Because in this case, the responses will be pre-produced (as it is specified
and allowed in RFC 2560 - chapter 2.5) at a central responder (and therefore
pre-signed).
These responses will then be distributed to many Web-Servers (not
necessarily OCSP-Responders, see (*)!) that only distribute them. Security
will be ensured using the time-stamps of the pre-produced response - thus
invalidating the pre-rpoduced responce after a few minutes.
This maybe necessary if you have a CA with only a few "users" (speak:
certificates) but a lot of OCSP-requests. This is the case for a root CA. It
has only few Sub-CAs, but every time when any certificate in the whole PKI
will be checked, while verifying the certificate-path the client will
generate an OCSP-request to the responder of the root-CA to verify the
Sub-CA certificate.
(*) BAD-GUY-HOWTO: how to abuse a webserver as OCSP-Responder:
OCSP is only a HTTP-GET and can be answered by any Webserver, given the
correct configuration. Do the following: Give every certificate a different
AIA, speak: a different GET-URL´s. Then ignore the actual request-data at
the server and always replying with the preproduced response for this URL.
Combined with a good DNS-Load-Balancing the fastest OCSP-responder you can
get. You can call this setup: "abusing the possibility of replay-attacks for
good".
> So the best we can probably do to check nonces is:
>
> 1. Check the nonce if it is present in both request and response.
> 2. If the request does not include a nonce don't check the response
> (i.e. tolerate nonce-less and nonce responses).
> 3. Otherwise reject it.
>
> If any responders don't process the nonce value then the request can
> either not send one in the request or not check it in the response for
> those particular responders.
>From a security standpoint of view: You are right. But the problem is,
client configuration is a nasty bitch. It´s hard to reconfigure a client if
you change the usage of pre-produced responses.
So the best we can probably do to check nonces is:
1. Always send a nonce in your request.
2. Check the nonce if it is present in both request and response.
3. If there is no nonce in the response, accept it and (only then)
check the timestamping (weaker replacement for nonce).
Clearly document, that every OCSP-responder SHALL send nonce if possible. If
it does not THE RESPONDER will expose itself to a replay attack. If any
PKI-designer in the world does this, he will have a good requirement for it.
In this special case, OPENSSL will help him in establishing a similar
security policy by checking the timestamps.
Remember: If an OCSP-Responder ALWAYS sends responses comprising nonce - IT
IS NOT VULNERABLE to any replay-attack against any client that sent nonces,
too.
Do it this way and:
- a well configured responder and openssl will never have security problem
- in case of a misconfiguration of the responder the security is gone (do
you know how many ways you can misconfigure an OCSP-Responder? :-))
- openssl clients cannot be misconfigured (a client NOT sending nonce IS
misconfigured, I cannot think of any cause why a client wants to omit
nonce!)
- in case of a deliberate omission of nonce in a responder, openssl alway
has the time checking feature as a fallback
- timestamping will not be a general problem, but only in PKI-systems not
sending nonces
--
Dipl.Inf. Florian Oelmaier
IT Security Development
syTrust S.A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
