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

Re: OCSP response pre-production

If I may attempt to add my 2 cents, the RFC says that

"If nextUpdate is not set, the responder is indicating that newer
revocation information is available all the time."

The behavior of our (experimental) client currently is:

1) We send a nonce
	1.1) We get a nonce back
		=> We check the nonce
	1.2) We do not get a nonce back
		=> We check "nextUpdate", if absent, we reject, as a
		live responder should really provide a nonce, if present
		we assume the responder is keyless or proxy and we check
		the local clock thingies

2) We do not send a nonce
	Whether we get a nonce back or not.
		=> We check "nextUpdate", if absent, we know very well
		that we could be subject to an replay attack, we decide
		based on user config (I would tend to reject but we
		kinda looked for it...), if present, we also know we could
		be subject to a replay attacka (as in 1.2 actually) but
		about as bad as what we have with CRLs, so we accept
		after checking the local clock thingies

If the two sets [Nonce-capable server] and [live servers] are the
same and if they are respecting the above RFC quote, the replay attacks
seem to be minimized by the above client behavior. Also, we play fairly
nicely with keyless and proxy responders.

The only thing we really do not accept is a "live" server pretending
it is unable to include nonces...

Now, the question is whether the distinction between "live" and
"caching" servers can actually be made (in real life) from the
"nextUpdate" field as indicated by the RFC above quote?

--
Julien


On Tue, Sep 30, 2003 at 08:23:33AM -0700, Ambarish Malpani wrote:
> 
> 
> Hi Florian, Denis,
>     The proposal also adds not-very-desirable semantics to requests
> being made by existing clients.
> 
> All clients today that make requests with nonces expect those nonces to
> come back in the response. With the semantics below, todays clients would
> be indicating that it is okay to get a response w/o the nonce.
> 
> 
> I think we are adding a lot of meaning in the nonce extension. My original
> rationale for nonces was to allow a client to force a response to its
> request
> and thus prevent any chance of a reply. This leaves the options very simple:
> 
> - If you (the client) want a fresh response, include a nonce in the request.
> - If you don't care whether the response is fresh or not, exclude a nonce
> 	in the request (and therefore, don't check to see whether there is a
> nonce
> 	in the reply or not - the cached response that you get back might
> have been
> 	generated for an earlier request that did contain a nonce)
> 
> Yes, this doesn't cover all the possible options, but it doesn't add a lot
> of complications to the protocol. As a client, if I do want to support all
> the cases identified by Florian below, I can still do it - potentially at
> the
> cost of a couple of requests.
> 
> Regards,
> Ambarish
> 
> 
> > -----Original Message-----
> > From: owner-ietf-pkix@xxxxxxxxxxxx 
> > [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Denis Pinkas
> > Sent: Tuesday, September 30, 2003 12:41 AM
> > To: Florian Oelmaier
> > Cc: ietf-pkix@xxxxxxx
> > Subject: Re: OCSP response pre-production
> > 
> > 
> > 
> > Florian,
> > 
> > I have no problem with the new flow chart you propose below.
> > 
> > Making the nonce extension critical or not in the request, as 
> > you propose in 
> > another e-mail, is a good proposal since it does not involve 
> > an ASN.1 module 
> > change (if can avoid a new error code), but only 
> > "clarifications" in the text.
> > 
> > It has the additional advantage of satisfying the "downgrade 
> > to cache-only 
> > iff that is all that is available", as requested by James.
> > 
> > Denis
> > 
> > 
> > > I think a client should definitely and in every case reject 
> > a response 
> > > with a mismatching nonce. This is covered in RfC2560 in its current
> > > form: mismatching nonce => reject.
> > > 
> > > So allow me to rephrase again based on your proposal:
> > > 
> > > A) always includes a nonce into his request;
> > > B) checks the nonce in the response:
> > > 
> > >      - if it matches with the nonce from the request, then accept
> > >        the response (pending other checks),
> > > 
> > >      - if it does not match with the nonce from the request, then
> > >        reject the response
> > > 
> > >      - if nonce is not present, then are a local trusted time 
> > >        available and a policy for cache responses both available ?
> > >  
> > >           - if both a local trusted time is available and 
> > there exists
> > >             a policy for cache responses, then compare the time
> > >             difference between that local trusted clock and the
> > >             producedAt field from ResponseData. If that 
> > time difference
> > >             is below the limit stated by that policy, then 
> > accept the
> > >             response (pending other checks).
> > > 
> > >           - if not, then reject the response.
> > > 
> > > 
> > > [Additionally we add some checks:
> > > 
> > > i) if nextUpdate is present and is lower than the current date from 
> > > our trusted clock before sending the request, we detected a clock 
> > > problem in our "trusted" clocks.
> > > 
> > > ii) if thisUpdate is too old for our limit stated in the policy we 
> > > reject the answer, too.
> > > 
> > > iii) additionally some sanity checks: 
> > > thisUpdate<=producedAt<=nextUpdate
> > > 
> > > I have to double check, but I think thats all we do.]
> > 
> > 
> > 
> 
>