Subject: OCSP, take three

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 15 Jul 2004 01:09:59 -0700

Finally, here is my proposal. the goal is to incorporate 
comments from recent discussons on the list on one hand, 

and on the other
hand to make Brian's job essier, in the event when he or the 
working group decides to maintain OCSP support in the PKINIT 
draft.

I won't object if Nico's text is preferred, or we go with
his draft separately. 

I want to thank Jeff (Altman), Nico, Martin, Sam
and others for supporting this feature request (or not objecting),
And it is time to bring it to a closure.  Shipping the PKINIT draft 
with high quality ASAP is our top prority now.

Thanks,

Larry

============================================================
3.2.5. OCSP Tunneling

Online Certificate Status Protocol (OCSP) [RFC2560] enables 
applications to obtain timely information regarding the 
revocation status of a certificate.  Constrained clients may 
wish to use OCSP to check the validity of KDC certificates, 
in order to avoid transmission of CRLs and therefore save 
bandwidth on constrained networks.

This section defines two pre-authentication types 
[clarifications], where the client and the KDC MAY send their 
OCSP responses along with the authentication exchanges defined 
in 3.2.1 and 3.2.3. 

This OPTIONAL feature also has the added benefit of maximizing 
the reuse of cached OCSP responses.

PA-PK-OCSP-REQ is sent by the client in the AS-REQ, and 
PA-PK-OCSP-REP is sent by the KDC in the AS-REP.  Note that 
neither the order of PA-PK-OCSP-REQ and PA-PK-AS-REQ, nor the 
order of PA-PK-OCSP-REP and PA-PK-AS-REP, is specified.

These pre-authentication fields contain data as follows:
    
    PA-PK-OCSP-REQ ::= SEQUENCE of OcspResponse

                        -- contains responses for validating 
                        -- certificates used in PA-PK-AS-REQ 

    PA-PK-OCSP-REP ::= SEQUENCE of OcspResponse
                     
                        -- contains responses for validating 
                        -- certificates used in PA-PK-AS-REP 

    OcspResponse ::= OCTET STRING

                        -- contains a complete OCSP response, 
                        -- defined in [RFC2560]

The KDC that receives a PA-PK-OCSP-REQ SHOULD send a 
PA-PK-OCSP-REP.

The client can request a PA-PK-OCSP-REP to be sent by using 
an empty sequence in the PA-PK-OCSP-REQ.

When using OCSP, the response is signed by the OCSP server, 
which is trusted by the receiver.  Depending on local policy, 
further verification of the validity of the OCSP servers MAY 
need to be done.

The client and the KDC SHOULD ignore invalid OCSP responses 
received via this tunneling mechanism, and they MAY implement 
CRL processing logic as a fall-back position, if the OCSP 
responses thus received alone are not sufficient for the 
verifications of certificate validity.  The client and the 
KDC MAY also ignore a valid OCSP response if it is a high 
risk that the certificate in question is revoked before 
the expiration date of this good response.
 
The KDC MAY send a PA-PK-OCSP-REP when it does not receive 
a PA-PK-OCSP-REQ from the client.  
==========================================================

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Jul 2004 10:53:04 -0500

> I won't object if Nico's text is preferred, or we go with

Your text seems more complete since it carries a SEQUENCE of OCSP
responses, which allows for the entire certificate trust chain to be
checked against revocation by the peer.

I'm not wedded to the separate I-D approach -- in fact, I'd prefer this
text be added to the PKINIT I-D but offered a separate I-D as a way to
help reach consensus.

I think there should be no doubt left in this WG about the utility and
desirability of this feature, that it should be a design requirement.
If so the only matter on which we need to reach consensus is whether
this text is in the same draft as PKINIT.

