idnits 2.17.1 draft-ietf-anima-brski-async-enroll-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2020) is 1385 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) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-01 == Outdated reference: A later version (-06) exists of draft-selander-ace-coap-est-oscore-03 -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG S. Fries 3 Internet-Draft H. Brockhaus 4 Intended status: Standards Track Siemens 5 Expires: January 11, 2021 E. Lear 6 Cisco Systems 7 July 10, 2020 9 Support of asynchronous Enrollment in BRSKI (BRSKI-AE) 10 draft-ietf-anima-brski-async-enroll-00 12 Abstract 14 This document describes enhancements of bootstrapping a remote secure 15 key infrastructure (BRSKI) to also operate in domains featuring no or 16 only timely limited connectivity between involved components. It 17 addresses connectivity to backend services supporting enrollment like 18 a Public Key Infrastructure (PKI) and also to the connectivity 19 between pledge and registrar. For this it enhances the use of 20 authenticated self-contained objects in BRSKI also for request and 21 distribution of deployment domain specific device certificates. The 22 defined approach is agnostic regarding the utilized enrollment 23 protocol allowing the application of existing and potentially new 24 certificate management protocols. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 11, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Scope of solution . . . . . . . . . . . . . . . . . . . . . . 7 63 3.1. Supported environment . . . . . . . . . . . . . . . . . . 7 64 3.2. Application Examples . . . . . . . . . . . . . . . . . . 7 65 3.2.1. Rolling stock . . . . . . . . . . . . . . . . . . . . 7 66 3.2.2. Building automation . . . . . . . . . . . . . . . . . 8 67 3.2.3. Substation automation . . . . . . . . . . . . . . . . 8 68 3.2.4. Electric vehicle charging infrastructure . . . . . . 8 69 3.2.5. Infrastructure isolation policy . . . . . . . . . . . 9 70 3.2.6. Less operational security in the deployment domain . 9 71 4. Requirement discussion and mapping to solution elements . . . 9 72 5. Architectural Overview and Communication Exchanges . . . . . 12 73 5.1. Use Case 1: Support of off-site PKI service . . . . . . . 12 74 5.1.1. Behavior of a pledge . . . . . . . . . . . . . . . . 15 75 5.1.2. Pledge - Registrar discovery and voucher exchange . . 15 76 5.1.3. Registrar - MASA voucher exchange . . . . . . . . . . 16 77 5.1.4. Pledge - Registrar - RA/CA certificate enrollment . . 16 78 5.1.5. Addressing Scheme Enhancements . . . . . . . . . . . 19 79 5.2. Use Case 2: pledge-agent . . . . . . . . . . . . . . . . 19 80 5.2.1. Behavior of a pledge . . . . . . . . . . . . . . . . 23 81 5.2.2. Behavior of a pledge-agent . . . . . . . . . . . . . 24 82 5.2.3. Registrar discovery . . . . . . . . . . . . . . . . . 24 83 5.2.4. Handling voucher request and certification requests . 24 84 5.3. Discovery of supported enrollment options at domain 85 registrar . . . . . . . . . . . . . . . . . . . . . . . . 27 86 6. Example mappings to existing enrollment protocols . . . . . . 28 87 6.1. EST Handling . . . . . . . . . . . . . . . . . . . . . . 29 88 6.2. Lightweight CMP Handling . . . . . . . . . . . . . . . . 29 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 90 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 92 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 95 11.2. Informative References . . . . . . . . . . . . . . . . . 31 97 Appendix A. History of changes [RFC Editor: please delete] . . . 32 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 100 1. Introduction 102 BRSKI as defined in [I-D.ietf-anima-bootstrapping-keyinfra] specifies 103 a solution for secure zero-touch (automated) bootstrapping of devices 104 (pledges) in a target deployment domain. This includes the discovery 105 of network elements in the deployment domain, time synchronization, 106 and the exchange of security information necessary to establish trust 107 between a pledge and the domain and to adopt a pledge as new network 108 and application element. Security information about the deployment 109 domain, specifically the deployment domain certificate (domain root 110 certificate), is exchanged utilizing voucher objects as defined in 111 [RFC8366]. These vouchers are authenticated self-contained (signed) 112 objects, which may be provided online (synchronous) or offline 113 (asynchronous) via the domain registrar to the pledge and originate 114 from a Manufacturer's Authorized Signing Authority (MASA). The MASA 115 signed voucher contains the target domain certificate and can be 116 verified by the pledge due to the possession of a manufacturer root 117 certificate. It facilitates the enrollment of the pledge in the 118 deployment domain and is used to establish trust from the pledge to 119 the domain. 121 For the enrollment of devices BRSKI relies on EST [RFC7030] to 122 request and distribute deployment domain specific device 123 certificates. EST in turn relies on a binding of the certification 124 request to an underlying TLS connection between the EST client and 125 the EST server. According to BRSKI the domain registrar acts as EST 126 server and is also acting as registration authority (RA) or local 127 registration authority (LRA). The binding to TLS is used to protect 128 the exchange of a certification request (for an LDevID certificate) 129 and to provide data origin authentication to support the 130 authorization decision for processing the certification request. The 131 TLS connection is mutually authenticated and the client side 132 authentication utilizes the pledge's manufacturer issued device 133 certificate (IDevID certificate). This approach requires an on-site 134 availability of a local asset or inventory management system 135 performing the authorization decision based on tuple of the 136 certification request and the pledge authentication using the IDevID 137 certificate, to issue a domain specific certificate to the pledge. 138 The reason bases on the EST server (the domain registrar) terminating 139 the security association with the pledge and thus the local binding 140 between the certification request and the authentication of the 141 pledge. This type of enrollment utilizing an online connection to 142 the PKI is considered as synchronous enrollment. 144 For certain use cases on-site support of a RA/CA component and/or an 145 asset management is not available and rather provided by an 146 operator's backend and may be provided timely limited or completely 147 through offline interactions. This may be due to higher security 148 requirements for operating the certification authority. The 149 authorization of a certification request based on an asset management 150 in this case will not / can not be performed on-site at enrollment 151 time. Enrollment, which cannot be performed in a (timely) consistent 152 fashion is considered as asynchronous enrollment in this document. 153 It requires the support of a store and forward functionality of 154 certification request together with the requester authentication 155 information. This enables processing of the request at a later point 156 in time. A similar situation may occur through network segmentation, 157 which is utilized in industrial systems to separate domains with 158 different security needs. Here, a similar requirement arises if the 159 communication channel carrying the requester authentication is 160 terminated before the RA/CA authorization handling of the 161 certification request. If a second communication channel is opened 162 to forward the certification request to the issuing RA/ CA, the 163 requester authentication information needs to be retained and ideally 164 bound to the certification request. This uses case is independent 165 from timely limitations of the first use case. For both cases, it is 166 assumed that the requester authentication information is utilized in 167 the process of authorization of a certification request. There are 168 different options to perform store and forward of certification 169 requests including the requester authentication information: 171 o Providing a trusted component (e.g., an LRA) in the deployment 172 domain, which stores the certification request combined with the 173 requester authentication information (based on the IDevID) and 174 potentially the information about a successful proof of possession 175 (of the corresponding private key) in a way prohibiting changes to 176 the combined information. Note that the assumption is that the 177 information elements may not be cryptographically bound together. 178 Once connectivity to the backend is available, the trusted 179 component forwards the certification request together with the 180 requester information (authentication and proof of possession) to 181 the off-site PKI for further processing. It is assumed that the 182 off-site PKI in this case relies on the local pledge 183 authentication result and thus performs the authorization and 184 issues the requested certificate. In BRSKI the trusted component 185 may be the EST server residing co-located with the registrar in 186 the deployment domain. 188 o Utilization of authenticated self-contained objects for the 189 enrollment, binding the certification request and the requester 190 authentication in a cryptographic way. This approach reduces the 191 necessary trust in a domain component to storage and delivery. 193 Unauthorized modifications of the requester information (request 194 and authentication) can be detected during the verification of the 195 authenticated self-contained object. An example for such an 196 object is a signed CMS wrapped object (as the voucher). 198 This targets environments, in which connectivity to a PKI is only 199 temporary or not directly available, by specifying support for 200 handling authenticated self-contained objects for enrollment. As it 201 is intended to enhance BRSKI it is named BRSKI-AE, where AE stands 202 for asynchronous enrollment. As BRSKI, BRSKI-AE results in the 203 pledge storing a X.509 root certificate sufficient for verifying the 204 domain registrar / proxy identity (LDevID CA Certificate) as well as 205 an domain specific X.509 device certificate (LDevID EE certificate). 207 Based on the proposed approach, a second set of scenarios can be 208 addressed, in which the pledge has no direct communication path to 209 the domain registrar, e.g., due to no network connectivity or a 210 different technology stack as the domain registrar, but is considered 211 to be managed by the domain registrar regarding the pledge domain 212 credentials. For this, an additional component is introduced acting 213 as an agent for the pledge towards the domain registrar, e.g., a 214 commissioning tool. In contrast to BRSKI here the credentials may be 215 pushed to the pledge instead of the pull approach taken by BRSKI. 217 The goal is to enhance BRSKI to either allow other existing 218 certificate management protocols supporting authenticated self- 219 contained objects to be applied or to allow other types of encoding 220 for the certificate management information exchange. This is 221 addressed by 223 o enhancing the well-known URI approach with additional path' for 224 the utilized enrollment protocol. 226 o defining a certificate waiting indication and handling, if the 227 certifying component is (temporarily) not available. 229 o allowing to utilize credentials different from the pledge's IDevID 230 to establish a connection to the domain registrar. 232 Note that in contrast to BRSKI, BRSKI-AE assumes support of multiple 233 enrollment protocols on the infrastructure side, allowing the pledge 234 manufacturer to select the most appropriate. Thus, BRSKI-AE can be 235 applied for both, asynchronous and synchronous enrollment. 237 2. Terminology 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 241 "OPTIONAL" in this document are to be interpreted as described in 242 [RFC2119]. 244 This document relies on the terminology defined in 245 [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are 246 defined additionally: 248 CA: Certification authority, issues certificates. 250 RA: Registration authority, an optional system component to which a 251 CA delegates certificate management functions such as 252 authorization checks. 254 LRA: Local registration authority, an optional RA system component 255 with proximity to end entities. 257 IED: Intelligent Electronic Device (in essence a pledge). 259 on-site: Describes a component or service or functionality available 260 in the target deployment domain. 262 off-site: Describes a component or service or functionality 263 available in an operator domain different from the target 264 deployment domain. This may be a central side, to which only a 265 temporarily connection is available, or which is in a different 266 administrative domain. 268 asynchronous communication: Describes a timely interrupted 269 communication between an end entity and a PKI component. 271 synchronous communication: Describes a timely uninterrupted 272 communication between an end entity and a PKI component. 274 authenticated self-contained object: Describes an object, which is 275 cryptographically bound to the IDevID EE credential of a pledge. 276 The binding is assumed to be provided through a digital signature 277 using the corresponding private key of the IDevID to wrap the 278 actual object. Note that depending on the availability of a 279 LDevID EE credential, the binding may also be achieved using 280 corresponding private key of the LDevID. This can be utilized in 281 for instance in the context of an initial certification request or 282 a certificate update. 284 3. Scope of solution 286 3.1. Supported environment 288 This solution is intended to be used in domains with limited support 289 of on-site PKI services and comprises use cases in which: 291 o there is no registration authority available in the deployment 292 domain. The connectivity to the backend RA may only be 293 temporarily available. A local store and forward device is used 294 for the communication with the backend services. 296 o authoritative actions of a LRA are limited and may not comprise 297 authorization of certification requests of pledges. Final 298 authorization is done at the RA residing in the backend operator 299 domain. 301 o the target deployment domain already uses a certificate management 302 approach that shall be reused to be consistent throughout the life 303 cycle. 305 In addition, the solution is intended to be applicable in domains in 306 which pledges have no direct connection to the domain registrar, but 307 are expected to be managed by the registrar. This can be motivated 308 by pledges featuring a different technology stack or by pledges 309 without an existing connection to the domain registrar during 310 onboarding. 312 3.2. Application Examples 314 The following examples are intended to motivate the support of 315 different enrollment approaches in general and asynchronous 316 enrollment specifically, by introducing industrial applications 317 cases, which could leverage BRSKI as such but also require support of 318 asynchronous operation as intended with BRSKI-AE. 320 3.2.1. Rolling stock 322 Rolling stock or railroad cars contain a variety of sensors, 323 actuators, and controller, which communicate within the railroad car 324 but also exchange information between railroad cars building a train 325 or with a backend. These devices are typically unaware of backend 326 connectivity. Managing certificates may be done during maintenance 327 cycles of the railroad car, but can already be prepared during 328 operation. The preparation may comprise the generation of 329 certification requests by the components, which are collected and 330 forwarded for processing once the railroad car is connected to the 331 operator backend. The authorization of the certification request is 332 then done based on the operator's asset/inventory information in the 333 backend. 335 3.2.2. Building automation 337 In building automation a use case can be described by a detached 338 building or the basement of a building equipped with sensor, 339 actuators, and controllers connected, but with only limited or no 340 connection to the centralized building management system. This 341 limited connectivity may be during the installation time but also 342 during operation time. During the installation in the basement, a 343 service technician collects the necessary information from the 344 basement network and provides them to the central building management 345 system, e.g., using a laptop or even a mobile phone to transport the 346 information. This information may comprise parameters and settings 347 required in the operational phase of the sensors/actuators, like a 348 certificate issued by the operator to authenticate against other 349 components and services. 351 The collected information may be provided by a domain registrar 352 already existing in the installation network. In this case 353 connectivity to the backend PKI may be facilitated by the service 354 technician's laptop. Contrary, the information can also be collected 355 from the pledges directly and provided to a domain registrar deployed 356 in the main network. In this cases connectivity to the domain 357 registrar may be facilitated by the service technician's laptop. 359 3.2.3. Substation automation 361 In substation automation a control center typically hosts PKI 362 services to issue certificates for Intelligent Electronic Devices 363 (IED)s in a substation. Communication between the substation and 364 control center is done through a proxy/gateway/DMZ, which terminates 365 protocol flows. Note that NERC CIP-005-5 [NERC-CIP-005-5] requires 366 inspection of protocols at the boundary of a security perimeter (the 367 substation in this case). In addition, security management in 368 substation automation assumes central support of different enrollment 369 protocols to facilitate the capabilities of IEDs from different 370 vendors. The IEC standard IEC62351-9 [IEC-62351-9] specifies the 371 mandatory support of two enrollment protocols, SCEP 372 [I-D.gutmann-scep] and EST [RFC7030] for the infrastructure side, 373 while the IED must only support one of the two. 375 3.2.4. Electric vehicle charging infrastructure 377 For the electric vehicle charging infrastructure protocols have been 378 defined for the interaction between the electric vehicle (EV) and the 379 charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as 380 between the charging point and the charging point operator (e.g. 381 OCPP [OCPP]). Depending on the authentication model, unilateral or 382 mutual authentication is required. In both cases the charging point 383 authenticates uses an X.509 certificate to authenticate in the 384 context of a TLS connection between the EV and the charging point. 385 The management of this certificate depends (beyond others) on the 386 selected backend connectivity protocol. Specifically, in case of 387 OCPP it is intended as single communication protocol between the 388 charging point and the backend carrying all information to control 389 the charging operations and maintain the charging point itself. This 390 means that the certificate management is intended to be handled in- 391 band of OCPP. This requires to be able to encapsulate the 392 certificate management exchanges in a transport independent way. 393 Authenticated self-containment will ease this by allowing the 394 transport without a separate communication protocol. For the purpose 395 of certificate management CMP [RFC4210] is intended to be used. 397 3.2.5. Infrastructure isolation policy 399 This refers to any case in which network infrastructure is normally 400 isolated from the Internet as a matter of policy, most likely for 401 security reasons. In such a case, limited access to external PKI 402 resources will be allowed in carefully controlled short periods of 403 time, for example when a batch of new devices are deployed, but 404 impossible at other times. 406 3.2.6. Less operational security in the deployment domain 408 The registration point performing the authorization of a certificate 409 request is a critical PKI component and therefore implicates higher 410 operational security than other components utilizing the issued 411 certificates for their security features. CAs may also demand higher 412 security in the registration procedures. Especially the CA/Browser 413 forum currently increases the security requirements in the 414 certificate issuance procedures for publicly trusted certificates. 415 There may be the situation that the deployment domain does not offer 416 enough security to operate a registration point and therefore wants 417 to transfer this service to a backend. 419 4. Requirement discussion and mapping to solution elements 421 For the requirements discussion it is assumed that the domain 422 registrar receiving a certification request as authenticated self- 423 contained object is not the authorization point for this 424 certification request. If the domain registrar is the authorization 425 point, BRSKI can be used directly. Note that BRSKI-AE could also be 426 used in this case. 428 Based on the intended deployment environment described in Section 3.1 429 and the motivated application examples described in Section 3.2 the 430 following base requirements are derived to support authenticated 431 self-contained objects as container carrying the certification 432 request and further information to support asynchronous operation. 434 At least the following properties are required: 436 o Proof of Possession: utilizing the private key corresponding to 437 the public key contained in the certification request. 439 o Proof of Identity: utilizing an existing IDevID credential bound 440 to the certification request. Certificate updates may utilize the 441 LDevID credential. 443 Solution examples (not complete) based on existing technology are 444 provided with the focus on existing IETF documents: 446 o Certification request objects: Certification requests are 447 structures protecting only the integrity of the contained data 448 providing a proof-of-private-key-possession for locally generated 449 key pairs. Examples for certification requests are: 451 * PKCS#10 [RFC2986]: Defines a structure for a certification 452 request. The structure is signed to ensure integrity 453 protection and proof of possession of the private key of the 454 requester that corresponds to the contained public key. 456 * CRMF [RFC4211]: Defines a structure for the certification 457 request message. The structure supports integrity protection 458 and proof of possession, through a signature generated over 459 parts of the structure by using the private key corresponding 460 to the contained public key. 462 Note that the integrity of the certification request is bound to 463 the public key contained in the certification request by 464 performing the signature operation with the corresponding private 465 key. In the considered application examples, this is not 466 sufficient and needs to be bound to the existing credential of the 467 pledge (IDevID) additionally. This binding supports the 468 authorization decision for the certification request through the 469 provisioning of a proof of identity. The binding of data origin 470 authentication to the certification request may be delegated to 471 the protocol used for certificate management. 473 o Proof of Identity options: The certification request should be 474 bound to an existing credential (here IDevID) to enable a proof of 475 identity and based on it an the authorization of the certification 476 request. The binding may be realized through a security options 477 in an underlying transport protocol if the authorization of the 478 the certification request is done at the next communication hop. 479 Alternatively, this binding can be done by a wrapping signature 480 employing an existing credential (initial: IDevID, renewal: 481 LDevID). This requirement is addressed by existing enrollment 482 protocols in different ways, for instance: 484 * EST [RFC7030]: Utilizes PKCS#10 to encode the certification 485 request. The Certificate Signing Request (CSR) may contain a 486 binding to the underlying TLS by including the tls-unique value 487 in the self-signed CSR structure. The tls-unique value is one 488 result of the TLS handshake. As the TLS handshake is performed 489 mutually authenticated and the pledge utilized its IDevID for 490 it, the proof of identity can be provided by the binding to the 491 TLS session. This is supported in EST using simpleenroll. To 492 avoid the binding to the underlying authentication in the 493 transport layer EST offers the support of a wrapping the CSR 494 with an existing certificate by using fullcmc. 496 * SCEP [I-D.gutmann-scep]: Provides the option to utilize either 497 an existing secret (password) or an existing certificate to 498 protect the CSR based on SCEP Secure Message Objects using CMS 499 wrapping ([RFC5652]). Note that the wrapping using an existing 500 IDevID credential in SCEP is referred to as renewal. SCEP 501 therefore does not rely on the security of an underlying 502 transport. 504 * CMP [RFC4210] Provides the option to utilize either an existing 505 secret (password) or an existing certificate to protect the 506 PKIMessage containing the certification request. The 507 certification request is encoded utilizing CRMF. PKCS#10 is 508 optionally supported. The proof of identity of the PKIMessage 509 containing the certification request can be achieved by using 510 IDevID credentials to calculate a signature over the header and 511 the body of the PKIMessage utilizing the protectionAlg signaled 512 in the PKIMessage header and the PKIProtection carrying the 513 actual signature value. CMP therefore does not rely on the 514 security of an underlying transport. 516 * CMC [RFC5272] Provides the option to utilize either an existing 517 secret (password) or an existing certificate to protect the 518 certification request (either in CRMF or PKCS#10) based on CMS 519 [RFC5652]). Here a FullCMCRequest can be used, which allows 520 signing with an existing IDevID credential to provide a proof 521 of identity. CMC therefore does not rely on the security of an 522 underlying transport. 524 Note that besides the already existing enrollment protocols there 525 ongoing work in the ACE WG to define an encapsulation of EST in 526 OSCORE to result in a TLS independent way of protecting EST. This 527 approach [I-D.selander-ace-coap-est-oscore] may be considered as 528 further variant. 530 5. Architectural Overview and Communication Exchanges 532 To support asynchronous enrollment, the base system architecture 533 defined in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] is enhanced 534 to facilitate the two target use cases. 536 o Use case 1 (PULL case): the pledge requests certificates from a 537 PKI operated off-site via the domain registrar. 539 o Use case 2 (PUSH/PULL case): allows delayed (delegated) onboarding 540 using a pledge-agent instead a direct connection to the domain 541 registrar. The communication model between pledge-agent and 542 pledge depends on the specified interface and may use a PULL or 543 PUSH approach. This interaction in terms of a protocol 544 specification is out of scope of this document. 546 Note that the terminology PUSH and PULL relates to the pledge 547 behavior. In PULL the pledge requests data objects as in BRSKI, 548 while in the PUSH case the pledge may be provisioned with the 549 necessary data objects. The pledge-agent as it represents the pledge 550 always acts in a PULL mode to the domain registrar. Both use cases 551 are described in the next subsections. They utilize the existing 552 BRSKI architecture elements as much as possible. Necessary 553 enhancements to support authenticated self-contained objects for 554 certificate enrollment are kept on a minimum to ensure reuse of 555 already defined architecture elements and interactions. 557 For the authenticated self-contained objects used for the 558 certification request, BRSKI-AE relies on the defined message 559 wrapping mechanisms of the enrollment protocols stated in Section 4 560 above. 562 5.1. Use Case 1: Support of off-site PKI service 564 One assumption of BRSKI-AE is that the authorization of a 565 certification request is performed based on an authenticated self- 566 contained object, binding the certification request to the 567 authentication using the IDevID. This supports interaction with off- 568 site or off-line PKI (RA/CA) components. In addition, the 569 authorization of the certification request may not be done by the 570 domain registrar but by a PKI residing in the backend of the domain 571 operator (off-site) as described in Section 3.1. This leads to 572 changes in the placement or enhancements of the logical elements as 573 shown in Figure 1. 575 +------------------------+ 576 +--------------Drop Ship--------------->| Vendor Service | 577 | +------------------------+ 578 | | M anufacturer| | 579 | | A uthorized |Ownership| 580 | | S igning |Tracker | 581 | | A uthority | | 582 | +--------------+---------+ 583 | ^ 584 | | 585 V | 586 +--------+ ......................................... | 587 | | . . | BRSKI- 588 | | . +------------+ +------------+ . | MASA 589 | Pledge | . | Join | | Domain <-----+ 590 | | . | Proxy | | Registrar/ | . 591 | <-------->............<-------> Enrollment | . 592 | | . | BRSKI-AE | Proxy | . 593 | IDevID | . | | +------^-----+ . 594 | | . +------------+ | . 595 | | . | . 596 +--------+ ...............................|......... 597 "on-site domain" components | 598 |e.g., RFC 7030, 599 | RFC 4210, ... 600 .............................................|..................... 601 . +---------------------------+ +--------v------------------+ . 602 . | Public Key Infrastructure |<----+ PKI RA | . 603 . | PKI CA |---->+ | . 604 . +---------------------------+ +---------------------------+ . 605 ................................................................... 606 "off-site domain" components 608 Figure 1: Architecture overview using off-site PKI components 610 The architecture overview in Figure 1 utilizes the same logical 611 elements as BRSKI but with a different placement in the deployment 612 architecture for some of the elements. The main difference is the 613 placement of the PKI RA/CA component, which is performing the 614 authorization decision for the certification request message. It is 615 placed in the off-site domain of the operator (not the deployment 616 site directly), which may have no or only temporary connectivity to 617 the deployment or on-site domain of the pledge. This is to underline 618 the authorization decision for the certification request in the 619 backend rather than on-site. The following list describes the 620 components in the deployment domain: 622 o Join Proxy: same functionality as described in BRSKI. 624 o Domain Registrar / Enrollment Proxy: In general the domain 625 registrar proxy has a similar functionality regarding the 626 imprinting of the pledge in the deployment domain to facilitate 627 the communication of the pledge with the MASA and the PKI. 628 Different is the authorization of the certification request. 629 BRSKI-AE allows to perform this in the operators backend (off- 630 site), and not directly at the domain registrar. 632 * Voucher exchange: The voucher exchange with the MASA via the 633 domain registrar is performed as described in BRSKI 634 [I-D.ietf-anima-bootstrapping-keyinfra] . 636 * Certificate enrollment: For the pledge enrollment the domain 637 registrar in the deployment domain supports the adoption of the 638 pledge in the domain based on the voucher request. 639 Nevertheless, it may not have sufficient information for 640 authorizing the certification request. If the authorization is 641 done in the off-site domain, the domain registrar forwards the 642 certification request to the RA to perform the authorization. 643 The domain registrar in this acts as an enrollment proxy or 644 local registration authority. It is also able to handle the 645 case having temporarily no connection to an off-site PKI by 646 storing the certification request and forwarding it to the RA 647 upon regaining connectivity. As authenticated self-contained 648 objects are used, it requires an enhancement of the domain 649 registrar. This is done by supporting alternative enrollment 650 approaches (protocol options, protocols, encoding) by enhancing 651 the addressing scheme to communicate with the domain registrar 652 (see Section 5.1.5) and also by providing a discover scheme to 653 allow the pledge to enumerate the supported enrollment options 654 (see Section 5.3). 656 The following list describes the vendor related components/service 657 outside the deployment domain: 659 o MASA: general functionality as described in BRSKI. Assumption 660 that the interaction with the MASA may be synchronous (voucher 661 request with nonce) or asynchronous (voucher request without 662 nonce). 664 o Ownership tracker: as defined in BRSKI. 666 The following list describes the operator related components/service 667 operated in the backend: 669 o PKI RA: Performs certificate management functions (validation of 670 certification requests, interaction with inventory/asset 671 management for authorization of certification requests, etc.) for 672 issuing, updating, and revoking certificates for a domain as a 673 centralized infrastructure for the domain operator. The inventory 674 (asset) management may be a separate component or integrated into 675 the RA directly. 677 o PKI CA: Performs certificate generation by signing the certificate 678 structure provided in the certification request. 680 Based on BRSKI and the architectural changes the original protocol 681 flow is divided into three phases showing commonalities and 682 differences to the original approach as depicted in the following. 684 o Discovery phase (same as BRSKI) 686 o Voucher exchange with deployment domain registrar (same as BRSKI). 688 o Enrollment phase (changed to accompany the application of 689 authenticated self-contained objects). 691 5.1.1. Behavior of a pledge 693 The behavior of a pledge as described in 694 [I-D.ietf-anima-bootstrapping-keyinfra] is kept with one exception. 695 After finishing the imprinting phase (4) the enrollment phase (5) is 696 performed with a method supporting authenticated self-contained 697 objects. Using EST with simpleenroll cannot be applied here, as it 698 binds the pledge authentication with the existing IDevID to the 699 transport channel (TLS) rather than to the certification request 700 object directly. This authentication in the transport layer is not 701 visible / verifiable at the authorization point in the off-site 702 domain. Section 6 discusses potential enrollment protocols and 703 options applicable. 705 5.1.2. Pledge - Registrar discovery and voucher exchange 707 The discovery phase is applied as specified in 708 [I-D.ietf-anima-bootstrapping-keyinfra]. 710 5.1.3. Registrar - MASA voucher exchange 712 The voucher exchange is performed as specified in 713 [I-D.ietf-anima-bootstrapping-keyinfra]. 715 5.1.4. Pledge - Registrar - RA/CA certificate enrollment 717 As stated in Section 4 the enrollment shall be performed using an 718 authenticated self-contained object providing: 720 o Proof of Possession: utilizing the private key corresponding to 721 the public key contained in the certification request. 723 o Proof of Identity: utilizing the existing IDevID credential to 724 generate a signature of the initial certification request. 725 Certificate updates may utilize the LDevID credential. 727 +--------+ +---------+ +------------+ +------------+ 728 | Pledge | | Circuit | | Domain | | Operator | 729 | | | Join | | Registrar | | RA/CA | 730 | | | Proxy | | (JRC) | | (OPKI) | 731 +--------+ +---------+ +------------+ +------------+ 732 /--> | | 733 [Request of CA Certificates] | | 734 |---------- CA Certs Request ------------>| | 735 | [if connection to operator domain is available] | 736 | |-Request CA Certs ->| 737 | |<- CA Certs Response| 738 |<-------- CA Certs Response--------------| | 739 /--> | | 740 [Request of Certificate Attributes to be included] | 741 |---------- Attribute Request ----------->| | 742 | [if connection to operator domain is available] | 743 | |Attribute Request ->| 744 | |<-Attribute Response| 745 |<--------- Attribute Response -----------| | 746 /--> | | 747 [Certification request] | | 748 |-------------- Cert Request ------------>| | 749 | [if connection to operator domain is available] | 750 | |--- Cert Request -->| 751 | |<-- Cert Response --| 752 [Optional Certification waiting indication] | | 753 /--> | | 754 |<---------- Cert Waiting ----------------| | 755 |-- Cert Polling (with orig request ID) ->| | 756 | [if connection to operator domain is available] | 757 | |--- Cert Request -->| 758 | |<-- Cert Response --| 759 /--> | | 760 |<------------- Cert Response ------------| | 761 /--> | | 762 [Certification confirmation] | | 763 |-------------- Cert Confirm ------------>| | 764 | /--> | 765 | |[optional] | 766 | |--- Cert Confirm -->| 767 | |<-- PKI Confirm ----| 768 |<------------- PKI/Registrar Confirm ----| | 770 Figure 2: Certificate enrollment 772 The following list provides an abstract description of the flow 773 depicted in Figure 2. 775 o CA Cert Request: The pledge SHOULD request the full distribution 776 of CA Certificates. This ensures that the pledge has the complete 777 set of current CA certificates beyond the pinned-domain-cert. 779 o CA Cert Response: Contains at least one CA certificate of the 780 issuing CA. 782 o Attribute Request: Typically, the automated bootstrapping occurs 783 without local administrative configuration of the pledge. 784 Nevertheless, there are cases, in which the pledge may also 785 include additional attributes specific to the deployment domain 786 into the certification request. To get these attributes in 787 advance, the attribute request SHOULD be used. 789 o Attribute Response: Contains the attributes to be included in the 790 certification request message. 792 o Cert Request: Depending on the utilized enrollment protocol, this 793 certification request contains the authenticated self-contained 794 object ensuring both, proof-of-possession of the corresponding 795 private key and proof-of-identity of the requester. 797 o Cert Response: certification response message containing the 798 requested certificate and potentially further information like 799 certificates of intermediary CAs on the certification path. 801 o Cert Waiting: waiting indication for the pledge to retry after a 802 given time. For this a request identifier is necessary. This 803 request identifier may bei either part of the enrollment protocol 804 or build based on the certification request. 806 o Cert Polling: querying the registrar, if the certificate request 807 was already processed; can be answered either with another Cert 808 Waiting, or a Cert Response. 810 o Cert Confirm: confirmation message from pledge after receiving and 811 verifying the certificate. 813 o PKI/Registrar Confirm: confirmation message from PKI/registrar 814 about reception of the pledge's certificate confirmation. 816 [RFC Editor: please delete] /* 818 Open Issues: 820 o Description of certificate waiting and retries. 822 o Message exchange description is expected to be done by the 823 utilized enrollment protocol based on the addressing scheme (see 824 also Section 6. 826 o Handling of certificate/PKI confirmation message between pledge 827 and domain registrar and PKI (treated optional?). 829 */ 831 5.1.5. Addressing Scheme Enhancements 833 BRSKI-AE requires enhancements to the addressing scheme defined in 834 [I-D.ietf-anima-bootstrapping-keyinfra] to accommodate the additional 835 handling of authenticated self-contained objects for the 836 certification request. As this is supported by different enrollment 837 protocols, they can be directly employed (see also Section 6). For 838 the support of different enrollment options at the domain registrar, 839 the addressing approach of BRSKI using a "/.well-known" tree from 840 [RFC5785] is enhanced. 842 The current addressing scheme in BRSKI for the client certificate 843 request function during the enrollment is using the definition from 844 EST [RFC7030], here on the example on simple enroll: "/.well- 845 known/est/simpleenroll" This approach is generalized to the following 846 notation: "/.well-known/enrollment-protocol/request" in which 847 enrollment-protocol may be an already existing protocol or a newly 848 defined approach. Note that enrollment is considered here as a 849 sequence of at least a certification request and a certification 850 response. In case of existing enrollment protocols the following 851 notation is used proving compatibility to BRSKI: 853 o enrollment-protocol: references either EST [RFC7030] as in BRSKI 854 or CMP, CMC, SCEP, or newly defined approaches as alternatives. 855 Note: the IANA registration of the well-known URI is expected to 856 be done by the enrollment protocol. For CMP a lightweight profile 857 is defined, which provides the definition of the well-known URI in 858 Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. 860 o request: depending on the utilized enrollment protocol, the 861 request describes the required operation at the registrar side. 862 Enrollment protocols are expected to define the request endpoints 863 as done by existing protocols (see also Section 6). 865 5.2. Use Case 2: pledge-agent 867 To support mutual trust establishment of pledges, not directly 868 connected to the domain registrar, a similar approach is applied as 869 discussed for the use case 1. It relies on the exchange of 870 authenticated self-contained objects (the voucher request/response 871 objects as known from BRSKI and the certification request/response 872 objects as introduced by BRSKI-AE). This allows independence from 873 the protection provided by the underlying transport. 875 In contrast to BRSKI, the exchange of these objects is performed with 876 the help of a pledge-agent, supporting the interaction of the pledge 877 with the domain registrar. It may be an integrated functionality of 878 a commissioning tool. This leads to enhancements of the logical 879 elements in the BRSKI architecture as shown in Figure 3. The pledge- 880 agent provides an interface to the pledge to enable creation or 881 consumption of required data objects, which are exchanged with the 882 domain registrar. Moreover, the addition of the pledge-agent also 883 influences the sequences for the data exchange between the pledge and 884 the domain registrar described in 885 [I-D.ietf-anima-bootstrapping-keyinfra]. The general goal for the 886 pledge-agent application is the reuse of already defined endpoints on 887 the domain registrar side. The behavior of the endpoint may need to 888 be adapted. 890 +------------------------+ 891 +--------------Drop Ship---------------| Vendor Service | 892 | +------------------------+ 893 | | M anufacturer| | 894 | | A uthorized |Ownership| 895 | | S igning |Tracker | 896 | | A uthority | | 897 | +--------------+---------+ 898 | ^ 899 | | BRSKI- 900 V | MASA 901 +-------+ +-------+ .............................|......... 902 | | | | . | . 903 | | | | . +-----------+ +-----v-----+ . 904 | | |Pledge | . | | | | . 905 |Pledge | | Agent | . | Join | | Domain | . 906 | | | | . | Proxy | | Registrar | . 907 | <----->.......<-------->...........<-------> (PKI RA) | . 908 | | | | . | BRSKI-AE | | . 909 | | | | . | | +-----+-----+ . 910 |IDevID | |opt. | . +-----------+ | . 911 | | |IDevID | . +------------------+-----+ . 912 | | |or | . | Key Infrastructure | . 913 | | |LDevID | . | (e.g., PKI Certificate | . 914 +-------+ +-------+ . | Authority) | . 915 . +------------------------+ . 916 ....................................... 917 "Domain" components 919 Figure 3: Architecture overview using a pledge-agent 921 The architecture overview in Figure 3 utilizes the same logical 922 elements as BRSKI with the addition of the pledge-agent. The pledge- 923 agent, may originate from the pledge manufacturer and may have either 924 an own IDevID credential issued by the manufacturer or an LDevID 925 issued already by the deployment (on-site) domain. 927 For authentication towards the domain registrar, the pledge-agent may 928 use the IDevID or LDevID credentials, which are verified by the 929 domain registrar as part of the TLS establishment. The provisioning 930 of this credential to the pledge-agent is out of scope for this 931 specification. Alternatively, the domain registrar may authenticate 932 the user operating the pledge-agent to perform authorization of 933 pledge onboarding. Examples for such a user level authentication are 934 the application of HTTP authentication or the usage of SAML tokens or 935 the application of a user related certificates in the TLS handshake 936 or other. If the pledge-agent utilizes a certificate, the domain 937 registrar must be able to verify the certificate by possessing the 938 corresponding root certificate. 940 The following list describes the components in the deployment domain: 942 o Pledge: The pledge is expected to communicate with the pledge- 943 agent for providing the necessary data objects for onboarding. 944 The exact protocol used between the pledge and the pledge-agent is 945 out of scope for this document but may consider: If the pledge is 946 triggered/PUSHED by the pledge-agent, it becomes a callee. There 947 are some differences to BRSKI: 949 * Discovery of the domain registrar will be omitted as the pledge 950 is expected to be triggered by the pledge-agent. 952 * The pledge-agent is expected to provide an option to trigger 953 the onboarding by pushing data objects to the pledge. 955 * Order of exchanges in the call flow is different as the pledge- 956 agent collects both voucher request objects and certification 957 request objects at once. 959 * The data objects utilized are the same objects already applied 960 in use case 1 Section 5.1. 962 o Pledge-Agent: provides a communication path to exchange data 963 objects between the pledge and the domain registrar. The pledge- 964 agent facilitates situations, in which the domain registrar is not 965 directly reachable by the pledge, either due to a different 966 technology stack or due to missing connectivity (e.g., if the 967 domain registrar resides in the cloud and the pledge has no 968 connectivity, yet). The pledge-agent in this cases can easily 969 collect voucher request objects and certification request objects 970 from one or multiple pledges at once and perform a bulk onboarding 971 based on the collected data. The pledge-agent may be configured 972 with the domain registrar information or may use the discovery 973 mechanism. 975 o Join Proxy: same functionality as described in BRSKI. 977 o Domain Registrar: In general the domain registrar fulfills the 978 same functionality regarding the onboarding of the pledge in the 979 deployment domain by facilitating the communication of the pledge 980 with the MASA and the PKI. In contrast to BRSKI, the domain 981 registrar does not interact with a pledge directly but through the 982 pledge-agent. This prohibits a pledge authentication using its 983 IDevID during TLS establishment towards the registrar. If the 984 pledge-agent has an IDevID or is already possessing a LDevID valid 985 in the deployment domain, it is expected to use this 986 authentication towards the domain registrar. 988 The manufacturer provided components/services (MASA and Ownership 989 tracker) are used as defined in BRSKI. 991 5.2.1. Behavior of a pledge 993 The behavior of a pledge as described for use case 1 Section 5.1 is 994 basically kept regarding the generation of voucher request/response 995 objects and certificate request/response objects. Due to the use of 996 the pledge-agent, the interaction with the domain registrar is 997 changed as shown in Figure 4. 999 The interaction of the pledge with the pledge-agent in terms of 1000 utilized protocols or discovery options is out of scope of this 1001 document. This document concentrates on the exchanged data objects 1002 between the pledge and the domain registrar via the pledge-agent. 1004 The pledge-agent should be able to authenticate the pledge-agent 1005 either based on security mechanisms as part of the communication 1006 channel between the pledge and the pledge-agent or based on the data 1007 (request) objects. 1009 The pledge-agent should provide the proximity-registrar-cert to the 1010 pledge to enable embedding in the voucher request object. The 1011 registrar certificate may be configured at the pledge-agent or may be 1012 fetched by the pledge-agent based on the TLS connection establishment 1013 with the domain registrar. 1015 The pledge interacts with the pledge-agent, to generate a voucher 1016 request object (VouReq) and a certification request object (CR), 1017 which are provided to the domain registrar through the pledge-agent. 1019 The pledge shall generate the voucher request object as described in 1020 [I-D.ietf-anima-bootstrapping-keyinfra] and provide this information 1021 to the pledge-agent. 1023 After the voucher request exchange the pledge will be triggered by to 1024 generate a certification request object. For this, the pledge-agent 1025 may have been pre-configured with the certification request 1026 attributes, that it may provide to the pledge. The certification 1027 request is generated as authenticated self-signed object, which 1028 assures proof of possession of the private key corresponding to the 1029 contained public key in the certification request as well as a proof 1030 of identity, based on the IDevID of the pledge. This is done as 1031 described for use case 1 Section 5.1. 1033 5.2.2. Behavior of a pledge-agent 1035 The pledge-agent is a new component in the BRSKI context. It 1036 provides connectivity between the pledge and the domain registrar and 1037 utilizes the endpoints already specified in 1038 [I-D.ietf-anima-bootstrapping-keyinfra]. The pledge-agent is 1039 expected to interact with the pledge independent of the domain 1040 registrar. As stated before, data exchange is only defined based on 1041 the data objects, which are the voucher request/response objects and 1042 the certification request/response objects. The transport mechanism 1043 is out of scope here. This changes the general interaction as shown 1044 in Figure 4. 1046 The pledge-agent may have an own IDevID or a deployment domain issued 1047 LDevID to be utilized in the TLS communication establishment towards 1048 the domain registrar. Note that the pledge-agent may also be used 1049 without client side authentication if no suitable credential is 1050 available on transport layer. As BRSKI-AE utilizes authenticated 1051 self-contained data objects, which bind the pledge authentication 1052 (proof of identity) directly to the objects (voucher request and 1053 certification request), the TLS client authentication may be 1054 neglected. This is a deviation from the BRSKI approach in which the 1055 pledge's IDevID credential is used to perform TLS client 1056 authentication. According to [I-D.ietf-anima-bootstrapping-keyinfra] 1057 section 5.3, the domain registrar performs the pledge authorization 1058 for onboarding within his domain based on the provided voucher 1059 request. 1061 5.2.3. Registrar discovery 1063 The discovery phase may be applied as specified in 1064 [I-D.ietf-anima-bootstrapping-keyinfra] with the deviation that it is 1065 done between the pledge-agent and the domain registrar. 1066 Alternatively, the domain registrar may be configured in the pledge- 1067 agent. 1069 The discovery of the pledge-agent by the pledge belongs to the 1070 communication between the two instances and is out of scope for this 1071 specification. 1073 5.2.4. Handling voucher request and certification requests 1075 The BRSKI-AE exchange of voucher requests and certification requests 1076 utilizes authenticated self-contained objects independent of 1077 transport protection. 1079 +--------+ +-------+ +-----------+ +--------+ +---------+ 1080 | Pledge | | Pledge| | Domain | | Domain | | Vendor | 1081 | | | Agent | | Registrar | | CA | | Service | 1082 | | | | | (JRC) | | | | (MASA) | 1083 +--------+ +-------+ +-----------+ +--------+ +---------+ 1084 | | | | Internet | 1085 | opt: configure | | | 1086 | - proximity-registrar-cert | | | 1087 | - CSR attributes | | | 1088 | | | | | 1089 [example: trigger voucher and certification request generation ] | 1090 | | | | | 1091 |<--trigger VouReq--| | | | 1092 |(o: proximity-cert)| | | | 1093 |- Voucher Request->| | | | 1094 | | | | | 1095 |<--trigger CR------| | | | 1096 |(o: attributes) | | | | 1097 |----Cert Request-->| | | | 1098 | |<---- TLS --->| | | 1099 | | | | | 1100 [Start known BRSKI interaction ] | | | 1101 | | | | | 1102 | |--- VouReq -->| | | 1103 | | [accept device?] | | 1104 | | [contact vendor] | | 1105 | | |----- Voucher Request ------>| 1106 | | |----- Pledge ID ------------>| 1107 | | |----- Domain ID ------------>| 1108 | | |----- optional: nonce ------>| 1109 | | | [extract DomainID] 1110 | | | [update audit log] 1111 | | |<--------- Voucher ---------| 1112 | |<-- Voucher --| | | 1113 | | |<----- device audit log ----| 1114 | | | | | 1115 [optional retrieve CA certs] | | | 1116 | |- CACertReq ->| | | 1117 | | |- CACertReq -->| | 1118 | | |<-CACertResp --| | 1119 | |< CACertResp -| | | 1120 | | | | | 1121 [certification request] | | | 1122 | |-- CertReq -->| | | 1123 | | |-- CertReq --->| | 1124 | | |<--CertResp----| | 1125 | |<-- CertResp -| | | 1126 | | | | | 1127 [Stop known BRSKI interaction ] | | | 1128 | | | | | 1130 [push voucher and certificate to pledge, optionally push CA certs] | 1131 | | | | | 1132 |<---post Voucher---| | | | 1133 |- Voucher Status-->| | | | 1134 | | | | | 1135 |<---post CACerts---| | | | 1136 |- CACerts Status-->| | | | 1137 | | | | | 1138 | | | | | 1139 |<--post CertResp---| | | | 1140 |---- CertConf ---->| | | | 1141 | | | | | 1142 | [voucher status telemetry ] | | 1143 | |VoucherStatus>| | | 1144 | |[verify audit log and voucher]| | 1145 | | | | | 1146 | | [enroll Status] | | 1147 | |-- CertConf ->| | | 1148 | | |-- CertConf -->| | 1149 | | | | | 1151 Figure 4: Request handling of the pledge using a pledge-agent 1153 As shown in Figure 4 the pledge-agent collects the voucher request 1154 and certification request objects from a pledge. As the pledge-agent 1155 (e.g., as part of a commissioning tool) is intended to work between 1156 the pledge and the domain registrar, a collection of requests from 1157 multiple pledges is possible, allowing a bulk onboarding of multiple 1158 pledges using the connection between the pledge-agent and the domain 1159 registrar. 1161 The information exchange between the pledge-agent and the domain 1162 registrar resembles the exchanges between the pledge and the domain 1163 registrar from BRSKI with one exception. As authenticated self- 1164 contained objects are used consequently, the authentication of the 1165 pledge-agent to the domain registrar may be neglected. Note that 1166 this allows to employ simple applications as pledge-agent. The 1167 authentication of the pledge-agent is recommended if it is desired to 1168 perform the onboarding with an authorized pledge-agent or to support 1169 advanced auditing in case a user based authentication is done. As 1170 stated above, the authentication may be realized by device (IDevID or 1171 LDevID) or user related credentials in the context of the TLS 1172 handshake, HTTP based authentication, SAML tokens or other. 1174 [RFC Editor: please delete] /* to be discussed: Description on how 1175 the registrar makes the decision if he is connected with pledge 1176 directly or with a pledge-agent. This may result in a case statement 1177 (client side authentication in TLS, user authentication above TLS, 1178 etc.) for the TLS connection establishment in the original BRSKI 1179 document in section 5.1 */ 1181 Once the pledge-agent has finished the exchanges with the domain 1182 registrar to get the voucher and the certificate object, it can close 1183 the TLS connection to the domain registrar and provide the objects to 1184 the pledge(s). The transport of the objects to the pledge is out of 1185 scope. The content of the response objects is defined through the 1186 voucher [RFC8366] and the certificate [RFC5280]. 1188 5.3. Discovery of supported enrollment options at domain registrar 1190 Well-know URIs for different endpoints on the domain registrar are 1191 already defined as part of the base BRSKI specification. In 1192 addition, this document utilizes well-known URIs to allow for 1193 alternative enrollment options at the domain registrar. The 1194 discovery of supported endpoints will therefore provide the 1195 information to the pledge, how to contact the domain registrar. 1197 Querying the registrar, the pledge will get a list of potential 1198 endpoints supported by the domain registrar. To allow for a BRSKI 1199 specific discovery of endpoints/resources, this document specifies a 1200 new URI for the discovery as "/.well-known/brski". 1202 Performing a GET on "/.well-known/brski" to the default port returns 1203 a set of links to endpoints available from the server. In addition 1204 to the link also the expected format of the data object is provided 1205 as content type (ct). 1207 The following provides an illustrative example for a domain registrar 1208 supporting different options for EST as well as CMP to be used in 1209 BRSKI-AE. The listing contains the supported endpoints for the 1210 onboarding: 1212 REQ: GET /.well-known/brski 1213 RES: Content 1214 ,ct=voucher-cms+json 1215 ,ct=json 1216 ,ct=json 1217 ,ct=json 1218 ;ct=pkcs7-mime 1219 ;ct=pkcs7-mime 1220 ;ct=pkcs7-mime 1221 ;ct=pkcs7-mime 1222 ;ct=pkcs7-mime 1223 ;ct= pkcs7-mime 1224 ;ct=pkcs7-mime 1225 ;ct=pkixcmp 1226 ;ct=pkixcmp 1227 ;ct=pkixcmp 1228 ;ct=pkixcmp 1229 ;ct=pkixcmp 1230 ;ct=pkixcmp 1232 [RFC Editor: please delete] /* 1234 Open Issues: 1236 o Change path from /est to /brski to be protocol agnostic 1238 o Define new well-know URI as above or reuse core approach as 1239 described in RFC 6690 with /.well-known/core and the already 1240 defined functionality? 1242 o In addition to the current content types, we may specify that the 1243 response provide information about different content types as 1244 multiple values. This would allow to further adopt the encoding 1245 of the objects exchanges (ASN.1, JSON, CBOR, ...). 1247 */ 1249 6. Example mappings to existing enrollment protocols 1251 This sections maps the requirements to support proof of possession 1252 and proof of identity to selected existing enrollment protocols. 1253 Note that that the work in the ACE WG described in 1254 [I-D.selander-ace-coap-est-oscore] may be considered here as well, as 1255 it also addresses the encapsulation of EST in a way to make it 1256 independent from the underlying TLS using OSCORE resulting in an 1257 authenticated self-contained object. 1259 6.1. EST Handling 1261 When using EST [RFC7030], the following constrains should be 1262 considered: 1264 o Proof of possession is provided by using the specified PKCS#10 1265 structure in the request. 1267 o Proof of identity is achieved by signing the certification request 1268 object, which is only supported when the /fullcmc endpoint is 1269 used. This contains sufficient information for the RA to make an 1270 authorization decision on the received certification request. 1271 Note: EST references CMC [RFC5272] for the definition of the Full 1272 PKI Request. For proof of identity, the signature of the 1273 SignedData of the Full PKI Request would be calculated using the 1274 IDevID credential of the pledge. 1276 o [RFC Editor: please delete] /* TBD: in this case the binding to 1277 the underlying TLS connection is not be necessary. */ 1279 o When the RA is not available, as per [RFC7030] Section 4.2.3, a 1280 202 return code should be returned by the Registrar. The pledge 1281 in this case would retry a simpleenroll with a PKCS#10 request. 1282 Note that if the TLS connection is teared down for the waiting 1283 time, the PKCS#10 request would need to be rebuild if it contains 1284 the unique identifier (tls_unique) from the underlying TLS 1285 connection for the binding. 1287 o [RFC Editor: please delete] /* TBD: clarification of retry for 1288 fullcmc is necessary as not specified in the context of EST */ 1290 6.2. Lightweight CMP Handling 1292 Instead of using CMP [RFC4210], this specification refers to the 1293 lightweight CMP profile [I-D.ietf-lamps-lightweight-cmp-profile], as 1294 it restricts the full featured CMP to the functionality needed here. 1295 For this, the following constrains should be observed: 1297 o For proof of possession, the defined approach in Lightweight CMP 1298 section 5.1.1 (based on CRMF) and 5.1.5 based on PCKS#10 should be 1299 supported. 1301 o Proof of identity can be provided by using the signatures to 1302 protect the certificate request message as outlined in section 1303 4.2. 1305 o When the RA/CA is not available, a waiting indication should be 1306 returned in the PKIStatus by the Registrar. The pledge in this 1307 case would retry using the PollReqContent with a request 1308 identifier certReqId provided in the initial CertRequest message 1309 as specified in section 6.1.4 with delayed enrollemnt. 1311 7. IANA Considerations 1313 This document requires the following IANA actions: 1315 [RFC Editor: please delete] /* to be done: IANA consideration to be 1316 included for the defined namespaces in Section 5.1.5 and Section 5.3 1317 . */ 1319 8. Privacy Considerations 1321 [RFC Editor: please delete] /* to be done: clarification necessary */ 1323 9. Security Considerations 1325 [RFC Editor: please delete] /* to be done: clarification necessary */ 1327 10. Acknowledgments 1329 We would like to thank the various reviewers for their input, in 1330 particular Brian E. Carpenter, Giorgio Romanenghi, Oskar Camenzind, 1331 for their input and discussion on use cases and call flows. 1333 11. References 1335 11.1. Normative References 1337 [I-D.ietf-anima-bootstrapping-keyinfra] 1338 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1339 and K. Watsen, "Bootstrapping Remote Secure Key 1340 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1341 keyinfra-41 (work in progress), April 2020. 1343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1344 Requirement Levels", BCP 14, RFC 2119, 1345 DOI 10.17487/RFC2119, March 1997, 1346 . 1348 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1349 "Enrollment over Secure Transport", RFC 7030, 1350 DOI 10.17487/RFC7030, October 2013, 1351 . 1353 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1354 "A Voucher Artifact for Bootstrapping Protocols", 1355 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1356 . 1358 11.2. Informative References 1360 [I-D.gutmann-scep] 1361 Gutmann, P., "Simple Certificate Enrolment Protocol", 1362 draft-gutmann-scep-16 (work in progress), March 2020. 1364 [I-D.ietf-lamps-lightweight-cmp-profile] 1365 Brockhaus, H., Fries, S., and D. Oheimb, "Lightweight CMP 1366 Profile", draft-ietf-lamps-lightweight-cmp-profile-01 1367 (work in progress), March 2020. 1369 [I-D.selander-ace-coap-est-oscore] 1370 Selander, G., Raza, S., Furuhed, M., Vucinic, M., and T. 1371 Claeys, "Protecting EST Payloads with OSCORE", draft- 1372 selander-ace-coap-est-oscore-03 (work in progress), March 1373 2020. 1375 [IEC-62351-9] 1376 International Electrotechnical Commission, "IEC 62351 - 1377 Power systems management and associated information 1378 exchange - Data and communications security - Part 9: 1379 Cyber security key management for power system equipment", 1380 IEC 62351-9 , May 2017. 1382 [ISO-IEC-15118-2] 1383 International Standardization Organization / International 1384 Electrotechnical Commission, "ISO/IEC 15118-2 Road 1385 vehicles - Vehicle-to-Grid Communication Interface - Part 1386 2: Network and application protocol requirements", ISO/ 1387 IEC 15118 , April 2014. 1389 [NERC-CIP-005-5] 1390 North American Reliability Council, "Cyber Security - 1391 Electronic Security Perimeter", CIP 005-5, December 2013. 1393 [OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0 1394 (Draft)", April 2018. 1396 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1397 Request Syntax Specification Version 1.7", RFC 2986, 1398 DOI 10.17487/RFC2986, November 2000, 1399 . 1401 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1402 "Internet X.509 Public Key Infrastructure Certificate 1403 Management Protocol (CMP)", RFC 4210, 1404 DOI 10.17487/RFC4210, September 2005, 1405 . 1407 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1408 Certificate Request Message Format (CRMF)", RFC 4211, 1409 DOI 10.17487/RFC4211, September 2005, 1410 . 1412 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 1413 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 1414 . 1416 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1417 Housley, R., and W. Polk, "Internet X.509 Public Key 1418 Infrastructure Certificate and Certificate Revocation List 1419 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1420 . 1422 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1423 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1424 . 1426 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1427 Uniform Resource Identifiers (URIs)", RFC 5785, 1428 DOI 10.17487/RFC5785, April 2010, 1429 . 1431 Appendix A. History of changes [RFC Editor: please delete] 1433 From individual version 03 -> IETF draft 00: 1435 o Inclusion of discovery options of enrollment endpoints at the 1436 domain registrar based on well-known endpoints in Section 5.3 as 1437 replacement of section 5.1.3 in the individual draft. This is 1438 intended to support both use cases in the document. An 1439 illustrative example is provided. 1441 o Missing details provided for the description and call flow in 1442 pledge-agent use case Section 5.2, e.g. to accommodate 1443 distribution of CA certificates. 1445 o Updated CMP example in Section 6 to use lightweight CMP instead of 1446 CMP, as the draft already provides the necessary /.well-known 1447 endpoints. 1449 o Requirements discussion moved to separate section in Section 4. 1450 Shortened description of proof of identity binding and mapping to 1451 existing protocols. 1453 o Removal of copied call flows for voucher exchange and registrar 1454 discovery flow from [I-D.ietf-anima-bootstrapping-keyinfra] in 1455 Section 5.1 to avoid doubling or text or inconsistencies. 1457 o Reworked abstract and introduction to be more crisp regarding the 1458 targeted solution. Several structural changes in the document to 1459 have a better distinction between requirements, use case 1460 description, and solution description as separate sections. 1461 History moved to appendix. 1463 From individual version 02 -> 03: 1465 o Update of terminology from self-contained to authenticated self- 1466 contained object to be consistent in the wording and to underline 1467 the protection of the object with an existing credential. Note 1468 that the naming of this object may be discussed. An alternative 1469 name may be attestation object. 1471 o Simplification of the architecture approach for the initial use 1472 case having an offsite PKI. 1474 o Introduction of a new use case utilizing authenticated self- 1475 contain objects to onboard a pledge using a commissioning tool 1476 containing a pledge-agent. This requires additional changes in 1477 the BRSKI call flow sequence and led to changes in the 1478 introduction, the application example,and also in the related 1479 BRSKI-AE call flow. 1481 o Update of provided examples of the addressing approach used in 1482 BRSKI to allow for support of multiple enrollment protocols in 1483 Section 5.1.5. 1485 From individual version 01 -> 02: 1487 o Update of introduction text to clearly relate to the usage of 1488 IDevID and LDevID. 1490 o Definition of the addressing approach used in BRSKI to allow for 1491 support of multiple enrollment protocols in Section 5.1.5. This 1492 section also contains a first discussion of an optional discovery 1493 mechanism to address situations in which the registrar supports 1494 more than one enrollment approach. Discovery should avoid that 1495 the pledge performs a trial and error of enrollment protocols. 1497 o Update of description of architecture elements and changes to 1498 BRSKI in Section 5. 1500 o Enhanced consideration of existing enrollment protocols in the 1501 context of mapping the requirements to existing solutions in 1502 Section 4 and in Section 6. 1504 From individual version 00 -> 01: 1506 o Update of examples, specifically for building automation as well 1507 as two new application use cases in Section 3.2. 1509 o Deletion of asynchronous interaction with MASA to not complicate 1510 the use case. Note that the voucher exchange can already be 1511 handled in an asynchronous manner and is therefore not considered 1512 further. This resulted in removal of the alternative path the 1513 MASA in Figure 1 and the associated description in Section 5. 1515 o Enhancement of description of architecture elements and changes to 1516 BRSKI in Section 5. 1518 o Consideration of existing enrollment protocols in the context of 1519 mapping the requirements to existing solutions in Section 4. 1521 o New section starting Section 6 with the mapping to existing 1522 enrollment protocols by collecting boundary conditions. 1524 Authors' Addresses 1526 Steffen Fries 1527 Siemens AG 1528 Otto-Hahn-Ring 6 1529 Munich, Bavaria 81739 1530 Germany 1532 Email: steffen.fries@siemens.com 1533 URI: http://www.siemens.com/ 1535 Hendrik Brockhaus 1536 Siemens AG 1537 Otto-Hahn-Ring 6 1538 Munich, Bavaria 81739 1539 Germany 1541 Email: hendrik.brockhaus@siemens.com 1542 URI: http://www.siemens.com/ 1543 Eliot Lear 1544 Cisco Systems 1545 Richtistrasse 7 1546 Wallisellen CH-8304 1547 Switzerland 1549 Phone: +41 44 878 9200 1550 Email: lear@cisco.com