Subject: RE: PKINIT open issues

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 23 Jun 2004 13:43:23 -0700

Is it just a knee-jerk reaction to pull off OCSP tunneling from PKINIT? 

I do not think it has been established that significant complexity is added by OCSP tunneling into the PKINIT draft.

Larry

-----Original Message-----
From: JK Jaganathan 
Sent: Wednesday, June 23, 2004 1:37 PM
To: 'Nicolas Williams'
Cc: Jeffrey Altman; [email-masked]; Liqiang(Larry) Zhu; Sam Hartman
Subject: RE: PKINIT open issues

In the real world among most large organisations PKI infrastructure and KDCs are maintained by separate groups of people and are considered separate pieces of infrastructure. We use PKINIT for smartcard logon and when using OCSP customers often run into connectivity problems such as that the OCSP port was blocked by a firewall admin or that the OCSP server is down. Caching the OCSP response at the KDC and using OCSP tunnelling greatly reduces the fragility of the solution. 
A usable PKINIT design must be reasonably resilient to these problems. 

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Wednesday, June 23, 2004 11:42 AM
> To: JK Jaganathan
> Cc: Jeffrey Altman; [email-masked]; Liqiang(Larry) Zhu; Sam 
> Hartman
> Subject: Re: PKINIT open issues
> 
> IMO lack of "sufficient momentum to be standardised by itself" is a 
> lame argument for including OCSP tunnelling in PKINIT.
> 
> The other reasons for pursuing OCSP tunnelling are not, IMO, 
> sufficient justification for including OCSP tunnelling in PKINIT.
> 
> The only good reason not to include OCSP tunnelling would be that it's 
> not necessary, but I'm not sure that that's been established.
> 
> We're left with no good reasons, yet (but, see below), for including 
> OCSP tunnelling in PKINIT.  Even a mandate from the IETF to support 
> OCSP wouldn't suffice to carry the day since tunnelling is not 
> actually required for the client to run OCSP.
> 
> OCSP tunnelling merely helps a client that lacks connectivity, which 
> may be useful in cases where obtaining Kerberos V tickets is part of 
> the process of establishing general connectivity, but then the client 
> can defer OCSP verification of KDC certs until after connectivity is 
> established -- assuming that the client wouldn't reveal any secrets to 
> an kerberized service until after that, otherwise OCSP tunnelling in 
> PKINIT becomes desirable.  But you've not made any arguments along 
> these lines (or have I missed them?).  Is this what you had in mind?
> 
> As for permanent lack of client connectivity to OCSP servers, well, I 
> think that if OCSP servers are not generally reachable, including 
> across firewalls, then we'd better stop talking about OCSP (or start 
> talking about tunnelling it in every Internet protocol, which would 
> bring us to the question of why anyone would want to not have general 
> connectivity to OCSP servers, that is, back to square one).
> 
> Can you elaborate on your reationale for pursuing OCSP tunnelling?
> 
> Nico
> --
> 
> On Tue, Jun 22, 2004 at 12:04:37PM -0700, JK Jaganathan wrote:
> >  I'm reviving this thread since Sam and Jeff brought up
> this topic while they were in Seattle. 
> > We generally agree that OCSP tunnelling support is useful
> as it permits caching at the KDC and it allows OCSP to be used when 
> the client does not have direct connectivity to the OCSP responder.
> > Also it is unlikely that this will have sufficient momentum
> to be standardised by itself outside of PKINIT. For these reasons we 
> believe it is appropriate to retain OCSP tunnelling in the PKINIT 
> draft.
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of JK 
> > > Jaganathan
> > > Sent: Wednesday, April 21, 2004 12:33 PM
> > > To: Jeffrey Altman; [email-masked]
> > > Subject: RE: PKINIT open issues
> > > 
> > > The OCSP tunneling logically belongs in the PKINIT draft. 
> I haven't
> > > heard any clear arguments for moving it to another draft
> other than
> > > 'it can be done'. I don't see how it would hold up the
> PKINIT draft
> > > in anyway. What are the major technical objections here? The same 
> > > work has already been done for TLS so we are not doing something 
> > > that is a major addition.
> > > I very much doubt the OCSP work would be standardized if
> we had to
> > > go through a whole separate draft process.
> > > 
> > > ________________________________________
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf
> Of Jeffrey
> > > Altman
> > > Sent: Tuesday, April 20, 2004 12:45 PM
> > > To: [email-masked]
> > > Subject: Re: PKINIT open issues
> > > 
> > > Nicolas Williams wrote:
> > > 
> > > I'm for moving the OCSP tunneling to a separate draft.  
> It's a new
> > > feature that, unlike the CAs-verified authz-data element, isn't 
> > > crucial for security and interoperability, even if it is
> desirable.
> > > 
> > > Nico
> > > I concur.  OCSP should be moved to a new draft.
> > > 
> > > Jeffrey Altman
> > > 
> > > 
> > > 
> > 
> > 
>

---

From: Martin Rex <[email-masked]>
Date: Tue, 29 Jun 2004 23:08:50 +0200 (MET DST)

Liqiang wrote:
> 
> I do not think it has been established that significant complexity
> is added by OCSP tunneling into the PKINIT draft.

I disagree.  Even plain OCSP and CRL checking for the client adds
complexity, tunneling OCSP adds huge complexity.

What is that revocation checking at the client side for at all?
In traditional Kerberos there is no way for the client to verify
the KDC, so why the sudden need to do it with PKINIT?

Just because that is how the PKI-Software works is pretty weak.
We ship PKI software without revocation and don't feel bad about it.

IIRC, Kerberos theoretically supports revocation of tickets but
it is not being used.

What kind of certificates would the client want to check anyway?
If it is about the KDCs certificate -- why should it?  In
traditional Kerberos the client does not check the KDC's credentials
either (because it can not), and it doesn't seem to be a problem.

The habit of PKI-Freaks to check certificates for revocation is
an extremely poor excuse.  The traditional approach in Kerberos
is to issue credentials with a short lifetime so that revocation
checking is not necessary (which in theory is possible with Kerberos
tickets but hardly implemented).  Technically it would be easy
to do the exact same with the KDC certificate--make it so short-lived
that you can ignore the revocation stuff altogether.  I don't care
whether that is compatible with the business model of particular
CAs.  Most of the PKI Software and protocols are so badly engineered
that they can hardly been used in productive Servers if all the
features are active without DoS oneself for 99.9% of the time.

In the Kerberos model it is the client's duty to get hold of
fresh/valid credentials and to cache them when they need to be
used several times.  This design helps to build robust and efficient
servers and makes it much harder to DoS AppServers and the KDC.

What exactly are the constraints on the OCSP tunneling for the KDC?
It sounds to me like an serious vulnerability of the KDC to perform
any OCSP on behalf, or worse: arbitrary OCSP on behalf of clients.

Was this feature meant to be optional?  For a small subset of users
it would be an unreasonable burden to make it a requirement.  But
as soon as it is optional, a KDC using a revoked cert (which is the
only situation where revocation checking of the KDCs cert would
make sense) could delibertately say that it doesn't implement
OCSP on behalf and the client would not be any wiser.

It appears to me that there is zero value for OCSP in PKINIT...

-Martin