Subject: RE: PKINIT open issues

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

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: Nicolas Williams <[email-masked]>
Date: Wed, 23 Jun 2004 15:55:07 -0500

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. 
> 

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
--