idnits 2.17.1 draft-ietf-acme-integrations-06.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 (December 17, 2021) is 860 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'CAB' is defined on line 878, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-acme-subdomains-00 == Outdated reference: A later version (-08) exists of draft-ietf-anima-brski-cloud-02 == Outdated reference: A later version (-04) exists of draft-richardson-lamps-rfc7030-csrattrs-01 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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: June 20, 2022 R. Shekh-Yusef 6 Auth0 7 M. Richardson 8 Sandelman Software Works 9 December 17, 2021 11 ACME Integrations 12 draft-ietf-acme-integrations-06 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 June 20, 2022. 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 . . . . . . . . . . . . . . . 15 62 7.1. Service Operators . . . . . . . . . . . . . . . . . . . . 15 63 7.2. CSR Attributes . . . . . . . . . . . . . . . . . . . . . 15 64 7.3. Certificate Chains and Trust Anchors . . . . . . . . . . 15 65 7.3.1. EST /cacerts . . . . . . . . . . . . . . . . . . . . 16 66 7.3.2. TEAP PKCS#7 TLV . . . . . . . . . . . . . . . . . . . 16 67 7.4. id-kp-cmcRA . . . . . . . . . . . . . . . . . . . . . . . 16 68 7.5. Error Handling . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . 21 75 1. Introduction 77 ACME [RFC8555] defines a protocol that a certification 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.ietf-acme-subdomains] outlines how ACME can 99 be used by a client to obtain a certificate for a subdomain 100 identifier from an ACME server where the client has fulfilled a 101 challenge against a parent domain, but does not need to fulfil a 102 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 DNS Terminology [RFC8499] and are 117 reproduced here: 119 o Label: An ordered list of zero or more octets that makes up a 120 portion of a domain name. Using graph theory, a label identifies 121 one node in a portion of the graph of all possible domain names. 123 o Domain Name: An ordered list of one or more labels. 125 o Subdomain: "A domain is a subdomain of another domain if it is 126 contained within that domain. This relationship can be tested by 127 seeing if the subdomain's name ends with the containing domain's 128 name." (Quoted from [RFC1034], Section 3.1) For example, in the 129 host name "nnn.mmm.example.com", both "mmm.example.com" and 130 "nnn.mmm.example.com" are subdomains of "example.com". Note that 131 the comparisons here are done on whole labels; that is, 132 "ooo.example.com" is not a subdomain of "oo.example.com". 134 o Fully-Qualified Domain Name (FQDN): This is often just a clear way 135 of saying the same thing as "domain name of a node", as outlined 136 above. However, the term is ambiguous. Strictly speaking, a 137 fully-qualified domain name would include every label, including 138 the zero-length label of the root: such a name would be written 139 "www.example.net." (note the terminating dot). But, because every 140 name eventually shares the common root, names are often written 141 relative to the root (such as "www.example.net") and are still 142 called "fully qualified". This term first appeared in [RFC0819]. 143 In this document, names are often written relative to the root. 145 The following terms are used in this document: 147 o BRSKI: Bootstrapping Remote Secure Key Infrastructures [RFC8995] 149 o Certification Authority (CA): An organization that is responsible 150 for the creation, issuance, revocation, and management of 151 Certificates. The term applies equally to both Roots CAs and 152 Subordinate CAs 154 o CMS: Cryptographic Message Syntax [RFC5652] 156 o CMC: Certificate Management over CMS [RFC5272] 158 o CSR: Certificate Signing Request 160 o EST: Enrollment over Secure Transport [RFC7030] 162 o MASA: Manufacturer Authorized Signing Authority as defined in 163 [RFC8995] 165 o RA: PKI Registration Authority 167 o TEAP: Tunneled Extensible Authentication Protocol [RFC7170] 169 o TLV: Type-Length-Value format defined in TEAP 171 3. ACME Integration with EST 173 EST [RFC7030] defines a mechanism for clients to enroll with a PKI 174 Registration Authority by sending CMC messages over HTTP. EST 175 section 1 states: 177 "Architecturally, the EST service is located between a Certification 178 Authority (CA) and a client. It performs several functions 179 traditionally allocated to the Registration Authority (RA) role in a 180 PKI." 182 EST section 1.1 states that: 184 "For certificate issuing services, the EST CA is reached through the 185 EST server; the CA could be logically "behind" the EST server or 186 embedded within it." 188 When the CA is logically "behind" the EST RA, EST does not specify 189 how the RA communicates with the CA. EST section 1 states: 191 "The nature of communication between an EST server and a CA is not 192 described in this document." 193 This section outlines how ACME could be used for communication 194 between the EST RA and the CA. The example call flow leverages 195 [I-D.ietf-acme-subdomains] and shows the RA proving ownership of a 196 parent domain, with individual client certificates being subdomains 197 under that parent domain. This is an optimization that reduces DNS 198 and ACME traffic overhead. The RA could of course prove ownership of 199 every explicit client certificate identifier. The example also 200 illustrates using the ACME DNS challenge type, but this integration 201 is not limited to DNS challenges. 203 The call flow illustrates the client calling the EST /csrattrs API 204 before calling the EST /simpleenroll API. This enables the server to 205 indicate what fields the client should include in the CSR that the 206 client sends in the /simpleenroll API. CSR Attributes handling are 207 discussed in Section 7.2. 209 The call flow illustrates the EST RA returning a 202 Retry-After 210 response to the client's simpleenroll request. This is an optional 211 step and may be necessary if the interactions between the RA and the 212 ACME server take some time to complete. The exact details of when 213 the RA returns a 202 Retry-After are implementation specific. 215 +--------+ +--------+ +--------+ +-----+ 216 | Client | | EST RA | | ACME | | DNS | 217 +--------+ +--------+ | Server | +-----+ 218 | | +--------+ | 219 | | | | 220 STEP 1: Pre-Authorization of parent domain 221 | | | | 222 | | POST /newAuthz | | 223 | | "example.com" | | 224 | |--------------------->| | 225 | | | | 226 | | 201 authorizations | | 227 | |<---------------------| | 228 | | | | 229 | | Publish DNS TXT | | 230 | | "example.com" | | 231 | |--------------------------------->| 232 | | | | 233 | | POST /challenge | | 234 | |--------------------->| | 235 | | | Verify | 236 | | |---------->| 237 | | 200 status=valid | | 238 | |<---------------------| | 239 | | | | 240 | | Delete DNS TXT | | 241 | | "example.com" | | 242 | |--------------------------------->| 243 | | | | 244 STEP 2: Client enrolls against RA 245 | | | | 246 | GET /csrattrs | | | 247 |--------------------->| | | 248 | | | | 249 | 200 OK | | | 250 | SEQUENCE {AttrOrOID} | | | 251 | SAN OID: | | | 252 | "client.example.com" | | | 253 |<---------------------| | | 254 | | | | 255 | POST /simpleenroll | | | 256 | PCSK#10 CSR | | | 257 | "client.example.com" | | | 258 |--------------------->| | | 259 | | | | 260 | 202 Retry-After | | | 261 |<---------------------| | | 262 | | | | 263 STEP 3: RA places ACME order 264 | | | | 265 | | POST /newOrder | | 266 | | "client.example.com" | | 267 | |--------------------->| | 268 | | | | 269 | | 201 status=ready | | 270 | |<---------------------| | 271 | | | | 272 | | POST /finalize | | 273 | | PKCS#10 CSR | | 274 | | "client.example.com" | | 275 | |--------------------->| | 276 | | | | 277 | | 200 OK status=valid | | 278 | |<---------------------| | 279 | | | | 280 | | POST /certificate | | 281 | |--------------------->| | 282 | | | | 283 | | 200 OK | | 284 | | PKCS#7 | | 285 | | "client.example.com" | | 286 | |<---------------------| | 287 | | | | 288 STEP 4: Client retries enroll 290 | | | | 291 | POST /simpleenroll | | | 292 | PCSK#10 CSR | | | 293 | "client.example.com" | | | 294 |--------------------->| | | 295 | | | | 296 | 200 OK | | | 297 | PKCS#7 | | | 298 | "client.example.com" | | | 299 |<---------------------| | | 301 4. ACME Integration with BRSKI 303 BRSKI [RFC8995] is based upon EST [RFC7030] and defines how to 304 autonomically bootstrap PKI trust anchors into devices via means of 305 signed vouchers. EST certificate enrollment may then optionally take 306 place after trust has been established. BRKSI voucher exchange and 307 trust establishment are based on EST extensions and the certificate 308 enrollment part of BRSKI is fully based on EST. Similar to EST, 309 BRSKI does not define how the EST RA communicates with the CA. 310 Therefore, the mechanisms outlined in the previous section for using 311 ACME as the communications protocol between the EST RA and the CA are 312 equally applicable to BRSKI. 314 The following call flow shows how ACME may be integrated into a full 315 BRSKI voucher plus EST enrollment workflow. For brevity, it assumes 316 that the EST RA has previously proven ownership of a parent domain 317 and that pledge certificate identifiers are a subdomain of that 318 parent domain. The domain ownership exchanges between the RA, ACME 319 and DNS are not shown. Similarly, not all BRSKI interactions are 320 shown and only the key protocol flows involving voucher exchange and 321 EST enrollment are shown. 323 Similar to the EST section above, the client calls EST /csrattrs API 324 before calling the EST /simpleenroll API. This enables the server to 325 indicate what fields the pledge should include in the CSR that the 326 client sends in the /simpleenroll API. Refer to section {csr- 327 attributes} for more details. 329 The call flow illustrates the RA returning a 202 Retry-After response 330 to the initial EST /simpleenroll API. This may be appropriate if 331 processing of the /simpleenroll request and ACME interactions takes 332 some time to complete. 334 +--------+ +--------+ +--------+ +------+ 335 | Pledge | | EST RA | | ACME | | MASA | 336 +--------+ +--------+ | Server | +------+ 337 | | +--------+ | 338 | | | | 339 NOTE: Pre-Authorization of "example.com" is complete 340 | | | | 341 STEP 1: Pledge requests Voucher 342 | | | | 343 | POST /requestvoucher | | | 344 |--------------------->| | | 345 | | POST /requestvoucher | | 346 | |--------------------------------->| 347 | | | | 348 | | 200 OK Voucher | | 349 | |<---------------------------------| 350 | 200 OK Voucher | | | 351 |<---------------------| | | 352 | | | | 353 STEP 2: Pledge enrolls against RA 354 | | | | 355 | GET /csrattrs | | | 356 |--------------------->| | | 357 | | | | 358 | 200 OK | | | 359 | SAN: | | | 360 | "pledge.example.com" | | | 361 |<---------------------| | | 362 | | | | 363 | POST /simpleenroll | | | 364 | PCSK#10 CSR | | | 365 | "pledge.example.com" | | | 366 |--------------------->| | | 367 | | | | 368 | 202 Retry-After | | | 369 |<---------------------| | | 370 | | | | 371 STEP 3: RA places ACME order 372 | | | | 373 | | POST /newOrder | | 374 | | "pledge.example.com" | | 375 | |--------------------->| | 376 | | | | 377 | | 201 status=ready | | 378 | |<---------------------| | 379 | | | | 380 | | POST /finalize | | 381 | | PKCS#10 CSR | | 382 | | "pledge.example.com" | | 383 | |--------------------->| | 384 | | | | 385 | | 200 OK status=valid | | 386 | |<---------------------| | 387 | | | | 388 | | POST /certificate | | 389 | |--------------------->| | 390 | | | | 391 | | 200 OK | | 392 | | PKCS#7 | | 393 | | "pledge.example.com" | | 394 | |<---------------------| | 395 | | | | 396 STEP 4: Pledge retries enroll 397 | | | | 398 | POST /simpleenroll | | | 399 | PCSK#10 CSR | | | 400 | "pledge.example.com" | | | 401 |--------------------->| | | 402 | | | | 403 | 200 OK | | | 404 | PKCS#7 | | | 405 | "pledge.example.com" | | | 406 |<---------------------| | | 408 5. ACME Integration with BRSKI Default Cloud Registrar 410 BRSKI Cloud Registrar [I-D.ietf-anima-brski-cloud] specifies the 411 behaviour of a BRSKI Cloud Registrar, and how a pledge can interact 412 with a BRSKI Cloud Registrar when bootstrapping. Similar to the 413 local domain registrar BRSKI flow, ACME can be easily integrated with 414 a cloud registrar bootstrap flow. 416 BRSKI cloud registrar is flexible and allows for multiple different 417 local domain discovery and redirect scenarios. In the example 418 illustrated here, the extension to [RFC8366] Vouchers which is 419 defined in [I-D.ietf-anima-brski-cloud], and allows the specification 420 of a bootstrap EST domain, is leveraged. This extension allows the 421 cloud registrar to specify the local domain RA that the pledge should 422 connect to for the purposes of EST enrollment. 424 Similar to the sections above, the client calls EST /csrattrs API 425 before calling the EST /simpleenroll API. 427 +--------+ +--------+ +--------+ +----------+ 428 | Pledge | | EST RA | | ACME | | Cloud RA | 429 +--------+ +--------+ | Server | | / MASA | 430 | +--------+ +----------+ 431 | | 432 NOTE: Pre-Authorization of "example.com" is complete 433 | | 434 STEP 1: Pledge requests Voucher from Cloud Registrar 435 | | 436 | POST /requestvoucher | 437 |-------------------------------------------------------->| 438 | | 439 | 200 OK Voucher (includes 'est-domain') | 440 |<--------------------------------------------------------| 441 | | | | 442 STEP 2: Pledge enrolls against local domain RA 443 | | | | 444 | GET /csrattrs | | | 445 |--------------------->| | | 446 | | | | 447 | 200 OK | | | 448 | SAN: | | | 449 | "pledge.example.com" | | | 450 |<---------------------| | | 451 | | | | 452 | POST /simpleenroll | | | 453 | PCSK#10 CSR | | | 454 | "pledge.example.com" | | | 455 |--------------------->| | | 456 | | | | 457 | 202 Retry-After | | | 458 |<---------------------| | | 459 | | | | 460 STEP 3: RA places ACME order 461 | | | | 462 | | POST /newOrder | | 463 | | "pledge.example.com" | | 464 | |--------------------->| | 465 | | | | 466 | | 201 status=ready | | 467 | |<---------------------| | 468 | | | | 469 | | POST /finalize | | 470 | | PKCS#10 CSR | | 471 | | "pledge.example.com" | | 472 | |--------------------->| | 473 | | | | 474 | | 200 OK status=valid | | 475 | |<---------------------| | 476 | | | | 477 | | POST /certificate | | 478 | |--------------------->| | 479 | | | | 480 | | 200 OK | | 481 | | PKCS#7 | | 482 | | "pledge.example.com" | | 483 | |<---------------------| | 484 | | | | 485 STEP 4: Pledge retries enroll 486 | | | | 487 | POST /simpleenroll | | | 488 | PCSK#10 CSR | | | 489 | "pledge.example.com" | | | 490 |--------------------->| | | 491 | | | | 492 | 200 OK | | | 493 | PKCS#7 | | | 494 | "pledge.example.com" | | | 495 |<---------------------| | | 497 6. ACME Integration with TEAP 499 TEAP [RFC7170] defines a tunnel-based EAP method that enables secure 500 communication between a peer and a server by using TLS to establish a 501 mutually authenticated tunnel. TEAP enables certificate provisioning 502 within the tunnel. TEAP Update and Extensions for Bootstrapping 503 [I-D.lear-eap-teap-brski] defines extensions to TEAP that includes 504 additional Type-Length-Value (TLV) elements for certificate 505 enrollment and BRSKI handling inside the TEAP tunnel. Neither TEAP 506 [RFC7170] or TEAP Update and Extensions for Bootstrapping 507 [I-D.lear-eap-teap-brski] define how the TEAP server communicates 508 with the CA. 510 This section outlines how ACME could be used for communication 511 between the TEAP server and the CA. The example call flow leverages 512 [I-D.ietf-acme-subdomains] and shows the TEAP server proving 513 ownership of a parent domain, with individual client certificates 514 being subdomains under that parent domain. 516 The example illustrates the TEAP server sending a Request-Action TLV 517 including a CSR-Attributes TLV instructing the peer to send a CSR- 518 Attributes TLV to the server. This enables the server to indicate 519 what fields the peer should include in the CSR that the peer sends in 520 the PKCS#10 TLV. 522 Although not explicitly illustrated in this call flow, the Peer and 523 TEAP Server could exchange BRSKI TLVs, and a BRSKI integration and 524 voucher exchange with a MASA server could take place over TEAP. 525 Whether a BRSKI TLV exchange takes place or not does not impact the 526 ACME specific message exchanges. 528 +------+ +-------------+ +--------+ +-----+ 529 | Peer | | TEAP-Server | | ACME | | DNS | 530 +------+ +-------------+ | Server | +-----+ 531 | | +--------| | 532 | | | | 533 STEP 1: Pre-Authorization of parent domain 534 | | | | 535 | | POST /newAuthz | | 536 | | "example.com" | | 537 | |--------------------->| | 538 | | | | 539 | | 201 authorizations | | 540 | |<---------------------| | 541 | | | | 542 | | Publish DNS TXT | | 543 | | "example.com" | | 544 | |--------------------------------->| 545 | | | | 546 | | POST /challenge | | 547 | |--------------------->| | 548 | | | Verify | 549 | | |---------->| 550 | | 200 status=valid | | 551 | |<---------------------| | 552 | | | | 553 | | Delete DNS TXT | | 554 | | "example.com" | | 555 | |--------------------------------->| 556 | | | | 557 | | | | 558 STEP 2: Establsh EAP Outer Tunnel 559 | | | | 560 | EAP-Request/ | | | 561 | Type=Identity | | | 562 |<------------------------| | | 563 | | | | 564 | EAP-Response/ | | | 565 | Type=Identity | | | 566 |------------------------>| | | 567 | | | | 568 | EAP-Request/ | | | 569 | Type=TEAP, | | | 570 | TEAP Start, | | | 571 | Authority-ID TLV | | | 572 |<------------------------| | | 573 | | | | 574 | EAP-Response/ | | | 575 | Type=TEAP, | | | 576 | TLS(ClientHello) | | | 577 |------------------------>| | | 578 | | | | 579 | EAP-Request/ | | | 580 | Type=TEAP, | | | 581 | TLS(ServerHello, | | | 582 | Certificate, | | | 583 | ServerKeyExchange, | | | 584 | CertificateRequest, | | | 585 | ServerHelloDone) | | | 586 |<------------------------| | | 587 | | | | 588 | EAP-Response/ | | | 589 | Type=TEAP, | | | 590 | TLS(Certificate, | | | 591 | ClientKeyExchange, | | | 592 | CertificateVerify, | | | 593 | ChangeCipherSpec, | | | 594 | Finished) | | | 595 |------------------------>| | | 596 | | | | 597 | EAP-Request/ | | | 598 | Type=TEAP, | | | 599 | TLS(ChangeCipherSpec, | | | 600 | Finished), | | | 601 | {Crypto-Binding TLV, | | | 602 | Result TLV=Success} | | | 603 |<------------------------| | | 604 | | | | 605 | EAP-Response/ | | | 606 | Type=TEAP, | | | 607 | {Crypto-Binding TLV, | | | 608 | Result TLV=Success} | | | 609 |------------------------>| | | 610 | | | | 611 | EAP-Request/ | | | 612 | Type=TEAP, | | | 613 | {Request-Action TLV: | | | 614 | Status=Failure, | | | 615 | Action=Process-TLV, | | | 616 | TLV=CSR-Attributes, | | | 617 | TLV=PKCS#10} | | | 618 |<------------------------| | | 619 | | | | 620 STEP 3: Enroll for certificate 621 | | | | 622 | EAP-Response/ | | | 623 | Type=TEAP, | | | 624 | {CSR-Attributes TLV} | | | 625 |------------------------>| | | 626 | | | | 627 | EAP-Request/ | | | 628 | Type=TEAP, | | | 629 | {CSR-Attributes TLV} | | | 630 |<------------------------| | | 631 | | | | 632 | EAP-Response/ | | | 633 | Type=TEAP, | | | 634 | {PKCS#10 TLV: | | | 635 | "client.example.com"} | | | 636 |------------------------>| | | 637 | | POST /newOrder | | 638 | | "client.example.com" | | 639 | |--------------------->| | 640 | | | | 641 | | 201 status=ready | | 642 | |<---------------------| | 643 | | | | 644 | | POST /finalize | | 645 | | PKCS#10 CSR | | 646 | | "client.example.com" | | 647 | |--------------------->| | 648 | | | | 649 | | 200 OK status=valid | | 650 | |<---------------------| | 651 | | | | 652 | | POST /certificate | | 653 | |--------------------->| | 654 | | | | 655 | | 200 OK | | 656 | | PKCS#7 | | 657 | | "client.example.com" | | 658 | |<---------------------| | 659 | | | | 660 | EAP-Request/ | | | 661 | Type=TEAP, | | | 662 | {PKCS#7 TLV, | | | 663 | Result TLV=Success} | | | 664 |<------------------------| | | 665 | | | | 666 | EAP-Response/ | | | 667 | Type=TEAP, | | | 668 | {Result TLV=Success} | | | 669 |------------------------>| | | 670 | | | | 671 | EAP-Success | | | 672 |<------------------------| | | 674 7. ACME Integration Considerations 676 7.1. Service Operators 678 The goal of these integrations is enabling issuance of certificates 679 with identifiers in a given domain by an ACME server to a client. It 680 is expected that the EST RA or TEAP servers that the client sends 681 certificate enrollment requests to are operated by the organization 682 that controls the domains. The ACME server is not necessarily 683 operated by the organization that controls the domain. 685 7.2. CSR Attributes 687 In all integrations, the client MUST send a CSR Attributes request to 688 the EST or TEAP server prior to sending a certificate enrollment 689 request. This enables the server to indicate to the client what 690 attributes, and what attribute values, it expects the client to 691 include in the subsequent CSR request. For example, the server could 692 instruct the peer what Subject Alternative Name entries to include in 693 its CSR. 695 EST [RFC7030] is not clear on how the CSR Attributes response should 696 be structured, and in particular is not clear on how a server can 697 instruct a client to include specific attribute values in its CSR. 698 [I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can 699 use CSR Attributes response to specify specific values for attributes 700 that the client should include in its CSR. 702 Servers MUST use this mechanism to tell the client what identifiers 703 to include in CSR request. ACME [RFC8555] allows the identifier to 704 be included in either CSR Subject or Subject Alternative Name fields, 705 however [I-D.ietf-uta-use-san] states that Subject Alternative Name 706 field MUST be used. This document aligns with [I-D.ietf-uta-use-san] 707 and Subject Alternate Name field MUST be used. The identifier must 708 be a subdomain of a domain that the server has control over and can 709 fulfill ACME challenges against. The leftmost part of the identifier 710 MAY be a field that the client presented to the server in an IEEE 711 802.1AR [IDevID]. 713 Servers MAY use this field to instruct the client to include other 714 attributes such as specific policy OIDs. Refer to EST [RFC7030] 715 section 2.6 for further details. 717 7.3. Certificate Chains and Trust Anchors 719 ACME [RFC8555] section 9.1 states that ACME servers may return a 720 certificate chain to an ACME client where an end entity certificate 721 is followed by certificates that certify it. The trust anchor 722 certificate MAY be omitted from the chain as it is assumed that the 723 trust anchor is already known by the ACME client i.e. the EST or TEAP 724 server. 726 7.3.1. EST /cacerts 728 EST [RFC7030] section 4.2.3 states that the /simpleenroll response 729 contains "only the certificate that was issued". EST [RFC7030] 730 section 4.1.3 states that the /cacerts response "MUST include any 731 additional certificates the client would need to build a chain from 732 an EST CA-issued certificate to the current EST CA TA". 734 Therefore, the EST server MUST return only the ACME end entity 735 certificate in the /simpleenroll response. The EST server MUST 736 return the remainder of the chain returned by the ACME server to the 737 EST server in the /cacerts response to the client, appending the 738 trust anchor root CA if necessary. 740 7.3.2. TEAP PKCS#7 TLV 742 TEAP [RFC7170] section 4.2.16 allows for download of a PKCS#7 743 certificate chain in response to a TEAP PKCS#10 TLV request. TEAP 744 also allows for download of multiple PKCS#7 certificates in response 745 to a TEAP Trusted-Server-Root TLV request. 747 The TEAP server MUST return the full ACME client certificate chain in 748 the PKCS#7 response to the PKCS#10 TLV request. The TEAP server MUST 749 return the ACME server trust anchor in a PKCS#7 response to a 750 Trusted-Server-Root TLV request. As outlined in Section 7.4, the 751 TEAP server SHOULD also return the trust anchor that was used for 752 issuing its own identity certificate, if different from the ACME 753 server trust anchor. 755 7.4. id-kp-cmcRA 757 BRSKI [RFC8995] mandates that the id-kp-cmcRA extended key usage bit 758 is set in the Registrar (or EST RA) end entity certificate that the 759 Registrar uses when signing voucher request messages sent to the 760 MASA. Public ACME servers may not be willing to issue end entity 761 certificates that have the id-kp-cmcRA extended key usage bit set. 762 In these scenarios, the EST RA may be used by the pledge to get 763 issued certificates by a public ACME server, but the EST RA itself 764 will need an end entity certificate that has been issued by a 765 different CA (e.g. an operator deployed private CA) and that has the 766 id-kp-cmcRA bit set. 768 7.5. Error Handling 770 ACME [RFC8555] section 6.7 defines multiple errors that may be 771 returned by an ACME server to an ACME client. TEAP [RFC7170] section 772 4.2.6 defines multiple errors that may be returned by a TEAP server 773 to a client in an Error TLV. EST [RFC7030] section 4.2.3 defines how 774 an EST server may return an error encoded in a CMC response, or may 775 return a human readable error in the response body. 777 The following mapping from ACME errors to CMC [RFC5272] section 6.1.4 778 CMCFailInfo and TEAP [RFC7170] section 4.2.6 error codes is 779 RECOMMENDED. 781 +--------------------+-----------------+--------------------------+ 782 | ACME | CMCFailInfo | TEAP Error Code | 783 +--------------------+-----------------+--------------------------+ 784 | badCSR | badRequest | 1025 Bad CSR | 785 | caa | badRequest | 1025 Bad CSR | 786 | rejectedIdentifier | badIdentity | 1024 Bad Identity In CSR | 787 | all other errors | internalCAError | 1026 Internal CA Error | 788 +--------------------+-----------------+--------------------------+ 790 8. IANA Considerations 792 This document does not make any requests to IANA. 794 9. Security Considerations 796 This draft is informational and makes no changes to the referenced 797 specifications. All security considerations from these referenced 798 documents are applicable here: 800 o EST [RFC7030] 802 o BRSKI [RFC8995] 804 o BRSKI Default Cloud Registrar [I-D.ietf-anima-brski-cloud] 806 o TEAP [RFC7170] and TEAP Update and Extensions for Bootstrapping 807 [I-D.lear-eap-teap-brski] 809 Additionally, all Security Considerations in ACME in the following 810 areas are equally applicable to ACME Integrations. 812 It is expected that the integration mechanisms proposed here will 813 primarily use the DNS-01 challenge documented in [RFC8555] section 814 8.4. The security considerations in RFC8555 says: 816 The DNS is a common point of vulnerability for all of these 817 challenges. An entity that can provision false DNS records for a 818 domain can attack the DNS challenge directly and can provision false 819 A/AAAA records to direct the ACME server to send its HTTP validation 820 query to a remote server of the attacker's choosing. 822 It is expected that the TEAP-EAP server/EST Registrar will perform 823 DNS dynamic updates to a DNS primary server using [RFC3007] Dynamic 824 updates, secured with either SIG(0), or TSIG keys. 826 A major source of vulnerability is the disclosure of these DNS key 827 records. An attacker that has access to them, can provision their 828 own certificates into the the name space of the entity. 830 For many uses, this may allow the attacker to get access to some 831 enterprise resource. When used to provision, for instance, a (SIP) 832 phone system this would permit an attacker to impersonate a 833 legitimate phone. Not only does this allow for redirection of phone 834 calls, but possibly also toll fraud. 836 Operators should consider restricting the integration server such 837 that it can only update the DNS records for a specific zone or zones 838 where ACME is required for client certificate enrollment automation. 839 For example, if all IoT devices in an organisation enroll using EST 840 against an EST RA, and all IoT devices will be issued certificates in 841 a subdomain under iot.example.com, then the integration server could 842 be issued a credential that only allows updating of DNS records in a 843 zone that includes domains in the iot.example.com namespace, but does 844 not allow updating of DNS records under any other example.com DNS 845 namespace. 847 When performing challenge fulfilment via writing files to HTTP 848 webservers, write access should only be granted to a specific set of 849 servers, and only to a specific set of directories for storage of 850 challenge files. 852 9.1. Denial of Service against ACME infrastructure 854 The intermediate node (the TEAP-EAP server, or the EST Registrar) 855 should cache the resulting certificates such that if the 856 communication with the pledge is lost, subsequent attempts to enroll 857 will result in the cache certificate being returned. 859 As many ACME servers have per-day, per-IP and per-subjectAltName 860 limits, it is prudent not to request identical certificates too 861 often. This could be due to operator or installer error, with 862 multiple configuration resets occurring within a short period of 863 time. 865 The cache should be indexed by the complete contents of the 866 Certificate Signing Request, and should not persist beyond the 867 notAfter date in the certificate. 869 This means that if the private/public keypair changes on the pledge, 870 then a new certificate will be issued. If the requested 871 SubjectAltName changes, then a new certificate will be requested. 873 In a case where a device is simply factory reset, and enrolls again, 874 then the same certificate can be returned. 876 10. Informative References 878 [CAB] CA/Browser Forum, "Baseline Requirements for the Issuance 879 and Management of Publicly-Trusted Certificates", n.d., 880 . 883 [I-D.ietf-acme-subdomains] 884 Friel, O., Barnes, R., Hollebeek, T., and M. Richardson, 885 "ACME for Subdomains", draft-ietf-acme-subdomains-00 (work 886 in progress), October 2021. 888 [I-D.ietf-anima-brski-cloud] 889 Friel, O., Shekh-Yusef, R., and M. Richardson, "BRSKI 890 Cloud Registrar", draft-ietf-anima-brski-cloud-02 (work in 891 progress), October 2021. 893 [I-D.ietf-uta-use-san] 894 Salz, R., "Update to Verifying TLS Server Identities with 895 X.509 Certificates", draft-ietf-uta-use-san-00 (work in 896 progress), April 2021. 898 [I-D.lear-eap-teap-brski] 899 Lear, E., Friel, O., Cam-Winget, N., and D. Harkins, "TEAP 900 Update and Extensions for Bootstrapping", draft-lear-eap- 901 teap-brski-06 (work in progress), August 2021. 903 [I-D.richardson-lamps-rfc7030-csrattrs] 904 Richardson, M., Harkins, D., Oheimb, D. D. V., and O. 905 Friel, "Clarification of RFC7030 CSR Attributes 906 definition", draft-richardson-lamps-rfc7030-csrattrs-01 907 (work in progress), October 2021. 909 [IDevID] IEEE, "IEEE Standard for Local and metropolitan area 910 networks - Secure Device Identity", n.d., 911 . 913 [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for 914 Internet User Applications", RFC 819, 915 DOI 10.17487/RFC0819, August 1982, 916 . 918 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 919 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 920 . 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, 924 DOI 10.17487/RFC2119, March 1997, 925 . 927 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 928 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 929 . 931 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 932 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 933 . 935 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 936 RFC 5652, DOI 10.17487/RFC5652, September 2009, 937 . 939 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 940 "Enrollment over Secure Transport", RFC 7030, 941 DOI 10.17487/RFC7030, October 2013, 942 . 944 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 945 "Tunnel Extensible Authentication Protocol (TEAP) Version 946 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 947 . 949 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 950 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 951 May 2017, . 953 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 954 "A Voucher Artifact for Bootstrapping Protocols", 955 RFC 8366, DOI 10.17487/RFC8366, May 2018, 956 . 958 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 959 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 960 January 2019, . 962 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 963 Kasten, "Automatic Certificate Management Environment 964 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 965 . 967 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 968 and K. Watsen, "Bootstrapping Remote Secure Key 969 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 970 May 2021, . 972 Authors' Addresses 974 Owen Friel 975 Cisco 977 Email: ofriel@cisco.com 979 Richard Barnes 980 Cisco 982 Email: rlb@ipv.sx 984 Rifaat Shekh-Yusef 985 Auth0 987 Email: rifaat.s.ietf@gmail.com 989 Michael Richardson 990 Sandelman Software Works 992 Email: mcr+ietf@sandelman.ca