Subject: RE: OCSP in IKEv2

From: "Dave Engberg" <[email-masked]>
Date: Mon, 16 Aug 2004 17:06:13 -0400

Regarding Michael & Hannes OCSP-over-IKEv2 proposal:
  http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt

I like the idea of using OCSP responses to provide revocation information
over IKEv2.  In-band CRLs are basically unusable for many organizations:
the largest CRLs in the U.S. Government are over 5MB.  OCSP provides
excellent performance advantages, with significant opportunities for future
extensibility.

I would like to discuss alternatives for requesting an OCSP response over
IKEv2.  First, I'm going to provide some OCSP background information.  Feel
free to skip if you're already very familiar with RFC 2560 ...

-----BEGIN OCSP BACKGROUND-----

In OCSP, a relying party client sends an OCSPRequest to a responder server.
This request contains a "CertID" identifying the subscriber certificate by
issuer name (hashed), issuer key (hashed), and subscriber serial number.
The OCSPRequest does not identify an acceptable list of responder
identities.

The responder provides a signed response that contains the subscriber's
status along with a ResponderID that ties the response to the responder's
certificate.  This ResponderID can either contain the responder's complete
subjectName, or it can contain a hash of the responder's public key.  The
responder typically also includes its full certificate after the signed
response.

A relying party may accept an OCSP response if any of the following criteria
is met:

1)  The response is signed by the CA that issued the subscriber's
certificate.  (Rare)

2)  The response is signed by a responder whose cert is delegated by the CA
for "OCSP Signing".

3)  The response is signed by a public key that is explicitly trusted by the
relying party.  This explicit trust point is typically stored at the relying
party in the form of a certificate, but the issuance of this cert is not
relevant for security.

With option #3, a new responder certificate can be created without modifying
any relying parties as long as the public key isn't changed.  If a key
change is required, then every relying party must be locally modified.

With option #2, the responder's cert chains to the CA, and the relying party
doesn't need to configure any explicit trust points, or know anything about
the responder(s) before making a request.  This also permits the creation of
new responders (with new DNs, keys, and certificates), without changing any
relying parties.

Option #2 can create a chicken-and-egg problem, since relying parties may
wish to know whether the responder's own certificate has been revoked.  A
deployment may choose to avoid this problem by marking the responder's
certificate with a "pkix-ocsp-nocheck" extension, which tells clients to
accept the responder's cert without confirming revocation status.  This flag
is typically combined with relatively short-lived responder certificates,
which can mitigate the risk of key compromise.

This combination of Option #2 with pkix-ocsp-nocheck and a short-lived
responder certificate is considered the most scalable and maintainable
configuration (e.g. this is what VeriSign uses).

-----END OCSP BACKGROUND-----

RFC 3546 (section 3.6) extends TLS to permit the use of OCSP responses for
revocation status.  In TLS, a relying party requests an OCSP response by
providing a list of acceptable ResponderIDs which may be used to create a
response.  This matches the "explicit trust" security for OCSP (option #3).

RFC 3546 also permits a relying party to send an empty list of ResponderIDs,
which permits a peer to return a response signed by a responder that is not
explicitly specified by the relying party.  This could permit the use of
delegated responders (option #2).

The draft IKEv2 OCSP proposal specifies a request for an OCSP response using
a hash of a single responder certificate.  This is less flexible than both
"plain" OCSP and OCSP-over-TLS.

Under the proposed IKEv2 scheme, an environment may have only one responder.
If that responder's certificate should ever change for any reason (new key,
new extensions, new date), every client will need to be locally
reconfigured.  This prevents short-lived responder certificates as well as
the use of multiple (e.g. load-balanced) responders with different keys.

The TLS scheme in RFC 3546 is more flexible in three different ways.  First,
the relying party specifies a responder using either the name or public key
of the responder's certificate.  Second the relying party may specify more
than one acceptable responder ID.  Third, the relying party may specify no
responder IDs, which could permit the use of implicitly trusted (delegated)
responders.

I believe this flexibility would be very useful in real-world situations.
Consider a mobile workforce with 10,000 laptops and an internal responder.
Each of the laptops has a hard-coded responder certificate.  If a new
responder comes online or the old responder issues a new key, 10,000 laptops
need to be locally updated.

I would suggest modifying the IKEv2 proposal to permit requests with:

a) More than one responder

b) Specify responders by name or key hash instead of cert hash

c) Permit "delegated" responders (OCSPSigning) without explicit trust at the
relying party

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 17 Aug 2004 18:30:38 -0400

Yes, but only because the CRLs used by these organizations
are a crock of dung.  The problem can be worked around by using
OCSP, but should really be avoided in the first place by
proper partitioning of the CRLs.  At the very least, a
single CRL should not cover both (frequently revoked) human
users and (hopefully almost never revoked) IKE devices.

Dave Engberg wrote:
> In-band CRLs are basically unusable for many organizations:
> the largest CRLs in the U.S. Government are over 5MB.