Subject: [Ipsec] RE: OCSP in IKEv2

From: "Dave Engberg" <[email-masked]>
Date: Mon, 16 Aug 2004 13:25:39 -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

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 23 Aug 2004 21:12:06 -0700

Dave,

It is better to think of this as OCSP-in-IKE, not OCSP-over-IKE.  That
said:

> From: Dave Engberg
> Sent: Monday, August 16, 2004 10:26 AM
>
> . . .
>

The I-D currently reads "Where it is useful to identify more than one
trusted OCSP responder, each such identification SHALL be transmitted
via separate OCSP Responder Hash CERTREQ payloads."  Is this sufficient?

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

My intent is to keep this as close as possible to the way IKEv2 does
things, especially given our SAAG discussion in San Diego re: PKI
complexity.  Hence the Responder Hash "SHALL be computed and produced in
a manner identical to that of trust anchor hashes as documented in
Section 3.7 of [IKEv2]".  I do not recall anybody having any problem
with that means of identifying CA certificates.  So why not OCSP
Responder certificates?

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

Such is not excluded by the I-D.  We make no assertions about what is at
the other end of that Responder Hash.  If an environment wants that
certificate to contain the indicator for explicit delegation of OCSP
signing, it is free to do so.  Or did I miss your point?

Mike

---

From: David Engberg <[email-masked]>
Date: Tue, 24 Aug 2004 08:02:17 -0400

> via separate OCSP Responder Hash CERTREQ payloads."  Is this sufficient?

Ah, right ... missed that.  Thanks.

> with that means of identifying CA certificates.  So why not OCSP

A trust anchor certificate (e.g. a self-signed root) should be extremely 
long-lived, so a hash of the entire certificate will be a relatively 
safe way to refer to that anchor.  Even if the root CA does need to 
generate a new certificate, proper key rollover procedures may permit 
chaining back to the old root.  This would allow clients to continue 
operating without requiring an immediate local change at every laptop.

The lifecycle for a responder certificate could be much more dynamic. 
For example, the most maintainable OCSP infrastructures (IMHO) use 
pkix-ocsp-nocheck along with shorter-lived responder certs to avoid the 
problem of determining responder revocation.  Responder certs don't have 
any way to do "rollover" to a new cert with implicit trust for existing 
clients.  This means that any change to the responder cert requires a 
local change on every peer device.

> signing, it is free to do so.  Or did I miss your point?

Sorry, I meant that it would be useful to allow the "service" side to 
send an OCSPResponse along with a delegated/chained responder cert that 
isn't explicitly known to the "client" before the transaction starts.

This would allow the client to say, "You may send me a response signed 
by any proper delegated responder cert."  The client receives the 
responder cert with the response, and confirms the chaining delegation 
to the CA.  This permits the greatest flexibility in the responder 
management without introducing another hard-coded trust point in every 
client.
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 24 Aug 2004 07:28:16 -0700

Dave,

Your clarifications below sound much more like a PKI problem than an
IPSEC need.  It is not my intent to use this I-D to patch around known
difficulties in configuring and managing a PKI.  So I think these two
points are out of scope.  I am willing be convinced otherwise but that
would take some discussion from folks on the IPSEC side of this I-D.

Mike

-----Original Message-----
From: David Engberg
Sent: Tuesday, August 24, 2004 5:02 AM

. . .

The lifecycle for a responder certificate could be much more dynamic
[than a root CA cert].
Responder certs don't have any way to do "rollover" to a new cert with
implicit trust for existing clients.  This means that any change to the
responder cert requires a local change on every peer device.

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

[By that I mean] it would be useful to allow the "service" side to send
an OCSPResponse along with a delegated/chained responder cert that isn't
explicitly known to the "client" before the transaction starts. . . .
This permits the greatest flexibility in the responder
management without introducing another hard-coded trust point in every
client.