Subject: RE: POLL: Use of nonces in OCSP

From: David Engberg <[email-masked]>
Date: Thu, 25 Sep 2003 17:44:53 -0400

No, we would not like to see the language change.  Yes, it would break 
existing deployments based on caching-only responders.

Explanation:

There is a (strong) case to be made that a large OCSP deployment based 
around caching-only responders with no private keys to protect can be 
more secure against real-world attacks than one based entirely on 
live-signing responders using nonces:

     http://www.corestreet.com/whitepapers/nonce-sense.pdf

It would be undesirable to change the specification to break existing 
implementations and deployments that chose this route.

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 25 Sep 2003 16:43:30 -0700

David,

The proposed text does not mandate use of nonces but rather
clarifies existing text regarding this optional OCSP extension.
Does that help?

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> David Engberg
> Sent: Thursday, September 25, 2003 2:45 PM
> To: [email-masked]
> Subject: RE: POLL: Use of nonces in OCSP
>
>
>
>

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 25 Sep 2003 17:41:26 -0700

The recent OCSP poll on the use of nonces has surfaced concerns
regarding OCSP response pre-production.

Let's use this thread to discuss the issue and so keep the POLL:
thread clear for break/no-break responses.

The text proposed in the poll does not mandate use of nonces.
It clarifies text that has been there from day one.

Mike

---

From: David Engberg <[email-masked]>
Date: Thu, 25 Sep 2003 23:37:33 -0400

I have worked with several clients (for example, Alacris's OCSP client) 
that have independent configuration options for "Send a nonce with the 
request" and "Require the nonce in the response."

There may be reasons to remove this client flexibility ... to say that 
any client that sends a nonce MUST reject any response that does not 
contain that response.  But this new requirement may be unnecessarily 
restrictive, since it removes a potentially useful deployment alternative.

I was more concerned on the responder side ... I don't want a 
caching-only responder to be considered "out of compliance" if it cannot 
(or will not) return a nonce.

Thanks,
Dave

[email-masked] wrote:
> David,
>  
> David Engberg wrote on 09/25/2003, 14:44:
> 
> Interesting paper.
> Are you saying that you have an OCSP client that sends a nonce in the 
> OCSP request, and you have a caching OCSP responder that ignores that 
> nonce, and sends a cached OCSP response without that nonce, and your 
> OCSP client subsequently accepts that cached OCSP response even though 
> the nonce doesn't match ?
>  
> To me it sounds like the client should not be sending the nonce. Then 
> the cached OCSP responses will work fine.
> Perhaps there should be a hint for the client not to send the nonce, eg. 
> something in the AIA extension of the certificate being verified.
>  
> -- 
> I am the dog in dogfood
>

---

From: David Engberg <[email-masked]>
Date: Thu, 25 Sep 2003 23:27:33 -0400

The only word I would change was in your second paragraph:

     "Correspondingly, upon receipt of a request
      containing a nonce, a responder SHALL include
      the value of such nonce in the production of
      the associated response."

I would recommend changing SHALL to SHOULD or MAY so that a compliant 
OCSP infrastructure can be deployed which has no signing keys on the 
responders.  If a request with a nonce is received, the responder can 
return a pre-generated response without the nonce, and the client can be 
configured to accept or reject this based on its local policies (as 
allowed by most current OCSP clients).  I believe that "SHALL" makes any 
responder without a signing key automatically uncompliant, since it will 
be unable to meet this requirement.

Thanks,
Dave

---

From: Vadim Fedukovich <[email-masked]>
Date: Fri, 26 Sep 2003 21:16:33 +0300

>     http://www.corestreet.com/whitepapers/nonce-sense.pdf

So, "a server without any signing key will have nothing to lose"
as I read it. Yes, it makes some sense. However some people still
chose SSL-capable web servers sometimes.

Something missing in this paper is a trade-off analysis like what kind
of responder fits business better:
  fresh response indicating current status with a risk of responder's
  key compromise because of a buffer overflow
or
  somewhat stale responses with less risk of compromising the key
  used by another task maybe on another host.
Such an analysis might include human errors and program bugs statistics

Also missing the case mentioned by Peter Gutmann with out-of-sync
clock at the client.

At last, old stale responses might be replayed by an attacker in case of
successful buffer overflow to keep already revoked certificate "valid".
This means bug-free responder software is a point with no route-around
either with or without signing key online.

I do believe 3 points mentioned contribute to "real-world security"
so it's hard to agree with "significantly higher overall security"
wording in the paper.

regards,
Vadim

---

From: David Engberg <[email-masked]>
Date: Fri, 26 Sep 2003 15:26:59 -0400

Vadim -

Thanks for the feedback on the nonce paper.

Anecdotal evidence from CERT advisories and similar sources indicates 
that network takeover attacks and denials-of-service are much more 
common than man-in-the-middle (e.g. "replay") attacks, but this is 
hardly scientific.  If I wanted to severely disrupt your PKI, I know 
which attack I would attempt first, however.

In practice, an out-of-sync clock on a client is noticed and corrected 
immediately since current, valid responses will be constantly rejected. 
  However, an attacker that knew of an unnoticed backwards (not 
forwards) clock skew on a specific client could theoretically replay a 
stored response from this period to that client.  Obviously, a serious 
clock skew will screw up many other parts of your PKI as well (accepting 
expired certificates, etc.).

I strongly disagree with your third point.  An attack on a caching-only 
responder can only replay "valid" responses that have not already 
expired.  If the responder issued a "valid" response for cert #1234 in 
the morning and you compromise it at noon, you could keep replyaing that 
response for the rest of that "day" only.  After expiration, every 
client will reject the response.  These responses are typically the same 
duration as the CRL, so this is similar to saying that "if I compromise 
your LDAP directory, I can replay your CRL for the rest of the day." 
Obviously, a traditional OCSP responder based off of the same CRL will 
keep providing the same "valid" response throughout that day until the 
next CRL is released, but it will give you the illusion of freshness 
with its nonces.

Contrast this with what I can do if I attack your key-bearing server in 
the same way that Kerberos was compromised last year.  I can create a 
response for ANY certificate that says it is revoked or that it is 
valid.  This can be used to reinstate a stolen ID card that was revoked 
six months ago, which may allow me to walk in to a secure facility, or 
it can be used to falsely revoke any valid certificate, potentially 
disrupting critical operations.  This is much more severe than the risk 
of keeping a certificate valid for a few extra minutes or hours on the 
day it is revoked.

Thanks,
David

---

From: Vadim Fedukovich <[email-masked]>
Date: Sun, 28 Sep 2003 09:11:05 +0300

hi David,

> which attack I would attempt first, however.

both attack types mentioned have an established business so to say:
one can try own the host or try to get host effectively down. Both results
in an asset of some sort. One should expect there will be man-in-the-middle
if it could result in something better that just demonstration.

Most important here, "replay" is not exactly "man-in-the-middle".
Schoolbook man-in-the-middle use it's own keys to decrypt messages intended
for someone else and re-encrypt with recipient key.
Replay copy a message and use it to replace some other response the next
minute (or maybe msec) without changing saved copy of 1st message.

> expired certificates, etc.).

