Online Certificate Status Protocol (OCSP) Extensions to IKEv2
RFC 4806
Document | Type |
RFC - Proposed Standard
(February 2007; No errata)
Was draft-myers-ikev2-ocsp (individual in sec area)
|
|
---|---|---|---|
Authors | Michael Myers , Hannes Tschofenig | ||
Last updated | 2018-12-20 | ||
Replaces | draft-myers-ipsec-ikev2-oscp | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4806 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | (None) |
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 OCSPShow full document text