Online Certificate Status Protocol
(OCSP) Nonce Extension
Palo Alto Networks
3000 Tannery Way
Santa Clara
CA
95054
United States of America
msahni@paloaltonetworks.com
LAMPS
OCSP Nonce Length
OCSP Nonce Randomness
This document specifies the updated format of the Nonce extension in the
Online Certificate Status Protocol (OCSP) request and response
messages. OCSP is used to check the status of a certificate, and
the Nonce extension is used to cryptographically bind an OCSP
response message to a particular OCSP request message. This document updates RFC 6960.
Introduction
This document updates the usage and format of the Nonce extension
in OCSP request and response messages. This extension was
previously defined in .
does not mention any minimum or maximum length of the nonce in the Nonce
extension.
Lacking limits on the length of the nonce in the Nonce extension, OCSP
responders that follow may be
vulnerable to various attacks, like Denial-of-Service attacks or chosen-prefix attacks (to get a desired signature), and
possible evasions using the Nonce extension data. This
document specifies a lower limit of 1 and an upper limit of 32 for the
length of the nonce in the Nonce extension. This document updates .
Terminology
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
OCSP Extensions
The message formats for OCSP requests and responses are defined in
. also defines the standard extensions for OCSP
messages based on the extension model employed in X.509 version 3
certificates (see ). This document
only specifies the new format for the Nonce extension and
does not change the specifications of any of the other standard extensions
defined in .
Nonce Extension
This section replaces the entirety of , which describes the OCSP Nonce
extension.
The nonce cryptographically binds a request and a response to
prevent replay attacks. The nonce is included as one of the
requestExtensions in requests; in responses, it would be
included as one of the responseExtensions. In both the request and
the response, the nonce will be identified by the object identifier
id-pkix-ocsp-nonce, while the extnValue is the value of the nonce.
If the Nonce extension is present, then the length of the nonce MUST be at
least 1 octet and can be up to 32 octets.
A server MUST reject any OCSP request that has a nonce
in the Nonce extension with a length of either 0 octets or more than 32 octets
with the malformedRequest OCSPResponseStatus, as described in .
The value of the nonce MUST be generated using a cryptographically
strong pseudorandom number generator (see ).
The minimum nonce length of 1 octet is defined to provide
backward compatibility with older clients that follow .
Newer OCSP clients that support this document MUST use a
length of 32 octets for the nonce in the Nonce extension. OCSP responders
MUST accept lengths of at least 16 octets and MAY choose to
ignore the Nonce extension for requests where the length of the nonce is less than 16 octets.
Security Considerations
The security considerations of OCSP, in general, are described in
. During the interval in which
the previous OCSP response for a
certificate is not expired but the responder has a changed status for
that certificate, a copy of that OCSP response can be used to indicate
that the status of the certificate is still valid.
Including a client's nonce value in the OCSP
response makes sure that the response is the latest response from
the server and not an old copy.
Replay Attack
The Nonce extension is used to avoid replay attacks. Since the OCSP
responder may choose not to send the Nonce extension in the OCSP
response even if the client has sent the Nonce extension in the
request , an on-path attacker can intercept the OCSP request
and respond with an earlier response from the server without the
Nonce extension. This can be mitigated by configuring the server to
use a short time interval between the thisUpdate and nextUpdate fields in
the OCSP response.
Nonce Collision
If the value of the nonce used by a client in the OCSP request is
predictable, then an attacker may prefetch responses with the
predicted nonce and can replay them, thus defeating the purpose of
using the nonce. Therefore, the value of the Nonce extension in the OCSP
request MUST contain cryptographically strong randomness and MUST be
freshly generated at the time of the creation of the OCSP request. Also,
if the length of the nonce is too small (e.g., 1 octet), then
an on-path attacker can prefetch responses with all the possible
values of the nonce and replay a matching nonce.
IANA Considerations
This document has no IANA actions.
Changes to Appendix B of RFC 6960
This section updates the ASN.1 definitions of the OCSP Nonce extension
in Appendices and of .
Appendix
defines OCSP using ASN.1 - 1998 Syntax; Appendix defines OCSP
using ASN.1 - 2008 Syntax.
Changes to Appendix B.1 OCSP in ASN.1 - 1998 Syntax
OLD Syntax:
The definition of OCSP Nonce extension is not provided in for the ASN.1 -
1998 Syntax.
NEW Syntax:
Changes to Appendix B.2 OCSP in ASN.1 - 2008 Syntax
OLD Syntax:
NEW Syntax:
References
Normative References
Informative References