idnits 2.17.1 draft-ietf-acme-integrations-04.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 (June 23, 2021) is 1031 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-friel-acme-subdomains-04 == Outdated reference: A later version (-08) exists of draft-ietf-anima-brski-cloud-00 == Outdated reference: A later version (-06) exists of draft-lear-eap-teap-brski-05 Summary: 0 errors (**), 0 flaws (~~), 4 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: Informational Cisco 5 Expires: December 25, 2021 R. Shekh-Yusef 6 Auth0 7 M. Richardson 8 Sandelman Software Works 9 June 23, 2021 11 ACME Integrations 12 draft-ietf-acme-integrations-04 14 Abstract 16 This document outlines multiple advanced use cases and integrations 17 that ACME facilitates without any modifications or enhancements 18 required to the base ACME specification. The use cases include ACME 19 integration with EST, BRSKI and TEAP. 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 https://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 December 25, 2021. 38 Copyright Notice 40 Copyright (c) 2021 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 (https://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. ACME Integration with EST . . . . . . . . . . . . . . . . . . 4 58 4. ACME Integration with BRSKI . . . . . . . . . . . . . . . . . 7 59 5. ACME Integration with BRSKI Default Cloud Registrar . . . . . 9 60 6. ACME Integration with TEAP . . . . . . . . . . . . . . . . . 11 61 7. ACME Integration Considerations . . . . . . . . . . . . . . . 14 62 7.1. Service Operators . . . . . . . . . . . . . . . . . . . . 14 63 7.2. CSR Attributes . . . . . . . . . . . . . . . . . . . . . 15 64 7.3. Certificate Chains and Trust Anchors . . . . . . . . . . 15 65 7.3.1. EST /cacerts . . . . . . . . . . . . . . . . . . . . 15 66 7.3.2. TEAP PKCS#7 TLV . . . . . . . . . . . . . . . . . . . 16 67 7.4. id-kp-cmcRA . . . . . . . . . . . . . . . . . . . . . . . 16 68 7.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 16 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 9.1. Denial of Service against ACME infrastructure . . . . . . 18 72 10. Informative References . . . . . . . . . . . . . . . . . . . 19 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 75 1. Introduction 77 ACME [RFC8555] defines a protocol that a certificate authority (CA) 78 and an applicant can use to automate the process of domain name 79 ownership validation and X.509 (PKIX) certificate issuance. The 80 protocol is rich and flexible and enables multiple use cases that are 81 not immediately obvious from reading the specification. This 82 document explicitly outlines multiple advanced ACME use cases 83 including: 85 o ACME integration with EST [RFC7030] 87 o ACME integration with BRSKI [RFC8995] 89 o ACME integration with BRSKI Default Cloud Registrar 90 [I-D.ietf-anima-brski-cloud] 92 o ACME integration with TEAP [RFC7170] and TEAP Update and 93 Extensions for Bootstrapping [I-D.lear-eap-teap-brski] 95 The integrations with EST, BRSKI (which is based upon EST), and TEAP 96 enable automated certificate enrollment for devices. 98 ACME for subdomains [I-D.friel-acme-subdomains] outlines how ACME can 99 be used by a client to obtain a certificate for a subdomain 100 identifier from a certificate authority where the client has 101 fulfilled a challenge against a parent domain, but does not need to 102 fulfil a challenge against the explicit subdomain. This is a useful 103 optimization when ACME is used to issue certificates for large 104 numbers of devices as it reduces the domain ownership proof traffic 105 (DNS or HTTP) and ACME traffic overhead, but is not a necessary 106 requirement. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 The following terms are defined in the CA/Browser Forum Baseline 117 Requirements [CAB] and are reproduced here: 119 o Authorization Domain Name (ADN): The Domain Name used to obtain 120 authorization for certificate issuance for a given FQDN. The CA 121 may use the FQDN returned from a DNS CNAME lookup as the FQDN for 122 the purposes of domain validation. If the FQDN contains a 123 wildcard character, then the CA MUST remove all wildcard labels 124 from the left most portion of requested FQDN. The CA may prune 125 zero or more labels from left to right until encountering a Base 126 Domain Name and may use any one of the intermediate values for the 127 purpose of domain validation 129 o Base Domain Name: The portion of an applied-for FQDN that is the 130 first domain name node left of a registry-controlled or public 131 suffix plus the registry-controlled or public suffix (e.g. 132 "example.co.uk" or "example.com"). For FQDNs where the right-most 133 domain name node is a gTLD having ICANN Specification 13 in its 134 registry agreement, the gTLD itself may be used as the Base Domain 135 Name. 137 o Certification Authority (CA): An organization that is responsible 138 for the creation, issuance, revocation, and management of 139 Certificates. The term applies equally to both Roots CAs and 140 Subordinate CAs 142 o Domain Name: The label assigned to a node in the Domain Name 143 System 145 o Domain Namespace: The set of all possible Domain Names that are 146 subordinate to a single node in the Domain Name System 148 o Fully-Qualified Domain Name (FQDN): A Domain Name that includes 149 the labels of all superior nodes in the Internet Domain Name 150 System. 152 The following terms are used in this document: 154 o BRSKI: Bootstrapping Remote Secure Key Infrastructures [RFC8995] 156 o CMC: Certificate Management over CMS 158 o CSR: Certificate Signing Request 160 o EST: Enrollment over Secure Transport [RFC7030] 162 o RA: PKI Registration Authority 164 o TEAP: Tunneled Extensible Authentication Protocol [RFC7170] 166 3. ACME Integration with EST 168 EST [RFC7030] defines a mechanism for clients to enroll with a PKI 169 Registration Authority by sending CMC messages over HTTP. EST 170 section 1 states: 172 "Architecturally, the EST service is located between a Certification 173 Authority (CA) and a client. It performs several functions 174 traditionally allocated to the Registration Authority (RA) role in a 175 PKI." 177 EST section 1.1 states that: 179 "For certificate issuing services, the EST CA is reached through the 180 EST server; the CA could be logically "behind" the EST server or 181 embedded within it." 183 When the CA is logically "behind" the EST RA, EST does not specify 184 how the RA communicates with the CA. EST section 1 states: 186 "The nature of communication between an EST server and a CA is not 187 described in this document." 189 This section outlines how ACME could be used for communication 190 between the EST RA and the CA. The example call flow leverages 191 [I-D.friel-acme-subdomains] and shows the RA proving ownership of a 192 parent domain, with individual client certificates being subdomains 193 under that parent domain. This is an optimization that reduces DNS 194 and ACME traffic overhead. The RA could of course prove ownership of 195 every explicit client certificate identifier. 197 The call flow illustrates the client calling the EST /csrattrs API 198 before calling the EST /simpleenroll API. 200 The call flow illustrates the EST RA returning a 202 Retry-After 201 response to the client's simpleenroll request. This is an optional 202 step and may be necessary if the interactions between the RA and the 203 ACME server take some time to complete. The exact details of when 204 the RA returns a 202 Retry-After are implementation specific. 206 +--------+ +--------+ +------+ +-----+ 207 | Pledge | | EST RA | | ACME | | DNS | 208 +--------+ +--------+ +------+ +-----+ 209 | | | | 210 STEP 1: Pre-Authorization of parent domain 211 | | | | 212 | | POST /newAuthz | | 213 | | "example.com" | | 214 | |--------------------->| | 215 | | | | 216 | | 201 authorizations | | 217 | |<---------------------| | 218 | | | | 219 | | Publish DNS TXT | | 220 | | "example.com" | | 221 | |--------------------------------->| 222 | | | | 223 | | POST /challenge | | 224 | |--------------------->| | 225 | | | Verify | 226 | | |---------->| 227 | | 200 status=valid | | 228 | |<---------------------| | 229 | | | | 230 | | Delete DNS TXT | | 231 | | "example.com" | | 232 | |--------------------------------->| 233 | | | | 234 STEP 2: Pledge enrolls against RA 235 | | | | 236 | GET /csrattrs | | | 237 |--------------------->| | | 238 | | | | 239 | 200 OK | | | 240 | SEQUENCE {AttrOrOID} | | | 241 | SAN OID: | | | 242 | "pledge.example.com" | | | 243 |<---------------------| | | 244 | | | | 245 | POST /simpleenroll | | | 246 | PCSK#10 CSR | | | 247 | "pledge.example.com" | | | 248 |--------------------->| | | 249 | | | | 250 | 202 Retry-After | | | 251 |<---------------------| | | 252 | | | | 253 STEP 3: RA places ACME order 254 | | | | 255 | | POST /newOrder | | 256 | | "pledge.example.com" | | 257 | |--------------------->| | 258 | | | | 259 | | 201 status=ready | | 260 | |<---------------------| | 261 | | | | 262 | | POST /finalize | | 263 | | PKCS#10 CSR | | 264 | | "pledge.example.com" | | 265 | |--------------------->| | 266 | | | | 267 | | 200 OK status=valid | | 268 | |<---------------------| | 269 | | | | 270 | | POST /certificate | | 271 | |--------------------->| | 272 | | | | 273 | | 200 OK | | 274 | | PKCS#7 | | 275 | | "pledge.example.com" | | 276 | |<---------------------| | 277 | | | | 278 STEP 4: Pledge retries enroll 279 | | | | 280 | POST /simpleenroll | | | 281 | PCSK#10 CSR | | | 282 | "pledge.example.com" | | | 283 |--------------------->| | | 284 | | | | 285 | 200 OK | | | 286 | PKCS#7 | | | 287 | "pledge.example.com" | | | 288 |<---------------------| | | 290 4. ACME Integration with BRSKI 292 BRSKI [RFC8995] is based upon EST [RFC7030] and defines how to 293 autonomically bootstrap PKI trust anchors into devices via means of 294 signed vouchers. EST certificate enrollment may then optionally take 295 place after trust has been established. BRKSI voucher exchange and 296 trust establishment are based on EST extensions and the certificate 297 enrollment part of BRSKI is fully based on EST. Similar to EST, 298 BRSKI does not define how the EST RA communicates with the CA. 299 Therefore, the mechanisms outlined in the previous section for using 300 ACME as the communications protocol between the EST RA and the CA are 301 equally applicable to BRSKI. 303 The following call flow shows how ACME may be integrated into a full 304 BRSKI voucher plus EST enrollment workflow. For brevity, it assumes 305 that the EST RA has previously proven ownership of a parent domain 306 and that pledge certificate identifiers are a subdomain of that 307 parent domain. The domain ownership exchanges between the RA, ACME 308 and DNS are not shown. Similarly, not all BRSKI interactions are 309 shown and only the key protocol flows involving voucher exchange and 310 EST enrollment are shown. 312 Similar to the EST section above, the client calls EST /csrattrs API 313 before calling the EST /simpleenroll API. This enables the server to 314 indicate what fields the pledge should include in the CSR that the 315 client sends in the /simpleenroll API. 317 The call flow illustrates the RA returning a 202 Retry-After response 318 to the initial EST /simpleenroll API. This may be appropriate if 319 processing of the /simpleenroll request and ACME interactions takes 320 some timme to complete. 322 +--------+ +--------+ +------+ +------+ 323 | Pledge | | EST RA | | ACME | | MASA | 324 +--------+ +--------+ +------+ +------+ 325 | | | | 326 NOTE: Pre-Authorization of "example.com" is complete 327 | | | | 328 STEP 1: Pledge requests Voucher 329 | | | | 330 | POST /requestvoucher | | | 331 |--------------------->| | | 332 | | POST /requestvoucher | | 333 | |--------------------------------->| 334 | | | | 335 | | 200 OK Voucher | | 336 | |<---------------------------------| 337 | 200 OK Voucher | | | 338 |<---------------------| | | 339 | | | | 340 STEP 2: Pledge enrolls against RA 341 | | | | 342 | GET /csrattrs | | | 343 |--------------------->| | | 344 | | | | 345 | 200 OK | | | 346 | SEQUENCE {AttrOrOID} | | | 347 | SAN OID: | | | 348 | "pledge.example.com" | | | 349 |<---------------------| | | 350 | | | | 351 | POST /simpleenroll | | | 352 | PCSK#10 CSR | | | 353 | "pledge.example.com" | | | 354 |--------------------->| | | 355 | | | | 356 | 202 Retry-After | | | 357 |<---------------------| | | 358 | | | | 359 STEP 3: RA places ACME order 360 | | | | 361 | | POST /newOrder | | 362 | | "pledge.example.com" | | 363 | |--------------------->| | 364 | | | | 365 | | 201 status=ready | | 366 | |<---------------------| | 367 | | | | 368 | | POST /finalize | | 369 | | PKCS#10 CSR | | 370 | | "pledge.example.com" | | 371 | |--------------------->| | 372 | | | | 373 | | 200 OK status=valid | | 374 | |<---------------------| | 375 | | | | 376 | | POST /certificate | | 377 | |--------------------->| | 378 | | | | 379 | | 200 OK | | 380 | | PKCS#7 | | 381 | | "pledge.example.com" | | 382 | |<---------------------| | 383 | | | | 384 STEP 4: Pledge retries enroll 385 | | | | 386 | POST /simpleenroll | | | 387 | PCSK#10 CSR | | | 388 | "pledge.example.com" | | | 389 |--------------------->| | | 390 | | | | 391 | 200 OK | | | 392 | PKCS#7 | | | 393 | "pledge.example.com" | | | 394 |<---------------------| | | 396 5. ACME Integration with BRSKI Default Cloud Registrar 398 BRSKI Cloud Registrar [I-D.ietf-anima-brski-cloud] specifies the 399 behaviour of a BRSKI Cloud Registrar, and how a pledge can interact 400 with a BRSKI Cloud Registrar when bootstrapping. Similar to the 401 local domain registrar BRSKI flow, ACME can be easily integrated with 402 a cloud registrar bootstrap flow. 404 BRSKI cloud registrar is flexible and allows for multiple different 405 local domain discovery and redirect scenarios. In the example 406 illustrated here, the extension to [RFC8366] Vouchers which is 407 defined in [I-D.ietf-anima-brski-cloud], and allows the specification 408 of a bootstrap EST domain, is leveraged. This extension allows the 409 cloud registrar to specify the local domain RA that the pledge should 410 connect to for the purposes of EST enrollment. 412 Similar to the sectioms above, the client calls EST /csrattrs API 413 before calling the EST /simpleenroll API. 415 +--------+ +--------+ +------+ +----------+ 416 | Pledge | | EST RA | | ACME | | Cloud RA | 417 +--------+ +--------+ +------+ | / MASA | 418 | +----------+ 419 | | 420 NOTE: Pre-Authorization of "example.com" is complete 421 | | 422 STEP 1: Pledge requests Voucher from Cloud Registrar 423 | | 424 | POST /requestvoucher | 425 |-------------------------------------------------------->| 426 | | 427 | 200 OK Voucher (includes 'est-domain') | 428 |<--------------------------------------------------------| 429 | | | | 430 STEP 2: Pledge enrolls against local domain RA 431 | | | | 432 | GET /csrattrs | | | 433 |--------------------->| | | 434 | | | | 435 | 200 OK | | | 436 | SEQUENCE {AttrOrOID} | | | 437 | SAN OID: | | | 438 | "pledge.example.com" | | | 439 |<---------------------| | | 440 | | | | 441 | POST /simpleenroll | | | 442 | PCSK#10 CSR | | | 443 | "pledge.example.com" | | | 444 |--------------------->| | | 445 | | | | 446 | 202 Retry-After | | | 447 |<---------------------| | | 448 | | | | 449 STEP 3: RA places ACME order 450 | | | | 451 | | POST /newOrder | | 452 | | "pledge.example.com" | | 453 | |--------------------->| | 454 | | | | 455 | | 201 status=ready | | 456 | |<---------------------| | 457 | | | | 458 | | POST /finalize | | 459 | | PKCS#10 CSR | | 460 | | "pledge.example.com" | | 461 | |--------------------->| | 462 | | | | 463 | | 200 OK status=valid | | 464 | |<---------------------| | 465 | | | | 466 | | POST /certificate | | 467 | |--------------------->| | 468 | | | | 469 | | 200 OK | | 470 | | PKCS#7 | | 471 | | "pledge.example.com" | | 472 | |<---------------------| | 473 | | | | 474 STEP 4: Pledge retries enroll 475 | | | | 476 | POST /simpleenroll | | | 477 | PCSK#10 CSR | | | 478 | "pledge.example.com" | | | 479 |--------------------->| | | 480 | | | | 481 | 200 OK | | | 482 | PKCS#7 | | | 483 | "pledge.example.com" | | | 484 |<---------------------| | | 486 6. ACME Integration with TEAP 488 TEAP [RFC7170] defines a tunnel-based EAP method that enables secure 489 communication between a peer and a server by using TLS to establish a 490 mutually authenticated tunnel. TEAP enables certificate provisioning 491 within the tunnel. TEAP Update and Extensions for Bootstrapping 492 [I-D.lear-eap-teap-brski] defines extensions to TEAP that includes 493 additional TLVs for certificate enrollment and BRSKI handling inside 494 the TEAP tunnel. Neither TEAP [RFC7170] or TEAP Update and 495 Extensions for Bootstrapping [I-D.lear-eap-teap-brski] define how the 496 TEAP server communicates with the CA. 498 This section outlines how ACME could be used for communication 499 between the TEAP server and the CA. The example call flow leverages 500 [I-D.friel-acme-subdomains] and shows the TEAP server proving 501 ownership of a parent domain, with individual client certificates 502 being subdomains under that parent domain. 504 The example illustrates the TEAP server sending a Request-Action TLV 505 including a CSR-Attributes TLV instructing the peer to send a CSR- 506 Attributes TLV to the server. This enables the server to indicate 507 what fields the peer should include in the CSR that the peer sends in 508 the PKCS#10 TLV. For example, the TEAP server could instruct the 509 peer what Subject or SAN entries to include in its CSR. 511 Althought not explicitly illustrated in this call flow, the Peer and 512 TEAP Server could exchange BRSKI TLVs, and a BRSKI integration and 513 voucher exchange with a MASA server could take place over TEAP. 514 Whether a BRSKI TLV exchange takes place or not does not impact the 515 ACME specific message exchanges. 517 +------+ +-------------+ +------+ +-----+ 518 | Peer | | TEAP-Server | | ACME | | DNS | 519 +------+ +-------------+ +------+ +-----+ 520 | | | | 521 STEP 1: Pre-Authorization of parent domain 522 | | | | 523 | | POST /newAuthz | | 524 | | "example.com" | | 525 | |--------------------->| | 526 | | | | 527 | | 201 authorizations | | 528 | |<---------------------| | 529 | | | | 530 | | Publish DNS TXT | | 531 | | "example.com" | | 532 | |--------------------------------->| 533 | | | | 534 | | POST /challenge | | 535 | |--------------------->| | 536 | | | Verify | 537 | | |---------->| 538 | | 200 status=valid | | 539 | |<---------------------| | 540 | | | | 541 | | Delete DNS TXT | | 542 | | "example.com" | | 543 | |--------------------------------->| 544 | | | | 545 | | | | 546 STEP 2: Establsh EAP Outer Tunnel 547 | | | | 548 | EAP-Request/ | | | 549 | Type=Identity | | | 550 |<------------------------| | | 551 | | | | 552 | EAP-Response/ | | | 553 | Type=Identity | | | 554 |------------------------>| | | 555 | | | | 556 | EAP-Request/ | | | 557 | Type=TEAP, | | | 558 | TEAP Start, | | | 559 | Authority-ID TLV | | | 560 |<------------------------| | | 561 | | | | 562 | EAP-Response/ | | | 563 | Type=TEAP, | | | 564 | TLS(ClientHello) | | | 565 |------------------------>| | | 566 | | | | 567 | EAP-Request/ | | | 568 | Type=TEAP, | | | 569 | TLS(ServerHello, | | | 570 | Certificate, | | | 571 | ServerKeyExchange, | | | 572 | CertificateRequest, | | | 573 | ServerHelloDone) | | | 574 |<------------------------| | | 575 | | | | 576 | EAP-Response/ | | | 577 | Type=TEAP, | | | 578 | TLS(Certificate, | | | 579 | ClientKeyExchange, | | | 580 | CertificateVerify, | | | 581 | ChangeCipherSpec, | | | 582 | Finished) | | | 583 |------------------------>| | | 584 | | | | 585 | EAP-Request/ | | | 586 | Type=TEAP, | | | 587 | TLS(ChangeCipherSpec, | | | 588 | Finished), | | | 589 | {Crypto-Binding TLV, | | | 590 | Result TLV=Success} | | | 591 |<------------------------| | | 592 | | | | 593 | EAP-Response/ | | | 594 | Type=TEAP, | | | 595 | {Crypto-Binding TLV, | | | 596 | Result TLV=Success} | | | 597 |------------------------>| | | 598 | | | | 599 | EAP-Request/ | | | 600 | Type=TEAP, | | | 601 | {Request-Action TLV: | | | 602 | Status=Failure, | | | 603 | Action=Process-TLV, | | | 604 | TLV=CSR-Attributes, | | | 605 | TLV=PKCS#10} | | | 606 |<------------------------| | | 607 | | | | 608 STEP 3: Enroll for certificate 609 | | | | 610 | EAP-Response/ | | | 611 | Type=TEAP, | | | 612 | {CSR-Attributes TLV} | | | 613 |------------------------>| | | 614 | | | | 615 | EAP-Request/ | | | 616 | Type=TEAP, | | | 617 | {CSR-Attributes TLV} | | | 618 |<------------------------| | | 619 | | | | 620 | EAP-Response/ | | | 621 | Type=TEAP, | | | 622 | {PKCS#10 TLV: | | | 623 | "pledge.example.com"} | | | 624 |------------------------>| | | 625 | | POST /newOrder | | 626 | | "pledge.example.com" | | 627 | |--------------------->| | 628 | | | | 629 | | 201 status=ready | | 630 | |<---------------------| | 631 | | | | 632 | | POST /finalize | | 633 | | PKCS#10 CSR | | 634 | | "pledge.example.com" | | 635 | |--------------------->| | 636 | | | | 637 | | 200 OK status=valid | | 638 | |<---------------------| | 639 | | | | 640 | | POST /certificate | | 641 | |--------------------->| | 642 | | | | 643 | | 200 OK | | 644 | | PKCS#7 | | 645 | | "pledge.example.com" | | 646 | |<---------------------| | 647 | | | | 648 | EAP-Request/ | | | 649 | Type=TEAP, | | | 650 | {PKCS#7 TLV, | | | 651 | Result TLV=Success} | | | 652 |<------------------------| | | 653 | | | | 654 | EAP-Response/ | | | 655 | Type=TEAP, | | | 656 | {Result TLV=Success} | | | 657 |------------------------>| | | 658 | | | | 659 | EAP-Success | | | 660 |<------------------------| | | 662 7. ACME Integration Considerations 664 7.1. Service Operators 666 The goal of these integrations is enabling issuance of certificates 667 with identitiers in a given domain by an ACME server to a client. It 668 is expected that the EST RA or TEAP servers that the client sends 669 certificate enrollment requests to are operated by the organization 670 that controls the domains. The ACME server is not necessarily 671 operated by the organization that controls the domain. 673 7.2. CSR Attributes 675 In all integrations, the client MUST send a CSR Attributes request to 676 the EST or TEAP server prior to sending a certificate enrollment 677 request. This enables the server to indicate to the client what 678 attributes it expects the client to include in the subsequent CSR 679 request. 681 Servers MUST use this mechanism to tell the client what identifiers 682 to include in CSR request. ACME [RFC8555] allows the identifier to 683 be included in either CSR Subject or Subject Alternative Name fields, 684 however [I-D.ietf-uta-use-san] states that Subject Alternative Name 685 field MUST be used. This document aligns with [I-D.ietf-uta-use-san] 686 and Subject Alternate Name field MUST be used. The identifier must 687 be a Domain Name in a Domain Namespace that the server has control 688 over and can fulfill ACME challenges against. The leftmost part of 689 the identifier MAY be a field that the client presented to the server 690 in an IEEE 802.1AR [IDevID]. 692 Servers MAY use this field to instruct the client to include other 693 attributes such as specific policy OIDs. Refer to EST [RFC7030] 694 section 2.6 for further details. 696 7.3. Certificate Chains and Trust Anchors 698 ACME [RFC8555] section 9.1 states that ACME servers may return a 699 certificate chain to an ACME client where an end entity certificate 700 is followed by certificates that certify it. The trust anchor 701 certificate MAY be ommitted from the chain as it is assumed that the 702 trust anchor is already known by the ACME client i.e. the EST or TEAP 703 server. 705 7.3.1. EST /cacerts 707 EST [RFC7030] section 4.2.3 states that the /simpleenroll response 708 contains "only the certificate that was issued". EST [RFC7030] 709 section 4.1.3 states that the /cacerts response "MUST include any 710 additional certificates the client would need to build a chain from 711 an EST CA-issued certificate to the current EST CA TA". 713 Therefore, the EST server MUST return only the ACME end entity 714 certificate in the /simpleenroll response. The EST server MUST 715 return the remainder of the chain returned by the ACME server to the 716 EST server in the /cacerts response to the client, appending the 717 trust anchor root CA if necessary. 719 7.3.2. TEAP PKCS#7 TLV 721 TEAP [RFC7170] section 4.2.16 allows for download of a PKCS#7 722 certificate chain in response to a TEAP PKCS#10 TLV request. TEAP 723 also allows for download of multiple PKCS#7 certificates in response 724 to a TEAP Trusted-Server-Root TLV request. 726 The TEAP server MUST return the full ACME client certificate chain in 727 the PKCS#7 response to the PKCS#10 TLV request. The TEAP server MUST 728 return the ACME server trust anchor in a PKCS#7 response to a 729 Trusted-Server-Root TLV request. As outlined in Section 7.4, the 730 TEAP server SHOULD also return the trust anchor that was used for 731 issuing its own identity certificate, if different from the ACME 732 server trust anchor. 734 7.4. id-kp-cmcRA 736 BRSKI [RFC8995] mandates that the id-kp-cmcRA extended key usage bit 737 is set in the Registrar (or EST RA) end entity certificate that the 738 Registrar uses when signing voucher request messages sent to the 739 MASA. Public ACME servers may not be willing to issue end entity 740 certificates that have the id-kp-cmcRA extended key usage bit set. 741 In these scenarios, the EST RA may be used by the pledge to get 742 issued certificates by a public ACME server, but the EST RA itself 743 will need an end entity certificate that has been issued by a 744 different CA (e.g. an operator deployed private CA) and that has the 745 id-kp-cmcRA bit set. 747 7.5. Error Handling 749 ACME [RFC8555] section 6.7 defines multiple errors that may be 750 returned by an ACME server to an ACME client. TEAP [RFC7170] section 751 4.2.6 defines multiple errors that may be returned by a TEAP server 752 to a client in an Error TLV. EST [RFC7030] section 4.2.3 defines how 753 an EST server may return an error encoded in a CMC response, or may 754 return a human readable error in the response body. 756 The following mapping from ACME errors to CMC [RFC5272] section 6.1.4 757 CMCFailInfo and TEAP [RFC7170] section 4.2.6 error codes is 758 RECOMMENDED. 760 +--------------------+-----------------+--------------------------+ 761 | ACME | CMCFailInfo | TEAP Error Code | 762 +--------------------+-----------------+--------------------------+ 763 | badCSR | badRequest | 1025 Bad CSR | 764 | caa | badRequest | 1025 Bad CSR | 765 | rejectedIdentifier | badIdentity | 1024 Bad Identity In CSR | 766 | all other errors | internalCAError | 1026 Internal CA Error | 767 +--------------------+-----------------+--------------------------+ 769 8. IANA Considerations 771 This document does not make any requests to IANA. 773 9. Security Considerations 775 This draft is informational and makes no changes to the referenced 776 specifications. All security considerations from these referenced 777 documents are applicable here: 779 o EST [RFC7030] 781 o BRSKI [RFC8995] 783 o BRSKI Default Cloud Registrar [I-D.ietf-anima-brski-cloud] 785 o TEAP [RFC7170] and TEAP Update and Extensions for Bootstrapping 786 [I-D.lear-eap-teap-brski] 788 Additionally, all Security Considerations in ACME in the following 789 areas are equally applicable to ACME Integrations. 791 The integration mechanisms proposed here will primarily use the 792 DNS-01 challenge documented in [RFC8555] section 8.4. The security 793 considerations in RFC8555 says: 795 The DNS is a common point of vulnerability for all of these 796 challenges. An entity that can provision false DNS records for a 797 domain can attack the DNS challenge directly and can provision false 798 A/AAAA records to direct the ACME server to send its HTTP validation 799 query to a remote server of the attacker's choosing. 801 It is expected that the TEAP-EAP server/EST Registrar will perform 802 DNS dynamic updates to a DNS primary server using [RFC3007] Dynamic 803 updates, secured with with either SIG(0), or TSIG keys. 805 A major source of vulnerability is the disclosure of these DNS key 806 records. An attacker that has access to them, can provision their 807 own certificates into the the name space of the entity. 809 For many uses, this may allow the attacker to get access to some 810 enterprise resource. When used to provision, for instance, a (SIP) 811 phone system this would permit an attacker to impersonate a 812 legitimate phone. Not only does this allow for redirection of phone 813 calls, but possibly also toll fraud. 815 Operators should consider restricting the integration server such 816 that it can only update the DNS records for a specific zone or zones 817 where ACME is required for client certificate enrollment automation. 818 For example, if all IoT devices in an organisation enroll using EST 819 against an EST RA, and all IoT devices will be issued certificates in 820 a subdomain under iot.example.com, then the integration server could 821 be issued a credential that only allows updating of DNS records in a 822 zone that includes domains in the iot.example.com namespace, but does 823 not allow updating of DNS records under any other example.com DNS 824 namespace. 826 When performing challenge fulfilment via writing files to HTTP 827 webservers, write access should only be granted to a specific set of 828 servers, and only to a specific set of directories for storage of 829 challenge files. 831 9.1. Denial of Service against ACME infrastructure 833 The intermdiate node (the TEAP-EAP server, or the EST Registrar) 834 should cache the resulting certificates such that if the 835 communication with the pledge is lost, subsequent attempts to enroll 836 will result in the cache certificate being returned. 838 As many ACME servers have per-day, per-IP and per-subjectAltName 839 limits, it is prudent not to request identical certificates too 840 often. This could be due to operator or installer error, with 841 multiple configuration resets occuring within a short period of time. 843 The cache should be indexed by the complete contents of the 844 Certificate Signing Request, and should not persist beyond the 845 notAfter date in the certificate. 847 This means that if the private/public keypair changes on the pledge, 848 then a new certificate will be issued. If the the requested 849 SubjectAltName changes, then a new certificate will be requested. 851 In a case where a device is simply factory reset, and enrolls again, 852 then the same certificate can be returned. 854 10. Informative References 856 [CAB] CA/Browser Forum, "Baseline Requirements for the Issuance 857 and Management of Publicly-Trusted Certificates", n.d., 858 . 861 [I-D.friel-acme-subdomains] 862 Friel, O., Barnes, R., Hollebeek, T., and M. Richardson, 863 "ACME for Subdomains", draft-friel-acme-subdomains-04 864 (work in progress), March 2021. 866 [I-D.ietf-anima-brski-cloud] 867 Friel, O., Shekh-Yusef, R., and M. Richardson, "BRSKI 868 Cloud Registrar", draft-ietf-anima-brski-cloud-00 (work in 869 progress), April 2021. 871 [I-D.ietf-uta-use-san] 872 Salz, R., "Update to Verifying TLS Server Identities with 873 X.509 Certificates", draft-ietf-uta-use-san-00 (work in 874 progress), April 2021. 876 [I-D.lear-eap-teap-brski] 877 Lear, E., Friel, O., Cam-Winget, N., and D. Harkins, "TEAP 878 Update and Extensions for Bootstrapping", draft-lear-eap- 879 teap-brski-05 (work in progress), November 2019. 881 [IDevID] IEEE, "IEEE Standard for Local and metropolitan area 882 networks - Secure Device Identity", n.d., 883 . 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", BCP 14, RFC 2119, 887 DOI 10.17487/RFC2119, March 1997, 888 . 890 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 891 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 892 . 894 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 895 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 896 . 898 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 899 "Enrollment over Secure Transport", RFC 7030, 900 DOI 10.17487/RFC7030, October 2013, 901 . 903 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 904 "Tunnel Extensible Authentication Protocol (TEAP) Version 905 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 906 . 908 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 909 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 910 May 2017, . 912 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 913 "A Voucher Artifact for Bootstrapping Protocols", 914 RFC 8366, DOI 10.17487/RFC8366, May 2018, 915 . 917 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 918 Kasten, "Automatic Certificate Management Environment 919 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 920 . 922 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 923 and K. Watsen, "Bootstrapping Remote Secure Key 924 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 925 May 2021, . 927 Authors' Addresses 929 Owen Friel 930 Cisco 932 Email: ofriel@cisco.com 934 Richard Barnes 935 Cisco 937 Email: rlb@ipv.sx 939 Rifaat Shekh-Yusef 940 Auth0 942 Email: rifaat.s.ietf@gmail.com 944 Michael Richardson 945 Sandelman Software Works 947 Email: mcr+ietf@sandelman.ca