I have only a few comments left:

 - Include the security consideration described in my I-D or move the
   OCSP responses into the PKINIT pre-auth messages.  I'll be happy
   either way.

 - We may need an error code for the KDC to indicate that a cert/OCSP
   response pair are insufficiently fresh; clients can then get a fresh
   OCSP response and try again.

   Note that this error is not specific to OCSP but generic to PKI
   ("your cert is too long lived and I can't verify that it's not been
   revoked without your help; send a CRL or OCSP response").

 - The term "tunnel" is misleading here, as evidenced by the trouble
   that Martin had earlier with your proposal, as well as my own
   confusion -- OCSP requests, after all, are not transported by PKINIT,
   just responses.

   Whatever term we settle on, if any, other than "tunnel," it will be
   useful to describe this very feature as used in other protocols.

   I note that draft-myers-ipsec-ikev2-oscp-00.txt, the recently
   submitted I-D that does the same for IKEv2 as we're doing here for
   PKINIT does not call this "OCSP tunnelling" -- it doesn't have a name
   for this feature at all.

   http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt

Cheers,

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 15 Jul 2004 17:51:46 -0400

Martin Rex wrote:

>Nicolas Williams wrote:
>Actually *really* dislike this particular request.  Supplying a cached
>OCSP response should be a mere short cut, not a requirement.  In particular
>for the PKINIT case, the **KDC** must NOT harass the client about
>an expired OCSP response supplied by the client.  If the KDC requires
>an OCSP response and the client has either not sent one at all or
>one that the KDC dislikes for whatever reason, then the KDC should
>go out and perform the OCSP request/response directly with an
>OCSP server.
>  
>
100% agreement.   We have to assume the KDC has better connectivity than 
the client.
I like the ability of the KDC to send back a better OSCP response for 
the client to the client
but there is no reason for the KDC to reject the request unless it can't 
obtain an independent
verification.

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Jul 2004 23:45:27 +0200 (MET DST)

>    confusion -- OCSP requests, after all, are not transported by PKINIT,

Yup, I was also puzzled to still see the word "tunnel" in the headline.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Jul 2004 16:56:10 -0500

> go out and perform the OCSP request/response directly with an

Did you read what I wrote?  The sentence that starts with "Note that
..."?

This error would not be specific to OCSP -- it merely tells the client
that the server is unhappy about freshness of the cert, CRL, and/or OCSP
response and the server's inability to check for revocation on its own.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Jul 2004 17:01:58 -0500

> but there is no reason for the KDC to reject the request unless it can't 

"unless it can't ...

And for this the KDC should use KDC_ERR_CANT_VERIFY_CERTIFICATE?  Does
this cover verification issues other than CRL/status checking?  If so
then a more specific error relating to cert freshness seems entirely
reasonable, and if not then we already have such an error and you can
ignore my comment.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Jul 2004 01:00:47 +0200 (MET DST)

> Did you read what I wrote?  The sentence that starts with "Note that

*I* _did_ read what you wrote. 
  "error code for the KDC" ... "clients can then get a fresh OCSP
  response and try again"

and I _really_ dislike it.  As I said: a KDC must *NEVER* harass
a client when is supplied an expired or no OCSP response.
Either the KDC can perform revocation checking within his policy
constraints by itself or it should fail entirely.
If a KDC has a policy that requires him to perform revocation
checking than it must be in the position to fulfil this on his
own or fail, and *NOT* harass the client about it.

The error code "validation/verification" of client cert failed should
*NOT* be a suggestion to the client to quickly retry with the very
same cert hoping for the best.

Btw. is there really a need to perform OCSP revocation checking
on any other certificate in the client's forward certification path?
I had the assumption that the OCSP confirmation included that.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Jul 2004 18:41:53 -0500

>   "error code for the KDC" ... "clients can then get a fresh OCSP

Right, and this would not be a requirement.  The KDC can always reject a
cert for policy reasons, or should be able to.  Inability to confirm a
cert's status with sufficient "freshness" qualifies, IMO.  Why not be
specific then, in the error reply, about that, if it means that the
client can do something about it.

> a client when is supplied an expired or no OCSP response.

See above.

> constraints by itself or it should fail entirely.

With this error it fails entirely; failure does not mean that the client
can't try again though.

> own or fail, and *NOT* harass the client about it.

Failing *is* harassing the client.  "No because of XYZ" is better than
"no."

> on any other certificate in the client's forward certification path?

Well, yes, but typically services will see enough OCSP responses for the
other certs in the trust chain that it might be redundant to send them
all around all the time.

> I had the assumption that the OCSP confirmation included that.

I don't think so.  I'll re-read the spec, but I'm pretty sure it doesn't
do that.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Jul 2004 02:49:27 +0200 (MET DST)

> With this error it fails entirely; failure does not mean that the client

What I'm a little afraid of is wording in the spec that suggest the
client to retry combined with logic that says "oh, since it's optional
and I don't have it let's (re)try without it".  This could result
in the KDC getting under "friendly fire" all to easily.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Jul 2004 00:06:21 -0500

> in the KDC getting under "friendly fire" all to easily.

If all you want is to make sure that the text leaves no doubt that
something is optional, then say so.  Opposing some feature out of fear
that the text might not be properly written is not really reasonable, not
in this forum IMO.

It's clear that re-trying with fresher creds wouldn't be a requirement,
just as re-trying plain old PA-ENC-TIMESTAMP pre-authentication today is
not a requirement (and yet many users do re-try it).

Nico
--