Subject: RE: PKINIT open issues

From: "JK Jaganathan" <[email-masked]>
Date: Tue, 22 Jun 2004 12:04:37 -0700

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 13:42:14 -0500

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

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 23 Jun 2004 15:08:15 -0400

Nico:

The interesting scenario is the one you describe.  However, I believe 
there are scenarios in
which it will be crucial for the client to be able to verify the certs 
before full connectivity
is available.   For example, a system which is booting off the network 
via PIXI may not gain
full access to the network until after it has been able to authenticate 
to the PIXI and DHCP
servers and downloaded a boot image.  It may not be possible in this 
scenario for the OCSP
servers which are run not by the local organization but by the 
commercial certificate authority
to be reachable even though Kerberos tickets have been issued.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Jun 2004 14:26:42 -0500

> to be reachable even though Kerberos tickets have been issued.

I too find this scenario interesting, but you do not address my
questions re: deferral of OCSP validation of KDC certs until
connectivity has been established.

Deferring OCSP validation of KDC certs can result in MITM attacks on the
client upto the point where the deferred OCSP validation or connectivity
establishment fails [but only where KDC certs have been revoked].

But, is this a problem?  Would the client have to exchange secret
information with kerberized services or otherwise be exposed to such
attacks prior to connectivity establishment and subsequent OCSP
validation of the KDC cert?

I suspect that the answer some will give is "typically no, but it will
be hard to provide any guarantees, so this becomes a security
consideration."  But I want to hear this from the proponents (you
included, I suppose) rather than speculate that this is indeed the
answer you'll give.

I can see how might forget about this consideration and misconfigure
such a client in such a way that it does become exposed, but then we
have to decide whether this overcomes objections to including OCSP
tunnelling in PKINIT.  (But then, I've not seen any particularly good
reasons not to include OCSP tunnelling in OCSP.)

Cheers,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 23 Jun 2004 15:36:42 -0400

I can't talk about the details but for at least one large organization I 
know of the
answer is "yes.  the client needs to exchange secret data with the 
kerberized DHCP/PIXI
server to determine which operating system and configuration it will be 
given to boot."

The client should not be allowed to boot from an untrusted network.  If 
the KDC cannot
be trusted, then the DHCP/PIXI servers cannot be trusted; and the 
machine should not
boot an untrusted OS image.  In the scenario I am thinking of, the 
client machine would
not be able to gain access beyond the local subnet until after the OS 
has been downloaded,
installed, configured and booted.

Jeffrey Altman