diff options
Diffstat (limited to 'doc/rfc/rfc8954.txt')
| -rw-r--r-- | doc/rfc/rfc8954.txt | 252 |
1 files changed, 252 insertions, 0 deletions
diff --git a/doc/rfc/rfc8954.txt b/doc/rfc/rfc8954.txt new file mode 100644 index 0000000..ee252eb --- /dev/null +++ b/doc/rfc/rfc8954.txt @@ -0,0 +1,252 @@ + + + + +Internet Engineering Task Force (IETF) M. Sahni, Ed. +Request for Comments: 8954 Palo Alto Networks +Updates: 6960 November 2020 +Category: Standards Track +ISSN: 2070-1721 + + + Online Certificate Status Protocol (OCSP) Nonce Extension + +Abstract + + 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. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8954. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 1.1. Terminology + 2. OCSP Extensions + 2.1. Nonce Extension + 3. Security Considerations + 3.1. Replay Attack + 3.2. Nonce Collision + 4. IANA Considerations + 5. Changes to Appendix B of RFC 6960 + 5.1. Changes to Appendix B.1 OCSP in ASN.1 - 1998 Syntax + 5.2. Changes to Appendix B.2 OCSP in ASN.1 - 2008 Syntax + 6. References + 6.1. Normative References + 6.2. Informative References + Author's Address + +1. Introduction + + This document updates the usage and format of the Nonce extension in + OCSP request and response messages. This extension was previously + defined in Section 4.4.1 of [RFC6960]. [RFC6960] 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 [RFC6960] may be vulnerable to various + attacks, like Denial-of-Service attacks [RFC4732] 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 [RFC6960]. + +1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. OCSP Extensions + + The message formats for OCSP requests and responses are defined in + [RFC6960]. [RFC6960] also defines the standard extensions for OCSP + messages based on the extension model employed in X.509 version 3 + certificates (see [RFC5280]). 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 [RFC6960]. + +2.1. Nonce Extension + + This section replaces the entirety of Section 4.4.1 of [RFC6960], + 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 + Section 4.2.1 of [RFC6960]. + + The value of the nonce MUST be generated using a cryptographically + strong pseudorandom number generator (see [RFC4086]). The minimum + nonce length of 1 octet is defined to provide backward compatibility + with older clients that follow [RFC6960]. 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. + + id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } + id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } + + Nonce ::= OCTET STRING(SIZE(1..32)) + +3. Security Considerations + + The security considerations of OCSP, in general, are described in + [RFC6960]. 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. + +3.1. 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 [RFC5019], 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. + +3.2. 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. + +4. IANA Considerations + + This document has no IANA actions. + +5. Changes to Appendix B of RFC 6960 + + This section updates the ASN.1 definitions of the OCSP Nonce + extension in Appendices B.1 and B.2 of [RFC6960]. Appendix B.1 + defines OCSP using ASN.1 - 1998 Syntax; Appendix B.2 defines OCSP + using ASN.1 - 2008 Syntax. + +5.1. Changes to Appendix B.1 OCSP in ASN.1 - 1998 Syntax + + OLD Syntax: + + The definition of OCSP Nonce extension is not provided in + Appendix B.1 of [RFC6960] for the ASN.1 - 1998 Syntax. + + NEW Syntax: + + Nonce ::= OCTET STRING(SIZE(1..32)) + +5.2. Changes to Appendix B.2 OCSP in ASN.1 - 2008 Syntax + + OLD Syntax: + + re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED + BY id-pkix-ocsp-nonce } + + NEW Syntax: + + re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING(SIZE(1..32)) + IDENTIFIED BY id-pkix-ocsp-nonce } + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + <https://www.rfc-editor.org/info/rfc5280>. + + [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., + Galperin, S., and C. Adams, "X.509 Internet Public Key + Infrastructure Online Certificate Status Protocol - OCSP", + RFC 6960, DOI 10.17487/RFC6960, June 2013, + <https://www.rfc-editor.org/info/rfc6960>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +6.2. Informative References + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + <https://www.rfc-editor.org/info/rfc4086>. + + [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet + Denial-of-Service Considerations", RFC 4732, + DOI 10.17487/RFC4732, December 2006, + <https://www.rfc-editor.org/info/rfc4732>. + + [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online + Certificate Status Protocol (OCSP) Profile for High-Volume + Environments", RFC 5019, DOI 10.17487/RFC5019, September + 2007, <https://www.rfc-editor.org/info/rfc5019>. + +Author's Address + + Mohit Sahni (editor) + Palo Alto Networks + 3000 Tannery Way + Santa Clara, CA 95054 + United States of America + + Email: msahni@paloaltonetworks.com |