{"draft":"draft-myers-ikev2-ocsp-05","doc_id":"RFC4806","title":"Online Certificate Status Protocol (OCSP) Extensions to IKEv2","authors":["M. Myers","H. Tschofenig"],"format":["ASCII","HTML"],"page_count":"11","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"IETF - NON WORKING GROUP","abstract":"While the Internet Key Exchange Protocol version 2 (IKEv2) supports\r\npublic key based authentication, the corresponding use of in-band\r\nCertificate Revocation Lists (CRL) is problematic due to unbounded\r\nCRL size.  The size of an Online Certificate Status Protocol (OCSP)\r\nresponse is however well-bounded and small.  This document defines\r\nthe \"OCSP Content\" extension to IKEv2.  A CERTREQ payload with \"OCSP\r\nContent\" identifies zero or more trusted OCSP responders and is a\r\nrequest for inclusion of an OCSP response in the IKEv2 handshake.  A\r\ncooperative recipient of such a request responds with a CERT payload\r\ncontaining the appropriate OCSP response.  This content is\r\nrecognizable via the same \"OCSP Content\" identifier.\r\n\r\nWhen certificates are used with IKEv2, the communicating peers need a\r\nmechanism to determine the revocation status of the peer's\r\ncertificate.  OCSP is one such mechanism.  This document applies when\r\nOCSP is desired and security policy prevents one of the IKEv2 peers\r\nfrom accessing the relevant OCSP responder directly.  Firewalls are\r\noften deployed in a manner that prevents such access by IKEv2 peers\r\noutside of an enterprise network.  [STANDARDS-TRACK]","pub_date":"February 2007","keywords":["[--------|p]","internet key exchange version 2"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC4806","errata_url":null}