[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: OCSP response pre-production
Thanks, Julien!
First: I love your client behaviour and your nextUpdate checking is
cool.
Second: SyTrust ValidationWorks shows a similar behaviour in its default
configuration. So I am not alone out there. Hipp Hipp Hurray :)
We understood the RfC the same way and I like the flexibility of this
approach.
And if a responder wants enforce nonce-checking on your client, it can
simply include a server-generated nonce into all responses. Thus an
attacker cannot get a response out of this OCSP responder that would
force your client into 1.2.
--
Florian Oelmaier
SyTrust
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Julien Stern
> Sent: Tuesday, September 30, 2003 6:26 PM
> To: ietf-pkix@xxxxxxx
> Subject: 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.]
> > >
> > >
> > >
> >
> >
>