idnits 2.17.1 draft-ietf-acme-integrations-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 09, 2021) is 1116 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-03 == Outdated reference: A later version (-04) exists of draft-friel-anima-brski-cloud-03 == Outdated reference: A later version (-06) exists of draft-lear-eap-teap-brski-05 Summary: 0 errors (**), 0 flaws (~~), 5 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: September 10, 2021 R. Shekh-Yusef 6 Auth0 7 M. Richardson 8 Sandelman Software Works 9 March 09, 2021 11 ACME Integrations 12 draft-ietf-acme-integrations-03 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 September 10, 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 . . . . . . . . . . . . . . . . . . 3 58 4. ACME Integration with BRSKI . . . . . . . . . . . . . . . . . 6 59 5. ACME Integration with BRSKI Default Cloud Registrar . . . . . 8 60 6. ACME Integration with TEAP . . . . . . . . . . . . . . . . . 10 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 8.1. Denial of Service against ACME infrastructure . . . . . . 15 64 9. Informative References . . . . . . . . . . . . . . . . . . . 16 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 67 1. Introduction 69 ACME [RFC8555] defines a protocol that a certificate authority (CA) 70 and an applicant can use to automate the process of domain name 71 ownership validation and X.509 (PKIX) certificate issuance. The 72 protocol is rich and flexible and enables multiple use cases that are 73 not immediately obvious from reading the specification. This 74 document explicitly outlines multiple advanced ACME use cases 75 including: 77 o ACME integration with EST [RFC7030] 79 o ACME integration with BRSKI 80 [I-D.ietf-anima-bootstrapping-keyinfra] 82 o ACME integration with BRSKI Default Cloud Registrar 83 [I-D.friel-anima-brski-cloud] 85 o ACME integration with TEAP [RFC7170] and TEAP Update and 86 Extensions for Bootstrapping [I-D.lear-eap-teap-brski] 88 The integrations with EST, BRSKI (which is based upon EST), and TEAP 89 enable automated certificate enrolment for devices. 91 ACME for subdomains [I-D.friel-acme-subdomains] outlines how ACME can 92 be used by a client to obtain a certificate for a subdomain 93 identifier from a certificate authority where the client has 94 fulfilled a challenge against a parent domain, but does not need to 95 fulfil a challenge against the explicit subdomain. This is a useful 96 optimization when ACME is used to issue certificates for large 97 numbers of devices as it reduces the domain ownership proof traffic 98 (DNS or HTTP) and ACME traffic overhead, but is not a necessary 99 requirement. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 The following terms are used in this document: 111 o BRSKI: Bootstrapping Remote Secure Key Infrastructures 112 [I-D.ietf-anima-bootstrapping-keyinfra] 114 o CA: Certificate Authority 116 o CMC: Certificate Management over CMS 118 o CSR: Certificate Signing Request 120 o EST: Enrollment over Secure Transport [RFC7030] 122 o FQDN: Fully Qualified Domain Name 124 o RA: PKI Registration Authority 126 o TEAP: Tunneled Extensible Authentication Protocol [RFC7170] 128 3. ACME Integration with EST 130 EST [RFC7030] defines a mechanism for clients to enroll with a PKI 131 Registration Authority by sending CMC messages over HTTP. EST 132 section 1 states: 134 "Architecturally, the EST service is located between a Certification 135 Authority (CA) and a client. It performs several functions 136 traditionally allocated to the Registration Authority (RA) role in a 137 PKI." 139 EST section 1.1 states that: 141 "For certificate issuing services, the EST CA is reached through the 142 EST server; the CA could be logically "behind" the EST server or 143 embedded within it." 144 When the CA is logically "behind" the EST RA, EST does not specify 145 how the RA communicates with the CA. EST section 1 states: 147 "The nature of communication between an EST server and a CA is not 148 described in this document." 150 This section outlines how ACME could be used for communication 151 between the EST RA and the CA. The example call flow leverages 152 [I-D.friel-acme-subdomains] and shows the RA proving ownership of a 153 parent domain, with individual client certificates being subdomains 154 under that parent domain. This is an optimization that reduces DNS 155 and ACME traffic overhead. The RA could of course prove ownership of 156 every explicit client certificate identifier. 158 The call flow illustrates the client calling the EST /csrattrs API 159 before calling the EST /simpleenroll API. This enables the EST 160 server to indicate to the client what attributes it expects the 161 client to include in the CSR request sent in the /simpleenroll API. 162 For example, EST servers could use this mechanism to tell the client 163 what fields to include in the CSR Subject and Subject Alternative 164 Name fields. 166 The call flow illustrates the EST RA returning a 202 Retry-After 167 response to the client's simpleenroll request. This is an optional 168 step and may be necessary if the interactions between the RA and the 169 ACME server take some time to complete. The exact details of when 170 the RA returns a 202 Retry-After are implementation specific. 172 +--------+ +--------+ +------+ +-----+ 173 | Pledge | | EST RA | | ACME | | DNS | 174 +--------+ +--------+ +------+ +-----+ 175 | | | | 176 STEP 1: Pre-Authorization of parent domain 177 | | | | 178 | | POST /newAuthz | | 179 | | "example.com" | | 180 | |--------------------->| | 181 | | | | 182 | | 201 authorizations | | 183 | |<---------------------| | 184 | | | | 185 | | Publish DNS TXT | | 186 | | "example.com" | | 187 | |--------------------------------->| 188 | | | | 189 | | POST /challenge | | 190 | |--------------------->| | 191 | | | Verify | 192 | | |---------->| 193 | | 200 status=valid | | 194 | |<---------------------| | 195 | | | | 196 | | Delete DNS TXT | | 197 | | "example.com" | | 198 | |--------------------------------->| 199 | | | | 200 STEP 2: Pledge enrolls against RA 201 | | | | 202 | GET /csrattrs | | | 203 |--------------------->| | | 204 | | | | 205 | 200 OK | | | 206 | SEQUENCE {AttrOrOID} | | | 207 | SAN OID: | | | 208 | "pledge.example.com" | | | 209 |<---------------------| | | 210 | | | | 211 | POST /simpleenroll | | | 212 | PCSK#10 CSR | | | 213 | "pledge.example.com" | | | 214 |--------------------->| | | 215 | | | | 216 | 202 Retry-After | | | 217 |<---------------------| | | 218 | | | | 219 STEP 3: RA places ACME order 220 | | | | 221 | | POST /newOrder | | 222 | | "pledge.example.com" | | 223 | |--------------------->| | 224 | | | | 225 | | 201 status=ready | | 226 | |<---------------------| | 227 | | | | 228 | | POST /finalize | | 229 | | PKCS#10 CSR | | 230 | | "pledge.example.com" | | 231 | |--------------------->| | 232 | | | | 233 | | 200 OK status=valid | | 234 | |<---------------------| | 235 | | | | 236 | | POST /certificate | | 237 | |--------------------->| | 238 | | | | 239 | | 200 OK | | 240 | | PEM | | 241 | | "pledge.example.com" | | 242 | |<---------------------| | 243 | | | | 244 STEP 4: Pledge retries enroll 245 | | | | 246 | POST /simpleenroll | | | 247 | PCSK#10 CSR | | | 248 | "pledge.example.com" | | | 249 |--------------------->| | | 250 | | | | 251 | 200 OK | | | 252 | PKCS#7 | | | 253 | "pledge.example.com" | | | 254 |<---------------------| | | 256 4. ACME Integration with BRSKI 258 BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] is based upon EST 259 [RFC7030] and defines how to autonomically bootstrap PKI trust 260 anchors into devices via means of signed vouchers. EST certificate 261 enrollment may then optionally take place after trust has been 262 established. BRKSI voucher exchange and trust establishment are 263 based on EST extensions and the certificate enrollment part of BRSKI 264 is fully based on EST. Similar to EST, BRSKI does not define how the 265 EST RA communicates with the CA. Therefore, the mechanisms outlined 266 in the previous section for using ACME as the communications protocol 267 between the EST RA and the CA are equally applicable to BRSKI. 269 Note that BRSKI mandates that the id-kp-cmcRA extended key usage bit 270 is set in the Registrar (or EST RA) end entity certificate that the 271 Registrar uses when signing voucher request messages sent to the 272 MASA. Public ACME servers may not be willing to issue end entity 273 certificates that have the id-kp-cmcRA extended key usage bit set. 274 In these scenarios, the EST RA may be used by the pledge to get 275 issued certificates by a public ACME server, but the EST RA itself 276 will need an end entity certificate that has been issued by a CA 277 (e.g. an operator deployed private CA) and that has the id-kp-cmcRA 278 bit set. 280 The following call flow shows how ACME may be integrated into a full 281 BRSKI voucher plus EST enrollment workflow. For brevity, it assumes 282 that the EST RA has previously proven ownership of a parent domain 283 and that pledge certificate identifiers are a subdomain of that 284 parent domain. The domain ownership exchanges between the RA, ACME 285 and DNS are not shown. Similarly, not all BRSKI interactions are 286 shown and only the key protocol flows involving voucher exchange and 287 EST enrollment are shown. 289 Similar to the EST section above, the client calls EST /csrattrs API 290 before calling the EST /simpleenroll API. This enables the server to 291 indicate what fields the pledge should include in the CSR that the 292 client sends in the /simpleenroll API. 294 The call flow illustrates the RA returning a 202 Retry-After response 295 to the initial EST /simpleenroll API. This may be appropriate if 296 processing of the /simpleenroll request and ACME interactions takes 297 some timme to complete. 299 +--------+ +--------+ +------+ +------+ 300 | Pledge | | EST RA | | ACME | | MASA | 301 +--------+ +--------+ +------+ +------+ 302 | | | | 303 NOTE: Pre-Authorization of "example.com" is complete 304 | | | | 305 STEP 1: Pledge requests Voucher 306 | | | | 307 | POST /requestvoucher | | | 308 |--------------------->| | | 309 | | POST /requestvoucher | | 310 | |--------------------------------->| 311 | | | | 312 | | 200 OK Voucher | | 313 | |<---------------------------------| 314 | 200 OK Voucher | | | 315 |<---------------------| | | 316 | | | | 317 STEP 2: Pledge enrolls against RA 318 | | | | 319 | GET /csrattrs | | | 320 |--------------------->| | | 321 | | | | 322 | 200 OK | | | 323 | SEQUENCE {AttrOrOID} | | | 324 | SAN OID: | | | 325 | "pledge.example.com" | | | 326 |<---------------------| | | 327 | | | | 328 | POST /simpleenroll | | | 329 | PCSK#10 CSR | | | 330 | "pledge.example.com" | | | 331 |--------------------->| | | 332 | | | | 333 | 202 Retry-After | | | 334 |<---------------------| | | 335 | | | | 336 STEP 3: RA places ACME order 338 | | | | 339 | | POST /newOrder | | 340 | | "pledge.example.com" | | 341 | |--------------------->| | 342 | | | | 343 | | 201 status=ready | | 344 | |<---------------------| | 345 | | | | 346 | | POST /finalize | | 347 | | PKCS#10 CSR | | 348 | | "pledge.example.com" | | 349 | |--------------------->| | 350 | | | | 351 | | 200 OK status=valid | | 352 | |<---------------------| | 353 | | | | 354 | | POST /certificate | | 355 | |--------------------->| | 356 | | | | 357 | | 200 OK | | 358 | | PEM | | 359 | | "pledge.example.com" | | 360 | |<---------------------| | 361 | | | | 362 STEP 4: Pledge retries enroll 363 | | | | 364 | POST /simpleenroll | | | 365 | PCSK#10 CSR | | | 366 | "pledge.example.com" | | | 367 |--------------------->| | | 368 | | | | 369 | 200 OK | | | 370 | PKCS#7 | | | 371 | "pledge.example.com" | | | 372 |<---------------------| | | 374 5. ACME Integration with BRSKI Default Cloud Registrar 376 BRSKI Cloud Registrar [I-D.friel-anima-brski-cloud] specifies the 377 behaviour of a BRSKI Cloud Registrar, and how a pledge can interact 378 with a BRSKI Cloud Registrar when bootstrapping. Similar to the 379 local domain registrar BRSKI flow, ACME can be easily integrated with 380 a cloud registrar bootstrap flow. 382 BRSKI cloud registrar is flexible and allows for multiple different 383 local domain discovery and redirect scenarios. In the example 384 illustrated here, the extension to [RFC8366] Vouchers which is 385 defined in [I-D.friel-anima-brski-cloud], and allows the 386 specification of a bootstrap EST domain, is leveraged. This 387 extension allows the cloud registrar to specify the local domain RA 388 that the pledge should connect to for the purposes of EST enrollment. 390 Similar to the sectiosn above, the client calls EST /csrattrs API 391 before calling the EST /simpleenroll API. 393 +--------+ +--------+ +------+ +----------+ 394 | Pledge | | EST RA | | ACME | | Cloud RA | 395 +--------+ +--------+ +------+ | / MASA | 396 | +----------+ 397 | | 398 NOTE: Pre-Authorization of "example.com" is complete 399 | | 400 STEP 1: Pledge requests Voucher from Cloud Registrar 401 | | 402 | POST /requestvoucher | 403 |-------------------------------------------------------->| 404 | | 405 | 200 OK Voucher (includes 'est-domain') | 406 |<--------------------------------------------------------| 407 | | | | 408 STEP 2: Pledge enrolls against local domain RA 409 | | | | 410 | GET /csrattrs | | | 411 |--------------------->| | | 412 | | | | 413 | 200 OK | | | 414 | SEQUENCE {AttrOrOID} | | | 415 | SAN OID: | | | 416 | "pledge.example.com" | | | 417 |<---------------------| | | 418 | | | | 419 | POST /simpleenroll | | | 420 | PCSK#10 CSR | | | 421 | "pledge.example.com" | | | 422 |--------------------->| | | 423 | | | | 424 | 202 Retry-After | | | 425 |<---------------------| | | 426 | | | | 427 STEP 3: RA places ACME order 428 | | | | 429 | | POST /newOrder | | 430 | | "pledge.example.com" | | 431 | |--------------------->| | 432 | | | | 433 | | 201 status=ready | | 434 | |<---------------------| | 435 | | | | 436 | | POST /finalize | | 437 | | PKCS#10 CSR | | 438 | | "pledge.example.com" | | 439 | |--------------------->| | 440 | | | | 441 | | 200 OK status=valid | | 442 | |<---------------------| | 443 | | | | 444 | | POST /certificate | | 445 | |--------------------->| | 446 | | | | 447 | | 200 OK | | 448 | | PEM | | 449 | | "pledge.example.com" | | 450 | |<---------------------| | 451 | | | | 452 STEP 4: Pledge retries enroll 453 | | | | 454 | POST /simpleenroll | | | 455 | PCSK#10 CSR | | | 456 | "pledge.example.com" | | | 457 |--------------------->| | | 458 | | | | 459 | 200 OK | | | 460 | PKCS#7 | | | 461 | "pledge.example.com" | | | 462 |<---------------------| | | 464 6. ACME Integration with TEAP 466 TEAP [RFC7170] defines a tunnel-based EAP method that enables secure 467 communication between a peer and a server by using TLS to establish a 468 mutually authenticated tunnel. TEAP enables certificate provisioning 469 within the tunnel. TEAP Update and Extensions for Bootstrapping 470 [I-D.lear-eap-teap-brski] defines extensions to TEAP that includes 471 additional TLVs for certificate enrollment and BRSKI handling inside 472 the TEAP tunnel. Neither TEAP [RFC7170] or TEAP Update and 473 Extensions for Bootstrapping [I-D.lear-eap-teap-brski] define how the 474 TEAP server communicates with the CA. 476 This section outlines how ACME could be used for communication 477 between the TEAP server and the CA. The example call flow leverages 478 [I-D.friel-acme-subdomains] and shows the TEAP server proving 479 ownership of a parent domain, with individual client certificates 480 being subdomains under that parent domain. 482 The example illustrates the TEAP server sending a Request-Action TLV 483 including a CSR-Attributes TLV instructing the peer to send a CSR- 484 Attributes TLV to the server. This enables the server to indicate 485 what fields the peer should include in the CSR that the peer sends in 486 the PKCS#10 TLV. For example, the TEAP server could instruct the 487 peer what Subject or SAN entries to include in its CSR. 489 Althought not explicitly illustrated in this call flow, the Peer and 490 TEAP Server could exchange BRSKI TLVs, and a BRSKI integration and 491 voucher exchange with a MASA server could take place over TEAP. 492 Whether a BRSKI TLV exchange takes place or not does not impact the 493 ACME specific message exchanges. 495 +------+ +-------------+ +------+ +-----+ 496 | Peer | | TEAP-Server | | ACME | | DNS | 497 +------+ +-------------+ +------+ +-----+ 498 | | | | 499 STEP 1: Pre-Authorization of parent domain 500 | | | | 501 | | POST /newAuthz | | 502 | | "example.com" | | 503 | |--------------------->| | 504 | | | | 505 | | 201 authorizations | | 506 | |<---------------------| | 507 | | | | 508 | | Publish DNS TXT | | 509 | | "example.com" | | 510 | |--------------------------------->| 511 | | | | 512 | | POST /challenge | | 513 | |--------------------->| | 514 | | | Verify | 515 | | |---------->| 516 | | 200 status=valid | | 517 | |<---------------------| | 518 | | | | 519 | | Delete DNS TXT | | 520 | | "example.com" | | 521 | |--------------------------------->| 522 | | | | 523 | | | | 524 STEP 2: Establsh EAP Outer Tunnel 525 | | | | 526 | EAP-Request/ | | | 527 | Type=Identity | | | 528 |<------------------------| | | 529 | | | | 530 | EAP-Response/ | | | 531 | Type=Identity | | | 532 |------------------------>| | | 533 | | | | 534 | EAP-Request/ | | | 535 | Type=TEAP, | | | 536 | TEAP Start, | | | 537 | Authority-ID TLV | | | 538 |<------------------------| | | 539 | | | | 540 | EAP-Response/ | | | 541 | Type=TEAP, | | | 542 | TLS(ClientHello) | | | 543 |------------------------>| | | 544 | | | | 545 | EAP-Request/ | | | 546 | Type=TEAP, | | | 547 | TLS(ServerHello, | | | 548 | Certificate, | | | 549 | ServerKeyExchange, | | | 550 | CertificateRequest, | | | 551 | ServerHelloDone) | | | 552 |<------------------------| | | 553 | | | | 554 | EAP-Response/ | | | 555 | Type=TEAP, | | | 556 | TLS(Certificate, | | | 557 | ClientKeyExchange, | | | 558 | CertificateVerify, | | | 559 | ChangeCipherSpec, | | | 560 | Finished) | | | 561 |------------------------>| | | 562 | | | | 563 | EAP-Request/ | | | 564 | Type=TEAP, | | | 565 | TLS(ChangeCipherSpec, | | | 566 | Finished), | | | 567 | {Crypto-Binding TLV, | | | 568 | Result TLV=Success} | | | 569 |<------------------------| | | 570 | | | | 571 | EAP-Response/ | | | 572 | Type=TEAP, | | | 573 | {Crypto-Binding TLV, | | | 574 | Result TLV=Success} | | | 575 |------------------------>| | | 576 | | | | 577 | EAP-Request/ | | | 578 | Type=TEAP, | | | 579 | {Request-Action TLV: | | | 580 | Status=Failure, | | | 581 | Action=Process-TLV, | | | 582 | TLV=CSR-Attributes, | | | 583 | TLV=PKCS#10} | | | 584 |<------------------------| | | 585 | | | | 586 STEP 3: Enroll for certificate 587 | | | | 588 | EAP-Response/ | | | 589 | Type=TEAP, | | | 590 | {CSR-Attributes TLV} | | | 591 |------------------------>| | | 592 | | | | 593 | EAP-Request/ | | | 594 | Type=TEAP, | | | 595 | {CSR-Attributes TLV} | | | 596 |<------------------------| | | 597 | | | | 598 | EAP-Response/ | | | 599 | Type=TEAP, | | | 600 | {PKCS#10 TLV: | | | 601 | "pledge.example.com"} | | | 602 |------------------------>| | | 603 | | POST /newOrder | | 604 | | "pledge.example.com" | | 605 | |--------------------->| | 606 | | | | 607 | | 201 status=ready | | 608 | |<---------------------| | 609 | | | | 610 | | POST /finalize | | 611 | | PKCS#10 CSR | | 612 | | "pledge.example.com" | | 613 | |--------------------->| | 614 | | | | 615 | | 200 OK status=valid | | 616 | |<---------------------| | 617 | | | | 618 | | POST /certificate | | 619 | |--------------------->| | 620 | | | | 621 | | 200 OK | | 622 | | PEM | | 623 | | "pledge.example.com" | | 624 | |<---------------------| | 625 | | | | 626 | EAP-Request/ | | | 627 | Type=TEAP, | | | 628 | {PKCS#7 TLV, | | | 629 | Result TLV=Success} | | | 630 |<------------------------| | | 631 | | | | 632 | EAP-Response/ | | | 633 | Type=TEAP, | | | 634 | {Result TLV=Success} | | | 635 |------------------------>| | | 636 | | | | 637 | EAP-Success | | | 638 |<------------------------| | | 640 7. IANA Considerations 642 This document does not make any requests to IANA. 644 8. Security Considerations 646 This draft is informational and makes no changes to the referenced 647 specifications. All security considerations from these referenced 648 documents are applicable here: 650 o EST [RFC7030] 652 o BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] 654 o BRSKI Default Cloud Registrar [I-D.friel-anima-brski-cloud] 656 o TEAP [RFC7170] and TEAP Update and Extensions for Bootstrapping 657 [I-D.lear-eap-teap-brski] 659 Additionally, all Security Considerations in ACME in the following 660 areas are equally applicable to ACME Integrations. 662 The integration mechanisms proposed here will primarily use the 663 DNS-01 challenge documented in [RFC8555] section 8.4. The security 664 considerations in RFC8555 says: 666 The DNS is a common point of vulnerability for all of these 667 challenges. An entity that can provision false DNS records for a 668 domain can attack the DNS challenge directly and can provision false 669 A/AAAA records to direct the ACME server to send its HTTP validation 670 query to a remote server of the attacker's choosing. 672 It is expected that the TEAP-EAP server/EST Registrar will perform 673 DNS dynamic updates to a DNS primary server using [RFC3007] Dynamic 674 updates, secured with with either SIG(0), or TSIG keys. 676 A major source of vulnerability is the disclosure of these DNS key 677 records. An attacker that has access to them, can provision their 678 own certificates into the the name space of the entity. 680 For many uses, this may allow the attacker to get access to some 681 enterprise resource. When used to provision, for instance, a (SIP) 682 phone system this would permit an attacker to impersonate a 683 legitimate phone. Not only does this allow for redirection of phone 684 calls, but possibly also toll fraud. 686 Operators should consider restricting the integration server such 687 that it can only update the DNS records for a specific zone or zones 688 where ACME is required for client certificate enrolment automation. 689 For example, if all IoT devices in an organisation enrol using EST 690 against an EST RA, and all IoT devices will be issued certificates in 691 a subdomain under iot.example.com, then the integration server could 692 be issued a credential that only allows updating of DNS records in a 693 zone that includes domains in the iot.example.com namespace, but does 694 not allow updating of DNS records under any other example.com DNS 695 namespace. 697 When performing challenge fulfilment via writing files to HTTP 698 webservers, write access should only be granted to a specific set of 699 servers, and only to a specific set of directories for storage of 700 challenge files. 702 8.1. Denial of Service against ACME infrastructure 704 The intermdiate node (the TEAP-EAP server, or the EST Registrar) 705 should cache the resulting certificates such that if the 706 communication with the pledge is lost, subsequent attempts to enroll 707 will result in the cache certificate being returned. 709 As many ACME servers have per-day, per-IP and per-subjectAltName 710 limits, it is prudent not to request identical certificates too 711 often. This could be due to operator or installer error, with 712 multiple configuration resets occuring within a short period of time. 714 The cache should be keyed by the complete contents of the Certificate 715 Signing Request, and should not persist beyond the notAfter date in 716 the certificate. 718 This means that if the private/public keypair changes on the pledge, 719 then a new certificate will be issued. If the the requested 720 SubjectAltName changes, then a new certificate will be requested. 722 In a case where a device is simply factory reset, and enrolls again, 723 then the same certificate can be returned. 725 9. Informative References 727 [I-D.friel-acme-subdomains] 728 Friel, O., Barnes, R., Hollebeek, T., and M. Richardson, 729 "ACME for Subdomains", draft-friel-acme-subdomains-03 730 (work in progress), October 2020. 732 [I-D.friel-anima-brski-cloud] 733 Friel, O., Shekh-Yusef, R., and M. Richardson, "BRSKI 734 Cloud Registrar", draft-friel-anima-brski-cloud-03 (work 735 in progress), September 2020. 737 [I-D.ietf-anima-bootstrapping-keyinfra] 738 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 739 and K. Watsen, "Bootstrapping Remote Secure Key 740 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 741 keyinfra-45 (work in progress), November 2020. 743 [I-D.lear-eap-teap-brski] 744 Lear, E., Friel, O., Cam-Winget, N., and D. Harkins, "TEAP 745 Update and Extensions for Bootstrapping", draft-lear-eap- 746 teap-brski-05 (work in progress), November 2019. 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, 750 DOI 10.17487/RFC2119, March 1997, 751 . 753 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 754 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 755 . 757 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 758 "Enrollment over Secure Transport", RFC 7030, 759 DOI 10.17487/RFC7030, October 2013, 760 . 762 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 763 "Tunnel Extensible Authentication Protocol (TEAP) Version 764 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 765 . 767 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 768 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 769 May 2017, . 771 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 772 "A Voucher Artifact for Bootstrapping Protocols", 773 RFC 8366, DOI 10.17487/RFC8366, May 2018, 774 . 776 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 777 Kasten, "Automatic Certificate Management Environment 778 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 779 . 781 Authors' Addresses 783 Owen Friel 784 Cisco 786 Email: ofriel@cisco.com 788 Richard Barnes 789 Cisco 791 Email: rlb@ipv.sx 793 Rifaat Shekh-Yusef 794 Auth0 796 Email: rifaat.s.ietf@gmail.com 798 Michael Richardson 799 Sandelman Software Works 801 Email: mcr+ietf@sandelman.ca