idnits 2.17.1 draft-friel-acme-integrations-01.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 (July 02, 2019) is 1760 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-22 == Outdated reference: A later version (-06) exists of draft-lear-eap-teap-brski-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Friel 3 Internet-Draft R. Barnes 4 Intended status: Standards Track Cisco 5 Expires: January 3, 2020 July 02, 2019 7 ACME Integrations 8 draft-friel-acme-integrations-01 10 Abstract 12 This document outlines multiple advanced use cases and integrations 13 that ACME facilitates without any modifications or enhancements 14 required to the base ACME specification. These use cases are not 15 immediately obvious from reading the ACME specification and thus are 16 explicitly documented here. The use cases include ACME issuance of 17 subdomain certificates, and ACME integration with EST and TEAP. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 3, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. ACME Issuance of Subdomain Certificates . . . . . . . . . . . 3 56 4. ACME Integration with EST . . . . . . . . . . . . . . . . . . 5 57 5. ACME Integration with BRSKI . . . . . . . . . . . . . . . . . 8 58 6. ACME Integration with TEAP . . . . . . . . . . . . . . . . . 10 59 7. ACME Integration with TEAP-BRSKI . . . . . . . . . . . . . . 13 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 62 10. Informative References . . . . . . . . . . . . . . . . . . . 16 63 Appendix A. Comments . . . . . . . . . . . . . . . . . . . . . . 16 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 66 1. Introduction 68 ACME [RFC8555] defines a protocol that a certificate authority (CA) 69 and an applicant can use to automate the process of domain name 70 ownership validation and X.509 (PKIX) certificate issuance. The 71 protocol is rich and flexible and enables multiple use cases that are 72 not immediately obvious from reading the specification. This 73 document explicitly outlines multiple advanced ACME use cases 74 including: 76 o ACME issuance of subdomain certificates 78 o ACME integration with EST [RFC7030] 80 o ACME integration with BRSKI 81 [I-D.ietf-anima-bootstrapping-keyinfra] 83 o ACME integration with TEAP [RFC7170] 85 o ACME integration with TEAP-BRSKI draft-lear-eap-teap-brski 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in BCP 92 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 The following terms are used in this document: 97 o BRSKI: Bootstrapping Remote Secure Key Infrastructures 98 [I-D.ietf-anima-bootstrapping-keyinfra] 100 o CA: Certificate Authority 102 o CMC: Certificate Management over CMS 104 o CSR: Certificate Signing Request 106 o EST: Enrollment over Secure Transport [RFC7030] 108 o FQDN: Fully Qualified Domain Name 110 o RA: PKI Registration Authority 112 o TEAP: Tunneled Extensible Authentication Protocol [RFC7170] 114 3. ACME Issuance of Subdomain Certificates 116 A typical ACME workflow for issuance of certificates is as follows: 118 1. client POSTs a newOrder request that contains a set of 119 "identifiers" 121 2. server replies with a set of "authorizations" and a "finalize" 122 URI 124 3. client sends POST-as-GET requests to retrieve the 125 "authorizations", with the downloaded "authorization" object(s) 126 containing the "identifier" that the client must prove control of 128 4. client proves control over the "identifier" in the 129 "authorization" object by completing the specified challenge, for 130 example, by publishing a DNS TXT record 132 5. client POSTs a CSR to the "finalize" API 134 ACME places the following restrictions on "identifiers": 136 o section 7.1.4: the only type of "identifier" defined by the ACME 137 specification is a fully qualified domain name: "The only type of 138 identifier defined by this specification is a fully qualified 139 domain name (type: "dns"). The domain name MUST be encoded in the 140 form in which it would appear in a certificate." 142 o Section 7.4: the "identifier" in the CSR request must match the 143 "identifier" in the newOrder request: "The CSR MUST indicate the 144 exact same set of requested identifiers as the initial newOrder 145 request." 147 o Sections 8.3: the "identifier", or FQDN, in the "authorization" 148 object must be used when fulfilling challenges via HTTP: 149 "Construct a URL by populating the URL template ... where the 150 domain field is set to the domain name being verified" 152 o Section 8.4: the "identifier", or FQDN, in the "authorization" 153 object must be used when fulfilling challenges via DNS: "The 154 client constructs the validation domain name by prepending the 155 label "_acme-challenge" to the domain name being validated." 157 ACME does not mandate that the "identifier" in a newOrder request 158 matches the "identifier" in "authorization" objects. This means that 159 the ACME specification does not preclude an ACME server processing 160 newOrder requests and issuing certificates for a subdomain without 161 requiring a challenge to be fulfilled against that explicit 162 subdomain. ACME server policy could allow issuance of certificates 163 for a subdomain to a client where the client only has to fulfill an 164 authorization challenge for the parent domain. 166 This allows a flow where a client proves ownership of "domain.com" 167 and then successfully obtains a certificate for "sub.domain.com". 168 The ACME pre-authorization flow makes most sense for this use case, 169 and that is what is illustrated in the following call flow. 171 The client could pre-authorize for the parent domain once, and then 172 issue multiple newOrder requests for certificates for multiple 173 subdomains. This call flow illustrates the client only placing one 174 newOrder request. 176 +--------+ +------+ +-----+ 177 | Client | | ACME | | DNS | 178 +--------+ +------+ +-----+ 179 | | | 180 STEP 1: Pre-Authorization of parent domain 181 | | | 182 | POST /newAuthz | | 183 | "domain.com" | | 184 |--------------------->| | 185 | | | 186 | 201 authorizations | | 187 |<---------------------| | 188 | | | 189 | Publish DNS TXT | | 190 | "domain.com" | | 191 |--------------------------------->| 192 | | | 193 | POST /challenge | | 194 |--------------------->| | 195 | | Verify | 196 | |---------->| 197 | 200 status=valid | | 198 |<---------------------| | 199 | | | 200 | Delete DNS TXT | | 201 | "domain.com" | | 202 |--------------------------------->| 203 | | | 204 STEP 2: Place order for subdomain 205 | | | 206 | POST /newOrder | | 207 | "sub.domain.com" | | 208 |--------------------->| | 209 | | | 210 | 201 status=ready | | 211 |<---------------------| | 212 | | | 213 | POST /finalize | | 214 | CSR "sub.domain.com" | | 215 |--------------------->| | 216 | | | 217 | 200 OK status=valid | | 218 |<---------------------| | 219 | | | 220 | POST /certificate | | 221 |--------------------->| | 222 | | | 223 | 200 OK | | 224 | PKI "sub.domain.com" | | 225 |<---------------------| | 227 4. ACME Integration with EST 229 EST [RFC7030] defines a mechanism for clients to enroll with a PKI 230 Registration Authority by sending CMC messages over HTTP. EST 231 section 1 states: 233 "Architecturally, the EST service is located between a Certification 234 Authority (CA) and a client. It performs several functions 235 traditionally allocated to the Registration Authority (RA) role in a 236 PKI." 238 EST section 1.1 states that: 240 "For certificate issuing services, the EST CA is reached through the 241 EST server; the CA could be logically "behind" the EST server or 242 embedded within it." 244 When the CA is logically "behind" the EST RA, EST does not specify 245 how the RA communicates with the CA. EST section 1 states: 247 "The nature of communication between an EST server and a CA is not 248 described in this document." 250 This section outlines how ACME could be used for communication 251 between the EST RA and the CA. The example call flow shows the RA 252 proving ownership of a parent domain, with individual client 253 certificates being subdomains under that parent domain. This is an 254 optimisation that reduces DNS and ACME traffic overhead. The RA 255 could of course prove ownership of every explicit client certificate 256 identifier. 258 The call flow also illustrates how the Pledge inserts relevant domain 259 information into the CSR Subject and Subject Alternative Name fields. 261 [todo: The details of how the pledge determines what information to 262 include in the CSR are TBD. For example, the pledge could discover 263 the DNS domain via DHCP Option 15, and prepend the identifier from 264 the IDevID to this. 266 Note also that EST https://tools.ietf.org/html/rfc7030#section-4.2.1 267 states that the ChangeSubjectName attribute MAY be used, for example, 268 if the Pledge uses its IDevID when requesting a CSR/LDevID with a 269 different Subject, however this field does not appear to have 270 widespread support across CAs.] 272 +--------+ +--------+ +------+ +-----+ 273 | Pledge | | EST RA | | ACME | | DNS | 274 +--------+ +--------+ +------+ +-----+ 275 | | | | 276 STEP 1: Pre-Authorization of parent domain 277 | | | | 278 | | POST /newAuthz | | 279 | | "domain.com" | | 280 | |--------------------->| | 281 | | | | 282 | | 201 authorizations | | 283 | |<---------------------| | 284 | | | | 285 | | Publish DNS TXT | | 286 | | "domain.com" | | 287 | |--------------------------------->| 288 | | | | 289 | | POST /challenge | | 290 | |--------------------->| | 291 | | | Verify | 292 | | |---------->| 293 | | 200 status=valid | | 294 | |<---------------------| | 295 | | | | 296 | | Delete DNS TXT | | 297 | | "domain.com" | | 298 | |--------------------------------->| 299 | | | | 300 STEP 2: Pledge enrolls against RA 301 | | | | 302 | POST /simpleenroll | | | 303 | PCSK#10 CSR | | | 304 | "pledgeid.domain.com"| | | 305 |--------------------->| | | 306 | | | | 307 | 202 Retry-After | | | 308 |<---------------------| | | 309 | | | | 310 STEP 3: RA places ACME order 311 | | | | 312 | | POST /newOrder | | 313 | | "pledgeid.domain.com"| | 314 | |--------------------->| | 315 | | | | 316 | | 201 status=ready | | 317 | |<---------------------| | 318 | | | | 319 | | POST /finalize | | 320 | | PKCS#10 CSR | | 321 | | "pledgeid.domain.com"| | 322 | |--------------------->| | 323 | | | | 324 | | 200 OK status=valid | | 325 | |<---------------------| | 326 | | | | 327 | | POST /certificate | | 328 | |--------------------->| | 329 | | | | 330 | | 200 OK | | 331 | | PEM | | 332 | | "pledgeid.domain.com"| | 333 | |<---------------------| | 334 | | | | 335 STEP 4: Pledge retries enroll 337 | | | | 338 | POST /simpleenroll | | | 339 | PCSK#10 CSR | | | 340 | "pledgeid.domain.com"| | | 341 |--------------------->| | | 342 | | | | 343 | 200 OK | | | 344 | PKCS#7 | | | 345 | "pledgeid.domain.com"| | | 346 |<---------------------| | | 348 5. ACME Integration with BRSKI 350 BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] is based upon EST 351 [RFC7030] and defines how to autonomically bootstrap PKI trust 352 anchors into devices via means of signed vouchers. EST certificate 353 enrollment may then optionally take place after trust has been 354 established. BRKSI voucher exchange and trust establishment are 355 based on EST extensions and the certificate enrollment part of BRSKI 356 is fully based on EST. Similar to EST, BRSKI does not define how the 357 EST RA communicates with the CA. Therefore, the mechanisms outlined 358 in the previous section for using ACME as the communications protocol 359 between the EST RA and the CA are equally applicable to BRSKI. 361 The following call flow shows how ACME may be integrated into a full 362 BRSKI voucher plus EST enrollment workflow. For brevity, it assumes 363 that the EST RA has previously proven ownership of a parent domain 364 and that pledge certificate identifiers are a subdomain of that 365 parent domain. The domain ownership exchanges between the RA, ACME 366 and DNS are not shown. Similarly, not all BRSKI interactions are 367 shown and only the key protocol flows involving voucher exchange and 368 EST enrollment are shown. 370 [todo: similar to the EST section above, it is TBD exactly how the 371 pledge determines what domain information to insert in the CSR. A 372 possibility is that the Voucher response includes domain information 373 and explicitly instructs the pledge what information to insert in the 374 CSR. The RA could also instruct the Pledge to include a guid or a 375 new unique random identifier in place of its MAC address, serial 376 number, or whatever other identifying information is included in the 377 IDevID. 379 +--------+ +--------+ +------+ +------+ 380 | Pledge | | EST RA | | ACME | | MASA | 381 +--------+ +--------+ +------+ +------+ 382 | | | | 383 NOTE: Pre-Authorization of "domain.com" is complete 384 | | | | 385 STEP 1: Pledge requests Voucher 386 | | | | 387 | POST /requestvoucher | | | 388 |--------------------->| | | 389 | | POST /requestvoucher | | 390 | |--------------------------------->| 391 | | | | 392 | | 200 OK Voucher | | 393 | |<---------------------------------| 394 | 200 OK Voucher | | | 395 |<---------------------| | | 396 | | | | 397 STEP 2: Pledge enrolls against RA 398 | | | | 399 | POST /simpleenroll | | | 400 | PCSK#10 CSR | | | 401 | "pledgeid.domain.com"| | | 402 |--------------------->| | | 403 | | | | 404 | 202 Retry-After | | | 405 |<---------------------| | | 406 | | | | 407 STEP 3: RA places ACME order 408 | | | | 409 | | POST /newOrder | | 410 | | "pledgeid.domain.com"| | 411 | |--------------------->| | 412 | | | | 413 | | 201 status=ready | | 414 | |<---------------------| | 415 | | | | 416 | | POST /finalize | | 417 | | PKCS#10 CSR | | 418 | | "pledgeid.domain.com"| | 419 | |--------------------->| | 420 | | | | 421 | | 200 OK status=valid | | 422 | |<---------------------| | 423 | | | | 424 | | POST /certificate | | 425 | |--------------------->| | 426 | | | | 427 | | 200 OK | | 428 | | PEM | | 429 | | "pledgeid.domain.com"| | 430 | |<---------------------| | 431 | | | | 432 STEP 4: Pledge retries enroll 434 | | | | 435 | POST /simpleenroll | | | 436 | PCSK#10 CSR | | | 437 | "pledgeid.domain.com"| | | 438 |--------------------->| | | 439 | | | | 440 | 200 OK | | | 441 | PKCS#7 | | | 442 | "pledgeid.domain.com"| | | 443 |<---------------------| | | 445 6. ACME Integration with TEAP 447 TEAP [RFC7170] define a tunnel-based EAP method that enables secure 448 communication between a peer and a server by using TLS to establish a 449 mutually authenticated tunnel. TEAP enables certificate provisioning 450 within the tunnel. TEAP does not define how the TEAP server 451 communicates with the CA. 453 This section outlines how ACME could be used for communication 454 between the TEAP server and the CA. The example call flow shows the 455 TEAP server proving ownership of a parent domain, with individual 456 client certificates being subdomains under that parent domain. This 457 is an optimisation that reduces DNS and ACME traffic overhead. The 458 TEAP server could of course prove ownership of every explicit client 459 certificate identifier. 461 [todo: Similar to the previous section, it is TBD exactly how the 462 Pledge determines what Subject/SAN to put in the CSR request.] 464 +--------+ +-------------+ +------+ +-----+ 465 | Pledge | | TEAP-Server | | ACME | | DNS | 466 +--------+ +-------------+ +------+ +-----+ 467 | | | | 468 STEP 1: Pre-Authorization of parent domain 469 | | | | 470 | | POST /newAuthz | | 471 | | "domain.com" | | 472 | |--------------------->| | 473 | | | | 474 | | 201 authorizations | | 475 | |<---------------------| | 476 | | | | 477 | | Publish DNS TXT | | 478 | | "domain.com" | | 479 | |--------------------------------->| 480 | | | | 481 | | POST /challenge | | 482 | |--------------------->| | 483 | | | Verify | 484 | | |---------->| 485 | | 200 status=valid | | 486 | |<---------------------| | 487 | | | | 488 | | Delete DNS TXT | | 489 | | "domain.com" | | 490 | |--------------------------------->| 491 | | | | 492 | | | | 493 STEP 2: Establsh EAP Outer Tunnel 494 | | | | 495 | EAP-Request/ | | | 496 | Type=Identity | | | 497 |<------------------------| | | 498 | | | | 499 | EAP-Response/ | | | 500 | Type=Identity | | | 501 |------------------------>| | | 502 | | | | 503 | EAP-Request/ | | | 504 | Type=TEAP, | | | 505 | TEAP Start, | | | 506 | Authority-ID TLV | | | 507 |<------------------------| | | 508 | | | | 509 | EAP-Response/ | | | 510 | Type=TEAP, | | | 511 | TLS(ClientHello) | | | 512 |------------------------>| | | 513 | | | | 514 | EAP-Request/ | | | 515 | Type=TEAP, | | | 516 | TLS(ServerHello, | | | 517 | Certificate, | | | 518 | ServerKeyExchange, | | | 519 | CertificateRequest, | | | 520 | ServerHelloDone) | | | 521 |<------------------------| | | 522 | | | | 523 | EAP-Response/ | | | 524 | Type=TEAP, | | | 525 | TLS(Certificate, | | | 526 | ClientKeyExchange, | | | 527 | CertificateVerify, | | | 528 | ChangeCipherSpec, | | | 529 | Finished) | | | 530 |------------------------>| | | 531 | | | | 532 | EAP-Request/ | | | 533 | Type=TEAP, | | | 534 | TLS(ChangeCipherSpec, | | | 535 | Finished), | | | 536 | {Crypto-Binding TLV, | | | 537 | Result TLV=Success} | | | 538 |<------------------------| | | 539 | | | | 540 | EAP-Response/ | | | 541 | Type=TEAP, | | | 542 | {Crypto-Binding TLV, | | | 543 | Result TLV=Success} | | | 544 |------------------------>| | | 545 | | | | 546 | EAP-Request/ | | | 547 | Type=TEAP, | | | 548 | {Request-Action TLV: | | | 549 | Status=Failure, | | | 550 | Action=Process-TLV, | | | 551 | TLV=PKCS#10} | | | 552 |<------------------------| | | 553 | | | | 554 STEP 3: Enroll for certificate 555 | | | | 556 | EAP-Response/ | | | 557 | Type=TEAP, | | | 558 | {PKCS#10 TLV: | | | 559 | "pledgeid.domain.com"}| | | 560 |------------------------>| | | 561 | | POST /newOrder | | 562 | | "pledgeid.domain.com"| | 563 | |--------------------->| | 564 | | | | 565 | | 201 status=ready | | 566 | |<---------------------| | 567 | | | | 568 | | POST /finalize | | 569 | | PKCS#10 CSR | | 570 | | "pledgeid.domain.com"| | 571 | |--------------------->| | 572 | | | | 573 | | 200 OK status=valid | | 574 | |<---------------------| | 575 | | | | 576 | | POST /certificate | | 577 | |--------------------->| | 578 | | | | 579 | | 200 OK | | 580 | | PEM | | 581 | | "pledgeid.domain.com"| | 582 | |<---------------------| | 583 | | | | 584 | EAP-Request/ | | | 585 | Type=TEAP, | | | 586 | {PKCS#7 TLV, | | | 587 | Result TLV=Success} | | | 588 |<------------------------| | | 589 | | | | 590 | EAP-Response/ | | | 591 | Type=TEAP, | | | 592 | {Result TLV=Success} | | | 593 |------------------------>| | | 594 | | | | 595 | EAP-Success | | | 596 |<------------------------| | | 598 7. ACME Integration with TEAP-BRSKI 600 TEAP-BRSKI [I-D.lear-eap-teap-brski] defines how to execute BRSKI at 601 layer 2 inside a TEAP tunnel. Similar to the TEAP proposal in the 602 previous section, BRSKI-TEAP leverages the existing TEAP PKXS#10 and 603 PKCS#7 mechanisms for certificate enrollment, and does not define how 604 the TEAP server communicates with the CA. 606 This section outlines how ACME could be used for communication 607 between the TEAP server and the CA, and how this fits in with the 608 TEAP-BRSKI proposal. 610 [todo: Similar to the previous section, it is TBD exactly how the 611 Pledge determines what Subject/SAN to put in the CSR request.] 613 +--------+ +-------------+ +------+ +------+ 614 | Pledge | | TEAP-Server | | ACME | | MASA | 615 +--------+ +-------------+ +------+ +------+ 616 | | | | 617 NOTE: Pre-Authorization of "domain.com" is complete 618 and EAP outer tunnel is established as outlined in 619 the previous section 620 | | | | 621 STEP 1: Perform BRSKI Flow 622 | | | | 623 | EAP-Request/ | | | 624 | Type=TEAP, | | | 625 | {Request-Action TLV: | | | 626 | Status=Failure, | | | 627 | Action=Process-TLV, | | | 628 | TLV=Request-Voucher, | | | 629 | TLV=Trusted-Server-Root,| | | 630 | TLV=CSR-Attributes, | | | 631 | TLV=PKCS#10} | | | 632 |<---------------------------| | | 633 | | | | 634 | EAP-Response/ | | | 635 | Type=TEAP, | | | 636 | {Request-Voucher TLV} | | | 637 |--------------------------->| RequestVoucher | | 638 | |-------------------/ | \------>| 639 | | Voucher | | 640 | |<------------------/ | \-------| 641 | EAP-Request/ | | | 642 | Type=TEAP, | | | 643 | {Voucher TLV} | | | 644 |<---------------------------| | | 645 | | | | 646 STEP 2: Retrieve CA Configuration 647 | | | | 648 | EAP-Response/ | | | 649 | Type=TEAP, | | | 650 | {Trusted-Server-Root TLV} | | | 651 |--------------------------->| | | 652 | | | | 653 | EAP-Request/ | | | 654 | Type=TEAP, | | | 655 | {Trusted-Server-Root TLV} | | | 656 |<---------------------------| | | 657 | | | | 658 | EAP-Response/ | | | 659 | Type=TEAP, | | | 660 | {CSR-Attributes TLV} | | | 661 |--------------------------->| | | 662 | | | | 663 | EAP-Request/ | | | 664 | Type=TEAP, | | | 665 | {CSR-Attributes TLV} | | | 666 |<---------------------------| | | 667 | | | | 668 STEP 3: Enroll for certificate 669 | | | | 670 | EAP-Response/ | | | 671 | Type=TEAP, | | | 672 | {PKCS#10 TLV: | | | 673 | "pledgeid.domain.com"} | | | 674 |--------------------------->| | | 675 | |POST /newOrder | | 676 | |"pledgeid.domain.com"| | 677 | |-------------------->| | 678 | | | | 679 | | 201 status=ready | | 680 | |<--------------------| | 681 | | | | 682 | |POST /finalize | | 683 | |PKCS#10 CSR | | 684 | |"pledgeid.domain.com"| | 685 | |-------------------->| | 686 | | | | 687 | | 200 OK status=valid | | 688 | |<--------------------| | 689 | | | | 690 | | POST /certificate | | 691 | |-------------------->| | 692 | | | | 693 | |200 OK | | 694 | |PEM | | 695 | |"pledgeid.domain.com"| | 696 | |<--------------------| | 697 | | | | 698 | EAP-Request/ | | | 699 | Type=TEAP, | | | 700 | {PKCS#7 TLV, | | | 701 | Result TLV=Success} | | | 702 |<---------------------------| | | 703 | | | | 704 | EAP-Response/ | | | 705 | Type=TEAP, | | | 706 | {Result TLV=Success} | | | 707 |--------------------------->| | | 708 | | | | 709 | EAP-Success | | | 710 |<---------------------------| | | 712 8. IANA Considerations 714 [todo] 716 9. Security Considerations 718 [todo] 720 10. Informative References 722 [I-D.ietf-anima-bootstrapping-keyinfra] 723 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 724 S., and K. Watsen, "Bootstrapping Remote Secure Key 725 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 726 keyinfra-22 (work in progress), June 2019. 728 [I-D.lear-eap-teap-brski] 729 Lear, E., Friel, O., and N. Cam-Winget, "Bootstrapping Key 730 Infrastructure over EAP", draft-lear-eap-teap-brski-02 731 (work in progress), February 2019. 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, 735 DOI 10.17487/RFC2119, March 1997, 736 . 738 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 739 "Enrollment over Secure Transport", RFC 7030, 740 DOI 10.17487/RFC7030, October 2013, 741 . 743 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 744 "Tunnel Extensible Authentication Protocol (TEAP) Version 745 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 746 . 748 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 749 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 750 May 2017, . 752 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 753 Kasten, "Automatic Certificate Management Environment 754 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 755 . 757 Appendix A. Comments 759 Authors' Addresses 760 Owen Friel 761 Cisco 763 Email: ofriel@cisco.com 765 Richard Barnes 766 Cisco 768 Email: rlb@ipv.sx