idnits 2.17.1 draft-ietf-acme-integrations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (January 20, 2020) is 1555 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-00 == Outdated reference: A later version (-04) exists of draft-friel-anima-brski-cloud-01 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-34 == Outdated reference: A later version (-06) exists of draft-lear-eap-teap-brski-05 Summary: 0 errors (**), 0 flaws (~~), 6 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: July 23, 2020 R. Shekh-Yusef 6 Avaya 7 M. Richardson 8 Sandelman Software Works 9 January 20, 2020 11 ACME Integrations 12 draft-ietf-acme-integrations-00 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 July 23, 2020. 38 Copyright Notice 40 Copyright (c) 2020 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. ACME Integration with TEAP-BRSKI . . . . . . . . . . . . . . 14 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 64 10. Informative References . . . . . . . . . . . . . . . . . . . 16 65 Appendix A. Comments . . . . . . . . . . . . . . . . . . . . . . 17 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 68 1. Introduction 70 ACME [RFC8555] defines a protocol that a certificate authority (CA) 71 and an applicant can use to automate the process of domain name 72 ownership validation and X.509 (PKIX) certificate issuance. The 73 protocol is rich and flexible and enables multiple use cases that are 74 not immediately obvious from reading the specification. This 75 document explicitly outlines multiple advanced ACME use cases 76 including: 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 BRSKI Default Cloud Registrar 84 [I-D.friel-anima-brski-cloud] 86 o ACME integration with TEAP [RFC7170] 88 o ACME integration with TEAP-BRSKI [I-D.lear-eap-teap-brski] 90 The integrations with EST, BRSKI (which is based upon EST), and TEAP 91 enable automated certificate enrolment for devices. 93 ACME for subdomains [I-D.friel-acme-subdomains] outlines how ACME can 94 be used by a client to obtain a certificate for a subdomain 95 identifier from a certificate authority where the client has 96 fulfilled a challenge against a parent domain, but does not need to 97 fulfil a challenge against the explicit subdomain. This is a useful 98 optimisation when ACME is used to issue certificates for large 99 numbers of devices as it reduces the domain ownership proof traffic 100 (DNS or HTTP) and ACME traffic overhead, but is not a necessary 101 requirement. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 The following terms are used in this document: 113 o BRSKI: Bootstrapping Remote Secure Key Infrastructures 114 [I-D.ietf-anima-bootstrapping-keyinfra] 116 o CA: Certificate Authority 118 o CMC: Certificate Management over CMS 120 o CSR: Certificate Signing Request 122 o EST: Enrollment over Secure Transport [RFC7030] 124 o FQDN: Fully Qualified Domain Name 126 o RA: PKI Registration Authority 128 o TEAP: Tunneled Extensible Authentication Protocol [RFC7170] 130 3. ACME Integration with EST 132 EST [RFC7030] defines a mechanism for clients to enroll with a PKI 133 Registration Authority by sending CMC messages over HTTP. EST 134 section 1 states: 136 "Architecturally, the EST service is located between a Certification 137 Authority (CA) and a client. It performs several functions 138 traditionally allocated to the Registration Authority (RA) role in a 139 PKI." 141 EST section 1.1 states that: 143 "For certificate issuing services, the EST CA is reached through the 144 EST server; the CA could be logically "behind" the EST server or 145 embedded within it." 147 When the CA is logically "behind" the EST RA, EST does not specify 148 how the RA communicates with the CA. EST section 1 states: 150 "The nature of communication between an EST server and a CA is not 151 described in this document." 153 This section outlines how ACME could be used for communication 154 between the EST RA and the CA. The example call flow leverages 155 [I-D.friel-acme-subdomains] and shows the RA proving ownership of a 156 parent domain, with individual client certificates being subdomains 157 under that parent domain. This is an optimisation that reduces DNS 158 and ACME traffic overhead. The RA could of course prove ownership of 159 every explicit client certificate identifier. 161 The call flow illustrates the client calling the EST /csrattrs API 162 before calling the EST /simpleenroll API. This enables the EST 163 server to indicate to the client what attributes it expects the 164 client to include in the CSR request send in the /simpleenroll API. 165 For example, EST servers could use this mechanism to tell the client 166 what fields to include in the CSR Subject and Subject Alternative 167 Name fields. 169 The call flow illustrates the EST RA returning a 202 Retry-After 170 response to the client's simpleenroll request. This is an optional 171 step and may be necessary if the ACME server is unable to issue a 172 certificate immediately. 174 [[ TODO the 202 response should probably be returned by the EST RA 175 only if ACME returns newOrder 'pending' or finalize 'processing' 176 responses. How much detail should be included in this document? ]] 178 +--------+ +--------+ +------+ +-----+ 179 | Pledge | | EST RA | | ACME | | DNS | 180 +--------+ +--------+ +------+ +-----+ 181 | | | | 182 STEP 1: Pre-Authorization of parent domain 183 | | | | 184 | | POST /newAuthz | | 185 | | "domain.com" | | 186 | |--------------------->| | 187 | | | | 188 | | 201 authorizations | | 189 | |<---------------------| | 190 | | | | 191 | | Publish DNS TXT | | 192 | | "domain.com" | | 193 | |--------------------------------->| 194 | | | | 195 | | POST /challenge | | 196 | |--------------------->| | 197 | | | Verify | 198 | | |---------->| 199 | | 200 status=valid | | 200 | |<---------------------| | 201 | | | | 202 | | Delete DNS TXT | | 203 | | "domain.com" | | 204 | |--------------------------------->| 205 | | | | 206 STEP 2: Pledge enrolls against RA 207 | | | | 208 | GET /csrattrs | | | 209 |--------------------->| | | 210 | | | | 211 | 200 OK | | | 212 | SEQUENCE {AttrOrOID} | | | 213 | SAN OID: | | | 214 | "pledgeid.domain.com"| | | 215 |<---------------------| | | 216 | | | | 217 | POST /simpleenroll | | | 218 | PCSK#10 CSR | | | 219 | "pledgeid.domain.com"| | | 220 |--------------------->| | | 221 | | | | 222 | 202 Retry-After | | | 223 |<---------------------| | | 224 | | | | 225 STEP 3: RA places ACME order 226 | | | | 227 | | POST /newOrder | | 228 | | "pledgeid.domain.com"| | 229 | |--------------------->| | 230 | | | | 231 | | 201 status=ready | | 232 | |<---------------------| | 233 | | | | 234 | | POST /finalize | | 235 | | PKCS#10 CSR | | 236 | | "pledgeid.domain.com"| | 237 | |--------------------->| | 238 | | | | 239 | | 200 OK status=valid | | 240 | |<---------------------| | 241 | | | | 242 | | POST /certificate | | 243 | |--------------------->| | 244 | | | | 245 | | 200 OK | | 246 | | PEM | | 247 | | "pledgeid.domain.com"| | 248 | |<---------------------| | 249 | | | | 250 STEP 4: Pledge retries enroll 251 | | | | 252 | POST /simpleenroll | | | 253 | PCSK#10 CSR | | | 254 | "pledgeid.domain.com"| | | 255 |--------------------->| | | 256 | | | | 257 | 200 OK | | | 258 | PKCS#7 | | | 259 | "pledgeid.domain.com"| | | 260 |<---------------------| | | 262 4. ACME Integration with BRSKI 264 BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] is based upon EST 265 [RFC7030] and defines how to autonomically bootstrap PKI trust 266 anchors into devices via means of signed vouchers. EST certificate 267 enrollment may then optionally take place after trust has been 268 established. BRKSI voucher exchange and trust establishment are 269 based on EST extensions and the certificate enrollment part of BRSKI 270 is fully based on EST. Similar to EST, BRSKI does not define how the 271 EST RA communicates with the CA. Therefore, the mechanisms outlined 272 in the previous section for using ACME as the communications protocol 273 between the EST RA and the CA are equally applicable to BRSKI. 275 The following call flow shows how ACME may be integrated into a full 276 BRSKI voucher plus EST enrollment workflow. For brevity, it assumes 277 that the EST RA has previously proven ownership of a parent domain 278 and that pledge certificate identifiers are a subdomain of that 279 parent domain. The domain ownership exchanges between the RA, ACME 280 and DNS are not shown. Similarly, not all BRSKI interactions are 281 shown and only the key protocol flows involving voucher exchange and 282 EST enrollment are shown. 284 Similar to the EST section above, the client calls EST /csrattrs API 285 before calling the EST /simpleenroll API. This enables the server to 286 indicate what fields the pledge should include in the CSR that the 287 client sends in the /simpleenroll API. 289 [[ TODO: the same question about 202 handling details as outlined in 290 the EST section apply here. ]] 292 +--------+ +--------+ +------+ +------+ 293 | Pledge | | EST RA | | ACME | | MASA | 294 +--------+ +--------+ +------+ +------+ 295 | | | | 296 NOTE: Pre-Authorization of "domain.com" is complete 297 | | | | 298 STEP 1: Pledge requests Voucher 299 | | | | 300 | POST /requestvoucher | | | 301 |--------------------->| | | 302 | | POST /requestvoucher | | 303 | |--------------------------------->| 304 | | | | 305 | | 200 OK Voucher | | 306 | |<---------------------------------| 307 | 200 OK Voucher | | | 308 |<---------------------| | | 309 | | | | 310 STEP 2: Pledge enrolls against RA 311 | | | | 312 | GET /csrattrs | | | 313 |--------------------->| | | 314 | | | | 315 | 200 OK | | | 316 | SEQUENCE {AttrOrOID} | | | 317 | SAN OID: | | | 318 | "pledgeid.domain.com"| | | 319 |<---------------------| | | 320 | | | | 321 | POST /simpleenroll | | | 322 | PCSK#10 CSR | | | 323 | "pledgeid.domain.com"| | | 324 |--------------------->| | | 325 | | | | 326 | 202 Retry-After | | | 327 |<---------------------| | | 328 | | | | 329 STEP 3: RA places ACME order 330 | | | | 331 | | POST /newOrder | | 332 | | "pledgeid.domain.com"| | 333 | |--------------------->| | 334 | | | | 335 | | 201 status=ready | | 336 | |<---------------------| | 337 | | | | 338 | | POST /finalize | | 339 | | PKCS#10 CSR | | 340 | | "pledgeid.domain.com"| | 341 | |--------------------->| | 342 | | | | 343 | | 200 OK status=valid | | 344 | |<---------------------| | 345 | | | | 346 | | POST /certificate | | 347 | |--------------------->| | 348 | | | | 349 | | 200 OK | | 350 | | PEM | | 351 | | "pledgeid.domain.com"| | 352 | |<---------------------| | 353 | | | | 354 STEP 4: Pledge retries enroll 355 | | | | 356 | POST /simpleenroll | | | 357 | PCSK#10 CSR | | | 358 | "pledgeid.domain.com"| | | 359 |--------------------->| | | 360 | | | | 361 | 200 OK | | | 362 | PKCS#7 | | | 363 | "pledgeid.domain.com"| | | 364 |<---------------------| | | 366 5. ACME Integration with BRSKI Default Cloud Registrar 368 BRSKI Cloud Registrar [I-D.friel-anima-brski-cloud] specifies the 369 behaviour of a BRSKI Cloud Registrar, and how a pledge can interact 370 with a BRSKI Cloud Registrar when bootstrapping. Similar to the 371 local domain registrar BRSKI flow, ACME can be easily integrated with 372 a cloud registrar bootstrap flow. 374 BRSKI cloud registrar is flexible and allows for multiple different 375 local domain discovery and redirect scenarios. In the example 376 illustrated here, the extension to [RFC8366] Vouchers which is 377 defined in [[TODO ID-TBD]] and allows the specification of a 378 bootstrap DNS domain is leveraged. This extension allows the cloud 379 registrar to specify the local domain RA that the pledge should 380 connect to for the purposes of EST enrollment. 382 +--------+ +--------+ +------+ +----------+ 383 | Pledge | | EST RA | | ACME | | Cloud RA | 384 +--------+ +--------+ +------+ | / MASA | 385 | +----------+ 386 | | 387 NOTE: Pre-Authorization of "domain.com" is complete 388 | | 389 STEP 1: Pledge requests Voucher from Cloud Registrar 390 | | 391 | POST /requestvoucher | 392 |-------------------------------------------------------->| 393 | | 394 | 200 OK Voucher (EST RA domain) | 395 |<--------------------------------------------------------| 396 | | | | 397 STEP 2: Pledge enrolls against local domain RA 398 | | | | 399 | GET /csrattrs | | | 400 |--------------------->| | | 401 | | | | 402 | 200 OK | | | 403 | SEQUENCE {AttrOrOID} | | | 404 | SAN OID: | | | 405 | "pledgeid.domain.com"| | | 406 |<---------------------| | | 407 | | | | 408 | POST /simpleenroll | | | 409 | PCSK#10 CSR | | | 410 | "pledgeid.domain.com"| | | 411 |--------------------->| | | 412 | | | | 413 | 202 Retry-After | | | 414 |<---------------------| | | 415 | | | | 416 STEP 3: RA places ACME order 417 | | | | 418 | | POST /newOrder | | 419 | | "pledgeid.domain.com"| | 420 | |--------------------->| | 421 | | | | 422 | | 201 status=ready | | 423 | |<---------------------| | 424 | | | | 425 | | POST /finalize | | 426 | | PKCS#10 CSR | | 427 | | "pledgeid.domain.com"| | 428 | |--------------------->| | 429 | | | | 430 | | 200 OK status=valid | | 431 | |<---------------------| | 432 | | | | 433 | | POST /certificate | | 434 | |--------------------->| | 435 | | | | 436 | | 200 OK | | 437 | | PEM | | 438 | | "pledgeid.domain.com"| | 439 | |<---------------------| | 440 | | | | 441 STEP 4: Pledge retries enroll 442 | | | | 443 | POST /simpleenroll | | | 444 | PCSK#10 CSR | | | 445 | "pledgeid.domain.com"| | | 446 |--------------------->| | | 447 | | | | 448 | 200 OK | | | 449 | PKCS#7 | | | 450 | "pledgeid.domain.com"| | | 451 |<---------------------| | | 453 6. ACME Integration with TEAP 455 TEAP [RFC7170] defines a tunnel-based EAP method that enables secure 456 communication between a peer and a server by using TLS to establish a 457 mutually authenticated tunnel. TEAP enables certificate provisioning 458 within the tunnel. TEAP does not define how the TEAP server 459 communicates with the CA. 461 This section outlines how ACME could be used for communication 462 between the TEAP server and the CA. The example call flow leverages 463 [I-D.friel-acme-subdomains] and shows the TEAP server proving 464 ownership of a parent domain, with individual client certificates 465 being subdomains under that parent domain. 467 The example illustrates the TEAP server sending a Request-Action TLV 468 including a CSR-Attributes TLV instructing the peer to send a CSR- 469 Attributes TLV to the server. This enables the server to indicate 470 what fields the peer should include in the CSR that the peer sends in 471 the PKCS#10 TLV. For example, the TEAP server could instruct the 472 peer what Subject or SAN entries to include in its CSR. 474 [[ TODO: Hmm, this section probably needs to be deleted. It shows 475 use of CSR-Attributes TLV which is not defined in RFC7170, and is 476 only introduced in draft-lear-eap-teap-brski. We likely need CSR- 477 Attributes TLV for in band cert enrollment. ]] 479 +------+ +-------------+ +------+ +-----+ 480 | Peer | | TEAP-Server | | ACME | | DNS | 481 +------+ +-------------+ +------+ +-----+ 482 | | | | 483 STEP 1: Pre-Authorization of parent domain 484 | | | | 485 | | POST /newAuthz | | 486 | | "domain.com" | | 487 | |--------------------->| | 488 | | | | 489 | | 201 authorizations | | 490 | |<---------------------| | 491 | | | | 492 | | Publish DNS TXT | | 493 | | "domain.com" | | 494 | |--------------------------------->| 495 | | | | 496 | | POST /challenge | | 497 | |--------------------->| | 498 | | | Verify | 499 | | |---------->| 500 | | 200 status=valid | | 501 | |<---------------------| | 502 | | | | 503 | | Delete DNS TXT | | 504 | | "domain.com" | | 505 | |--------------------------------->| 506 | | | | 507 | | | | 508 STEP 2: Establsh EAP Outer Tunnel 509 | | | | 510 | EAP-Request/ | | | 511 | Type=Identity | | | 512 |<------------------------| | | 513 | | | | 514 | EAP-Response/ | | | 515 | Type=Identity | | | 516 |------------------------>| | | 517 | | | | 518 | EAP-Request/ | | | 519 | Type=TEAP, | | | 520 | TEAP Start, | | | 521 | Authority-ID TLV | | | 522 |<------------------------| | | 523 | | | | 524 | EAP-Response/ | | | 525 | Type=TEAP, | | | 526 | TLS(ClientHello) | | | 527 |------------------------>| | | 528 | | | | 529 | EAP-Request/ | | | 530 | Type=TEAP, | | | 531 | TLS(ServerHello, | | | 532 | Certificate, | | | 533 | ServerKeyExchange, | | | 534 | CertificateRequest, | | | 535 | ServerHelloDone) | | | 536 |<------------------------| | | 537 | | | | 538 | EAP-Response/ | | | 539 | Type=TEAP, | | | 540 | TLS(Certificate, | | | 541 | ClientKeyExchange, | | | 542 | CertificateVerify, | | | 543 | ChangeCipherSpec, | | | 544 | Finished) | | | 545 |------------------------>| | | 546 | | | | 547 | EAP-Request/ | | | 548 | Type=TEAP, | | | 549 | TLS(ChangeCipherSpec, | | | 550 | Finished), | | | 551 | {Crypto-Binding TLV, | | | 552 | Result TLV=Success} | | | 553 |<------------------------| | | 554 | | | | 555 | EAP-Response/ | | | 556 | Type=TEAP, | | | 557 | {Crypto-Binding TLV, | | | 558 | Result TLV=Success} | | | 559 |------------------------>| | | 560 | | | | 561 | EAP-Request/ | | | 562 | Type=TEAP, | | | 563 | {Request-Action TLV: | | | 564 | Status=Failure, | | | 565 | Action=Process-TLV, | | | 566 | TLV=CSR-Attributes, | | | 567 | TLV=PKCS#10} | | | 568 |<------------------------| | | 569 | | | | 570 STEP 3: Enroll for certificate 571 | | | | 572 | EAP-Response/ | | | 573 | Type=TEAP, | | | 574 | {CSR-Attributes TLV} | | | 575 |------------------------>| | | 576 | | | | 577 | EAP-Request/ | | | 578 | Type=TEAP, | | | 579 | {CSR-Attributes TLV} | | | 580 |<------------------------| | | 581 | | | | 582 | EAP-Response/ | | | 583 | Type=TEAP, | | | 584 | {PKCS#10 TLV: | | | 585 | "pledgeid.domain.com"}| | | 586 |------------------------>| | | 587 | | POST /newOrder | | 588 | | "pledgeid.domain.com"| | 589 | |--------------------->| | 590 | | | | 591 | | 201 status=ready | | 592 | |<---------------------| | 593 | | | | 594 | | POST /finalize | | 595 | | PKCS#10 CSR | | 596 | | "pledgeid.domain.com"| | 597 | |--------------------->| | 598 | | | | 599 | | 200 OK status=valid | | 600 | |<---------------------| | 601 | | | | 602 | | POST /certificate | | 603 | |--------------------->| | 604 | | | | 605 | | 200 OK | | 606 | | PEM | | 607 | | "pledgeid.domain.com"| | 608 | |<---------------------| | 609 | | | | 610 | EAP-Request/ | | | 611 | Type=TEAP, | | | 612 | {PKCS#7 TLV, | | | 613 | Result TLV=Success} | | | 614 |<------------------------| | | 615 | | | | 616 | EAP-Response/ | | | 617 | Type=TEAP, | | | 618 | {Result TLV=Success} | | | 619 |------------------------>| | | 620 | | | | 621 | EAP-Success | | | 622 |<------------------------| | | 624 7. ACME Integration with TEAP-BRSKI 626 TEAP-BRSKI [I-D.lear-eap-teap-brski] defines how to execute BRSKI at 627 layer 2 inside a TEAP tunnel. Similar to the TEAP proposal in the 628 previous section, BRSKI-TEAP leverages the existing TEAP PKXS#10 and 629 PKCS#7 mechanisms for certificate enrollment, and does not define how 630 the TEAP server communicates with the CA. 632 This section outlines how ACME could be used for communication 633 between the TEAP server and the CA, and how this fits in with the 634 TEAP-BRSKI proposal. 636 The TEAP server uses the CSR-Atributes TLV to tell the peer what 637 attributes to include in its CSR request. 639 [[ TODO: probably need to describe how Retry-After TLV can be used 640 when ACME returns newOrder 'pending' or finalize 'processing' ]] 642 +--------+ +-------------+ +------+ +------+ 643 | Pledge | | TEAP-Server | | ACME | | MASA | 644 +--------+ +-------------+ +------+ +------+ 645 | | | | 646 NOTE: Pre-Authorization of "domain.com" is complete 647 and EAP outer tunnel is established as outlined in 648 the previous section 649 | | | | 650 STEP 1: Perform BRSKI Flow 651 | | | | 652 | EAP-Request/ | | | 653 | Type=TEAP, | | | 654 | {Request-Action TLV: | | | 655 | Status=Failure, | | | 656 | Action=Process-TLV, | | | 657 | TLV=Request-Voucher, | | | 658 | TLV=Trusted-Server-Root,| | | 659 | TLV=CSR-Attributes, | | | 660 | TLV=PKCS#10} | | | 661 |<---------------------------| | | 662 | | | | 663 | EAP-Response/ | | | 664 | Type=TEAP, | | | 665 | {Request-Voucher TLV} | | | 666 |--------------------------->| RequestVoucher | | 667 | |-------------------/ | \------>| 668 | | Voucher | | 669 | |<------------------/ | \-------| 670 | EAP-Request/ | | | 671 | Type=TEAP, | | | 672 | {Voucher TLV} | | | 673 |<---------------------------| | | 674 | | | | 675 STEP 2: Retrieve CA Configuration 676 | | | | 677 | EAP-Response/ | | | 678 | Type=TEAP, | | | 679 | {Trusted-Server-Root TLV} | | | 680 |--------------------------->| | | 681 | | | | 682 | EAP-Request/ | | | 683 | Type=TEAP, | | | 684 | {Trusted-Server-Root TLV} | | | 685 |<---------------------------| | | 686 | | | | 687 | EAP-Response/ | | | 688 | Type=TEAP, | | | 689 | {CSR-Attributes TLV} | | | 690 |--------------------------->| | | 691 | | | | 692 | EAP-Request/ | | | 693 | Type=TEAP, | | | 694 | {CSR-Attributes TLV} | | | 695 |<---------------------------| | | 696 | | | | 697 STEP 3: Enroll for certificate 698 | | | | 699 | EAP-Response/ | | | 700 | Type=TEAP, | | | 701 | {PKCS#10 TLV: | | | 702 | "pledgeid.domain.com"} | | | 703 |--------------------------->| | | 704 | |POST /newOrder | | 705 | |"pledgeid.domain.com"| | 706 | |-------------------->| | 707 | | | | 708 | | 201 status=ready | | 709 | |<--------------------| | 710 | | | | 711 | |POST /finalize | | 712 | |PKCS#10 CSR | | 713 | |"pledgeid.domain.com"| | 714 | |-------------------->| | 715 | | | | 716 | | 200 OK status=valid | | 717 | |<--------------------| | 718 | | | | 719 | | POST /certificate | | 720 | |-------------------->| | 721 | | | | 722 | |200 OK | | 723 | |PEM | | 724 | |"pledgeid.domain.com"| | 725 | |<--------------------| | 726 | | | | 727 | EAP-Request/ | | | 728 | Type=TEAP, | | | 729 | {PKCS#7 TLV, | | | 730 | Result TLV=Success} | | | 731 |<---------------------------| | | 732 | | | | 733 | EAP-Response/ | | | 734 | Type=TEAP, | | | 735 | {Result TLV=Success} | | | 736 |--------------------------->| | | 737 | | | | 738 | EAP-Success | | | 739 |<---------------------------| | | 741 8. IANA Considerations 743 [todo] 745 9. Security Considerations 747 [todo] 749 10. Informative References 751 [I-D.friel-acme-subdomains] 752 Friel, O., Barnes, R., and T. Hollebeek, "ACME for 753 Subdomains", draft-friel-acme-subdomains-00 (work in 754 progress), October 2019. 756 [I-D.friel-anima-brski-cloud] 757 Friel, O., Shekh-Yusef, R., and M. Richardson, "BRSKI 758 Cloud Registrar", draft-friel-anima-brski-cloud-01 (work 759 in progress), October 2019. 761 [I-D.ietf-anima-bootstrapping-keyinfra] 762 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 763 and K. Watsen, "Bootstrapping Remote Secure Key 764 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 765 keyinfra-34 (work in progress), January 2020. 767 [I-D.lear-eap-teap-brski] 768 Lear, E., Friel, O., Cam-Winget, N., and D. Harkins, "TEAP 769 Update and Extensions for Bootstrapping", draft-lear-eap- 770 teap-brski-05 (work in progress), November 2019. 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels", BCP 14, RFC 2119, 774 DOI 10.17487/RFC2119, March 1997, 775 . 777 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 778 "Enrollment over Secure Transport", RFC 7030, 779 DOI 10.17487/RFC7030, October 2013, 780 . 782 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 783 "Tunnel Extensible Authentication Protocol (TEAP) Version 784 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 785 . 787 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 788 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 789 May 2017, . 791 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 792 "A Voucher Artifact for Bootstrapping Protocols", 793 RFC 8366, DOI 10.17487/RFC8366, May 2018, 794 . 796 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 797 Kasten, "Automatic Certificate Management Environment 798 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 799 . 801 Appendix A. Comments 803 Authors' Addresses 805 Owen Friel 806 Cisco 808 Email: ofriel@cisco.com 810 Richard Barnes 811 Cisco 813 Email: rlb@ipv.sx 814 Rifaat Shekh-Yusef 815 Avaya 817 Email: rifaat.ietf@gmail.com 819 Michael Richardson 820 Sandelman Software Works 822 Email: mcr+ietf@sandelman.ca