[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: DISCUSSION: Nonce-specific error code for OCSP
> It seems to me that an extended response is no improvement
> upon a plain response when applied to replay detection. It
> too can be replayed because there is no dynamic binding
> between request and response. That's what the nonce
> extension was defined to
> enable: client-side elimination of replay risks via dynamic binding.
The response can be replayed. Thats true. But the client now has a way
of dectecting if the responder supports nonces. So the client will ask
itself: Why should I accept a response without nonce from a responder
that supports nonce? Coming to the conclusion that something is wrong
the client can now disregard the response.
Today, when a client sends a request with nonce and gets a response
without nonce that can mean:
A) the responder does not support nonces
B) the responder would support nonces but this is a replay (the attacker
is replaying the response to a request without nonce)
With either one of the proposed extensions, the client would get a
secure method of differentiation between these two cases.
Imagine an attacker now recording an OCSP response to a request without
nonce and replaying this response to another request with nonce. With
the proposed extensions, the replayed response contains information
saying that this responder usually supports nonces. Thus the client will
reject the response, as it did not contain a nonce but the responder
simultaneous indicates that it would support nonce generation.
> Further, the requestor which sent a nonce and received a
> non-nonced response can today infer "responder does not
> support nonces." Something like 11 of 12 client side
> implementors claim ability to detect such. Inclusion of an
> extension which in effect asserts that "I as responder give
> myself permission to disregard your nonce" does nothing to
> improve upon that.
I know that 11 of 12 client side implementors think they can infer such
a conclusion. But - sad to say - this conclusion is not necessarily true
in the current state of RfC2560. The response could also be a replay of
a response to a request without nonce. Thats why we need the extension
(or server-generated nonces as a work-around).
So the inclusion of an extension saying that "I AS RESPONDER give myself
permission to disregard your nonce" has a real value. It indicates that
the responder KNOWS that this response may be used in replay or caching
situations. It is a lot better than the current situation. Currently a
response without nonce asserts that "I as responder OR ATTACKER give
myself permission to disregard your nonce".
I hope that clarifies why we want something to the effect of this
proposal so urgently.
--
Florian Oelmaier
SyTrust