Subject: RE: OCSP thoughts

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 29 Jun 2004 22:53:11 -0700

Sam Hartman wrote:
> 1) Is OCSP tunneling a useful feature in some pkinit environments?

This is useful for clients that have slow or no connectivity.

> 2) Is OCSP tunneling a useful feature in most open pkinit
> environments?  By open, I mean environments where multiple
>   different implementations are likely to be involved as opposed to
>   closed enviroments like Cable Labs.  If I need to do a better job
>   of specifying what I mean by this question or why I think it is a
>   useful question, please ask

It is mostly helpful for authentication.

> To be useful, does OCSP tunneling need to be a SHOULD/MUST or is it
>   useful as a MAY?

A SHOULD. This is optional.

> 4) If OCSP tunneling is not available, how should a client proceed in
>   order to be interoperable?

The client should fallback to other revocation mechanisms.

> 5) Do we believe we understand how to specify OCSP tunneling well
>   enough to do a good job now?

Microsoft has resources to get this done.

> 6) Do we believe we understand OCSP tunneling well enough to do an
>   efficient job?  Do we believe we have enough qualified reviewers?

I leave this question to the chairs

> 7) Could OCSP be specified without updating the pkinit protocol?

This is mainly to address a deficiency of the current version of CMS,
used by PKINIT.

> I will give my opinion on these questions in a separate message.

I like to hear from you. I did not see this separate message so I
suspect my mail client was faulty again.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Saturday, June 26, 2004 4:05 PM
To: [email-masked]
Subject: OCSP thoughts

Greetings, folks.  I've been migrating to a new laptop so I haven't had
the opportunity of participating in the OCSP discussion in real time.
However I do have a few thoughts after reading all the messages in this
thread.

A lot of the discussion seems to focus on process issues.  For example,
Nico believes it is lame to include a feature because there is
insufficient motivation to standardize it on its own.  Sasha and Eric
are concerned that this will delay the document and is unnecessary.

It's not wrong to consider these process issues, but I believe that in
this case, resolving the process debate may take longer than resolving
the technical issue.  I'd hate to spend longer deciding whether OCSP
tunneling has met some barrier for inclusion at a process level than we
do deciding how to specify it and whether it is a good idea at a
technical level.   

Even from the people who believe the current process debate is
important, I'd appreciate a few minutes of consideration to some
technical questions:

1) Is OCSP tunneling a useful feature in some pkinit environments?

2) Is OCSP tunneling a useful feature in most open pkinit
   environments?  By open, I mean environments where multiple
   different implementations are likely to be involved as opposed to
   closed enviroments like Cable Labs.  If I need to do a better job
   of specifying what I mean by this question or why I think it is a
   useful question, please ask.

3) To be useful, does OCSP tunneling need to be a SHOULD/MUST or is it
   useful as a MAY?

4) If OCSP tunneling is not available, how should a client proceed in
   order to be interoperable?

5) Do we believe we understand how to specify OCSP tunneling well
   enough to do a good job now?

6) Do we believe we understand OCSP tunneling well enough to do an
   efficient job?  Do we believe we have enough qualified reviewers?

7) Could OCSP be specified without updating the pkinit protocol?

I will give my opinion on these questions in a separate message.

--Sam

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Jun 2004 15:21:33 +0200 (MET DST)

Sorry for my last Mail, it was confusing.

> This is useful for clients that have slow or no connectivity.

Why is it useful?  I mean: what security benefit is there?
What conceived vulnerability is there which an **optional** (!!)
OCSP tunneling will prevent?

When the KDC is a good guy then there is no vulnerability without
OCSP, even for the case where it sends an revoked cert because of
a configuration error.

When the KDC is a bad guy in hold of a revoked cert then it
could claim to not implement an optional OCSP tunneling and
the attack is successful.

Absence of OCSP tunneling does *NOT* add additional vulnerabilities,
but simplifies the protocol significantly.

> A SHOULD. This is optional.

Anything else than a must implement for PKINIT implementations leaves
the vulnerability that OCSP is supposed to address in place.

> The client should fallback to other revocation mechanisms.

What is the problem to defer (or redo) the revocation checking of the
KDCs certificate once the network connectivity is established?

> Microsoft has resources to get this done.

I guess this question was more about: Do we have enough peer review
to prevent protocol flaws that cause interoperability problems?

Why do you think that the ASN.1-ladden SPNEGO spec has an interoperability
problem?  Here Microsoft was also one of the implementors but apparently
didn't see the problem.  And because of the lack of peer review the
problem went unnoticed.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Jun 2004 12:26:38 -0500

> OCSP tunneling will prevent?

