idnits 2.17.1 draft-hallambaker-tlssecuritypolicy-03.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 (November 14, 2012) is 4152 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: 'RFC1035' is defined on line 347, 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 (==), 1 comment (--). 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 November 14, 2012 5 Expires: May 18, 2013 7 X.509v3 Extension: OCSP Stapling Required 8 draft-hallambaker-tlssecuritypolicy-03 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. In particular, the TLS Security Policy extension may be 15 used to mandate support for revocation checking features in the TLS 16 protocol such as OCSP stapling. Informing clients that an OCSP 17 status response will always be stapled permits an immediate failure 18 in the case that the response is not stapled. This in turn prevents 19 a denial of service attack that might otherwise be possible. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 18, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 57 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. SecurityPolicy . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1.1. status_request . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2.1. Certificate Signing Request . . . . . . . . . . . . . . 5 63 3.2.2. Certificate Signing Certificate . . . . . . . . . . . . 5 64 3.2.3. End Entity Certificate . . . . . . . . . . . . . . . . 6 65 3.3. Processing . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3.1. Certification Authority . . . . . . . . . . . . . . . . 6 67 3.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 5.1. Alternative Certificates and Certificate Issuers . . . . . 7 72 5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . . 7 73 5.3. Cipher Suite Downgrade Attack . . . . . . . . . . . . . . . 7 74 6. For discussion. . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6.1. Mandated client behavior . . . . . . . . . . . . . . . . . 8 76 6.2. OCSP Analog . . . . . . . . . . . . . . . . . . . . . . . . 8 77 6.3. Other protocols and applications . . . . . . . . . . . . . 8 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 79 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Definitions 84 1.1. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 2. Purpose 92 The purpose of the TLS Security Policy extension is to prevent 93 downgrade attacks that are not otherwise prevented by the TLS 94 protocol. 96 Since the TLS protocol itself provides strong protection against most 97 forms of downgrade attack, the TLS Security Policy is only relevant 98 to the validation of TLS protocol credentials. In particular to the 99 revocation status of the credentials presented. 101 At the time of writing, the only TLS feature that is relevant to the 102 revocation status of credentials is the Certificate Status Request 103 extension (status_request) used to support in-band exchange of OCSP 104 tokens, otherwise known as OCSP stapling. This extension is 105 described in RFC 4366 [RFC4366]. 107 The TLS Security Policy mechanism described in this document is 108 designed to support policy statements that prevent a downgrade attack 109 against the current OCSP stapling mechanism and possible future 110 certificate revocation mechanisms such as stapling of multiple OCSP 111 tokens. 113 The OCSP stapling mechanism described in RFC 4366 [RFC4366] permits a 114 TLS server to provide evidence of valid certificate status inband and 115 thus improve client response. A TLS Security Policy that advertises 116 the status_request extension informs a client that if the 117 status_request is specified in a TLS Client Helo, that a server 118 compliant with the policy MUST respond with a valid OCSP token for 119 the End Entity Certificate it presents. 121 Use of the TLS Security Policy extension in this fashion permits a 122 client to avoid reliance on certificates that are revoked for the 123 reasons that occur most frequently. In particular it allows a client 124 to avoid mis-reliance on certificates that are revoked for cause or 125 at the request of the subject (e.g. because of a compromised private 126 key). 128 Advertising the status_request extension permits a client to fail 129 immediately in the case that the token is not provided by the server 130 without the need to query the OCSP responder in addition. This 131 improves client efficiency and more importantly prevents a denial of 132 service attack against the client by either blocking the OCSP 133 response or mounting a denial of service attack against the OCSP 134 responder. 136 Since the TLS Security Policy extension is an option, it is not 137 likely that an attacker attempting to obtain a certificate through 138 fraud will choose to have a certificate issued with this extension. 139 Such risks are more approrpriately addressed by mechanisms such as 140 Certificate Authority Authorization records that are designed to 141 prevent or mitigate mis-issue. Nevertheless a Certification 142 Authority MAY consider the presence or absence of a required security 143 policy as one factor in determining the level of additional scruitiny 144 a request should be subject to. 146 Any security policy specified in an End Entity certificate MUST be 147 followed by the server or clients MAY refuse connection. It is 148 important therefore that a Certification Authority only issue 149 certificates that specify policies that match the configuration of 150 the server and that the server is capable of verifying that its 151 configuration is compatible with the security policy of the 152 certificates it offers. Ideally, the TLS security policy would be 153 specified by the client as part of the certificate issue process. 155 This document describes a mechanism that MAY be used to provide this 156 communication in-band for the most commonly used certificate 157 registration protocol. 159 3. Syntax 161 The TLS Security Policy extension has the following format: 163 cabf-tls-security-policy OBJECT IDENTIFIER ::= { cabf 1 } 165 SecurityPolicy ::= SEQUENCE OF INTEGER 167 The TLS Security Policy Extension MAY be marked critical. 168 Implementations that process the extension MUST ignore the 169 criticality bit setting. 171 3.1. SecurityPolicy 173 The SecurityPolicy extension lists a sequence of TLS extension 174 identifiers that a server compliant with the policy MUST support and 175 accept on client request. 177 This specification does not require a TLS client to offer or support 178 any TLS extension regardless of whether it is specified in the TLS 179 Security Policy or not. In particular a client MAY request and a 180 server MAY support any TLS extension regardless of whether it is 181 specified in a TLS security extension or not. 183 If a TLS Security Policy extension specifies a TLS extension, a 184 server offering the certificate MUST support the extension specified 185 and MUST comply with any specific requirements specified for that 186 extension in this document or in the document that specifies the TLS 187 extension. 189 3.1.1. status_request 191 If the TLS status_request extension is specified in the TLS Security 192 Policy extension and a TLS client specifies the status_request 193 extensionin the Client Hello, a server MUST return a valid OCSP token 194 for the specified End Entity certificate in the response. 196 3.2. Use 198 3.2.1. Certificate Signing Request 200 If the certificate issue mechanism makes use of the PKCS#10 201 Certificate Signing Request (CSR) RFC 4366 [RFC4366], the CSR MAY 202 specify a TLS Security Policy extension as a CSR attribute. A server 203 or server administration tool should only generate key signing 204 requests that it knows can be supperted by the server for which the 205 certificate is intended. 207 3.2.2. Certificate Signing Certificate 209 When present in a Certificate Signing Certificate, the TLS Security 210 Policy extension specifies a constraint on valid certificate chains. 211 Specifically, a certificate chain is only valid if each certificate 212 in the chain specifies a TLS Security Policy that is at least as 213 restrictive as that specified in the certificate for the key used to 214 sign it. 216 While relying clients MAY reject certificates that do not comply with 217 this particular requirement, the use of TLs Security Policy in 218 Certificate Signing Certificates is primarily intended for use by 219 parties seeking to evaluate the performance of certificate issuers 220 and MAY be ignored by clients. 222 3.2.3. End Entity Certificate 224 When specified in an End Entity Certificate, the TLS Security Policy 225 extension specifies criteria that a server MUST meet to be compliant 226 with the policy. 228 In the case that a client determines that the server configuration is 229 inconsistent with the specified policy it MAY reject the TLS 230 configuration. 232 In the case that a client determines that the server configuration is 233 inconsistent with a policy specifying support for the TLS 234 status_request extension it SHOULD reject the TLS configuration. 236 3.3. Processing 238 3.3.1. Certification Authority 240 A CA SHOULD NOT issue certs with the extension unless there is an 241 affirmative statement to the effect that stapling is requested. 243 For example the use of the extension in the CSR or through an out of 244 band communication. 246 3.3.2. Server 248 A server SHOULD verify that its configuration is compatible with the 249 TLS Security Policy extension expressed in a certificate it presents. 250 A server MAY override local configuration options if necessary to 251 ensure consistency but SHOULD inform the administrator whenever such 252 an inconsitency is discovered. 254 A server SHOULD NOT override local configuration options to offer use 255 of cipher suites that have been otherwise deprecated as insecure but 256 MAY override local configuration to offer stronger cipher suites that 257 would otherwise have been the case. For example, a server that would 258 normally only offer DES might offer 3DES but not vice versa. 260 A server SHOULD support generation of the extension in CSRs if key 261 generation is supported. 263 3.3.3. Client 265 A compliant client MUST process the TLS Security Policy Extension and 266 MUST ignore the setting of the X.509 criticality flag. 268 A compliant client SHOULD reject a TLS connection with security 269 properties that are inconsistent with the specified TLS Security 270 Policy extension. A compliant client MAY accept such a TLS 271 connection request however if it is determined that doing so is 272 appropriate in particular circumstances. 274 4. Acknowledgements 276 [List of CABForum and PKIX contributors] 278 5. Security Considerations 280 5.1. Alternative Certificates and Certificate Issuers 282 Use of the TLS Security Policy to mandate support for a particular 283 form of revocation checking is optional. This control can provide 284 protection in the case that a certificate with a TLS Security Policy 285 is compromised after issue but not in the case that the attacker 286 obtains an unmarked certificate from an issuer through fraud. 288 TLS Security Policy is a post-issue security control. Such risks can 289 only be addressed by security controls that take effect before issue. 291 5.2. Denial of Service 293 A certificate Issuer could issue a certificate that intentionally 294 specified a security policy that they knew the server could not 295 support. 297 The risks of such refusal would appear to be negligible since a 298 Certificate Authority could equally refuse to issue the certificate. 300 5.3. Cipher Suite Downgrade Attack 302 The TLS Security Policy extension does not provide protection against 303 a cipher suite downgrade attack. This is left to the existing 304 controls in the TLS protocol itself. 306 6. For discussion. 308 [RFC EDITOR: DELETE PRIOR TO PUBLICATION] 310 During the design of the extension, various proposals were made to 311 add functionality. This section explains the reasons that particular 312 functionality was chosen to be supported. It should be deleted by 313 the RFC editor prior to publication. 315 6.1. Mandated client behavior 317 Many certificate issuers (including this one) would like to mandate a 318 particular set of client behavior when a certificate is processed. 319 For example, requiring that a certificate 'hard fail' in cases where 320 the server is unable to obtain OCSP status. 322 Desirable though this functionality is to certificate issuers, it is 323 hard to see how client providers are likely to provide support. In 324 particular the browser providers are already aware that CAs would 325 prefer that they 'hard fail' on OCSP status. Will expressing that 326 request in a certificate make them any more likely to comply? 328 6.2. OCSP Analog 330 A related extension for OCSP may also be useful. In particular an 331 OCSP security policy extension might specify that the service 332 supported particular OCSP extensions such as the digest locator. 334 6.3. Other protocols and applications 336 Should we describe a similar extension for code signing? 338 While such an extension would clearly be useful, execution would 339 require a specification for code signing to refer to. 341 7. IANA Considerations 343 No action by IANA is required. 345 8. Normative References 347 [RFC1035] Mockapetris, P., "Domain names - implementation and 348 specification", STD 13, RFC 1035, November 1987. 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 354 and T. Wright, "Transport Layer Security (TLS) 355 Extensions", RFC 4366, April 2006. 357 [X.509] International Telecommunication Union, "ITU-T 358 Recommendation X.509 (11/2008): Information technology - 359 Open systems interconnection - The Directory: Public-key 360 and attribute certificate frameworks", ITU-T 361 Recommendation X.509, November 2008. 363 [X.680] International Telecommunication Union, "ITU-T 364 Recommendation X.680 (11/2008): Information technology - 365 Abstract Syntax Notation One (ASN.1): Specification of 366 basic notation", ITU-T Recommendation X.680, 367 November 2008. 369 Author's Address 371 Phillip Hallam-Baker 372 Comodo Group Inc. 374 Email: philliph@comodo.com