idnits 2.17.1 draft-msahni-lamps-ocsp-nonce-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2020) is 1516 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3279' is defined on line 161, but no explicit reference was found in the text == Unused Reference: 'RFC2560' is defined on line 181, but no explicit reference was found in the text == Unused Reference: 'RFC4732' is defined on line 187, but no explicit reference was found in the text == Unused Reference: 'RFC5019' is defined on line 192, but no explicit reference was found in the text == Unused Reference: 'RFC5912' is defined on line 197, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS M. Sahni, Ed. 3 Internet-Draft Palo Alto Networks 4 Intended status: Standards Track March 1, 2020 5 Expires: September 2, 2020 7 OCSP Nonce Extension 8 draft-msahni-lamps-ocsp-nonce-00 10 Abstract 12 This document specifies the updated format of the nonce extension in 13 Online Certificate Status Protocol (OCSP) request and response 14 messages. OCSP is used to check the status of a certificate and the 15 Nonce extension is used in the OCSP request and response messages to 16 avoid replay attacks. This document updates the RFC 6960 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 2, 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. OCSP Extensions . . . . . . . . . . . . . . . . . . . . . . . 2 55 2.1. Nonce Extension . . . . . . . . . . . . . . . . . . . . . 3 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 60 5.2. Informative References . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 This document updates the usage and format of the nonce extension 66 used in OCSP request and response messages. This extension was 67 previously defined in the section 4.1.1 of [RFC6960]. The [RFC6960] 68 does not mention any minimum and maximum length of the nonce 69 extension. Due to not having an upper or lower limit of the length 70 of the nonce extension, the OCSP responders that follow [RFC6960] may 71 be vulnerable to various attacks like Denial of Service attacks, 72 chosen prefix attacks to get desired signature of the OCSP responder 73 and other possible evasions which can use nonce extension data. This 74 document specifies a lower limit of 1 and upper limit of 32 to the 75 length of the Nonce extension. This document updates the [RFC6960]. 77 1.1. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in BCP 82 14 [RFC2119] [RFC8174] when, and only when, they appear in all 83 capitals, as shown here. 85 2. OCSP Extensions 87 The message format for the OCSP request and response is defined in 88 the [RFC6960] [RFC5280]. It also defines the standard extensions for 89 OCSP messages based on the extension model employed in X.509 version 90 3 certificates (see [RFC5280]). Following is the list of standard 91 extensions that can be used in the OCSP messages by the OCSP 92 responder and OCSP client. 94 o Nonce 95 o CRL References 96 o Acceptable Response Types 97 o Archive Cutoff 98 o CRL Entry Extensions 99 o Service Locator 100 o Preferred Signature Algorithms 101 o Extended Response Definition 103 This document only specifies the new format for Nonce extension and 104 does not change specification of any of the other standard 105 extensions. 107 2.1. Nonce Extension 109 The nonce cryptographically binds a request and a response to prevent 110 replay attacks. The nonce is included as one of the 111 requestExtensions in requests, while in responses it would be 112 included as one of the responseExtensions. In both the request and 113 the response, the nonce will be identified by the object identifier 114 id-pkix-ocsp-nonce, while the extnValue is the value of the nonce. 115 If nonce extension is present then the length of nonce MUST be 116 atleast 1 byte and can be upto 32 bytes. 118 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 120 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 122 Nonce ::= OCTET STRING(SIZE(1..32)) 124 3. Security Considerations 126 The security considerations of OCSP in general are described in the 127 [RFC6960]. The nonce extension is used to avoid replay attacks during 128 the interval in which the previous OCSP response for a certificate is 129 not expired but responder has a changed status for that certificate. 130 Including client's Nonce value in the OCSP response makes sure that 131 the response is a latest response from the server and not a old copy. 133 3.1 Replay Attack 135 The nonce extension is used to avoid replay attacks. Since the 136 OCSP responder may choose to not send the nonce extension in the 137 OCSP response even if the client has sent the nonce extension in 138 the request, a man in the middle (MITM) entity can intercept the 139 OCSP request and respond with a earlier response from the server 140 without the Nonce extension. This can be mitigated by server 141 using a closer nextUpdate value in the OCSP response. 143 4. IANA Considerations 145 This document does not include any new media type registrations 146 for OCSP. 148 5. References 150 5.1. Normative References 152 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 153 Requirement Levels", BCP 14, RFC 2119, 154 DOI 10.17487/RFC2119, March 1997, 155 . 157 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 158 2119 Key Words", DOI 10.17487/RFC8174, RFC 8174, BCP 14, 159 May 2017, . 161 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 162 Identifiers for the Internet X.509 Public Key 163 Infrastructure Certificate and Certificate Revocation List 164 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 165 2002, . 167 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 168 Housley, R., and W. Polk, "Internet X.509 Public Key 169 Infrastructure Certificate and Certificate Revocation List 170 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 171 . 173 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 174 Galperin, S., and C. Adams, "X.509 Internet Public Key 175 Infrastructure Online Certificate Status Protocol - OCSP", 176 RFC 6960, DOI 10.17487/RFC6960, June 2013, 177 . 179 5.2. Informative References 181 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 182 Adams, "X.509 Internet Public Key Infrastructure Online 183 Certificate Status Protocol - OCSP", RFC 2560, 184 DOI 10.17487/RFC2560, June 1999, 185 . 187 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 188 Denial-of-Service Considerations", RFC 4732, 189 DOI 10.17487/RFC4732, December 2006, 190 . 192 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 193 Certificate Status Protocol (OCSP) Profile for High-Volume 194 Environments", RFC 5019, DOI 10.17487/RFC5019, September 195 2007, . 197 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 198 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 199 DOI 10.17487/RFC5912, June 2010, 200 . 202 Author's Address 204 Mohit Sahni (editor) 205 Palo Alto Networks 207 Email: msahni@paloaltonetworks.com