idnits 2.17.00 (12 Aug 2021) /tmp/idnits15763/draft-ietf-anima-brski-prm-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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: ---------------------------------------------------------------------------- == Line 2112 has weird spacing: '...request creat...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * The communication between the registrar-agent and the pledge MUST not rely on transport layer security (TLS) to support also other technology stacks (e.g., BTLE). Therefore authenticated self-contained objects are required. -- The document date (29 April 2022) is 15 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 2116, but not defined Summary: 2 errors (**), 0 flaws (~~), 4 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 T. Werner 4 Intended status: Standards Track Siemens 5 Expires: 31 October 2022 E. Lear 6 Cisco Systems 7 M. Richardson 8 Sandelman Software Works 9 29 April 2022 11 BRSKI with Pledge in Responder Mode (BRSKI-PRM) 12 draft-ietf-anima-brski-prm-03 14 Abstract 16 This document defines enhancements to bootstrapping a remote secure 17 key infrastructure (BRSKI, [RFC8995]) to facilitate bootstrapping in 18 domains featuring no or only timely limited connectivity between a 19 pledge and the domain registrar. It specifically targets situations, 20 in which the interaction model changes from a pledge-initiator-mode, 21 as used in BRSKI, to a pledge-responder-mode as described in this 22 document. To support both, BRSKI-PRM introduces a new registrar- 23 agent component, which facilitates the communication between pledge 24 and registrar during the bootstrapping phase. For the establishment 25 of a trust relation between pledge and domain registrar, BRSKI-PRM 26 relies on the exchange of authenticated self-contained objects 27 (signature-wrapped objects). The defined approach is agnostic 28 regarding the utilized enrollment protocol, deployed by the domain 29 registrar to communicate with the Domain CA. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 31 October 2022. 48 Copyright Notice 50 Copyright (c) 2022 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Scope of Solution . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Supported Environment . . . . . . . . . . . . . . . . . . 6 68 3.2. Application Examples . . . . . . . . . . . . . . . . . . 6 69 3.2.1. Building Automation . . . . . . . . . . . . . . . . . 6 70 3.2.2. Infrastructure Isolation Policy . . . . . . . . . . . 7 71 3.2.3. Less Operational Security in the Target-Domain . . . 7 72 3.3. Limitations . . . . . . . . . . . . . . . . . . . . . . . 7 73 4. Requirements Discussion and Mapping to Solution-Elements . . 7 74 5. Architectural Overview and Communication Exchanges . . . . . 9 75 5.1. Pledge-responder-mode (PRM): Registrar-agent Communication 76 with Pledges . . . . . . . . . . . . . . . . . . . . . . 10 77 5.2. Agent-Proximity Assertion . . . . . . . . . . . . . . . . 13 78 5.3. Behavior of Pledge in Pledge-Responder-Mode . . . . . . . 14 79 5.4. Behavior of Registrar-Agent . . . . . . . . . . . . . . . 15 80 5.4.1. Discovery of Registrar by Registrar-Agent . . . . . . 17 81 5.4.2. Discovery of Pledge by Registrar-Agent . . . . . . . 17 82 5.5. Bootstrapping Objects and Corresponding Exchanges . . . . 17 83 5.5.1. Request Objects Acquisition by Registrar-Agent from 84 Pledge . . . . . . . . . . . . . . . . . . . . . . . 20 85 5.5.2. Request Processing by the Registrar-Agent . . . . . . 28 86 5.5.3. Response Object Supply by Registrar-Agent to 87 Pledge . . . . . . . . . . . . . . . . . . . . . . . 38 88 5.5.4. Telemetry status handling (registrar-agent - domain 89 registrar) . . . . . . . . . . . . . . . . . . . . . 42 90 6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 44 91 6.1. Voucher Request Artifact . . . . . . . . . . . . . . . . 44 92 6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 44 93 6.1.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 44 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 95 7.1. BRSKI .well-known Registry . . . . . . . . . . . . . . . 48 97 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 99 9.1. Exhaustion Attack on Pledge . . . . . . . . . . . . . . . 49 100 9.2. Misuse of acquired Voucher and Enrollment objects by 101 Registrar-Agent . . . . . . . . . . . . . . . . . . . . . 49 102 9.3. Misuse of Registrar-Agent Credentials . . . . . . . . . . 50 103 9.4. YANG Module Security Considerations . . . . . . . . . . . 50 104 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 106 11.1. Normative References . . . . . . . . . . . . . . . . . . 51 107 11.2. Informative References . . . . . . . . . . . . . . . . . 52 108 Appendix A. History of Changes [RFC Editor: please delete] . . . 53 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 111 1. Introduction 113 BRSKI as defined in [RFC8995] specifies a solution for secure zero- 114 touch (automated) bootstrapping of devices (pledges) in a (customer) 115 site domain. This includes the discovery of network elements in the 116 customer site/domain and the exchange of security information 117 necessary to establish trust between a pledge and the domain. 119 Security information about the customer site/domain, specifically the 120 customer site/domain certificate, is exchanged utilizing voucher 121 objects as defined in [RFC8366]. These vouchers are signed objects, 122 provided via the domain registrar to the pledge and originate from a 123 Manufacturer's Authorized Signing Authority (MASA). 125 BRSKI addresses scenarios in which the pledge acts as client for the 126 bootstrapping and is the initiator of the bootstrapping (this 127 document refers to the approach as pledge-initiator-mode). In 128 industrial environments the pledge may behave as a server and thus 129 does not initiate the bootstrapping with the domain registrar. In 130 this scenarios it is expected that the pledge will be triggered to 131 generate request objects to be bootstrapped in the customer site/ 132 domain (this document refers to the approach as pledge-responder- 133 mode). For this, an additional component is introduced acting as an 134 agent for the domain registrar (registrar-agent) towards the pledge. 135 This may be a functionality of a commissioning or configuration tool 136 or it may be even co-located with the registrar. 138 In contrast to BRSKI the registrar-agent facilitates the object 139 exchange with the pledge and provides/retrieves data objects to/from 140 the domain registrar. For the interaction with the domain registrar 141 the registrar-agent will use existing BRSKI [RFC8995] endpoints. 143 The goal is to enhance BRSKI to support pledges in responder mode. 144 This is addressed by 145 * introducing the registrar-agent as new component to facilitate the 146 communication between the pledge and the registrar, if the pledge 147 is in responder mode (acting as server). 149 * handling the security on application layer only to enable 150 application of arbitrary transport means between the pledge and 151 the domain registrar, by keeping the registrar-agent in the 152 communication path. Examples may be connectivity via IP based 153 networks (wired or wireless) but also connectivity via Bluetooth 154 or NFC between the pledge and the registrar-agent. 156 * allowing to utilize credentials different from the pledge's IDevID 157 to establish a TLS connection to the domain registrar, which is 158 necessary in case of using a registrar-agent. 160 * defining the interaction (data exchange and data objects) between 161 a pledge acting as server and a registrar-agent and the domain 162 registrar. 164 For the enrollment of devices BRSKI relies on EST [RFC7030] to 165 request and distribute customer site/domain specific device 166 certificates. EST in turn relies on a binding of the certification 167 request to an underlying TLS connection between the EST client and 168 the EST server. According to BRSKI the domain registrar acts as EST 169 server and is also acting as registration authority (RA) for its 170 domain. To utilize the EST server endpoints on the domain-registrar, 171 the registrar-agent defined in this document will act as client 172 towards the domain registrar. The registrar-agent will also act as 173 client when communicating with the pledge in responder mode. Here, 174 TLS with server-side, certificate-based authentication is not 175 directly applicable, as the pledge only possesses an IDevID 176 certificate, which does not contain a subject alternative name (SAN) 177 for the customer site/domain and does also not contain a TLS server 178 flag. This is one reason for relying on higher layer security by 179 using signature wrapped objects for the exchange between the pledge 180 and the registrar agent. A further reason is the application on 181 different transports, for which TLS may not be available, like 182 Bluetooth or NFC. As the described solution will rely on additional 183 wrapping signature it will require pre-processing specifically for 184 EST. EST simpleenroll uses PKCS#10 requests only. 186 2. Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in 191 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 This document relies on the terminology defined in [RFC8995], section 195 1.2. The following terms are defined additionally: 197 authenticated self-contained object: Describes an object, which is 198 cryptographically bound to the end entity (EE) certificate (IDevID 199 certificate or LDEVID certificate). The binding is assumed to be 200 provided through a digital signature of the actual object using 201 the corresponding private key of the EE certificate. 203 CA: Certification authority, issues certificates. 205 Commissioning tool: Tool to interact with devices to provide 206 configuration data 208 EE: End entity 210 on-site: Describes a component or service or functionality available 211 in the customer site/domain. 213 off-site: Describes a component or service or functionality not 214 available in the customer site/domain. This may be a central site 215 or a cloud service, to which only a temporary connection is 216 available, or which is in a different administrative domain. 218 PER: Pledge-enrollment-request 220 POP: Proof of possession (of a private key) 222 POI: Proof of identity 224 PVR: Pledge-voucher-request 226 RA: Registration authority, an optional system component to which a 227 CA delegates certificate management functions such as 228 authorization checks. 230 RER: Registrar-enrollment-request 232 RVR: Registrar-voucher-request 234 3. Scope of Solution 235 3.1. Supported Environment 237 The described solution is applicable in environments in which pledges 238 have a different technology stack or pledges have no direct 239 connection to the domain registrar, but are expected to be managed by 240 this registrar. This can be motivated by pledges deployed in 241 networks not connected to the operational customer site/domain, e.g., 242 during construction of a site. Another application is the 243 preparation of cabinets, which are to be prepared to be installed on 244 a customer site/domain. As there is no direct connection to the 245 registrar available in these environments the solution specified in 246 this document lets the pledges act in a server role so that they can 247 be accessed by a commissioning tool to trigger the bootstrapping. As 248 BRSKI focuses on the pledge in a client role, initiating the 249 bootstrapping, this document defines pledges acting as a server 250 answering to requests for pledge-voucher-request objects and 251 certification objects. 253 3.2. Application Examples 255 The following examples are intended to motivate the support of 256 additional bootstrapping approaches. Industrial application use 257 cases are introduced, which could leverage BRSKI as such but 258 additionally require to support pledges acting as server only 259 responding to requests, as well as scenarios with limited 260 connectivity to the registrar. 262 3.2.1. Building Automation 264 In building automation a typical use case exists where a detached 265 building (or a cabinet) or the basement of a building is equipped 266 with sensors, actuators and controllers, but with only limited or no 267 connection to the central building management system. This limited 268 connectivity may exist during installation time or also during 269 operation time. During the installation in the basement, a service 270 technician collects the device specific information from the basement 271 network and provides them to the central building management system, 272 e.g., using a laptop or a mobile device to transport the information. 273 A domain registrar may be part of the central building management 274 system and already be operational in the installation network. The 275 central building management system can then provide operational 276 parameters for the specific devices in the basement. This 277 operational parameters may comprise values and settings required in 278 the operational phase of the sensors/actuators, among them a 279 certificate issued by the operator to authenticate against other 280 components and services. These operational parameters are then 281 provided to the devices in the basement facilitated by the service 282 technician's laptop. 284 3.2.2. Infrastructure Isolation Policy 286 This refers to any case in which the network infrastructure is 287 normally isolated from the Internet as a matter of policy, most 288 likely for security reasons. In such a case, limited access to a 289 domain registrar may be allowed in carefully controlled short periods 290 of time, for example when a batch of new devices are deployed, but 291 prohibited at other times. 293 3.2.3. Less Operational Security in the Target-Domain 295 The registration authority (RA) performing the authorization of a 296 certificate request is a critical PKI component and therefore 297 requires higher operational security than other components utilizing 298 the issued certificates . CAs may also require higher security in the 299 registration procedures. Especially the CA/Browser forum currently 300 increases the security requirements in the certificate issuance 301 procedures for publicly trusted certificates. There may be 302 situations in which the customer site/domain does not offer enough 303 security to operate a RA/CA and therefore this service is transferred 304 to a backend that offers a higher level of operational security. 306 3.3. Limitations 308 The mechanisms in this draft presume the availability of the pledge 309 to communicate with the registrar-agent. 310 This may not be possible in constrained environments where, in 311 particular, power must be conserved. 312 In these situations, it is anticipated that the transceiver will be 313 powered down most of the time. 314 This presents a rendezvous problem: the pledge is unavailable for 315 certain periods of time, and the registrar-agent is similarly 316 presumed to be unavailable for certain periods of time. 318 4. Requirements Discussion and Mapping to Solution-Elements 320 Based on the intended target environment described in Section 3.1 and 321 the application examples described in Section 3.2 the following 322 requirements are derived to support bootstrapping of pledges in 323 responder mode (acting as server). 325 * To facilitate the communication between a pledge in responder mode 326 and registrar, additional functionality is needed either on the 327 registrar (if the registrar needs to interact with pledge in 328 responder mode directly) or as a stand-alone component. This 329 component acts as an agent of the registrar to trigger the pledge 330 to generate request objects for voucher and enrollment. These 331 voucher an enrollment request objects are than to be provided by 332 the so called registrar-agent to the registrar. This requires the 333 definition of endpoints on the pledge. 335 * The communication between the registrar-agent and the pledge MUST 336 not rely on transport layer security (TLS) to support also other 337 technology stacks (e.g., BTLE). Therefore authenticated self- 338 contained objects are required. 340 * The registrar-agent must be authenticated by the registrar as a 341 component, acting on behalf of the registrar. In addition the 342 registrar must be able to verify, which registrar-agent was in 343 direct contact with the pledge. 345 * The pledge cannot get the assertion with value "proximity" in the 346 voucher, as it was not in direct contact with the registrar for 347 bootstrapping. Therefore the "agent-proximity" assertion value is 348 necessary for distinguishing assertions the MASA can state. 350 At least the following properties are required for the voucher and 351 enrollment objects: 353 * Proof of Identity (POI): provides data-origin authentication of a 354 data object, e.g., a voucher request or an enrollment request, 355 utilizing an existing IDevID. Certificate updates may utilize the 356 certificate that is to be updated. 358 * Proof of Possession (POP): proves that an entity possesses and 359 controls the private key corresponding to the public key contained 360 in the certification request, typically by adding a signature 361 using the private key to the enrollment request object. 363 Solution examples based on existing technology are provided with the 364 focus on existing IETF RFCs: 366 * Voucher request and response objects as used in [RFC8995] already 367 provide both, POP and POI, through a digital signature to protect 368 the integrity of the voucher object, while the corresponding 369 signing certificate contains the identity of the signer. 371 * Certification request objects: Certification requests are data 372 structures containing the information from a requester for a CA to 373 create a certificate. The certification request format in BRSKI 374 is PKCS#10 [RFC2986]. In PKCS#10, the structure is signed to 375 ensure integrity protection and proof of possession of the private 376 key of the requester that corresponds to the contained public key. 377 In the application examples, this POP alone is not sufficient. 378 POI is also required for the certification request object and 379 therefore needs to be additionally bound to the existing 380 credential of the pledge (IDevID). This binding supports the 381 authorization decision for the certification request through a 382 proof of identity (POI). The binding of data origin 383 authentication or POI to the certification request may be provided 384 directly by the certification request object. While BRSKI uses 385 the binding to TLS, BRSKI-PRM aims at an additional signature of 386 the PCKS#10 object using existing credentials on the pledge 387 (IDevID). This ensures independence of the selected transport. 389 5. Architectural Overview and Communication Exchanges 391 For BRSKI with pledge in responder mode, the base system architecture 392 defined in BRSKI [RFC8995] is enhanced to facilitate the new use 393 cases. The pledge-responder-mode allows delegated bootstrapping 394 using a registrar-agent instead of a direct connection between the 395 pledge and the domain registrar. The communication model between 396 registrar-agent and pledge in this document assumes that the pledge 397 is acting as server and responds to requests. 399 Necessary enhancements to support authenticated self-contained 400 objects for certificate enrollment are kept at a minimum to enable 401 reuse of already defined architecture elements and interactions. 403 For the authenticated self-contained objects used for the 404 certification request, BRSKI-PRM relies on the defined message 405 wrapping mechanisms of the enrollment protocols stated in Section 4 406 above. 408 The security used within the document for bootstrapping objects 409 produced or consumed by the pledge bases on JOSE [RFC7515]. In 410 constraint environments it may provided based on COSE [RFC8152]. 412 An abstract overview of the BRSKI-PRM protocol can be found in 413 [BRSKI-PRM-abstract]. 415 5.1. Pledge-responder-mode (PRM): Registrar-agent Communication with 416 Pledges 418 To support mutual trust establishment between the domain registrar 419 and pledges not directly connected to the customer site/domain, this 420 document specifies the exchange of authenticated self-contained 421 objects (the voucher request/response objects as known from BRSKI and 422 the enrollment request/response objects as introduced by BRSKI-PRM) 423 with the help of a registrar-agent. This allows independence from 424 protection provided by the utilized transport protocol. 426 The registrar-agent may be implemented as an integrated functionality 427 of a commissioning tool or be co-located with the registrar itself. 428 This leads to extensions of the logical components in the BRSKI 429 architecture as shown in Figure 1. The registrar-agent interacts 430 with the pledge to transfer the required data objects for 431 bootstrapping, which are then also exchanged between the registrar- 432 agent and the domain registrar. The addition of the registrar-agent 433 influences the sequences of the data exchange between the pledge and 434 the domain registrar as described in [RFC8995]. A general goal for 435 the registrar-agent implementation is the reuse of already defined 436 endpoints of the domain registrar. The already existing registrar 437 endpoints have been enhanced to provide distinct endpoints for 438 providing objects with additional signatures for the enrollment 439 objects in Section 5.3. 441 +------------------------+ 442 +--------------Drop Ship---------------| Vendor Service | 443 | +------------------------+ 444 | | M anufacturer| | 445 | | A uthorized |Ownership| 446 | | S igning |Tracker | 447 | | A uthority | | 448 | +--------------+---------+ 449 | ^ 450 | | BRSKI- 451 V BRSKI-PRM | MASA 452 +-------+ +---------+ .............................|......... 453 | | | | . | . 454 | | | | . +-----------+ +-----v-----+ . 455 | | |Registrar| . | | | | . 456 |Pledge | |Agent | . | Join | | Domain | . 457 | | | | . | Proxy | | Registrar | . 458 | <----->.........<------>...........<-------> (PKI RA) | . 459 | | | | . | | | | . 460 | | | | . | | +-----+-----+ . 461 |IDevID | | LDevID | . +-----------+ | . 462 | | | | . +------------------+-----+ . 463 +-------+ +---------+ . | Key Infrastructure | . 464 . | (e.g., PKI Certificate | . 465 . | Authority) | . 466 . +------------------------+ . 467 ....................................... 468 "Domain" components 470 Figure 1: Architecture overview using registrar-agent 472 For authentication to the domain registrar, the registrar-agent uses 473 its LDevID(RegAgt). The provisioning of the registrar-agent LDevID 474 may be done by a separate BRSKI run or other means in advance. It is 475 recommended to use short lived registrar-agent LDevIDs in the range 476 of days or weeks as outlined in Section 9.3. 478 If a registrar detects a request that originates from a registrar- 479 agent it is able to switch the operational mode from BRSKI to BRSKI- 480 PRM. This may be supported by a specific naming in the SAN (subject 481 alternative name) component of the LDevID(RegAgt) certificate. 482 Alternatively, the domain may feature an own issuing CA for 483 registrar-agent LDevID certificates. This allows the registrar to 484 detect registrar-agents based on the issuing CA. 486 The following list describes the components in a (customer) site 487 domain: 489 * Pledge: The pledge is expected to respond with the necessary data 490 objects for bootstrapping to the registrar-agent. The protocol 491 used between the pledge and the registrar-agent is assumed to be 492 HTTP in the context of this document. Other protocols may be used 493 like CoAP, Bluetooth, or NFC, but are out of scope of this 494 document. A pledge acting as a server during bootstrapping leads 495 to some differences to BRSKI: 497 - Discovery of the domain registrar by the pledge is not needed 498 as the pledge will be triggered by the registrar-agent. This 499 enables the registrar to verify that the pledge was contacted 500 by an authorized registrar. In addition, it enables the MASA 501 to provide an agent-proximity assertion. 503 - Discovery of the pledge by the registrar-agent must be 504 possible. 506 - As the registrar-agent must be able to request data objects for 507 bootstrapping of the pledge, the pledge must offer 508 corresponding endpoints. 510 - The registrar-agent may provide additional data to the pledge 511 in the context of the triggering request, to make itself 512 visible to the domain registrar. 514 - Order of exchanges in the call flow may be different as the 515 registrar-agent collects both objects, pledge-voucher-request 516 objects and pledge-enrollment-request objects, at once and 517 provides them to the registrar. This approach may also be used 518 to perform a bulk bootstrapping of several devices. 520 - The data objects utilized for the data exchange between the 521 pledge and the registrar are self-contained authenticated 522 objects (signature-wrapped objects). 524 * Registrar-agent: provides a communication path to exchange data 525 objects between the pledge and the domain registrar. The 526 registrar-agent brokers in situations, in which the domain 527 registrar is not directly reachable by the pledge, either due to a 528 different technology stack or due to missing connectivity. The 529 registrar-agent triggers a pledge to create bootstrapping 530 artifacts such as voucher-request objects and enrollment-request 531 objects on one or multiple pledges and performs a (bulk) 532 bootstrapping based on the collected data. The registrar-agent is 533 expected to possess information of the domain registrar (i.e., 534 LDevID(Reg) certificate, LDevID(CA) certificate, address), either 535 by configuration or by using the discovery mechanism defined in 536 [RFC8995]. There is no trust assumption between the pledge and 537 the registrar-agent as only authenticated self-contained objects 538 are used, which are transported via the registrar-agent and 539 provided either by the pledge or the registrar. The trust 540 assumption between the registrar-agent and the registrar is based 541 on the LDevID of the registrar-agent, provided by the PKI 542 responsible for the domain. 543 This allows the registrar-agent to authenticate towards the 544 registrar, e.g., in a TLS handshake. Based on this, the registrar 545 is able to distinguish a pledge from a registrar-agent during the 546 session establishment and also to verify that the registrar-agent 547 is authorized to perform the bootstrapping of the distinct pledge. 549 * Join Proxy: same functionality as described in [RFC8995]. Note 550 that it may be used by the registrar-agent instead of the pledge 551 to find the registrar, if not configured. 553 * Domain Registrar: In general the domain registrar fulfills the 554 same functionality regarding the bootstrapping of the pledge in a 555 (customer) site domain by facilitating the communication of the 556 pledge with the MASA service and the domain PKI service. In 557 contrast to [RFC8995], the domain registrar does not interact with 558 a pledge directly but through the registrar-agent. The registrar 559 detects if the bootstrapping is performed by the pledge directly 560 or by the registrar-agent. The manufacturer provided components/ 561 services (MASA and Ownership tracker) are used as defined in 562 [RFC8995]. For issuing a voucher, the MASA may perform additional 563 checks on voucher-request objects, to issue a voucher indicating 564 agent-proximity instead of (registrar-)proximity. 566 5.2. Agent-Proximity Assertion 568 "Agent-proximity" is a weaker assertion then "proximity". It is 569 defined as additional assertion type in [I-D.ietf-anima-rfc8366bis] 570 "agent-proximity" is a statement, that the proximity registrar 571 certificate was provided via the registrar-agent and not directly to 572 the pledge as defined in Section 5.5. This can be verified by the 573 registrar and also by the MASA during the voucher-request processing. 574 Note that at the time of creating the voucher-request, the pledge 575 cannot verify the registrar's LDevID(Reg) EE certificate and has no 576 proof-of-possession of the corresponding private key for the 577 certificate. The pledge accepts the LDevID(Reg) provisionally until 578 it receives the voucher as described in Section 5.5.3. 580 Trust handover to the domain is established via the "pinned-domain- 581 certificate" in the voucher. 583 In contrast, "proximity" provides a statement, that the pledge was in 584 direct contact with the registrar and was able to verify proof-of- 585 possession of the private key in the context of the TLS handshake. 586 The provisionally accepted LDevID(Reg) EE certificate can be verified 587 after the voucher has been processed by the pledge through a 588 verification of an additional signature of the returned voucher by 589 the registrar if contained (optional feature). 591 5.3. Behavior of Pledge in Pledge-Responder-Mode 593 In contrast to BRSKI the pledge acts as server. It is triggered by 594 the registrar-agent for the generation of the pledge-voucher-request 595 and pledge-enrollment-request objects as well as for the processing 596 of the response objects and the generation of status information. 597 Due to the use of the registrar-agent, the interaction with the 598 domain registrar is changed as shown in Figure 4. To enable 599 interaction with the registrar-agent, the pledge provides endpoints 600 using the BRSKI defined endpoints based on the "/.well-known/brski" 601 URI tree. 603 The following endpoints are defined for the _pledge_ in this 604 document. The URI path begins with "http://www.example.com/.well- 605 known/brski" followed by a path-suffix that indicates the intended 606 operation. 608 Operations and their corresponding URIs: 609 +------------------------+----------------------------+---------+ 610 | Operation |Operation path | Details | 611 +========================+============================+=========+ 612 | Trigger pledge-voucher-| /pledge-voucher-request | Section | 613 | request creation | | 5.5.1 | 614 | Returns | | | 615 | pledge-voucher-request | | | 616 ++------------------------+----------------------------+---------+ 617 | Trigger pledge- | /pledge-enrollment-request | Section | 618 | enrollment-request | | 5.5.1 | 619 | Returns pledge- | | | 620 | enrollment-request | | | 621 +------------------------+----------------------------+---------+ 622 | Provide voucher to | /pledge-voucher | Section | 623 | pledge | | 5.5.3 | 624 | Returns | | | 625 | pledge-voucher-status | | | 626 +------------------------+----------------------------+---------+ 627 | Provide enrollment | /pledge-enrollment | Section | 628 | response to pledge | | 5.5.3 | 629 | Returns pledge- | | | 630 | enrollment-status | | | 631 +------------------------+----------------------------+---------+ 632 | Provide CA certs to | /pledge-CACerts | | 633 | pledge (OPTIONAL) | | | 634 +------------------------+----------------------------+---------+ 636 Figure 2: Endpoints on the pledge 638 5.4. Behavior of Registrar-Agent 640 The registrar-agent is a new component in the BRSKI context. It 641 provides connectivity between the pledge and the domain registrar and 642 reuses the endpoints of the domain registrar side already specified 643 in [RFC8995]. It facilitates the exchange of data objects between 644 the pledge and the domain registrar, which are the voucher request/ 645 response objects, the enrollment request/response objects, as well as 646 related status objects. For the communication with the pledge the 647 registrar-agent utilizes communication endpoints provided by the 648 pledge. The transport in this specification is based on HTTP but may 649 also be done using other transport mechanisms. This new component 650 changes the general interaction between the pledge and the domain 651 registrar as shown in Figure 1. 653 The registrar-agent is expected to already possess an LDevID(RegAgt) 654 to authenticate to the domain registrar. The registrar-agent will 655 use this LDevID(RegAgt) when establishing the TLS session with the 656 domain registrar for TLS client authentication. The LDevID(RegAgt) 657 EE certificate MUST include a SubjectKeyIdentifier (SKID), which is 658 used as reference in the context of an agent-signed-data object as 659 defined in Section 5.5.1. Note that this is an additional 660 requirement for issuing the certificate, as [IEEE-802.1AR] only 661 requires the SKID to be included for intermediate CA certificates. 662 In BRSKI-PRM, the SKID is used in favor of a certificate fingerprint 663 to avoid additional computations. 665 Using an LDevID for TLS client authentication is a deviation from 666 [RFC8995], in which the pledge's IDevID credential is used to perform 667 TLS client authentication. The use of the LDevID(RegAgt) allows the 668 domain registrar to distinguish, if bootstrapping is initiated from a 669 pledge or from a registrar-agent and adopt the internal handling 670 accordingly. As BRSKI-PRM uses authenticated self-contained data 671 objects between the pledge and the domain registrar, the binding of 672 the pledge identity to the request object is provided by the data 673 object signature employing the pledge's IDevID. The objects 674 exchanged between the pledge and the domain registrar used in the 675 context of this specifications are JOSE objects 677 In addition to the LDevID(RegAgt), the registrar-agent is provided 678 with the product-serial-numbers of the pledges to be bootstrapped. 679 This is necessary to allow the discovery of pledges by the registrar- 680 agent using mDNS. The list may be provided by administrative means 681 or the registrar agent may get the information via an interaction 682 with the pledge, like scanning of product-serial-number information 683 using a QR code or similar. 685 According to [RFC8995] section 5.3, the domain registrar performs the 686 pledge authorization for bootstrapping within his domain based on the 687 pledge voucher-request object. 689 The following information must therefore be available at the 690 registrar-agent: 692 * LDevID(RegAgt): own operational key pair. 694 * LDevID(reg) certificate: certificate of the domain registrar. 696 * Serial-number(s): product-serial-number(s) of pledge(s) to be 697 bootstrapped. 699 5.4.1. Discovery of Registrar by Registrar-Agent 701 The discovery of the domain registrar may be done as specified in 702 [RFC8995] with the deviation that it is done between the registrar- 703 agent and the domain registrar. Alternatively, the registrar-agent 704 may be configured with the address of the domain registrar and the 705 certificate of the domain registrar. 707 5.4.2. Discovery of Pledge by Registrar-Agent 709 The discovery of the pledge by registrar-agent should be done by 710 using DNS-based Service Discovery [RFC6763] over Multicast DNS 711 [RFC6762] to discover the pledge at "product-serial-number.brski- 712 pledge._tcp.local." The pledge constructs a local host name based on 713 device local information (product-serial-number), which results in 714 "product-serial-number.brski-pledge._tcp.local." It can then be 715 discovered by the registrar-agent via mDNS. Note that other 716 mechanisms for discovery may be used. 718 The registrar-agent is able to build the same information based on 719 the provided list of product-serial-number. 721 5.5. Bootstrapping Objects and Corresponding Exchanges 723 The interaction of the pledge with the registrar-agent may be 724 accomplished using different transport means (protocols and or 725 network technologies). For this document the usage of HTTP is 726 targeted as in BRSKI. Alternatives may be CoAP, Bluetooth Low Energy 727 (BLE), or Nearfield Communication (NFC). This requires independence 728 of the exchanged data objects between the pledge and the registrar 729 from transport security. Therefore, authenticated self-contained 730 objects (here: signature-wrapped objects) are applied in the data 731 exchange between the pledge and the registrar. 733 The registrar-agent provides the domain-registrar certificate 734 (LDevID(Reg) EE certificate) to the pledge to be included into the 735 "agent-provided-proximity-registrar-certificate" leaf of the pledge- 736 voucher-request object. This enables the registrar to verify, that 737 it is the target registrar for handling the request. The registrar 738 certificate may be configured at the registrar-agent or may be 739 fetched by the registrar-agent based on a prior TLS connection 740 establishment with the domain registrar. In addition, the registrar- 741 agent provides agent-signed-data containing the product-serial-number 742 in the body, signed with the LDevID(RegAgt). This enables the 743 registrar to verify and log, which registrar-agent was in contact 744 with the pledge, when verifying the pledge-voucher-request. 745 Optionally the registrar-agent may provide its LDevID(RegAgt) EE 746 certificate (and optionally also the issuing CA certificate) to the 747 pledge to be used in the "agent-sign-cert" component of the pledge- 748 voucher-request. If contained, the LDevID(RegAgt) EE certificate 749 MUST be the first certificate in the array. Note, this may be 750 omitted in constraint environments to save bandwidth between the 751 registrar-agent and the pledge. If not contained, the registrar- 752 agent MUST fetch the LDevID(RegAgt) EE certificate based on the 753 SubjectKeyIdentifier (SKID) in the header of the agent-signed-data of 754 the pledge-voucher-request. The registrar includes the 755 LDevID(RegAgt) EE certificate information into the registrar-voucher- 756 request if the pledge-voucher-requests contains the assertion of 757 "agent-proximity". 759 The MASA in turn verifies the LDevID(Reg) EE certificate is included 760 in the pledge-voucher-request (prior-signed-voucher-request) in the 761 "agent-provided-proximity-registrar-certificate" leaf and may assert 762 in the voucher "verified" or "logged" instead of "proximity", as 763 there is no direct connection between the pledge and the registrar. 764 In addition, the MASA can provide the assertion "agent-proximity" as 765 following. If the LDevID(RegAgt) EE certificate information is 766 contained in the "agent-sign-cert" component of the registrar- 767 voucher-request, the MASA can verify the signature of the agent- 768 signed-data contained in the prior-signed-voucher-request. If both 769 can be verified successfully, the MASA can assert "agent-proximity" 770 in the voucher. Otherwise, it may assert "verified" or "logged". 771 The voucher can then be supplied via the registrar to the registrar- 772 agent. 774 Figure 3 provides an overview of the exchanges detailed in the 775 following sub sections. 777 +--------+ +-----------+ +-----------+ +--------+ +---------+ 778 | Pledge | | Registrar | | Domain | | Domain | | Vendor | 779 | | | Agent | | Registrar | | CA | | Service | 780 | | | (RegAgt) | | (JRC) | | | | (MASA) | 781 +--------+ +-----------+ +-----------+ +--------+ +---------+ 782 | | | | Internet | 783 [discovery of pledge] 784 | mDNS query | | | | 785 |<-------------| | | | 786 |------------->| | | | 787 | | | | | 788 [trigger pledge-voucher-request and 789 pledge-enrollment-request generation] 790 |<- vTrigger --| | | | 791 |-Voucher-Req->| | | | 792 | | | | | 793 |<- eTrigger --| | | | 794 |- Enroll-Req->| | | | 795 ~ ~ ~ ~ ~ 796 [provide pledge-voucher-request to infrastructure] 797 | |<------ TLS ----->| | | 798 | | [Reg-Agt authenticated | | 799 | | and authorized?] | | 800 | |-- Voucher-Req -->| | | 801 | | [Reg-Agt authorized?] | | 802 | | [accept device?] | | 803 | | [contact vendor] | | 804 | | |------- Voucher-Req ------>| 805 | | | [extract DomainID] 806 | | | [update audit log] 807 | | |<-------- Voucher ---------| 808 | |<---- Voucher ----| | | 809 | | | | | 810 [provide pledge enrollment request to infrastructure] 811 | |-- Enroll-Req --->| | | 812 | | |- Cert-Req -->| | 813 | | |<-Certificate-| | 814 | |<-- Enroll-Resp --| | | 815 ~ ~ ~ ~ ~ 816 [provide voucher and certificate 817 to pledge and collect status info] 818 |<-- Voucher --| | | | 819 |-- vStatus -->| | | | 820 |<-Enroll-Resp-| | | | 821 |-- eStatus -->| | | | 822 ~ ~ ~ ~ ~ 823 [provide voucher status and enroll status to registrar] 824 | |<------ TLS ----->| | | 825 | |---- vStatus --->| | | 826 | | |-- req. device audit log ->| 827 | | |<---- device audit log ----| 828 | | [verify audit log] 829 | | | | | 830 | |---- eStatus --->| | | 831 | | | | | 833 Figure 3: Overview pledge-responder-mode exchanges 835 The following sub sections split the interactions between the 836 different components into: 838 * Section 5.5.1 describes objects exchanged between the registrar- 839 agent and the pledge. 841 * Section 5.5.2 describes objects exchanged between the registrar- 842 agent and the registrar and also the interaction of the registrar 843 with the MASA and the domain CA. 845 * Section 5.5.3 describes objects exchanged between the registrar- 846 agent and the pledge including the status objects. 848 * Section 5.5.4 describes the status handling addresses the 849 exchanges between the registrar-agent and the registrar. 851 5.5.1. Request Objects Acquisition by Registrar-Agent from Pledge 853 The following description assumes that the registrar-agent already 854 discovered the pledge. This may be done as described in 855 Section 5.4.2 based on mDNS. 857 The focus is on the exchange of signature-wrapped objects using 858 endpoints defined for the pledge in Section 5.3. 860 Preconditions: 862 * Pledge: possesses IDevID 864 * Registrar-agent: possesses/trusts IDevID CA certificate and an own 865 LDevID(RegAgt) EE credential for the registrar domain. In 866 addition, the registrar-agent MAY be configured with the product- 867 serial-number(s) of the pledge(s) to be bootstrapped. Note that 868 the product-serial-number may have been used during the pledge 869 discovery already. 871 * Registrar: possesses/trusts IDevID CA certificate and an own 872 LDevID(Reg) credential. 874 * MASA: possesses own credentials (voucher signing key, TLS server 875 certificate) as well as IDevID CA certificate of pledge vendor / 876 manufacturer and site-specific LDevID CA certificate. 878 +--------+ +-----------+ 879 | Pledge | | Registrar | 880 | | | Agent | 881 | | | (RegAgt) | 882 +--------+ +-----------+ 883 | |-create 884 | | agent-signed-data 885 |<--- trigger pledge-voucher-request ----| 886 |-agent-provided-proximity-registrar-cert| 887 |-agent-signed-data | 888 |-agent-sign-cert (optional) | 889 | | 890 |----- pledge-voucher-request ---------->|-store 891 | | pledge-voucher-request 892 |<----- trigger enrollment request ------| 893 | (empty) | 894 | | 895 |------ pledge-enrollment-request ------>|-store 896 | | pledge-enrollment-req. 898 Figure 4: Request collection (registrar-agent - pledge) 900 Triggering the pledge to create the pledge-voucher-request is done 901 using HTTP POST on the defined pledge endpoint "/.well-known/brski/ 902 pledge-voucher-request". 904 The registrar-agent pledge-voucher-request Content-Type header is: 905 application/json. It defines a JSON document to provide three 906 parameter: 908 * agent-provided-proximity-registrar-cert: base64-encoded 909 LDevID(Reg) TLS EE certificate. 911 * agent-signed-data: base64-encoded JWS-object. 913 * agent-sign-cert: array of base64-encoded certificate data 914 (optional). 916 The the trigger for the pledge to create a pledge-voucher-request is 917 depicted in the following figure: 919 { 920 "agent-provided-proximity-registrar-cert": "base64encodedvalue==", 921 "agent-signed-data": "base64encodedvalue==", 922 "agent-sign-cert": ["base64encodedvalue==", "base64encodedvalue==", "..."] 923 } 925 Figure 5: Representation of trigger to create pledge-voucher-request 926 The pledge provisionally accepts the agent-provided-proximity- 927 registrar-cert and can verify it once it has received the voucher. 928 If the optionally agent-sign-cert data is included the pledge MAY 929 verify at least the signature of the agent-signed-data using the 930 first contained certificate, which is the LDevID(RegAgt) EE 931 certificate. If further certificates are contained in the agent- 932 sign-cert, they enable also the certificate chain validation. The 933 pledge may not verify the agent-sign-cert itself as the domain trust 934 has not been established at this point of the communication. It can 935 be done, after the voucher has been received. 937 The agent-signed-data is a JOSE object and contains the following 938 information: 940 The header of the agent-signed-data contains: 942 * alg: algorithm used for creating the object signature. 944 * kid: contains the base64-encoded SubjectKeyIdentifier of the 945 LDevID(RegAgt) certificate. 947 The body of the agent-signed-data contains an ietf-voucher-request- 948 prm:agent-signed-data element (defined in Section 6.1): 950 * created-on: MUST contain the creation date and time in yang:date- 951 and-time format. 953 * serial-number: MUST contain the product-serial-number as type 954 string as defined in [RFC8995], section 2.3.1. The serial-number 955 corresponds with the product-serial-number contained in the 956 X520SerialNumber field of the IDevID certificate of the pledge. 958 { 959 "payload": { 960 "ietf-voucher-request-prm:agent-signed-data": { 961 "created-on": "2021-04-16T00:00:01.000Z", 962 "serial-number": "callee4711" 963 }, 964 "signatures": [ 965 { 966 "protected": { 967 "alg": "ES256", 968 "kid": "base64encodedvalue==" 969 }, 970 "signature": "base64encodedvalue==" 971 } 972 ] 973 } 974 } 976 Figure 6: Representation of agent-signed-data 978 Upon receiving the voucher-request trigger, the pledge SHALL 979 construct the body of the pledge-voucher-request object as defined in 980 [RFC8995]. It will contain additional information provided by the 981 registrar-agent as specified in the following. This object becomes a 982 JSON-in-JWS object as defined in [I-D.ietf-anima-jws-voucher]. If 983 the pledge is unable to construct the pledge-voucher-request it 984 SHOULD respond with HTTP 406 error code to the registrar-agent to 985 indicate that it is not able to create the pledge-voucher-request. 987 The header of the pledge-voucher-request SHALL contain the following 988 parameters as defined in [RFC7515]: 990 * alg: algorithm used for creating the object signature. 992 * x5c: contains the base64-encoded pledge IDevID certificate. It 993 may optionally contain the certificate chain for this certificate. 995 The payload of the pledge-voucher-request (PVR) object MUST contain 996 the following parameters as part of the ietf-voucher-request- 997 prm:voucher as defined in [RFC8995]: 999 * created-on: SHALL contain the current date and time in yang:date- 1000 and-time format. 1002 * nonce: SHALL contain a cryptographically strong random or pseudo- 1003 random number. 1005 * serial-number: SHALL contain the pledge product-serial-number as 1006 X520SerialNumber. 1008 * assertion: SHALL contain the requested voucher assertion "agent- 1009 proximity". 1011 The ietf-voucher-request:voucher is enhanced with additional 1012 parameters: 1014 * agent-provided-proximity-registrar-cert: MUST be included and 1015 contains the base64-encoded LDevID(Reg) EE certificate (provided 1016 as trigger parameter by the registrar-agent). 1018 * agent-signed-data: MUST contain the base64-encoded agent-signed- 1019 data (as defined in Figure 6) and provided as trigger parameter. 1021 * agent-sign-cert: MAY contain the certificate or certificate chain 1022 of the registrar-agent as array of base64encoded certificate 1023 information. It starts from the base64-encoded LDevID(RegAgt) EE 1024 certificate optionally followed by the issuing CA certificate and 1025 potential further certificates. If supported, it MUST at least 1026 contain the LDevID(RegAgt) EE certificate provided as trigger 1027 parameter. 1029 The enhancements of the YANG module for the ietf-voucher-request with 1030 these new leafs are defined in Section 6.1. 1032 The object is signed using the pledge's IDevID credential contained 1033 as x5c parameter of the JOSE header. 1035 { 1036 "payload": { 1037 "ietf-voucher-request-prm:voucher": { 1038 "created-on": "2021-04-16T00:00:02.000Z", 1039 "nonce": "eDs++/FuDHGUnRxN3E14CQ==", 1040 "serial-number": "callee4711", 1041 "assertion": "agent-proximity", 1042 "agent-provided-proximity-registrar-cert": "base64encodedvalue==", 1043 "agent-signed-data": "base64encodedvalue==", 1044 "agent-sign-cert": [ 1045 "base64encodedvalue==", 1046 "base64encodedvalue==", 1047 "..." 1048 ] 1049 }, 1050 "signatures": [ 1051 { 1052 "protected": { 1053 "alg": "ES256", 1054 "x5c": [ "MIIB2jCC...dA==" ] 1055 }, 1056 "signature": "base64encodedvalue==" 1057 } 1058 ] 1059 } 1060 } 1062 Figure 7: Representation of pledge-voucher-request 1064 The pledge-voucher-request Content-Type is defined in 1065 [I-D.ietf-anima-jws-voucher] as application/voucher-jws+json. 1067 The pledge SHOULD include this Content-Type header field indicating 1068 the included media type for the voucher response. Note that this is 1069 also an indication regarding the acceptable format of the voucher 1070 response. This format is included by the registrar as described in 1071 Section 5.5.2. 1073 Once the registrar-agent has received the pledge-voucher-request it 1074 can trigger the pledge to generate an enrollment-request object. As 1075 in BRSKI the enrollment request object is a PKCS#10, but additionally 1076 signed using the pledge's IDevID. Note, as the initial enrollment 1077 aims to request a generic certificate, no certificate attributes are 1078 provided to the pledge. 1080 Triggering the pledge to create the enrollment-request is done using 1081 HTTP POST on the defined pledge endpoint "/.well-known/brski/pledge- 1082 enrollment-request". 1084 The registrar-agent pledge-enrollment-request Content-Type header is: 1085 application/json with an empty body. Note that using HTTP POST 1086 allows for an empty body, but also to provide additional data, like 1087 CSR attributes or information about the enroll type: initial or re- 1088 enroll as shown in Figure 8. 1090 { 1091 "enroll-type" = "intial" 1092 } 1094 Figure 8: Example of trigger to create a pledge-enrollment-request 1096 In the following the enrollment is described as initial enrollment 1097 with an empty body. 1099 Upon receiving the enrollment-trigger, the pledge SHALL construct the 1100 pledge-enrollment-request as authenticated self-contained object. 1101 The CSR already assures proof of possession of the private key 1102 corresponding to the contained public key. In addition, based on the 1103 additional signature using the IDevID, proof of identity is provided. 1104 Here, a JOSE object is being created in which the body utilizes the 1105 YANG module ietf-ztp-types with the grouping for csr-grouping for the 1106 CSR as defined in [I-D.ietf-netconf-sztp-csr]. 1108 Depending on the capability of the pledge, it constructs the 1109 enrollment request as plain PKCS#10. Note that the focus in this use 1110 case is placed on PKCS#10 as PKCS#10 can be transmitted in different 1111 enrollment protocols in the infrastructure like EST, CMP, CMS, and 1112 SCEP. If the pledge is already implementing an enrollment protocol, 1113 it may leverage that functionality for the creation of the enrollment 1114 request object. Note also that [I-D.ietf-netconf-sztp-csr] also 1115 allows for inclusion of certification request objects such as CMP or 1116 CMC. 1118 The pledge SHOULD construct the pledge-enrollment-request as PKCS#10 1119 object. In BRSKI-PRM it MUST sign it additionally with its IDevID 1120 credential to provide proof-of-identity bound to the PKCS#10 as 1121 described below. 1123 If the pledge is unable to construct the enrollment-request it SHOULD 1124 respond with HTTP 406 error code to the registrar-agent to indicate 1125 that it is not able to create the enrollment-request. 1127 A successful enrollment will result in a generic LDevID certificate 1128 for the pledge in the new domain, which can be used to request 1129 further (application specific) LDevID certificates if necessary for 1130 its operation. The registrar-agent SHALL use the endpoints specified 1131 in this document. 1133 [I-D.ietf-netconf-sztp-csr] considers PKCS#10 but also CMP and CMC as 1134 certification request format. Note that the wrapping signature is 1135 only necessary for plain PKCS#10 as other request formats like CMP 1136 and CMS support the signature wrapping as part of their own 1137 certificate request format. 1139 The registrar-agent enrollment-request Content-Type header for a 1140 wrapped PKCS#10 is: application/jose+json 1142 The header of the pledge enrollment-request SHALL contain the 1143 following parameter as defined in [RFC7515]: 1145 * alg: algorithm used for creating the object signature. 1147 * x5c: contains the base64-encoded pledge IDevID certificate. It 1148 may optionally contain the certificate chain for this certificate. 1150 The body of the pledge enrollment-request object SHOULD contain a P10 1151 parameter (for PKCS#10) as defined for ietf-ztp-types:p10-csr in 1152 [I-D.ietf-netconf-sztp-csr]: 1154 * P10: contains the base64-encoded PKCS#10 of the pledge. 1156 The JOSE object is signed using the pledge's IDevID credential, which 1157 corresponds to the certificate signaled in the JOSE header. 1159 { 1160 "payload": { 1161 "ietf-ztp-types": { 1162 "p10-csr": "base64encodedvalue==" 1163 }, 1164 "signatures": [ 1165 { 1166 "protected": { 1167 "alg": "ES256", 1168 "x5c": [ "MIIB2jCC...dA==" ] 1169 }, 1170 "signature": "base64encodedvalue==" 1171 } 1172 ] 1173 } 1174 } 1176 Figure 9: Representation of pledge-enrollment-request 1178 With the collected pledge-voucher-request object and the pledge- 1179 enrollment-request object, the registrar-agent starts the interaction 1180 with the domain registrar. 1182 As the registrar-agent is intended to facilitate communication 1183 between the pledge and the domain registrar, a collection of requests 1184 from more than one pledge is possible, allowing a bulk bootstrapping 1185 of multiple pledges using the same connection between the registrar- 1186 agent and the domain registrar. 1188 5.5.2. Request Processing by the Registrar-Agent 1190 The BRSKI-PRM bootstrapping exchanges between registrar-agent and 1191 domain registrar resemble the BRSKI exchanges between pledge and 1192 domain registrar (pledge-initiator-mode) with some deviations. 1194 Preconditions: 1196 * Registrar-agent: possesses it's own LDevID(RegAgt) credentials of 1197 the site domain. In addition, it may possess the IDevID CA 1198 certificate of the pledge vendor/manufacturer to verify the pledge 1199 certificate in the received request messages. It has the address 1200 of the domain registrar through configuration or by discovery, 1201 e.g., mDNS/DNSSD. The registrar-agent has acquired pledge- 1202 voucher-request and pledge-enrollment-request objects(s). 1204 * Registrar: possesses the IDevID CA certificate of the pledge 1205 vendor/manufacturer and an it's own LDevID(Reg) credentials of the 1206 site domain. 1208 * MASA: possesses it's own vendor/manufacturer credentials (voucher 1209 signing key, TLS server certificate) related to pledges IDevID and 1210 the site-specific LDevID CA certificate. 1212 +-----------+ +-----------+ +--------+ +---------+ 1213 | Registrar-| | Domain | | Domain | | Vendor | 1214 | agent | | Registrar | | CA | | Service | 1215 | (RegAgt) | | (JRC) | | | | (MASA) | 1216 +-----------+ +-----------+ +--------+ +---------+ 1217 | | | Internet | 1218 [voucher + enrollment] | | | 1219 [objects available. ] | | | 1220 | | | | 1221 |<----- mTLS ----->| | | 1222 | [Reg-Agt authenticated | | 1223 | and authorized?] | | 1224 | | | | 1225 |-- Voucher-Req -->| | | 1226 | (PVR) | | | 1227 | [Reg-Agt authorized?] | | 1228 | [accept device?] | | 1229 | [contact vendor] | | 1230 | |----------- mTLS --------->| 1231 | |-- Voucher-Req ----------->| 1232 | | (RVR) | 1233 | | [extract DomainID] 1234 | | [update audit log] 1235 | |<-------- Voucher ---------| 1236 |<---- Voucher ----| | 1237 | | | 1238 |--- Enroll-Req -->| | | 1239 | (PER) | | | 1240 | |--- mTLS ---->| | 1241 | |- Enroll-Req->| | 1242 | | (RER) | | 1243 | |<-Enroll-Resp-| | 1244 |<-- Enroll-Resp---| | | 1245 | | | | 1247 Figure 10: Request processing between registrar-agent and 1248 infrastructure bootstrapping services 1250 The registrar-agent establishes a TLS connection with the registrar. 1251 As already stated in [RFC8995], the use of TLS 1.3 (or newer) is 1252 encouraged. TLS 1.2 or newer is REQUIRED on the registrar-agent 1253 side. TLS 1.3 (or newer) SHOULD be available on the registrar, but 1254 TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be available on the 1255 MASA, but TLS 1.2 MAY be used. 1257 In contrast to [RFC8995] TLS client authentication to the registrar 1258 is achieved by using registrar-agent LDevID(RegAgt) credentials 1259 instead of pledge IDevID credentials. Consequently BRSKI (pledge- 1260 initiator-mode) is distinguishable from BRSKI-PRM (pledge-responder- 1261 mode) by the registrar. The registrar SHOULD verify that the 1262 registrar-agent is authorized to establish a connection to the 1263 registrar by TLS client authentication using LDevID(RegAgt) 1264 credentials. If the connection form registrar-agent to registrar is 1265 established, the authorization SHALL be verified again based on the 1266 agent-signed-data contained in the pledge-voucher-request (PVR). 1267 This ensures that the pledge has been triggered by an authorized 1268 registrar-agent. 1270 The registrar can receive request objects in different formats as 1271 defined in [RFC8995]. Specifically, the registrar will receive JSON- 1272 in-JWS objects generated by the pledge for voucher-request and 1273 enrollment-request (instead of BRSKI voucher-request as CMS-signed 1274 JSON and enrollment-request as PKCS#10 objects). 1276 The registrar-agent SHALL send the pledge-voucher-request by HTTP 1277 POST to the registrar endpoint: "/.well-known/brski/requestvoucher" 1279 The Content-Type header field for JSON-in-JWS pledge-voucher-request 1280 is: application/voucher-jws+json (see Figure 7 for the content 1281 definition), as defined in [I-D.ietf-anima-jws-voucher]. 1283 The registrar-agent SHOULD set the Accept field in the request-header 1284 indicating the acceptable Content-Type for the voucher-response. The 1285 voucher-response Content-Type header field SHOULD be set to 1286 application/voucher-jws+json as defined in 1287 [I-D.ietf-anima-jws-voucher]. 1289 After receiving the pledge-voucher-request from registrar-agent, the 1290 registrar SHALL perform the verification as defined in section 5.3 of 1291 [RFC8995]. In addition, the registrar shall verify the following 1292 parameters from the pledge-voucher-request (PVR): 1294 * agent-provided-proximity-registrar-cert: MUST contain registrar's 1295 own LDevID(Reg) EE certificate to ensure the registrar in 1296 proximity of the registrar-agent is the destination for this PVR. 1298 * agent-signed-data: The registrar MUST verify that the agent 1299 provided data has been signed with the LDevID(RegAgt) credential 1300 indicated in the "kid" JOSE header parameter. If the certificate 1301 is not included in the agent-sign-cert properties of the pledge- 1302 voucher-request, it must be fetched out-of-band by the registrar 1303 if "agent-proximity" assertion is requested. 1305 * agent-sign-cert: MAY contain an array of base64-encoded 1306 certificate data starting with the LDevID(RegAgt) EE certificate. 1307 If contained the registrar MUST verify that the LDevID(ReAgt) EE 1308 certificate, used to sign the data, is still valid. If the 1309 certificate is already expired, the registrar SHALL reject the 1310 request. Validity of used signing certificates during 1311 bootstrapping is necessary as no trusted timestamp is available, 1312 see also Section 9.3. 1313 If the agent-signed-cert is not provided, the registrar MUST fetch 1314 the LDevID(RegAgt) EE certificate, based on the provided 1315 SubjectKeyIdentifier (SKID) contained in the kid header of the 1316 agent-signed-data, and perform this verification. This requires, 1317 that the registrar can fetch the LDevID(RegAgt) certificate data 1318 (including intermediate CA certificates if existent) based on the 1319 SKID. 1321 If the validation fails the registrar SHOULD respond with HTTP 404 1322 error code to the registrar-agent. HTTP 406 error code SHOULD be 1323 used if the format of pledge-voucher-request is unknown. 1325 If the validation succeeds, the registrar SHOULD accept the pledge- 1326 voucher-request (PVR) to join the domain as defined in section 5.3 of 1327 [RFC8995]. The registrar then establishes a TLS connection to MASA 1328 as described in section 5.4 of [RFC8995] to obtain a voucher for the 1329 pledge. 1331 The registrar SHALL construct the payload of the registrar-voucher- 1332 request (RVR) object as defined in [RFC8995]. The RVR object 1333 encoding SHALL be JSON-in-JWS as defined in 1334 [I-D.ietf-anima-jws-voucher]. 1336 The header of the registrar-voucher-request (RVR) SHALL contain the 1337 following parameter as defined in [RFC7515]: 1339 * alg: algorithm used to create the object signature. 1341 * x5c: contains the base64-encoded registrar LDevID certificate(s). 1342 It may optionally contain the certificate chain for this 1343 certificate. 1345 The payload of the registrar-voucher-request (RVR) object MUST 1346 contain the following parameter as part of the voucher request as 1347 defined in [RFC8995]: 1349 * created-on: contains the current date and time in yang:date-and- 1350 time format for the registrar-voucher-request creation time. 1352 * nonce: copied form the pledge-voucher-request 1353 * serial-number: contains the pledge product-serial-number. The 1354 registrar MUST verify that the IDevID EE certificate subject 1355 serialNumber of the pledge (X520SerialNumber) matches the serial- 1356 number value in the PVR. In addition, it MUST be equal to the 1357 serial-number value contained in the agent-signed data of PVR. 1359 * assertion: contains the voucher assertion requested by the pledge 1360 (agent-proximity). The registrar provides this information to 1361 assure successful verification of agent proximity based on the 1362 agent-signed-data. 1364 * prior-signed-voucher-request: contains the pledge-voucher-request 1365 provided by the registrar-agent. 1367 The registrar-voucher-request (RVR) can be enhanced optionally with 1368 the following parameter as defined in Section 6.1: 1370 * agent-sign-cert: contains the LDevID(RegAgt) EE certificate or the 1371 LDevID(RegAgt) EE certificate including the certificate chain. In 1372 the context of this document it is a JSON array of base64encoded 1373 certificate information and handled in the same way as x5c header 1374 objects. 1376 If only a single object is contained in the x5c it MUST be the 1377 base64-encoded LDevID(RegAgt) EE certificate. If multiple 1378 certificates are included in the x5c, the first MUST be the 1379 base64-encoded LDevID(RegAgt) EE certificate. 1381 The MASA uses this information for verification of the agent is in 1382 proximity to the registrar to state the corresponding assertion 1383 "agent-proximity". If the agent-sign-cert is not included in the 1384 registrar-voucher-request (RVR), it is also contained in the "prior- 1385 signed-voucher-request" field carrying the pledge-voucher-request 1386 PVR. 1388 The object is signed using the registrar LDevID(Reg) credential, 1389 which corresponds to the certificate signaled in the JOSE header. 1391 { 1392 "payload": { 1393 "ietf-voucher-request-prm:voucher": { 1394 "created-on": "2022-01-04T02:37:39.235Z", 1395 "nonce": "eDs++/FuDHGUnRxN3E14CQ==", 1396 "serial-number": "callee4711", 1397 "assertion": "agent-proximity", 1398 "prior-signed-voucher-request": "base64encodedvalue==", 1399 "agent-sign-cert": [ 1400 "base64encodedvalue==", 1401 "base64encodedvalue==", 1402 "..." 1403 ] 1404 }, 1405 "signatures": [ 1406 { 1407 "protected": { 1408 "alg": "ES256", 1409 "x5c": [ "base64encodedvalue==" ] 1410 }, 1411 "signature": "base64encodedvalue==" 1412 } 1413 ] 1414 } 1415 } 1417 Figure 11: Representation of registrar-voucher-request 1419 The registrar SHALL send the registrar-voucher-request (RVR) to the 1420 MASA endpoint by HTTP POST: "/.well-known/brski/requestvoucher" 1422 The registrar-voucher-request Content-Type header field is defined in 1423 [I-D.ietf-anima-jws-voucher] as: application/voucher-jws+json 1425 The registrar-voucher-request (RVR) SHOULD set the Accept header 1426 indicating the desired media type for the voucher-response. The 1427 media type is application/voucher-jws+json as defined in 1428 [I-D.ietf-anima-jws-voucher]. 1430 Once the MASA receives the registrar-voucher-request (RVR) it SHALL 1431 perform the verification as described in section 5.5 in [RFC8995]. 1433 In addition, the following processing SHALL be performed for PVR data 1434 contained in RVR "prior-signed-voucher-request" field: 1436 * agent-provided-proximity-registrar-cert: The MASA MAY verify that 1437 this field contains the LDevID(Reg) certificate. If so, it MUST 1438 correspond to the LDevID(Reg) certificate used to sign the 1439 registrar-voucher-request (RVR). Note: Correspond here relates to 1440 the case that a single LDevID(Reg) certificate is used or that 1441 different LDevID(Reg) certificates are used, which are issued by 1442 the same CA. 1444 * agent-signed-data: The MASA MAY verify this field to issue "agent- 1445 proximity" assertion. If so, the agent-signed-data MUST contain 1446 the pledge product-serial-number, contained in the "serial-number" 1447 field of the PVR (from "prior-signed-voucher-request" field) and 1448 also in "serial-number" field of the registrar-voucher-request 1449 (RVR). The LDevID(RegAgt) EE certificate used to generate the 1450 signature is identified by the "kid" parameter of the JOSE header 1451 (agent-signed-data). If the assertion "agent-proximity" is 1452 requested, the registrar-voucher-request MUST contain the 1453 corresponding LDevID(RegAgt) certificate data in the "agent-sign- 1454 cert" field of either the LDevID(RegAgt) EE certificate of 1455 registrar-voucher-request (RVR) or of pledge-voucher-request (PVR) 1456 from "prior-signed-voucher-request" field. It can be verified by 1457 the MASA that it was issued by the same domain CA as the 1458 LDevID(Reg) EE certificate. 1459 If the "agent-sign-cert" field is not provided, the MASA MAY state 1460 a lower level assertion value, e.g.: "logged" or "verified" Note: 1461 Sub-CA certificate(s) MUST also be carried by "agent-sign-cert", 1462 in case the LDevID(RegAgt) EE certificate is issued by a sub-CA 1463 and not the domain CA known to the MASA. As the "agent-sign-cert" 1464 field is defined as array (x5c), it can handle multiple 1465 certificates. 1467 If validation fails, the MASA SHOULD respond with an HTTP error code 1468 to the registrar. The HTTP error codes are kept the same as defined 1469 in section 5.6 of [RFC8995], and comprise the codes: 403, 404, 406, 1470 and 415. 1472 The expected voucher-response format is indicated by the Accept 1473 header field of the RVR or MASA SHOULD respond with the same format 1474 as the PVR was (default "JSON-in-JWS") Specifically for the pledge- 1475 responder-mode the application/voucher-jws+json as defined in 1476 [I-D.ietf-anima-jws-voucher] is applied. The voucher syntax is 1477 described in detail by [RFC8366]. Figure 12 shows an example of the 1478 contents of a voucher. 1480 { 1481 "payload": { 1482 "ietf-voucher:voucher": { 1483 "assertion": "agent-proximity", 1484 "serial-number": "callee4711", 1485 "nonce": "eDs++/FuDHGUnRxN3E14CQ==", 1486 "created-on": "2022-01-04T00:00:02.000Z", 1487 "pinned-domain-cert": "MIIBpDCCA...w==" 1488 }, 1489 "signatures": [ 1490 { 1491 "protected": { 1492 "alg": "ES256", 1493 "x5c": [ "base64encodedvalue==" ] 1494 }, 1495 "signature": "base64encodedvalue==" 1496 } 1497 ] 1498 } 1499 } 1501 Figure 12: Representation of MASA issued voucher 1503 The MASA returns the voucher-response object to the registrar. 1505 After receiving the voucher the registrar SHOULD evaluate it for 1506 transparency and logging purposes as outlined in section 5.6 of 1507 [RFC8995]. The registrar MAY add an additional signature to the 1508 voucher-response object, by signing it using its registrar 1509 credentials (LDevID(Reg)). This signature is done over the same 1510 content as the MASA signature of the voucher and provides a proof of 1511 possession of the private key corresponding to the LDevID(Reg) the 1512 pledge received in the trigger for the PVR (see Figure 5). The 1513 registrar MUST use the same LDevID(Reg) credential that is used for 1514 authentication in the TLS handshake to authenticate towards the 1515 registrar-agent. This ensures that the same LDevID(Reg) certificate 1516 can be used to verify the signature as transmitted in the voucher 1517 request as is transferred in the pledge-voucher-request in the agent- 1518 provided-proximity-registrar-cert component. Figure Figure 13 below 1519 provides an example of the voucher with two signatures. 1521 { 1522 "payload": { 1523 "ietf-voucher:voucher": { 1524 "assertion": "agent-proximity", 1525 "serial-number": "callee4711", 1526 "nonce": "eDs++/FuDHGUnRxN3E14CQ==", 1527 "created-on": "2022-01-04T00:00:02.000Z", 1528 "pinned-domain-cert": "MIIBpDCCA...w==" 1529 }, 1530 "signatures": [ 1531 { 1532 "protected": { 1533 "alg": "ES256", 1534 "x5c": [ "base64encodedvalue==" ] 1535 }, 1536 "signature": "base64encodedvalue==" 1537 }, 1538 { 1539 "protected": { 1540 "alg": "ES256", 1541 "x5c": [ "base64encodedvalue==" ] 1542 }, 1543 "signature": "base64encodedvalue==" 1544 } 1545 ] 1546 } 1547 } 1549 Figure 13: Representation of MASA issued voucher with additional 1550 registrar signature 1552 Depending on the security policy of the operator, this signature can 1553 also be interpreted by the pledge explicit authorization of the 1554 registrar to install the contained trust anchor. The registrar sends 1555 the voucher to the registrar-agent. 1557 After receiving the voucher, the registrar-agent sends the pledge- 1558 enrollment-request (PER) to the registrar. Deviating from BRSKI the 1559 pledge-enrollment-request (PER) is not a raw PKCS#10 object. As the 1560 registrar-agent is involved in the exchange, the PKCS#10 is wrapped 1561 in a JWS object by the pledge and signed with pledge's IDevID to 1562 ensure proof-of-identity as outlined in Figure 9. 1564 [RFC7030] EST standard endpoints (/simpleenroll, /simplereenroll, 1565 /serverkeygen) on the registrar cannot be used for BRSKI-PRM. As EST 1566 requires to sent a raw PKCS#10 request to the /simpleenroll endpoint. 1567 This document makes an enhancement by utilizing EST but with the 1568 exception to transport a signature wrapped PKCS#10 request. 1569 Therefore a new endpoint for BRSKI-PRM on the registrar is defined as 1570 "/.well-known/brski/requestenroll" 1572 The Content-Type header of PER is: application/jose+json. 1574 This is a deviation from the Content-Type header values used in 1575 [RFC7030] and results in additional processing at the domain 1576 registrar (as EST server). Note, the registrar is already aware that 1577 the bootstrapping is performed in a pledge-responder-mode due to the 1578 use of the LDevID(RegAgt) EE certificate in the TLS establishment and 1579 the provided pledge-voucher-request (PVR) as JSON-in-JWS object. 1581 * If the registrar receives a pledge-enrollment-request (PER) with 1582 Content-Type header: application/jose+json, it MUST verify the 1583 wrapping signature using the certificate indicated in the JOSE 1584 header. 1586 * The registrar verifies that the pledge's certificate (here 1587 IDevID), carried in "x5c" header field, is accepted to join the 1588 domain after successful validation of the pledge-voucher-request. 1590 * If both succeed, the registrar utilizes the PKCS#10 request 1591 contained in the JWS object body as "P10" parameter of "ietf-sztp- 1592 csr:csr" for further processing of the enrollment request with the 1593 corresponding domain CA. It creates a registrar-enrollment- 1594 request (RER) by utilizing the protocol expected by the domain CA. 1595 The domain registrar may either enhance the PKCS#10 request or 1596 generate a structure containing the attributes to be included by 1597 the CA into the requested LDevID EE certificate and sends both 1598 (the original PKCS#10 request and the enhancements) to the domain 1599 CA. As enhancing the PKCS#10 request destroys the initial proof 1600 of possession of the corresponding private key, the CA would need 1601 to accept RA-verified requests. This request handling to the 1602 domain CA is out of scope for this document. 1604 The registrar-agent SHALL send the PER to the registrar by HTTP POST 1605 to the endpoint: "/.well-known/brski/requestenroll" 1606 If validation of the wrapping signature fails, the registrar SHOULD 1607 respond with the HTTP 404 error code. The HTTP 406 error code SHOULD 1608 be used, if the pledge-enrollment-request (PER) is in an unknown 1609 format. 1610 A situation that could be resolved with administrative action (such 1611 as adding a vendor/manufacturer IDevID CA as trusted party) MAY be 1612 responded with the HTTP 403 error code. 1614 A successful interaction with the domain CA will result in a pledge 1615 LDevID EE certificate, which is then forwarded by the registrar to 1616 the registrar-agent using the Content-Type header: application/ 1617 pkcs7-mime. 1619 The registrar-agent has now finished the exchanges with the domain 1620 registrar and can supply the voucher-response (from MASA via 1621 Registrar) and the enrollment-response (LDevID EE certificate, from 1622 CA via Registrar) to the pledge. It can close the TLS connection to 1623 the domain registrar and provide the objects to the pledge(s). The 1624 content of the response objects is defined by the voucher [RFC8366] 1625 and the certificate [RFC5280]. 1627 5.5.3. Response Object Supply by Registrar-Agent to Pledge 1629 The following description assumes that the registrar-agent has 1630 obtained the response objects from the domain registrar. It will re- 1631 start the interaction with the pledge. To contact the pledge, it may 1632 either discover the pledge as described in Section 5.4.2 or use 1633 stored information from the first contact with the pledge. 1635 Preconditions in addition to Section 5.5.2: 1637 * Registrar-agent: possesses voucher and LDevID certificate. 1639 +--------+ +-----------+ 1640 | Pledge | | Registrar-| 1641 | | | Agent | 1642 | | | (RegAgt) | 1643 +--------+ +-----------+ 1644 | [voucher and enrollment] 1645 | [responses available] 1646 | | 1647 |<------- supply voucher -----------| 1648 | | 1649 |--------- voucher status --------->| - store 1650 | | pledge voucher status 1651 |<--- supply enrollment response ---| 1652 | | 1653 |--------- enroll status ---------->| - store 1654 | | pledge enroll status 1656 Figure 14: Response and status handling between pledge and 1657 registrar-agent 1659 The registrar-agent provides the information via two distinct pledge 1660 endpoints as following. 1662 The registrar-agent SHALL send the voucher-response to the pledge by 1663 HTTP POST to the endpoint: "/.well-known/brski/pledge-voucher". 1665 The registrar-agent voucher-response Content-Type header is 1666 application/voucher-jws+json and contains the voucher as provided by 1667 the MASA. An example if given in Figure 12 for a MASA only signed 1668 voucher and in Figure Figure 13 for multiple signatures. 1670 If a single signature is contained, the pledge receives the voucher 1671 and verifies it as described in section 5.6.1 in [RFC8995]. 1673 If multiple signatures are contained in the voucher, the pledge SHALL 1674 perform the signature verification in the following order: 1676 1. Validate MASA signature as described in section 5.6.1 in 1677 [RFC8995] successfully. 1679 2. Install contained trust anchor provisionally. 1681 3. Verify registrar signature as described in section 5.6.1 in 1682 [RFC8995] successfully, but take the registrar certificate 1683 instead of the MASA certificate for verification. 1685 4. Validate the registrar certificate received in the agent- 1686 provided-proximity-registrar-cert in the voucher request 1687 successfully, including revocation state of the certificate, 1688 validity, and authorization to bootstrap the particular pledge. 1690 If all verification steps stated above have been performed 1691 successfully, the pledge SHALL end the provisional accept state for 1692 the domain trust anchor and the LDevID(Reg). If multiple signatures 1693 are contained in the voucher-response, the pledge MUST verify all 1694 successfully. 1696 If an error occurs during the verification it SHALL be signaled in 1697 the reason field of the pledge voucher status object. 1699 After verification the pledge MUST reply with a status telemetry 1700 message as defined in section 5.7 of [RFC8995]. 1701 The pledge generates the voucher status object and provides it as 1702 JOSE object with the wrapping signature in the response message to 1703 the registrar-agent. 1705 The response has the Content-Type application/jose+json and is signed 1706 using the IDevID of the pledge as shown in Figure 15. As the reason 1707 field is optional (see [RFC8995]), it MAY be omitted in case of 1708 success. 1710 { 1711 "payload": { 1712 "version": 1, 1713 "status": true, 1714 "reason": "Informative human readable message", 1715 "reason-context": { 1716 "additional": "JSON" 1717 } 1718 }, 1719 "signatures": [ 1720 { 1721 "protected": { 1722 "alg": "ES256", 1723 "x5c": [ "base64encodedvalue==" ] 1724 }, 1725 "signature": "base64encodedvalue==" 1726 } 1727 ] 1728 } 1730 Figure 15: Representation of pledge voucher status telemetry 1732 The registrar-agent SHALL send the enroll-response to the pledge by 1733 HTTP POST to the endpoint: "/.well-known/brski/pledge-enrollment". 1735 The registrar-agent enroll-response Content-Type header, when using 1736 EST [RFC7030] as enrollment protocol between the registrar-agent and 1737 the infrastructure, is application/pkcs7-mime. Note that it only 1738 contains the LDevID certificate for the pledge, not the certificate 1739 chain. 1741 Upon reception, the pledge SHALL verify the received LDevID EE 1742 certificate. The pledge MAY omit the revocation check as the EE 1743 LDevID certificate was freshly issued.. The pledge SHALL generate 1744 the enroll status object and provide it in the response message to 1745 the registrar-agent. If the verification of the LDevID EE 1746 certificate succeeds, the status SHALL be set to true, otherwise to 1747 FALSE. 1749 The pledge MUST reply with a status telemetry message as defined in 1750 section 5.9.4 of [RFC8995]. As for the other objects, the enrollment 1751 status object is provided with an additional signature using JOSE. 1752 If the pledge verified the received LDevID EE certificate 1753 successfully it SHALL sign the response using the LDevID of the 1754 pledge as shown in Figure 16. In the failure case, the pledge SHALL 1755 use the available IdevID credentials. As the reason field is 1756 optional, it MAY be omitted in case of success. 1758 The response has the Content-Type application/jose+json. 1760 { 1761 "payload": { 1762 "version": 1, 1763 "status": true, 1764 "reason": "Informative human readable message", 1765 "reason-context": { 1766 "additional": "JSON" 1767 } 1768 }, 1769 "signatures": [ 1770 { 1771 "protected": { 1772 "alg": "ES256", 1773 "x5c": [ "base64encodedvalue==" ] 1774 }, 1775 "signature": "base64encodedvalue==" 1776 } 1777 ] 1778 } 1779 Figure 16: Representation of pledge enroll status telemetry 1781 Once the registrar-agent has collected the information, it can 1782 connect to the registrar-agent to provide the status responses to the 1783 registrar. 1785 5.5.4. Telemetry status handling (registrar-agent - domain registrar) 1787 The following description requires that the registrar-agent has 1788 collected the status objects from the pledge. It SHALL provide the 1789 status objects to the registrar for further processing. 1791 Preconditions in addition to Section 5.5.2: 1793 * Registrar-agent: possesses voucher status and enroll status 1794 objects from pledge. 1796 +-----------+ +-----------+ +--------+ +---------+ 1797 | Registrar | | Domain | | Domain | | Vendor | 1798 | Agent | | Registrar | | CA | | Service | 1799 | RegAgt) | | (JRC) | | | | (MASA) | 1800 +-----------+ +-----------+ +--------+ +---------+ 1801 | | | Internet | 1802 [voucher + enroll ] | | | 1803 [status objects avail.]| | | 1804 | | | | 1805 |<----- mTLS ----->| | | 1806 | | | | 1807 |--Voucher Status->| | | 1808 | |<---- device audit log ----| 1809 | [verify audit log ] 1810 | | | | 1811 |--Enroll Status-->| | | 1812 | | | | 1813 | | | | 1815 Figure 17: Bootstrapping status handling 1817 The registrar-agent MUST provide the collected pledge voucher status 1818 object to the registrar. This status indicates if the pledge could 1819 process the voucher successfully or not. 1821 If the TLS connection to the registrar was closed, the registrar- 1822 agent establishes a TLS connection with the registrar as stated in 1823 Section 5.5.2. 1825 The registrar-agent sends the pledge voucher status object without 1826 modification to the registrar with an HTTP-over-TLS POST using the 1827 registrar endpoint "/.well-known/brski/voucher_status". The Content- 1828 Type header is kept as application/jose+json as described in 1829 Figure 14 and depicted in the example in Figure 15. 1831 The registrar SHALL verify the signature of the pledge voucher status 1832 object and validate that it belongs to an accepted device in his 1833 domain based on the contained "serial-number" in the IDevID 1834 certificate referenced in the header of the voucher status object. 1836 According to [RFC8995] section 5.7, the registrar SHOULD respond with 1837 an HTTP 200 but MAY simply fail with an HTTP 404 error. The 1838 registrar-agent may use the response to signal success / failure to 1839 the service technician operating the registrar agent. Within the 1840 server logs the server SHOULD capture this telemetry information. 1842 The registrar SHOULD proceed with collecting and logging status 1843 information by requesting the MASA audit-log from the MASA service as 1844 described in section 5.8 of [RFC8995]. 1846 The registrar-agent MUST provide the pledge's enroll status object to 1847 the registrar. The status indicates the pledge could process the 1848 enroll-response object and holds the corresponding private key. 1850 The registrar-agent sends the pledge enroll status object without 1851 modification to the registrar with an HTTP-over-TLS POST using the 1852 registrar endpoint "/.well-known/brski/enrollstatus". The Content- 1853 Type header is kept as application/jose+json as described in 1854 Figure 14 and depicted in the example in Figure 16. 1856 The registrar SHALL verify the signature of the pledge enroll status 1857 object. In case the enroll status object indicates success the 1858 registrar SHALL validate that the pledge belongs to an accepted 1859 device in his domain based on the contained product-serial-number in 1860 the LDevID EE certificate referenced in the header of the enroll 1861 status object. In case the enroll status object indicates a failure, 1862 the pledge was unable to verify the received LDevID EE certificate 1863 and therefore signed the enroll status objects with its IDevID 1864 credential. Note that the verification of a signature of the object 1865 is a deviation from the described handling in section 5.9.4 of 1866 [RFC8995]. 1868 According to [RFC8995] section 5.9.4, the registrar SHOULD respond 1869 with an HTTP 200 but MAY simply fail with an HTTP 404 error. The 1870 registrar-agent may use the response to signal success / failure to 1871 the service technician operating the registrar agent. Within the 1872 server log the registrar SHOULD capture this telemetry information. 1874 6. Artifacts 1876 6.1. Voucher Request Artifact 1878 The following enhancement extends the voucher-request as defined in 1879 [RFC8995] to include additional fields necessary for handling 1880 bootstrapping in the pledge-responder-mode. 1882 6.1.1. Tree Diagram 1884 The following tree diagram is mostly a duplicate of the contents of 1885 [RFC8995], with the addition of the fields agent-signed-data, the 1886 registrar-proximity-certificate, and agent-signing certificate. The 1887 tree diagram is described in [RFC8340]. Each node in the diagram is 1888 fully described by the YANG module in Section Section 6.1.2. 1890 module: ietf-voucher-request-prm 1892 grouping voucher-request-prm-grouping 1893 +-- voucher 1894 +-- created-on? yang:date-and-time 1895 +-- expires-on? yang:date-and-time 1896 +-- assertion? enumeration 1897 +-- serial-number string 1898 +-- idevid-issuer? binary 1899 +-- pinned-domain-cert? binary 1900 +-- domain-cert-revocation-checks? boolean 1901 +-- nonce? binary 1902 +-- last-renewal-date? yang:date-and-time 1903 +-- prior-signed-voucher-request? binary 1904 +-- proximity-registrar-cert? binary 1905 +-- agent-signed-data? binary 1906 +-- agent-provided-proximity-registrar-cert? binary 1907 +-- agent-sign-cert? binary 1909 6.1.2. YANG Module 1911 The following YANG module extends the [RFC8995] Voucher Request to 1912 include a signed artifact from the registrar-agent (agent-signed- 1913 data) as well as the registrar-proximity-certificate and the agent- 1914 signing certificate. 1916 file "ietf-voucher-request-prm@2021-12-16.yang" 1917 module ietf-voucher-request-prm { 1918 yang-version 1.1; 1920 namespace "urn:ietf:params:xml:ns:yang:ietf-voucher-request-prm"; 1921 prefix vrprm; 1922 import ietf-restconf { 1923 prefix rc; 1924 description 1925 "This import statement is only present to access 1926 the yang-data extension defined in RFC 8040."; 1927 reference "RFC 8040: RESTCONF Protocol"; 1928 } 1930 import ietf-voucher-request { 1931 prefix vcr; 1932 description 1933 "This module defines the format for a voucher request, 1934 which is produced by a pledge as part of the RFC8995 1935 onboarding process."; 1936 reference 1937 "RFC 8995: Bootstrapping Remote Secure Key Infrastructure"; 1938 } 1940 organization 1941 "IETF ANIMA Working Group"; 1943 contact 1944 "WG Web: 1945 WG List: 1946 Author: Steffen Fries 1947 1948 Author: Eliot Lear 1949 1950 Author: Thomas Werner 1951 1952 Author: Michael Richardson 1953 "; 1955 description 1956 "This module defines the format for a voucher-request. 1957 It is a superset of the voucher itself. 1958 It provides content to the MASA for consideration 1959 during a voucher-request. 1961 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1962 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1963 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1964 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1965 they appear in all capitals, as shown here. 1967 Copyright (c) 2022 IETF Trust and the persons identified as 1968 authors of the code. All rights reserved. 1970 Redistribution and use in source and binary forms, with or 1971 without modification, is permitted pursuant to, and subject 1972 to the license terms contained in, the Simplified BSD License 1973 set forth in Section 4.c of the IETF Trust's Legal Provisions 1974 Relating to IETF Documents 1975 (https://trustee.ietf.org/license-info). 1977 This version of this YANG module is part of RFC 8995; see the 1978 RFC itself for full legal notices."; 1980 revision 2021-12-16 { 1981 description 1982 "Initial version"; 1983 reference 1984 "RFC XXXX: BRSKI for Pledge in Responder Mode"; 1985 } 1987 // Top-level statement 1988 rc:yang-data voucher-request-prm-artifact { 1989 // YANG data template for a voucher-request. 1990 uses voucher-request-prm-grouping; 1991 } 1992 // Grouping defined for future usage 1993 grouping voucher-request-prm-grouping { 1994 description 1995 "Grouping to allow reuse/extensions in future work."; 1996 uses vcr:voucher-request-grouping { 1997 refine "voucher/expires-on" { 1998 mandatory false; 1999 description 2000 "An expires-on field is not valid in a 2001 voucher-request, and any occurrence MUST be ignored."; 2002 } 2003 refine "voucher/pinned-domain-cert" { 2004 mandatory false; 2005 description 2006 "A pinned-domain-cert field is not valid in a 2007 voucher-request, and any occurrence MUST be ignored."; 2008 } 2009 refine "voucher/last-renewal-date" { 2010 description 2011 "A last-renewal-date field is not valid in a 2012 voucher-request, and any occurrence MUST be ignored."; 2013 } 2014 refine "voucher/domain-cert-revocation-checks" { 2015 description 2016 "The domain-cert-revocation-checks field is not valid in a 2017 voucher-request, and any occurrence MUST be ignored."; 2018 } 2019 refine "voucher/assertion" { 2020 mandatory false; 2021 description 2022 "Any assertion included in registrar voucher-requests 2023 SHOULD be ignored by the MASA."; 2024 } 2026 augment voucher { 2027 description "Base the voucher-request-prm upon the 2028 regular one"; 2029 leaf agent-signed-data { 2030 type binary; 2031 description 2032 "The agent-signed-data field contains a JOSE [RFC7515] 2033 object provided by the Registrar-Agent to the Pledge. 2035 This artifact is signed by the Registrar-Agent 2036 and contains a copy of the pledge's serial-number."; 2037 } 2039 leaf agent-provided-proximity-registrar-cert { 2040 type binary; 2041 description 2042 "An X.509 v3 certificate structure, as specified by 2043 RFC 5280, Section 4, encoded using the ASN.1 2044 distinguished encoding rules (DER), as specified 2045 in ITU X.690. 2046 The first certificate in the registrar TLS server 2047 certificate_list sequence (the end-entity TLS 2048 certificate; see RFC 8446) presented by the 2049 registrar to the registrar-agent and provided to 2050 the pledge. 2051 This MUST be populated in a pledge's voucher-request 2052 when an agent-proximity assertion is requested."; 2053 reference 2054 "ITU X.690: Information Technology - ASN.1 encoding 2055 rules: Specification of Basic Encoding Rules (BER), 2056 Canonical Encoding Rules (CER) and Distinguished 2057 Encoding Rules (DER) 2058 RFC 5280: Internet X.509 Public Key Infrastructure 2059 Certificate and Certificate Revocation List (CRL) 2060 Profile 2061 RFC 8446: The Transport Layer Security (TLS) 2062 Protocol Version 1.3"; 2063 } 2064 leaf-list agent-sign-cert { 2065 type binary; 2066 min-elements 1; 2067 description 2068 "An X.509 v3 certificate structure, as specified by 2069 RFC 5280, Section 4, encoded using the ASN.1 2070 distinguished encoding rules (DER), as specified 2071 in ITU X.690. 2072 This certificate can be used by the pledge, 2073 the registrar, and the MASA to verify the signature 2074 of agent-signed-data. It is an optional component 2075 for the pledge-voucher request. 2076 This MUST be populated in a registrar's 2077 voucher-request when an agent-proximity assertion 2078 is requested. 2079 It is defined as list to enable inclusion of further 2080 certificates along the certificate chain if different 2081 issuing CAs have been used for the registrar-agent 2082 and the registrar."; 2083 reference 2084 "ITU X.690: Information Technology - ASN.1 encoding 2085 rules: Specification of Basic Encoding Rules (BER), 2086 Canonical Encoding Rules (CER) and Distinguished 2087 Encoding Rules (DER) 2088 RFC 5280: Internet X.509 Public Key Infrastructure 2089 Certificate and Certificate Revocation List (CRL) 2090 Profile"; 2091 } 2092 } 2093 } 2094 } 2095 } 2096 2098 Examples for the pledge-voucher-request are provided in 2099 Section 5.5.2. 2101 7. IANA Considerations 2103 This document requires the following IANA actions. 2105 7.1. BRSKI .well-known Registry 2107 IANA is requested to enhance the Registry entitled: "BRSKI Well-Known 2108 URIs" with the following endpoints: 2110 URI Description Reference 2111 pledge-voucher-request create pledge-voucher-request [THISRFC] 2112 pledge-enrollment-request create pledge-enrollment-request [THISRFC] 2113 pledge-voucher supply voucher response [THISRFC] 2114 pledge-enrollment supply enrollment response [THISRFC] 2115 pledge-CACerts supply CA certs to pledge [THISRFC] 2116 requestenroll supply PER to registrar [THISRFC] 2118 8. Privacy Considerations 2120 The credential used by the registrar-agent to sign the data for the 2121 pledge in case of the pledge-initiator-mode should not contain 2122 personal information. Therefore, it is recommended to use an LDevID 2123 certificate associated with the device instead of a potential service 2124 technician operating the device, to avoid revealing this information 2125 to the MASA. 2127 9. Security Considerations 2129 9.1. Exhaustion Attack on Pledge 2131 Exhaustion attack on pledge based on DoS attack (connection 2132 establishment, etc.) 2134 9.2. Misuse of acquired Voucher and Enrollment objects by Registrar- 2135 Agent 2137 A Registrar-agent that uses acquired voucher and enrollment objects 2138 for domain-A in domain-B can be avoided by the pledge-voucher-request 2139 processing on the domain registrar side. This requires the domain 2140 registrar to verify the "proximity-registrar-cert" field in the 2141 pledge-voucher-request (PVR) against his own LDevID(Reg). In 2142 addition, the domain registrar has to verify the association of the 2143 pledge to his domain based on the product-serial-number contained in 2144 the pledge-voucher-request (PvR) and in the pledge IDevID 2145 certificate. Moreover, the registrar verifies if the registrar-agent 2146 is authorized to interact with the pledge for voucher-requests, based 2147 on the LDevID(RegAgt) EE certificate information contained in the 2148 pledge-voucher-request (PVR). 2150 Misbinding of a pledge by a faked domain registrar is countered as 2151 described in BRSKI security considerations (section 11.4). 2153 9.3. Misuse of Registrar-Agent Credentials 2155 Concerns on opportunities to misuse the registrar-agent with a valid 2156 LDevID, may be addressed by utilizing short-lived certificates (e.g., 2157 valid for a day) to authenticate the registrar-agent against the 2158 domain registrar. The LDevID(RegAgt) certificate may be acquired by 2159 a prior BRSKI run for the registrar-agent, if IDevID is available on 2160 registrar-agent. Alternatively, the LDevID may be acquired by a 2161 service technician from the domain PKI system. 2163 In addition it is required that the LDevID(RegAgt) certificate is 2164 valid for the complete bootstrapping phase. This avoids a registrar- 2165 agent could be misused to create arbitrary "agent-signed-data" 2166 objects to perform an authorized bootstrapping of a rouge pledge. As 2167 "agent-signed-data" could be dated after the validity time of the 2168 LDevID(RegAgt) EE certificate, due to missing trusted timestamp in 2169 the registrar-agents signature. 2170 To address this, the registrar SHOULD verify the certificate used to 2171 create the signature on "agent-signed-data". Furthermore the 2172 registrar also verifies the LDevID(RegAgt) EE certificate used in the 2173 TLS handshake. If both certificates are successfully verified, the 2174 registrar-agents signature can be considered as valid. 2176 9.4. YANG Module Security Considerations 2178 The enhanced voucher-request described in section Section 6.1 is 2179 bases on [RFC8995], but uses a different encoding based on 2180 [I-D.ietf-anima-jws-voucher]. Therefore similar considerations as 2181 described in Section 11.7 (Security Considerations) of [RFC8995] 2182 apply. The YANG module specified in this document defines the schema 2183 for data that is subsequently encapsulated by a JOSE signed-data 2184 Content-type as described in [I-D.ietf-anima-jws-voucher]. As such, 2185 all of the YANG-modeled data is protected against modification. The 2186 use of YANG to define data structures via the "yang-data" statement, 2187 is relatively new and distinct from the traditional use of YANG to 2188 define an API accessed by network management protocols such as 2189 NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason these 2190 guidelines do not follow the template described by Section 3.7 of 2191 [RFC8407]. 2193 10. Acknowledgments 2195 We would like to thank the various reviewers, in particular Brian E. 2196 Carpenter and Oskar Camenzind, for their input and discussion on use 2197 cases and call flows. 2199 11. References 2200 11.1. Normative References 2202 [I-D.ietf-anima-jws-voucher] 2203 Richardson, M. and T. Werner, "JWS signed Voucher 2204 Artifacts for Bootstrapping Protocols", Work in Progress, 2205 Internet-Draft, draft-ietf-anima-jws-voucher-03, 7 March 2206 2022, . 2209 [I-D.ietf-anima-rfc8366bis] 2210 Watsen, K., Richardson, M. C., Pritikin, M., Eckert, T., 2211 and Q. Ma, "A Voucher Artifact for Bootstrapping 2212 Protocols", Work in Progress, Internet-Draft, draft-ietf- 2213 anima-rfc8366bis-00, 31 January 2022, 2214 . 2217 [I-D.ietf-netconf-sztp-csr] 2218 Watsen, K., Housley, R., and S. Turner, "Conveying a 2219 Certificate Signing Request (CSR) in a Secure Zero Touch 2220 Provisioning (SZTP) Bootstrapping Request", Work in 2221 Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14, 2222 2 March 2022, . 2225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2226 Requirement Levels", BCP 14, RFC 2119, 2227 DOI 10.17487/RFC2119, March 1997, 2228 . 2230 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2231 and A. Bierman, Ed., "Network Configuration Protocol 2232 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2233 . 2235 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2236 DOI 10.17487/RFC6762, February 2013, 2237 . 2239 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2240 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2241 . 2243 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 2244 "Enrollment over Secure Transport", RFC 7030, 2245 DOI 10.17487/RFC7030, October 2013, 2246 . 2248 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 2249 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2250 2015, . 2252 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2253 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2254 . 2256 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2257 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2258 May 2017, . 2260 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2261 "A Voucher Artifact for Bootstrapping Protocols", 2262 RFC 8366, DOI 10.17487/RFC8366, May 2018, 2263 . 2265 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 2266 Documents Containing YANG Data Models", BCP 216, RFC 8407, 2267 DOI 10.17487/RFC8407, October 2018, 2268 . 2270 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2271 and K. Watsen, "Bootstrapping Remote Secure Key 2272 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 2273 May 2021, . 2275 11.2. Informative References 2277 [BRSKI-PRM-abstract] 2278 "Abstract BRSKI-PRM Protocol Overview", April 2022, 2279 . 2282 [IEEE-802.1AR] 2283 Institute of Electrical and Electronics Engineers, "IEEE 2284 802.1AR Secure Device Identifier", IEEE 802.1AR, June 2285 2018. 2287 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 2288 Request Syntax Specification Version 1.7", RFC 2986, 2289 DOI 10.17487/RFC2986, November 2000, 2290 . 2292 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2293 Housley, R., and W. Polk, "Internet X.509 Public Key 2294 Infrastructure Certificate and Certificate Revocation List 2295 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2296 . 2298 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 2299 RFC 8152, DOI 10.17487/RFC8152, July 2017, 2300 . 2302 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 2303 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 2304 . 2306 Appendix A. History of Changes [RFC Editor: please delete] 2308 From IETF draft 02 -> IETF draft 03: 2310 * Updated examples to state "base64encodedvalue==" for x5c 2311 occurrences 2313 * Include link to SVG graphic as general overview 2315 * Restructuring of section 5 to flatten hierarchy 2317 * Enhanced requirements and motivation in Section 4 2319 * Several editorial improvements based on review comments 2321 From IETF draft 01 -> IETF draft 02: 2323 * Issue #15 included additional signature on voucher from registrar 2324 in section Section 5.5.2 and section Section 5.2 The verification 2325 of multiple signatures is described in section Section 5.5.3 2327 * Included representation for General JWS JSON Serialization for 2328 examples 2330 * Included error responses from pledge if it is not able to create a 2331 pledge-voucher request or an enrollment request in section 2332 Section 5.5.1 2334 * Removed open issue regarding handling of multiple CSRs and 2335 enrollment responses during the bootstrapping as the initial 2336 target it the provisioning of a generic LDevID certificate. The 2337 defined endpoint on the pledge may also be used for management of 2338 further certificates. 2340 From IETF draft 00 -> IETF draft 01: 2342 * Issue #15 lead to the inclusion of an option for an additional 2343 signature of the registrar on the voucher received from the MASA 2344 before forwarding to the registrar-agent to support verification 2345 of POP of the registrars private key in section Section 5.5.2 and 2346 Section 5.5.3. 2348 * Based on issue #11, a new endpoint was defined for the registrar 2349 to enable delivery of the wrapped enrollment request from the 2350 pledge (in contrast to plain PKCS#10 in simple enroll). 2352 * Decision on issue #8 to not provide an additional signature on the 2353 enrollment-response object by the registrar. As the enrollment 2354 response will only contain the generic LDevID EE certificate. 2355 This credential builds the base for further configuration outside 2356 the initial enrollment. 2358 * Decision on issue #7 to not support multiple CSRs during the 2359 bootstrapping, as based on the generic LDevID EE certificate the 2360 pledge may enroll for further certificates. 2362 * Closed open issue #5 regarding verification of ietf-ztp-types 2363 usage as verified via a proof-of-concept in section 2364 {#exchanges_uc2_1}. 2366 * Housekeeping: Removed already addressed open issues stated in the 2367 draft directly. 2369 * Reworked text in from introduction to section pledge-responder- 2370 mode 2372 * Fixed "serial-number" encoding in PVR/RVR 2374 * Added prior-signed-voucher-request in the parameter description of 2375 the registrar-voucher-request in Section 5.5.2. 2377 * Note added in Section 5.5.2 if sub-CAs are used, that the 2378 corresponding information is to be provided to the MASA. 2380 * Inclusion of limitation section (pledge sleeps and needs to be 2381 waked up. Pledge is awake but registrar-agent is not available) 2382 (Issue #10). 2384 * Assertion-type aligned with voucher in RFC8366bis, deleted related 2385 open issues. (Issue #4) 2387 * Included table for endpoints in Section 5.3 for better 2388 readability. 2390 * Included registrar authorization check for registrar-agent during 2391 TLS handshake in section Section 5.5.2. Also enhanced figure 2392 Figure 10 with the authorization step on TLS level. 2394 * Enhanced description of registrar authorization check for 2395 registrar-agent based on the agent-signed-data in section 2396 Section 5.5.2. Also enhanced figure Figure 10 with the 2397 authorization step on pledge-voucher-request level. 2399 * Changed agent-signed-cert to an array to allow for providing 2400 further certificate information like the issuing CA cert for the 2401 LDevID(RegAgt) EE certificate in case the registrar and the 2402 registrar-agent have different issuing CAs in Figure 10 (issue 2403 #12). This also required changes in the YANG module in 2404 Section 6.1.2 2406 * Addressed YANG warning (issue #1) 2408 * Inclusion of examples for a trigger to create a pledge-voucher- 2409 request and an enrollment-request. 2411 From IETF draft-ietf-anima-brski-async-enroll-03 -> IETF anima-brski- 2412 prm-00: 2414 * Moved UC2 related parts defining the pledge in responder mode from 2415 draft-ietf-anima-brski-async-enroll-03 to this document This 2416 required changes and adaptations in several sections to remove the 2417 description and references to UC1. 2419 * Addressed feedback for voucher-request enhancements from YANG 2420 doctor early review in Section 6.1 as well as in the security 2421 considerations (formerly named ietf-async-voucher-request). 2423 * Renamed ietf-async-voucher-request to IETF-voucher-request-prm to 2424 to allow better listing of voucher related extensions; aligned 2425 with constraint voucher (#20) 2427 * Utilized ietf-voucher-request-async instead of ietf-voucher- 2428 request in voucher exchanges to utilize the enhanced voucher- 2429 request. 2431 * Included changes from draft-ietf-netconf-sztp-csr-06 regarding the 2432 YANG definition of csr-types into the enrollment request exchange. 2434 From IETF draft 02 -> IETF draft 03: 2436 * Housekeeping, deleted open issue regarding YANG voucher-request in 2437 Section 5.5.1 as voucher-request was enhanced with additional 2438 leaf. 2440 * Included open issues in YANG model in Section 5.1 regarding 2441 assertion value agent-proximity and csr encapsulation using SZTP 2442 sub module). 2444 From IETF draft 01 -> IETF draft 02: 2446 * Defined call flow and objects for interactions in UC2. Object 2447 format based on draft for JOSE signed voucher artifacts and 2448 aligned the remaining objects with this approach in Section 5.5 . 2450 * Terminology change: issue #2 pledge-agent -> registrar-agent to 2451 better underline agent relation. 2453 * Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode 2454 and pledge-responder-mode to better address the pledge operation. 2456 * Communication approach between pledge and registrar-agent changed 2457 by removing TLS-PSK (former section TLS establishment) and 2458 associated references to other drafts in favor of relying on 2459 higher layer exchange of signed data objects. These data objects 2460 are included also in the pledge-voucher-request and lead to an 2461 extension of the YANG module for the voucher-request (issue #12). 2463 * Details on trust relationship between registrar-agent and 2464 registrar (issue #4, #5, #9) included in Section 5.1. 2466 * Recommendation regarding short-lived certificates for registrar- 2467 agent authentication towards registrar (issue #7) in the security 2468 considerations. 2470 * Introduction of reference to agent signing certificate using SKID 2471 in agent signed data (issue #11). 2473 * Enhanced objects in exchanges between pledge and registrar-agent 2474 to allow the registrar to verify agent-proximity to the pledge 2475 (issue #1) in Section 5.5. 2477 * Details on trust relationship between registrar-agent and pledge 2478 (issue #5) included in Section 5.1. 2480 * Split of use case 2 call flow into sub sections in Section 5.5. 2482 From IETF draft 00 -> IETF draft 01: 2484 * Update of scope in Section 3.1 to include in which the pledge acts 2485 as a server. This is one main motivation for use case 2. 2487 * Rework of use case 2 in Section 5.1 to consider the transport 2488 between the pledge and the pledge-agent. Addressed is the TLS 2489 channel establishment between the pledge-agent and the pledge as 2490 well as the endpoint definition on the pledge. 2492 * First description of exchanged object types (needs more work) 2494 * Clarification in discovery options for enrollment endpoints at the 2495 domain registrar based on well-known endpoints do not result in 2496 additional /.well-known URIs. Update of the illustrative example. 2497 Note that the change to /brski for the voucher related endpoints 2498 has been taken over in the BRSKI main document. 2500 * Updated references. 2502 * Included Thomas Werner as additional author for the document. 2504 From individual version 03 -> IETF draft 00: 2506 * Inclusion of discovery options of enrollment endpoints at the 2507 domain registrar based on well-known endpoints in new section as 2508 replacement of section 5.1.3 in the individual draft. This is 2509 intended to support both use cases in the document. An 2510 illustrative example is provided. 2512 * Missing details provided for the description and call flow in 2513 pledge-agent use case Section 5.1, e.g. to accommodate 2514 distribution of CA certificates. 2516 * Updated CMP example in to use lightweight CMP instead of CMP, as 2517 the draft already provides the necessary /.well-known endpoints. 2519 * Requirements discussion moved to separate section in Section 4. 2520 Shortened description of proof of identity binding and mapping to 2521 existing protocols. 2523 * Removal of copied call flows for voucher exchange and registrar 2524 discovery flow from [RFC8995] in UC1 to avoid doubling or text or 2525 inconsistencies. 2527 * Reworked abstract and introduction to be more crisp regarding the 2528 targeted solution. Several structural changes in the document to 2529 have a better distinction between requirements, use case 2530 description, and solution description as separate sections. 2531 History moved to appendix. 2533 From individual version 02 -> 03: 2535 * Update of terminology from self-contained to authenticated self- 2536 contained object to be consistent in the wording and to underline 2537 the protection of the object with an existing credential. Note 2538 that the naming of this object may be discussed. An alternative 2539 name may be attestation object. 2541 * Simplification of the architecture approach for the initial use 2542 case having an offsite PKI. 2544 * Introduction of a new use case utilizing authenticated self- 2545 contain objects to onboard a pledge using a commissioning tool 2546 containing a pledge-agent. This requires additional changes in 2547 the BRSKI call flow sequence and led to changes in the 2548 introduction, the application example,and also in the related 2549 BRSKI-PRM call flow. 2551 From individual version 01 -> 02: 2553 * Update of introduction text to clearly relate to the usage of 2554 IDevID and LDevID. 2556 * Update of description of architecture elements and changes to 2557 BRSKI in Section 5. 2559 * Enhanced consideration of existing enrollment protocols in the 2560 context of mapping the requirements to existing solutions in 2561 Section 4. 2563 From individual version 00 -> 01: 2565 * Update of examples, specifically for building automation as well 2566 as two new application use cases in Section 3.2. 2568 * Deletion of asynchronous interaction with MASA to not complicate 2569 the use case. Note that the voucher exchange can already be 2570 handled in an asynchronous manner and is therefore not considered 2571 further. This resulted in removal of the alternative path the 2572 MASA in Figure 1 and the associated description in Section 5. 2574 * Enhancement of description of architecture elements and changes to 2575 BRSKI in Section 5. 2577 * Consideration of existing enrollment protocols in the context of 2578 mapping the requirements to existing solutions in Section 4. 2580 * New section starting with the mapping to existing enrollment 2581 protocols by collecting boundary conditions. 2583 Authors' Addresses 2585 Steffen Fries 2586 Siemens AG 2587 Otto-Hahn-Ring 6 2588 81739 Munich 2589 Germany 2590 Email: steffen.fries@siemens.com 2591 URI: https://www.siemens.com/ 2593 Thomas Werner 2594 Siemens AG 2595 Otto-Hahn-Ring 6 2596 81739 Munich 2597 Germany 2598 Email: thomas-werner@siemens.com 2599 URI: https://www.siemens.com/ 2601 Eliot Lear 2602 Cisco Systems 2603 Richtistrasse 7 2604 CH-8304 Wallisellen 2605 Switzerland 2606 Phone: +41 44 878 9200 2607 Email: lear@cisco.com 2609 Michael C. Richardson 2610 Sandelman Software Works 2611 Email: mcr+ietf@sandelman.ca 2612 URI: http://www.sandelman.ca/