Subject: OCSP and PKINIT, take two

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Jul 2004 16:59:09 -0500

Summary:  I believe support for PKINIT peers to send OCSP responses for
          their certs to each other should be a requirement.  Further, I
	  believe this requirement can be satisfied without modification
	  to the PKINIT ASN.1 types/PDUs.  Further, this can be done in
	  the same document as PKINIT or in a separate document.

My understanding of OCSP has improved, and so I have now come to support
not only the inclusion of an OCSP response by the KDC in its reply, but
also the inclusion of an OCSP response in the client's request.

I recently saw a proposal for the use of OCSP in IKEv2 (IPsec) where
each peer can request an OCSP response for the other's CERT and,
correspondingly, each peer can send an OCSP response, even if the other
peer did not request it, for its CERT.

This approach of having each peer send an OCSP response for its certs
has the benefit of reducing OCSP traffic and load by maximizing re-use
of cached OCSP responses.

If there is no RFC that recommends this for new PK protocols then there
ought to be one.

Note that connectivity to OCSP responders does not figure in the above;
the ability to reuse OCSP responses maximally is a Good Thing.  The
connectivity rationale discussed earlier continues to be valid, of
course, but is, IMO, from an architectural point of view, secondary to
the reuse maximization argument.

As to the matter of how to include OCSP definitve responses in PKINIT, I
believe that the easiest way would be through a separate pre-auth type.
The certificate identifiers in the responses sent this way have to match
those of the sender's certificate (and its trust chain, if requested),
thus no additional binding to the PKINIT pre-authentication is required.

Cheers,

Nico
--

---

From: Brian Tung <[email-masked]>
Date: Wed, 14 Jul 2004 15:22:36 -0700

> 	  the same document as PKINIT or in a separate document.

First of all, I agree that this requirement (if it becomes one) can
be satisfied without modification to the existing PKINIT ASN.1 types.
I also agree that it would make sense to put them in a separate
preauth.

However, assuming I stipulate to requiring the OCSP responses, I don't
see that it makes much sense to put it in another draft.  In order to
verify that I am compliant with PKINIT, I should have to check the
PKINIT draft *plus* the OCSP add-on draft?

But I also don't see that supporting this has to be a requirement (for
both sides) for PKINIT compliance.  Can you explain your rationale for
it being a requirement?

Brian Tung <[email-masked]>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Jul 2004 18:31:52 -0500

> 	  the same document as PKINIT or in a separate document.

By popular request, and since this seemed so easy, particularly with
xml2rfc, here's an I-D that defines a pre-auth method for transporting
OCSP responses in Kerberos KDC requests/replies.  Attached.

Note that I can't submit this to the IETF I-D repository until after the
60th IETF meeting concludes.

Also, for some reason I can't get xml2rfc to let reference I-Ds, so the
PKINIT and clarifications I-Ds are not referenced in the references
section.  This will be remedied later.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Jul 2004 18:57:07 -0500

> PKINIT draft *plus* the OCSP add-on draft?

I propose separate I-Ds for two reasons:

 - to gain the approval of implementors who don't care about OCSP
 - my I-D is so, so simple that it might pass WG Last-Call before
   PKINIT...

> both sides) for PKINIT compliance.  Can you explain your rationale for

I meant that it should be a design requirement, not a requirement for
every PKINIT exchange.

I also think that all new protocols that use PK certs should have this
feature.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Jul 2004 14:33:37 +0200 (MET DST)

> 	  the same document as PKINIT or in a separate document.

As Nico has already clarified, he wanted a design requirement for
protocols that do (X.509) PK authentication to provide a container
for transfering (cached) OCSP responses for one's certificate.

For PKINIT there shouldn't be a requirement for supplying OCSP responses
for either side, but a possibility to do so.  I would expect the client
to have less of a chance of possessing a (still) valid OCSP response,
because of all the possible client side connectivity problems that were
mentioned.  Actually, I think it is much *more* likely that the KDC has
a recent/valid OCSP response for the clients cert (after validating
the clients cert) than the client itself.

The KDC is likely to be most closely watched to be able to obtain
OCSP responses (a failure would become quickly obvious to the
admin if the KDC was configured to require OCSP revocation checking),
and fixing the KDCs OCSP connectivity is probably much simpler than
figuring out why particular clients have such failure.

So a KDC appreciating a valid OCSP response supplied by a client in
a PKINIT handshake would be fine, a KDC requiring the client to supply
a valid OCSP response might be entirely impossible for some of the
scenarios mentioned in the discussion and is likely to become a
helpdesk nightmare.

Btw. how about this:  if a PKINIT client does not have an OCSP response
for his own cert, but the KDC obtains one during validation of the
clients authentication request, wouldn't it be nice if he sent this
OCSP response along to the client with the authentication reply so
that the client can cache it (the client would have to indicate that
he is interested in an OCSP response for his own cert).

-Martin

---

From: Brian Tung <[email-masked]>
Date: Thu, 15 Jul 2004 15:19:51 -0700

> I meant that it should be a design requirement, not a requirement for

Before, I couldn't tell which of three things you meant by "requirement":

    1.  We must define the exchange, so that it may be implemented
        consistently.

    2.  Compliant implementations must support the exchange, even if
        they don't use it each time.

    3.  Compliant implementations must use the exchange each time.  (Very
        unlikely you meant this, but included for completeness. <g>)

Now that you've eliminated number 3, which of the first two do you mean?
(I'm not trying to be dense, although I admit that unintentional density
is certainly possible.)

---

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

> (I'm not trying to be dense, although I admit that unintentional density

I mean something between (1) and (2): compliant implementations MUST NOT
break when they see an OCSP response.

Nico
--

---

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

> break when they see an OCSP response.

I would also say it's something between (1) and (2).

Actually, for the KDC it should be a MUST to NOT break upon seeing
this protocol extension, even if it doesn't support/implement
filling/processing of the contents.

The OCSP-aware client SHOULD indicate support for OCSP processing
by including an OSCP response container (which may be empty!),
and the KDC SHOULD return an OCSP response for his own cert
if the client indicated to support this in case the KDC supports
this and posesses an OCSP response.

How should the client indicate that it would be interested in an
OCSP response for its own client cert in case the KDC supports
this extension and obtained an OCSP response for the client cert
while validating/verifying it?

-Martin

---

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

> this and posesses an OCSP response.

Right, though it seems easier to say that the client shouldn't break
either.

> while validating/verifying it?

Similarly to how the other cases are handled -- either have fields for
this in the PKINIT pre-auth messages or have separate pre-auths just for
this.  In the latter case the client's pre-auth request for this would
be empty and the server's reply would be the OCSP response (or SEQUENCE
thereof, to allow for an OCSP response for each cert in the trust
chain).

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 16 Jul 2004 13:10:08 -0400

On Thursday, July 15, 2004 18:33:44 -0500 Nicolas Williams 
<[email-masked]> wrote:

>> > > > I meant that it should be a design requirement, not a requirement
>> > > > for every PKINIT exchange.
>> > >
>> > >     3.  Compliant implementations must use the exchange each time.
>> > >     (Very unlikely you meant this, but included for completeness.
>> > >         <g>)
>> > >
>> > > Now that you've eliminated number 3, which of the first two do you
>> > > mean? (I'm not trying to be dense, although I admit that
>> > > unintentional density is certainly possible.)
>> >
>> > I mean something between (1) and (2): compliant implementations MUST
>> > NOT break when they see an OCSP response.
>>
>>

So, last I checked we were talking about PA-DATA.
Which already has this property.