idnits 2.17.1 draft-friel-acme-integrations-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 129 characters in excess of 72. 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 1803 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: 'RFC6570' is mentioned on line 150, but not defined == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-20 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Friel 3 Internet-Draft R. Barnes 4 Intended status: Standards Track Cisco 5 Expires: November 14, 2019 May 13, 2019 7 ACME Integrations 8 draft-friel-acme-integrations-00 10 Abstract 12 This document outlines multiple advanced use cases and integrations 13 that ACME facilitates without any modifications or enhancements 14 required to the base ACME specification. These use cases are not 15 immediately obvious from reading the ACME specification and thus are 16 explicitly documented here. The use cases include ACME issuance of 17 subdomain certificates, and ACME integration with EST and TEAP. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 14, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. ACME Issuance of Subdomain Certificates . . . . . . . . . . . 3 56 4. ACME Integration with EST . . . . . . . . . . . . . . . . . . 5 57 5. ACME Integration with BRSKI . . . . . . . . . . . . . . . . . 8 58 6. ACME Integration with TEAP . . . . . . . . . . . . . . . . . 9 59 7. ACME Integration with TEAP-BRSKI . . . . . . . . . . . . . . 12 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 62 10. Informative References . . . . . . . . . . . . . . . . . . . 13 63 Appendix A. Comments . . . . . . . . . . . . . . . . . . . . . . 13 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 66 1. Introduction 68 ACME [RFC8555] defines a protocol that a certificate authority (CA) 69 and an applicant can use to automate the process of domain name 70 ownership validation and X.509 (PKIX) certificate issuance. The 71 protocol is rich and flexible and enables multiple use cases that are 72 not immediately obvious from reading the specification. This 73 document explicitly outlines multiple advanced ACME use cases 74 including: 76 o ACME issuance of subdomain certificates 78 o ACME integration with EST [RFC7030] 80 o ACME integration with BRSKI 81 [I-D.ietf-anima-bootstrapping-keyinfra] 83 o ACME integration with TEAP [RFC7170] 85 o ACME integration with TEAP-BRSKI draft-lear-eap-teap-brski 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in BCP 92 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 The following terms are used in this document: 97 o BRSKI: Bootstrapping Remote Secure Key Infrastructures 98 [I-D.ietf-anima-bootstrapping-keyinfra] 100 o CA: Certificate Authority 102 o CMC: Certificate Management over CMS 104 o CSR: Certificate Signing Request 106 o EST: Enrollment over Secure Transport [RFC7030] 108 o FQDN: Fully Qualified Domain Name 110 o RA: PKI Registration Authority 112 o TEAP: Tunneled Extensible Authentication Protocol [RFC7170] 114 3. ACME Issuance of Subdomain Certificates 116 A typical ACME workflow for issuance of certificates is as follows: 118 1. client POSTs a newOrder request that contains a set of 119 "identifiers" 121 2. server replies with a set of "authorizations" and a "finalize" 122 URI 124 3. client sends POST-as-GET requests to retrieve the 125 "authorizations", with the downloaded "authorization" object(s) 126 containing the "identifier" that the client must prove control of 128 4. client proves control over the "identifier" in the 129 "authorization" object by completing the specified challenge, for 130 example, by pubilshing a DNS TXT record 132 5. client POSTs a CSR to the "finalize" API 134 ACME places the following restrictions on "identifiers": 136 o section 7.1.4: the only type of "identifier" defined by the ACME 137 specification is a fully qualified domain name 139 The only type of identifier defined by this specification is a fully qualified domain name (type: "dns"). The domain name MUST be encoded in the form in which it would appear in a certificate. 141 o Section 7.4: the "identifier" in the CSR request must match the 142 "identifier" in the newOrder request 144 The CSR MUST indicate the exact same set of requested identifiers as the initial newOrder request. 146 o Sections 8.3 and 8.4: the "identifier", or FQDN, in the 147 "authorization" object must be used when fulfilling challenges via 148 HTTP or DNS mechanisms 150 Construct a URL by populating the URL template [RFC6570] 151 "http://{domain}/.well-known/acme-challenge/{token}", where: 153 * the domain field is set to the domain name being verified 155 The client constructs the validation domain name by 156 prepending the label "_acme-challenge" to the domain name being 157 validated 159 ACME does not mandate that the "identifier" in a newOrder request 160 matches the "identifier" in "authorization" objects. This means that 161 the ACME specification does not preclude an ACME server processing 162 newOrder requests and issuing certificates for a subdomain without 163 requiring a challenge to be fulfilled against that explicit 164 subdomain. ACME server policy could allow issuance of certificates 165 for a subdomain to a client where the client only has to fulfill an 166 authorization challenge for the parent domain. 168 This allows a flow where a client proves ownership of "domain.com" 169 and then successfully obtains a certificate for "sub.domain.com". 170 The ACME pre-authorization flow makes most sense for this use case, 171 and that is what is illustrated in the following call flow. 173 The client could pre-authorize for the parent domain once, and then 174 issue multiple newOrder requests for certificates for multiple 175 subdomains. This call flow illustrates the client only placing one 176 newOrder request. 178 +--------+ +------+ +-----+ 179 | Client | | ACME | | DNS | 180 +--------+ +------+ +-----+ 181 | | | 182 STEP 1: Pre-Authorization of parent domain 183 | | | 184 | POST /newAuthz | | 185 | "domain.com" | | 186 |--------------------->| | 187 | | | 188 | 201 authorizations | | 189 |<---------------------| | 190 | | | 191 | Publish DNS TXT | | 192 | "domain.com" | | 193 |--------------------------------->| 194 | | | 195 | POST /challenge | | 196 |--------------------->| | 197 | | Verify | 198 | |---------->| 199 | 200 status=valid | | 200 |<---------------------| | 201 | | | 202 | Delete DNS TXT | | 203 | "domain.com" | | 204 |--------------------------------->| 205 | | | 206 STEP 2: Place order for subdomain 207 | | | 208 | POST /newOrder | | 209 | "sub.domain.com" | | 210 |--------------------->| | 211 | | | 212 | 201 status=ready | | 213 |<---------------------| | 214 | | | 215 | POST /finalize | | 216 | CSR "sub.domain.com" | | 217 |--------------------->| | 218 | | | 219 | 200 OK status=valid | | 220 |<---------------------| | 221 | | | 222 | POST /certificate | | 223 |--------------------->| | 224 | | | 225 | 200 OK | | 226 | PKI "sub.domain.com" | | 227 |<---------------------| | 229 4. ACME Integration with EST 231 EST [RFC7030] defines a mechanism for clients to enroll with a PKI 232 Registration Authority by sending CMC messages over HTTP. EST 233 section 1 states: 235 Architecturally, the EST service is located between a Certification Authority (CA) and a client. It performs several functions traditionally allocated to the Registration Authority (RA) role in a PKI. 237 EST section 1.1 states that: 239 For certificate issuing services, the EST CA is reached through the EST server; the CA could be logically "behind" the EST server or embedded within it. 241 When the CA is logically "behind" the EST RA, EST does not specify 242 how the RA communicates with the CA. EST section 1 states: 244 The nature of communication between an EST server and a CA is not described in this document. 246 This section outlines how ACME could be used for communication 247 between the EST RA and the CA. The example call flow shows the RA 248 proving ownership of a parent domain, with individual client 249 certificates being subdomains under that parent domain. This is an 250 optimisation that reduces DNS and ACME traffic overhead. The RA 251 could of course prove ownership of every explicit client certificate 252 identifier. 254 The call flow also illustrates how the RA can include relevant domain 255 information in the CSR request to ACME that the client may not have 256 knowledge of. For example, a device or pledge may know its MAC 257 address and serial number and only include that as its identifier in 258 a CSR request. The RA could insert the domain information into the 259 CSR request. Additionally, for privacy reasons, the RA may not want 260 to divulge MAC or serial number information to the CA and could 261 additionally assign an opaque random identifier to the device. 263 +--------+ +--------+ +------+ +-----+ 264 | Pledge | | EST RA | | ACME | | DNS | 265 +--------+ +--------+ +------+ +-----+ 266 | | | | 267 STEP 1: Pre-Authorization of parent domain 268 | | | | 269 | | POST /newAuthz | | 270 | | "domain.com" | | 271 | |--------------------->| | 272 | | | | 273 | | 201 authorizations | | 274 | |<---------------------| | 275 | | | | 276 | | Publish DNS TXT | | 277 | | "domain.com" | | 278 | |--------------------------------->| 279 | | | | 280 | | POST /challenge | | 281 | |--------------------->| | 282 | | | Verify | 283 | | |---------->| 284 | | 200 status=valid | | 285 | |<---------------------| | 286 | | | | 287 | | Delete DNS TXT | | 288 | | "domain.com" | | 289 | |--------------------------------->| 290 | | | | 291 STEP 2: Pledge enrolls against RA 292 | | | | 293 | POST /simpleenroll | | | 294 | PCSK#10 "MAC/serial" | | | 295 |--------------------->| | | 296 | | | | 297 | 202 Retry-After | | | 298 |<---------------------| | | 299 | | | | 300 STEP 3: RA places ACME order 301 | | | | 302 | | POST /newOrder | | 303 | | "pledgeX.domain.com" | | 304 | |--------------------->| | 305 | | | | 306 | | 201 status=ready | | 307 | |<---------------------| | 308 | | | | 309 | | POST /finalize | | 310 | | CSR "pledgeX.domain.com" | 311 | |--------------------->| | 312 | | | | 313 | | 200 OK status=valid | | 314 | |<---------------------| | 315 | | | | 316 | | POST /certificate | | 317 | |--------------------->| | 318 | | | | 319 | | 200 OK | | 320 | | PKI "pledgeX.domain.com" | 321 | |<---------------------| | 322 | | | | 323 STEP 4: Pledge retries enroll 324 | | | | 325 | POST /simpleenroll | | | 326 | PCSK#10 "MAC/serial" | | | 327 |--------------------->| | | 328 | | | | 329 | 200 OK | 330 | PKCS#7 "pledgeX.domain.com" | | 331 |<---------------------| | | 333 5. ACME Integration with BRSKI 335 BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] is based upon EST 336 [RFC7030] and defines how to autonomically bootstrap PKI trust 337 anchors into devices via means of signed vouchers. EST certificate 338 enrollment may then optionally take place after trust has been 339 established. BRKSI voucher exchange and trust establishment are 340 based on EST extensions and the certicicate enrollment part of BRSKI 341 is fully based on EST. Similar to EST, BRSKI does not define how the 342 EST RA communicates with the CA. Therefore the mechanisms outlined 343 in the previous section for using ACME as the communications protocol 344 between the EST RA and the CA are equally applicable to BRSKI. 346 The following call flow shows how ACME may be integated into a full 347 BRSKI voucher plus EST enrollment workflow. For brevity, it assumes 348 that the EST RA has previously proven ownership of a parent domain 349 and that pledge certificate identifiers are a subdomain of that 350 parent domain. The doain owernship excahnges between the RA, ACME 351 and DNS are not shown. Similarly, not all BRSKI interactions are 352 shown and only the key protocol flows involving voucher exchange and 353 EST enrollment are shown. 355 +--------+ +--------+ +------+ +------+ 356 | Pledge | | EST RA | | ACME | | MASA | 357 +--------+ +--------+ +------+ +------+ 358 | | | | 359 NOTE: Pre-Authorization of "domain.com" is complete 360 | | | | 361 STEP 1: Pledge requests Voucher 362 | | | | 363 | POST /requestvoucher | | | 364 |--------------------->| | | 365 | | POST /requestvoucher | | 366 | |--------------------------------->| 367 | | | | 368 | | 200 OK Voucher | | 369 | |<---------------------------------| 370 | 200 OK Voucher | | | 371 |<---------------------| | | 372 | | | | 373 STEP 2: Pledge enrolls against RA 374 | | | | 375 | POST /simpleenroll | | | 376 | PCSK#10 "MAC/serial" | | | 377 |--------------------->| | | 378 | | | | 379 | 202 Retry-After | | | 380 |<---------------------| | | 381 | | | | 382 STEP 3: RA places ACME order 383 | | | | 384 | | POST /newOrder | | 385 | | "pledgeX.domain.com" | | 386 | |--------------------->| | 387 | | | | 388 | | 201 status=ready | | 389 | |<---------------------| | 390 | | | | 391 | | POST /finalize | | 392 | | CSR "pledgeX.domain.com" | 393 | |--------------------->| | 394 | | | | 395 | | 200 OK status=valid | | 396 | |<---------------------| | 397 | | | | 398 | | POST /certificate | | 399 | |--------------------->| | 400 | | | | 401 | | 200 OK | | 402 | | PKI "pledgeX.domain.com" | 403 | |<---------------------| | 404 | | | | 405 STEP 4: Pledge retries enroll 406 | | | | 407 | POST /simpleenroll | | | 408 | PCSK#10 "MAC/serial" | | | 409 |--------------------->| | | 410 | | | | 411 | 200 OK | 412 | PKCS#7 "pledgeX.domain.com" | | 413 |<---------------------| | | 415 6. ACME Integration with TEAP 417 TEAP [RFC7170] define a tunnel-based EAP method that enables secure 418 communication between a peer and a server by using TLS to establish a 419 mutually authenticated tunnel. TEAP enables certificate provisioning 420 within the tunnel. TEAP does not define how the TEAP server 421 communicates with the CA. 423 This section outlines how ACME could be used for communication 424 between the TEAP server and the CA. The example call flow shows the 425 TEAP server proving ownership of a parent domain, with individual 426 client certificates being subdomains under that parent domain. This 427 is an optimisation that reduces DNS and ACME traffic overhead. The 428 TEAP server could of course prove ownership of every explicit client 429 certificate identifier. 431 +--------+ +-------------+ +------+ +-----+ 432 | Pledge | | TEAP-Server | | ACME | | DNS | 433 +--------+ +-------------+ +------+ +-----+ 434 | | | | 435 STEP 1: Pre-Authorization of parent domain 436 | | | | 437 | | POST /newAuthz | | 438 | | "domain.com" | | 439 | |--------------------->| | 440 | | | | 441 | | 201 authorizations | | 442 | |<---------------------| | 443 | | | | 444 | | Publish DNS TXT | | 445 | | "domain.com" | | 446 | |--------------------------------->| 447 | | | | 448 | | POST /challenge | | 449 | |--------------------->| | 450 | | | Verify | 451 | | |---------->| 452 | | 200 status=valid | | 453 | |<---------------------| | 454 | | | | 455 | | Delete DNS TXT | | 456 | | "domain.com" | | 457 | |--------------------------------->| 458 | | | | 459 | | | | 460 STEP 2: Establsh EAP Outer Tunnel 461 | | | | 462 | EAP-Request/ | | | 463 | Type=Identity | | | 464 |<------------------------| | | 465 | | | | 466 | EAP-Response/ | | | 467 | Type=Identity | | | 468 |------------------------>| | | 469 | | | | 470 | EAP-Request/ | | | 471 | Type=TEAP, | | | 472 | TEAP Start, | | | 473 | Authority-ID TLV | | | 474 |<------------------------| | | 475 | | | | 476 | EAP-Response/ | | | 477 | Type=TEAP, | | | 478 | TLS(ClientHello) | | | 479 |------------------------>| | | 480 | | | | 481 | EAP-Request/ | | | 482 | Type=TEAP, | | | 483 | TLS(ServerHello, | | | 484 | Certificate, | | | 485 | ServerKeyExchange, | | | 486 | CertificateRequest, | | | 487 | ServerHelloDone) | | | 488 |<------------------------| | | 489 | | | | 490 | EAP-Response/ | | | 491 | Type=TEAP, | | | 492 | TLS(Certificate, | | | 493 | ClientKeyExchange, | | | 494 | CertificateVerify, | | | 495 | ChangeCipherSpec, | | | 496 | Finished) | | | 497 |------------------------>| | | 498 | | | | 499 | EAP-Request/ | | | 500 | Type=TEAP, | | | 501 | TLS(ChangeCipherSpec, | | | 502 | Finished), | | | 503 | {Crypto-Binding TLV, | | | 504 | Result TLV=Success} | | | 505 |<------------------------| | | 506 | | | | 507 | EAP-Response/ | | | 508 | Type=TEAP, | | | 509 | {Crypto-Binding TLV, | | | 510 | Result TLV=Success} | | | 511 |------------------------>| | | 512 | | | | 513 | EAP-Request/ | | | 514 | Type=TEAP, | | | 515 | {Request-Action TLV: | | | 516 | Status=Failure, | | | 517 | Action=Process-TLV, | | | 518 | TLV=PKCS#10} | | | 519 |<------------------------| | | 520 | | | | 521 STEP 3: Enroll for certificate 522 | | | | 523 | EAP-Response/ | | | 524 | Type=TEAP, | | | 525 | {PKCS#10 TLV: | | | 526 | SAN:"MAC/serial"} | | | 527 |------------------------>| | | 528 | | POST /newOrder | | 529 | | "pledgeX.domain.com" | | 530 | |--------------------->| | 531 | | | | 532 | | 201 status=ready | | 533 | |<---------------------| | 534 | | | | 535 | | POST /finalize | | 536 | | CSR "pledgeX.domain.com" | 537 | |--------------------->| | 538 | | | | 539 | | 200 OK status=valid | | 540 | |<---------------------| | 541 | | | | 542 | | POST /certificate | | 543 | |--------------------->| | 544 | | | | 545 | | 200 OK | | 546 | | PKI "pledgeX.domain.com" | 547 | |<---------------------| | 548 | | | | 549 | EAP-Request/ | | | 550 | Type=TEAP, | | | 551 | {PKCS#7 TLV, | | | 552 | Result TLV=Success} | | | 553 |<------------------------| | | 554 | | | | 555 | EAP-Response/ | | | 556 | Type=TEAP, | | | 557 | {Result TLV=Success} | | | 558 |------------------------>| | | 559 | | | | 560 | EAP-Success | | | 561 |<------------------------| | | 563 7. ACME Integration with TEAP-BRSKI 565 TEAP-BRSKI draft-lear-eap-teap-brski defines... and its very similar 566 to the TEAP proposal in the prevous section. 568 8. IANA Considerations 570 [todo] 572 9. Security Considerations 574 [todo] 576 10. Informative References 578 [I-D.ietf-anima-bootstrapping-keyinfra] 579 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 580 S., and K. Watsen, "Bootstrapping Remote Secure Key 581 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 582 keyinfra-20 (work in progress), May 2019. 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, 586 DOI 10.17487/RFC2119, March 1997, 587 . 589 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 590 "Enrollment over Secure Transport", RFC 7030, 591 DOI 10.17487/RFC7030, October 2013, 592 . 594 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 595 "Tunnel Extensible Authentication Protocol (TEAP) Version 596 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 597 . 599 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 600 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 601 May 2017, . 603 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 604 Kasten, "Automatic Certificate Management Environment 605 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 606 . 608 Appendix A. Comments 610 Authors' Addresses 612 Owen Friel 613 Cisco 615 Email: ofriel@cisco.com 616 Richard Barnes 617 Cisco 619 Email: rlb@ipv.sx