Subject: RE: OCSP response pre-production

From: "Manger, James H" <[email-masked]>
Date: Mon, 29 Sep 2003 10:36:25 +1000

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:[email-masked]]
Sent: Saturday, 27 September 2003 7:29 AM
To: 'Deacon, Alex'; 'Michael Myers'; 'David Engberg'
Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; [email-masked]; '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:[email-masked]]
> > Sent: Friday, September 26, 2003 10:37 AM
> > To: 'Michael Myers'; 'David Engberg'
> > Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; [email-masked]; '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
> > 
>

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 29 Sep 2003 12:03:16 +0200

(...)

[Florian]

> B) accepts responses without nonce

(...)

[James]

> desirable from an operating point of view.

If a client Type I "accepts responses without nonce" (i.e. "B condition") 
then a nonce generated by the server is ignored by the client and thus does 
not help, and "do NOT allow Client Type I operate securely".

Denis

---

From: "Florian Oelmaier" <[email-masked]>
Date: Mon, 29 Sep 2003 17:15:12 +0200

> not help, and "do NOT allow Client Type I operate securely".

Why should the client *ignore* the nonce? The client will check the
nonce when it is included in the response while simultaneous accepting
responses without nonce. Although I have not tested it, I dont think any
client out there that accepts nonce-less responses to his nonce-requests
IGNORES the nonce. After all a mismatching nonce definitely indicates a
replay attack while a response without nonce just indicates no
protection against replay attacks.

This way the responder can decide wether to protect the client against
replay attacks (through server-generated nonces).

So allow me to define the behaviour of "Client Type I" more clearly:
A) always includes a nonce into his request
B) checks if the nonces match if the response included a nonce
C) accepts responses without nonce

-- 
Florian Oelmaier
SyTrust

PS: -> James: To allow replay protection, a pre-defined nonce would not
help. So in my scenario it should be the usual non-predictable random
string.

---

From: "Florian Oelmaier" <[email-masked]>
Date: Mon, 29 Sep 2003 18:06:30 +0200

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.]

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 29 Sep 2003 17:44:52 +0200

Florian,

>>If a client Type I "accepts responses without nonce" (i.e. "B 
>>condition")then a nonce generated by the server is ignored by 
 >>the client and thus does not help, and "do NOT allow
 >>Client Type I operate securely".

> protection against replay attacks.

No, this is not as simple. What you say is true, if only real-time responses 
are being used. Since we also want to allow for cached-responses, the story 
is a litte more complicated.

> C) accepts responses without nonce

Not exactly. Proposed rephrasing for a "Client Type I":

       - if it does not match with the nonce from the request or if it
         is not present, then are a local trusted time available and
         a policy for cache responses both available ?

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 29 Sep 2003 12:14:06 -0700

All,

We have discovered a hole.  To give it a name let's call it
Nonce Capability Discovery.  This hole will not be filled by
artful requirements language alone.  We need proposed technical
components: a few bits of ASN.1 and associated semantics.

Mike

---

From: "Florian Oelmaier" <[email-masked]>
Date: Tue, 30 Sep 2003 01:58:17 +0200

> components: a few bits of ASN.1 and associated semantics.

So we need some additional signalling between client and responder. I
tried to list all the items a client would like to signal to the
responder and the other way round.

The client has 3 options that he would like to signal to the responder:
A) Client will accept a pre-produced/cached response. 
B) Client wants to get a custom-made response, but will also accept a
pre-produced/cached response.
C) Client wants to get a custom-made response and will not accept
pre-produced/cached responses.

A responder has 5 options that he would like to signal to the client:
1) Responder wants others to be able to cache (replay) this response
2) The response is a cached copy from another soure or was pre-produced
3) This is a custom-made response to a particular request (this
obviously includes 4)
4) This particular response should not be used in any type of caching
(replaying) 
5) Error: This Responder cannot produce custom-made responses

What about the following proposal (numbers corresponding to the signals
above):

A) Client does not include nonce into request.
B) Client includes nonce into request.
C) Client includes nonce into request and marks it CRITICAL.

1) Responder does not include nonce into response.
2) Responder does not include nonce into response.
3) Responder copies the nonce of the request into the response
4) If the request did not contain a nonce, the responder generates a
nonce for the response
5) We add a new error code 7: "Nonce extension cannot be processed"

Advantage: We only need to change minor things in the RfC:
- allow for CRITICAL on extensions
- add a new error code
- add some clarifications / text.

Disadvantage of this proposal: 
- we miss the opportunity to signal the "source of validation" - CRL vs.
fresh/live data.
- We cannot distinguish 1) and 2).

-- 
Florian Oelmaier
SyTrust

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 29 Sep 2003 17:21:48 -0700