I have presented a case where it would be useful.  Jeff Altman wants
this feature for that scenario.  Larry and JK continue to champion this
feature for reasons I don't find convincing, but we've agreed that that
disagreement is not a matter worth arguing about.

The scenario in question is this: where establishing Kerberos V
credentials is a required step in the process of bootstrapping network
connectivity.

Think kerberized DHCP.

Think kerberized DHCP, where a client might not have a useful IP address
until after authenticating to the DHCP server, but how would the client
authenticate the KDC when using PKINIT?

I'm not convinced that tunnelling OCSP in PKINIT is a very compelling
solution; there are others.  And anyways, we don't really have
kerberized DHCP (?) (though that doesn't make the scenario impossible,
since establishing connectivity is not just about obtaining an IP adress
but about obtaining a routable/routed IP address).

I do think that tunnelling OCSP in PKINIT should not be overly
complicated to specify, and that any such spec could be reviewed easily
enough.

So I don't oppose.  I will oppose anything stronger than MAY though.

[...]
> the vulnerability that OCSP is supposed to address in place.

Only for the scenario I proposed.  I don't care for clients that lack
connectivity due to firewall misconfigurations (one of Larry's and JK's
examples).

> KDCs certificate once the network connectivity is established?

That is one alternative.

> to prevent protocol flaws that cause interoperability problems?

We may not find out until MS produces a spec, so let them go ahead I
say.

> didn't see the problem.  And because of the lack of peer review the

SPNEGO is not really broken (the spec has some issues, but none fatal).

The problem with SPNEGO is that a really broken implementation has been
deployed far and wide, and it's broken in such a way that other
implementations cannot securely negotiate the use of non-broken SPNEGO
with them.

Cheers,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 30 Jun 2004 06:41:05 -0700

>but simplifies the protocol significantly.
A configuration requirement on the client stating OCSP tunnelling must 
be used
or the KDC will not be trusted increases the security.   I believe that 
this is how
this option will be deployed.  It would not be deployed as an optional 
negotiation
which as you have pointed out, could not work.

>the vulnerability that OCSP is supposed to address in place.
This is not true.  Please remember that a MUST is for implementers; a 
MUST is not for users.
Even of OCSP were implemented by all vendors it would not be required 
for those deploying
PKINIT to turn it on.   In the same way, a MAY or SHOULD implement may 
be configured
by end users to be required in their environments.

>KDCs certificate once the network connectivity is established?
I believe I addressed this last week.   There are environments such as a 
raw machine booting
onto the network and downloading an OS in which it would not be possible 
for the client
to communicate with an OCSP server directly until after it had to 
communicate secret
information to servers other than the KDC based upon the trust of the 
KDC.  The client
in this case would not have access to the network at until after the 
boot process is complete.

>didn't see the problem.  And because of the lack of peer review the
Unlike SPNEGO there are others interested in seeing this happen.  Not 
just Microsoft.

Jeffrey Altman

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Jun 2004 21:15:47 +0200 (MET DST)

OK, I accept that there are scenarios where OCSP *might* be useful,
still I'm having problems matching this into the traditional Kerberos
architecture.

In traditional Kerberos there is no means to revoke a KDCs credentials
(which is the KDCs knowledge of a client's secret key).  Since with
pkinit the KDC does not prove possession of a shared secret it might
be good to have some other means of authenticating the KDC.

A simple path validation to a trusted CA (even with revocation checking)
appears insufficient to me--usually CAs issue lots of certificates
and how is the client going to distinguish a mere users certificate
from a real KDCs certificate.  There must be something unique about
a KDCs certificate so that the client can recognize it, i.e. either
the Client needs to memorize each individual certificate of each
KDC it trusts, or (for the trust-freaks) it needs to be able to
securely distinguish KDC certs from non-KDC certs from the same CA.

A Basic constraint similar to "Allowed to act as a CA" comes to mind,
e.g. "Allowed to act as a KDC", or an Extended Key Usage OID that
indicates this.

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.

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?

Maybe it would also be good if the spec said that the tunneled OCSP
request should not be processed by the KDC before the client has been
successfully authenticates?

-Martin

---

From: Love <[email-masked]>
Date: Wed, 30 Jun 2004 21:50:38 +0200

> but NOT something to identify KDC certificates.

see <[email-masked]> in krb-wg archive.

Love

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Jun 2004 16:06:32 -0500

> be good to have some other means of authenticating the KDC.

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

> e.g. "Allowed to act as a KDC", or an Extended Key Usage OID that

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.

> significant than to get OCSP reassurance.

Really?

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

Yes.

> successfully authenticates?

Sure, but I think that's how it would be anyways.  Otherwise there might
be a covert channel where one might really not want one.

Nico
--