RE: OCSP response pre-production

["Miguel Rodriguez" <mars@xxxxxxxxxxxxxx>]

Please dismiss my previous posting where I question a server generated
nonce to avoid scenario 1.2. I completely agree with Florian's view.

Miguel A Rodriguez
SeguriDATA
Mexico
  
> > -----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.]
> > > >
> > > >
> > > >
> > >
> > >
> >