Online Certificate Status Protocol (OCSP) Extensions to IKEv2
RFC 4806

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Network Working Group                                           M. Myers
Request for Comments: 4806                       TraceRoute Security LLC
Category: Standards Track                                  H. Tschofenig
                                           Siemens Networks GmbH & Co KG
                                                           February 2007

     Online Certificate Status Protocol (OCSP) Extensions to IKEv2

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   While the Internet Key Exchange Protocol version 2 (IKEv2) supports
   public key based authentication, the corresponding use of in-band
   Certificate Revocation Lists (CRL) is problematic due to unbounded
   CRL size.  The size of an Online Certificate Status Protocol (OCSP)
   response is however well-bounded and small.  This document defines
   the "OCSP Content" extension to IKEv2.  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.

   When certificates are used with IKEv2, the communicating peers need a
   mechanism to determine the revocation status of the peer's
   certificate.  OCSP is one such mechanism.  This document applies when
   OCSP is desired and security policy prevents one of the IKEv2 peers
   from accessing the relevant OCSP responder directly.  Firewalls are
   often deployed in a manner that prevents such access by IKEv2 peers
   outside of an enterprise network.

Myers & Tschofenig          Standards Track                     [Page 1]
RFC 4806                OCSP Extensions to IKEv2           February 2007

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Extension Definition . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  OCSP Request . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  OCSP Response  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Extension Requirements . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Request for OCSP Support . . . . . . . . . . . . . . . . .  5
     4.2.  Response to OCSP Support . . . . . . . . . . . . . . . . .  6
   5.  Examples and Discussion  . . . . . . . . . . . . . . . . . . .  6
     5.1.  Peer to Peer . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Extended Authentication Protocol (EAP) . . . . . . . . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  9

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.

Myers & Tschofenig          Standards Track                     [Page 2]
RFC 4806                OCSP Extensions to IKEv2           February 2007

   OCSP [RFC2560] offers a useful alternative.  The size of an OCSP