draft-ietf-lamps-ocsp-nonce-04.txt | draft-ietf-lamps-ocsp-nonce-05.txt | |||
---|---|---|---|---|
LAMPS M. Sahni, Ed. | LAMPS M. Sahni, Ed. | |||
Internet-Draft Palo Alto Networks | Internet-Draft Palo Alto Networks | |||
Updates: 6960 (if approved) September 2, 2020 | Updates: 6960 (if approved) September 10, 2020 | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: March 6, 2021 | Expires: March 14, 2021 | |||
OCSP Nonce Extension | OCSP Nonce Extension | |||
draft-ietf-lamps-ocsp-nonce-04 | draft-ietf-lamps-ocsp-nonce-05 | |||
Abstract | Abstract | |||
This document specifies the updated format of the Nonce extension in | This document specifies the updated format of the Nonce extension in | |||
Online Certificate Status Protocol (OCSP) request and response | the Online Certificate Status Protocol (OCSP) request and response | |||
messages. OCSP is used to check the status of a certificate and the | messages. OCSP is used to check the status of a certificate and the | |||
Nonce extension is used in the OCSP request and response messages to | Nonce extension is used to cryptographically bind an OCSP response | |||
avoid replay attacks. This document updates the RFC 6960. | message to a particular OCSP request message. This document updates | |||
RFC 6960. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on March 6, 2021. | This Internet-Draft will expire on March 14, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. OCSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. OCSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2.1. Nonce Extension . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Nonce Extension . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 | |||
3.1. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 4 | 3.1. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.2. Nonce Collision . . . . . . . . . . . . . . . . . . . . . 4 | 3.2. Nonce Collision . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |||
5. Changes to Appendix B. of RFC 6960 . . . . . . . . . . . . . 5 | 5. Changes to Appendix B. of RFC 6960 . . . . . . . . . . . . . 4 | |||
5.1. Changes to Appendix B.1. OCSP in ASN.1 - 1998 Syntax . . 5 | 5.1. Changes to Appendix B.1. OCSP in ASN.1 - 1998 Syntax . . 4 | |||
5.2. Changes to Appendix B.2 OCSP in ASN.1 - 2008 Syntax . . . 5 | 5.2. Changes to Appendix B.2 OCSP in ASN.1 - 2008 Syntax . . . 5 | |||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
6.1. Normative References . . . . . . . . . . . . . . . . . . 5 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 | |||
6.2. Informative References . . . . . . . . . . . . . . . . . 6 | 6.2. Informative References . . . . . . . . . . . . . . . . . 5 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1. Introduction | 1. Introduction | |||
This document updates the usage and format of the Nonce extension | This document updates the usage and format of the Nonce extension | |||
used in OCSP request and response messages. This extension was | used in OCSP request and response messages. This extension was | |||
previously defined in section 4.4.1 of [RFC6960]. The [RFC6960] does | previously defined in section 4.4.1 of [RFC6960]. [RFC6960] does not | |||
not mention any minimum and maximum length of the nonce extension. | mention any minimum and maximum length of nonce in the Nonce | |||
Due to not having an upper or lower limit of the length of the Nonce | extension. Lacking limits on the length of nonce in the Nonce | |||
extension, the OCSP responders that follow [RFC6960] may be | extension, an OCSP responders that follow [RFC6960] may be vulnerable | |||
vulnerable to various attacks like Denial of Service attacks | to various attacks like Denial of Service attacks [RFC4732], chosen | |||
[RFC4732], chosen prefix attacks to get a desired signature from the | prefix attacks to get a desired signature, and possible evasions | |||
OCSP responder and possible evasions that can use the Nonce extension | using the Nonce extension data. This document specifies a lower | |||
data for evasion. This document specifies a lower limit of 1 and an | limit of 1 and an upper limit of 32 to the length of nonce in the | |||
upper limit of 32 to the length of the Nonce extension. This | Nonce extension. This document updates [RFC6960]. | |||
document updates the [RFC6960]. | ||||
1.1. Terminology | 1.1. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2. OCSP Extensions | 2. OCSP Extensions | |||
The message format for the OCSP request and response is defined in | The message format for OCSP request and response is defined in | |||
the [RFC6960]. [RFC6960] also defines the standard extensions for | [RFC6960]. [RFC6960] also defines the standard extensions for OCSP | |||
OCSP messages based on the extension model employed in X.509 version | messages based on the extension model employed in X.509 version 3 | |||
3 certificates (see [RFC5280]). The following is a list of standard | certificates (see [RFC5280]). This document only specifies the new | |||
extensions that can be used in the OCSP messages by the OCSP | format for Nonce extension and does not change specification of any | |||
responder and OCSP client. | of the other standard extensions defined in [RFC6960]. | |||
* Nonce | ||||
* CRL References | ||||
* Acceptable Response Types | ||||
* Archive Cutoff | ||||
* CRL Entry Extensions | ||||
* Service Locator | ||||
* Preferred Signature Algorithms | ||||
* Extended Response Definition | ||||
This document only specifies the new format for Nonce extension and | ||||
does not change the specification of any of the other standard | ||||
extensions. | ||||
2.1. Nonce Extension | 2.1. Nonce Extension | |||
This section replaces the entirety of the Section 4.4.1 of [RFC6960] | This section replaces the entirety of the Section 4.4.1 of [RFC6960] | |||
which describes the OCSP Nonce extension. | which describes the OCSP Nonce extension. | |||
The nonce cryptographically binds a request and a response to prevent | The nonce cryptographically binds a request and a response to prevent | |||
replay attacks. The nonce is included as one of the | replay attacks. The nonce is included as one of the | |||
requestExtensions in requests, while in responses it would be | requestExtensions in requests, while in responses it would be | |||
included as one of the responseExtensions. In both the request and | included as one of the responseExtensions. In both the request and | |||
the response, the nonce will be identified by the object identifier | the response, the nonce will be identified by the object identifier | |||
id-pkix-ocsp-nonce, while the extnValue is the value of the nonce. | id-pkix-ocsp-nonce, while the extnValue is the value of the nonce. | |||
If Nonce extension is present then the length of nonce MUST be at | If Nonce extension is present then the length of nonce MUST be at | |||
least 1 octet and can be up to 32 octets. | least 1 octet and can be up to 32 octets. | |||
A server MUST reject any OCSP request having a Nonce extension with | A server MUST reject any OCSP request having a nonce in the Nonce | |||
length of 0 octets or more than 32 octets with the malformedRequest | extension with length of 0 octets or more than 32 octets with the | |||
OCSPResponseStatus as described in section 4.2.1 of [RFC6960]. | malformedRequest OCSPResponseStatus as described in section 4.2.1 of | |||
[RFC6960]. | ||||
The value of the nonce MUST be generated using a cryptographically | The value of the nonce MUST be generated using a cryptographically | |||
strong pseudorandom number generator (see [RFC4086]). The OCSP | strong pseudorandom number generator (see [RFC4086]). The minimum | |||
clients SHOULD use a length of 32 octets for the Nonce extension. | nonce length of 1 octet is defined to provide backward compatibility | |||
The minimum nonce length of 1 octet is defined to provide the | with older clients that follow [RFC6960]. Newer OCSP clients that | |||
backward compatibility with older clients following [RFC6960] | support this document MUST use a length of 32 octets for the nonce in | |||
however, the newer OCSP clients MUST use a length of at least 16 | Nonce extension. OCSP responders MUST accept lengths of at least 16 | |||
octets for Nonce extension. The OCSP responder MAY choose to ignore | octets, and MAY choose to ignore the Nonce extension for requests | |||
Nonce extension for the requests where length of the Nonce extension | where the length of the nonce is less than 16 octets | |||
is less than 16 octets. | ||||
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } | id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } | |||
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } | id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } | |||
Nonce ::= OCTET STRING(SIZE(1..32)) | Nonce ::= OCTET STRING(SIZE(1..32)) | |||
3. Security Considerations | 3. Security Considerations | |||
The security considerations of OCSP, in general, are described in the | The security considerations of OCSP, in general, are described in | |||
[RFC6960]. The Nonce extension is used to avoid replay attacks | [RFC6960]. During the interval in which the previous OCSP response | |||
during the interval in which the previous OCSP response for a | for a certificate is not expired but the responder has a changed | |||
certificate is not expired but the responder has a changed status for | status for that certificate, a copy of that OCSP response can be used | |||
that certificate. Including client's Nonce value in the OCSP | to indicate that the status of the certificate is still valid. | |||
response makes sure that the response is the latest response from the | Including client's Nonce value in the OCSP response makes sure that | |||
server and not an old copy. | the response is the latest response from the server and not an old | |||
copy. | ||||
3.1. Replay Attack | 3.1. Replay Attack | |||
The Nonce extension is used to avoid replay attacks. Since the OCSP | The Nonce extension is used to avoid replay attacks. Since the OCSP | |||
responder may choose to not send the Nonce extension in the OCSP | responder may choose to not send the Nonce extension in the OCSP | |||
response even if the client has sent the Nonce extension in the | response even if the client has sent the Nonce extension in the | |||
request [RFC5019], an on-path attacker can intercept the OCSP request | request [RFC5019], an on-path attacker can intercept the OCSP request | |||
and respond with an earlier response from the server without the | and respond with an earlier response from the server without the | |||
Nonce extension. This can be mitigated by configuring the server to | Nonce extension. This can be mitigated by configuring the server to | |||
use a short time interval between thisUpdate and nextUpdate fields in | use a short time interval between the thisUpdate and nextUpdate | |||
the OCSP response. | fields in the OCSP response. | |||
3.2. Nonce Collision | 3.2. Nonce Collision | |||
If the value of the nonce used by a client in OCSP request is not | If the value of nonce used by a client in OCSP request is | |||
random enough, then an attacker may prefetch responses with the | predictable, then an attacker may prefetch responses with the | |||
predicted nonce and can replay them, thus defeating the purpose of | predicted nonce and can replay them, thus defeating the purpose of | |||
using nonce. Therefore the value of Nonce extension in the OCSP | using nonce. Therefore the value of Nonce extension in the OCSP | |||
request MUST contain cryptographically strong randomness and MUST be | request MUST contain cryptographically strong randomness and MUST be | |||
freshly generated at the time of creating the OCSP request. Also if | freshly generated at the time of creating the OCSP request. Also if | |||
the length of the nonce extension is too small e.g. 1 octet then an | the length of nonce is too small e.g. 1 octet then an on-path | |||
on-path attacker can prefetch responses with all the possible values | attacker can prefetch responses with all the possible values of nonce | |||
of the nonce and replay a matching nonce. | and replay a matching nonce. | |||
4. IANA Considerations | 4. IANA Considerations | |||
This document does not call for any IANA actions. | This document does not call for any IANA actions. | |||
5. Changes to Appendix B. of RFC 6960 | 5. Changes to Appendix B. of RFC 6960 | |||
This section updates the ASN.1 definitions of the OCSP Nonce | This section updates the ASN.1 definitions of the OCSP Nonce | |||
extension in the Appendix B.1 and Appendix B.2 of the [RFC6960] The | extension in Appendix B.1 and Appendix B.2 of [RFC6960] The | |||
Appendix B.1 defines OCSP using ASN.1 - 1998 Syntax and Appendix B.2 | Appendix B.1 defines OCSP using ASN.1 - 1998 Syntax and Appendix B.2 | |||
defines OCSP using ASN.1 - 2008 Syntax | defines OCSP using ASN.1 - 2008 Syntax | |||
5.1. Changes to Appendix B.1. OCSP in ASN.1 - 1998 Syntax | 5.1. Changes to Appendix B.1. OCSP in ASN.1 - 1998 Syntax | |||
OLD Syntax: | OLD Syntax: | |||
The definition of OCSP Nonce Extension is not provided in the | The definition of OCSP Nonce Extension is not provided in | |||
Appendix B.1 of [RFC6960] for the ASN.1 - 1998 Syntax. | Appendix B.1 of [RFC6960] for the ASN.1 - 1998 Syntax. | |||
NEW Syntax: | NEW Syntax: | |||
Nonce ::= OCTET STRING(SIZE(1..32)) | Nonce ::= OCTET STRING(SIZE(1..32)) | |||
5.2. Changes to Appendix B.2 OCSP in ASN.1 - 2008 Syntax | 5.2. Changes to Appendix B.2 OCSP in ASN.1 - 2008 Syntax | |||
OLD Syntax: | OLD Syntax: | |||
End of changes. 20 change blocks. | ||||
68 lines changed or deleted | 56 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |