Subject: Re: OCSP thoughts

From: Nicolas Williams <[email-masked]>
Date: Thu, 1 Jul 2004 16:08:26 -0500

On Thu, Jul 01, 2004 at 02:07:21PM -0700, Liqiang(Larry) Zhu wrote:
> Martin Rex wrote:
> Nicolas Williams wrote:
> > > Martin Rex wrote:
> > > To me, being able to tell KDC-certs from non-KDC certs appears more 
> > > significant than to get OCSP reassurance.
> > 
> > Really?
> 
> Please convince me why an MITM attack is not possible if the client can
> not tell if the KDC cert is really from a KDC.

Larry, see my reply to Martin's reply to that.  I was not arguing that
we shouldn't have a way to distinguish KDC vs. non-KDC certs!  Just that
that doesn't make the need for KDC cert revocation checking go away.

Note to self: don't be too terse! :) :)

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 1 Jul 2004 14:07:21 -0700

Martin Rex wrote:
> How?

> If OCSP responses can really be cached, then it should be possible to
skip the request and piggy-back the OCSP response > 
> on the message carrying the KDC cert.  In a way, this would entirely
remove OCSP tunneling.

Please take a look at ID smime-rfc3369bis and also my earlier email
response to Nico.

> The only certificate(s) for which a KDC should process a tunneled OCSP
request is the KDCs own certificate(s), everything > else opens
additional DoS attack surface (resource exhaustion), so *personally* I
think full OCSP tunneling is overkill 
> here (besides requiring an additional roundtrip).

This is exactly right. Why the clients need OCSP response for any cert
other than that of the KDC?

Larry
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Thursday, July 01, 2004 1:40 PM
To: Nicolas Williams
Cc: [email-masked]
Subject: Re: OCSP thoughts

Nicolas Williams wrote:
> 
> Adding PK into the mix changes the game.  Now we can have revocation 
> of KDC's creds, so why not?

Yup, but it doesn't make things more secure that way (actually PK&Trust
makes it less secure).

With PKINIT it seems to have to trust (1) the KDC, (2) the KDCs CA and
the (3) OCSP server, whereas with traditional Kerberos it was only the
KDC.

From an engineering standpoint, forcing each and every client to hassle
with certificate revocation appears like a serious architectural flaw,
especially in the face of all the clients problems to actually perform
OCSP that have been mentioned.
(That lots of PKI-based software is poorly architectures in just that
way doesn't make it any better).

Ideally, the KDC should provide the proof (didn't I read that OCSP
responses can be cached somewhere?) that his cert is still valid along
with his cert, and any client that wants to perform the revocation check
can use it, all others ignore it.  That would be by far the most
efficient way to do it (saving a roundtrip on PKINIT) and there would
not be any more problem with the clients lack of connectivity.

Now if some PKI freak comes along and tells me that his client trusts
the CA the KDCs cert, trusts the KDC in case the KDCs cert can be
verified but doesn't want to trust the particular OCSP server which the
KDC used, then I would definititely consider him nuts.

Using a short-lived KDC cert and making it the KDCs task to
update/replace his cert before it expires would simplify the
architecture by magnitudes...
and it would make it so much easier to locate and fix the problems in
case of a failure!

> 
> None of that makes revocation go away as an issue.  Short-lived 
> signatures by trusted CAs does.  I.e., there are other alternatives to

> OCSP tunnelling in PKINIT, but OCSP tunnelling ain't a bad idea
either.

The only certificate(s) for which a KDC should process a tunneled OCSP
request is the KDCs own certificate(s), everything else opens additional
DoS attack surface (resource exhaustion), so *personally* I think full
OCSP tunneling is overkill here (besides requiring an additional
roundtrip).

> 
> > I found the Extended Key Usage OID for *client* certificates but NOT

> > something to identify KDC certificates.
> > 

Yes, of course!

How often do you expect KDC certs to get revoked in the real world?
How often do you expect CAs to issue *ONLY* KDC certs in the real world?
 
Definitely doing correct KDC authentication is much more significant
than revocation checking.

Keep in mind that in >95% of all cases where X.509-certs are validated
today no certificate revocation check is performed (and I haven't seen
anyone complaining about the default settings  of MSIE settings so far.)

> 
> > 
> > I don't know OCSP itself, so I'm wondering about the following:
> > since you call it tunneling, it appears that the client can specify 
> > which certificate should be checked for revocation.  Wouldn't it 
> > make sense to constrain it to the certificate which the KDC uses for

> > the reply?
> Yes.

How?

If OCSP responses can really be cached, then it should be possible to
skip the request and piggy-back the OCSP response on the message
carrying the KDC cert.  In a way, this would entirely remove OCSP
tunneling.

-Martin