Internet-Draft H. Brockhaus
Intended status: Standards Track Siemens
Expires: January 9, 2020 E. Lear
Cisco Systems
July 8, 2019

Support of asynchronous Enrollment in BRSKI


This document discusses an enhancement of automated bootstrapping of a remote secure key infrastructure (BRSKI) to operate in domains featuring no or only timely limited connectivity to backend services offering enrollment functionality, specifically a Public Key Infrastructure (PKI). In the context of deploying new devices the design of BRSKI allows for online (synchronous object exchange) and offline interactions (asynchronous object exchange) with a manufacturer's authorization service. For this it utilizes a self-contained voucher to transport the domain credentials as a signed object to establish an initial trust between the pledge and the deployment domain. The currently supported enrollment protocol for request and distribution of deployment domain specific device certificates provides only limited support for asynchronous PKI interactions. This memo motivates the enhancement of supporting self-contained objects for certificate management by using an abstract notation. This allows off-site operation of PKI services outside the deployment domain of the pledge. This addresses specifically scenarios, in which the final authorization of certification request of a pledge cannot be made in the deployment domain and is therefore delegated to a operator backend. The goal is to enable the usage of existing and potentially new PKI protocols supporting self-containment for certificate management.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 9, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

BRSKI as defined in [I-D.ietf-anima-bootstrapping-keyinfra] specifies a solution for secure zero-touch (automated) bootstrapping of devices (pledges) in a target deployment domain. This includes the discovery of network elements in the deployment domain, time synchronization, and the exchange of security information necessary to establish trust between a pledge and the domain and to adopt a pledge as new network and application element. Security information about the deployment domain, specifically the deployment domain certificate (domain root certificate), is exchanged utilizing vouchers as defined in [RFC8366]. These vouchers are self-contained objects, which may be provided online (synchronous) or offline (asynchronous) via the domain registrar to the pledge and originate from a manufacturer's authorization service (MASA). The manufacturer signed voucher contains the target domain certificate and can be verified by the pledge due to the possession of a manufacturer root certificate. It facilitates the enrollment of the pledge in the deployment domain and is used to establish trust.

For the enrollment of devices BRSKI relies on EST [RFC7030] to request and distribute deployment domain specific device certificates. EST in turn relies on a binding of the certification request to an underlying TLS connection between the EST client and the EST server. According to BRSKI the domain registrar acts as EST server and is also acting as registration authority (RA) or local registration authority (LRA). The binding to TLS is used to protect the exchange of a certification request (for an LDevID certificate) and to provide data origin authentication to support the authorization decision for processing the certification request. The TLS connection is mutually authenticated and the client side authentication bases on the pledge's manufacturer issued device certificate (IDevID certificate). This approach requires an on-site availability of the RA as PKI component and/or a local asset or inventory management system performing the authorization decision based on the certification request to issue a domain specific certificate to the pledge. This is due to the EST server terminating the security association with the pledge and thus the binding between the certification request and the authentication of the pledge. This type of enrollment utilizing an online connection to the PKI is considered as synchronous enrollment.

For certain use cases on-site support of a RA/CA component and/or an asset management is not available and rather provided by an operators backend and may be provided timely limited or completely through offline interactions. This may be due to higher security requirements for operating the certification authority. The authorization of a certification request based on an asset management in this case will not / can not be performed on-site at enrollment time. Enrollment, which cannot be performed in a (timely) consistent fashion is considered as asynchronous enrollment in this document. It requires the support of a store and forward functionality of certification request together with the requester authentication information. This enables processing of the request at a later point in time. A similar situation may occur through network segmentation, which is utilized in industrial systems to separate domains with different security needs. Here, a similar requirement arises if the communication channel carrying the requester authentication is terminated before the RA/CA. If a second communication channel is opened to forward the certification request to the issuing CA, the requester authentication information needs to be bound to the certification request. For both cases, it is assumed that the requester authentication information is utilized in the process of authorization of a certification request. There are different options to perform store and forward of certification requests including the requester authentication information:

This document targets environments, in which connectivity to the PKI functionality is only temporary or not directly available by specifying support for handling self-contained objects supporting asynchronous enrollment. As it is intended to enhance BRSKI it is named BRSKI-AE, where AE stands for asynchronous enrollment. As BRSKI, BRSKI-AE results in the pledge storing a X.509 root certificate sufficient for verifying the domain registrar / proxy identity as well as an domain specific X.509 device certificate (LDevID certificate).

The goal is to enhance BRSKI to either allow other existing certificate management protocols supporting self-contained objects to be applied or to allow other types of encoding for the certificate management information exchange.

Note that in contrast to BRSKI, BRSKI-AE assumes support of multiple enrollment protocols on the infrastructure side, allowing the pledge manufacturer to select the most appropriate. Thus, BRSKI-AE can be applied for both, asynchronous and synchronous enrollment.

2. History of changes

From version 00 -> 01:

3. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

This document relies on the terminology defined in [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are defined additionally:

Certification authority, issues certificates.
Registration authority, an optional system component to which a CA delegates certificate management functions such as authorization checks.
Local registration authority, an optional RA system component with proximity to end entities.
Intelligent Electronic Device (in essence a pledge).
Describes a component or service or functionality available in the target deployment domain.
Describes a component or service or functionality available in an operator domain different from the target deployment domain. This may be a central side, to which only a temporarily connection is available or which is in a different administrative domain.
asynchronous communication:
Describes a timely interrupted communication between an end entity and a PKI component.
synchronous communication:
Describes a timely uninterrupted communication between an end entity and a PKI component.

4. Scope of solution

4.1. Supported environment

This solution is intended to be used in domains with limited support of on-site PKI services and comprises use cases in which:

4.2. Application Examples

The following examples are intended to motivate the support of different enrollment approaches in general and asynchronous enrollment specifically, by introducing industrial applications cases, which could leverage BRSKI as such but also require support of asynchronous operation as intended with BRSKI-AE.

4.2.1. Rolling stock

Rolling stock or railroad cars contain a variety of sensors, actuators, and controller, which communicate within the railroad car but also exchange information between railroad cars building a train or with a backend. These devices are typically unaware of backend connectivity. Managing certificates may be done during maintenance cycles of the railroad car, but can already be prepared during operation. The preparation may comprise the generation of certification requests by the components which are collected and forwarded for processing once the railroad car is connected to the operator backend. The authorization of the certification request is then done based on the operators asset/inventory information.

4.2.2. Building automation

In building automation a use case can be described by a detached building or the basement of a building equipped with sensor, actuators, and controllers connected, but with only limited or no connection to the centralized building management system. This limited connectivity may be during the installation time but also during operation time. During the installation in the basement, a service technician collects the necessary information from the basement network and provides them to the central building management system, e.g., using a laptop or even a mobile phone to transport the information. This information may comprise parameters and settings required in the operational phase of the sensors/actuators, like a certificate issued by the operator to authenticate against other components and services.

4.2.3. Substation automation

In substation automation a control center typically hosts PKI services to issue certificates for Intelligent Electronic Devices (IED)s in a substation. Communication between the substation and control center is done through a proxy/gateway/DMZ, which terminates protocol flows. Note that NERC CIP-005-5 [NERC-CIP-005-5] requires inspection of protocols at the boundary of a security perimeter (the substation in this case). In addition, security management in substation automation assumes central support of different enrollment protocols to facilitate the capabilities of IEDs from different vendors. The IEC standard IEC62351-9 [IEC-62351-9] specifies the mandatory support of two enrollment protocols, SCEP [I-D.gutmann-scep] and EST [RFC7030] for the infrastructure side, while the IED must only support one of the two.

4.2.4. Electric vehicle charging infrastructure

For the electric vehicle charging infrastructure protocols have been defined for the interaction between the electric vehicle (EV) and the charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as between the charging point and the charging point operator (e.g. OCPP [OCPP]). Depending on the authentication model, unilateral or mutual authentication is required. In both cases the charging point authenticates uses an X.509 certificate to authenticate in the context of a TLS connection between the EV and the charging point. The management of this certificate depends (beyond others) on the selected backend connectivity protocol. Specifically in case of OCPP it is intended as single communication protocol between the charging point and the backend carrying all information to control the charging operations and maintain the charging point itself. This means that the certificate management is intended to be handled in-band of OCPP. This requires to be able to encapsulate the certificate management exchanges in a transport independent way. Self-containment will ease this by allowing the transport without a separate communication protocol. For the purpose of certificate management CMP [RFC4210]is intended to be used.

4.2.5. Infrastructure isolation policy

This refers to any case in which network infrastructure is normally isolated from the Internet as a matter of policy, most likely for security reasons. In such a case, limited access to external PKI resources will be allowed in carefully controlled short periods of time, for example when a batch of new devices are deployed, but impossible at other times.

4.2.6. Less operational security in the deployment domain

The registration point performing the authorization of a certificate request is a critical PKI component and therefore implicates higher operational security than other components utilizing the issued certificates for their security features. CAs may also demand higher security in the registration procedures. Especially the CA/Browser forum currently increases the security requirements in the certificate issuance procedures for publicly trusted certificates. There may be the situation that the deployment domain does not offer enough security to operate a registration point and therefore wants to transfer this service to a backend.

4.3. Requirement discussion and mapping to solution elements

For the requirements discussion it is assumed that the entity receiving the self-contained object in the deployment domain is not the authorization point for the certification request contained in the object. If the entity is the authorization point, BRSKI can be used directly. Note that BRSKI-AE could address both cases.

Based on the supported deployment environment described in Section 4.1 and the motivated application examples described in Section 4.2 the following base requirements are derived to support self-contained objects as container carrying the certification request and further information to support asynchronous operation. Moreover, potential solution examples (not complete) based on existing technology are provided with the focus on existing IETF standards track documents:

5. Architectural Overview

To support asynchronous enrollment, the base system architecture defined in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] is changed to allow for off-site operation of the PKI components. The assumption for BRSKI-AE is that the authorization for a certification request is performed using an inventory or asset management system residing in the backend of the domain operator as described in Section 4.1. This leads to changes in the placement or enhancements of the logical elements as shown in Figure 1.

   +--------------Drop Ship--------------->| Vendor Service         |
   |                                       +------------------------+
   |                                       | M anufacturer|         |
   |                                       | A uthorized  |Ownership|
   |                                       | S igning     |Tracker  |
   |                                       | A uthority   |         |
   |                                       +--------------+---------+
   |                                                      ^          
   |                                                      |    
   V                                                      |      
