Subject: Re: OCSP thoughts

From: Martin Rex <[email-masked]>
Date: Thu, 1 Jul 2004 22:39:33 +0200 (MET DST)

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.
> > 
> > To me, being able to tell KDC-certs from non-KDC certs appears more
> > significant than to get OCSP reassurance.
> 
> Really?

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

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 01 Jul 2004 13:52:57 -0700

>carrying the KDC cert.  In a way, this would entirely remove OCSP tunneling.
I do not believe that OSCP responses can be cached. 

There is a possibility that the KDC could be an authorized OCSP server 
in order to cut down
on the round trips from the KDC to the CA.  However, this model is not 
in line with the majority
of the CA business models.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 1 Jul 2004 15:59:34 -0500

> the (3) OCSP server, whereas with traditional Kerberos it was only the KDC.

In traditional Kerberos authentication of the KDC and the client
principals is symmetric -- the same item (long-term keys) is used to
authenticate both.

With PKINIT we get to do better, so why not?  What's wrong with doing
better?

>  way doesn't make it any better).

I don't want to argue about whether or not PKI is a hassle.  Cert
revocations is part and parcel of PKI and can only be truly avoided by
using short-lived certs or by ignoring the problem altogether.  PKINIT
will allow clients to ignore cert revocation.

But why make it hard for the client to check for KDC cert revocation?

I'd rather argue about how the client that cares about KDC cert
revocation deals with the problem than whether we should cater to such
clients, for I believe that we must cater to them, else we're not doing
PK correctly.

That said, I've pointed out that there are alternatives to OCSP
tunnelling in PKINIT.  I don't believe that tunnelling OCSP in PKINIT
will be hard to specify or review.  These two observations add up to
this conclusion, for me anyways: a) let this be optional (MAY) to
implement, b) put a timer on the spec and, if consensus is not arrived
at by the deadline, yank it.

> and there would not be any more problem with the clients lack of

I have to go read up on OCSP to comment on this.

> server which the KDC used, then I would definititely consider him nuts.

Well, yeah.

> and it would make it so much easier to locate and fix the problems in

Yup!  That's why I've offered this very alternative.

> full OCSP tunneling is overkill here (besides requiring an additional

We're in agreement, as a quote from that post of mine, that you did not
include here, should make clear.

> > > significant than to get OCSP reassurance.

You misunderstood me.  I do expect to be able to distinguish KDC certs
from non-KDC certs (is that an open item for PKINIT?); that helps with
KDC impersonators using stolen non-KDC certs, but even then one should
have a way to deal with KDC cert revocation, so to me this isn't a
complete solution.

> How often do you expect KDC certs to get revoked in the real world?

Every time a KDC implementation has a vulnerability discovered and
patched.

> How often do you expect CAs to issue *ONLY* KDC certs in the real world?

Dunno, but that's not relevant here (see above).

> than revocation checking.

Yes, but the latter is not completely unimportant.

>  of MSIE settings so far.)

This doesn't mean that we should ignore cert revocation in specs.

> > > sense to constrain it to the certificate which the KDC uses for the

I don't know enough about OCSP either, but I suspect there is a way.

Larry, take note.

> carrying the KDC cert.  In a way, this would entirely remove OCSP tunneling.

I suspect that the comment about caching OCSP requests was incorrect.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Jul 2004 23:47:47 +0200 (MET DST)

> I do not believe that OSCP responses can be cached. 

I just looked at rfc2560 (PKIX OCSP), and to me it looks like there's
no field in the response tying it to a particular request (which would
preclude caching).  But there is a validity information in the
OCSP reply, which would give an idea for how long the OCSP response
can be cached.

-Martin

Quoting rfc2560, page 3:

   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA

   A definitive response message is composed of:

   -- version of the response syntax
   -- name of the responder
   -- responses for each of the certificates in a request
   -- optional extensions
   -- signature algorithm OID
   -- signature computed across hash of the response

   The response for each of the certificates in a request consists of

   -- target certificate identifier
   -- certificate status value
   -- response validity interval
   -- optional extensions

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Jul 2004 23:59:54 +0200 (MET DST)

> Every time a KDC implementation has a vulnerability discovered and

Wow!  Actually, the pedantic would have to do it every time when
remotely-accessible software on the KDC machine has a vulnerability
discovered, not only the KDC code itself.

And if I'm not mistaken, then all the services still use traditional
shared-secret keys.  So if you assume compromise of the PKI credentials
of the KDC, you should equally assume compromise of all secret keys in
the KDC database and rekey them all, plus re-verify all the
X.509-cert <-> account mappings for PKINIT.

