Subject: RE: last call initiated

From: "Dave Engberg" <[email-masked]>
Date: Wed, 8 Feb 2006 08:40:27 -0500

Re: #1

I agree that the semantics of "unauthorized" aren't an ideal fit for this
usage, but I don't agree that this profile creates the security risk you
describe.

If you have a client implementation that will report "good" whenever it
can't get a signed answer about the status of a certificate, that client is
absolutely broken.  An attacker could get the same result by returning HTTP
error codes instead of OCSP error codes.  A client should only report "I
know this certificate is good" when it gets a positive signed response.
Failure to retrieve such a response for any reason (including network
errors, HTTP errors, etc.) means "I could not determine the status one way
or the other".

All commercial OCSP products I have used behave this way.  If you're using a
client that is broken in the way you describe, then the attacker could
perform your attack regardless whether the OCSP server implements this
profile.

Re: #2

We agree that it would be very nice if there were an unambiguous way to
indicate "this server never supports nonces" in the OCSP response to tell
the difference between a nonceless OCSP server and a replay attack in front
of a nonce-supporting server.  However, I think that overloading the
nextUpdate field for this purpose may cause problems.  E.g. some OCSP
clients may locally choose to cache an OCSP response until the nextUpdate
time.  They lose this information on a nonced response.  I'd prefer to add
an independent flag (e.g. a response extension) to indicate "no nonces"
rather than overloading nextUpdate. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Wednesday, February 08, 2006 6:08 AM
To: [email-masked]
Subject: Re: last call initiated

Greetings,

I have two comments on the draft (that I had already posted after the -02
draft was published):

1) Section 1.2.3 states that the OCSP responder should reply with an
"unauthorized" reply code when it is not capable of replying
authoritatively.

I believe there are two problems with that:

First, it overrides the semantic of the "unauthorized" error code, which
originally means that the client is not, well, authorized :) to access to
service. How would one know when he is actually not authorized ?

Second, because OCSP replies are unsigned, it allows for an very easy
man-in-the-middle attack. Because most client software assume by default
that the certificate is valid when the revocation status is unknown, it is
easy to turn an invalid certificate into a valid one is you control a proxy
in the middle, by sending an unsigned "unauthorized" reply.

I totally understand that sending signed replies for certificates of unknown
status is not possible for "caching" server. However, the present draft just
refers to the security considerations of RFC2560, whereas they have more
impact in the present case.

2) Regarding Nonces

This profile is obviously nonceless. No caching server in its sane mind
would ever implement nonce. So why imply that a server could possibly send
one ? If this is to cope with the case of a client that does not know
whether the server supports nonce or not, the extensive discussions that
occured on the list regarding this issue do not seem to be definitely
solved. If this RFC is published as is, it will practically destroy all
nonced implementations of OCSP, because the client has no way to know
whether is it talking with a nonce-supporting server or not. Hence, nonced
implementations becomes useless, because replay attacks always become
possible, unless the client is pre-configured to know that the server is
indeed using nonces.

To make my point(s) clearer: I have nothing against this protocol and think
it is important to have it because it's very efficient.
However, I do not think that, security-wise, it is a _profile_ of OCSP.

Lightweight OCSP is less secure than OCSP (the price to pay for efficiency),
but because
1) a client cannot know whether it is talking to a standard OCSP or
   a lightweight OCSP server, and
2) the lightweight OCSP mandates that the client falls back
   to less secure mode

it means that lightweight OCSP practically prevents a regular OCSP server to
provide extra security to its clients.

Note that, in my very humble opinion, this problem comes from RFC2560 and
not from this draft. If RFC2560 was modified to include the following
semantic behavior, we could have a bit-on-the-wire compatible protocol AND
allow regular OCSP to cohabit with lightweight OCSP without sacrifying
security:

the changes would be:

1) A server (identified by a ResponderID) can serve "fresh" responses or
"cached" responses, but MUST NOT serve both (else one MUST use different
responderIDs).

2) For a "caching" server:
- the nextUpdate field of all the SingleResponse elements MUST be present.
  It should indicate the expiration date of the (cached) information
validity.
- the nonce extension MUST be ignored

3) For a "live" server:
- the nextUpdate field of all the SingleResponse elements MUST be absent,
  thus indicating the information is live
