Subject: RE: last call initiated

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 8 Feb 2006 07:23:46 -0800

I agree with Dave on both counts.

Furthermore, nextUpdate is already overloaded.  Per 2560, nextUpdate can be
empty signifying that a new response is always available and nextUpdate can
also be empty because CA CRL used by the Responder does not have the field.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dave Engberg
Sent: Wednesday, February 08, 2006 8:40 AM
To: Julien Stern; [email-masked]
Subject: RE: last call initiated

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
>