There are well-known race attacks that stands on tiny time slice while
manipulating files that makes no chance for a human typing commands
with shell but still allow a process to catch it.

> next CRL is released, but it will give you the illusion of freshness 

Sure a practical attack would try to race status update process
instead of replaying last year status.

Why not compare with a responder using CA status database instead of CRLs?
Database could be locked to serialize events and this makes it possible
to report current status with no chance at all for race on "this-day" status.

At least one responder do use CA database for reporting.
Yes, here's the same risk of responder/host compromise and precise status
reporting trade-off.

> of keeping a certificate valid for a few extra minutes or hours on the 

Yes any signing or verifying signatures software is in sharp contrast
with popular gaming PC stuff. I'd consider this issue as general need
for secure code and a bit irrelevant caching- or signing OCSP responder.

Yes, a race attack would unlikely let a human walk in a secure facility
but could let some faster event happen.

regards,
Vadim

-- 
Naina library: http://www.unity.net/~vf/naina_r1.tgz

---

From: David Engberg <[email-masked]>
Date: Sun, 28 Sep 2003 09:25:11 -0400

> Yes, here's the same risk of responder/host compromise and precise status

Exactly:  only a responder that actually runs AT the CA will ever truly 
give you a fresh response when you send it a nonce.  Any responder based 
on multi-hour CRLs will only give you the illusion of freshness.

Of course, if you need to support more than a trivial PKI with one 
physical site, a single responder running at the CA won't scale to your 
needs, even if you accept the security risk of thousands of online 
requests per minute into your CA environment.

> for secure code and a bit irrelevant caching- or signing OCSP responder.

