1. Introduction

   Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2]
   supports a range of authentication mechanisms, including the use of
   public key based authentication.  Confirmation of certificate
   reliability is essential in order to achieve the security assurances
   public key cryptography provides.  One fundamental element of such
   confirmation is reference to certificate revocation status (see
   [RFC3280] for additional detail).

   The traditional means of determining certificate revocation status is
   through the use of Certificate Revocation Lists (CRLs).  IKEv2 allows
   CRLs to be exchanged in-band via the CERT payload.

   However, CRLs can grow unbounded in size.  Many real-world examples
   exist to demonstrate the impracticality of including a multi-megabyte
   file in an IKE exchange.  This constraint is particularly acute in
   bandwidth-limited environments (e.g., mobile communications).  The
   net effect is exclusion of in-band CRLs in favor of out-of-band (OOB)
   acquisition of these data, should they even be used at all.

   Reliance on OOB methods can be further complicated if access to
   revocation data requires use of IPsec (and therefore IKE) to
   establish secure and authorized access to the CRLs of an IKE
   participant.  Such network access deadlock further contributes to a
   reduced reliance on the status of certificate revocations in favor of
   blind trust.

   OCSP [RFC2560] offers a useful alternative.  The size of an OCSP
   response is bounded and small and therefore suitable for in-band
   IKEv2 signaling of a certificate's revocation status.

   This document defines an extension to IKEv2 that enables the use of
   OCSP for in-band signaling of certificate revocation status.  A new
   content encoding is defined for use in the CERTREQ and CERT payloads.
   A CERTREQ payload with "OCSP Content" identifies zero or more trusted
   OCSP responders and is a request for inclusion of an OCSP response in
   the IKEv2 handshake.  A cooperative recipient of such a request
   responds with a CERT payload containing the appropriate OCSP
   response.  This content is recognizable via the same "OCSP Content"
   identifier.