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
Attachment:
smime.p7s
Description: application/pkcs7-signature
_______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec