Subject: RE: DISCUSS: MUST reject in OCSPv1

From: "Ryan M. Hurst" <[email-masked]>
Date: Thu, 4 Dec 2003 17:40:57 -0800

I am concerned with the idea of making any change to the standard that
"changes the 5 year old protocol".

This is particularly true since I don't see anyone on the list saying
this NonceUnsupported is needed, just that they would accept it.

I still think what is done with the nonce is a matter of local (client)
policy, and that if replay protection is desired responses not
containing the requested nonce MUST be rejected.

But since I appear to be odd man out on this, I would rather see us fall
back to Russ's original recommendation of MUST reject than break a 5
year old standard. 

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

> I like the elegance of Russ and Florian's ideas for securely
signalling 
> that a server doesn't support nonces by using a special value for the 
> nonce in replies.  This seems like the "right" place to put this
message 
> to the client.

Just for the record: I think you are referring to our server-generated
nonces when you talk about "Florian's idea". And while Russel is
signalling "NonceUnsupported" with a special nonce-value, we are
singalling "NonceSupported" with the inclusion of a nonce into every
request (mirrored from the request or server-generated). Thus we are not
subject to the attack you mention, as this does not need any additional
code in any existing client.

Russ proposal is a change in the protocol. Thus we need to update all
the clients and servers out there. Seeing that the proposed change is
needed and recognizing it as a good solution, I would accept this. 

-- 
Florian Oelmaier
SyTrust

---

From: "Liaquat Khan" <[email-masked]>
Date: Fri, 5 Dec 2003 06:54:43 -0000

Ryan,

We also agree with your viewpoint, particular the point about a nonce
being a matter for local client policy.  

In the various OCSP clients we have, the option of whether to include
nonce or not in the request message is left to local policy (i.e. the
administrator can configure whether or not nonce is included in the
request message). 

If the administrator decides nonces are necessary (to prevent replays)
then he/she will select these and our OCSP clients will include these in
the requests.  Now if an OCSP response is received back without a nonce
it will be rejected by our OCSP clients.

On the other hand, if the administrator feels nonces are not required
(to allow for cached responses) then he/she will not select to include
one in outgoing responses. 

The situation "we would like to have nonces in OCSP requests as default,
but if the server legitimately doesn't support nonces we are happy to
forgo nonces or we will generate a fresh request without a nonce" is not
that common in my opinion.  If such a case does exist, local policy will
probably be also happy to choose to not include a nonce in the OCSP
request message in the first place.

Regards,
Liaquat

Ascertia Limited, Orchard Building, Royal Holloway, Egham, Surrey, TW20
OEX
tel: +44(0)1784 497 321, fax: +44(0)1784 497301, mobile: +44 (0)7776
308766
website: www.ascertia.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

Ryan
-----Original Message-----

signalling 
message 

-- 
Florian Oelmaier
SyTrust

---

From: "Liaquat Khan" <[email-masked]>
Date: Fri, 5 Dec 2003 08:20:53 -0000

