idnits 2.17.1 draft-moriarty-acme-overview-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 (May 13, 2019) is 1781 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) == Missing Reference: 'KMIP' is mentioned on line 336, but not defined == Missing Reference: 'NIST800-63A' is mentioned on line 340, but not defined == Missing Reference: 'NIST800-63B' is mentioned on line 345, but not defined == Missing Reference: 'NIST800-63C' is mentioned on line 350, but not defined == Missing Reference: 'NIST800-63r3' is mentioned on line 355, but not defined == Unused Reference: 'RFC2119' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-acme-ip' is defined on line 319, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-acme-ip-05 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-19 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF K. Moriarty 3 Internet-Draft DellEMC 4 Intended status: Standards Track M. Richardson 5 Expires: November 14, 2019 Sandelman 6 May 13, 2019 8 ACME Overview 9 draft-moriarty-acme-overview-00 11 Abstract 13 Automated Certificate Management Environment (ACME) core protocol 14 addresses the use case of web server certificates for TLS and defines 15 authentication challenge types to automate certificate issuance. 16 This document describes the orthoganal nature of certificate types to 17 challenge types for a better understanding of the applicability of 18 challenge types to various certificate types. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 14, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Key Storage . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Why Not EST . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Why EST, Bootstrapping with BRSKI . . . . . . . . . . . . . . 4 58 5. Why EST and BRSKI with ACME, or KMIP with ACME . . . . . . . 5 59 6. Authentication Challenges and Certificate Types . . . . . . . 6 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 10.2. Informative References . . . . . . . . . . . . . . . . . 7 66 10.3. URL References . . . . . . . . . . . . . . . . . . . . . 8 67 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 68 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 ACME [RFC8555] is a mechanism for automating certificate management 74 on the Internet. It enables administrative entities to prove 75 effective control over resources like domain names, and automates the 76 process of generating and issuing certificates. 78 ACME was designed for web server certificates with the possibility to 79 create extensions for other use cases and certificate types. 80 Although it was not explicitly stated, the challenge types defined in 81 RFC8555 and any other ACME extensions may be used with any 82 certificate type as deemed appropriate by the Certificate Authority 83 management. The defined challenge types are orthogonal in nature to 84 the certificate type that may be specified in the protocol document 85 definition. For instance, it is possible to use a a pre-defined 86 authentictaion challenge, such as a DNS resource record RFC8555 87 [RFC8555] originally specificed for web server certificates, to 88 authenticate a device to be issued a client certificate. In this 89 scenario, the only change necessary would be in the CSR. There is 90 nothing in the ACME protocol challenge/response mechanism that 91 specifies the certificate type. When designing extensions or 92 revewing options to implement ACME, understanding that the 93 certificate type is decoupled from the challenge type may be 94 important. When designing for specific certificate types, it is 95 logical to design for practical, reasonable challenges specific to 96 the certificate type to enable the secure automation of certificate 97 management. 99 This document will cover some early design decisions, and 100 authentication considerations such as identity proofing providing a 101 summary for those interested in the history and decision points. 103 2. Key Storage 105 A design goal for the automated workflow for these certificate types 106 via ACME is to allow for flexibility in the selection of key storage 107 containers, for instance one may select the Key Management 108 Interoperability Protocol (KMIP) [KMIP] for key management and 109 storage, PKCS-11 for key storage, or a proprietary key store. This 110 is particularly important and may be asked in regard to client 111 certificates as flexibility to store certificates on a device or 112 external to a device may be a concern and the flexibility to store 113 keys using a chosen protocol may be important. In the case of KMIP, 114 the KMIP enterprise key manager could use ACME to communicate with 115 the CA server, leaving the device communications between devices and 116 the KMIP server. However, the use of ACME can be standalone 117 integrating with the available client key storage method (for 118 example, PKCS-#11) provided for accessibility and to prevent cost 119 barriers for automating key management for some implementations. The 120 ACME client on the device or system storing the code signing 121 certificate would authenticate to the CA running an ACME server to 122 obtain initial certificates or renew certificates. With the 123 proliferation of open source implementations of ACME for TLS server 124 certificates, this seems like a reasonable goal. Several options for 125 integrating ACME with other protocols will be presented in this 126 draft, this section is specific to key storage and thus covers the 127 open standards that enable key storage. 129 3. Why Not EST 131 Enrollment over Secure Transport (EST) [RFC7030] and OpenStack's 132 Keystone are options for automating client certificates. OpenSSL can 133 be combined with libest to automate the management of client 134 certificates, for instance. 136 The authentication options used in EST to obtain a client certificate 137 are described in [RFC7030] Section 2.2 and are stated as follows: 139 o TLS with a previously issued client certificate (e.g., an existing 140 certificate issued by the EST CA); 142 o TLS with a previously installed certificate (e.g., manufacturer- 143 installed certificate or a certificate issued by some other 144 party); 146 o Certificate-less TLS (e.g., with a shared credential distributed 147 out-of-band); 149 o HTTP-based with a username/password distributed out-of-band. 151 Although a fine a protocol, none of these options enable the protocol 152 to establish authentication of the entity (device, user, owner of 153 code signing certificate) without a pre-established and external 154 process to the protocol. In some cases, higher levels of assertion 155 are necessary and EST may be more suited for those purposes or 156 additional out-of-band processing could be used in conjunction with 157 ACME if adopted widely for the automation of client certificate 158 management. 160 4. Why EST, Bootstrapping with BRSKI 162 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 163 [I-D.ietf-anima-bootstrapping-keyinfra] is an extension to EST that 164 has been deployed, but is still in the standardization process. 165 Client device certificates typically require administrator 166 interaction to request, retrieve, and install the initial 167 certificate. The process being manual allows for control and 168 understanding of the CA issuing certificates, the device, and 169 verifying the security parameters including authenticating each 170 party. While there are security advantages to the manual process, 171 automation is necessary not only to scale deployment, but in some 172 cases to make it possible. BRSKI defines a protocol to bootstrap the 173 initial enrollment using device properties. This bootstrapping 174 capability is critical when deploying devices at scale and enabling 175 encryption via certificates. BRSKI allows devices to find their 176 owner without being online first, and without preconfiguration. 177 BRSKI does not change how EST authenticates the device; it just 178 reduces it as described below. 180 BRSKI uses device information to "authenticate" for bootstrapping, 181 namely a serial number entered into the subject field's DN and the 182 subject-alt field may include the Trusted Platform Module (TPM) 183 identifier, IDevID defined in Section 7.2.9 of RFC4108 [RFC4108]. If 184 the subject field is present, it takes precedence over the subject- 185 alt field. These identifiers are included in a voucher or voucher- 186 requests (cryptographically protected artifact using a digital 187 signature) to uniquely identify the device, or in BRSKI terms, the 188 'pledge'. It should be noted that to date, the identifier in the TPM 189 has not been used in practice as the TPM identifier has not been 190 present in systems where EST with the BRSKI extension have been used. 191 A registrar may be used with a local policy and it is also possible 192 to use a Manufacturer Authorized Signing Authority (MASA) service for 193 the authentication process. MASA has been the default (See section 5 194 of BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]. The pledge only 195 imprints when the voucher can be validated. 197 In the case where a private CA is used, it is possible to configure 198 the environment to use EST with the BRSKI extension to fully automate 199 certificate enrollment and management with bootstrapping. In some 200 cases, it is possible to use EST and BRSKI alone when retreieving a 201 certificate from a public CA. In this case, the Registration 202 Authority (RA) or registrar, may be on the same system as the CA or 203 the registrar has a protocol to communicate with the CA using a 204 variation of EST such as fullcmc rather than the simpleenroll 205 methods. If EST is not supported on the public CA, the registrar may 206 need to communicate with the CA using another protocol that enables 207 automated certificate management, namely ACME. This scenario may be 208 true for other certificate and key management protocols, such as 209 KMIP, where the device certificate management handled by the 210 registrar is fully enabled to the devices or 'pledges', but 211 communication to the CA uses ACME. 213 5. Why EST and BRSKI with ACME, or KMIP with ACME 215 Interoperability is the key factor that would drive a deployment 216 mixing several protocols. Since there are a few choices and some are 217 a better fit in certain enviornments, the method to fully automate 218 with the avilable infrastructure may require a mix of protocols. 219 Yes, this is a bit more complicated and a method like EST with BRSKI 220 could solve this end-to-end, but support is needed at the public CA 221 to make that possible. KMIP may also be used to manage certificates 222 to devices and with a similar design, may utilize ACME for 223 communications from the registrar to the CA. The use case is as 224 follows: 226 o BRSKI provides the authentication of the new device, establishing 227 trust for use with EST 229 o EST enables enrollment, where the device requests the certificate 230 from the registrar 232 o The registrar invokes the ACME protocol to request a certificate 233 from the CA. 235 ACME could possibly be used as a protocol in multiple use cases where 236 the existing standard does not specify how the enrolment server 237 communicates with the CA. In addition to the above described use 238 case for EST with BRSKI, EST and TEAP enrolment servers, with BRSKI 239 and TEAP-BRSKI is a variations on extensions to those. Similarly, 240 KMIP may be used for the first two steps, with the connection from 241 the registrar to the CA using ACME. 243 6. Authentication Challenges and Certificate Types 245 A typical process to obtain a client certificate may be similar to 246 the workflow described in the introduction of RFC8555 with the 247 exception of certificate type and Enhanced Key Usage (EKU). Although 248 RFC8555 was written with the web server use case in mind, the 249 protocol was designed to allow for the defined authentication 250 challenges to be orthogonal to the certificate type issued. The 251 workflow may vary between certificate types as the issuance process 252 may have specific requirements and as a result, may have unique 253 authentication challenge options that alter the workflow. If the 254 defined challenge types are appropriate for use to issue certificates 255 of other types, this is possible without further specification. The 256 implementation would use the appropriate certificate type, defined in 257 the CSR. The ACME protocol does not define CSR contents, hence the 258 certificate type and challenge, as well as pre-authorization 259 challenges, are decoupled from the certificate type. The EKU are 260 standard defined values and include: 262 o 1.3.6.1.5.5.7.3.1 Server Authentication 264 o 1.3.6.1.5.5.7.3.2 Client Authentication 266 o 1.3.6.1.5.5.7.3.3 Code Signing 268 o 1.3.6.1.5.5.7.3.4 Email Protection 270 o 1.3.6.1.5.5.7.3.5 IPSec End System 272 o 1.3.6.1.5.5.7.3.6 IPSec Tunnel 274 o 1.3.6.1.5.5.7.3.7 IPSec User 276 o 1.3.6.1.5.5.7.3.8 Time Stamping 278 o 1.3.6.1.5.5.7.3.9 OCSP Signing 280 7. Security Considerations 282 This will likely be full of considerations and is TBD for revision 283 one. 285 8. IANA Considerations 287 This memo includes no request to IANA, yet. 289 9. Contributors 291 Thank you to Owen Friel for your early comments and suggestions and 292 to Richard Barnes for suggesting the need for such a document. 294 10. References 296 10.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, 300 DOI 10.17487/RFC2119, March 1997, 301 . 303 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 304 "Enrollment over Secure Transport", RFC 7030, 305 DOI 10.17487/RFC7030, October 2013, 306 . 308 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 309 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 310 May 2017, . 312 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 313 Kasten, "Automatic Certificate Management Environment 314 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 315 . 317 10.2. Informative References 319 [I-D.ietf-acme-ip] 320 Shoemaker, R., "ACME IP Identifier Validation Extension", 321 draft-ietf-acme-ip-05 (work in progress), February 2019. 323 [I-D.ietf-anima-bootstrapping-keyinfra] 324 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 325 S., and K. Watsen, "Bootstrapping Remote Secure Key 326 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 327 keyinfra-19 (work in progress), March 2019. 329 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 330 Protect Firmware Packages", RFC 4108, 331 DOI 10.17487/RFC4108, August 2005, 332 . 334 10.3. URL References 336 [KMIP] OASIS, "Key Management Interoperability Protocol 337 Specification Version 1.4 http://docs.oasis- 338 open.org/kmip/spec/v1.4/cos01/kmip-spec-v1.4-cos01.pdf". 340 [NIST800-63A] 341 US National Institute of Standards and Technology, 342 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 343 NIST.SP.800-63a.pdf". 345 [NIST800-63B] 346 US National Institute of Standards and Technology, 347 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 348 NIST.SP.800-63b.pdf". 350 [NIST800-63C] 351 US National Institute of Standards and Technology, 352 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 353 NIST.SP.800-63c.pdf". 355 [NIST800-63r3] 356 US National Institute of Standards and Technology, 357 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 358 NIST.SP.800-63-3.pdf". 360 Appendix A. Change Log 362 Note to RFC Editor: if this document does not obsolete an existing 363 RFC, please remove this appendix before publication as an RFC. 365 Appendix B. Open Issues 367 Note to RFC Editor: please remove this appendix before publication as 368 an RFC. 370 Authors' Addresses 372 Kathleen M. Moriarty 373 DellEMC 374 176 South Street 375 Hopkinton 376 US 378 EMail: Kathleen.Moriarty@dell.com 380 Michael C. Richardson 381 Sandelman Software Works 383 EMail: mcr+ietf@sandelman.ca 384 URI: http://www.sandelman.ca/