[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: DISCUSS: MUST reject in OCSPv1



comments in-line


From: David Engberg
Sent: Fri 12/5/2003 11:17 AM
To: Ryan M. Hurst
Cc: liaquat.khan@xxxxxxxxxxxx; 'Florian Oelmaier'; ietf-pkix@xxxxxxx
Subject: Re: DISCUSS: MUST reject in OCSPv1

Unfortunately, I think the anwer to Ryan's specific question is no.  If 
you send a nonce and get back a response without that nonce under the 
current spec, you know either:

   a)  The server does not support nonces
   b)  An attacker is replaying a recorded response from a 
nonce-supporting server
[rmh] This is absolutley true, but in either of these cases if the client is attempting to protect against replay he would reject responses in both a and b. And in not he wanted the "replay" (eg he wants caching wherever he can get it)
I think there needs to be another flag in the response (e.g. 
nonceUnsupported extension) to securely separate 'a' from 'b'.
[rmh] But what prevents the nonce unsupported response from being replayed?

Ryan M. Hurst wrote:

>   1.
>       What the responder returns if it can not return a nonce
>   2.
>       What the client must do when it receives a response to a nonced
>       request
>
...

> My take on #1 is that I don't see why the client needs to know that, 
> after all if the response to a nonced request does not contain the 
> same nonce doesn't that mean the server was unable to produce a nonced 
> response?