Online Certificate Status Protocol (OCSP) Extensions to IKEv2
Extracted elements (17)
CRLs can grow unbounded and multi-megabyte CRLs are impractical for in-band IKE exchange, especially in bandwidth-limited environments. Out-of-band CRL retrieval can create a deadlock if IPsec/IKE is required to access the CRL server. OCSP responses are small and bounded, making them suitable for in-band IKEv2 signaling.
The OCSP request in this extension uses responder certificate hashes rather than a full OCSP request syntax because the Responder does not yet possess the Initiator's certificate at the time it must signal OCSP support. Hashes serve as index values enabling OCSP responses to be produced before the corresponding certificate is known, provided OCSP nonces are not used.
Absence of an OCSP response CERT payload after sending an OCSP request CERTREQ may indicate the peer does not support this extension. Nodes SHOULD be configured to require a response only when all peers are known to support it; otherwise they should fall back to other revocation-checking means if no response is received.
In the EAP scenario, OCSP applies only to the server-side IKEv2 certificate, not to certificates used within EAP methods by the EAP peer or EAP server. In the event of conflict between this document and IKEv2 (RFC 4306) regarding the EAP illustrations, RFC 4306 SHALL dominate.
An OCSP request CERTREQ SHALL be transmitted separate from any other CERTREQ payloads in an IKEv2 exchange, because there is no means to indicate which trust anchor hash (if any) relates to a trusted OCSP responder.
An OCSP response CERT payload SHALL be transmitted separate from any other CERT payload in an IKEv2 exchange.
The Certificate Data field of an OCSP response CERT payload SHALL contain a DER-encoded OCSPResponse structure as defined in RFC 2560.
The Certification Authority value in an OCSP request CERTREQ SHALL be computed and produced identically to trust anchor hashes as documented in Section 3.7 of IKEv2.
Upon receipt of an OCSP request CERTREQ payload, the recipient SHOULD acquire the related OCSP-based assertion and produce and transmit an OCSP response CERT payload corresponding to the certificate needed to verify its IKEv2 signature payloads.
Upon receipt of an OCSP response CERT payload corresponding to a prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the OCSP response into path validation logic defined by RFC 3280.
Where more than one trusted OCSP responder is to be identified, each responder hash SHALL be concatenated in the Certificate Authority field using the same method as for trust anchor hashes in Section 3.7 of IKEv2 (RFC 4306).
A new Cert Encoding value of 14 ('OCSP Content') is defined for use in both CERTREQ and CERT payloads in IKEv2. When used in a CERTREQ, it signals an OCSP request; when used in a CERT, it carries an OCSP response.
An OCSP request is a CERTREQ payload with Cert Encoding value 14 ('OCSP Content'). Its Certificate Authority field contains zero or more SHA-1 hashes of trusted OCSP responder certificates, identifying Trusted Responders (case b of RFC 2560 Section 2.2); for CA-signed or CA-designated responders no hashes are needed.
An OCSP response is a CERT payload with Cert Encoding value 14 ('OCSP Content'). Its Certificate Data field contains a DER-encoded OCSPResponse structure as defined in RFC 2560. Correlation to the certificate being validated is achieved by matching the OCSP response CertID field to the certificate.
This document assigns Cert Encoding value 14 ('OCSP Content') in the IKEv2 Certificate Payload Cert Encoding table (Section 3.6 of RFC 4306). The assignment was obtained from IANA.
The OCSP request format defined by this document cannot accommodate OCSP nonces (as defined in RFC 2560 Section 4.4.1), meaning pre-produced OCSP responses must be used. This introduces replay vulnerability: an old 'good' response could be replayed after the certificate has been revoked but before the response expires. Nodes SHOULD make OCSP response freshness requirements configurable.
The Certificate Data field of an OCSP response CERT payload SHALL contain a DER-encoded OCSPResponse structure as defined in RFC 2560. The Cert Encoding field value is 14 ('OCSP Content').