Subject: RE: PKINIT open issues

From: Medvinsky Alexander-MGI1174 <[email-masked]>
Date: Wed, 23 Jun 2004 10:25:36 -0700

I agree with Eric's comments.  OCSP tunneling should be a separate draft because:

	1) OCSP is not necessary for PKINIT implementations, since CRLs could be used instead.
	2) When OCSP is used, it doesn't have to be tunneled through Kerberos.  The same KDC host could implement a standard OCSP responder, based on existing OCSP specifications.
	3) OCSP was not part of the PKINIT draft until recently and would further delay the draft, when it can be specified in its own IETF draft instead.

Sasha.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rosenfeld
Sent: Wednesday, June 23, 2004 7:46 AM
To: JK Jaganathan; Jeffrey Altman; [email-masked]
Cc: Liqiang(Larry) Zhu; Sam Hartman
Subject: RE: PKINIT open issues

I strongly object to including OCSP tunneling. First, OCSP tunneling is one mechanism, among many, to convey revocation information. It seems best to specify individual mechanisms in separate documents. 

Second, it is expanding the scope of PKINIT, which can only further delay an already overdue document. We have been pushing PKINIT for almost a year now; two planned "last call" dates have come and gone, and the document doesn't seem to be any closer to RFP status, as indicated by the ever expanding list of open issues. I believe the WGs focus should be on finishing a tighly scoped PKINIT document.

-Eric

Eric S. Rosenfeld
Project Director, PacketCable Security
CableLabs
858 Coal Creek Circle
Louisville, CO  80027-9750

Email: [email-masked]
Phone: 303-661-3841
Fax: 303-661-9199

-----Original Message-----
From: JK Jaganathan [mailto:[email-masked]] 
Sent: Tuesday, June 22, 2004 1:05 PM
To: Jeffrey Altman; [email-masked]
Cc: Liqiang(Larry) Zhu; Sam Hartman
Subject: RE: PKINIT open issues

 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: "Eric Rosenfeld" <[email-masked]>
Date: Wed, 23 Jun 2004 15:02:46 -0600

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, June 23, 2004 1:48 PM
To: Eric Rosenfeld
Cc: JK Jaganathan; Jeffrey Altman; [email-masked]; Liqiang(Larry)
Zhu

>>>>> "Eric" == Eric Rosenfeld <[email-masked]> writes:

    Eric> I strongly object to including OCSP tunneling. First, OCSP
    Eric> tunneling is one mechanism, among many, to convey revocation
    Eric> information. It seems best to specify individual mechanisms
    Eric> in separate documents.

Is their another mechanism within the scope of the IETF?

[ERIC] Sam, OCSP is the IETF protocol for offloading certification
revocation checking. My statement was that there are mechanisms other
than OCSP tunneling that can be used to convey revocation information to
a client. The two most obvious are:
1 - The client can contact the OCSP server itself.
2 - The client can download a CRL itself.

---

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

> The two most obvious are:

I've explained the problems with this in my response to Nico.

> 2 - The client can download a CRL itself. 

  CRLs are unusable especially when it comes to smartcard logon. How
would you like to be the user waiting for a 5MB CRL to download over a
56Kbps line just so he can logon to his laptop?

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 24 Jun 2004 12:52:03 -0700

> 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

Nico, you are right about this one. Look at ID smime-rfc3369bis, not surprisingly, Microsoft and Sun people are not alone realizing this deployment problem.

Larry

-----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:
> > [mailto:[email-masked]] On Behalf Of JK 
> > Jaganathan
> > 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.
> > 
> > [mailto:[email-masked]] On Behalf Of Jeffrey 
> > Altman
> > 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

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 29 Jun 2004 17:13:57 -0700

Martin, 

The client does not have to use/request the OCSP tunneling.

Larry
-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, June 29, 2004 2:09 PM
To: Liqiang(Larry) Zhu
Cc: JK Jaganathan; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: PKINIT open issues

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