+--------+     .........................................  |         
|        |     .                                       .  |         
|        |     .  +------------+       +------------+  .  | BRSKI-        
|        |     .  |            |       |            |  .  | MASA        
| Pledge |     .  |   Join     |       | Domain     <-----+   
|        |     .  |   Proxy    |       | Registrar/ |  .    
|        <-------->............<-------> Proxy      |  .    
|        |     .  |        BRSKI-AE    |            |  .   
| IDevID |     .  |            |       +------^-----+  .    
|        |     .  +------------+              |        .   
|        |     .                              |        .   
+--------+     ...............................|.........   
                "on-site domain" components   |            
 . +---------------------------+     +--------v------------------+ .   
 . | Public Key Infrastructure |<----+ PKI RA                    | .
 . | PKI CA                    |---->+ [(Domain) Registrar (opt)]| .   
 . +---------------------------+     +--------+--^---------------+ .
 .                                            |  |                 .   
 .                                   +--------v--+---------------+ .
 .                                   | Inventory (Asset)         | .   
 .                                   | Management                | .
 .                                   +---------------------------+ .
         "off-site domain" components

Figure 1: Architecture overview of BRSKI-AE

The architecture overview in Figure 1 utilizes the same logical elements as BRSKI but with a different placement in the architecture for some of the elements. The main difference is the placement of the PKI RA/CA component, which is actually performing the authorization decision for the certification request message. Also shown is the connectivity of the RA/CA with an inventory management system, which is expected to be utilized in the authorization decision. Note that this may also be an integrated functionality of the RA. Both components are placed in the off-site domain of the operator (not the deployment site directly), which may have no or only temporary connectivity to the deployment domain of the pledge. This is to underline the authorization decision for the certification request in the backend rather than in the deployment domain itself. The following list describes the components in the deployment domain:

The following list describes the vendor related components/service outside the deployment domain:

The following list describes the operator related components/service operated in the backend:

5.1. Behavior of a pledge