Ultimately, one needs to consider why it is a good idea for CAs (or at 
least the root) in a real PKI to be deployed offline.  If your 
firewalls, IDS, HSM, web servers, and armed guards are perfect, you 
don't need an offline CA, but most people choose not to make that 
assumption.

The difference between compromising a Traditional OCSP responder and a 
Distributed (caching-only) OCSP responder is similar to the difference 
between compromising a CA versus its LDAP directory.  By compromising a 
CA, I can forge a certificate or CRL that will be universally accepted, 
saying whatever I like.  This attack may not be detected until its 
consequences are felt.

Compromising the LDAP directory could allow me to replay a CRL for a few 
hours after its replacement is published, but that's about it. 
Attempting to replay an expired CRL will be immediately noticed by every 
client, who will call the IT department to complain.

---

From: "Julien Stern" <[email-masked]>
Date: Mon, 29 Sep 2003 11:26:17 +0200

> thread clear for break/no-break responses.

Having recently looked into much detail at RFC2560, I feel there are
really two totally different scenarios possible:

1) Responder with a "live" backend (Nonce MUST be used)
2) Responder with a CRL backend (Nonce do not matter)

CASE 1) The responder has access to timely information,
the "thisUpdate" field should be equal to the "producedAt" field
and the "nextUpdate" field should be absent. Nonces must clearly
be used to prevent replay attacks. Server should add a nonce even
to nonceless requests.

CASE 2) The responder is backed by a CRL, (or is acting as a keyless
proxy). The "thisUpdate" field should be the production time of the CRL,
the "nextUpdate" field the production time of the next one. Nonce should
not be used as they hinder caching and do not provide any extra security
in that setting. Sure, you can do a replay attack, but you will only
replay the same data as it won't change until the "nextUpdate" time.
Some attacks might be possible around local clock problem, but this
scenario has essentially the same security as CRLs at a much lower
traffic cost. Nonced requests should be rejected or forwarded.

I actually believe that nonce are essentially pointless for any server
without access to "live" revocation information. I think the real info
clients should be able to obtain from the servers is whether they
provide "live" info. This could be indicated by systematic inclusion of
nonces by the server even for nonceless requests. If a server does not
send a nonce, it means his info is not timely anyway, and the nextUpdate
field should be checked in order to minimize (not prevent as clocks are
not perfect) replay attacks.

If a client knows in advance if the server is "live" or CRL based, I
believe there is no difficulty. The major difficulty for a client is
to figure out whether a server is live or not.

The only thing I would (personaly humbly) truly mandate is to consider
as malformed a response without a nonce and without a "nextUpdate"
field. A replayable response without an expiration date is just plain
bad. This is why I believe it should be mandatory for "live" servers to
include a nonce in every response.

--
Julien

---

From: Vadim Fedukovich <[email-masked]>
Date: Mon, 29 Sep 2003 17:49:01 +0300

> be used to prevent replay attacks. Server should add a nonce even

What's the point to respond with a nonce to a request without one?
If a client did not include a nonce he knows is unique there's nothing
to compare with so any old response with any nonce would be fine

regards,
Vadim

---

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

> I actually believe that nonce are essentially pointless for 
> any server without access to "live" revocation information.

In theory your are right. In the real world you cannot always rely on a
synchronized time (throughout a company for example). Mind: I am not
talking about attacks, but I am talking about interoperability problems
and rejected validations. While certs usually have a long duration (to
long for small clock skews to become a problem), validation is a major
problem with clocks having a difference of a few hours. This way using
nonces are an advantage even for CRL-based responders. I will not argue,
if this advantage is worth the trouble or not - but this argumentation
is very common out there.

For example: one of the points for using OCSP at some of our customers
was to reduce the issues coming up due to not-synchronized times. Using
nonces in OCSP and setting very late nextUpdate values while
simultaneous disabling OCSP-client caching does the trick in a closed
environment while maintaining a high security standard. 

> I think the real info clients should be able to obtain from
> the servers is whether they provide "live" info.

I agree. But I am not sure if this information should be connected with
the nonce-system. Here at SyTrust we currently judge this by comparing
nextUpdate, thisUpdate and producedAt. When
nextUpdate=producedAt=thisUpdate we assume that this is a "live"
response (we allow a few seconds difference). Seeing that this is not
what was meant by these three times and that nextUpdate is optional, I
am not really glad with that system. So it would be nice to have such a
signalling.

Mind: There are responders not includind "nextUpdate" into there
response when they have live access to the data.

-- 
Florian Oelmaier
SyTrust