RE: OCSP response pre-production

["Manger, James H" <James.H.Manger@xxxxxxxxxxxxxxxx>]

Nice solution, Florian.


Adding a nonce at the server when the client didn't include one *sounds* silly.  A different way of describing the same solution would be...

A server that can handle nonces should indicate this ability when responding to a request that did not include a nonce.  One way to indicate this is to include a nonce in the response.
Note: the same "nonce" can be included in every response to requests without nonces.  This still allows responses to nonce-less requests to be cached.  It might even be worth defining a "standard" "nonce" for this purpose (eg a empty octet string or a single 0x00 byte).

Responses from cache-only OCSP systems will not include the nonce extension.
Responses from other (nonce-capable) OCSP systems will include the nonce extension (populated with the request's nonce if present or some "dummy" value otherwise).

This allows clients to distinguish cache-only OCSP systems from the others.  Consequently, clients can be configured to ask for the freshest possible response (include a nonce) but accept nonce-less responses **only if** that is the best the system has to offer.  An attacker cannot make a nonce-capable system look like a cache-only system.



----------
From: Florian Oelmaier [mailto:oelmaier@xxxxxxxxxxx]
Sent: Saturday, 27 September 2003 7:29 AM
To: 'Deacon, Alex'; 'Michael Myers'; 'David Engberg'
Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; ietf-pkix@xxxxxxx; 'Russ
Housley'; 'Stephen Kent'; 'Tim Polk'
Subject: RE: OCSP response pre-production

> 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

> 
> 
> > -----Original Message-----
> > From: Florian Oelmaier [mailto:oelmaier@xxxxxxxxxxx]
> > Sent: Friday, September 26, 2003 10:37 AM
> > To: 'Michael Myers'; 'David Engberg'
> > Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; ietf-pkix@xxxxxxx; '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
> > 
>