idnits 2.17.1 draft-fries-anima-brski-async-enroll-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1754 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-22 == Outdated reference: A later version (-16) exists of draft-gutmann-scep-14 -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 0 errors (**), 0 flaws (~~), 3 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 9, 2020 E. Lear 6 Cisco Systems 7 July 8, 2019 9 Support of asynchronous Enrollment in BRSKI 10 draft-fries-anima-brski-async-enroll-01 12 Abstract 14 This document discusses an enhancement of automated bootstrapping of 15 a remote secure key infrastructure (BRSKI) to operate in domains 16 featuring no or only timely limited connectivity to backend services 17 offering enrollment functionality, specifically a Public Key 18 Infrastructure (PKI). In the context of deploying new devices the 19 design of BRSKI allows for online (synchronous object exchange) and 20 offline interactions (asynchronous object exchange) with a 21 manufacturer's authorization service. For this it utilizes a self- 22 contained voucher to transport the domain credentials as a signed 23 object to establish an initial trust between the pledge and the 24 deployment domain. The currently supported enrollment protocol for 25 request and distribution of deployment domain specific device 26 certificates provides only limited support for asynchronous PKI 27 interactions. This memo motivates the enhancement of supporting 28 self-contained objects for certificate management by using an 29 abstract notation. This allows off-site operation of PKI services 30 outside the deployment domain of the pledge. This addresses 31 specifically scenarios, in which the final authorization of 32 certification request of a pledge cannot be made in the deployment 33 domain and is therefore delegated to a operator backend. The goal is 34 to enable the usage of existing and potentially new PKI protocols 35 supporting self-containment for certificate management. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 9, 2020. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. History of changes . . . . . . . . . . . . . . . . . . . . . 5 73 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4. Scope of solution . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1. Supported environment . . . . . . . . . . . . . . . . . . 6 76 4.2. Application Examples . . . . . . . . . . . . . . . . . . 7 77 4.2.1. Rolling stock . . . . . . . . . . . . . . . . . . . . 7 78 4.2.2. Building automation . . . . . . . . . . . . . . . . . 7 79 4.2.3. Substation automation . . . . . . . . . . . . . . . . 8 80 4.2.4. Electric vehicle charging infrastructure . . . . . . 8 81 4.2.5. Infrastructure isolation policy . . . . . . . . . . . 8 82 4.2.6. Less operational security in the deployment domain . 9 83 4.3. Requirement discussion and mapping to solution elements . 9 84 5. Architectural Overview . . . . . . . . . . . . . . . . . . . 11 85 5.1. Behavior of a pledge . . . . . . . . . . . . . . . . . . 14 86 5.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 14 87 5.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . 15 88 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 15 89 6.1. Pledge - Registrar discovery and voucher exchange . . . . 15 90 6.2. Registrar - MASA voucher exchange . . . . . . . . . . . . 16 91 6.3. Pledge - Registrar - RA/CA certificate enrollment . . . . 17 92 7. Mapping to exisitng enrollment protocols . . . . . . . . . . 19 93 7.1. EST Handling . . . . . . . . . . . . . . . . . . . . . . 19 94 7.2. CMP Handling . . . . . . . . . . . . . . . . . . . . . . 20 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 96 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 98 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 101 12.2. Informative References . . . . . . . . . . . . . . . . . 21 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 104 1. Introduction 106 BRSKI as defined in [I-D.ietf-anima-bootstrapping-keyinfra] specifies 107 a solution for secure zero-touch (automated) bootstrapping of devices 108 (pledges) in a target deployment domain. This includes the discovery 109 of network elements in the deployment domain, time synchronization, 110 and the exchange of security information necessary to establish trust 111 between a pledge and the domain and to adopt a pledge as new network 112 and application element. Security information about the deployment 113 domain, specifically the deployment domain certificate (domain root 114 certificate), is exchanged utilizing vouchers as defined in 115 [RFC8366]. These vouchers are self-contained objects, which may be 116 provided online (synchronous) or offline (asynchronous) via the 117 domain registrar to the pledge and originate from a manufacturer's 118 authorization service (MASA). The manufacturer signed voucher 119 contains the target domain certificate and can be verified by the 120 pledge due to the possession of a manufacturer root certificate. It 121 facilitates the enrollment of the pledge in the deployment domain and 122 is used to establish trust. 124 For the enrollment of devices BRSKI relies on EST [RFC7030] to 125 request and distribute deployment domain specific device 126 certificates. EST in turn relies on a binding of the certification 127 request to an underlying TLS connection between the EST client and 128 the EST server. According to BRSKI the domain registrar acts as EST 129 server and is also acting as registration authority (RA) or local 130 registration authority (LRA). The binding to TLS is used to protect 131 the exchange of a certification request (for an LDevID certificate) 132 and to provide data origin authentication to support the 133 authorization decision for processing the certification request. The 134 TLS connection is mutually authenticated and the client side 135 authentication bases on the pledge's manufacturer issued device 136 certificate (IDevID certificate). This approach requires an on-site 137 availability of the RA as PKI component and/or a local asset or 138 inventory management system performing the authorization decision 139 based on the certification request to issue a domain specific 140 certificate to the pledge. This is due to the EST server terminating 141 the security association with the pledge and thus the binding between 142 the certification request and the authentication of the pledge. This 143 type of enrollment utilizing an online connection to the PKI is 144 considered as synchronous enrollment. 146 For certain use cases on-site support of a RA/CA component and/or an 147 asset management is not available and rather provided by an operators 148 backend and may be provided timely limited or completely through 149 offline interactions. This may be due to higher security 150 requirements for operating the certification authority. The 151 authorization of a certification request based on an asset management 152 in this case will not / can not be performed on-site at enrollment 153 time. Enrollment, which cannot be performed in a (timely) consistent 154 fashion is considered as asynchronous enrollment in this document. 155 It requires the support of a store and forward functionality of 156 certification request together with the requester authentication 157 information. This enables processing of the request at a later point 158 in time. A similar situation may occur through network segmentation, 159 which is utilized in industrial systems to separate domains with 160 different security needs. Here, a similar requirement arises if the 161 communication channel carrying the requester authentication is 162 terminated before the RA/CA. If a second communication channel is 163 opened to forward the certification request to the issuing CA, the 164 requester authentication information needs to be bound to the 165 certification request. For both cases, it is assumed that the 166 requester authentication information is utilized in the process of 167 authorization of a certification request. There are different 168 options to perform store and forward of certification requests 169 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 (the IDevID) and potentially 174 the information about a successful proof of possession (of the 175 corresponding private key) in a way prohibiting changes to the 176 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 possesion) 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 authentication 183 result and thus performs the authorization and issues the 184 requested certificate. In BRSKI the trusted component may be the 185 EST server residing co-located with the registrar in the 186 deployment domain. 188 o Utilization of self-contained objects binding the certification 189 request and the requester authentication in a cryptographic way. 190 This approach reduces the necessary trust in a domain component to 191 storage and delivery. Unauthorized modifications of the requestor 192 information (request and authentication) can be detected during 193 the verification of the cryptographic binding of the self- 194 contained object in the off-site PKI. 196 This document targets environments, in which connectivity to the PKI 197 functionality is only temporary or not directly available by 198 specifying support for handling self-contained objects supporting 199 asynchronous enrollment. As it is intended to enhance BRSKI it is 200 named BRSKI-AE, where AE stands for asynchronous enrollment. As 201 BRSKI, BRSKI-AE results in the pledge storing a X.509 root 202 certificate sufficient for verifying the domain registrar / proxy 203 identity as well as an domain specific X.509 device certificate 204 (LDevID certificate). 206 The goal is to enhance BRSKI to either allow other existing 207 certificate management protocols supporting self-contained objects to 208 be applied or to allow other types of encoding for the certificate 209 management information exchange. 211 Note that in contrast to BRSKI, BRSKI-AE assumes support of multiple 212 enrollment protocols on the infrastructure side, allowing the pledge 213 manufacturer to select the most appropriate. Thus, BRSKI-AE can be 214 applied for both, asynchronous and synchronous enrollment. 216 2. History of changes 218 From version 00 -> 01: 220 o Update of examples, specifically for building automation as well 221 as two new application use cases in Section 4.2. 223 o Deletion of asynchronous interaction with MASA to not complicate 224 the use case. Note that the voucher exchange can already be 225 handled in an asynchronous manner and is therefore not considered 226 further. This resulted in removal of the alternative path the 227 MASA in Figure 1 and the associated description in Section 5. 229 o Enhancement of description of architecture elements and changes to 230 BRSKI in Section 5. 232 o Consideration of existing enrollment protocols in the context of 233 mapping the requirements to existing solutions in Section 4.3. 235 o New section starting Section 7 with the mapping to existing 236 enrollment protocols by collecting boundary conditions. 238 3. Terminology 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 242 "OPTIONAL" in this document are to be interpreted as described in 243 [RFC2119]. 245 This document relies on the terminology defined in 246 [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are 247 defined additionally: 249 CA: Certification authority, issues certificates. 251 RA: Registration authority, an optional system component to which a 252 CA delegates certificate management functions such as 253 authorization checks. 255 LRA: Local registration authority, an optional RA system component 256 with proximity to end entities. 258 IED: Intelligent Electronic Device (in essence a pledge). 260 on-site: Describes a component or service or functionality available 261 in the target deployment domain. 263 off-site: Describes a component or service or functionality 264 available in an operator domain different from the target 265 deployment domain. This may be a central side, to which only a 266 temporarily connection is available or which is in a different 267 administrative domain. 269 asynchronous communication: Describes a timely interrupted 270 communication between an end entity and a PKI component. 272 synchronous communication: Describes a timely uninterrupted 273 communication between an end entity and a PKI component. 275 4. Scope of solution 277 4.1. Supported environment 279 This solution is intended to be used in domains with limited support 280 of on-site PKI services and comprises use cases in which: 282 o there is no registration authority available in the deployment 283 domain. The connectivity to the backend RA may only be 284 temporarily available. A local store and forward device is used 285 for the communication with the backend services. 287 o authoritive actions of a LRA are limited and may not comprise 288 authorization of certification requests of pledges. Final 289 authorization is done at the RA residing in the backend operator 290 domain. 292 o the target deployment domain already uses a certificate management 293 approach that shall be reused to be consistent throughout the 294 lifecycle. 296 4.2. Application Examples 298 The following examples are intended to motivate the support of 299 different enrollment approaches in general and asynchronous 300 enrollment specifically, by introducing industrial applications 301 cases, which could leverage BRSKI as such but also require support of 302 asynchronous operation as intended with BRSKI-AE. 304 4.2.1. Rolling stock 306 Rolling stock or railroad cars contain a variety of sensors, 307 actuators, and controller, which communicate within the railroad car 308 but also exchange information between railroad cars building a train 309 or with a backend. These devices are typically unaware of backend 310 connectivity. Managing certificates may be done during maintenance 311 cycles of the railroad car, but can already be prepared during 312 operation. The preparation may comprise the generation of 313 certification requests by the components which are collected and 314 forwarded for processing once the railroad car is connected to the 315 operator backend. The authorization of the certification request is 316 then done based on the operators asset/inventory information. 318 4.2.2. Building automation 320 In building automation a use case can be described by a detached 321 building or the basement of a building equipped with sensor, 322 actuators, and controllers connected, but with only limited or no 323 connection to the centralized building management system. This 324 limited connectivity may be during the installation time but also 325 during operation time. During the installation in the basement, a 326 service technician collects the necessary information from the 327 basement network and provides them to the central building management 328 system, e.g., using a laptop or even a mobile phone to transport the 329 information. This information may comprise parameters and settings 330 required in the operational phase of the sensors/actuators, like a 331 certificate issued by the operator to authenticate against other 332 components and services. 334 4.2.3. Substation automation 336 In substation automation a control center typically hosts PKI 337 services to issue certificates for Intelligent Electronic Devices 338 (IED)s in a substation. Communication between the substation and 339 control center is done through a proxy/gateway/DMZ, which terminates 340 protocol flows. Note that NERC CIP-005-5 [NERC-CIP-005-5] requires 341 inspection of protocols at the boundary of a security perimeter (the 342 substation in this case). In addition, security management in 343 substation automation assumes central support of different enrollment 344 protocols to facilitate the capabilities of IEDs from different 345 vendors. The IEC standard IEC62351-9 [IEC-62351-9] specifies the 346 mandatory support of two enrollment protocols, SCEP 347 [I-D.gutmann-scep] and EST [RFC7030] for the infrastructure side, 348 while the IED must only support one of the two. 350 4.2.4. Electric vehicle charging infrastructure 352 For the electric vehicle charging infrastructure protocols have been 353 defined for the interaction between the electric vehicle (EV) and the 354 charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as 355 between the charging point and the charging point operator (e.g. 356 OCPP [OCPP]). Depending on the authentication model, unilateral or 357 mutual authentication is required. In both cases the charging point 358 authenticates uses an X.509 certificate to authenticate in the 359 context of a TLS connection between the EV and the charging point. 360 The management of this certificate depends (beyond others) on the 361 selected backend connectivity protocol. Specifically in case of OCPP 362 it is intended as single communication protocol between the charging 363 point and the backend carrying all information to control the 364 charging operations and maintain the charging point itself. This 365 means that the certificate management is intended to be handled in- 366 band of OCPP. This requires to be able to encapsulate the 367 certificate management exchanges in a transport independent way. 368 Self-containment will ease this by allowing the transport without a 369 separate communication protocol. For the purpose of certificate 370 management CMP [RFC4210]is intended to be used. 372 4.2.5. Infrastructure isolation policy 374 This refers to any case in which network infrastructure is normally 375 isolated from the Internet as a matter of policy, most likely for 376 security reasons. In such a case, limited access to external PKI 377 resources will be allowed in carefully controlled short periods of 378 time, for example when a batch of new devices are deployed, but 379 impossible at other times. 381 4.2.6. Less operational security in the deployment domain 383 The registration point performing the authorization of a certificate 384 request is a critical PKI component and therefore implicates higher 385 operational security than other components utilizing the issued 386 certificates for their security features. CAs may also demand higher 387 security in the registration procedures. Especially the CA/Browser 388 forum currently increases the security requirements in the 389 certificate issuance procedures for publicly trusted certificates. 390 There may be the situation that the deployment domain does not offer 391 enough security to operate a registration point and therefore wants 392 to transfer this service to a backend. 394 4.3. Requirement discussion and mapping to solution elements 396 For the requirements discussion it is assumed that the entity 397 receiving the self-contained object in the deployment domain is not 398 the authorization point for the certification request contained in 399 the object. If the entity is the authorization point, BRSKI can be 400 used directly. Note that BRSKI-AE could address both cases. 402 Based on the supported deployment environment described in 403 Section 4.1 and the motivated application examples described in 404 Section 4.2 the following base requirements are derived to support 405 self-contained objects as container carrying the certification 406 request and further information to support asynchronous operation. 407 Moreover, potential solution examples (not complete) based on 408 existing technology are provided with the focus on existing IETF 409 standards track documents: 411 o Certification requests are structures protecting at least 412 integrity of the contained data combined with a proof-of-private- 413 key-possession for locally generated key pairs. Examples for 414 certification requests 416 * PKCS#10 [RFC2986]: Defines a structure for a certification 417 request. The structure must be signed to ensure integrity 418 protection and proof-of-private-key-possession. Hence, the 419 signature is performed by using the private key of the 420 requestor (corresponding to the contained public key). 422 * CRMF [RFC4211]: Defines a structure for the certification 423 request. The structure also typically contains an integrity 424 protection and a proof of possession, in which a signature 425 value is generated by using the corresponding private key to 426 the contained public key. This self-signature can also be 427 replaced by the RA after verification, if the RA intends to 428 update or alter the request message. 430 Note that the integrity is bound to the public key contained in 431 the certification request. In the considered application 432 examples, this is not sufficient and needs to be bound to the data 433 origin authentication (IDevID). This binding also supports the 434 authorization decision for the certification request. The binding 435 of data origin authentication to the certification request is 436 delegated to the management protocol. 438 o The container carrying the certification request should support a 439 binding to an existing credential known to the peer performing the 440 authoriation of the certification request as proof of identity. 441 The binding may be transport dependent if the endpoint at the next 442 communication hop is authorizing the certification request. This 443 requirements is addressed by existing enrollment protocols in 444 different ways, for instance: 446 * EST [RFC7030]: Utilizes PKCS#10 to encode the certification 447 request. The Certificate Signing Request (CSR) contains a 448 binding to the underlying TLS by including the tls-unique value 449 in the self-signed CSR structure. The tls-unique value is one 450 result of the TLS handshake. As the TLS handshake is performed 451 mutually authenticated and the pledge utilized its IDevID for 452 it, the proof of identity can be provided by the binding to the 453 TLS session. 455 * SCEP [I-D.gutmann-scep]: Provides the option to utilize either 456 an existing secret (password) or an existing certificate to 457 protect the CSR based on SCEP Secure Message Objects using CMS 458 ([RFC5652]). Note that the wrapping using an existing IDevID 459 credential is not specified directly in SCEP. 461 * CMP [RFC4210] Provides the option to utilize either an existing 462 secret (password) or an existing certificate to protect the 463 PKIMessage containing the certification request. The 464 certification request is encoded utilizing CRMF. PKCS#10 is 465 optionally supported. The proof of identity of the PKIMessage 466 containing the certification request can be achieved by using 467 IDevID credentials to calculate a signature over the header and 468 the body of the PKIMessage utilizing the protectionAlg signaled 469 in the PKIMessage header and the PKIProtection carrying the 470 actual signature value. 472 * CMC [RFC5272] Provides the option to utilize either an existing 473 secret (password) or an existing certificate to protect the 474 certification request (either in CRMF or PKCS#10) based on CMS 475 [RFC5652]). Here a FullCMCRequest would be used, which allows 476 signing with an existing IDevID credential to provide a proof 477 of identity. 479 o The container carrying the certification request should support 480 transport independent protection using an existing credential of 481 the pledge verifiable at the authorization point of the 482 certification request (typically the RA in conjunction with an 483 inventory). This requirements is addressed by existing enrollment 484 protocols in different ways, for instance: 486 * EST [RFC7030]: Not supported. 488 * SCEP [I-D.gutmann-scep]: Not specified in SCEP, could be done 489 using message wrapping with signature (based on CMS). 491 * CMP [RFC4210]: Message wrapping with signature. 493 * CMC [RFC5272]: Message wrapping with signature. 495 5. Architectural Overview 497 To support asynchronous enrollment, the base system architecture 498 defined in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] is changed 499 to allow for off-site operation of the PKI components. The 500 assumption for BRSKI-AE is that the authorization for a certification 501 request is performed using an inventory or asset management system 502 residing in the backend of the domain operator as described in 503 Section 4.1. This leads to changes in the placement or enhancements 504 of the logical elements as shown in Figure 1. 506 +------------------------+ 507 +--------------Drop Ship--------------->| Vendor Service | 508 | +------------------------+ 509 | | M anufacturer| | 510 | | A uthorized |Ownership| 511 | | S igning |Tracker | 512 | | A uthority | | 513 | +--------------+---------+ 514 | ^ 515 | | 516 V | 517 +--------+ ......................................... | 518 | | . . | 519 | | . +------------+ +------------+ . | BRSKI- 520 | | . | | | | . | MASA 521 | Pledge | . | Join | | Domain <-----+ 522 | | . | Proxy | | Registrar/ | . 523 | <-------->............<-------> Proxy | . 524 | | . | BRSKI-AE | | . 525 | IDevID | . | | +------^-----+ . 526 | | . +------------+ | . 527 | | . | . 528 +--------+ ...............................|......... 529 "on-site domain" components | 530 | 531 | 532 .............................................|..................... 533 . +---------------------------+ +--------v------------------+ . 534 . | Public Key Infrastructure |<----+ PKI RA | . 535 . | PKI CA |---->+ [(Domain) Registrar (opt)]| . 536 . +---------------------------+ +--------+--^---------------+ . 537 . | | . 538 . +--------v--+---------------+ . 539 . | Inventory (Asset) | . 540 . | Management | . 541 . +---------------------------+ . 542 ................................................................... 543 "off-site domain" components 545 Figure 1: Architecture overview of BRSKI-AE 547 The architecture overview in Figure 1 utilizes the same logical 548 elements as BRSKI but with a different placement in the architecture 549 for some of the elements. The main difference is the placement of 550 the PKI RA/CA component, which is actually performing the 551 authorization decision for the certification request message. Also 552 shown is the connectivity of the RA/CA with an inventory management 553 system, which is expected to be utilized in the authorization 554 decision. Note that this may also be an integrated functionality of 555 the RA. Both components are placed in the off-site domain of the 556 operator (not the deployment site directly), which may have no or 557 only temporary connectivity to the deployment domain of the pledge. 558 This is to underline the authorization decision for the certification 559 request in the backend rather than in the deployment domain itself. 560 The following list describes the components in the deployment domain: 562 o Join Proxy: same functionality as described in BRSKI 564 o Domain Registrar / Proxy: In general the domain registrar / proxy 565 has a similar functionality regarding the imprinting of the pledge 566 in the deployment domain to facilitate the communication of the 567 pledge with the MASA and the PKI. Different is the authorization 568 of the certification request. BRSKI-AE allows to perform this in 569 the operators backend (off-site), even if the deployment domain 570 has only temporary or no connectivity to an operator domain. 572 * Voucher exchange: The voucher exchange with the MASA via the 573 domain registrar is performed as described in BRSKI 574 [I-D.ietf-anima-bootstrapping-keyinfra] . 576 * Certificate enrollment: For the pledge enrollment the domain 577 registrar in the deployment domain support the authorization of 578 the pledge to be part of the domain, but not necessarily to 579 authorize the certification request provided during enrollment. 580 This may be due to lack of authorization information in the 581 deployment domain. If the authorization is done in the 582 operator domain, the domain registrar is used to forward the 583 certification request to the RA. Thus it basically works as a 584 proxy. In the case of no connectivity, the domain registrar 585 stores the certification request and forwards it to the RA upon 586 connectivity. As this requires the certification request to be 587 self-contained, the domain registrar needs functionality 588 enhancements with respect to the support of alternative 589 enrollment approaches supporting self-containment. To support 590 alternative enrollment approaches (protocols, encodings), it is 591 necessary to enhance the addressing scheme at the domain 592 registrar. The communication channel between the pledge and 593 the domain registrar may be similarly described as in BRSKI 594 within the same "/.well-known" tree and may result in "/.well- 595 known/enrollment-variant/request". 597 The following list describes the vendor related components/service 598 outside the deployment domain: 600 o MASA: general functionality as described in BRSKI. Assumption 601 that the interaction with the MASA may be synchronous (voucher 602 request with nonce) or asynchronous (voucher request without 603 nonce). 605 o Ownership tracker: as defined in BRSKI. 607 The following list describes the operator related components/service 608 operated in the backend: 610 o PKI RA: Performs certificate management functions (validation of 611 certification requests, interaction with inventory/asset 612 management for authorization of certification requests, etc.) for 613 issuing, updating, and revoking certificates for a domain as a 614 centralized infrastructure for the operator. 616 o PKI CA: Performs certificate generation by signing the certificate 617 structure provided in the certification request. 619 o Inventory (asset) management: contains information about the known 620 devices belonging to the operator. Specifically, the inventory is 621 used to provide the information to authorize issuing a certificate 622 based on the certification request of the pledge. Note: the 623 communication between the inventory (asset) management and the PKI 624 components (RA/CA) are out of scope of this document. 626 o (Domain) registrar: Optional component if the deployment domain 627 does not feature a domain registrar but only a proxy. In this 628 case it is involved in the certification request processing and is 629 assumed to be co-located with the PKI RA. 631 5.1. Behavior of a pledge 633 The behavior of a pledge as described in 634 [I-D.ietf-anima-bootstrapping-keyinfra] is kept with one exception. 635 After finishing the imprinting phase (4) the enrollment phase (5) is 636 performed with a method supporting self-contained objects. Using 637 simpleenroll with EST as taken in BRSKI cannot be applied here, as it 638 binds the pledge authentication with the existing IDevID using the 639 transport channel. This authentication is not visible / verifiable 640 at the authorization point in the off-site domain. /* mapping to 641 existing protocols based on the outcome of the discussion */ 643 5.2. Secure Imprinting using Vouchers 645 The described approach in [I-D.ietf-anima-bootstrapping-keyinfra] is 646 kept as is. 648 5.3. Addressing 650 For the provisioning of different enrollment options at the domain 651 registrar, the addressing approach of BRSKI using a "/.well-known" 652 tree from [RFC5785] is enhanced. 654 /* to be done: Description of "/.well-known/enrollment-protocol/ 655 request" in which enrollment-protocol may be an already existing 656 protocol like "est" or "scep" or "cmp" or "cms" or a newly defined 657 protocol. */ 659 6. Protocol Flows 661 Based on BRSKI and the architectural changes the original protocol 662 flow is divided into three phases showing commonalities and 663 differences to the original approach as depicted in the following. 665 o Discovery phase (same as BRSKI) 667 o Voucher exchange with deployment domain registrar (same as BRSKI). 669 o Enrollment phase (changed to accompany the application of self- 670 contained objects for the enrollment). 672 6.1. Pledge - Registrar discovery and voucher exchange 674 The discovery phase is applied as specified in 675 [I-D.ietf-anima-bootstrapping-keyinfra]. /* for discussion: is a 676 reference to BRSKI sufficient here or is it helpful to provide 677 additional information and the figure? */ 678 +--------+ +---------+ +------------+ +------------+ 679 | Pledge | | Circuit | | Domain | | Vendor | 680 | | | Join | | Registrar | | Service | 681 | | | Proxy | | (JRC) | | (MASA) | 682 +--------+ +---------+ +------------+ +------------+ 683 | | | Internet | 684 |<-RFC4862 IPv6 addr | | | 685 |<-RFC3927 IPv4 addr | Appendix A | Legend | 686 |-------------------->| | C - circuit | 687 | optional: mDNS query| Appendix B | join proxy | 688 | RFC6763/RFC6762 | | P - provisional | 689 |<--------------------| | TLS connection | 690 | GRASP M_FLOOD | | | 691 | periodic broadcast| | | 692 |<------------------->C<----------------->| | 693 | TLS via the Join Proxy | | 694 |<--Registrar TLS server authentication---| | 695 [PROVISIONAL accept of server cert] | | 696 P---X.509 client authentication---------->| | 697 P | | | 698 P--Voucher Request (w/nonce for voucher)->| | 699 P | /---> | | 700 P | | see Figure 3 below | 701 P | \----> | | 702 P<------voucher---------------------------| | 703 [verify voucher, imprint] | | 704 |---------------------------------------->| | 705 | [voucher status telemetry] |<-device audit log--| 706 | | [verify audit log and voucher] | 707 |<--------------------------------------->| | 709 Figure 2: Pledge discovery of domain registrar discovery and voucher 710 exchange 712 6.2. Registrar - MASA voucher exchange 714 The voucher exchange is performed as specified in 715 [I-D.ietf-anima-bootstrapping-keyinfra]. /* for discussion: is a 716 reference to BRSKI sufficient here or is it helpful to provide 717 additional information and the figure? */ 718 +--------+ +---------+ +------------+ +------------+ 719 | Pledge | | Circuit | | Domain | | Vendor | 720 | | | Join | | Registrar | | Service | 721 | | | Proxy | | (JRC) | | (MASA) | 722 +--------+ +---------+ +------------+ +------------+ 723 P | /---> | | 724 P | | [accept device in domain] | 725 P | | [contact Vendor] | 726 P | | |--Pledge ID-------->| 727 P | | |--Domain ID-------->| 728 P | | |--optional:nonce--->| 729 P | | | [extract DomainID] 730 P | optional: | [update audit log] 731 P | can occur in advance if nonceless | 733 Figure 3: Domain registrar - MASA voucher exchange 735 6.3. Pledge - Registrar - RA/CA certificate enrollment 737 The enrollment for BRSKI-AE will be performed using a self-contained 738 object. According to the abstract requirements from 739 [I-D.ietf-anima-bootstrapping-keyinfra]. This object shall at least 740 contain the following information: 742 o Proof of Possession: utilizing the private key corresponding to 743 the public key contained in the certification request. 745 o Proof of Identity: utilizing the existing IDevID credential to 746 generate a signature of the certification request. 748 o /* further parameter to be specified */. 750 +--------+ +---------+ +------------+ +------------+ 751 | Pledge | | Circuit | | Domain | | Operator | 752 | | | Join | | Registrar | | RA/CA | 753 | | | Proxy | | (JRC) | | (OPKI) | 754 +--------+ +---------+ +------------+ +------------+ 755 /--> | | 756 |---------- Request CA Certs ------------>| | 757 | [if connection to operator domain is available] | 758 | |-Request CA Certs ->| 759 | |<- CA Certs Response| 760 |<-------- CA Certs Response--------------| | 761 |---------- Attribute Request ----------->| | 762 | [if connection to operator domain is available] | 763 | |Attribute Request ->| 764 | |<-Attribute Response| 765 |<--------- Attribute Response -----------| | 766 /--> | | 767 |-------------- Cert Request ------------>| | 768 | [if connection to operator domain is available] | 769 | |--- Cert Request -->| 770 | |<-- Cert Response --| 771 /--> | | 772 | [if connection to operator domain is not available] | 773 | | | 774 |<---------- Cert Waiting ----------------| | 775 |-- Cert Polling (with orig request ID) ->| | 776 | [if connection to operator domain is available] | 777 | |--- Cert Request -->| 778 | |<-- Cert Response --| 779 /--> | | 780 |<------------- Cert Response ------------| | 781 |-------------- Cert Confirm ------------>| | 782 | /--> | 783 | |[optional] | 784 | |--- Cert Confirm -->| 785 | |<-- PKI Confirm ----| 786 |<------------- PKI/Registrar Confirm ----| | 788 Figure 4: Certificate enrollment 790 The following list provides an abstract description of the flow 791 depicted in Figure 4. 793 o CA Cert Request: The pledge SHOULD request the full distribution 794 of CA Certificates message. This ensures that the pledge has the 795 complete set of current CA certificates beyond the pinned-domain- 796 cert. 798 o Attribute Request: Typically, the automated bootstrapping occurs 799 without local administrative configuration of the pledge. 800 Nevertheless, there are cases, in which the pledge should also 801 include additional attributes specific to the deployment domain 802 into the certification request. To get these attributes in 803 advance, the attribute request SHOULD be used. 805 o Cert Request: certification request message (to be done: reference 806 to PKCS#10 or CRMF, proof of possession, pledge authentication) 808 o Cert Response: certification response message containing the 809 requested certificate and potentially further information like 810 certificates of intermediary CAs on the certification path. 812 o Cert Waiting: waiting indication for the pledge to retry after a 813 given time. For this a request identifier is necessary. This 814 request identifier may bei either part of the enrollment protocol 815 or build based on the certification request. 817 o Cert Poling: querying the registrar, if the certificate request 818 was already processed; can be answered either with another Cert 819 Waiting, or a Cert Response. 821 o Cert Confirm: confirmation message from pledge after receiving and 822 verifying the certificate. 824 o PKI/Registrar Confirm: confirmation message from PKI/registrar 825 about reception of the pledge's certificate confirmation. 827 /* to be done: - investigation into handling of certificate request 828 retries - message exchange description - confirmation message 829 (necessary? optional? from Registrar and/or PKI?) */ 831 7. Mapping to exisitng enrollment protocols 833 This sections maps the requirements and the approach described in 834 Section 6.3 to already exisitng enrollment protocols. 836 7.1. EST Handling 838 When using the EST protocol [RFC7030], the following constrains 839 should be observed: 841 o Proof of possession is provided by using the specified PKCS #10 842 structure in the request method. 844 o For proof of identit only the /fullcmc endpoint should be used 845 with a fullcmc request. This contains sufficient information for 846 the RA/CA to make an authorization decision on the received 847 certification request. Note that EST references CMC [RFC5272] for 848 the definition of the full PKI request. For proof of identity, 849 the signature of the SignedData of the Full PKI Request would be 850 calculated using the IDEVID credential of the pledge. /*TBD: in 851 this case the binding to the underlying TLS connection may not be 852 necessary */ 854 o When the CA/CA is not available, as per [RFC7030] Section 4.2.3, a 855 202 return code should be returned by the Join Registrar. The 856 pledge in this case would retry with the same PKCS#10 request as 857 in the initial simpleentroll run. Note that if the TLS connection 858 is teared down for the waiting time, the PKCS#10 request would 859 need to be rebuild as it contains the unique identifier 860 (tls_unique) from the underlying TLS connection for the binding. 862 7.2. CMP Handling 864 When using the CMP protocol [RFC4210], the following constrains 865 should be observed: 867 o For proof of posession, the defined approach in CMP [RFC4210] 868 section 4.3 should be supported. This can be achieved by using 869 either CRMF or PKCS#10 to specify the certification request. 871 o Proof of identity can be provided by using the MSG_SIG_ALG to 872 protect the certificate request message with signatures as 873 outlined in section D.5. 875 o When the CA/CA is not available, as per [RFC4210] Section 5.2.3, a 876 waiting indication should be returned in the PKIStatus by the Join 877 Registrar. The pledge in this case would retry using the 878 PollReqContent with a request identifier certReqId provided in the 879 initial CertRequest message as specified in section 5.3.22. 881 8. IANA Considerations 883 This document requires the following IANA actions: 885 /* to be done: clarification necessary */ 887 9. Privacy Considerations 889 /* to be done: clarification necessary */ 891 10. Security Considerations 893 /* to be done: clarification necessary */ 895 11. Acknowledgements 897 We would like to thank the various reviewers for their input, in 898 particular Brian E. Carpenter, Giorgio Romanenghi, Oskar Camenzind 899 for their input and discussion on use cases and call flows. 901 12. References 903 12.1. Normative References 905 [I-D.ietf-anima-bootstrapping-keyinfra] 906 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 907 S., and K. Watsen, "Bootstrapping Remote Secure Key 908 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 909 keyinfra-22 (work in progress), June 2019. 911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 912 Requirement Levels", BCP 14, RFC 2119, 913 DOI 10.17487/RFC2119, March 1997, 914 . 916 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 917 "Enrollment over Secure Transport", RFC 7030, 918 DOI 10.17487/RFC7030, October 2013, 919 . 921 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 922 "A Voucher Artifact for Bootstrapping Protocols", 923 RFC 8366, DOI 10.17487/RFC8366, May 2018, 924 . 926 12.2. Informative References 928 [I-D.gutmann-scep] 929 Gutmann, P., "Simple Certificate Enrolment Protocol", 930 draft-gutmann-scep-14 (work in progress), June 2019. 932 [IEC-62351-9] 933 International Electrotechnical Commission, "IEC 62351 - 934 Power systems management and associated information 935 exchange - Data and communications security - Part 9: 936 Cyber security key management for power system equipment", 937 IEC 62351-9 , May 2017. 939 [ISO-IEC-15118-2] 940 International Standardization Organization / International 941 Electrotechnical Commission, "ISO/IEC 15118-2 Road 942 vehicles - Vehicle-to-Grid Communication Interface - Part 943 2: Network and application protocol requirements", ISO/ 944 IEC 15118 , April 2014. 946 [NERC-CIP-005-5] 947 North American Reliability Council, "Cyber Security - 948 Electronic Security Perimeter", CIP 005-5, December 2013. 950 [OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0", 951 April 2018. 953 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 954 Request Syntax Specification Version 1.7", RFC 2986, 955 DOI 10.17487/RFC2986, November 2000, 956 . 958 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 959 "Internet X.509 Public Key Infrastructure Certificate 960 Management Protocol (CMP)", RFC 4210, 961 DOI 10.17487/RFC4210, September 2005, 962 . 964 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 965 Certificate Request Message Format (CRMF)", RFC 4211, 966 DOI 10.17487/RFC4211, September 2005, 967 . 969 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 970 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 971 . 973 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 974 RFC 5652, DOI 10.17487/RFC5652, September 2009, 975 . 977 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 978 Uniform Resource Identifiers (URIs)", RFC 5785, 979 DOI 10.17487/RFC5785, April 2010, 980 . 982 Authors' Addresses 983 Steffen Fries 984 Siemens AG 985 Otto-Hahn-Ring 6 986 Munich, Bavaria 81739 987 Germany 989 Email: steffen.fries@siemens.com 990 URI: http://www.siemens.com/ 992 Hendrik Brockhaus 993 Siemens AG 994 Otto-Hahn-Ring 6 995 Munich, Bavaria 81739 996 Germany 998 Email: hendrik.brockhaus@siemens.com 999 URI: http://www.siemens.com/ 1001 Eliot Lear 1002 Cisco Systems 1003 Richtistrasse 7 1004 Wallisellen CH-8304 1005 Switzerland 1007 Phone: +41 44 878 9200 1008 Email: lear@cisco.com