idnits 2.17.1 draft-ietf-anima-brski-async-enroll-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8995]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2328 has weird spacing: '...ocument descr...' -- The document date (June 24, 2021) is 1036 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'THISRFC' is mentioned on line 2333, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-netconf-sztp-csr-03 == Outdated reference: A later version (-02) exists of draft-richardson-anima-jose-voucher-01 == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-10 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-05 == Outdated reference: A later version (-06) exists of draft-selander-ace-coap-est-oscore-05 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG S. Fries 3 Internet-Draft H. Brockhaus 4 Intended status: Standards Track Siemens 5 Expires: December 26, 2021 E. Lear 6 Cisco Systems 7 T. Werner 8 Siemens 9 June 24, 2021 11 Support of asynchronous Enrollment in BRSKI (BRSKI-AE) 12 draft-ietf-anima-brski-async-enroll-03 14 Abstract 16 This document describes enhancements of bootstrapping a remote secure 17 key infrastructure (BRSKI, [RFC8995] ) to also operate in domains 18 featuring no or only timely limited connectivity between involved 19 components. Further enhancements are provided to perform the BRSKI 20 approach in environments, in which the role of the pledge changes 21 from a client to a server . This changes the interaction model from a 22 pledge-initiator-mode to a pledge-responder-mode. To support both 23 use cases, BRSKI-AE relies on the exchange of authenticated self- 24 contained objects (signature-wrapped objects) also for requesting and 25 distributing of domain specific device certificates. The defined 26 approach is agnostic regarding the utilized enrollment protocol 27 allowing the application of existing and potentially new certificate 28 management protocols. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 26, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Scope of solution . . . . . . . . . . . . . . . . . . . . . . 7 67 3.1. Supported environment . . . . . . . . . . . . . . . . . . 7 68 3.2. Application Examples . . . . . . . . . . . . . . . . . . 7 69 3.2.1. Rolling stock . . . . . . . . . . . . . . . . . . . . 7 70 3.2.2. Building automation . . . . . . . . . . . . . . . . . 8 71 3.2.3. Substation automation . . . . . . . . . . . . . . . . 8 72 3.2.4. Electric vehicle charging infrastructure . . . . . . 9 73 3.2.5. Infrastructure isolation policy . . . . . . . . . . . 9 74 3.2.6. Less operational security in the target domain . . . 9 75 4. Requirement discussion and mapping to solution elements . . . 10 76 5. Architectural Overview and Communication Exchanges . . . . . 12 77 5.1. Use Case 1 (pledge-initiator-mode): Support of off-site 78 PKI service . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.1.1. Behavior of a pledge . . . . . . . . . . . . . . . . 16 80 5.1.2. Pledge - Registrar discovery and voucher exchange . . 16 81 5.1.3. Registrar - MASA voucher exchange . . . . . . . . . . 16 82 5.1.4. Pledge - Registrar - RA/CA certificate enrollment . . 16 83 5.1.5. Addressing Scheme Enhancements . . . . . . . . . . . 19 84 5.2. Use Case 2 (pledge-responder-mode): Registrar-agent 85 communication with Pledges . . . . . . . . . . . . . . . 19 86 5.2.1. Behavior of a pledge in pledge-responder-mode . . . . 23 87 5.2.2. Behavior of a registrar-agent . . . . . . . . . . . . 23 88 5.2.3. Bootstrapping objects and corresponding exchanges . . 25 89 5.3. Domain registrar support of different enrollment options 47 90 6. YANG Extensions to Voucher Request . . . . . . . . . . . . . 48 91 7. Example for signature-wrapping using existing enrollment 92 protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 51 93 7.1. EST Handling . . . . . . . . . . . . . . . . . . . . . . 51 94 7.2. CMP Handling . . . . . . . . . . . . . . . . . . . . . . 52 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 97 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 53 98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 53 99 10.1. Exhaustion attack on pledge . . . . . . . . . . . . . . 53 100 10.2. Misuse of acquired voucher and enrollment responses . . 53 101 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 103 12.1. Normative References . . . . . . . . . . . . . . . . . . 54 104 12.2. Informative References . . . . . . . . . . . . . . . . . 55 105 Appendix A. History of changes [RFC Editor: please delete] . . . 56 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 108 1. Introduction 110 BRSKI as defined in [RFC8995] specifies a solution for secure zero- 111 touch (automated) bootstrapping of devices (pledges) in a (customer) 112 site domain. This includes the discovery of network elements in the 113 target domain, time synchronization, and the exchange of security 114 information necessary to establish trust between a pledge and the 115 domain. Security information about the target domain, specifically 116 the target domain certificate, is exchanged utilizing voucher objects 117 as defined in [RFC8366]. These vouchers are authenticated self- 118 contained (signed) objects, which may be provided online 119 (synchronous) or offline (asynchronous) via the domain registrar to 120 the pledge and originate from a Manufacturer's Authorized Signing 121 Authority (MASA). 123 For the enrollment of devices BRSKI relies on EST [RFC7030] to 124 request and distribute target domain specific device certificates. 125 EST in turn relies on a binding of the certification request to an 126 underlying TLS connection between the EST client and the EST server. 127 According to BRSKI the domain registrar acts as EST server and is 128 also acting as registration authority (RA) or local registration 129 authority (LRA). The binding to TLS is used to protect the exchange 130 of a certification request (for a LDevID EE certificate) and to 131 provide data origin authentication (client identity information), to 132 support the authorization decision for processing the certification 133 request. The TLS connection is mutually authenticated and the 134 client-side authentication utilizes the pledge's manufacturer issued 135 device certificate (IDevID certificate). This approach requires an 136 on-site availability of a local asset or inventory management system 137 performing the authorization decision based on tuple of the 138 certification request and the pledge authentication using the IDevID 139 certificate, to issue a domain specific certificate to the pledge. 140 The EST server (the domain registrar) terminates the security 141 association with the pledge and thus the binding between the 142 certification request and the authentication of the pledge via TLS. 144 This type of enrollment utilizing an online connection to the PKI is 145 considered as synchronous enrollment. 147 For certain use cases on-site support of a RA/CA component and/or an 148 asset management is not available and rather provided by an 149 operator's backend and may be provided timely limited or completely 150 through offline interactions. This may be due to higher security 151 requirements for operating the certification authority or for 152 optimization of operation for smaller deployments to avoid the always 153 on-site operation. The authorization of a certification request 154 based on an asset management in this case will not / can not be 155 performed on-site at enrollment time. Enrollment, which cannot be 156 performed in a (timely) consistent fashion is considered as 157 asynchronous enrollment in this document. It requires the support of 158 a store and forward functionality of certification request together 159 with the requester authentication (and identity) information. This 160 enables processing of the request at a later point in time. A 161 similar situation may occur through network segmentation, which is 162 utilized in industrial systems to separate domains with different 163 security needs. Here, a similar requirement arises if the 164 communication channel carrying the requester authentication is 165 terminated before the RA/CA authorization handling of the 166 certification request. If a second communication channel is opened 167 to forward the certification request to the issuing RA/ CA, the 168 requester authentication information needs to be retained and ideally 169 bound to the certification request. This uses case is independent 170 from timely limitations of the first use case. For both cases, it is 171 assumed that the requester authentication information is utilized in 172 the process of authorization of a certification request. There are 173 different options to perform store and forward of certification 174 requests including the requester authentication information: 176 o Providing a trusted component (e.g., an LRA) in the target domain, 177 which stores the certification request combined with the requester 178 authentication information (based on the IDevID) and potentially 179 the information about a successful proof of possession (of the 180 corresponding private key) in a way prohibiting changes to the 181 combined information. Note that the assumption is that the 182 information elements may not be cryptographically bound together. 183 Once connectivity to the backend is available, the trusted 184 component forwards the certification request together with the 185 requester information (authentication and proof of possession) to 186 the off-site PKI for further processing. It is assumed that the 187 off-site PKI in this case relies on the local pledge 188 authentication result and thus performs the authorization and 189 issues the requested certificate. In BRSKI the trusted component 190 may be the EST server residing co-located with the registrar in 191 the target domain. 193 o Utilization of authenticated self-contained objects for the 194 enrollment, binding the certification request and the requester 195 authentication in a cryptographic way. This approach reduces the 196 necessary trust in a domain component to storage and delivery. 197 Unauthorized modifications of the requester information (request 198 and authentication) can be detected during the verification of the 199 authenticated self-contained object. 201 Focus of this document the support of handling authenticated self- 202 contained objects for bootstrapping. As it is intended to enhance 203 BRSKI it is named BRSKI-AE, where AE stands for asynchronous 204 enrollment. As BRSKI, BRSKI-AE results in the pledge storing an 205 X.509 domain certificate and sufficient information for verifying the 206 domain registrar / proxy identity (LDevID CA Certificate) as well as 207 domain specific X.509 device certificates (LDevID EE certificate). 209 Based on the proposed approach, a second set of scenarios can be 210 addressed, in which the pledge has either no direct communication 211 path to the domain registrar, e.g., due to missing network 212 connectivity or a different technology stack. In such scenarios the 213 pledge is expected to act as a server rather than a client. The 214 pledge will be triggered to generate request objects to be onboarded 215 in the registrar's domain. For this, an additional component is 216 introduced acting as an agent for the domain registrar (registrar- 217 agent) towards the pledge. This could be a functionality of a 218 commissioning tool or it may be even co-located with the registrar. 219 In contrast to BRSKI the registrar-agent performs the object exchange 220 with the pledge and provides/retrieves data objects to/from the 221 domain registrar. For the interaction with the domain registrar the 222 registrar agent will use existing BRSKI endpoints. 224 The goal is to enhance BRSKI to be applicable to the additional use 225 cases. This is addressed by 227 o enhancing the well-known URI approach with an additional path for 228 the utilized enrollment protocol. 230 o defining a certificate waiting indication and handling, if the 231 certifying component is (temporarily) not available. 233 o allowing to utilize credentials different from the pledge's IDevID 234 to establish a TLS connection to the domain registrar, which is 235 necessary in case of using a registrar-agent. 237 o defining the interaction (dta exchange and data objects) between a 238 pledge acting as server an a registrar-agent and the domain 239 registrar. 241 Note that in contrast to BRSKI, BRSKI-AE assumes support of multiple 242 enrollment protocols on the infrastructure side, allowing the pledge 243 manufacturer to select the most appropriate. Thus, BRSKI-AE can be 244 applied for both, asynchronous and synchronous enrollment. 246 2. Terminology 248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 250 "OPTIONAL" in this document are to be interpreted as described in 251 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 252 capitals, as shown here. 254 This document relies on the terminology defined in [RFC8995]. The 255 following terms are defined additionally: 257 CA: Certification authority, issues certificates. 259 RA: Registration authority, an optional system component to which a 260 CA delegates certificate management functions such as 261 authorization checks. 263 LRA: Local registration authority, an optional RA system component 264 with proximity to end entities. 266 IED: Intelligent Electronic Device (in essence a pledge). 268 on-site: Describes a component or service or functionality available 269 in the target deployment domain. 271 off-site: Describes a component or service or functionality 272 available in an operator domain different from the target 273 deployment domain. This may be a central site or a cloud service, 274 to which only a temporary connection is available, or which is in 275 a different administrative domain. 277 asynchronous communication: Describes a timely interrupted 278 communication between an end entity and a PKI component. 280 synchronous communication: Describes a timely uninterrupted 281 communication between an end entity and a PKI component. 283 authenticated self-contained object: Describes an object, which is 284 cryptographically bound to the EE certificate (IDevID certificate 285 or LDEVID certificate) of a pledge. The binding is assumed to be 286 provided through a digital signature of the actual object using 287 the corresponding private key of the EE certificate. 289 3. Scope of solution 291 3.1. Supported environment 293 This solution is intended to be used in domains with limited support 294 of on-site PKI services and comprises use cases in which: 296 o there is no registration authority available in the target domain. 297 The connectivity to an off-site RA in an operator's network may 298 only be available temporarily. A local store and forward device 299 is used for the communication with the off-site services. 301 o authoritative actions of a LRA are limited and may not comprise 302 authorization of certification requests of pledges. Final 303 authorization is done at the RA residing in the operator domain. 305 o the target deployment domain already has an established 306 certificate management approach that shall be reused to (e.g., in 307 brownfield installations). 309 In addition, the solution is intended to be applicable in domains in 310 which pledges have no direct connection to the domain registrar, but 311 are expected to be managed by the registrar. This can be motivated 312 by pledges featuring a different technology stack or by pledges 313 without an existing connection to the domain registrar during 314 bootstrapping. These pledges are likely to act in a server role. 315 Therefore, the pledge has to offer endpoints on which it can be 316 triggered for the generation of voucher-request objects and 317 certification objects as well as to provide the response objects to 318 the pledge. 320 3.2. Application Examples 322 The following examples are intended to motivate the support of 323 different enrollment approaches in general and asynchronous 324 enrollment specifically, by introducing industrial applications 325 cases, which could leverage BRSKI as such but also require support of 326 asynchronous operation as intended with BRSKI-AE. 328 3.2.1. Rolling stock 330 Rolling stock or railroad cars contain a variety of sensors, 331 actuators, and controllers, which communicate within the railroad car 332 but also exchange information between railroad cars building a train, 333 or with a backend. These devices are typically unaware of backend 334 connectivity. Managing certificates may be done during maintenance 335 cycles of the railroad car, but can already be prepared during 336 operation. The preparation may comprise the generation of 337 certification requests by the components which are collected and 338 forwarded for processing, once the railroad car is connected to the 339 operator backend. The authorization of the certification request is 340 then done based on the operator's asset/inventory information in the 341 backend. 343 3.2.2. Building automation 345 In building automation, a use case can be described by a detached 346 building or the basement of a building equipped with sensor, 347 actuators, and controllers connected, but with only limited or no 348 connection to the centralized building management system. This 349 limited connectivity may be during the installation time but also 350 during operation time. During the installation in the basement, a 351 service technician collects the necessary information from the 352 basement network and provides them to the central building management 353 system, e.g., using a laptop or even a mobile phone to transport the 354 information. This information may comprise parameters and settings 355 required in the operational phase of the sensors/actuators, like a 356 certificate issued by the operator to authenticate against other 357 components and services. 359 The collected information may be provided by a domain registrar 360 already existing in the installation network. In this case 361 connectivity to the backend PKI may be facilitated by the service 362 technician's laptop. Contrary, the information can also be collected 363 from the pledges directly and provided to a domain registrar deployed 364 in a different network. In this cases connectivity to the domain 365 registrar may be facilitated by the service technician's laptop. 367 3.2.3. Substation automation 369 In electrical substation automation a control center typically hosts 370 PKI services to issue certificates for Intelligent Electronic Devices 371 (IED)s operated in a substation. Communication between the 372 substation and control center is done through a proxy/gateway/DMZ, 373 which terminates protocol flows. Note that [NERC-CIP-005-5] requires 374 inspection of protocols at the boundary of a security perimeter (the 375 substation in this case). In addition, security management in 376 substation automation assumes central support of different enrollment 377 protocols to facilitate the capabilities of IEDs from different 378 vendors. The IEC standard IEC62351-9 [IEC-62351-9] specifies the 379 mandatory support of two enrollment protocols, SCEP [RFC8894] and EST 380 [RFC7030] for the infrastructure side, while the IED must only 381 support one of the two. 383 3.2.4. Electric vehicle charging infrastructure 385 For the electric vehicle charging infrastructure protocols have been 386 defined for the interaction between the electric vehicle (EV) and the 387 charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as 388 between the charging point and the charging point operator (e.g. 389 OCPP [OCPP]). Depending on the authentication model, unilateral or 390 mutual authentication is required. In both cases the charging point 391 uses an X.509 certificate to authenticate itself in the context of a 392 TLS connection between the EV and the charging point. The management 393 of this certificate depends (beyond others) on the selected backend 394 connectivity protocol. Specifically, in case of OCPP it is intended 395 as single communication protocol between the charging point and the 396 backend carrying all information to control the charging operations 397 and maintain the charging point itself. This means that the 398 certificate management is intended to be handled in-band of OCPP. 399 This requires to be able to encapsulate the certificate management 400 exchanges in a transport independent way. Authenticated self- 401 containment will ease this by allowing the transport without a 402 separate enrollment protocol. This provides a binding of the 403 exchanges to the identity of the communicating endpoints. 405 3.2.5. Infrastructure isolation policy 407 This refers to any case in which network infrastructure is normally 408 isolated from the Internet as a matter of policy, most likely for 409 security reasons. In such a case, limited access to external PKI 410 resources will be allowed in carefully controlled short periods of 411 time, for example when a batch of new devices are deployed, but 412 impossible at other times. 414 3.2.6. Less operational security in the target domain 416 The registration point performing the authorization of a certificate 417 request is a critical PKI component and therefore implicates higher 418 operational security than other components utilizing the issued 419 certificates for their security features. CAs may also demand higher 420 security in the registration procedures. Especially the CA/Browser 421 forum currently increases the security requirements in the 422 certificate issuance procedures for publicly trusted certificates. 423 There may be the situation that the target domain does not offer 424 enough security to operate a registration point and therefore wants 425 to transfer this service to a backend that offers a higher level of 426 operational security. 428 4. Requirement discussion and mapping to solution elements 430 For the requirements discussion it is assumed that the domain 431 registrar receiving a certification request as authenticated self- 432 contained object is not the authorization point for this 433 certification request. If the domain registrar is the authorization 434 point and the pledge has a direct connection to the registrar, BRSKI 435 can be used directly. Note that BRSKI-AE could also be used in this 436 case. 438 Based on the intended target environment described in Section 3.1 and 439 the motivated application examples described in Section 3.2 the 440 following base requirements are derived to support authenticated 441 self-contained objects as container carrying the certification 442 request and further information to support asynchronous operation. 444 At least the following properties are required: 446 o Proof of Possession: proves to possess and control the private key 447 corresponding to the public key contained in the certification 448 request, typically by adding a signature using the private key. 450 o Proof of Identity: provides data-origin authentication of a data 451 object, e.g., a certificate request, utilizing an existing IDevID. 452 Certificate updates may utilize the certificate that is to be 453 updated. 455 Solution examples (not complete) based on existing technology are 456 provided with the focus on existing IETF documents: 458 o Certification request objects: Certification requests are 459 structures protecting only the integrity of the contained data 460 providing a proof-of-private-key-possession for locally generated 461 key pairs. Examples for certification requests are: 463 * PKCS#10 [RFC2986]: Defines a structure for a certification 464 request. The structure is signed to ensure integrity 465 protection and proof of possession of the private key of the 466 requester that corresponds to the contained public key. 468 * CRMF [RFC4211]: Defines a structure for the certification 469 request message. The structure supports integrity protection 470 and proof of possession, through a signature generated over 471 parts of the structure by using the private key corresponding 472 to the contained public key. CRMF also supports further proof- 473 of-possession methods for key pairs not capable to be used for 474 signing. 476 Note that the integrity of the certification request is bound to 477 the public key contained in the certification request by 478 performing the signature operation with the corresponding private 479 key. In the considered application examples, this is not 480 sufficient to provide data origin authentication and needs to be 481 bound to the existing credential of the pledge (IDevID) 482 additionally. This binding supports the authorization decision 483 for the certification request through the provisioning of a proof 484 of identity. The binding of data origin authentication to the 485 certification request may be delegated to the protocol used for 486 certificate management. 488 o Proof of Identity options: The certification request should be 489 bound to an existing credential (here IDevID) to enable a proof of 490 identity and based on it an authorization of the certification 491 request. The binding may be realized through security options in 492 an underlying transport protocol if the authorization of the 493 certification request is done at the next communication hop. 494 Alternatively, this binding can be done by a wrapping signature 495 employing an existing credential (initial: IDevID, renewal: 496 LDevID). This requirement is addressed by existing enrollment 497 protocols in different ways, for instance: 499 * EST [RFC7030]: Utilizes PKCS#10 to encode the certification 500 request. The Certificate Signing Request (CSR) may contain a 501 binding to the underlying TLS by including the tls-unique value 502 in the self-signed CSR structure. The tls-unique value is one 503 result of the TLS handshake. As the TLS handshake is performed 504 mutually authenticated and the pledge utilized its IDevID for 505 it, the proof of identity can be provided by the binding to the 506 TLS session. This is supported in EST using the simpleenroll 507 endpoint. To avoid the binding to the underlying 508 authentication in the transport layer, EST offers the support 509 of a wrapping the CSR with an existing certificate by using 510 Full PKI Request messages. 512 * SCEP [RFC8894]: Provides the option to utilize either an 513 existing secret (password) or an existing certificate to 514 protect the CSR based on SCEP Secure Message Objects using CMS 515 wrapping ([RFC5652]). Note that the wrapping using an existing 516 IDevID credential in SCEP is referred to as renewal. SCEP 517 therefore does not rely on the security of an underlying 518 transport. 520 * CMP [RFC4210] Provides the option to utilize either an existing 521 secret (password) or an existing certificate to protect the 522 PKIMessage containing the certification request. The 523 certification request is encoded utilizing CRMF. PKCS#10 is 524 optionally supported. The proof of identity of the PKIMessage 525 containing the certification request can be achieved by using 526 IDevID credentials to a PKIProtection carrying the actual 527 signature value. CMP therefore does not rely on the security 528 of an underlying transport protocol. 530 * CMC [RFC5272] Provides the option to utilize either an existing 531 secret (password) or an existing certificate to protect the 532 certification request (either in CRMF or PKCS#10) based on CMS 533 [RFC5652]). Here a FullCMCRequest can be used, which allows 534 signing with an existing IDevID credential to provide a proof 535 of identity. CMC therefore does not rely on the security of an 536 underlying transport. 538 Note that besides the already existing enrollment protocols there is 539 ongoing work in the ACE WG to define an encapsulation of EST messages 540 in OSCORE to result in a TLS independent way of protecting EST. This 541 approach [I-D.selander-ace-coap-est-oscore] may be considered as 542 further variant. 544 5. Architectural Overview and Communication Exchanges 546 To support asynchronous enrollment, the base system architecture 547 defined in BRSKI [RFC8995] is enhanced to facilitate the two target 548 use cases. 550 o Use case 1 (Pledge-initiator-mode): the pledge requests 551 certificates from a PKI operated off-site via the domain 552 registrar. The communication model follows the BRSKI model in 553 which the pledge initiates the communication. 555 o Use case 2 (Pledge-responder-mode): allows delegated bootstrapping 556 using a registrar-agent instead a direct connection from the 557 pledge to the domain registrar. The communication model between 558 registrar-agent and pledge assumes that the pledge is acting as 559 server and responds to requests. 561 Both use cases are described in the next subsections. They utilize 562 the existing BRSKI architecture elements as much as possible. 563 Necessary enhancements to support authenticated self-contained 564 objects for certificate enrollment are kept on a minimum to ensure 565 reuse of already defined architecture elements and interactions. 567 For the authenticated self-contained objects used for the 568 certification request, BRSKI-AE relies on the defined message 569 wrapping mechanisms of the enrollment protocols stated in Section 4 570 above. 572 5.1. Use Case 1 (pledge-initiator-mode): Support of off-site PKI 573 service 575 One assumption of BRSKI-AE is that the authorization of a 576 certification request is performed based on an authenticated self- 577 contained object, binding the certification request to the 578 authentication using the IDevID. This supports interaction with off- 579 site or off-line PKI (RA/CA) components. In addition, the 580 authorization of the certification request may not be done by the 581 domain registrar but by a PKI residing in the backend of the domain 582 operator (off-site) as described in Section 3.1. Also, the 583 certification request may be piggybacked by another protocol. This 584 leads to changes in the placement or enhancements of the logical 585 elements as shown in Figure 1. 587 +------------------------+ 588 +--------------Drop Ship--------------->| Vendor Service | 589 | +------------------------+ 590 | | M anufacturer| | 591 | | A uthorized |Ownership| 592 | | S igning |Tracker | 593 | | A uthority | | 594 | +--------------+---------+ 595 | ^ 596 | | 597 V | 598 +--------+ ......................................... | 599 | | . . | BRSKI- 600 | | . +------------+ +------------+ . | MASA 601 | Pledge | . | Join | | Domain <-----+ 602 | | . | Proxy | | Registrar/ | . 603 | <-------->............<-------> Enrollment | . 604 | | . | BRSKI-AE | Proxy | . 605 | IDevID | . | | +------^-----+ . 606 | | . +------------+ | . 607 | | . | . 608 +--------+ ...............................|......... 609 "on-site domain" components | 610 |e.g., RFC 7030, 611 | RFC 4210, ... 612 .............................................|..................... 613 . +---------------------------+ +--------v------------------+ . 614 . | Public Key Infrastructure |<----+ PKI RA | . 615 . | PKI CA |---->+ | . 616 . +---------------------------+ +---------------------------+ . 617 ................................................................... 618 "off-site domain" components 620 Figure 1: Architecture overview using off-site PKI components 622 The architecture overview in Figure 1 utilizes the same logical 623 elements as BRSKI but with a different placement in the deployment 624 architecture for some of the elements. The main difference is the 625 placement of the PKI RA/CA component, which is performing the 626 authorization decision for the certification request message. It is 627 placed in the off-site domain of the operator (not the deployment 628 site directly), which may have no or only temporary connectivity to 629 the deployment or on-site domain of the pledge. This is to underline 630 the authorization decision for the certification request in the 631 backend rather than on-site. The following list describes the 632 components in the target domain: 634 o Join Proxy: same functionality as described in BRSKI. 636 o Domain Registrar / Enrollment Proxy: In general the domain 637 registrar proxy has a similar functionality regarding the 638 imprinting of the pledge in the deployment domain to facilitate 639 the communication of the pledge with the MASA and the PKI. 640 Different is the authorization of the certification request. 641 BRSKI-AE allows to perform this in the operator's backend (off- 642 site), and not directly at the domain registrar. 644 * Voucher exchange: The voucher exchange with the MASA via the 645 domain registrar is performed as described in BRSKI [RFC8995]. 647 * Certificate enrollment: For the pledge enrollment the domain 648 registrar in the deployment domain supports the adoption of the 649 pledge in the domain based on the voucher request. 650 Nevertheless, it may not have sufficient information for 651 authorizing the certification request. If the authorization of 652 the certification request is done in the off-site domain, the 653 domain registrar forwards the certification request to the RA 654 to perform the authorization. Note that this requires, that 655 the certification request object is enhanced with a proof-of- 656 identity to allow the authorization based on the bound identity 657 information of the pledge. As stated above, this can be done 658 by an additional signature using the IDevID. The domain 659 registrar here acts as an enrollment proxy or local 660 registration authority. It is also able to handle the case 661 having no connection temporarily to an off-site PKI, by storing 662 the authenticated certification request and forwarding it to 663 the RA upon reestablished connectivity. As authenticated self- 664 contained objects are used, it requires an enhancement of the 665 domain registrar. This is done by supporting alternative 666 enrollment approaches (protocol options, protocols, encoding) 667 by enhancing the addressing scheme to communicate with the 668 domain registrar (see Section 5.1.5). 670 The following list describes the vendor related components/service 671 outside the deployment domain: 673 o MASA: general functionality as described in [RFC8995]. Assumption 674 is that the interaction with the MASA may be synchronous (voucher 675 request with nonce) or asynchronous (voucher request without 676 nonce). 678 o Ownership tracker: as defined in [RFC8995]. 680 The following list describes the operator related components/service 681 operated in the backend: 683 o PKI RA: Performs certificate management functions (validation of 684 certification requests, interaction with inventory/asset 685 management for authorization of certification requests, etc.) for 686 issuing, updating, and revoking certificates for a domain as a 687 centralized infrastructure for the domain operator. The inventory 688 (asset) management may be a separate component or integrated into 689 the RA directly. 691 o PKI CA: Performs certificate generation by signing the certificate 692 structure provided in the certification request. 694 Based on BRSKI and the architectural changes the original protocol 695 flow is divided into three phases showing commonalities and 696 differences to the original approach as depicted in the following. 698 o Discovery phase (same as BRSKI) 700 o Voucher exchange with deployment domain registrar (same as BRSKI). 702 o Enrollment phase (changed to support the application of 703 authenticated self-contained objects). 705 5.1.1. Behavior of a pledge 707 The behavior of a pledge as described in [RFC8995] is kept with one 708 exception. After finishing the imprinting phase (4) the enrollment 709 phase (5) is performed with a method supporting authenticated self- 710 contained objects. Using EST with simple-enroll cannot be applied 711 here, as it binds the pledge authentication with the existing IDevID 712 to the transport channel (TLS) rather than to the certification 713 request object directly. This authentication in the transport layer 714 is not visible / verifiable at the authorization point in the off- 715 site domain. Section 7 discusses potential enrollment protocols and 716 options applicable. 718 5.1.2. Pledge - Registrar discovery and voucher exchange 720 The discovery phase is applied as specified in [RFC8995]. 722 5.1.3. Registrar - MASA voucher exchange 724 The voucher exchange is performed as specified in [RFC8995]. 726 5.1.4. Pledge - Registrar - RA/CA certificate enrollment 728 As stated in Section 4 the enrollment shall be performed using an 729 authenticated self-contained object providing proof of possession and 730 proof of identity. 732 +--------+ +---------+ +------------+ +------------+ 733 | Pledge | | Circuit | | Domain | | Operator | 734 | | | Join | | Registrar | | RA/CA | 735 | | | Proxy | | (JRC) | | (OPKI) | 736 +--------+ +---------+ +------------+ +------------+ 737 /--> | | 738 [Request of CA Certificates] | | 739 |---------- CA Certs Request ------------>| | 740 | [if connection to operator domain is available] | 741 | |-Request CA Certs ->| 742 | |<- CA Certs Response| 743 |<-------- CA Certs Response--------------| | 744 /--> | | 745 [Request of Certificate Attributes to be included] | 746 |---------- Attribute Request ----------->| | 747 | [if connection to operator domain is available] | 748 | |Attribute Request ->| 749 | |<-Attribute Response| 750 |<--------- Attribute Response -----------| | 751 /--> | | 752 [Certification request] | | 753 |-------------- Cert Request ------------>| | 754 | [if connection to operator domain is available] | 755 | |--- Cert Request -->| 756 | | | 757 [Optional Certificate waiting indication] | | 758 /--> | | 759 |<----- Cert Response (with Waiting) -----| | 760 |-- Cert Polling (with orig request ID) ->| | 761 | | | 762 /--> | | 763 | |<-- Cert Response --| 764 | | | 765 |<-- Cert Response (with Certificate) ----| | 766 /--> | | 767 [Certificate confirmation] | | 768 |-------------- Cert Confirm ------------>| | 769 | /--> | 770 | |[optional] | 771 | |--- Cert Confirm -->| 772 | |<-- PKI Confirm ----| 773 |<------------- PKI/Registrar Confirm ----| | 775 Figure 2: Certificate enrollment 777 The following list provides an abstract description of the flow 778 depicted in Figure 2. 780 o CA Cert Request: The pledge SHOULD request the full distribution 781 of CA Certificates. This ensures that the pledge has the complete 782 set of current CA certificates beyond the pinned-domain-cert 783 (which may be the domain registrar certificate contained in the 784 voucher). 786 o CA Cert Response: Contains at least one CA certificate of the 787 issuing CA. 789 o Attribute Request: Typically, the automated bootstrapping occurs 790 without local administrative configuration of the pledge. 791 Nevertheless, there are cases, in which the pledge may also 792 include additional attributes specific to the deployment domain 793 into the certification request. To get these attributes in 794 advance, the attribute request SHOULD be used. 796 o Attribute Response: Contains the attributes to be included in the 797 certification request message. 799 o Cert Request: Depending on the utilized enrollment protocol, this 800 certification request contains the authenticated self-contained 801 object ensuring both, proof-of-possession of the corresponding 802 private key and proof-of-identity of the requester. 804 o Cert Response: certification response message containing the 805 requested certificate and potentially further information like 806 certificates of intermediary CAs on the certification path. 808 o Cert Waiting: waiting indication for the pledge to retry after a 809 given time. For this a request identifier is necessary. This 810 request identifier may be either part of the enrollment protocol 811 or build based on the certification request. 813 o Cert Polling: querying the registrar, if the certificate request 814 was already processed; can be answered either with another Cert 815 Waiting, or a Cert Response. 817 o Cert Confirm: confirmation message from pledge after receiving and 818 verifying the certificate. 820 o PKI/Registrar Confirm: confirmation message from PKI/registrar 821 about reception of the pledge's certificate confirmation. 823 The generic messages described above can implemented using various 824 protocols implementing authenticated self-contained objects, as 825 described in Section 4. Examples are available in Section 7. 827 5.1.5. Addressing Scheme Enhancements 829 BRSKI-AE provides enhancements to the addressing scheme defined in 830 [RFC8995] to accommodate the additional handling of authenticated 831 self-contained objects for the certification request. As this is 832 supported by different enrollment protocols, they can be directly 833 employed (see also Section 7). 835 The addressing scheme in BRSKI for client certificate request and CA 836 certificate distribution function during the enrollment uses the 837 definition from EST [RFC7030], here on the example on simple enroll: 838 "/.well-known/est/simpleenroll" This approach is generalized to the 839 following notation: "/.well-known/enrollment-protocol/request" in 840 which enrollment-protocol may be an already existing protocol or a 841 newly defined approach. Note that enrollment is considered here as a 842 sequence of at least a certification request and a certification 843 response. In case of existing enrollment protocols the following 844 notation is used proving compatibility to BRSKI: 846 o enrollment-protocol: references either EST [RFC7030] as in BRSKI 847 or CMP, CMC, SCEP, or newly defined approaches as alternatives. 848 Note: additional endpoints (well-known URI) at the registrar may 849 need to be defined by the utilized enrollment protocol. 851 o request: depending on the utilized enrollment protocol, the 852 request describes the required operation at the registrar side. 853 Enrollment protocols are expected to define the request endpoints 854 as done by existing protocols (see also Section 7). 856 5.2. Use Case 2 (pledge-responder-mode): Registrar-agent communication 857 with Pledges 859 To support mutual trust establishment of pledges, not directly 860 connected to the domain registrar. It relies on the exchange of 861 authenticated self-contained objects (the voucher request/response 862 objects as known from BRSKI and the enrollment request/response 863 objects as introduced by BRSKI-AE). This approach has also been 864 applied also for the use case 1. This allows independence of a 865 potential protection provided by the used transport protocol. 867 In contrast to BRSKI, the object exchanges performed with the help of 868 a registrar-agent component, supporting the interaction of the pledge 869 with the domain registrar. It may be an integrated functionality of 870 a commissioning tool. This leads to enhancements of the logical 871 elements in the BRSKI architecture as shown in Figure 3. The 872 registrar-agent interacts with the pledge to acquire and to supply 873 the required data objects for bootstrapping, which are also exchanged 874 between the registrar-agent and the domain registrar. Moreover, the 875 addition of the registrar-agent also influences the sequences for the 876 data exchange between the pledge and the domain registrar described 877 in [RFC8995]. The general goal for the registrar-agent application 878 is the reuse of already defined endpoints of the domain registrar 879 side. The functionality of the already existing registrar endpoints 880 may need small enhancements. 882 +------------------------+ 883 +--------------Drop Ship---------------| Vendor Service | 884 | +------------------------+ 885 | | M anufacturer| | 886 | | A uthorized |Ownership| 887 | | S igning |Tracker | 888 | | A uthority | | 889 | +--------------+---------+ 890 | ^ 891 | | BRSKI- 892 V | MASA 893 +-------+ +---------+ .............................|......... 894 | | | | . | . 895 | | | | . +-----------+ +-----v-----+ . 896 | | |Registrar| . | | | | . 897 |Pledge | |Agent | . | Join | | Domain | . 898 | | | | . | Proxy | | Registrar | . 899 | <----->.........<------>...........<-------> (PKI RA) | . 900 | | | | . | BRSKI-AE | | . 901 | | | | . | | +-----+-----+ . 902 |IDevID | | LDevID | . +-----------+ | . 903 | | | | . +------------------+-----+ . 904 +-------+ +---------+ . | Key Infrastructure | . 905 . | (e.g., PKI Certificate | . 906 . | Authority) | . 907 . +------------------------+ . 908 ....................................... 909 "Domain" components 911 Figure 3: Architecture overview using registrar-agent 913 The architecture overview in Figure 3 utilizes the same logical 914 components as BRSKI with the registrar-agent component in addition. 916 For authentication towards the domain registrar, the registrar-agent 917 uses its LDevID. The provisioning of the registrar-agent LDevID may 918 be done by a separate BRSKI run or other means in advance. It is 919 recommended to use short lived registrar-agent LDevIDs in the range 920 of days or weeks. 922 If a registrar detects a request originates from a registrar-agent it 923 is able to switch the operational mode from BRSKI to BRSKI-AE. 925 In addition, the domain registrar may authenticate the user operating 926 the registrar-agent to perform additional authorization of a pledge 927 enrollment action. Examples for such user level authentication are 928 the application of HTTP authentication or the usage of authorization 929 tokens or other. This is out of scope of this document. 931 The following list describes the components in a (customer) site 932 domain: 934 o Pledge: The pledge is expected to respond with the necessary data 935 objects for bootstrapping to the registrar-agent. The transport 936 protocol used between the pledge and the registrar-agent is 937 assumed to be HTTP in the context of this document. Other 938 transport protocols may be used but are out of scope of this 939 document. As the pledge is acting as a server during 940 bootstrapping it leads to some differences to BRSKI: 942 * Discovery of the domain registrar by the pledge is not needed 943 as the pledge will be triggered by the registrar-agent. 945 * Discovery of the pledge by the registrar-agent must be 946 possible. 948 * As the registrar-agent must be able to request data objects for 949 bootstrapping of the pledge, the pledge must offer 950 corresponding endpoints. 952 * The registrar-agent may provide additional data to the pledge, 953 in the context of the triggering request. 955 * Order of exchanges in the call flow may be different as the 956 registrar-agent collects both objects, pledge-voucher-request 957 objects and pledge-enrollment-request objects, at once and 958 provides them to the registrar. This approach may also be used 959 to perform a bulk bootstrapping of several devices. 961 * The data objects utilized for the data exchange between the 962 pledge and the registrar are self-contained authenticated 963 objects (signature-wrapped objects) as in use case 1 964 Section 5.1. 966 o Registrar-agent: provides a communication path to exchange data 967 objects between the pledge and the domain registrar. The 968 registrar-agent facilitates situations, in which the domain 969 registrar is not directly reachable by the pledge, either due to a 970 different technology stack or due to missing connectivity. The 971 registrar-agent triggers the pledge to create bootstrapping 972 information such as voucher request objects and enrollment request 973 objects from one or multiple pledges at once and performs a bulk 974 bootstrapping based on the collected data. The registrar-agent is 975 expected to possess information of the domain registrar, either by 976 configuration or by using the discovery mechanism defined in 977 [RFC8995]. There is no trust assumption between the pledge and 978 the registrar-agent as only authenticated self-contained objects 979 are applied, which are transported via the registrar-agent and 980 provided either by the pledge or the registrar. The trust 981 assumption between the registrar-agent and the registrar bases on 982 an own LDevID of the registrar-agent, acting as registrar 983 component. This allows the registrar-agent to authenticate 984 towards the registrar. The registrar can utilize this 985 authentication to distinguish communication with a pledge from a 986 registrar-agent based on the exchanged objects. 988 o Join Proxy: same functionality as described in [RFC8995]. Note 989 that it may be used by the registrar-agent instead of the pledge 990 to find the registrar, if not configured. 992 o Domain Registrar: In general the domain registrar fulfills the 993 same functionality regarding the bootstrapping of the pledge in a 994 (customer) site domain by facilitating the communication of the 995 pledge with the MASA service and the domain PKI service. In 996 contrast to [RFC8995], the domain registrar does not interact with 997 a pledge directly but through the registrar-agent. The registrar 998 detects if the bootstrapping is performed by the pledge directly 999 or by the registrar-agent. The manufacturer provided components/ 1000 services (MASA and Ownership tracker) are used as defined in 1001 [RFC8995]. For issuing a voucher, the MASA may perform additional 1002 checks on voucher-request objects, to issue a voucher indicating 1003 agent-proximity instead of registrar-proximity. 1005 [RFC Editor: please delete] /* 1007 Open Issues: The voucher defined in [RFC8366] defines the leaf 1008 assertion as enum, which cannot be extended. To define an additional 1009 assertion RFC 8366 may be revised. */ 1011 "Agent-proximity" is a weaker assertion then "proximity". In case of 1012 "agent-proximity" it is a statement, that the proximity-registrar- 1013 certificate was provided via the registrar-agent and not directly. 1014 This can be verified by the registrar and also by the MASA through 1015 voucher-request processing. Note that at the time of creating the 1016 voucher-request, the pledge cannot verify the LDevID(Reg) EE 1017 certificate and has no proof-of-possession of the corresponding 1018 private key for the certificate. Trust handover to the domain is 1019 established via the "pinned-domain-certificate" in the voucher. 1021 In contrast, "proximity" provides a statement, that the pledge was in 1022 direct contact with the registrar and was able to verify proof-of- 1023 possession of the private key in the context of the TLS handshake. 1024 The provisionally accepted LDevID(Reg) EE certificate can be verified 1025 after the voucher has been processed by the pledge. 1027 5.2.1. Behavior of a pledge in pledge-responder-mode 1029 In contrast to use case 1 Section 5.1 the pledge acts as a server 1030 component if data is triggered by the registrar-agent for the 1031 generation of pledge-voucher-request and pledge-enrollment-request 1032 objects as well as for the processing of the response objects and the 1033 generation of status information. Due to the use of the registrar- 1034 agent, the interaction with the domain registrar is changed as shown 1035 in Figure 5. To enable interaction with the registrar-agent, the 1036 pledge provides endpoints using the BRSKI interface based on the 1037 "/.well-known/brski" URI tree. The following endpoints are defined 1038 for the pledge in this document: 1040 o /.well-known/brski/pledge-voucher-request: trigger pledge to 1041 create voucher request. It returns the pledge-voucher-request. 1043 o /.well-known/brski/pledge-enrollment-request: trigger pledge to 1044 create enrollment request. it returns the pledge-enrollment- 1045 request. 1047 o /.well-known/brski/pledge-voucher: supply MASA provided voucher to 1048 pledge. It returns the pledge-voucher-status. 1050 o /.well-known/brski/pledge-enrollment: supply enroll response 1051 (certificate) to pledge. It returns the pledge-enrollment-status. 1053 o /.well-known/brski/pledge-CACerts: supply CACerts to pledge 1054 (optional). 1056 5.2.2. Behavior of a registrar-agent 1058 The registrar-agent is a new component in the BRSKI context. It 1059 provides connectivity between the pledge and the domain registrar and 1060 reuses the endpoints of the domain registrar side already specified 1061 in [RFC8995]. It facilitates the exchange of data objects between 1062 the pledge and the domain registrar, which are the voucher request/ 1063 response objects, the enrollment request/response objects, as well as 1064 related status objects. For the communication the registrar-agent 1065 utilizes communication endpoints provided by the pledge. The 1066 transport in this specification is based on HTTP but may also be done 1067 using other transport mechanisms. This new component changes the 1068 general interaction between the pledge and the domain registrar as 1069 shown in Figure 9. 1071 The registrar-agent is expected to already possess an LDevID(RegAgt) 1072 to authenticate towards the domain registrar. The registrar-agent 1073 will use this LDevID(RegAgt) when establishing the TLS session with 1074 the domain registrar in the context of for TLS client-side 1075 authentication. The LDevID(RegAgt) certificate MUST include a 1076 SubjectKeyIdentifier (SKID), which is used as reference in the 1077 context of an agent-signed-data object. Note that this is an 1078 additional requirement for issuing the certificate, as [IEEE-802.1AR] 1079 only requires the SKID to be included for intermediate CA 1080 certificates. In the specific application of BRSKI-AE, it is used in 1081 favor of a certificate fingerprint to avoid additional computations. 1083 Using an LDevID for TLS client-side authentication is a deviation 1084 from [RFC8995], in which the pledge's IDevID credential is used to 1085 perform TLS client authentication. The use of the LDevID(RegAgt) 1086 allows the domain registrar to distinguish, if bootstrapping is 1087 initiated from a pledge or from a registrar-agent and adopt the 1088 internal handling accordingly. As BRSKI-AE uses authenticated self- 1089 contained data objects between the pledge and the domain registrar, 1090 the binding of the pledge identity to the request object is provided 1091 by the data object signature employing the pledge's IDevID. The 1092 objects exchanged between the pledge and the domain registrar used in 1093 the context of this specifications are JOSE objects 1095 In addition to the LDevID(RegAgt), the registrar-agent is provided 1096 with the product-serial-numbers of the pledges to be bootstrapped. 1097 This is necessary to allow the discovery of pledges by the registrar- 1098 agent using mDNS. The list may be provided by administrative means 1099 or the registrar agent may get the information via an interaction 1100 with the pledge, like scanning of product-serial-number information 1101 using a QR code or similar. 1103 According to [RFC8995] section 5.3, the domain registrar performs the 1104 pledge authorization for bootstrapping within his domain based on the 1105 pledge voucher-request object. 1107 The following information is therefore available at the registrar- 1108 agent: 1110 o LDevID(RegAgt): own operational key pair. 1112 o LDevID(reg) certificate: certificate of the domain registrar. 1114 o Serial-number(s): product-serial-number(s) of pledge(s) to be 1115 bootstrapped. 1117 5.2.2.1. Registrar discovery by the registrar-agent 1119 The discovery of the domain registrar may be done as specified in 1120 [RFC8995] with the deviation that it is done between the registrar- 1121 agent and the domain registrar. Alternatively, the registrar-agent 1122 may be configured with the address of the domain registrar and the 1123 certificate of the domain registrar. 1125 5.2.2.2. Pledge discovery by the registrar-agent 1127 The discovery of the pledge by registrar-agent should be done by 1128 using DNS-based Service Discovery [RFC6763] over Multicast DNS 1129 [RFC6762] to discover the pledge at "product-serial-number.brski- 1130 pledge._tcp.local." The pledge constructs a local host name based on 1131 device local information (product-serial-number), which results in 1132 "product-serial-number.brski-pledge._tcp.local.". It can then be 1133 discovered by the registrar-agent via mDNS. Note that other 1134 mechanisms for discovery may be used. 1136 The registrar-agent is able to build the same information based on 1137 the provided list of product-serial-number. 1139 5.2.3. Bootstrapping objects and corresponding exchanges 1141 The interaction of the pledge with the registrar-agent may be 1142 accomplished using different transport means (protocols and or 1143 network technologies). For this document the usage of HTTP is 1144 targeted as in BRSKI. Alternatives may be CoAP, Bluetooth Low Energy 1145 (BLE), or Nearfield Communication (NFC). This requires independence 1146 of the exchanged data objects between the pledge and the registrar 1147 from transport security. Therefore, authenticated self-contained 1148 objects (here: signature-wrapped objects) are applied in the data 1149 exchange between the pledge and the registrar. 1151 The registrar-agent provides the domain-registrar certificate 1152 (LDevID(Reg) EE certificate) to the pledge to be included into the 1153 "agent-provided-proximity-registrar-certificate" leaf in the pledge- 1154 voucher-request object. This enables the registrar to verify, that 1155 it is the target registrar for handling the request. The registrar 1156 certificate may be configured at the registrar-agent or may be 1157 fetched by the registrar-agent based on a prior TLS connection 1158 establishment with the domain registrar. In addition, the registrar- 1159 agent provides agent-signed-data containing the product-serial-number 1160 in the body, signed with the LDevID(RegAgt). This enables the 1161 registrar to verify and log, which registrar-agent was in contact 1162 with the pledge. Optionally the registrar-agent may provide its 1163 LDevID(RegAgt) certificate to the pledge for inclusion into the 1164 pledge-voucher-request as "agent-sign-cert" leaf. Note that this may 1165 be omitted in constraint environments to safe bandwidth between the 1166 registrar-agent and the pledge. If not contained, the registrar- 1167 agent MUST fetch the LDevID(RegAgt) certificate based on the 1168 SubjectKeyIdentifier (SKID) in the header of the agent-signed-data. 1169 The registrar may include the LDevID(RegAgt) certificate information 1170 into the registrar-voucher-request. 1172 The MASA in turn verifies the LDevID(Reg) certificate is included in 1173 the pledge-voucher-request (prior-signed-voucher-request) in the 1174 "agent-provided-proximity-registrar-certificate" leaf and may assert 1175 in the voucher "verified" or "logged" instead of "proximity", as 1176 there is no direct connection between the pledge and the registrar. 1177 If the LDevID(RegAgt) certificate is included contained in the 1178 "agent-sign-cert" leave of the registrar-voucher-request, the MASA 1179 can verify the LDevID(RegAgt) certificate and the signature of the 1180 registrar-agent in the agent-signed-data provided in the prior- 1181 signed-voucher-request. If both can be verified successfully, the 1182 MASA can assert "agent-proximity" in the voucher. Otherwise, it may 1183 assert "verified" or "logged". The voucher can then be supplied via 1184 the registrar to the registrar-agent. 1186 Figure 4 provides an overview of the exchanges detailed in the 1187 following sub sections. 1189 +--------+ +-----------+ +-----------+ +--------+ +---------+ 1190 | Pledge | | Registrar | | Domain | | Domain | | Vendor | 1191 | | | Agent | | Registrar | | CA | | Service | 1192 | | | (RegAgt) | | (JRC) | | | | (MASA) | 1193 +--------+ +-----------+ +-----------+ +--------+ +---------+ 1194 | | | | Internet | 1195 [discovery of pledge] 1196 | mDNS query | | | | 1197 |<-------------| | | | 1198 |------------->| | | | 1199 | | | | | 1200 [trigger pledge-voucher-request and 1201 pledge-enrollment-request generation] 1202 |<- vTrigger --| | | | 1203 |-Voucher-Req->| | | | 1204 | | | | | 1205 |<- eTrigger --| | | | 1206 |- Enroll-Req->| | | | 1207 ~ ~ ~ ~ ~ 1208 [provide pledge-voucher-request to infrastructure] 1209 | |<------ TLS ----->| | | 1210 | |-- Voucher-Req -->| | | 1211 | | [accept device?] | | 1212 | | [contact vendor] | | 1213 | | |------- Voucher-Req ------>| 1214 | | | [extract DomainID] 1215 | | | [update audit log] 1216 | | |<-------- Voucher ---------| 1217 | |<---- Voucher ----| | | 1218 | | | | | 1219 [provide pledge enrollment request to infrastructure] 1220 | |-- Enroll-Req --->| | | 1221 | | |- Cert-Req -->| | 1222 | | |<-Certificate-| | 1223 | |<-- Enroll-Resp --| | | 1224 ~ ~ ~ ~ ~ 1225 [provide voucher and certificate 1226 to pledge and collect status info] 1227 |<-- Voucher --| | | | 1228 |-- vStatus -->| | | | 1229 |<-Enroll-Resp-| | | | 1230 |-- eStatus -->| | | | 1231 ~ ~ ~ ~ ~ 1232 [provide voucher-status and enrollment status to registrar] 1233 | |<------ TLS ----->| | | 1234 | |---- vStatus --->| | | 1235 | | |-- req. device audit log ->| 1236 | | |<---- device audit log ----| 1237 | | [verify audit log] 1238 | | | | | 1239 | |---- eStatus --->| | | 1240 | | | | | 1242 Figure 4: Overview pledge-responder-mode exchanges 1244 The following sub sections split the interactions between the 1245 different components into: 1247 o Request objects acquisition targets exchanges and objects between 1248 the registrar-agent and the pledge. 1250 o Request handling targets exchanges and objects between the 1251 registrar-agent and the registrar and also the interaction of the 1252 registrar with the MASA and the domain CA. 1254 o Response object supply targets the exchanges and objects between 1255 the registrar-agent and the pledge including the status objects. 1257 o Status handling addresses the exchanges between the registrar- 1258 agent and the registrar. 1260 5.2.3.1. Request objects acquisition (registrar-agent - pledge) 1262 The following description assumes that the registrar-agent already 1263 discovered the pledge. This may be done as described in 1264 Section 5.2.2.2 based on mDNS. 1266 The focus is on the exchange of signature-wrapped objects using 1267 endpoints defined for the pledge in Section 5.2.1. 1269 Preconditions: 1271 o Pledge: possesses IDevID 1273 o Registrar-agent: possesses IDevID CA certificate and an own 1274 LDevID(RegAgt) EE credential for the registrar domain. In 1275 addition, the registrar-agent can be configured with the product- 1276 serial-number(s) of the pledge(s) to be bootstrapped. Note that 1277 the product-serial-number may have been used during the pledge 1278 discovery already. 1280 o Registrar: possesses IDevID CA certificate and an own LDevID/Reg) 1281 credential. 1283 o MASA: possesses own credentials (voucher signing key, TLS server 1284 certificate) as well as IDevID CA certificate of pledge vendor / 1285 manufacturer and site-specific LDevID CA certificate. 1287 +--------+ +-----------+ 1288 | Pledge | | Registrar | 1289 | | | Agent | 1290 | | | (RegAgt) | 1291 +--------+ +-----------+ 1292 | |-create 1293 | | agent-signed-data 1294 |<--- trigger pledge-voucher-request ----| 1295 |-agent-provided-proximity-registrar-cert| 1296 |-agent-signed-data | 1297 |-agent-sign-cert (optional) | 1298 | | 1299 |----- pledge-voucher-request ---------->|-store 1300 | | pledge-voucher-request 1301 |<----- trigger enrollment request ------| 1302 | (empty) | 1303 | | 1304 |------ pledge-enrollment-request ------>|-store 1305 | | pledge-enrollment-req. 1307 Figure 5: Request collection (registrar-agent - pledge) 1309 Triggering the pledge to create the pledge-voucher-request is done 1310 using HTTPS POST on the defined pledge endpoint "/.well-known/brski/ 1311 pledge-voucher-request". 1313 The registrar-agent pledge-voucher-request Content-Type header is: 1315 application/json: defines a JSON document to provide three parameter: 1317 o agent-provided-proximity-registrar-cert: base64-encoded 1318 LDevID(Reg) TLS EE certificate. 1320 o agent-sign-cert: base64-encoded LDevID(RegAgt) signing certificate 1321 (optional). 1323 o agent-signed-data: base64-encoded JWS-object. 1325 Note that optionally including the agent-sign-cert enables the pledge 1326 to verify at least the signature of the agent-signed-data. It may 1327 not verify the agent-sign-cert itself due to missing issuing CA 1328 information. 1330 The agent-signed-data is a JOSE object and contains the following 1331 information: 1333 The header of the agent-signed-data contains: 1335 o alg: algorithm used for creating the object signature. 1337 o kid: contains the base64-encoded SubjectKeyIdentifier of the 1338 LDevID(RegAgt) certificate. 1340 The body of the agent-signed-data contains an ietf-voucher- 1341 request:agent-signed-data element (defined in Section 6): 1343 o created-on: MUST contain the creation date and time in yang:date- 1344 and-time format. 1346 o serial-number: MUST contain the product-serial-number as type 1347 string as defined in [RFC8995], section 2.3.1. The serial-number 1348 corresponds with the product-serial-number contained in the 1349 X520SerialNumber field of the IDevID certificate of the pledge. 1351 { 1352 "alg": "ES256", 1353 "kid": "base64encodedvalue==" 1354 } 1355 { 1356 "ietf-voucher-request-trigger:agent-signed-data": { 1357 "created-on": "2021-04-16T00:00:01.000Z", 1358 "serial-number": "callee4711" 1359 } 1360 } 1361 { 1362 SIGNATURE 1363 } 1365 Figure 6: Example of agent-signed-data 1367 Upon receiving the voucher-request trigger, the pledge SHOULD 1368 construct the body of the pledge-voucher-request object as defined in 1369 [RFC8995]. This object becomes a JSON-in-JWS object as defined in 1370 [I-D.richardson-anima-jose-voucher]. 1372 The header of the pledge-voucher-request SHALL contain the following 1373 parameter as defined in [RFC7515]: 1375 o alg: algorithm used for creating the object signature. 1377 o x5c: contains the base64-encoded pledge IDevID certificate. 1379 The body of the pledge-voucher-request object MUST contain the 1380 following parameter as part of the ietf-voucher-request:voucher as 1381 defined in [RFC8995]: 1383 o created-on: contains the current date and time in yang:date-and- 1384 time format. 1386 o nonce: contains a cryptographically strong random or pseudo-random 1387 number. 1389 o serial-number: contains the base64-encoded pledge product-serial- 1390 number. 1392 o assertion: contains the requested voucher assertion. 1394 The ietf-voucher-request:voucher is enhanced with additional 1395 parameters: 1397 o agent-provided-proximity-registrar-cert: MUST be included and 1398 contains the base64-encoded LDevID(Reg) EE certificate (provided 1399 as trigger parameter by the registrar-agent). 1401 o agent-signed-data: MUST contain the base64-encoded agent-signed- 1402 data (as defined in Figure 6) and provided as trigger parameter. 1404 o agent-sign-cert: May contain the base64-encoded LDevID(RegAgt) EE 1405 certificate if provided as trigger parameter. 1407 The enhancements of the YANG module for the ietf-voucher-request with 1408 these new leafs are defined in Section 6. 1410 The object is signed using the pledges IDevID credential contained as 1411 x5c parameter of the JOSE header. 1413 { 1414 "alg": "ES256", 1415 "x5c": ["MIIB2jCC...dA=="] 1416 } 1417 { 1418 "ietf-voucher-request:voucher": { 1419 "created-on": "2021-04-16T00:00:02.000Z", 1420 "nonce": "eDs++/FuDHGUnRxN3E14CQ==", 1421 "serial-number": "callee4711", 1422 "assertion": "agent-proximity", 1423 "agent-provided-proximity-registrar-cert": "base64encodedvalue==", 1424 "agent-signed-data": "base64encodedvalue==", 1425 "agent-sign-cert": "base64encodedvalue==" 1426 } 1427 } 1428 { 1429 SIGNATURE 1430 } 1432 Figure 7: Example of pledge-voucher-request 1434 The pledge-voucher-request Content-Type is defined in 1435 [I-D.richardson-anima-jose-voucher] as: 1437 application/voucher-jose+json 1439 The pledge SHOULD include an "Accept" header field indicating the 1440 acceptable media type for the voucher response. The media type 1441 "application/voucher-jose+json" is defined in 1442 [I-D.richardson-anima-jose-voucher]. 1444 Once the registrar-agent has received the pledge-voucher-request it 1445 can trigger the pledge to generate an enrollment-request object. As 1446 in BRSKI the enrollment request object is a PKCS#10, additionally 1447 signed by the IDevID. Note, as the initial enrollment aims to 1448 request a general certificate, no certificate attributes are provided 1449 to the pledge. 1451 Triggering the pledge to create the enrollment-request is done using 1452 HTTPS GET on the defined pledge endpoint "/.well-known/brski/pledge- 1453 enrollment-request". 1455 The registrar-agent pledge-enrollment-request Content-Type header is: 1457 application/json: 1459 with an empty body. 1461 Upon receiving the enrollment-trigger, the pledge SHALL construct the 1462 pledge-enrollment-request as authenticated self-contained object. 1463 The CSR already assures proof of possession of the private key 1464 corresponding to the contained public key. In addition, based on the 1465 additional signature using the IDevID, proof of identity is provided. 1466 Here, a JOSE object is being created in which the body utilizes the 1467 YANG module for the CSR as defined in [I-D.ietf-netconf-sztp-csr]. 1469 [RFC Editor: please delete] /* Open Issues: Reuse of the sub-tree 1470 ietf-sztp-csr:csr may not be possible as it is not the complete 1471 module. */ 1473 Depending on the capability of the pledge, it MAY construct the 1474 enrollment request as plain PKCS#10. Note that the focus here is 1475 placed on PKCS#10 as PKCS#10 can be transmitted in different 1476 enrollment protocols like EST, CMP, CMS, and SCEP. If the pledge is 1477 already implementing an enrollment protocol, it may leverage that 1478 functionality for the creation of the enrollment request object. 1479 Note also that [I-D.ietf-netconf-sztp-csr] also allows for inclusion 1480 of certificate request objects from CMP or CMC. 1482 The pledge SHOULD construct the pledge-enrollment-request as PKCS#10 1483 object and sign it additionally with its IDevID credential. The 1484 pledge-enrollment-request should be encoded as JOSE object. 1486 [RFC Editor: please delete] /* Open Issues: Depending on target 1487 environment, it may be useful to assume that the pledge may already 1488 "know" its functional scope and therefore the number of certificates 1489 needed during operation. As a result, multiple CSRs may be generated 1490 to provide achieve multiple certificates as a result of the 1491 enrollment. This would need further description and potential 1492 enhancements also in the enrollment-request object to transport 1493 different CSRs. */ 1495 [I-D.ietf-netconf-sztp-csr] considers PKCS#10 but also CMP and CMC as 1496 certificate request format. Note that the wrapping signature is only 1497 necessary for plain PKCS#10 as other request formats like CMP and CMS 1498 support the signature wrapping as part of their own certificate 1499 request format. 1501 The registrar-agent enrollment-request Content-Type header for a 1502 wrapped PKCS#10 is: 1504 application/jose: 1506 The header of the pledge enrollment-request SHALL contain the 1507 following parameter as defined in [RFC7515]: 1509 o alg: algorithm used for creating the object signature. 1511 o x5c: contains the base64-encoded pledge IDevID certificate. 1513 The body of the pledge enrollment-request object SHOULD contain a P10 1514 parameter (for PKCS#10) as defined for ietf-sztp-csr:csr in 1515 [I-D.ietf-netconf-sztp-csr]: 1517 o P10: contains the base64-encoded PKCS#10 of the pledge. 1519 The JOSE object is signed using the pledge's IDevID credential, which 1520 corresponds to the certificate signaled in the JOSE header. 1522 { 1523 "alg": "ES256", 1524 "x5c": ["MIIB2jCC...dA=="] 1525 } 1526 { 1527 "ietf-sztp-csr:csr": { 1528 "p10": "base64encodedvalue==" 1529 } 1530 } 1531 { 1532 SIGNATURE 1533 } 1535 Figure 8: Example of pledge-enrollment-request 1537 With the collected pledge-voucher-request object and the pledge- 1538 enrollment-request object, the registrar-agent starts the interaction 1539 with the domain registrar. 1541 [RFC Editor: please delete] /* 1543 Open Issues: further description necessary at least for */ 1545 o Values to be taken from the IDevID into the PKCS#10 (like product- 1546 serial-number or subjectName, or certificate template) 1548 Once the registrar-agent has collected the pledge-voucher-request and 1549 pledge-enrollment-request objects, it connects to the registrar and 1550 sends the request objects. As the registrar-agent is intended to 1551 work between the pledge and the domain registrar, a collection of 1552 requests from more than one pledges is possible, allowing a bulk 1553 bootstrapping of multiple pledges using the same connection between 1554 the registrar-agent and the domain registrar. 1556 5.2.3.2. Request handling (registrar-agent - infrastructure) 1558 The bootstrapping exchange between the registrar-agent and the domain 1559 registrar resembles the exchanges between the pledge and the domain 1560 registrar from BRSKI in the pledge-initiator-mode with some 1561 deviations. 1563 Preconditions: 1565 o Registrar-agent: possesses IDevID CA certificate and own 1566 LDevID(RegAgt) EE credential of registrar domain. It knows the 1567 address of the domain registrar through configuration or discovery 1568 by, e.g., mDNS/DNSSD. The registrar-agent has acquired pledge- 1569 voucher-request and pledge-enrollment-request objects(s). 1571 o Registrar: possesses IDevID CA certificate of pledge vendors / 1572 manufacturers and an own LDevID(Reg) EE credential. 1574 o MASA: possesses own credentials (voucher signing key, TLS server 1575 certificate) as well as IDevID CA certificate of pledge vendor / 1576 manufacturer and site-specific LDevID CA certificate. 1578 +-----------+ +-----------+ +--------+ +---------+ 1579 | Registrar | | Domain | | Domain | | Vendor | 1580 | Agent | | Registrar | | CA | | Service | 1581 | (RegAgt) | | (JRC) | | | | (MASA) | 1582 +-----------+ +-----------+ +--------+ +---------+ 1583 | | | Internet | 1584 [exchange between pledge and ] 1585 [registrar-agent done. ] 1586 | | | | 1587 |<------ TLS ----->| | | 1588 | | | | 1589 |-- Voucher-Req -->| | | 1590 | [accept device?] | | 1591 | [contact vendor] | | 1592 | |------------ TLS --------->| 1593 | |-- Voucher-Req ----------->| 1594 | | [extract DomainID] 1595 | | [update audit log] 1596 |<---- Voucher ----|<-------- Voucher ---------| 1597 | | | | 1598 [certification request handling registrar-agent] 1599 [and site infrastructure] 1600 |--- Enroll-Req -->| | | 1601 | |---- TLS ---->| | 1602 | |- Enroll-Req->| | 1603 | |<-Enroll-Resp-| | 1604 |<-- Enroll-Resp---| | | 1605 | | | | 1607 Figure 9: Request processing between registrar-agent and 1608 infrastructure bootstrapping services 1610 The registrar-agent establishes a TLS connection with the registrar. 1611 As already stated in [RFC8995], the use of TLS 1.3 (or newer) is 1612 encouraged. TLS 1.2 or newer is REQUIRED on the registrar-agent 1613 side. TLS 1.3 (or newer) SHOULD be available on the registrar, but 1614 TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be available on the 1615 MASA, but TLS 1.2 MAY be used. 1617 In contrast to [RFC8995] client authentication is achieved by using 1618 the LDevID(RegAgt) of the registrar-agent instead of the IDevID of 1619 the pledge. This allows the registrar to distinguish between pledge- 1620 initiator-mode and pledge-responder-mode. In pledge-responder-mode 1621 the registrar has no direct connection to the pledge but via the 1622 registrar-agent. The registrar can receive request objects in 1623 different forms as defined in [RFC8995]. Specifically, the registrar 1624 will receive JOSE objects from the pledge for voucher-request and 1625 enrollment-request (instead of the objects for voucher-request (CMS- 1626 signed JSON) and enrollment-request (PKCS#10). 1628 The registrar-agent sends the pledge-voucher-request to the registrar 1629 with an HTTPS POST to the endpoint "/.well-known/brski/ 1630 requestvoucher". 1632 The pledge-voucher-request Content-Type used in the pledge-responder- 1633 mode is defined in [I-D.richardson-anima-jose-voucher] as: 1635 application/voucher-jose+json (see Figure 7 for the content 1636 definition). 1638 The registrar-agent SHOULD include the "Accept" header field received 1639 during the communication with the pledge, indicating the pledge 1640 acceptable Content-Type for the voucher-response. The voucher- 1641 response Content-Type "application/voucher-jose+json" is defined in 1642 [I-D.richardson-anima-jose-voucher]. 1644 Upon reception of the pledge-voucher-request, the registrar SHALL 1645 perform the verification of the voucher-request parameter as defined 1646 in section 5.3 of [RFC8995]. In addition, the registrar shall verify 1647 the following parameters from the pledge-voucher-request: 1649 o agent-provided-proximity-registrar-cert: MUST contain the own 1650 LDevID(Reg) EE certificate to ensure the registrar in proximity is 1651 the target registrar for the request. 1653 o agent-signed-data: The registrar MUST verify that the data has 1654 been signed with the LDevID(RegAgt) credential indicated in the 1655 "kid" JOSE header parameter. If the certificate is not contained 1656 in the agent-sign-cert component of the pledge-voucher-request, it 1657 must fetch the certificate from a repository. 1659 o agent-sign-cert: May contain the base64-encoded LDevID(RegAgt) 1660 certificate. If contained the registrar MUST verify that the 1661 connected credential used to sign the data was valid at signature 1662 creation time and that the corresponding registrar-agent was 1663 authorized to be involved in the bootstrapping. 1665 If validation fails the registrar SHOULD respond with the HTTP 404 1666 error code to the registrar-agent. If the pledge-voucher-request is 1667 in an unknown format, then an HTTP 406 error code is more 1668 appropriate. 1670 If validation succeeds, the registrar will accept the pledge request 1671 to join the domain as defined in section 5.3 of [RFC8995]. The 1672 registrar then establishes a TLS connection with the MASA as 1673 described in section 5.4 of [RFC8995] to obtain a voucher for the 1674 pledge. 1676 The registrar SHALL construct the body of the registrar-voucher- 1677 request object as defined in [RFC8995]. The encoding SHALL be done 1678 as JOSE object as defined in [I-D.richardson-anima-jose-voucher]. 1680 The header of the registrar-voucher-request SHALL contain the 1681 following parameter as defined in [RFC7515]: 1683 o alg: algorithm used for creating the object signature. 1685 o x5c: contains the base64-encoded registrar LDevID certificate. 1687 The body of the registrar-voucher-request object MUST contain the 1688 following parameter as part of the ietf-voucher-request:voucher as 1689 defined in [RFC8995]: 1691 o created-on: contains the current date and time in yang:date-and- 1692 time format for the registrar-voucher-request creation time. 1694 o nonce: copied form the pledge-voucher-request 1696 o serial-number: contains the base64-encoded product-serial-number. 1697 The registrar MUST verify that the product-serial-number contained 1698 in the IDevID certificate of the pledge matches the serial-number 1699 field in the pledge-voucher-request. In addition, it MUST be 1700 equal to the serial-number field contained in the agent-signed 1701 data of pledge-voucher-request. 1703 o assertion: contains the voucher assertion requested the pledge 1704 (agent-proximity). The registrar provides this information to 1705 assure successful verification of agent proximity based on the 1706 agent-signed-data. 1708 The ietf-voucher-request:voucher can be optionally enhanced with the 1709 following additional parameter: 1711 o agent-sign-cert: Contain the base64-encoded LDevID(RegAgt) EE 1712 certificate if MASA verification of agent-proximity is required to 1713 provide the assertion "agent-proximity". 1715 The object is signed using the registrar LDevID(Reg) credential, 1716 which corresponds to the certificate signaled in the JOSE header. 1718 { 1719 "alg": "ES256", 1720 "x5c": ["MIIB2jCC...dA=="] 1721 } 1722 { 1723 "ietf-voucher-request:voucher": { 1724 "created-on": "2021-04-16T02:37:39.235Z", 1725 "nonce": "eDs++/FuDHGUnRxN3E14CQ==", 1726 "serial-number": "callee4711", 1727 "assertion": "agent-proximity", 1728 "prior-signed-voucher-request": "base64encodedvalue==", 1729 "agent-sign-cert": "base64encodedvalue==" 1730 } 1731 } 1732 { 1733 SIGNATURE 1734 } 1736 Figure 10: Example of registrar-voucher-request 1738 The registrar sends the registrar-voucher-request to the MASA with an 1739 HTTPS POST at the endpoint "/.well-known/brski/requestvoucher". 1741 The registrar-voucher-request Content-Type is defined in 1742 [I-D.richardson-anima-jose-voucher] as: 1744 application/voucher-jose+json 1746 The registrar SHOULD include an "Accept" header field indicating the 1747 acceptable media type for the voucher-response. The media type 1748 "application/voucher-jose+json" is defined in 1749 [I-D.richardson-anima-jose-voucher]. 1751 Once the MASA receives the registrar-voucher-request it SHALL perform 1752 the verification of the contained components as described in section 1753 5.5 in [RFC8995]. In addition, the following additional processing 1754 SHALL be done for components contained in the prior-signed-voucher- 1755 request: 1757 o agent-provided-proximity-registrar-cert: The MASA MAY verify that 1758 this field contains the LDevID(Reg) certificate. If so, it MUST 1759 be consistent with the certificate used to sign the registrar- 1760 voucher-request. 1762 o agent-signed-data: The MASA MAY verify this field to be able to 1763 provide an assertion "agent-proximity". If so, the agent-signed- 1764 data MUST contain the product-serial-number of the pledge 1765 contained in the serial-number component of the prior-signed- 1766 voucher and also in serial-number component of the registrar- 1767 voucher-request. The LDevID(RegAgt) used to generate provide the 1768 signature is identified by the "kid" parameter of the JOSE header 1769 (agent-signed-data). If the assertion "agent-proximity" is 1770 requested, the registrar-voucher-request MUST contain the 1771 corresponding LDevID(RegAgt) EE certificate in the agent-sign- 1772 cert, which can be verified by the MASA as issued by the same 1773 domain CA as the LDevID(Reg) EE certificate. If the agent-sign- 1774 cert is not provided, the MASA MAY provide a lower level assertion 1775 "logged" or "verified" 1777 If validation fails, the MASA SHOULD respond with an HTTP error code 1778 to the registrar. The error codes are kept as defined in section 5.6 1779 of [RFC8995]. and comprise the response codes 403, 404, 406, and 1780 415. 1782 The voucher response format is as indicated in the submitted Accept 1783 header fields or based on the MASA's prior understanding of proper 1784 format for this pledge. Specifically for the pledge-responder-mode 1785 the "application/voucher-jose+json" as defined in 1786 [I-D.richardson-anima-jose-voucher] is applied. The syntactic 1787 details of vouchers are described in detail in [RFC8366]. Figure 11 1788 shows an example of the contents of a voucher. 1790 { 1791 "alg": "ES256", 1792 "x5c": ["MIIBkzCCAT...dA=="] 1793 } 1794 { 1795 "ietf-voucher:voucher": { 1796 "assertion": "agent-proximity", 1797 "serial-number": "callee4711", 1798 "nonce": "eDs++/FuDHGUnRxN3E14CQ==", 1799 "created-on": "2021-04-17T00:00:02.000Z", 1800 "pinned-domain-cert": "MIIBpDCCA...w==" 1801 } 1802 } 1803 { 1804 SIGNATURE 1805 } 1807 Figure 11: Example of MASA issued voucher 1809 The MASA sends the voucher in the indicated form to the registrar. 1810 After receiving the voucher the registrar may evaluate the voucher 1811 for transparency and logging purposes as outlined in section 5.6 of 1813 [RFC8995]. The registrar forwards the voucher without changes to the 1814 registrar-agent. 1816 After receiving the voucher, the registrar-agent sends the pledge's 1817 enrollment-request to the registrar. Deviating from BRSKI the 1818 enrollment-request is not a raw PKCS#10 request. As the registrar- 1819 agent is involved in the exchange, the PKCS#10 is contained in the 1820 JOSE object. The signature is created using the pledge's IDevID to 1821 provide proof-of-identity as outlined in Figure 8. 1823 When using EST, the registrar-agent sends the enrollment request to 1824 the registrar with an HTTPS POST at the endpoint "/.well-known/est/ 1825 simpleenroll". 1827 The enrollment-request Content-Type is: 1829 application/jose 1831 If validation of the wrapping signature fails, the registrar SHOULD 1832 respond with the HTTP 404 error code. If the voucher-request is in 1833 an unknown format, then an HTTP 406 error code is more appropriate. 1834 A situation that could be resolved with administrative action (such 1835 as adding a vendor/manufacturer IDevID CA as trusted party) MAY be 1836 responded with an 403 HTTP error code. 1838 This results in a deviation from the content types used in [RFC7030] 1839 and results in additional processing at the domain registrar as EST 1840 server as following. Note that the registrar is already aware that 1841 the bootstrapping is performed in a pledge-responder-mode due to the 1842 use of the LDevID(RegAgt) certificate in the TLS establishment and 1843 the provided pledge-voucher-request in JOSE object. 1845 o If registrar receives the enrollment-request with the Content Type 1846 application/jose, it MUST verify the signature using the 1847 certificate indicated in the JOSE header. 1849 o The domain registrar verifies that the serial-number contained in 1850 the pledge's IDevID certificate contained in the JOSE header as 1851 being accepted to join the domain, based on the verification of 1852 the pledge-voucher-request. 1854 o If both succeed, the registrar utilizes the PKCS#10 request 1855 contained in the JOSE body as "P10" parameter of "ietf-sztp- 1856 csr:csr" for further processing of the enrollment request with the 1857 domain CA. 1859 [RFC Editor: please delete] /* 1860 Open Issues: 1862 o The domain registrar may either enhance the PKCS#10 request or 1863 generate a structure containing the attributes to be included by 1864 the CA and sends both (the original PKCS#10 request and the 1865 enhancements) to the domain CA. As enhancing the PKCS#10 request 1866 destroys the initial proof of possession of the corresponding 1867 private key, the CA would need to accept RA-verified requests. 1869 A successful interaction with the domain CA will result in the pledge 1870 LDevID EE certificate, which is then forwarded by the registrar to 1871 the registrar-agent using the content type "application/pkcs7-mime". 1873 The registrar-agent has now finished the exchanges with the domain 1874 registrar. Now the registrar-agent can supply the voucher-response 1875 (from MASA via Registrar) and the enrollment-response (LDevID EE 1876 certificate) to the pledge. It can close the TLS connection to the 1877 domain registrar and provide the objects to the pledge(s). The 1878 content of the response objects is defined through the voucher 1879 [RFC8366] and the certificate [RFC5280]. 1881 5.2.3.3. Response object supply (registrar-agent - pledge) 1883 The following description assumes that the registrar-agent has 1884 obtained the response objects from the domain registrar. It will re- 1885 start the interaction with the pledge. To contact the pledge, it may 1886 either discover the pledge as described in Section 5.2.2.2 or use 1887 stored information from the first contact with the pledge. 1889 Preconditions in addition to Section 5.2.3.2: 1891 o Registrar-agent: possesses voucher and LDevID certificate. 1893 +--------+ +-----------+ 1894 | Pledge | | Registrar | 1895 | | | Agent | 1896 | | | (RegAgt) | 1897 +--------+ +-----------+ 1898 | | 1899 |<------- supply voucher -----------| 1900 | | 1901 |--------- voucher-status --------->| - store 1902 | | pledge voucher-status 1903 |<--- supply enrollment response ---| 1904 | | 1905 |--------- enroll-status ---------->| - store 1906 | | pledge enroll-status 1908 Figure 12: Response and status handling between pledge and registrar- 1909 agent 1911 The registrar-agent provides the information via two distinct 1912 endpoints to the pledge as following. 1914 The voucher response is provided with a HTTP POST using the operation 1915 path value of "/.well-known/brski/pledge-voucher". 1917 The registrar-agent voucher-response Content-Type header is 1918 "application/voucher-jose+json and contains the voucher as provided 1919 by the MASA. An example if given in Figure 11. 1921 The pledge verifies the voucher as described in section 5.6.1 in 1922 [RFC8995]. 1924 After successful verification the pledge MUST reply with a status 1925 telemetry message as defined in section 5.7 of [RFC8995]. As for the 1926 other objects, the defined object is provided with an additional 1927 signature using JOSE. The pledge generates the voucher-status-object 1928 and provides it in the response message to the registrar-agent. 1930 The response has the Content-Type "application/jose", signed using 1931 the IDevID of the pledge as shown in Figure 13. As the reason field 1932 is optional (see [RFC8995]), it MAY be omitted in case of success. 1934 { 1935 "alg": "ES256", 1936 "x5c": ["MIIB2jCC...dA=="] 1937 { 1938 "version": 1, 1939 "status":true, 1940 "reason":"Informative human readable message", 1941 "reason-context": { "additional" : "JSON" } 1942 } 1943 { 1944 SIGNATURE 1945 } 1947 Figure 13: Example of pledge voucher-status telemetry 1949 The enrollment response is provided with a HTTP POST using the 1950 operation path value of "/.well-known/brski/pledge-enrollment". 1952 The registrar-agent enroll-response Content-Type header when using 1953 EST [RFC7030] as enrollment protocol, from the registrar-agent to the 1954 infrastructure is: 1956 application/pkcs7-mime: note that it only contains the LDevID 1957 certificate for the pledge, not the certificate chain. 1959 [RFC Editor: please delete] /* 1961 Open Issue: the enrollment response object may also be an 1962 application/jose object with a signature of the domain registrar. 1963 This may be used either to transport additional data which is bound 1964 to the LDevID or it may be considered for enrollment status to ensure 1965 that in an error case the registrar providing the certificate can be 1966 identified. */ 1968 After successful verification the pledge MUST reply with a status 1969 telemetry message as defined in section 5.9.4 of [RFC8995]. As for 1970 the other objects, the defined object is provided with an additional 1971 signature using the JOSE. The pledge generates the enrollment status 1972 and provides it in the response message to the registrar-agent. 1974 The response has the Content-Type "application/jose", signed using 1975 the LDevID of the pledge as shown in Figure 14. As the reason field 1976 is optional, it MAY be omitted in case of success. 1978 { 1979 "alg": "ES256", 1980 "x5c": ["MIIB56uz...dA=="] 1981 { 1982 "version": 1, 1983 "status":true, 1984 "reason":"Informative human readable message", 1985 "reason-context": { "additional" : "JSON" } 1986 } 1987 { 1988 SIGNATURE 1989 } 1991 Figure 14: Example of pledge enroll-status telemetry 1993 Once the registrar-agent has collected the information, it can 1994 connect to the registrar agent to provide the status responses to the 1995 registrar. 1997 5.2.3.4. Telemetry status handling (registrar-agent - domain registrar) 1999 The following description assumes that the registrar-agent has 2000 collected the status objects from the pledge. It will provide the 2001 status objects to the registrar for further processing and audit log 2002 information of voucher-status for MASA. 2004 Preconditions in addition to Section 5.2.3.2: 2006 o Registrar-agent: possesses voucher-status and enroll-status 2007 objects from pledge. 2009 +-----------+ +-----------+ +--------+ +---------+ 2010 | Registrar | | Domain | | Domain | | Vendor | 2011 | Agent | | Registrar | | CA | | Service | 2012 | RegAgt) | | (JRC) | | | | (MASA) | 2013 +-----------+ +-----------+ +--------+ +---------+ 2014 | | | Internet | 2015 | | | | 2016 |<------ TLS ----->| | | 2017 | | | | 2018 |--Voucher-Status->| | | 2019 | |<---- device audit log ----| 2020 | [verify audit log ] 2021 | | | | 2022 |--Enroll-Status-->| | | 2023 | | | | 2024 | | | | 2026 Figure 15: Bootstrapping status handling 2028 The registrar-agent MUST provide the collected pledge voucher-status 2029 to the registrar. This status indicates the pledge could process the 2030 voucher successfully or not. 2032 If the TLS connection to the registrar was closed, the registrar- 2033 agent establishes a TLS connection with the registrar as stated in 2034 Section 5.2.3.2. 2036 The registrar-agent sends the pledge voucher-status object without 2037 modification to the registrar with an HTTPS POST using the operation 2038 path value of "/.well-known/brski/voucher_status". The Content-Type 2039 header is kept as "application/jose" as described in Figure 12 and 2040 depicted in the example in Figure 13. 2042 The registrar SHALL verify the signature of the pledge voucher-status 2043 and validate that it belongs to an accepted device in his domain 2044 based on the contained "serial-number" in the IDevID certificate 2045 referenced in the header of the voucher-status object. 2047 According to [RFC8995] section 5.7, the registrar SHOULD respond with 2048 an HTTP 200 but MAY simply fail with an HTTP 404 error. The 2049 registrar-agent may use the response to signal success / failure to 2050 the service technician operating the registrar agent. Within the 2051 server logs the server SHOULD capture this telemetry information. 2053 The registrar SHOULD proceed with the collecting and logging the 2054 status information by requesting the MASA audit-log from the MASA 2055 service as described in section 5.8 of [RFC8995]. 2057 The registrar-agent MUST provide the enroll-status object to the 2058 registrar. The status indicates the pledge could process the enroll- 2059 response object and holds the corresponding private key. 2061 The registrar-agent sends the pledge enroll-status object without 2062 modification to the registrar with an HTTPS POST using the operation 2063 path value of "/.well-known/brski/enrollstatus". The Content-Type 2064 header is kept as "application/jose" as described in Figure 12 and 2065 depicted in the example in Figure 14. 2067 The registrar SHALL verify the signature of the pledge enroll-status 2068 object and validate that it belongs to an accepted device in his 2069 domain based on the contained product-serial-number in the LDevID EE 2070 certificate referenced in the header of the enroll-status object. 2071 Note that the verification of a signature of the object is a 2072 deviation form the described handling in section 5.9.4 of [RFC8995]. 2074 According to [RFC8995] section 5.9.4, the registrar SHOULD respond 2075 with an HTTP 200 but MAY simply fail with an HTTP 404 error. The 2076 registrar-agent may use the response to signal success / failure to 2077 the service technician operating the registrar agent. Within the 2078 server log the registrar SHOULD capture this telemetry information. 2080 5.3. Domain registrar support of different enrollment options 2082 Well-known URIs for different endpoints on the domain registrar are 2083 already defined as part of the base BRSKI specification. In 2084 addition, alternative enrollment endpoints may be supported at the 2085 domain registrar. The pledge / registrar-agent will recognize if its 2086 supported enrollment option is supported by the domain registrar by 2087 sending a request to its preferred enrollment endpoint. 2089 The following provides an illustrative example for a domain registrar 2090 supporting different options for EST as well as CMP to be used in 2091 BRSKI-AE. The listing contains the supported endpoints for the 2092 bootstrapping, to which the pledge may connect. This includes the 2093 voucher handling as well as the enrollment endpoints. The CMP 2094 related enrollment endpoints are defined as well-known URI in CMP 2095 Updates [I-D.ietf-lamps-cmp-updates]. 2097 ,ct=voucher-cms+json 2098 ,ct=json 2099 ,ct=json 2100 ;ct=pkcs7-mime 2101 ;ct=pkcs7-mime 2102 ;ct=pkcs7-mime 2103 ;ct=pkcs7-mime 2104 ;ct= pkcs7-mime 2105 ;ct=pkcs7-mime 2106 ;ct=pkixcmp 2107 ;ct=pkixcmp 2108 ;ct=pkixcmp 2109 ;ct=pkixcmp 2110 ;ct=pkixcmp 2111 ;ct=pkixcmp 2113 [RFC Editor: please delete] /* 2115 Open Issues: 2117 o In addition to the current content types, we may specify that the 2118 response provide information about different content types as 2119 multiple values. This would allow to further adopt the encoding 2120 of the objects exchanges (ASN.1, JSON, CBOR, ...). -> dependent on 2121 the utilized protocol. */ 2123 6. YANG Extensions to Voucher Request 2125 The following modules extends the [RFC8995] Voucher Request to 2126 include a signed artifact from the registrar-agent as well as the 2127 registrar-proximity-certificate and the agent-signing certificate. 2129 module ietf-async-voucher-request { 2130 yang-version 1.1; 2132 namespace 2133 "urn:ietf:params:xml:ns:yang:ietf-async-voucher-request"; 2134 prefix "constrained"; 2136 import ietf-restconf { 2137 prefix rc; 2138 description 2139 "This import statement is only present to access 2140 the yang-data extension defined in RFC 8040."; 2141 reference "RFC 8040: RESTCONF Protocol"; 2142 } 2143 import ietf-voucher-request { 2144 prefix ivr; 2145 description 2146 "This module defines the format for a voucher request, 2147 which is produced by a pledge as part of the RFC8995 2148 onboarding process."; 2149 reference 2150 "RFC 8995: Bootstrapping Remote Secure Key Infrastructure"; 2151 } 2153 organization 2154 "IETF ANIMA Working Group"; 2156 contact 2157 "WG Web: 2158 WG List: 2159 Author: Steffen Fries 2160 2161 Author: Hendrik Brockhaus 2162 2163 Author: Eliot Lear 2164 "; 2165 Author: Thomas Werner 2166 "; 2167 description 2168 "This module defines an extension of the RFC8995 voucher 2169 request to permit a registrar-agent to convey the adjacency 2170 relationship from the registrar-agent to the registrar. 2172 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 2173 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 2174 and 'OPTIONAL' in the module text are to be interpreted as 2175 described in RFC 2119."; 2176 revision "YYYY-MM-DD" { 2177 description 2178 "Initial version"; 2179 reference 2180 "RFC XXXX: Voucher Request for Asynchronous Enrollment"; 2181 } 2182 rc:yang-data voucher-request-async-artifact { 2183 // YANG data template for a voucher. 2184 uses voucher-request-async-grouping; 2185 } 2186 // Grouping defined for future usage 2187 grouping voucher-request-async-grouping { 2188 description 2189 "Grouping to allow reuse/extensions in future work."; 2190 uses ivr:voucher-request-grouping { 2191 augment "voucher-request" { 2192 description "Base the constrained voucher-request upon the 2193 regular one"; 2194 leaf agent-signed-data { 2195 type binary; 2196 description 2197 "The agent-signed-data field contains a JOSE [RFC7515] 2198 object provided by the Registrar-Agent to the Pledge. 2200 This artifact is signed by the Registrar-Agent 2201 and contains a copy of the pledge's serial-number."; 2202 } 2204 leaf agent-provided-proximity-registrar-cert { 2205 type binary; 2206 description 2207 "An X.509 v3 certificate structure, as specified by 2208 RFC 5280, Section 4, encoded using the ASN.1 2209 distinguished encoding rules (DER), as specified 2210 in ITU X.690. 2211 The first certificate in the registrar TLS server 2212 certificate_list sequence (the end-entity TLS 2213 certificate; see RFC 8446) presented by the 2214 registrar to the registrar-agent and provided to 2215 the pledge. 2216 This MUST be populated in a pledge's voucher-request 2217 when an agent-proximity assertion is requested."; 2218 reference 2219 "ITU X.690: Information Technology - ASN.1 encoding 2220 rules: Specification of Basic Encoding Rules (BER), 2221 Canonical Encoding Rules (CER) and Distinguished 2222 Encoding Rules (DER) 2223 RFC 5280: Internet X.509 Public Key Infrastructure 2224 Certificate and Certificate Revocation List (CRL) 2225 Profile 2226 RFC 8446: The Transport Layer Security (TLS) 2227 Protocol Version 1.3"; 2228 } 2230 leaf agent-sign-cert { 2231 type binary; 2232 description 2233 "An X.509 v3 certificate structure, as specified by 2234 RFC 5280, Section 4, encoded using the ASN.1 2235 distinguished encoding rules (DER), as specified 2236 in ITU X.690. 2237 This certificate can be used by the pledge, 2238 the registrar, and the MASA to verify the signature 2239 of agent-signed-data. It is an optional component 2240 for the pledge-voucher request. 2241 This MUST be populated in a registrar's 2242 voucher-request when an agent-proximity assertion 2243 is requested."; 2244 reference 2245 "ITU X.690: Information Technology - ASN.1 encoding 2246 rules: Specification of Basic Encoding Rules (BER), 2247 Canonical Encoding Rules (CER) and Distinguished 2248 Encoding Rules (DER) 2249 RFC 5280: Internet X.509 Public Key Infrastructure 2250 Certificate and Certificate Revocation List (CRL) 2251 Profile"; 2252 } 2253 } 2254 } 2255 } 2256 } 2258 7. Example for signature-wrapping using existing enrollment protocols 2260 This section map the requirements to support proof of possession and 2261 proof of identity to selected existing enrollment protocols. Note 2262 that that the work in the ACE WG described in 2263 [I-D.selander-ace-coap-est-oscore] may be considered here as well, as 2264 it also addresses the encapsulation of EST in a way to make it 2265 independent from the underlying TLS using OSCORE resulting in an 2266 authenticated self-contained object. 2268 7.1. EST Handling 2270 When using EST [RFC7030], the following constraints should be 2271 considered: 2273 o Proof of possession is provided by using the specified PKCS#10 2274 structure in the request. 2276 o Proof of identity is achieved by signing the certification request 2277 object, which is only supported when Full PKI Request (the 2278 /fullcmc endpoint) is used. This contains sufficient information 2279 for the RA to make an authorization decision on the received 2280 certification request. Note: EST references CMC [RFC5272] for the 2281 definition of the Full PKI Request. For proof of identity, the 2282 signature of the SignedData of the Full PKI Request would be 2283 calculated using the IDevID credential of the pledge. 2285 o [RFC Editor: please delete] /* TBD: in this case the binding to 2286 the underlying TLS connection is not be necessary. */ 2288 o When the RA is not available, as per [RFC7030] Section 4.2.3, a 2289 202 return code should be returned by the Registrar. The pledge 2290 in this case would retry a simpleenroll with a PKCS#10 request. 2291 Note that if the TLS connection is teared down for the waiting 2292 time, the PKCS#10 request would need to be rebuilt if it contains 2293 the unique identifier (tls_unique) from the underlying TLS 2294 connection for the binding. 2296 o [RFC Editor: please delete] /* TBD: clarification of retry for 2297 fullcmc is necessary as not specified in the context of EST */ 2299 7.2. CMP Handling 2301 Instead of using CMP [RFC4210], this specification refers to the 2302 lightweight CMP profile [I-D.ietf-lamps-lightweight-cmp-profile], as 2303 it restricts the full featured CMP to the functionality needed here. 2304 For this, the following constrains should be observed: 2306 o For proof of possession, the defined approach in Lightweight CMP 2307 Profile section 4.1.1 (based on CRMF) and 4.1.5 (based on PCKS#10) 2308 should be supported. 2310 o Proof of identity can be provided by using the signatures to 2311 protect the certificate request message as outlined in section 2312 3.2. of [I-D.ietf-lamps-lightweight-cmp-profile]. 2314 o When the RA/CA is not available, a waiting indication should be 2315 returned in the PKIStatus by the Registrar. The pledge in this 2316 case would retry using the PollReqContent with a request 2317 identifier certReqId provided in the initial CertRequest message 2318 as specified in section 5.2.4 of 2319 [I-D.ietf-lamps-lightweight-cmp-profile] with delayed enrollment. 2321 8. IANA Considerations 2323 This document requires the following IANA actions: 2325 IANA is requested to enhance the Registry entitled: "BRSKI well- 2326 known URIs" with the following: 2328 URI document description 2329 pledge-voucher-request [THISRFC] create pledge-voucher-request 2330 pledge-enrollment-request [THISRFC] create pledge-enrollment-request 2331 pledge-voucher [THISRFC] supply voucher response 2332 pledge-enrollment [THISRFC] supply enrollment response 2333 pledge-CACerts [THISRFC] supply CA certs to pledge 2335 9. Privacy Considerations 2337 The credential used by the registrar-agent to sign the data for the 2338 pledge in case of the pledge-initiator-mode should not contain 2339 personal information. Therefore, it is recommended to use an LDevID 2340 certificate associated with the device instead of a potential service 2341 technician operating the device, to avoid revealing this information 2342 to the MASA. 2344 10. Security Considerations 2346 10.1. Exhaustion attack on pledge 2348 Exhaustion attack on pledge based on DoS attack (connection 2349 establishment, etc.) 2351 10.2. Misuse of acquired voucher and enrollment responses 2353 Registrar-agent that uses acquired voucher and enrollment response 2354 for domain 1 in domain 2: can be detected in Voucher Request 2355 processing on domain registrar side. Requires domain registrar to 2356 verify the proximity-registrar-cert leaf in the pledge-voucher- 2357 request against his own as well as the association of the pledge to 2358 his domain based on the product-serial-number contained in the 2359 voucher. 2361 Misbinding of pledge by a faked domain registrar is countered as 2362 described in BRSKI security considerations (section 11.4). 2364 Misuse of registrar-agent LDevID may be addressed by utilizing short- 2365 lived certificates to be used for authenticating the registrar-agent 2366 against the registrar. The LDevID certificate for the registrar- 2367 agent may be provided by a prior BRSKI execution based on an existing 2368 IDevID. Alternatively, the LDevID may be acquired by a service 2369 technician after authentication against the issuing CA. 2371 11. Acknowledgments 2373 We would like to thank the various reviewers for their input, in 2374 particular Brian E. Carpenter, Michael Richardson, Giorgio 2375 Romanenghi, Oskar Camenzind, for their input and discussion on use 2376 cases and call flows. 2378 12. References 2379 12.1. Normative References 2381 [I-D.ietf-netconf-sztp-csr] 2382 Watsen, K., Housley, R., and S. Turner, "Conveying a 2383 Certificate Signing Request (CSR) in a Secure Zero Touch 2384 Provisioning (SZTP) Bootstrapping Request", draft-ietf- 2385 netconf-sztp-csr-03 (work in progress), June 2021. 2387 [I-D.richardson-anima-jose-voucher] 2388 Richardson, M. and T. Werner, "JOSE signed Voucher 2389 Artifacts for Bootstrapping Protocols", draft-richardson- 2390 anima-jose-voucher-01 (work in progress), June 2021. 2392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2393 Requirement Levels", BCP 14, RFC 2119, 2394 DOI 10.17487/RFC2119, March 1997, 2395 . 2397 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2398 DOI 10.17487/RFC6762, February 2013, 2399 . 2401 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2402 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2403 . 2405 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 2406 "Enrollment over Secure Transport", RFC 7030, 2407 DOI 10.17487/RFC7030, October 2013, 2408 . 2410 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 2411 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2412 2015, . 2414 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2415 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2416 May 2017, . 2418 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2419 "A Voucher Artifact for Bootstrapping Protocols", 2420 RFC 8366, DOI 10.17487/RFC8366, May 2018, 2421 . 2423 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2424 and K. Watsen, "Bootstrapping Remote Secure Key 2425 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 2426 May 2021, . 2428 12.2. Informative References 2430 [I-D.ietf-lamps-cmp-updates] 2431 Brockhaus, H. and D. V. Oheimb, "Certificate Management 2432 Protocol (CMP) Updates", draft-ietf-lamps-cmp-updates-10 2433 (work in progress), May 2021. 2435 [I-D.ietf-lamps-lightweight-cmp-profile] 2436 Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight 2437 Certificate Management Protocol (CMP) Profile", draft- 2438 ietf-lamps-lightweight-cmp-profile-05 (work in progress), 2439 February 2021. 2441 [I-D.selander-ace-coap-est-oscore] 2442 Selander, G., Raza, S., Furuhed, M., Vucinic, M., and T. 2443 Claeys, "Protecting EST Payloads with OSCORE", draft- 2444 selander-ace-coap-est-oscore-05 (work in progress), May 2445 2021. 2447 [IEC-62351-9] 2448 International Electrotechnical Commission, "IEC 62351 - 2449 Power systems management and associated information 2450 exchange - Data and communications security - Part 9: 2451 Cyber security key management for power system equipment", 2452 IEC 62351-9 , May 2017. 2454 [IEEE-802.1AR] 2455 Institute of Electrical and Electronics Engineers, "IEEE 2456 802.1AR Secure Device Identifier", IEEE 802.1AR , June 2457 2018. 2459 [ISO-IEC-15118-2] 2460 International Standardization Organization / International 2461 Electrotechnical Commission, "ISO/IEC 15118-2 Road 2462 vehicles - Vehicle-to-Grid Communication Interface - Part 2463 2: Network and application protocol requirements", ISO/ 2464 IEC 15118-2 , April 2014. 2466 [NERC-CIP-005-5] 2467 North American Reliability Council, "Cyber Security - 2468 Electronic Security Perimeter", CIP 005-5, December 2013. 2470 [OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0.1 2471 (Draft)", December 2019. 2473 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 2474 Request Syntax Specification Version 1.7", RFC 2986, 2475 DOI 10.17487/RFC2986, November 2000, 2476 . 2478 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 2479 "Internet X.509 Public Key Infrastructure Certificate 2480 Management Protocol (CMP)", RFC 4210, 2481 DOI 10.17487/RFC4210, September 2005, 2482 . 2484 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 2485 Certificate Request Message Format (CRMF)", RFC 4211, 2486 DOI 10.17487/RFC4211, September 2005, 2487 . 2489 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 2490 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 2491 . 2493 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2494 Housley, R., and W. Polk, "Internet X.509 Public Key 2495 Infrastructure Certificate and Certificate Revocation List 2496 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2497 . 2499 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2500 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2501 . 2503 [RFC8894] Gutmann, P., "Simple Certificate Enrolment Protocol", 2504 RFC 8894, DOI 10.17487/RFC8894, September 2020, 2505 . 2507 Appendix A. History of changes [RFC Editor: please delete] 2509 From IETF draft 02 -> IETF draft 03: 2511 o Housekeeping, deleted open issue regarding YANG voucher-request in 2512 Section 5.2.3.1 as voucher-request was enhanced with additional 2513 leaf. 2515 o Included open issues in YANG model in Section 5.2 regarding 2516 assertion value agent-proximity and csr encapsulation using SZTP 2517 sub module). 2519 From IETF draft 01 -> IETF draft 02: 2521 o Defined call flow and objects for interactions in UC2. Object 2522 format based on draft for JOSE signed voucher artifacts and 2523 aligned the remaining objects with this approach in Section 5.2.3 2524 . 2526 o Terminology change: issue #2 pledge-agent -> registrar-agent to 2527 better underline agent relation. 2529 o Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode 2530 and pledge-responder-mode to better address the pledge operation. 2532 o Communication approach between pledge and registrar-agent changed 2533 by removing TLS-PSK (former section TLS establishment) and 2534 associated references to other drafts in favor of relying on 2535 higher layer exchange of signed data objects. These data objects 2536 are included also in the pledge-voucher-request and lead to an 2537 extension of the YANG module for the voucher-request (issue #12). 2539 o Details on trust relationship between registrar-agent and 2540 registrar (issue #4, #5, #9) included in Section 5.2. 2542 o Recommendation regarding short-lived certificates for registrar- 2543 agent authentication towards registrar (issue #7) in the security 2544 considerations. 2546 o Introduction of reference to agent signing certificate using SKID 2547 in agent signed data (issue #11). 2549 o Enhanced objects in exchanges between pledge and registrar-agent 2550 to allow the registrar to verify agent-proximity to the pledge 2551 (issue #1) in Section 5.2.3. 2553 o Details on trust relationship between registrar-agent and pledge 2554 (issue #5) included in Section 5.2. 2556 o Split of use case 2 call flow into sub sections in Section 5.2.3. 2558 From IETF draft 00 -> IETF draft 01: 2560 o Update of scope in Section 3.1 to include in which the pledge acts 2561 as a server. This is one main motivation for use case 2. 2563 o Rework of use case 2 in Section 5.2 to consider the transport 2564 between the pledge and the pledge-agent. Addressed is the TLS 2565 channel establishment between the pledge-agent and the pledge as 2566 well as the endpoint definition on the pledge. 2568 o First description of exchanged object types (needs more work) 2569 o Clarification in discovery options for enrollment endpoints at the 2570 domain registrar based on well-known endpoints in Section 5.3 do 2571 not result in additional /.well-known URIs. Update of the 2572 illustrative example. Note that the change to /brski for the 2573 voucher related endpoints has been taken over in the BRSKI main 2574 document. 2576 o Updated references. 2578 o Included Thomas Werner as additional author for the document. 2580 From individual version 03 -> IETF draft 00: 2582 o Inclusion of discovery options of enrollment endpoints at the 2583 domain registrar based on well-known endpoints in Section 5.3 as 2584 replacement of section 5.1.3 in the individual draft. This is 2585 intended to support both use cases in the document. An 2586 illustrative example is provided. 2588 o Missing details provided for the description and call flow in 2589 pledge-agent use case Section 5.2, e.g. to accommodate 2590 distribution of CA certificates. 2592 o Updated CMP example in Section 7 to use lightweight CMP instead of 2593 CMP, as the draft already provides the necessary /.well-known 2594 endpoints. 2596 o Requirements discussion moved to separate section in Section 4. 2597 Shortened description of proof of identity binding and mapping to 2598 existing protocols. 2600 o Removal of copied call flows for voucher exchange and registrar 2601 discovery flow from [RFC8995] in Section 5.1 to avoid doubling or 2602 text or inconsistencies. 2604 o Reworked abstract and introduction to be more crisp regarding the 2605 targeted solution. Several structural changes in the document to 2606 have a better distinction between requirements, use case 2607 description, and solution description as separate sections. 2608 History moved to appendix. 2610 From individual version 02 -> 03: 2612 o Update of terminology from self-contained to authenticated self- 2613 contained object to be consistent in the wording and to underline 2614 the protection of the object with an existing credential. Note 2615 that the naming of this object may be discussed. An alternative 2616 name may be attestation object. 2618 o Simplification of the architecture approach for the initial use 2619 case having an offsite PKI. 2621 o Introduction of a new use case utilizing authenticated self- 2622 contain objects to onboard a pledge using a commissioning tool 2623 containing a pledge-agent. This requires additional changes in 2624 the BRSKI call flow sequence and led to changes in the 2625 introduction, the application example,and also in the related 2626 BRSKI-AE call flow. 2628 o Update of provided examples of the addressing approach used in 2629 BRSKI to allow for support of multiple enrollment protocols in 2630 Section 5.1.5. 2632 From individual version 01 -> 02: 2634 o Update of introduction text to clearly relate to the usage of 2635 IDevID and LDevID. 2637 o Definition of the addressing approach used in BRSKI to allow for 2638 support of multiple enrollment protocols in Section 5.1.5. This 2639 section also contains a first discussion of an optional discovery 2640 mechanism to address situations in which the registrar supports 2641 more than one enrollment approach. Discovery should avoid that 2642 the pledge performs a trial and error of enrollment protocols. 2644 o Update of description of architecture elements and changes to 2645 BRSKI in Section 5. 2647 o Enhanced consideration of existing enrollment protocols in the 2648 context of mapping the requirements to existing solutions in 2649 Section 4 and in Section 7. 2651 From individual version 00 -> 01: 2653 o Update of examples, specifically for building automation as well 2654 as two new application use cases in Section 3.2. 2656 o Deletion of asynchronous interaction with MASA to not complicate 2657 the use case. Note that the voucher exchange can already be 2658 handled in an asynchronous manner and is therefore not considered 2659 further. This resulted in removal of the alternative path the 2660 MASA in Figure 1 and the associated description in Section 5. 2662 o Enhancement of description of architecture elements and changes to 2663 BRSKI in Section 5. 2665 o Consideration of existing enrollment protocols in the context of 2666 mapping the requirements to existing solutions in Section 4. 2668 o New section starting Section 7 with the mapping to existing 2669 enrollment protocols by collecting boundary conditions. 2671 Authors' Addresses 2673 Steffen Fries 2674 Siemens AG 2675 Otto-Hahn-Ring 6 2676 Munich, Bavaria 81739 2677 Germany 2679 Email: steffen.fries@siemens.com 2680 URI: https://www.siemens.com/ 2682 Hendrik Brockhaus 2683 Siemens AG 2684 Otto-Hahn-Ring 6 2685 Munich, Bavaria 81739 2686 Germany 2688 Email: hendrik.brockhaus@siemens.com 2689 URI: https://www.siemens.com/ 2691 Eliot Lear 2692 Cisco Systems 2693 Richtistrasse 7 2694 Wallisellen CH-8304 2695 Switzerland 2697 Phone: +41 44 878 9200 2698 Email: lear@cisco.com 2700 Thomas Werner 2701 Siemens AG 2702 Otto-Hahn-Ring 6 2703 Munich, Bavaria 81739 2704 Germany 2706 Email: thomas-werner@siemens.com 2707 URI: https://www.siemens.com/