Subject: RE: OCSP response pre-production

From: "Deacon, Alex" <[email-masked]>
Date: Fri, 26 Sep 2003 14:11:40 -0700

Florian,

I don't understand how adding a server generated nonce would help in this
situation.  How does this help the client protect against replay attacks?

Alex

> -----Original Message-----
> From: Florian Oelmaier [mailto:[email-masked]]
> Sent: Friday, September 26, 2003 10:37 AM
> To: 'Michael Myers'; 'David Engberg'
> Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; [email-masked]; 'Russ
> Housley'; 'Stephen Kent'; 'Tim Polk'
> Subject: RE: OCSP response pre-production
> 
> 
> 
> [...]
> 
> > Thus "Maybe the nonce is incorporated, maybe not" is 
> > equivalent to NOT sending a nonce in the first place.  Which 
> > rather defeats the purpose of sending a nonce.
> 
> Thats true. But this can be "cured"! If an OCSP-Responders 
> that is able
> to use nonces, detects a request without nonce, he simply includes a
> self-generated nonce into his response. Thus an attacker is 
> not able to
> obtain a response without nonce from this particular 
> responder. Thus he
> cannot fool the client with a replay attack.
> 
> The client behaviour you describe is exactly the reason why our
> responder (in its default configuration) will currently 
> ALWAYS include a
> nonce into the response (even at the cost of generating one 
> by itself).
> 
> This way nonces are of value when used with a responder being able to
> use them while simultaneous allowing response pre-production.
> 
> -- 
> Florian Oelmaier
> SyTrust
>

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 26 Sep 2003 23:29:00 +0200

> Florian,
> 
> I don't understand how adding a server generated nonce would 
> help in this situation.  How does this help the client 
> protect against replay attacks?
> 
> Alex

Client Type I) Given you have a client with the following behaviour:
A) always includes a nonce into his request
B) accepts responses without nonce

If an attacker is able to get a response without nonce from a responder,
he can replay that response to your client and the client will accept it
(rule B). So we have to ensure, that the attacker is NOT able to get a
response without nonce. Thus we simply add a server-generated nonce to
every response not already having a copy of a request-nonce.

This way, an attacker cannot get a response without a nonce. In
conclusion he can not get data to fool your client.

Client Type II) Given you have a client with the following behaviour:
A) does not includes a nonce into his request

A server generated nonce does not help this client anything (but also
does not harm it). He is in every case in danger of replay attacks.
(BTW: an attacker would use such a client to get a response without
nonce from your OCSP responder.)

Client Type III) Given you have a client with the following behaviour:
A) always includes a nonce into his request
B) does NOT accept responses without nonce

This client is never subject to a replay attack. A server generated
nonce does not improve anything (but also does not harm it).

So the proposed server-generated nonces are simply a mechanism to allow
Client Type I operate securely. I fully agree with you, that such a
client behaviour (accepting responses without nonce) seems to be
desirable from an operating point of view.

-- 
Florian Oelmaier
SyTrust

> ALWAYS include 
> > a nonce into the response (even at the cost of generating one
> > by itself).
> >

---

From: "Miguel Rodriguez" <[email-masked]>
Date: Fri, 26 Sep 2003 17:51:59 -0500

Cached (pre-produced) responses can be treated as CRLs (checked for time
validity using the ThisUpdate and NextUpdate fields). We don't worry
about replay attacks when using CRLs. 

If we want to enable the client to work with both fresh and cached
responses we could include a nonce in the request and accept responses
without it. Of course this means that we are giving up prevention
against replay attacks. This prevention only makes sense for fresh
responses. The bad scenario is a replay attack for fresh responses, how
can we avoid it? Maybe by having a way to distinguish fresh responses
from cached ones. Then the client can reject a fresh response without
the nonce included in the request. 

Opinions are welcomed,

Miguel A Rodriguez
SeguriDATA 
Mexico