The problem I am seeing with the proposals that it is OK for the 
responder to send nonce-less responses to queries with nonces is that 
it allows a man-in-the-middle to perform a fairly trivial replay 
attack. A sophisticated man-in-the-middle might capture every 
request, strip out the nonce (and signature, if any), pass it on to 
the server, and then send back all the responses with no nonces, so 
that the client expects no nonces from the server and won't be at all 
suspicious when snookered with a replay attack.

If we go for the minority proposal of allowing responders to ignore 
nonces in the queries, we will certainly need to beef up the Security 
Considerations section, and probably section 4.4.1 as well.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 30 Sep 2003 09:40:49 +0200

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

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 30 Sep 2003 08:08:03 -0700

All,

I was talking to some folks offlist on this subject yesterday
and thought I might ask if it's possible we could all get behind
the following simple fix.

SYNTAX:     Expand v1 OCSPResponseStatus syntax to
            include (7) noncesNotAccepted.

SEMANTICS:  Responders SHOULD respond back with the
            requestor's nonce but if can't then SHALL
            respond with an error message of the value
            noncesNotAccepted.

            Requestors SHALL reject signed responses
            that fail to incorporate a supplied nonce.

            Upon receipt of noncesNotRequired, requestors
            MAY retry the request without using a nonce.
            Requestors are STRONGLY ADVISED that doing
            so MAY subject them to additional risk.

Thus, essentially, requestors can set "nonce always" but if they
want to they can have that overridden on a per-request basis.

Opinions?

Mike

---

From: "Ambarish Malpani" <[email-masked]>
Date: Tue, 30 Sep 2003 08:23:33 -0700

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Tuesday, September 30, 2003 12:41 AM
> To: Florian Oelmaier
> Cc: [email-masked]
> Subject: Re: OCSP response pre-production
> 
> 
> 
> Florian,
> 
> > 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.
> >

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 30 Sep 2003 18:26:16 +0200

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

---

From: "Ambarish Malpani" <[email-masked]>
Date: Tue, 30 Sep 2003 09:42:18 -0700

I agree with the statements below.

Mike, we should also add some statements of correct client behavior.

My thoughts:
    (a) If a client makes a request with a nonce, it MUST reject
		 a response that doesn't include the same nonce.
    (b) If a client makes a request without a nonce, it MUST ignore the
		nonce extension in the response (it doesn't matter if there
		is a nonce in the reply or not, because the server might be
		returning a cached response produced in response to a
previous
		request that was made with a nonce - although that wouldn't
be
		the behavior of a regular http proxy).

Ambarish

> [mailto:[email-masked]] On Behalf Of Michael Myers
> Sent: Tuesday, September 30, 2003 8:08 AM
> To: [email-masked]
> and thought I might ask if it's possible we could all get 
> behind the following simple fix.
> 
> 
> Thus, essentially, requestors can set "nonce always" but if 
> they want to they can have that overridden on a per-request basis.
> 
> Opinions?
> 
> Mike
> 
>

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 30 Sep 2003 10:30:02 -0700

Ambarish,

Good.

I think I said the same thing as (a) but we can work on the
exact languange.

As for (b), I guess we'll first have to see if this new proposed
text goes forward more or less as written.  If so, then
unilateral server-side nonces are by definition non-conformant
due to the absence of any normative text associated with the
practice.  In which case I see no reason to discuss
non-conformant behavior.

Mike

> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Tuesday, September 30, 2003 9:42 AM
> To: 'Michael Myers'; [email-masked]

---

From: "Florian Oelmaier" <[email-masked]>
Date: Tue, 30 Sep 2003 21:05:26 +0200

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

> [mailto:[email-masked]] On Behalf Of Julien Stern
> Sent: Tuesday, September 30, 2003 6:26 PM
> To: [email-masked]
> "If nextUpdate is not set, the responder is indicating that 
> newer revocation information is available all the time."
> 
> 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
> 
> 
> > 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:
> > 
> > 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
> > 
> >

---

From: "Miguel Rodriguez" <[email-masked]>
Date: Tue, 30 Sep 2003 16:17:41 -0500

I also agree with this idea proposed by Julien Stern, checking the
nextUpdate field is a good way of distinguishing fresh responses from
cached or pre-produced ones (in fact I think the date checking makes
sense for this type of responses, with all the clock drift associated
problems, as in the case of CRLs). 

However I object the use of a server generated nonce to avoid condition
1.2 in Julien's statement. How is that different from a replay attack? 

Miguel A Rodriguez
SeguriDATA
Mexico

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Florian Oelmaier
> Sent: Tuesday, September 30, 2003 2:05 PM
> To: 'Julien Stern'; [email-masked]

---

From: "Miguel Rodriguez" <[email-masked]>
Date: Tue, 30 Sep 2003 16:26:21 -0500

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
  
> > > - If you (the client) want a fresh response, include a nonce in
the
> > > request.