- the nonce extension MUST be honored

Sincerely,

--
Julien Stern

On Tue, Feb 07, 2006 at 04:53:25PM -0500, Stephen Kent wrote:
> 
> Folks,
> 
> I am initiating a WG last call for the lightweight OCSP profile:
> 
>  draft-ietf-pkix-lightweight-ocsp-profile-03.txt
> 
> I have provided the authors with an initial set of comments.
> 
> Please send your comments to the list by February 17th, 1.5 weeks from 
> today.
> 
> Thanks,
> 
> Steve
>

---

From: "Julien Stern" <[email-masked]>
Date: Wed, 8 Feb 2006 16:46:51 +0100

On Wed, Feb 08, 2006 at 08:40:27AM -0500, Dave Engberg wrote:

Dave,

thank you for your replies.
See comments in-line.

> errors, HTTP errors, etc.) means "I could not determine the status one way

You do have a point, although, if there is a network or HTTP error,
there will probably be a popup of some sort indicating the failure
to the user. It is unclear how clients will react when given an
"unauthorized" response. If they display that you are not "authorized"
the popup will come up very often...

> perform your attack regardless whether the OCSP server implements this

Well, there might be something wrong with the configurations I've seen,
but I believed Outlook Express behaved this way.

Awyway, that was a minor point...

> rather than overloading nextUpdate. 

That would certainly be an alternative solution (but not bit-on-the-wire
compatible). In any case, I think it would be nice to solve the problem
of knowing whether "this server never supports nonces", otherwise, there
is a really a cohabitation problem between regular and lightweight OCSP.

I guess that in an ideal world, a son-of-2560 would have to be produced
at the same time as lightweight to enable the cohabitation of nonced
and non-nonced servers, but in order to be more realistic I think
that the OCSP nonce problem should be addressed in the near future.

My only remaining issue therefore is the following. Paragraph 3 says:

"Clients that opt to include a nonce in the
request SHOULD NOT reject a corresponding OCSPResponse solely on the
basis of the non-existent expected nonce, but MUST fall back to
validating the OCSPResponse based on time."

By mandating the client to fallback on time, you seem to block
the way to a future cohabitation between nonced and cached replies.

I'm not sure anticipating that the future is something you are allowed
to do in an RFC, but if it is, it might be safer to have a wording in
the spirit of:

"Future versions of the OCSP protocol may provide a way for the client
to know whether the server supports nonces or does not support nonces.
If a client can determine that the server supports nonces, it MUST
reject a reply that does not contain the expected nonce.
Otherwise, clients that opt to include a nonce in the
request SHOULD NOT reject a corresponding OCSPResponse solely on the
basis of the non-existent expected nonce, but MUST fall back to
validating the OCSPResponse based on time."

Sincerely,

--
Julien Stern

---

From: "Ryan Hurst" <[email-masked]>
Date: Mon, 13 Feb 2006 07:57:10 -0800

Thanks for all the feedback.

Our thinking has been exactly what David and Santosh called out bellow, however on David's last point we were hesitant to introduce a new extension indicating that "the server who produced the response doesn't support nonces" as we were shooting for a profile of 2560 vs creation of a new protocol as we did not want to break compatibility.

I have spoken with Alex and although we don?t know of any precedence of a profile of an existing protocol referring to a future version of a protocol in this way, we understand the intent of the statement and are OK with the change you call out, e.g:

"Future versions of the OCSP protocol may provide a way for the client to know whether the server supports nonces or does not support nonces.
If a client can determine that the server supports nonces, it MUST reject a reply that does not contain the expected nonce.
Otherwise, clients that opt to include a nonce in the request SHOULD NOT reject a corresponding OCSPResponse solely on the basis of the non-existent expected nonce, but MUST fall back to validating the OCSPResponse based on time."

I will be working on a revision of the draft tomorrow with the editorial changes from Steve (thanks) and will include this new text in the same revision.

Ryan

________________________________

From: [email-masked] on behalf of Dave Engberg
Sent: Wed 2/8/2006 5:40 AM
To: Julien Stern; [email-masked]
Subject: RE: last call initiated

Re: #1

Re: #2

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

Greetings,

2) Regarding Nonces

the changes would be:

3) For a "live" server:

Sincerely,

--
Julien Stern