Subject: RE: PKINIT open issues

From: "JK Jaganathan" <[email-masked]>
Date: Wed, 23 Jun 2004 16:27:43 -0700

Wrong analogy.
Right analogy:
Patient: Doctor, I cant breathe properly if I take this medicine.
Doctor: Didn't you read the instructions? Just hold your breath for an
hour after you take it.  

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Wednesday, June 23, 2004 2:37 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 02:19:36PM -0700, JK Jaganathan wrote:
> > I'm glad you agree that there are good reasons to do OCSP 
> tunnelling 
> > even though they are not the same.
> 
> Ok, so we can agree for different reasons...
> 
> > 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.
> 
> 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
> -- 
>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Jun 2004 19:49:23 -0500

> Doctor: Didn't you read the instructions? Just hold your breath for an

No, the doctor has not given this "medicine" (blocking OCSP) to the
patient.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 23 Jun 2004 21:26:04 -0400

>No, the doctor has not given this "medicine" (blocking OCSP) to the
I think this conversation is silly.  I have already provided a scenario 
which I believe demonstrates
the need for OCSP tunneling in order for PKINIT to be able to work with 
KDC certificate validation.
It does not matter if the two of you (Nico and J.K.) disagree on the 
need for OCSP tunneling
in an alternate scenario.

Personally I think the firewall justification is somewhat weak as well.  
If a company is going to
deploy smart cards for login they had better understand the 
infrastructure requirements.  The
problem Microsoft is seeing with OCSP ports is identical to what happens 
when admins close
other ports which are necessary for gaining access to the 
authentication/authorization infrastructure.
Many sites have had to deal with a worse problem due to the blocking of 
the krb524 port (4444)
in the last year.  Or folks who have blocked port 88 thinking that it is 
somehow related to CIFS.

The biggest problem that I have with OCSP is that the server is located 
somewhere far far away
on the Internet and the unreliability of the Internet often results in 
the OCSP server being unreachable.
This is why so few people run with OCSP validation turned on in their 
browser.  I've tried to use it
and there are just too many sites for which it fails and there is no 
many bypass to say "yes, I am willing
to take the risk".  So instead we all just turn it off.  This is true 
for IE6, Mozilla, and Opera.

In the non-bootstrapping scenario, what you really want to deploy within 
the organization is a local
copy of the remote OCSP server using a "CA Designated Responder" signing 
certificate which can routinely
fetch a CRL to fall back on when the real server is unreachable.  Of 
course, this would require an
additional payment to the CA provider if a commercial provider is being 
used.  If the CA is a
Microsoft Windows hosted CA, the organization can deploy these servers 
as needed.

Another possibility is for the OSCP server to use a "Trusted Responder" 
public key which is known
to the client prior to the connection.    This would allow an 
organization to setup their own OCSP
servers for CAs not under the control of the organization but has the 
traditional key management
problems.

OSCP redundancy can be obtained without tunneling in any case in which 
network connectivity
is provided.  What these mechanisms cannot do is provide OSCP access 
when the client does not
yet have IP connectivity.  It is in that case, where the Kerberos TGS 
exchange itself is being tunneling
as part of some other bootstrapping protocol that OCSP tunneling would 
have to be provided
within Kerberos since only PKINIT knows that it needs to be done.

Jeffrey Altman