<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3279 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3279.xml">
<!ENTITY RFC2560 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2560.xml">
<!ENTITY RFC4732 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4732.xml">
<!ENTITY RFC5019 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5019.xml">
<!ENTITY RFC5912 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml">
<!ENTITY RFC6960 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6960.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC4086 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml">
]> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-ietf-lamps-ocsp-nonce-05"
     category="std" consensus="true" docName="draft-ietf-lamps-ocsp-nonce-05"
     number="8954" ipr="trust200902" updates="6960"> updates="6960"  obsoletes=""
     xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true"
     version="3">

  <!-- xml2rfc v2v3 conversion 3.2.1 -->
  <!-- Generated by id2xml 1.5.0 on 2020-03-02T06:24:23Z -->
	<?rfc compact="yes"?>
	<?rfc text-list-symbols="*o+-"?>
	<?rfc subcompact="no"?>
	<?rfc sortrefs="no"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<?rfc toc="yes"?>
  <front>
	<title>OCSP

    <title abbrev="OCSP Nonce Extension">Online Certificate Status Protocol
    (OCSP) Nonce Extension</title>
    <seriesInfo name="RFC" value="8954"/>
    <author initials="M." surname="Sahni" fullname="Mohit Sahni" role="editor">
      <organization>Palo Alto Networks</organization>
      <address>
        <postal>
          <street>3000 Tannery Way</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95054</code>
	<country>US</country>
          <country>United States of America</country>
        </postal>
        <email>msahni@paloaltonetworks.com</email>
      </address>
    </author>
    <date day="10" month="September" month="November" year="2020"/>
    <workgroup>LAMPS</workgroup>
	<abstract><t>

<keyword>OCSP Nonce Length</keyword>
<keyword>OCSP Nonce Randomness</keyword>

    <abstract>
      <t>
   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 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.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   This document updates the usage and format of the Nonce extension
   used
   in OCSP request and response messages. This extension was
   previously defined in section 4.4.1 of <xref target="RFC6960"/>. target="RFC6960"
   sectionFormat="of" section="4.4.1"/>. <xref target="RFC6960"/> target="RFC6960" format="default"/>
   does not mention any minimum and or maximum length of the nonce in the Nonce
   extension.

   Lacking limits on the length of the nonce in the Nonce extension, an OCSP
   responders that follow <xref target="RFC6960"/> target="RFC6960" format="default"/> may be
   vulnerable to various attacks attacks,  like Denial of Service Denial-of-Service attacks <xref target="RFC4732"/>, chosen
   prefix
   target="RFC4732" format="default"/> or chosen-prefix attacks to (to get a desired signature, signature), and
   possible evasions using the Nonce extension data. This
   document specifies a lower limit of 1 and an upper limit of 32 to for the
   length of the nonce in the Nonce extension.  This document updates <xref target="RFC6960"/>.</t>
   target="RFC6960" format="default"/>.</t>
      <section title="Terminology" anchor="sect-1.1"><t> anchor="sect-1.1" numbered="true" toc="default">
        <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section title="OCSP Extensions" anchor="sect-2"><t> anchor="sect-2" numbered="true" toc="default">
      <name>OCSP Extensions</name>
      <t>
   The message format formats for OCSP request requests and response is responses are defined in
   <xref target="RFC6960"/>. target="RFC6960" format="default"/>. <xref target="RFC6960"/> target="RFC6960"
   format="default"/> also defines the standard extensions for OCSP
   messages based on the extension model employed in X.509 version 3
   certificates (see <xref target="RFC5280"/>). target="RFC5280" format="default"/>). This document
   only specifies the new format for the Nonce extension and
   does not change specification the specifications of any of the other standard extensions
      defined in <xref target="RFC6960"/>.</t> target="RFC6960" format="default"/>.</t>
      <section title="Nonce Extension" anchor="sect-2.1"> <t>
   This anchor="sect-2.1" numbered="true" toc="default">
        <name>Nonce Extension</name>
        <t>This section replaces the entirety of the Section 4.4.1 of <xref target="RFC6960"/> target="RFC6960"
	sectionFormat="of" section="4.4.1"/>, which describes the OCSP Nonce extension.
   </t><t>
	extension.</t>
        <t>
   The nonce cryptographically binds a request and a response to
   prevent replay attacks. The nonce is included as one of the
   requestExtensions in requests, while requests; in responses 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 present, then the length of the nonce MUST <bcp14>MUST</bcp14> be at
   least 1 octet and can be up to 32 octets.
        </t>
   <t>
   A
        <t>A server MUST <bcp14>MUST</bcp14> reject any OCSP request having that has a nonce
	in the Nonce extension with a length of either 0 octets or more than 32 octets
	with the malformedRequest
   OCSPResponseStatus OCSPResponseStatus, as described in section 4.2.1 of <xref target="RFC6960"/>.
   </t>
	target="RFC6960" sectionFormat="of" section="4.2.1"/>.</t>
        <t>
   The value of the nonce MUST <bcp14>MUST</bcp14> be generated using a cryptographically
   strong pseudorandom number generator (see <xref target="RFC4086"/>). target="RFC4086" format="default"/>).
   The minimum nonce length of 1 octet is defined to provide
   backward compatibility with older clients that follow [RFC6960]. <xref
   target="RFC6960" format="default"/>.
   Newer OCSP clients that support this document MUST <bcp14>MUST</bcp14> use a
   length of 32 octets for the nonce in the Nonce extension. OCSP responders
   MUST
   <bcp14>MUST</bcp14> accept lengths of at least 16 octets, octets and  MAY  <bcp14>MAY</bcp14> choose to
   ignore the Nonce extension for requests where the length of the nonce is less than 16 octets octets.
        </t>

	<figure><artwork><![CDATA[

<sourcecode type="asn.1"><![CDATA[
   id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
   id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

   Nonce ::= OCTET STRING(SIZE(1..32))
]]></artwork>
	</figure>
]]></sourcecode>
      </section>
    </section>
    <section title="Security Considerations" anchor="sect-3"> anchor="sect-3" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
      The security considerations of OCSP, in general, are described in
      <xref target="RFC6960"/>. target="RFC6960" format="default"/>. 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 nonce value in the OCSP
      response makes sure that the response is the latest response from
      the server and not an old copy.
      </t>
      <section title="Replay Attack" anchor="sect-3-1"> anchor="sect-3-1" numbered="true" toc="default">
        <name>Replay Attack</name>
        <t>
   The Nonce extension is used to avoid replay attacks. Since the OCSP
   responder may choose to not to send the Nonce extension in the OCSP
   response even if the client has sent the Nonce extension in the
   request <xref target="RFC5019"/>, target="RFC5019" format="default"/>, 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.
