Subject: RE: OCSP in IKEv2

From: "Ryan Hurst" <[email-masked]>
Date: Mon, 16 Aug 2004 16:56:48 -0700

I support Dave's proposal, my only additions would be in this context I
would like to see byKeyhash given preference in any normative text.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dave Engberg
Sent: Monday, August 16, 2004 2:06 PM
To: [email-masked]
Subject: RE: OCSP in IKEv2

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