Now with all the Software that comes along on a Microsoft PDC,
this would be about once a week, wouldn't it?  So for large companies
that operate huge Microsoft domains the constant rekeying would provide
jobs for dozens of admins (plus a significant revenue stream for the CA...)

:)

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 1 Jul 2004 17:06:07 -0500

> X.509-cert <-> account mappings for PKINIT.

Newsflash: KDC (KDB) compromises require re-keys; in practice this is
typically done only where a KDC is confirmed to have been compromised.

And it is painful.

> jobs for dozens of admins (plus a significant revenue stream for the CA...)

I'll let Larry answer this with specifics :), but I suspect (warning:
understatement) that folk do try to minimize the set of services running
on a KDC, regardless of what the actual platform is.

Can we go back to OCSP now?  Or better yet: can we now wait until Larry
publishes something we can look at and review?

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 01 Jul 2004 21:13:27 -0700

>publishes something we can look at and review?

I was speaking with some folks who sell our popular operating systems to 
the government
sector and was told point blank that their highest priorities with 
regards to Kerberos are
PKINIT.  I asked whether certificate validation is a requirement and if 
so what the preferred
method was.  The response was "Absolutely!" and "OCSP!  Have you seen 
how large the CRLs
are for Federal Government CAs?  You could never have your clients 
downloading them as
part of validation.  They are just too big."

This discussion settled for me any question of whether or not OSCP must 
be available
for client validation of certificates.  It does not answer the question 
of whether tunnelling
must be used.  (Although I agree it should be supported.)

I second the request for Microsoft to publish a spec on this ASAP.

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Fri, 2 Jul 2004 14:55:39 +0200 (MET DST)

Jeffrey Altman wrote:
> the government sector and was told point blank that their highest
> priorities with regards to Kerberos are PKINIT.  I asked whether
> certificate validation is a requirement and if so what the preferred
> how large the CRLs are for Federal Government CAs?  You could never
> have your clients downloading them as part of validation.
> They are just too big."
> 
> be available for client validation of certificates.  It does not answer
> the question of whether tunnelling must be used.
> (Although I agree it should be supported.)

I have the feeling that both of you were not talking about entirely
seperate issues and didn't notice it.

Why do you think that CRLs from Government CAs are so big?
It's not because their most important servers (KDC) are compromised several
times a day and need to be rekeyed (and its certificate revoked)
each and every time.

The Government customers want certificate validation for **client**
certificates!  That is because they put privigeles into certificates
and use the killing (revoking) of identities (certificates) in order
to revoke/change privileges.

So the government customers desperately need the KDCs ability to
check the client certificates for revocation because of how they
(ab)use the technology.  (Most of the PKI design doesn't seperate
authentication from authorization, which is a BAD thing.)

Anyway, the most important thing for PKINIT, particularly for CAs that have
awfully large CRLs (because they issue certs *not* only to tightly guarded
servers) is to be able to securely distinguish KDC certs from non-KDC certs.
And in order to enable clients to perform revocation checking on KDC
certs it should be perfectly sufficient to have the KDC provide the
proof by sending a cached OCSP response along with his cert to the
PKINIT client.

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 02 Jul 2004 11:07:24 -0700

>proof by sending a cached OCSP response along with his cert to the

I understand your arguments but it won't matter.   The organizations 
purchasing the software
does not see the distinction.  The requirements will state that if certs 
are used then ocsp must
be used to validate the certs on each use.  It does not matter whether 
or not the certs will never
be changed or would never be revoked.

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Fri, 2 Jul 2004 22:35:01 +0200 (MET DST)

Jeffrey Altman wrote:
> purchasing the software does not see the distinction.
> The requirements will state that if certs are used then ocsp must
> or not the certs will never be changed or would never be revoked.

But at least *WE* should see the distinction.

I'm NOT AT ALL against the client *processing* an OCSP *response* to check
the KDCs cert for revocation -- but it does not need to perform the
OCSP *request* through OCSP tunneling in PKINIT if the KDC supplies
it along with its own certificate.

Your governmental customer should not have any problems with this
particular optimization.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Jul 2004 15:52:05 -0500

> But at least *WE* should see the distinction.

Yes, but it's a difference in degree and insufficient, at that, for us
to ignore that customer's request.

> Your governmental customer should not have any problems with this

Fine with me, a very reasonable simplification.

Thank you,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 02 Jul 2004 14:09:55 -0700

>Fine with me, a very reasonable simplification.
I agree with this proposed optimization.

- Jeff