idnits 2.17.1 draft-hallambaker-muststaple-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 2, 2012) is 4218 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) -- Looks like a reference, but probably isn't: '0' on line 161 -- Looks like a reference, but probably isn't: '1' on line 162 == Unused Reference: 'RFC1035' is defined on line 366, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Standards Track October 2, 2012 5 Expires: April 5, 2013 7 X.509v3 Extension: OCSP Stapling Required 8 draft-hallambaker-muststaple-00 10 Abstract 12 The purpose of the TLS Security Policy extension is to prevent 13 downgrade attacks that are not otherwise prevented by the TLS 14 protocol. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 5, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 52 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. minVersion . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. extensions . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.3. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.3.1. Certificate Signing Request . . . . . . . . . . . . . . 5 58 3.3.2. Certificate Signing Certificate . . . . . . . . . . . . 6 59 3.3.3. End Entity Certificate . . . . . . . . . . . . . . . . 6 60 3.4. Processing . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.4.1. Certification Authority . . . . . . . . . . . . . . . . 6 62 3.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.4.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Alternative Certificates and Certificate Issuers . . . . . 7 67 5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . . 7 68 5.3. Cipher Suite Downgrade Attack . . . . . . . . . . . . . . . 7 69 6. For discussion. . . . . . . . . . . . . . . . . . . . . . . . . 8 70 6.1. Cipher Suite Downgrade Attack . . . . . . . . . . . . . . . 8 71 6.2. Remove Version attribute . . . . . . . . . . . . . . . . . 8 72 6.3. Mandated client behavior . . . . . . . . . . . . . . . . . 8 73 6.4. Other protocols and applications . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 75 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Definitions 80 1.1. Requirements Language 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Purpose 88 [This could do with a re-write to start by explaining the intended 89 use od OCSP, the reasons that browsers do not normally hard fail (DoS 90 attack, flaky OCSP servers, efficiency) and that passing the OCSP 91 data in band avoids dependence on an external service but does not 92 allow the client to avoid the DoS attack or consequences of flaky 93 servers unless it knows the OCSP data is passed in band.] 95 The purpose of the TLS Security Policy extension is to prevent 96 downgrade attacks that are not otherwise prevented by the TLS 97 protocol. 99 Since the TLS protocol itself provides strong protection against most 100 forms of downgrade attack, the TLS Security Policy is only relevant 101 to the validation of TLS protocol credentials. In particular to the 102 revocation status of the credentials presented. 104 At the time of writing, the only TLS feature that is relevant to the 105 revocation status of credentials is the Certificate Status Request 106 extension (status_request) used to support in-band exchange of OCSP 107 tokens, otherwise known as OCSP stapling. This extension is 108 described in RFC 4366 [RFC4366]. 110 The TLS Security Policy mechanism described in this document is 111 designed to support policy statements that prevent a downgrade attack 112 against the current OCSP stapling mechanism and possible future 113 certificate revocation mechanisms such as stapling of multiple OCSP 114 tokens. 116 The OCSP stapling mechanism described in RFC 4366 [RFC4366] permits a 117 TLS server to provide evidence of valid certificate status inband and 118 thus improve client response. A TLS Security Policy that advertises 119 the status_request extension informs a client that if the 120 status_request is specified in a TLS Client Helo, that a server 121 compliant with the policy MUST respond with a valid OCSP token for 122 the End Entity Certificate it presents. 124 Verification of the TLS Security Policy extension in a client permits 125 the client to avoid reliance on certificates that are revoked for the 126 reasons that occur most frequently. In particular it allows a client 127 to avoid mis-reliance on certificates that are revoked for cause or 128 at the request of the subject (e.g. because of a compromised private 129 key). 131 Since the TLS Security Policy extension is an option, it is not 132 likely that an attacker attempting to obtain a certificate through 133 fraud will choose to have a certificate issued with this extension. 134 Such risks are more approrpriately addressed by mechanisms such as 135 Certificate Authority Authorization records that are designed to 136 prevent or mitigate mis-issue. Nevertheless a Certification 137 Authority MAY consider the presence or absence of a required security 138 policy as one factor in determining the level of additional scruitiny 139 a request should be subject to. 141 Any security policy specified in an End Entity certificate MUST be 142 followed by the server or clients MAY refuse connection. It is 143 important therefore that a Certification Authority only issue 144 certificates that specify policies that match the configuration of 145 the server and that the server is capable of verifying that its 146 configuration is compatible with the security policy of the 147 certificates it offers. Ideally, the TLS security policy would be 148 specified by the client as part of the certificate issue process. 150 This document describes a mechanism that MAY be used to provide this 151 communication in-band for the most commonly used certificate 152 registration protocol. 154 3. Syntax 156 The TLS Security Policy extension has the following format: 158 cabf-tls-security-policy OBJECT IDENTIFIER ::= { cabf 1 } 160 SecurityPolicy ::= SEQUENCE { 161 minVersion [0] INTEGER, 162 extensions [1] SEQUENCE OF INTEGER OPTIONAL} 164 Extension MAY be marked critical. Implementations that process the 165 extension MUST ignore the criticality bit setting. 167 3.1. minVersion 169 The minVersion element constrains the minimum version of the TLS 170 protocol to be offered as follows: 172 1 To be compliant with the policy a server MUST offer TLS version 173 1.0 or higher 175 2 To be compliant with the policy a server MUST offer TLS version 176 1.1 or higher 178 3 To be compliant with the policy a server MUST offer TLS version 179 1.2 or higher 181 n To be compliant with the policy a server MUST offer a TLS 182 connection that specifies a version identifier of {3, m} where 183 m >= n. 185 For historical reasons, TLS version 1.0 uses the protocol identifer 186 {3,1}, TLS version 1.1 the identifier {3,2} and so on. The 187 minVersion specifier is defined for consistency with the internal TLS 188 protocol rather than the descriptive name. 190 It will be noted that this approach does not support major version 191 number increments. This is intentional since a major version number 192 increment signals an incompatible change to the specification which 193 would almost certainly require a new Security Policy extension to be 194 defined. 196 3.2. extensions 198 The extensions element lists a sequence of TLS extension identifiers 199 that a server compliant with the policy MUST support and accept on 200 client request. 202 If the TLS status_request extension is specified in the Client Hello, 203 a compliant server MUST return a valid OCSP token for the specified 204 End Entity certificate in the response. 206 3.3. Use 208 3.3.1. Certificate Signing Request 210 If the certificate issue mechanism makes use of the PKCS#10 211 Certificate Signing Request (CSR) RFC 4366 [RFC4366], the CSR MAY 212 specify a TLS Security Policy extension as a CSR attribute. A server 213 or server administration tool should only generate key signing 214 requests that it knows can be supperted by the server for which the 215 certificate is intended. 217 3.3.2. Certificate Signing Certificate 219 When present in a Certificate Signing Certificate, the TLS Security 220 Policy extension specifies a constraint on valid certificate chains. 221 Specifically, a certificate chain is only valid if each certificate 222 in the chain specifies a TLS Security Policy that is at least as 223 restrictive as that specified in the certificate for the key used to 224 sign it. 226 While relying clients MAY reject certificates that do not comply with 227 this particular requirement, the use of TLs Security Policy in 228 Certificate Signing Certificates is primarily intended for use by 229 parties seeking to evaluate the performance of certificate issuers 230 and MAY be ignored by clients. 232 3.3.3. End Entity Certificate 234 When specified in an End Entity Certificate, the TLS Security Policy 235 extension specifies criteria that a server MUST meet to be compliant 236 with the policy. 238 In the case that a client determines that the server configuration is 239 inconsistent with the specified policy it MAY reject the TLS 240 configuration. 242 In the case that a client determines that the server configuration is 243 inconsistent with a policy specifying support for the TLS 244 status_request extension it SHOULD reject the TLS configuration. 246 3.4. Processing 248 3.4.1. Certification Authority 250 A CA SHOULD NOT issue certs with the extension unless there is an 251 affirmative statement to the effect that stapling is requested. 253 For example the use of the extension in the CSR or through an out of 254 band communication. 256 3.4.2. Server 258 A server SHOULD verify that its configuration is compatible with the 259 TLS Security Policy extension expressed in a certificate it presents. 260 A server MAY override local configuration options if necessary to 261 ensure consistency but SHOULD inform the administrator whenever such 262 an inconsitency is discovered. 264 A server SHOULD NOT override local configuration options to offer use 265 of cipher suites that have been otherwise deprecated as insecure but 266 MAY override local configuration to offer stronger cipher suites that 267 would otherwise have been the case. For example, a server that would 268 normally only offer DES might offer 3DES but not vice versa. 270 A server SHOULD support generation of the extension in CSRs if key 271 generation is supported. 273 3.4.3. Client 275 A compliant client SHOULD reject an attempt to establish a TLS 276 connection with security properties that are inconsistent with the 277 specified TLS Security Policy extension. 279 4. Acknowledgements 281 [List of CABForum and PKIX contributors] 283 5. Security Considerations 285 5.1. Alternative Certificates and Certificate Issuers 287 Use of the TLS Security Policy to mandate support for a particular 288 form of revocation checking is optional. This control can provide 289 protection in the case that a certificate with a TLS Security Policy 290 is compromised after issue but not in the case that the attacker 291 obtains an unmarked certificate from an issuer through fraud. 293 TLS Security Policy is a post-issue security control. Such risks can 294 only be addressed by security controls that take effect before issue. 296 5.2. Denial of Service 298 A certificate Issuer could issue a certificate that intentionally 299 specified a security policy that they knew the server could not 300 support. 302 The risks of such refusal would appear to be negligible since a 303 Certificate Authority could equally refuse to issue the certificate. 305 5.3. Cipher Suite Downgrade Attack 307 The TLS Security Policy extension does not provide protection against 308 a cipher suite downgrade attack. This is left to the existing 309 controls in the TLS protocol itself. 311 6. For discussion. 313 [RFC EDITOR: DELETE PRIOR TO PUBLICATION] 315 During the design of the extension, various proposals were made to 316 add functionality. This section explains the reasons that particular 317 functionality was chosen to be supported. It should be deleted by 318 the RFC editor prior to publication. 320 6.1. Cipher Suite Downgrade Attack 322 The TLS protocol provides controls designed to prevent a cipher suite 323 downgrade attack. Should these be found to be inadequate, the 324 appropriate response would be a modification of the TLS protocol and 325 assignment of a new minor version number or a required extension. 327 6.2. Remove Version attribute 329 The TLS protocol arguably provides a sufficient degree of protection 330 against a version number downgrade attack and thus it could be argued 331 that this particular attribute is unnecessary. 333 The reason the attribute was included is that it provides a failsafe 334 for the single most important aspect of the protocol. While TLS is 335 intended to be secure against downgrade attack this is not 336 established by means of a formal proof, nor is it likely that such 337 proof would be possible without making assumptions as to the security 338 of the cryptographic algorithms used to authenticate packets. 340 6.3. Mandated client behavior 342 Many certificate issuers (including this one) would like to mandate a 343 particular set of client behavior when a certificate is processed. 344 For example, requiring that a certificate 'hard fail' in cases where 345 the server is unable to obtain OCSP status. 347 Desirable though this functionality is to certificate issuers, it is 348 hard to see how client providers are likely to provide support. In 349 particular the browser providers are already aware that CAs would 350 prefer that they 'hard fail' on OCSP status. Will expressing that 351 request in a certificate make them any more likely to comply? 353 6.4. Other protocols and applications 355 Should we describe a similar extension for code signing? 357 While such an extension would clearly be useful, execution would 358 require a specification for code signing to refer to. 360 7. IANA Considerations 362 No action by IANA is required. 364 8. Normative References 366 [RFC1035] Mockapetris, P., "Domain names - implementation and 367 specification", STD 13, RFC 1035, November 1987. 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 373 and T. Wright, "Transport Layer Security (TLS) 374 Extensions", RFC 4366, April 2006. 376 [X.509] International Telecommunication Union, "ITU-T 377 Recommendation X.509 (11/2008): Information technology - 378 Open systems interconnection - The Directory: Public-key 379 and attribute certificate frameworks", ITU-T 380 Recommendation X.509, November 2008. 382 [X.680] International Telecommunication Union, "ITU-T 383 Recommendation X.680 (11/2008): Information technology - 384 Abstract Syntax Notation One (ASN.1): Specification of 385 basic notation", ITU-T Recommendation X.680, 386 November 2008. 388 Author's Address 390 Phillip Hallam-Baker 391 Comodo Group Inc. 393 Email: philliph@comodo.com