</t>
      </section>
      <section title="Nonce Collision" anchor="sect-3-2"> anchor="sect-3-2" numbered="true" toc="default">
        <name>Nonce Collision</name>
        <t>
   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 Therefore, the value of the Nonce extension in the OCSP
   request MUST <bcp14>MUST</bcp14> contain cryptographically strong randomness and MUST <bcp14>MUST</bcp14> be
   freshly generated at the time of creating the creation of the OCSP request. Also Also,
   if the length of the nonce is too small e.g. (e.g., 1 octet octet), then
   an on-path attacker can prefetch responses with all the possible
   values of the nonce and replay a matching nonce.
        </t>
      </section>
    </section>
    <section title="IANA Considerations" anchor="sect-4"> anchor="sect-4" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document does not call for any has no IANA actions.</t>
    </section>
    <section title="Changes anchor="sect-5" numbered="true" toc="default">
      <name>Changes to Appendix B. B of RFC 6960" anchor="sect-5"> 6960</name>
      <t>
	This section updates the ASN.1 definitions of the OCSP Nonce extension
	in Appendix B.1 Appendices <xref target="RFC6960"
	section="B.1" sectionFormat="bare"/> and Appendix B.2 <xref target="RFC6960"
	section="B.2" sectionFormat="bare"/> of <xref target="RFC6960"/>
	The target="RFC6960"/>.
	Appendix B.1 <xref target="RFC6960" section="B.1" sectionFormat="bare"/>
	defines OCSP using ASN.1 - 1998 Syntax and Syntax; Appendix B.2 <xref
	target="RFC6960" section="B.2" sectionFormat="bare"/> defines OCSP
      using ASN.1 - 2008 Syntax
	</t> Syntax.</t>
      <section title="Changes anchor="sect-5-1" numbered="true" toc="default">
        <name>Changes to Appendix B.1. B.1 OCSP in ASN.1 - 1998 Syntax" anchor="sect-5-1"> Syntax</name>
        <t>OLD Syntax: </t>
        <t>The definition of OCSP Nonce Extension extension is not provided in Appendix B.1 of <xref target="RFC6960"/>
	target="RFC6960" sectionFormat="of" section="B.1"/> for the ASN.1 -
	1998 Syntax.</t>
        <t>NEW Syntax: </t>
<figure><artwork><![CDATA[
<sourcecode type="asn.1"><![CDATA[
    Nonce ::= OCTET STRING(SIZE(1..32))
]]></artwork>
</figure>
]]></sourcecode>
      </section>
      <section title="Changes anchor="sect-5-2" numbered="true" toc="default">
        <name>Changes to Appendix B.2 OCSP in ASN.1 - 2008 Syntax" anchor="sect-5-2"> Syntax</name>
        <t>OLD Syntax: </t>
    <figure><artwork><![CDATA[
<sourcecode type="asn.1"><![CDATA[
    re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED
        BY id-pkix-ocsp-nonce }

]]></artwork>
</figure>
]]></sourcecode>
        <t>NEW Syntax: </t>
    <figure><artwork><![CDATA[
<sourcecode type="asn.1"><![CDATA[
    re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING(SIZE(1..32))
        IDENTIFIED BY id-pkix-ocsp-nonce }
]]></artwork>
	</figure>
]]></sourcecode>
      </section>
    </section>
  </middle>
  <back>
	<references title="Normative References">
	<reference anchor="RFC2119" target="http://www.rfc-editor.org/info/rfc2119"><front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>
	<author fullname="S. Bradner" initials="S." surname="Bradner">
	</author>

	<date month="March" year="1997"/>
	</front>

	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
	<front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
            </author>
            <date year="2017" month="May"/>
	</front>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
        </reference>
	&RFC5280;
	&RFC6960;
    <references>
      <name>References</name>
      <references>

        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6960.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4732.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5019.xml"/>
      </references>
	<references title="Informative References">
	&RFC4086;
	&RFC4732;
	&RFC5019;
    </references>
  </back>
</rfc>