Ooops...in 4th paragraph below, I meant to say "outgoing requests"
instead of "outgoing responses".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Liaquat Khan
Sent: 05 December 2003 06:55
To: 'Ryan M. Hurst'; 'Florian Oelmaier'; 'David Engberg';
[email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

Ryan,

Regards,
Liaquat

-----Original Message-----

Ryan
-----Original Message-----

signalling 
message 

-- 
Florian Oelmaier
SyTrust

---

From: David Engberg <[email-masked]>
Date: Fri, 05 Dec 2003 07:15:21 -0500

I agree that this is not a current problem that many people are seeing, 
because current OCSP use is primarily limited to small "internal" 
deployments where a one-size-fits-all security policy isn't an issue. 
 If I'm only ever hitting one OCSP responder, a "require nonces from all 
servers" policy may be fine.

On the other hand, when people start using OCSP for real-world 
interoperability, the nonce-related options in all existing clients will 
likely be too limited.  For example, if ACME Amalgamated installs CAPI 
clients for its internal PKI users that are configured to "require 
nonces from every server," this client will immediately act up when apps 
try to verify SSL certs from Verisign if Verisign were to deploy a 
cache-based infrastructure.

Without a spec refinement to handle the broader interopability case, 
most people will probably just turn off nonce support across the board 
rather than trying to reconcile their internal PKI with external ones 
that they interoperate with.  Since I think nonces are actually negative 
for security on balance, I'm fine with this result, but I don't think 
this is the desired goal of everyone involved.

---

From: "Liaquat Khan" <[email-masked]>
Date: Fri, 5 Dec 2003 12:43:27 -0000

It's interesting what you say about "one-size-fits-all".  My view is you
have to look at things from the RPs point of view, i.e. as a relying
party, I only care what's best for me.  Therefore either nonces are
important to me or they are not (I don't particularly care whether OCSP
responder's support them or not).  

Therefore from a RP perspective a single security policy is probably
want you do want.  Also from a security perspective, you don't want to
make special cases unless you think that communication between that
particular server is secure against such threats and hence the
protection is not required.  

I think it is sufficient to make OCSP clients configurable on whether to
include a nonce or not (since the protocol already identifies it as an
optional item) and then leave it up the local administrator to define
what suits them according to their local security policy.  I should add
though that if you include a nonce in the request you MUST reject a
response if it doesn't include a nonce (or a correct one).  

Regards,
LK

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 5 Dec 2003 08:45:12 -0700

The fact still remains that Section 4.4.1 of RFC 2560 opens with
the sentence "The nonce cryptographically binds a request and a
response to prevent replay attacks."  The original intent of
this assertion is self-evident: nonces are to be incorporated by
servers.

Yet it is a fair observation that the relationship between
cached responses and nonced requests is underspecified,
particularly in the case of Internet-facing services receiving
requests from a heterogeneous population of clients over which
such services have no administrative control.

I chose nonceUnsupported as a candidate means of developing a
compromise solution to this issue based in part on prior list
dialog, including that below:

> From: David Engberg
> Sent: Thursday, October 02, 2003 12:23 PM
> Subject: Re: OCSP response pre-production
>
> If adding a new top-level error code is possible
> in v1, and adding a new response extension to
> indicate nonceUnsupported (or similar solution)
> is only possible in v2, then this may be the
> best course of action.

I saw how it was possible by cycling v1 at Proposed to get this
solution into v1 in a way that satisified all perspectives,
including that of the opening sentence, and yet not break the
installed base.  The core notion was that of a "caveated
response".  Looking back, had we addressed this issue during the
I-D phase of OCSP, I suspect we would have come up with
something very similar.

It enables secure on-the-fly client configuration on a
per-server basis while also providing as much OCSP value add as
possible.  Upon receipt of a caveated response, a clever client
could record this fact and not bother sending nonces to that
server again.

As proposed on this thread,
http://www.imc.org/ietf-pkix/mail-archive/msg07210.html
we have six who agree to this path forward and two who disagree.
Perhaps a poll is in order to get conclusive on it.

Yes, sending back a plain nonceless response to a nonced request
is not conformant to this proposal.  But neither is it
conformant in spirit to the above 4.4.1 sentence.  My
expectation is that, no matter what we do here, this will
continue anyway as a de-facto market standard practice until
such time as the market dictates otherwise. e.g. somebody gets
burned.  In which case the official IETF standard will have the
solution in place.  By not taking this action, someone could
otherwise point back to the RFC and claim it is the RFC's fault
for being underspecified in this area.  Which is where we got
started over two months ago.

Mike

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 5 Dec 2003 09:16:21 -0800

Liaquat - I don't think there is any disagreement on weather it is up to the client or not on including the nonce, there is however disagreement on:
What the responder returns if it can not return a nonce
What the client must do when it receives a response to a nonced request
For #1 my stance has been that the server should always return a authoritative response.

For #2 my stance has been that just like the decision to include the nonce in the first place its up to the client to decide what to do with it when he gets it back, and that clients wanting replay protection SHOULD reject responses that do not contain the nonce from their request.

That being said others believe:

For #1 that the server needs to return a special response indicating it is not capable of supporting nonces

For #2 that the client has no choice on what to do with the nonce in the response if he included a nonce in the 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? 

Changing the protocol by adjusting the ASN.1 of the nonce, adding a new extension or error code, or adding special semantics to the value of the nonce will break the existing implementations out there and its not clear to me why this is needed (especialy in v1).

My take on #2 is that its a matter of policy of the client to the client, but if accepting the MUST reject text here gets us out of #1 which will break clients I will accept it.

Ryan 

From: Liaquat Khan
Sent: Thu 12/4/2003 10:54 PM
To: 'Ryan M. Hurst'; 'Florian Oelmaier'; 'David Engberg'; [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

Ryan,

Regards,
Liaquat

-----Original Message-----

Ryan
-----Original Message-----

signalling 
message 

-- 
Florian Oelmaier
SyTrust

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 5 Dec 2003 09:56:31 -0800

Comments in-line

From: Michael Myers
Sent: Fri 12/5/2003 7:45 AM
To: [email-masked]
Subject: RE: DISCUSS: MUST reject in OCSPv1

[rmh]As I said, I am willing to accept the must reject if that means that others will drop the idea of adding breaking changes to the v1 protocol.

[rmh] No argument here!
[rmh]I just dont see what the client gets out of nonce not supported, he either knows he needs a nonced response or not, its a matter of local policy. I remember when I did the default configuration for the ValiCert desktop validator, it just was not possible to make a one-size fits all policy just as an example consider the fact that some responders will require signatures and some wont, the client already has to deal with this concept. 

Mike

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 5 Dec 2003 11:47:20 -0700

> From: Ryan M. Hurst
> Sent: Friday, December 05, 2003 10:57 AM
>
> [rmh]As I said, I am willing to accept the
> must reject if that means that others will
> drop the idea of adding breaking changes to
> the v1 protocol.

So now we've come full circle.  A plain MUST reject is where we
got started and which principle Russ affirmed in Minneapolis.
I'm curious what others think.

Mike

---

From: David Engberg <[email-masked]>
Date: Fri, 05 Dec 2003 14:17:46 -0500

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

I think there needs to be another flag in the response (e.g. 
nonceUnsupported extension) to securely separate 'a' from 'b'.

Ryan M. Hurst wrote:

>   1.
>   2.
...

> 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?

---

From: "Liaquat Khan" <[email-masked]>
Date: Fri, 5 Dec 2003 19:14:51 -0000

See my comments inline.  
 
Regards,
LK
 
-----Original Message-----
From: Ryan M. Hurst [mailto:[email-masked]] 
Sent: 05 December 2003 17:16
To: [email-masked]; 'Florian Oelmaier'; 'David Engberg';
[email-masked]
 
Liaquat - I don't think there is any disagreement on weather it is up to
the client or not on including the nonce, there is however disagreement
on:
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
For #1 my stance has been that the server should always return a
authoritative response.
 
LK: I agree (precisely for the reason you give for #2, i.e. this replay
protection was requested by the client, so let the client decide whether
or not it wants to go ahead and accept a nonce-less response.  Our ARP
client will currently reject such nonce-less responses, if it included a
nonce in the outgoing message.)  
 
For #2 my stance has been that just like the decision to include the
nonce in the first place its up to the client to decide what to do with
it when he gets it back, and that clients wanting replay protection
SHOULD reject responses that do not contain the nonce from their
request.

For #1 that the server needs to return a special response indicating it
is not capable of supporting nonces
 
For #2 that the client has no choice on what to do with the nonce in the
response if he included a nonce in the 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? 
 
LK: I assume the others believe that if you can indicate in a special
way that a nonce-less response is still "trustworthy".i.e. the only
reason it doesn't contain a nonce is because it's coming from a keyless
responder otherwise it's trustworthy.   Rather than a normal nonce-less
response which may be coming from a keyless responder or may be a
replay!  Assuming my understanding is correct, I still think this is
unnecessary complication.   Even in this case the final decision will
still remain with the client on what to do next.i.e. the client may
accept the response or reject it depending on local policy..so what are
you gaining??
 
Changing the protocol by adjusting the ASN.1 of the nonce, adding a new
extension or error code, or adding special semantics to the value of the
nonce will break the existing implementations out there and its not
clear to me why this is needed (especialy in v1).
 
My take on #2 is that its a matter of policy of the client to the
client, but if accepting the MUST reject text here gets us out of #1
which will break clients I will accept it.
 
Ryan 
 
  _____  

From: Liaquat Khan

 

 
Regards,
Liaquat

-----Original Message-----

 

Ryan
-----Original Message-----

signalling 
message 

 
-- 
Florian Oelmaier
SyTrust

---

From: "Liaquat Khan" <[email-masked]>
Date: Fri, 5 Dec 2003 19:13:40 -0000

See my comments inline.  
 
Regards,
LK
 
-----Original Message-----
From: Ryan M. Hurst [mailto:[email-masked]] 
Sent: 05 December 2003 17:16
To: [email-masked]; 'Florian Oelmaier'; 'David Engberg';
[email-masked]

 

 

 

Ryan 
 
  _____  

From: Liaquat Khan

 

 
Regards,
Liaquat

-----Original Message-----

 

Ryan
-----Original Message-----

signalling 
message 

 
-- 
Florian Oelmaier
SyTrust

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 5 Dec 2003 11:24:51 -0800

comments in-line

From: David Engberg
Sent: Fri 12/5/2003 11:17 AM
To: Ryan M. Hurst
Cc: [email-masked]; 'Florian Oelmaier'; [email-masked]
Subject: Re: DISCUSS: MUST reject in OCSPv1

[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?

...

---

From: David Engberg <[email-masked]>
Date: Fri, 05 Dec 2003 15:01:28 -0500

The value of 'nonceUnsupported' is to allow a client to distinguish 
between 'a' and 'b' securely if that client cares about the difference 
between the two.  Without this mechanism, the client cannot securely 
tell the difference.

It sounds like the argument is that no client will/should ever care 
about this distinction.  This is an argument about "business case" 
rather than technology/security.

I believe that it would be valuable for many clients to make this 
distinction.  It allows a local security policy that permits 
interoperabitliy with certs (e.g. SSL certs) from all sorts of 
environments (e.g. with AIA fields).  I'd say clients would use this to 
implement a "use the security model that the server chooses" policy. 
 Not every client or user would choose this policy, but I believe some 
clients would do so if permitted.

The presence of a 'nonceSupported' extension doesn't just permit replay, 
it encourages it (i.e. caching). The 'nonceSupported' extension may also 
indicate that that server is not vulnerable to key compromise or DoS 
attacks, and a client may choose to use that securely-transmitted 
information in its decision making.

Ryan M. Hurst wrote:

> comments in-line
>
> ------------------------------------------------------------------------
> *From:* David Engberg
> *Sent:* Fri 12/5/2003 11:17 AM
> *To:* Ryan M. Hurst
> *Cc:* [email-masked]; 'Florian Oelmaier'; [email-masked]
> *Subject:* Re: DISCUSS: MUST reject in OCSPv1
>

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 5 Dec 2003 13:51:36 -0700

> From: Ryan M. Hurst
> Sent: Friday, December 05, 2003 12:25 PM
>

While a caveated response can be replayed, it bears with it
unambiguous signed proof that the client's request for
anti-replay would not have been successful in the first place.

This is substantially different from replay of a nonceless
response captured from a server able and willing to support
nonces, but also able and willing to support non-nonced requests
(hence the capture and replay).

In the former case, the replay protection is not there to begin
with and the server/service is being forthright about that.  Any
lawyer will tell you, full disclosure is good thing, especially
in the case when one has no contracted relationship with a
relying party.

In the latter case, anti-replay *is* available but the client is
being blocked from it by an attacker.  This is not so good.

Mike

---

From: "Ambarish Malpani" <[email-masked]>
Date: Fri, 5 Dec 2003 17:52:08 -0800

I agree completely with Liaquat.

Ambarish

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Liaquat Khan
> Sent: Friday, December 05, 2003 4:43 AM
> To: 'David Engberg'
> It's interesting what you say about "one-size-fits-all".  My 
> view is you have to look at things from the RPs point of 
> view, i.e. as a relying party, I only care what's best for 
> me.  Therefore either nonces are important to me or they are 
> not (I don't particularly care whether OCSP responder's 
> support them or not).  
> 
> Therefore from a RP perspective a single security policy is 
> probably want you do want.  Also from a security perspective, 
> you don't want to make special cases unless you think that 
> communication between that particular server is secure 
> against such threats and hence the protection is not required.  
> 
> I think it is sufficient to make OCSP clients configurable on 
> whether to include a nonce or not (since the protocol already 
> identifies it as an optional item) and then leave it up the 
> local administrator to define what suits them according to 
> their local security policy.  I should add though that if you 
> include a nonce in the request you MUST reject a response if 
> it doesn't include a nonce (or a correct one).  
> 
> Regards,
> LK
> 
>

---

From: "Ambarish Malpani" <[email-masked]>
Date: Sat, 6 Dec 2003 19:57:52 -0800

Can we break this discussion up into two parts (and maybe even
have a couple of straw polls)?

1. When a server sees a nonce in a request, should the spec
require a server to include the nonce in the response or
return an error (as recommended by Russ) or should the spec
recommend the server include the nonce (as requested by Ryan,
Alex and David and maybe Florian).

2. Does there need to be a way of a server to indicate to a
client that it doesn't support nonces. If there does, I
assume everybody agrees that the way should be a secure
way.

Does this help clarify the issues?

Regards,
Ambarish

> [mailto:[email-masked]] On Behalf Of Michael Myers
> Sent: Friday, December 05, 2003 10:47 AM
> To: Ryan M. Hurst; [email-masked]
> So now we've come full circle.  A plain MUST reject is where 
> we got started and which principle Russ affirmed in 
> Minneapolis. I'm curious what others think.
> 
> Mike
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Dec 2003 21:21:18 -0500

>administrator can configure whether or not nonce is included in the

Yes, a client decides whether to include a nonce, or not. But, we 
need the standard to clearly indicate what the client will do with a 
response, when a nonce is included in a request. This is fundamental 
to the definition of the protocol.

>it will be rejected by our OCSP clients.

that is an appropriate thing for the client to do, and is consistent 
with the "MUST reject" clarification that Russ articulated at the WG 
meeting.

>=On the other hand, if the administrator feels nonces are not required

right.

>request message in the first place.

the hard part in all of this is how the client knows what the server 
is capable of doing, which seems not to be part of the discussion 
above.

Steve