The behavior of a pledge as described in [I-D.ietf-anima-bootstrapping-keyinfra] is kept with one exception. After finishing the imprinting phase (4) the enrollment phase (5) is performed with a method supporting self-contained objects. Using simpleenroll with EST as taken in BRSKI cannot be applied here, as it binds the pledge authentication with the existing IDevID using the transport channel. This authentication is not visible / verifiable at the authorization point in the off-site domain. /* mapping to existing protocols based on the outcome of the discussion */

5.2. Secure Imprinting using Vouchers

The described approach in [I-D.ietf-anima-bootstrapping-keyinfra] is kept as is.

5.3. Addressing

For the provisioning of different enrollment options at the domain registrar, the addressing approach of BRSKI using a "/.well-known" tree from [RFC5785] is enhanced.

/* to be done: Description of "/.well-known/enrollment-protocol/request" in which enrollment-protocol may be an already existing protocol like "est" or "scep" or "cmp" or "cms" or a newly defined protocol. */

6. Protocol Flows

Based on BRSKI and the architectural changes the original protocol flow is divided into three phases showing commonalities and differences to the original approach as depicted in the following.

6.1. Pledge - Registrar discovery and voucher exchange

The discovery phase is applied as specified in [I-D.ietf-anima-bootstrapping-keyinfra]. /* for discussion: is a reference to BRSKI sufficient here or is it helpful to provide additional information and the figure? */

+--------+         +---------+    +------------+     +------------+
| Pledge |         | Circuit |    | Domain     |     | Vendor     |
|        |         | Join    |    | Registrar  |     | Service    |
|        |         | Proxy   |    |  (JRC)     |     | (MASA)     |
+--------+         +---------+    +------------+     +------------+
  |                     |                   |           Internet |
  |<-RFC4862 IPv6 addr  |                   |                    |
  |<-RFC3927 IPv4 addr  | Appendix A        |  Legend            |
  |-------------------->|                   |  C - circuit       |
  | optional: mDNS query| Appendix B        |      join proxy    |
  | RFC6763/RFC6762     |                   |  P - provisional   |
  |<--------------------|                   |    TLS connection  |
  | GRASP M_FLOOD       |                   |                    |
  |   periodic broadcast|                   |                    |
  |<------------------->C<----------------->|                    |
  |              TLS via the Join Proxy     |                    |
  |<--Registrar TLS server authentication---|                    |
[PROVISIONAL accept of server cert]         |                    |
  P---X.509 client authentication---------->|                    |
  P                     |                   |                    |
  P--Voucher Request (w/nonce for voucher)->|                    |
  P                     |       /--->       |                    |
  P                     |       |      see Figure 3 below        |
  P                     |       \---->      |                    |
  P<------voucher---------------------------|                    |
[verify voucher, imprint]                   |                    |
  |---------------------------------------->|                    |
  |      [voucher status telemetry]         |<-device audit log--|
  |                     |       [verify audit log and voucher]   |
  |<--------------------------------------->|                    |

Figure 2: Pledge discovery of domain registrar discovery and voucher exchange

6.2. Registrar - MASA voucher exchange

The voucher exchange is performed as specified in [I-D.ietf-anima-bootstrapping-keyinfra]. /* for discussion: is a reference to BRSKI sufficient here or is it helpful to provide additional information and the figure? */

+--------+         +---------+    +------------+     +------------+
| Pledge |         | Circuit |    | Domain     |     | Vendor     |
|        |         | Join    |    | Registrar  |     | Service    |
|        |         | Proxy   |    |  (JRC)     |     | (MASA)     |
+--------+         +---------+    +------------+     +------------+
  P                     |       /--->       |                    |
  P                     |       |      [accept device in domain] |
  P                     |       |      [contact Vendor]          |
  P                     |       |           |--Pledge ID-------->|
  P                     |       |           |--Domain ID-------->|
  P                     |       |           |--optional:nonce--->|
  P                     |       |           |     [extract DomainID]
  P                     |    optional:      |     [update audit log]
  P                     |      can occur in advance if nonceless |  

Figure 3: Domain registrar - MASA voucher exchange

6.3. Pledge - Registrar - RA/CA certificate enrollment

The enrollment for BRSKI-AE will be performed using a self-contained object. According to the abstract requirements from [I-D.ietf-anima-bootstrapping-keyinfra]. This object shall at least contain the following information:

+--------+         +---------+    +------------+     +------------+
| Pledge |         | Circuit |    | Domain     |     | Operator   |
|        |         | Join    |    | Registrar  |     | RA/CA      |
|        |         | Proxy   |    |  (JRC)     |     | (OPKI)     |
+--------+         +---------+    +------------+     +------------+
  /-->                                      |                    |
  |---------- Request CA Certs ------------>|                    |
  |              [if connection to operator domain is available] |  
  |                                         |-Request CA Certs ->|
  |                                         |<- CA Certs Response|
  |<-------- CA Certs Response--------------|                    |
  |---------- Attribute Request ----------->|                    |
  |              [if connection to operator domain is available] |  
  |                                         |Attribute Request ->|
  |                                         |<-Attribute Response|
  |<--------- Attribute Response -----------|                    |
  /-->                                      |                    |
  |-------------- Cert Request ------------>|                    |
  |              [if connection to operator domain is available] |  
  |                                         |--- Cert Request -->|
  |                                         |<-- Cert Response --|
  /-->                                      |                    |
  |          [if connection to operator domain is not available] |  
  |                                         |                    |
  |<---------- Cert Waiting ----------------|                    |
  |-- Cert Polling (with orig request ID) ->|                    |
  |              [if connection to operator domain is available] |  
  |                                         |--- Cert Request -->|
  |                                         |<-- Cert Response --|
  /-->                                      |                    |
  |<------------- Cert Response ------------|                    |
  |-------------- Cert Confirm ------------>|                    |
  |                                         /-->                 |
  |                                         |[optional]          |
  |                                         |--- Cert Confirm -->|
  |                                         |<-- PKI Confirm ----|
  |<------------- PKI/Registrar Confirm ----|                    |

Figure 4: Certificate enrollment

The following list provides an abstract description of the flow depicted in Figure 4.

/* to be done: - investigation into handling of certificate request retries - message exchange description - confirmation message (necessary? optional? from Registrar and/or PKI?) */

7. Mapping to exisitng enrollment protocols

This sections maps the requirements and the approach described in Section 6.3 to already exisitng enrollment protocols.

7.1. EST Handling

When using the EST protocol [RFC7030], the following constrains should be observed:

7.2. CMP Handling

When using the CMP protocol [RFC4210], the following constrains should be observed:

8. IANA Considerations

This document requires the following IANA actions:

/* to be done: clarification necessary */

9. Privacy Considerations

/* to be done: clarification necessary */

10. Security Considerations

/* to be done: clarification necessary */

11. Acknowledgements

We would like to thank the various reviewers for their input, in particular Brian E. Carpenter, Giorgio Romanenghi, Oskar Camenzind for their input and discussion on use cases and call flows.

12. References

12.1. Normative References

[I-D.ietf-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Behringer, M., Bjarnason, S. and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Internet-Draft draft-ietf-anima-bootstrapping-keyinfra-22, June 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC7030] Pritikin, M., Yee, P. and D. Harkins, "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M. and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, May 2018.

12.2. Informative References

[I-D.gutmann-scep] Gutmann, P., "Simple Certificate Enrolment Protocol", Internet-Draft draft-gutmann-scep-14, June 2019.
[IEC-62351-9] International Electrotechnical Commission, "IEC 62351 - Power systems management and associated information exchange - Data and communications security - Part 9: Cyber security key management for power system equipment", IEC 62351-9 , May 2017.
[ISO-IEC-15118-2] International Standardization Organization / International Electrotechnical Commission, "ISO/IEC 15118-2 Road vehicles - Vehicle-to-Grid Communication Interface - Part 2: Network and application protocol requirements", ISO/IEC 15118 , April 2014.
[NERC-CIP-005-5] North American Reliability Council, "Cyber Security - Electronic Security Perimeter", CIP 005-5, December 2013.
[OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0", April 2018.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000.
[RFC4210] Adams, C., Farrell, S., Kause, T. and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, DOI 10.17487/RFC4210, September 2005.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010.

Authors' Addresses

Steffen Fries Siemens AG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany EMail: URI:
Hendrik Brockhaus Siemens AG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany EMail: URI:
Eliot Lear Cisco Systems Richtistrasse 7 Wallisellen, CH-8304 Switzerland Phone: +41 44 878 9200 EMail: