Subject: RE: PKINIT open issues

From: "JK Jaganathan" <[email-masked]>
Date: Wed, 23 Jun 2004 14:19:36 -0700

I'm glad you agree that there are good reasons to do OCSP tunnelling
even though they are not the same.
In a perfect world firewall admins would just open their ports and not
make any mistakes and OCSP servers would never go down. However we do
not live in a perfect world and we must design solutions that deal with
imperfection. This is a scenario that we repeatedly encounter with our
customers. When a 100,000 people come in on Monday morning and find out
that they cannot logon to their workstations with their smartcard it
takes time to find out who the firewall admin is who shutdown the wrong
port or why the OCSP server went down. Infact because this is an
important thing for our customers we are planning to let them turn off
revocation checking but that is not the best thing to do, which is why
OCSP tunnelling is important for us. 

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Wednesday, June 23, 2004 1:55 PM
> To: JK Jaganathan
> Cc: Jeffrey Altman; [email-masked]; Liqiang(Larry) Zhu; 
> Sam Hartman
> Subject: Re: PKINIT open issues
> 
> On Wed, Jun 23, 2004 at 01:36:39PM -0700, JK Jaganathan wrote:
> > 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. 
> 
> Reliability problems in OCSP deployments do NOT justify OCSP 
> tunnelling in PKINIT.  Kerberos detractors often point out 
> the Kerberos requirement for online infrastructure (i.e., the 
> KDC) as a negative for Kerberos.
> 
> Obviously OCSP does the same for PKI; it seems a bit silly to 
> now turn around and say that OCSP is too much infra and that 
> we have to correct for that in Kerberos!  :)
> 
> Neither do firewall problems (see my explanation in my first 
> posts on this today) justify OCSP tunnelling in PKINIT.  
> Customers who firewall OCSP should be told not to -- we don't 
> want to build OCSP tunnels in every protocol that firewalls 
> that block OCSP might allow through.  If OCSP is so 
> important, then let it through.
> 
> The bootstrapping problem though is much, much more 
> interesting and closer to convincing.  I think that some 
> client bootstrap scenarios technically don't need OCSP 
> tunnelling in PKINIT, though in many cases arranging for 
> connectivity to OCSP is likely to be harder in practice than 
> one might think.  But scenarios where the client has no 
> connectivity because it has and will not have useful IP 
> addresses until a network configuration protocol (e.g., DHCP) 
> involving KDC exchange tunnelling (e.g., kerberized DHCP) is 
> completed take the cake, as here we really do have a 
> chicken/egg problem and just as we might solve part of it by 
> tunnelling Kerberos in DHCP we might also have to tunnel OCSP.
> 
> Of course, we can end up tunnelling anything and everything, 
> so we must draw the line somewhere... :)
> 
> Cheers,
> 
> Nico
> -- 
>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Jun 2004 16:36:53 -0500

> even though they are not the same.

Ok, so we can agree for different reasons...

> OCSP tunnelling is important for us. 

Oh stop it, customers do stupid things sometimes and then we can tell
them to stop.  Customers already have enough rope to hang themselves
anyways so I really, really don't buy this.

"Patient: Doctor, doctor, it hurts when I do this!  <hits self with hammer>
 Doctor:  Well, don't do that!"

Nico
--