idnits 2.17.00 (12 Aug 2021) /tmp/idnits20303/draft-ietf-anima-brski-ae-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 document date (6 April 2022) is 38 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 (-18) exists of draft-ietf-lamps-cmp-updates-17 == Outdated reference: A later version (-12) exists of draft-ietf-lamps-lightweight-cmp-profile-10 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG D. von Oheimb, Ed. 3 Internet-Draft S. Fries 4 Intended status: Standards Track H. Brockhaus 5 Expires: 8 October 2022 Siemens 6 E. Lear 7 Cisco Systems 8 6 April 2022 10 BRSKI-AE: Alternative Enrollment Protocols in BRSKI 11 draft-ietf-anima-brski-ae-01 13 Abstract 15 This document enhances Bootstrapping Remote Secure Key Infrastructure 16 (BRSKI, RFC 8995) to allow employing alternative enrollment 17 protocols, such as CMP. 19 Using self-contained signed objects, the origin of enrollment 20 requests and responses can be authenticated independently of message 21 transfer. This supports end-to-end security and asynchronous 22 operation of certificate enrollment and provides flexibility where to 23 authenticate and authorize certification requests. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 8 October 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Supported Environment . . . . . . . . . . . . . . . . . . 5 61 1.3. List of Application Examples . . . . . . . . . . . . . . 6 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Requirements and Mapping to Solutions . . . . . . . . . . . . 7 64 3.1. Basic Requirements . . . . . . . . . . . . . . . . . . . 7 65 3.2. Solution Options for Proof-of-possession . . . . . . . . 8 66 3.3. Solution Options for Proof-of-identity . . . . . . . . . 9 67 4. Adaptations to BRSKI . . . . . . . . . . . . . . . . . . . . 10 68 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 10 69 4.2. Message Exchange . . . . . . . . . . . . . . . . . . . . 13 70 4.3. Enhancements to Addressing Scheme . . . . . . . . . . . . 16 71 4.4. Domain Registrar Support of Alternative Enrollment 72 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 16 73 5. Instantiation to Existing Enrollment Protocols . . . . . . . 17 74 5.1. BRSKI-EST-fullCMC: Instantiation to EST (informative) . . 17 75 5.2. BRSKI-CMP: Instantiation to CMP (normative if CMP is 76 chosen) . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 82 9.2. Informative References . . . . . . . . . . . . . . . . . 20 83 Appendix A. Using EST for Certificate Enrollment . . . . . . . . 22 84 Appendix B. Application Examples . . . . . . . . . . . . . . . . 23 85 B.1. Rolling Stock . . . . . . . . . . . . . . . . . . . . . . 23 86 B.2. Building Automation . . . . . . . . . . . . . . . . . . . 23 87 B.3. Substation Automation . . . . . . . . . . . . . . . . . . 24 88 B.4. Electric Vehicle Charging Infrastructure . . . . . . . . 24 89 B.5. Infrastructure Isolation Policy . . . . . . . . . . . . . 24 90 B.6. Sites with Insufficient Level of Operational Security . . 25 91 Appendix C. History of Changes TBD RFC Editor: please delete . . 25 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 94 1. Introduction 96 1.1. Motivation 98 BRSKI, as defined in [RFC8995], specifies a solution for secure 99 automated zero-touch bootstrapping of new devices, so-called pledges. 100 This includes the discovery of the registrar in the target domain, 101 time synchronization, and the exchange of security information 102 necessary to establish mutual trust between pledges and the target 103 domain. 105 A pledge gains trust in the target domain via the domain registrar as 106 follows. It obtains security information about the domain, 107 specifically a domain certificate to be trusted, by requesting a 108 voucher object defined in [RFC8366]. Such a voucher is a self- 109 contained signed object originating from a Manufacturer Authorized 110 Signing Authority (MASA). Therefore, the voucher may be provided in 111 online mode (synchronously) or offline mode (asynchronously). The 112 pledge can authenticate the voucher because it is shipped with a 113 trust anchor of its manufacturer such that it can validate signatures 114 (including related certificates) by the MASA. 116 Trust by the target domain in a pledge is established by providing 117 the pledge with a domain-specific LDevID certificate. The 118 certification request of the pledge is signed using its IDevID secret 119 and can be validated by the target domain using the trust anchor of 120 the pledge manufacturer, which needs to pre-installed in the domain. 122 For enrolling devices with LDevID certificates, BRSKI typically 123 utilizes Enrollment over Secure Transport (EST) [RFC7030]. EST has 124 its specific characteristics, detailed in Appendix A. In particular, 125 it requires online or on-site availability of the RA for performing 126 the data origin authentication and final authorization decision on 127 the certification request. This type of enrollment can be called 128 'synchronous enrollment'. For various reasons, it may be preferable 129 to use alternative enrollment protocols such as the Certificate 130 Management Protocol (CMP) [RFC4210] profiled in 131 [I-D.ietf-lamps-lightweight-cmp-profile] or Certificate Management 132 over CMS (CMC) [RFC5272]. that are more flexible and independent of 133 the transfer mechanism because they represent certification request 134 messages as authenticated self-contained objects. 136 Depending on the application scenario, the required RA/CA components 137 may not be part of the registrar. They even may not be available on- 138 site but rather be provided by remote backend systems. The registrar 139 or its deployment site may not have an online connection with them or 140 the connectivity may be intermittent. This may be due to security 141 requirements for operating the backend systems or due to site 142 deployments where on-site or always-online operation may be not 143 feasible or too costly. In such scenarios, the authentication and 144 authorization of certification requests will not or can not be 145 performed on-site at enrollment time. In this document, enrollment 146 that is not performed in a (time-wise) consistent way is called 147 'asynchronous enrollment'. Asynchronous enrollment requires a store- 148 and-forward transfer of certification requests along with the 149 information needed for authenticating the requester. This allows 150 offline processing the request. 152 Application scenarios may also involve network segmentation, which is 153 utilized in industrial systems to separate domains with different 154 security needs. Such scenarios lead to similar requirements if the 155 TLS connection carrying the requester authentication is terminated 156 and thus request messages need to be forwarded on further channels 157 before the registrar/RA can authorize the certification request. In 158 order to preserve the requester authentication, authentication 159 information needs to be retained and ideally bound directly to the 160 certification request. 162 There are basically two approaches for forwarding certification 163 requests along with requester authentication information: 165 * A trusted component (e.g., a local RA) in the target domain is 166 needed that forwards the certification request combined with the 167 validated identity of the requester (e,g., its IDevID certificate) 168 and an indication of successful verification of the proof-of- 169 possession (of the corresponding private key) in a way preventing 170 changes to the combined information. When connectivity is 171 available, the trusted component forwards the certification 172 request together with the requester information (authentication 173 and proof-of-possession) for further processing. This approach 174 offers only hop-by-hop security. The backend PKI must rely on the 175 local pledge authentication result provided by the local RA when 176 performing the authorization of the certification request. In 177 BRSKI, the EST server is such a trusted component, being co- 178 located with the registrar in the target domain. 180 * Involved components use authenticated self-contained objects for 181 the enrollment, directly binding the certification request and the 182 requester authentication in a cryptographic way. This approach 183 supports end-to-end security, without the need to trust in 184 intermediate domain components. Manipulation of the request and 185 the requester identity information can be detected during the 186 validation of the self-contained signed object. 188 Focus of this document is the support of alternative enrollment 189 protocols that allow using authenticated self-contained objects for 190 device credential bootstrapping. This enhancement of BRSKI is named 191 BRSKI-AE, where AE stands for alternative enrollment protocols and 192 for asynchronous enrollment. This specification carries over the 193 main characteristics of BRSKI, namely that the pledge obtains trust 194 anchor information for authenticating the domain registrar and other 195 target domain components as well as a domain-specific X.509 device 196 certificate (the LDevID certificate) along with the corresponding 197 private key (the LDevID secret) and certificate chain. 199 The goals are to enhance BRSKI to 201 * support alternative enrollment protocols, 203 * support end-to-end security for enrollment, and 205 * make it applicable to scenarios involving asynchronous enrollment. 207 This is achieved by 209 * extending the well-known URI approach with an additional path 210 element indicating the enrollment protocol being used, and 212 * defining a certificate waiting indication and handling, for the 213 case that the certifying component is (temporarily) not available. 215 This specification can be applied to both synchronous and 216 asynchronous enrollment. 218 In contrast to BRSKI, this specification supports offering multiple 219 enrollment protocols on the infrastructure side, which enables 220 pledges and their developers to pick the preferred one. 222 1.2. Supported Environment 224 BRSKI-AE is intended to be used in domains that may have limited 225 support of on-site PKI services and comprises application scenarios 226 like the following. 228 * There are requirements or implementation restrictions that do not 229 allow using EST for enrolling an LDevID certificate. 231 * Pledges and/or the target domain already have an established 232 certificate management approach different from EST that shall be 233 reused (e.g., in brownfield installations). 235 * There is no registration authority available on site in the target 236 domain. Connectivity to an off-site RA is intermittent or 237 entirely offline. A store-and-forward mechanism is used for 238 communicating with the off-site services. 240 * Authoritative actions of a local RA are limited and may not be 241 sufficient for authorizing certification requests by pledges. 242 Final authorization is done by an RA residing in the operator 243 domain. 245 1.3. List of Application Examples 247 Bootstrapping can be handled in various ways, depending on the 248 application domains. The informative Appendix B provides 249 illustrative examples from various industrial control system 250 environments and operational setups. They motivate the support of 251 alternative enrollment protocols, based on the following examples of 252 operational environments: 254 * Rolling stock 256 * Building automation 258 * Electrical substation automation 260 * Electric vehicle charging infrastructures 262 * Infrastructure isolation policy 264 * Sites with insufficient level of operational security 266 2. Terminology 268 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 269 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 270 "OPTIONAL" in this document are to be interpreted as described in 271 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 272 capitals, as shown here. 274 This document relies on the terminology defined in [RFC8995] and 275 [IEEE.802.1AR_2009].The following terms are defined in addition: 277 EE: End entity, in the BRSKI context called pledge. It is the 278 entity that is bootstrapped to the target domain. It holds a 279 public-private key pair, for which it requests a public-key 280 certificate. An identifier for the EE is given as the subject 281 name of the certificate. 283 RA: Registration authority, an optional system component to which a 284 CA delegates certificate management functions such as 285 authenticating requesters and performing authorization checks on 286 certification requests. 288 CA: Certification authority, issues certificates and provides 289 certificate status information. 291 target domain: The set of entities that share a common local trust 292 anchor, independent of where the entities are deployed. 294 site: Describes the locality where an entity, e.g., pledge, 295 registrar, RA, CA, is deployed. Different sites can belong to the 296 same target domain. 298 on-site: Describes a component or service or functionality available 299 in the target deployment site. 301 off-site: Describes a component or service or functionality 302 available in an operator site different from the target deployment 303 site. This may be a central site or a cloud service, to which 304 only a temporary connection is available. 306 asynchronous communication: Describes a time-wise interrupted 307 communication between a pledge (EE) and a registrar or PKI 308 component. 310 synchronous communication: Describes a time-wise uninterrupted 311 communication between a pledge (EE) and a registrar or PKI 312 component. 314 authenticated self-contained object: Describes in this context an 315 object that is cryptographically bound to the IDevID certificate 316 of a pledge. The binding is assumed to be provided through a 317 digital signature of the actual object using the IDevID secret. 319 3. Requirements and Mapping to Solutions 321 3.1. Basic Requirements 323 There were two main drivers for the definition of BRSKI-AE: 325 * The solution architecture may already use or require a certificate 326 management protocol other than EST. Therefore, this other 327 protocol should be usable for requesting LDevID certificates. 329 * The domain registrar may not be the (final) point that 330 authenticates and authorizes certification requests and the pledge 331 may not have a direct connection to it. Therefore, certification 332 requests should be self-contained signed objects. 334 Based on the intended target environment described in Section 1.2 and 335 the application examples described in Appendix B, the following 336 requirements are derived to support authenticated self-contained 337 objects as containers carrying certification requests. 339 At least the following properties are required: 341 * proof-of-possession: demonstrates access to the private key 342 corresponding to the public key contained in a certification 343 request. This is typically achieved by a self-signature using the 344 corresponding private key. 346 * proof-of-identity: provides data origin authentication of the 347 certification request. This typically is achieved by a signature 348 using the IDevID secret of the pledge. 350 The rest of this section gives an incomplete list of solution 351 examples, based on existing technology described in IETF documents: 353 3.2. Solution Options for Proof-of-possession 355 Certification request objects: Certification requests are data 356 structures protecting only the integrity of the contained data and 357 providing proof-of-possession for a (locally generated) private key. 358 Examples for certification request data structures are: 360 * PKCS#10 [RFC2986]. This certification request structure is self- 361 signed to protect its integrity and prove possession of the 362 private key that corresponds to the public key included in the 363 request. 365 * CRMF [RFC4211]. Also this certificate request message format 366 supports integrity protection and proof-of-possession, typically 367 by a self-signature generated over (part of) the structure with 368 the private key corresponding to the included public key. CRMF 369 also supports further proof-of-possession methods for types of 370 keys that do not support any signature algorithm. 372 The integrity protection of certification request fields includes the 373 public key because it is part of the data signed by the corresponding 374 private key. Yet note that for the above examples this is not 375 sufficient to provide data origin authentication, i.e., proof-of- 376 identity. This extra property can be achieved by an additional 377 binding to the IDevID of the pledge. This binding to source 378 authentication supports the authorization decision for the 379 certification request. The binding of data origin authentication to 380 the certification request may be delegated to the protocol used for 381 certificate management. 383 3.3. Solution Options for Proof-of-identity 385 The certification request should be bound to an existing 386 authenticated credential (here, the IDevID certificate) to enable a 387 proof of identity and, based on it, an authorization of the 388 certification request. The binding may be achieved through security 389 options in an underlying transport protocol such as TLS if the 390 authorization of the certification request is (completely) done at 391 the next communication hop. This binding can also be done in a 392 transport-independent way by wrapping the certification request with 393 signature employing an existing IDevID. the BRSKI context, this will 394 be the IDevID. This requirement is addressed by existing enrollment 395 protocols in various ways, such as: 397 * EST [RFC7030] utilizes PKCS#10 to encode the certification 398 request. The Certificate Signing Request (CSR) optionally 399 provides a binding to the underlying TLS session by including the 400 tls-unique value in the self-signed PKCS#10 structure. The tls- 401 unique value results from the TLS handshake. Since the TLS 402 handshake includes client authentication and the pledge utilizes 403 its IDevID for it, the proof-of-identity is provided by such a 404 binding to the TLS session. This can be supported using the EST 405 /simpleenroll endpoint. Note that the binding of the TLS 406 handshake to the CSR is optional in EST. As an alternative to 407 binding to the underlying TLS authentication in the transport 408 layer, [RFC7030] sketches wrapping the CSR with a Full PKI Request 409 message using an existing certificate. 411 * SCEP [RFC8894] supports using a shared secret (passphrase) or an 412 existing certificate to protect CSRs based on SCEP Secure Message 413 Objects using CMS wrapping ([RFC5652]). Note that the wrapping 414 using an existing IDevID in SCEP is referred to as renewal. Thus 415 SCEP does not rely on the security of the underlying transfer. 417 * CMP [RFC4210] supports using a shared secret (passphrase) or an 418 existing certificate, which may be an IDevID credential, to 419 authenticate certification requests via the PKIProtection 420 structure in a PKIMessage. The certification request is typically 421 encoded utilizing CRMF, while PKCS#10 is supported as an 422 alternative. Thus CMP does not rely on the security of the 423 underlying transfer protocol. 425 * CMC [RFC5272] also supports utilizing a shared secret (passphrase) 426 or an existing certificate to protect certification requests, 427 which can be either in CRMF or PKCS#10 structure. The proof-of- 428 identity can be provided as part of a FullCMCRequest, based on CMS 429 [RFC5652] and signed with an existing IDevID secret. Thus CMC 430 does not rely on the security of the underlying transfer protocol. 432 4. Adaptations to BRSKI 434 In order to support alternative enrollment protocols, asynchronous 435 enrollment, and more general system architectures, BRSKI-AE lifts 436 some restrictions of BRSKI [RFC8995]. This way, authenticated self- 437 contained objects such as those described in Section 3 above can be 438 used for certificate enrollment. 440 The enhancements needed are kept to a minimum in order to ensure 441 reuse of already defined architecture elements and interactions. In 442 general, the communication follows the BRSKI model and utilizes the 443 existing BRSKI architecture elements. In particular, the pledge 444 initiates communication with the domain registrar and interacts with 445 the MASA as usual. 447 4.1. Architecture 449 The key element of BRSKI-AE is that the authorization of a 450 certification request MUST be performed based on an authenticated 451 self-contained object. The certification request is bound in a self- 452 contained way to a proof-of-origin based on the IDevID. 453 Consequently, the authentication and authorization of the 454 certification request MAY be done by the domain registrar and/or by 455 other domain components. These components may be offline or reside 456 in some central backend of the domain operator (off-site) as 457 described in Section 1.2. The registrar and other on-site domain 458 components may have no or only temporary (intermittent) connectivity 459 to them. The certification request MAY also be piggybacked on 460 another protocol. 462 This leads to generalizations in the placement and enhancements of 463 the logical elements as shown in Figure 1. 465 +------------------------+ 466 +--------------Drop-Ship--------------->| Vendor Service | 467 | +------------------------+ 468 | | M anufacturer| | 469 | | A uthorized |Ownership| 470 | | S igning |Tracker | 471 | | A uthority | | 472 | +--------------+---------+ 473 | ^ 474 | | 475 V | 476 +--------+ ......................................... | 477 | | . . | BRSKI- 478 | | . +------------+ +------------+ . | MASA 479 | Pledge | . | Join | | Domain <-----+ 480 | | . | Proxy | | Registrar/ | . 481 | <-------->............<-------> Enrollment | . 482 | | . | BRSKI-AE | Proxy/LRA | . 483 | IDevID | . | | +------^-----+ . 484 | | . +------------+ | . 485 | | . | . 486 +--------+ ...............................|......... 487 on-site "domain" components | 488 | e.g., RFC 4210, 489 | RFC 7030, ... 490 .............................................|..................... 491 . +---------------------------+ +--------v------------------+ . 492 . | Public-Key Infrastructure <-----+ Registration Authority | . 493 . | PKI CA +-----> PKI RA | . 494 . +---------------------------+ +---------------------------+ . 495 ................................................................... 496 off-site or central "domain" components 498 Figure 1: Architecture Overview Using Off-site PKI Components 500 The architecture overview in Figure 1 has the same logical elements 501 as BRSKI, but with more flexible placement of the authentication and 502 authorization checks on certification requests. Depending on the 503 application scenario, the registrar MAY still do all of these checks 504 (as is the case in BRSKI), or part of them, or none of them. 506 The following list describes the on-site components in the target 507 domain of the pledge shown in Figure 1. 509 * Join Proxy: same functionality as described in BRSKI [RFC8995]. 511 * Domain Registrar / Enrollment Proxy / LRA: in BRSKI-AE, the domain 512 registrar has mostly the same functionality as in BRSKI, namely to 513 facilitate the communication of the pledge with the MASA and the 514 PKI. Yet in contrast to BRSKI, the registrar offers different 515 enrollment protocols and MAY act as a local registration authority 516 (LRA) or simply as an enrollment proxy. In such cases, the domain 517 registrar forwards the certification request to some off-site RA 518 component, which performs at least part of the authorization. 519 This also covers the case that the registrar has only intermittent 520 connection and forwards the certification request to the RA upon 521 re-established connectivity. 523 Note: To support alternative enrollment protocols, the URI scheme 524 for addressing the domain registrar is generalized (see 525 Section 4.3). 527 The following list describes the components provided by the vendor or 528 manufacturer outside the target domain. 530 * MASA: general functionality as described in BRSKI [RFC8995]. The 531 voucher exchange with the MASA via the domain registrar is 532 performed as described in BRSKI. 534 Note: The interaction with the MASA may be synchronous (voucher 535 request with nonce) or asynchronous (voucher request without 536 nonce). 538 * Ownership tracker: as defined in BRSKI. 540 The following list describes the target domain components that can 541 optionally be operated in the off-site backend of the target domain. 543 * PKI RA: Performs certificate management functions for the domain 544 as a centralized public-key infrastructure for the domain 545 operator. As far as not already done by the domain registrar, it 546 performs the final validation and authorization of certification 547 requests. 549 * PKI CA: Performs certificate generation by signing the certificate 550 structure requested in already authenticated and authorized 551 certification requests. 553 Based on the diagram in Section 2.1 of BRSKI [RFC8995] and the 554 architectural changes, the original protocol flow is divided into 555 three phases showing commonalities and differences to the original 556 approach as follows. 558 * Discovery phase: same as in BRSKI steps (1) and (2) 559 * Voucher exchange phase: same as in BRSKI steps (3) and (4). 561 * Enrollment phase: step (5) is changed to employing an alternative 562 enrollment protocol that uses authenticated self-contained 563 objects. 565 4.2. Message Exchange 567 The behavior of a pledge described in Section 2.1 of BRSKI [RFC8995] 568 is kept with one exception. After finishing the Imprint step (4), 569 the Enroll step (5) MUST be performed with an enrollment protocol 570 utilizing authenticated self-contained objects. Section 5 discusses 571 selected suitable enrollment protocols and options applicable. 573 [ 574 Cannot render SVG graphics - please view 575 https://raw.githubusercontent.com/anima-wg/anima-brski-ae/main/o.png 576 ] 578 Figure 2: BRSKI-AE Abstract Protocol Overview 580 *Pledge - registrar discovery and voucher exchange* 582 The discovery phase and voucher exchange are applied as specified in 583 [RFC8995]. 585 *Registrar - MASA voucher exchange* 587 This voucher exchange is performed as specified in [RFC8995]. 589 *Pledge - registrar - RA/CA certificate enrollment* 591 As stated in Section 3, the enrollment MUST be performed using an 592 authenticated self-contained object providing not only proof-of- 593 possession but also proof-of-identity (source authentication). 595 +--------+ +------------+ +------------+ 596 | Pledge | | Domain | | Operator | 597 | | | Registrar | | RA/CA | 598 | | | (JRC) | | (PKI) | 599 +--------+ +------------+ +------------+ 600 /--> | | 601 [Optional request of CA certificates] | | 602 |---------- CA Certs Request ------------>| | 603 | [if connection to operator domain is available] | 604 | |-- CA Certs Request -->| 605 | |<- CA Certs Response --| 606 |<--------- CA Certs Response ------------| | 607 /--> | | 608 [Optional request of attributes to include in Certificate Request] | 609 |---------- Attribute Request ----------->| | 610 | [if connection to operator domain is available] | 611 | |- Attribute Request -->| 612 | |<- Attribute Response -| 613 |<--------- Attribute Response -----------| | 614 /--> | | 615 [Mandatory certificate request] | | 616 |---------- Certificate Request --------->| | 617 | [if connection to operator domain is available] | 618 | |-Certificate Request ->| 619 | |<- Certificate Resp. --| 620 |<--------- Certificate Response ---------| | 621 /--> | | 622 [Optional certificate confirmation] | | 623 |---------- Certificate Confirm --------->| | 624 | [if connection to operator domain is available] | 625 | |-Certificate Confirm ->| 626 | |<---- PKI Confirm -----| 627 |<--------- PKI/Registrar Confirm --------| | 629 Figure 3: Certificate Enrollment 631 The following list provides an abstract description of the flow 632 depicted in Figure 3. 634 * CA Certs Request: The pledge optionally requests the latest 635 relevant CA certificates. This ensures that the pledge has the 636 complete set of current CA certificates beyond the pinned-domain- 637 cert (which is contained in the voucher and may be just the domain 638 registrar certificate). 640 * CA Certs Response: It MUST contain the current root CA 641 certificate, which typically is the LDevID trust anchor, and any 642 additional certificates that the pledge may need to validate 643 certificates. 645 * Attribute Request: Typically, the automated bootstrapping occurs 646 without local administrative configuration of the pledge. 647 Nevertheless, there are cases in which the pledge may also include 648 additional attributes specific to the target domain into the 649 certification request. To get these attributes in advance, the 650 attribute request can be used. 652 * Attribute Response: It MUST contain the attributes to be included 653 in the subsequent certification request. 655 * Certificate Request: This certification request MUST contain the 656 authenticated self-contained object ensuring both proof-of- 657 possession of the corresponding private key and proof-of-identity 658 of the requester. 660 * Certificate Response: The certification response message MUST 661 contain on success the requested certificate and MAY include 662 further information, like certificates of intermediate CAs. 664 * Certificate Confirm: An optional confirmation sent after the 665 requested certificate has been received and validated. It 666 contains a positive or negative confirmation by the pledge whether 667 the certificate was successfully enrolled and fits its needs. 669 * PKI/Registrar Confirm: An acknowledgment by the PKI or registrar 670 that MUST be sent on reception of the Cert Confirm. 672 The generic messages described above may be implemented using various 673 enrollment protocols supporting authenticated self-contained objects, 674 as described in Section 3. Examples are available in Section 5. 676 *Pledge - registrar - enrollment status telemetry* 678 The enrollment status telemetry is performed as specified in 679 [RFC8995]. In BRSKI this is described as part of the enrollment 680 phase, but due to the generalization on the enrollment protocol 681 described in this document it fits better as a separate step here. 683 4.3. Enhancements to Addressing Scheme 685 BRSKI-AE provides generalizations to the addressing scheme defined in 686 BRSKI [RFC8995] to accommodate alternative enrollment protocols that 687 use authenticated self-contained objects for certification requests. 688 As this is supported by various existing enrollment protocols, they 689 can be directly employed (see also Section 5). 691 The addressing scheme in BRSKI for certification requests and the 692 related CA certificates and CSR attributes retrieval functions uses 693 the definition from EST [RFC7030]; here on the example of simple 694 enrollment: "/.well-known/est/simpleenroll". This approach is 695 generalized to the following notation: "/.well-known//" in which refers to a 697 certificate enrollment protocol. Note that enrollment is considered 698 here a message sequence that contains at least a certification 699 request and a certification response. The following conventions are 700 used in order to provide maximal compatibility to BRSKI: 702 * : MUST reference the protocol being used, 703 which MAY be CMP, CMC, SCEP, EST [RFC7030] as in BRSKI, or a newly 704 defined approach. 706 Note: additional endpoints (well-known URIs) at the registrar may 707 need to be defined by the enrollment protocol being used. 709 * : if present, the path component MUST describe, 710 depending on the enrollment protocol being used, the operation 711 requested. Enrollment protocols are expected to define their 712 request endpoints, as done by existing protocols (see also 713 Section 5). 715 4.4. Domain Registrar Support of Alternative Enrollment Protocols 717 Well-known URIs for various endpoints on the domain registrar are 718 already defined as part of the base BRSKI specification or indirectly 719 by EST. In addition, alternative enrollment endpoints MAY be 720 supported at the registrar. The pledge will recognize whether its 721 preferred enrollment option is supported by the domain registrar by 722 sending a request to its preferred enrollment endpoint and evaluating 723 the HTTP response status code. 725 The following list of endpoints provides an illustrative example for 726 a domain registrar supporting several options for EST as well as for 727 CMP to be used in BRSKI-AE. The listing contains the supported 728 endpoints to which the pledge may connect for bootstrapping. This 729 includes the voucher handling as well as the enrollment endpoints. 730 The CMP related enrollment endpoints are defined as well-known URIs 731 in CMP Updates [I-D.ietf-lamps-cmp-updates] and the Lightweight CMP 732 profile [I-D.ietf-lamps-lightweight-cmp-profile]. 734 ,ct=voucher-cms+json 735 ,ct=json 736 ,ct=json 737 ;ct=pkcs7-mime 738 ;ct=pkcs7-mime 739 ;ct=pkcs7-mime 740 ;ct=pkixcmp 741 ;ct=pkixcmp 742 ;ct=pkixcmp 743 ;ct=pkixcmp 745 5. Instantiation to Existing Enrollment Protocols 747 This section maps the requirements to support proof-of-possession and 748 proof-of-identity to selected existing enrollment protocols handles 749 provides further aspects of instantiating them in BRSKI-AE. 751 5.1. BRSKI-EST-fullCMC: Instantiation to EST (informative) 753 When using EST [RFC7030], the following aspects and constraints need 754 to be considered and the given extra requirements need to be 755 fulfilled, which adapt Section 5.9.3 of BRSKI [RFC8995]: 757 * proof-of-possession is provided typically by using the specified 758 PKCS#10 structure in the request. Together with Full PKI 759 requests, also CRMF can be used. 761 * proof-of-identity needs to be achieved by signing the 762 certification request object using the Full PKI Request option 763 (including the /fullcmc endpoint). This provides sufficient 764 information for the RA to authenticate the pledge as the origin of 765 the request and to make an authorization decision on the received 766 certification request. Note: EST references CMC [RFC5272] for the 767 definition of the Full PKI Request. For proof-of-identity, the 768 signature of the SignedData of the Full PKI Request is performed 769 using the IDevID secret of the pledge. 771 Note: In this case the binding to the underlying TLS connection is 772 not necessary. 774 * When the RA is temporarily not available, as per Section 4.2.3 of 775 [RFC7030], an HTTP status code 202 should be returned by the 776 registrar, and the pledge will repeat the initial Full PKI Request 778 5.2. BRSKI-CMP: Instantiation to CMP (normative if CMP is chosen) 780 Note: Instead of referring to CMP as specified in [RFC4210] and 781 [I-D.ietf-lamps-cmp-updates], this document refers to the Lightweight 782 CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile] because the 783 subset of CMP defined there is sufficient for the functionality 784 needed here. 786 When using CMP, the following specific implementation requirements 787 apply (cf. Figure 3). 789 * CA Certs Request 791 - Requesting CA certificates over CMP is OPTIONAL. 792 If supported, it SHALL be implemented as specified in 793 Section 4.3.1 of [I-D.ietf-lamps-lightweight-cmp-profile]. 795 * Attribute Request 797 - Requesting certificate request attributes over CMP is OPTIONAL. 798 If supported, it SHALL be implemented as specified in 799 Section 4.3.3 of [I-D.ietf-lamps-lightweight-cmp-profile]. 800 Note that alternatively the registrar MAY modify the contents 801 of requested certificate contents as specified in 802 Section 5.2.3.2 of [I-D.ietf-lamps-lightweight-cmp-profile]. 804 * Certificate Request 806 - Proof-of-possession SHALL be provided as defined in 807 Section 4.1.1 (based on CRMF) or Section 4.1.4 (based on 808 PKCS#10) of the Lightweight CMP Profile 809 [I-D.ietf-lamps-lightweight-cmp-profile]. 810 The caPubs field of certificate response messages SHOULD NOT be 811 used. 813 - Proof-of-identity SHALL be provided by using signature-based 814 protection of the certification request message as outlined in 815 Section 3.2. of [I-D.ietf-lamps-lightweight-cmp-profile] using 816 the IDevID secret. 818 * Certificate Confirm 819 - Explicit confirmation of new certificates to the RA MAY be used 820 as specified in Section 4.1.1 of the Lightweight CMP Profile 821 [I-D.ietf-lamps-lightweight-cmp-profile]. 822 Note that independently of certificate confirmation within CMP, 823 enrollment status telemetry with the registrar will be 824 performed as described in Section 5.9.4 of BRSKI [RFC8995]. 826 * If delayed delivery of responses (for instance, to support 827 asynchronous enrollment) within CMP is needed, it SHALL be 828 performed as specified in Sections 4.4 and 5.1.2 of 829 [I-D.ietf-lamps-lightweight-cmp-profile]. 831 6. IANA Considerations 833 This document does not require IANA actions. 835 7. Security Considerations 837 The security considerations as laid out in BRSKI [RFC8995] apply for 838 the discovery and voucher exchange as well as for the status exchange 839 information. 841 The security considerations as laid out in the Lightweight CMP 842 Profile [I-D.ietf-lamps-lightweight-cmp-profile] apply as far as CMP 843 is used. 845 8. Acknowledgments 847 We would like to thank Brian E. Carpenter, Michael Richardson, and 848 Giorgio Romanenghi for their input and discussion on use cases and 849 call flows. 851 9. References 853 9.1. Normative References 855 [I-D.ietf-lamps-cmp-updates] 856 Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate 857 Management Protocol (CMP) Updates", Work in Progress, 858 Internet-Draft, draft-ietf-lamps-cmp-updates-17, 12 859 January 2022, . 862 [I-D.ietf-lamps-lightweight-cmp-profile] 863 Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight 864 Certificate Management Protocol (CMP) Profile", Work in 865 Progress, Internet-Draft, draft-ietf-lamps-lightweight- 866 cmp-profile-10, 1 February 2022, 867 . 870 [IEEE.802.1AR_2009] 871 IEEE, "IEEE Standard for Local and metropolitan area 872 networks - Secure Device Identity", IEEE 802.1AR-2009, 873 DOI 10.1109/ieeestd.2009.5367679, 28 December 2009, 874 . 877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, 879 DOI 10.17487/RFC2119, March 1997, 880 . 882 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 883 "Internet X.509 Public Key Infrastructure Certificate 884 Management Protocol (CMP)", RFC 4210, 885 DOI 10.17487/RFC4210, September 2005, 886 . 888 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 889 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 890 May 2017, . 892 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 893 "A Voucher Artifact for Bootstrapping Protocols", 894 RFC 8366, DOI 10.17487/RFC8366, May 2018, 895 . 897 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 898 and K. Watsen, "Bootstrapping Remote Secure Key 899 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 900 May 2021, . 902 9.2. Informative References 904 [IEC-62351-9] 905 International Electrotechnical Commission, "IEC 62351 - 906 Power systems management and associated information 907 exchange - Data and communications security - Part 9: 908 Cyber security key management for power system equipment", 909 IEC 62351-9, May 2017. 911 [ISO-IEC-15118-2] 912 International Standardization Organization / International 913 Electrotechnical Commission, "ISO/IEC 15118-2 Road 914 vehicles - Vehicle-to-Grid Communication Interface - Part 915 2: Network and application protocol requirements", ISO/ 916 IEC 15118-2, April 2014. 918 [NERC-CIP-005-5] 919 North American Reliability Council, "Cyber Security - 920 Electronic Security Perimeter", CIP 005-5, December 2013. 922 [OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0.1 923 (Draft)", December 2019. 925 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 926 Request Syntax Specification Version 1.7", RFC 2986, 927 DOI 10.17487/RFC2986, November 2000, 928 . 930 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 931 Certificate Request Message Format (CRMF)", RFC 4211, 932 DOI 10.17487/RFC4211, September 2005, 933 . 935 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 936 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 937 . 939 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 940 RFC 5652, DOI 10.17487/RFC5652, September 2009, 941 . 943 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 944 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, 945 . 947 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 948 "Enrollment over Secure Transport", RFC 7030, 949 DOI 10.17487/RFC7030, October 2013, 950 . 952 [RFC8894] Gutmann, P., "Simple Certificate Enrolment Protocol", 953 RFC 8894, DOI 10.17487/RFC8894, September 2020, 954 . 956 [UNISIG-Subset-137] 957 UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 958 FFFIS; V1.0.0", December 2015, 959 . 963 http://www.kmc-subset137.eu/index.php/download/ 965 Appendix A. Using EST for Certificate Enrollment 967 When using EST with BRSKI, pledges interact via TLS with the domain 968 registrar, which acts both as EST server and as registration 969 authority (RA). The TLS connection is mutually authenticated, where 970 the pledge uses its IDevID certificate issued by its manufacturer. 972 In order to provide a strong proof-of-origin of the certification 973 request, EST has the option to include in the certification request 974 the so-called tls-unique value [RFC5929] of the underlying TLS 975 channel. This binding of the proof-of-identity of the TLS client, 976 which is supposed to be the certificate requester, to the proof-of- 977 possession for the private key is conceptually non-trivial and 978 requires specific support by TLS implementations. 980 The registrar terminates the security association with the pledge at 981 TLS level and thus the binding between the certification request and 982 the authentication of the pledge. The EST server uses the 983 authenticated pledge identity provided by the IDevID for checking the 984 authorization of the pledge for the given certification request 985 before issuing to the pledge a domain-specific certificate (LDevID 986 certificate). This approach typically requires online or on-site 987 availability of the RA for performing the final authorization 988 decision for the certification request. 990 Using EST for BRSKI has the advantage that the mutually authenticated 991 TLS connection established between the pledge and the registrar can 992 be reused for protecting the message exchange needed for enrolling 993 the LDevID certificate. This strongly simplifies the implementation 994 of the enrollment message exchange. 996 Yet the use of TLS has the limitation that this cannot provide 997 auditability nor end-to-end security for the certificate enrollment 998 request because the TLS session is transient and terminates at the 999 registrar. This is a problem in particular if the enrollment is done 1000 via multiple hops, part of which may not even be network-based. 1002 A further limitation of using EST as the certificate enrollment 1003 protocol is that due to using PKCS#10 structures in enrollment 1004 requests, the only possible proof-of-possession method is a self- 1005 signature, which excludes requesting certificates for key types that 1006 do not support signing. 1008 Appendix B. Application Examples 1010 This informative annex provides some detail to the application 1011 examples listed in Section 1.3. 1013 B.1. Rolling Stock 1015 Rolling stock or railroad cars contain a variety of sensors, 1016 actuators, and controllers, which communicate within the railroad car 1017 but also exchange information between railroad cars building a train, 1018 with track-side equipment, and/or possibly with backend systems. 1019 These devices are typically unaware of backend system connectivity. 1020 Managing certificates may be done during maintenance cycles of the 1021 railroad car, but can already be prepared during operation. 1022 Preparation will include generating certification requests, which are 1023 collected and later forwarded for processing, once the railroad car 1024 is connected to the operator backend. The authorization of the 1025 certification request is then done based on the operator's asset/ 1026 inventory information in the backend. 1028 UNISIG has included a CMP profile for enrollment of TLS certificates 1029 of on-board and track-side components in the Subset-137 specifying 1030 the ETRAM/ETCS on-line key management for train control systems 1031 [UNISIG-Subset-137]. 1033 B.2. Building Automation 1035 In building automation scenarios, a detached building or the basement 1036 of a building may be equipped with sensors, actuators, and 1037 controllers that are connected with each other in a local network but 1038 with only limited or no connectivity to a central building management 1039 system. This problem may occur during installation time but also 1040 during operation. In such a situation a service technician collects 1041 the necessary data and transfers it between the local network and the 1042 central building management system, e.g., using a laptop or a mobile 1043 phone. This data may comprise parameters and settings required in 1044 the operational phase of the sensors/actuators, like a component 1045 certificate issued by the operator to authenticate against other 1046 components and services. 1048 The collected data may be provided by a domain registrar already 1049 existing in the local network. In this case connectivity to the 1050 backend PKI may be facilitated by the service technician's laptop. 1051 Alternatively, the data can also be collected from the pledges 1052 directly and provided to a domain registrar deployed in a different 1053 network as preparation for the operational phase. In this case, 1054 connectivity to the domain registrar may also be facilitated by the 1055 service technician's laptop. 1057 B.3. Substation Automation 1059 In electrical substation automation scenarios, a control center 1060 typically hosts PKI services to issue certificates for Intelligent 1061 Electronic Devices (IEDs) operated in a substation. Communication 1062 between the substation and control center is performed through a 1063 proxy/gateway/DMZ, which terminates protocol flows. Note that 1064 [NERC-CIP-005-5] requires inspection of protocols at the boundary of 1065 a security perimeter (the substation in this case). In addition, 1066 security management in substation automation assumes central support 1067 of several enrollment protocols in order to support the various 1068 capabilities of IEDs from different vendors. The IEC standard 1069 IEC62351-9 [IEC-62351-9] specifies mandatory support of two 1070 enrollment protocols: SCEP [RFC8894] and EST [RFC7030] for the 1071 infrastructure side, while the IED must only support one of the two. 1073 B.4. Electric Vehicle Charging Infrastructure 1075 For electric vehicle charging infrastructure, protocols have been 1076 defined for the interaction between the electric vehicle and the 1077 charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as 1078 between the charging point and the charging point operator (e.g. 1079 OCPP [OCPP]). Depending on the authentication model, unilateral or 1080 mutual authentication is required. In both cases the charging point 1081 uses an X.509 certificate to authenticate itself in TLS connections 1082 between the electric vehicle and the charging point. The management 1083 of this certificate depends, among others, on the selected backend 1084 connectivity protocol. In the case of OCPP, this protocol is meant 1085 to be the only communication protocol between the charging point and 1086 the backend, carrying all information to control the charging 1087 operations and maintain the charging point itself. This means that 1088 the certificate management needs to be handled in-band of OCPP. This 1089 requires the ability to encapsulate the certificate management 1090 messages in a transport-independent way. Authenticated self- 1091 containment will support this by allowing the transport without a 1092 separate enrollment protocol, binding the messages to the identity of 1093 the communicating endpoints. 1095 B.5. Infrastructure Isolation Policy 1097 This refers to any case in which network infrastructure is normally 1098 isolated from the Internet as a matter of policy, most likely for 1099 security reasons. In such a case, limited access to external PKI 1100 services will be allowed in carefully controlled short periods of 1101 time, for example when a batch of new devices is deployed, and 1102 forbidden or prevented at other times. 1104 B.6. Sites with Insufficient Level of Operational Security 1106 The registration authority performing (at least part of) the 1107 authorization of a certification request is a critical PKI component 1108 and therefore requires higher operational security than components 1109 utilizing the issued certificates for their security features. CAs 1110 may also demand higher security in the registration procedures. 1111 Especially the CA/Browser forum currently increases the security 1112 requirements in the certificate issuance procedures for publicly 1113 trusted certificates. In case the on-site components of the target 1114 domain cannot be operated securely enough for the needs of a 1115 registration authority, this service should be transferred to an off- 1116 site backend component that has a sufficient level of security. 1118 Appendix C. History of Changes TBD RFC Editor: please delete 1120 From IETF draft 06 -> IETF draft 06: 1122 * Renamed the repo and files from anima-brski-async-enroll to anima- 1123 brski-ae 1125 * Added graphics for abstract protocol overview as suggested by 1126 Toerless Eckert 1128 * Balanced (sub-)sections and their headers 1130 * Added details on CMP instance, now called BRSKI-CMP 1132 From IETF draft 04 -> IETF draft 05: 1134 * David von Oheimb became the editor. 1136 * Streamline wording, consolidate terminology, improve grammar, etc. 1138 * Shift the emphasis towards supporting alternative enrollment 1139 protocols. 1141 * Update the title accordingly - preliminary change to be approved. 1143 * Move comments on EST and detailed application examples to 1144 informative annex. 1146 * Move the remaining text of section 3 as two new sub-sections of 1147 section 1. 1149 From IETF draft 03 -> IETF draft 04: 1151 * Moved UC2 related parts defining the pledge in responder mode to a 1152 separate document. This required changes and adaptations in 1153 several sections. Main changes concerned the removal of the 1154 subsection for UC2 as well as the removal of the YANG model 1155 related text as it is not applicable in UC1. 1157 * Updated references to the Lightweight CMP Profile. 1159 * Added David von Oheimb as co-author. 1161 From IETF draft 02 -> IETF draft 03: 1163 * Housekeeping, deleted open issue regarding YANG voucher-request in 1164 UC2 as voucher-request was enhanced with additional leaf. 1166 * Included open issues in YANG model in UC2 regarding assertion 1167 value agent-proximity and CSR encapsulation using SZTP sub 1168 module). 1170 From IETF draft 01 -> IETF draft 02: 1172 * Defined call flow and objects for interactions in UC2. Object 1173 format based on draft for JOSE signed voucher artifacts and 1174 aligned the remaining objects with this approach in UC2 . 1176 * Terminology change: issue #2 pledge-agent -> registrar-agent to 1177 better underline agent relation. 1179 * Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode 1180 and pledge-responder-mode to better address the pledge operation. 1182 * Communication approach between pledge and registrar-agent changed 1183 by removing TLS-PSK (former section TLS establishment) and 1184 associated references to other drafts in favor of relying on 1185 higher layer exchange of signed data objects. These data objects 1186 are included also in the pledge-voucher-request and lead to an 1187 extension of the YANG module for the voucher-request (issue #12). 1189 * Details on trust relationship between registrar-agent and 1190 registrar (issue #4, #5, #9) included in UC2. 1192 * Recommendation regarding short-lived certificates for registrar- 1193 agent authentication towards registrar (issue #7) in the security 1194 considerations. 1196 * Introduction of reference to agent signing certificate using SKID 1197 in agent signed data (issue #11). 1199 * Enhanced objects in exchanges between pledge and registrar-agent 1200 to allow the registrar to verify agent-proximity to the pledge 1201 (issue #1) in UC2. 1203 * Details on trust relationship between registrar-agent and pledge 1204 (issue #5) included in UC2. 1206 * Split of use case 2 call flow into sub sections in UC2. 1208 From IETF draft 00 -> IETF draft 01: 1210 * Update of scope in Section 1.2 to include in which the pledge acts 1211 as a server. This is one main motivation for use case 2. 1213 * Rework of use case 2 to consider the transport between the pledge 1214 and the pledge-agent. Addressed is the TLS channel establishment 1215 between the pledge-agent and the pledge as well as the endpoint 1216 definition on the pledge. 1218 * First description of exchanged object types (needs more work) 1220 * Clarification in discovery options for enrollment endpoints at the 1221 domain registrar based on well-known endpoints in Section 4.4 do 1222 not result in additional /.well-known URIs. Update of the 1223 illustrative example. Note that the change to /brski for the 1224 voucher related endpoints has been taken over in the BRSKI main 1225 document. 1227 * Updated references. 1229 * Included Thomas Werner as additional author for the document. 1231 From individual version 03 -> IETF draft 00: 1233 * Inclusion of discovery options of enrollment endpoints at the 1234 domain registrar based on well-known endpoints in Section 4.4 as 1235 replacement of section 5.1.3 in the individual draft. This is 1236 intended to support both use cases in the document. An 1237 illustrative example is provided. 1239 * Missing details provided for the description and call flow in 1240 pledge-agent use case UC2, e.g. to accommodate distribution of CA 1241 certificates. 1243 * Updated CMP example in Section 5 to use Lightweight CMP instead of 1244 CMP, as the draft already provides the necessary /.well-known 1245 endpoints. 1247 * Requirements discussion moved to separate section in Section 3. 1248 Shortened description of proof of identity binding and mapping to 1249 existing protocols. 1251 * Removal of copied call flows for voucher exchange and registrar 1252 discovery flow from [RFC8995] in Section 4 to avoid doubling or 1253 text or inconsistencies. 1255 * Reworked abstract and introduction to be more crisp regarding the 1256 targeted solution. Several structural changes in the document to 1257 have a better distinction between requirements, use case 1258 description, and solution description as separate sections. 1259 History moved to appendix. 1261 From individual version 02 -> 03: 1263 * Update of terminology from self-contained to authenticated self- 1264 contained object to be consistent in the wording and to underline 1265 the protection of the object with an existing credential. Note 1266 that the naming of this object may be discussed. An alternative 1267 name may be attestation object. 1269 * Simplification of the architecture approach for the initial use 1270 case having an offsite PKI. 1272 * Introduction of a new use case utilizing authenticated self- 1273 contain objects to onboard a pledge using a commissioning tool 1274 containing a pledge-agent. This requires additional changes in 1275 the BRSKI call flow sequence and led to changes in the 1276 introduction, the application example,and also in the related 1277 BRSKI-AE call flow. 1279 * Update of provided examples of the addressing approach used in 1280 BRSKI to allow for support of multiple enrollment protocols in 1281 Section 4.3. 1283 From individual version 01 -> 02: 1285 * Update of introduction text to clearly relate to the usage of 1286 IDevID and LDevID. 1288 * Definition of the addressing approach used in BRSKI to allow for 1289 support of multiple enrollment protocols in Section 4.3. This 1290 section also contains a first discussion of an optional discovery 1291 mechanism to address situations in which the registrar supports 1292 more than one enrollment approach. Discovery should avoid that 1293 the pledge performs a trial and error of enrollment protocols. 1295 * Update of description of architecture elements and changes to 1296 BRSKI in Section 4.1. 1298 * Enhanced consideration of existing enrollment protocols in the 1299 context of mapping the requirements to existing solutions in 1300 Section 3 and in Section 5. 1302 From individual version 00 -> 01: 1304 * Update of examples, specifically for building automation as well 1305 as two new application use cases in Appendix B. 1307 * Deletion of asynchronous interaction with MASA to not complicate 1308 the use case. Note that the voucher exchange can already be 1309 handled in an asynchronous manner and is therefore not considered 1310 further. This resulted in removal of the alternative path the 1311 MASA in Figure 1 and the associated description in Section 4.1. 1313 * Enhancement of description of architecture elements and changes to 1314 BRSKI in Section 4.1. 1316 * Consideration of existing enrollment protocols in the context of 1317 mapping the requirements to existing solutions in Section 3. 1319 * New section starting Section 5 with the mapping to existing 1320 enrollment protocols by collecting boundary conditions. 1322 Authors' Addresses 1324 David von Oheimb (editor) 1325 Siemens AG 1326 Otto-Hahn-Ring 6 1327 81739 Munich 1328 Germany 1329 Email: david.von.oheimb@siemens.com 1330 URI: https://www.siemens.com/ 1332 Steffen Fries 1333 Siemens AG 1334 Otto-Hahn-Ring 6 1335 81739 Munich 1336 Germany 1337 Email: steffen.fries@siemens.com 1338 URI: https://www.siemens.com/ 1339 Hendrik Brockhaus 1340 Siemens AG 1341 Otto-Hahn-Ring 6 1342 81739 Munich 1343 Germany 1344 Email: hendrik.brockhaus@siemens.com 1345 URI: https://www.siemens.com/ 1347 Eliot Lear 1348 Cisco Systems 1349 Richtistrasse 7 1350 CH-8304 Wallisellen 1351 Switzerland 1352 Phone: +41 44 878 9200 1353 Email: lear@cisco.com