| ANIMA WG | S. Fries |
| Internet-Draft | H. Brockhaus |
| Intended status: Standards Track | Siemens |
| Expires: September 12, 2019 | E. Lear |
| Cisco Systems | |
| March 11, 2019 |
Support of asynchronous Enrollment in BRSKI
draft-fries-anima-brski-async-enroll-00
This document discusses the 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 like 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. 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 support of self-contained objects also for certificate management by using an abstract notation to allow off-site operation of PKI services, with only limited connectivity to the pledge deployment domain. This addresses specifically scenarios, in which the deployment domain of a pledge does not perform the final authorization of a certification request and rather delegates this decision to an operator backend. The goal is to enable the usage of existing and potentially new PKI protocols supporting self-containment for certificate management.
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 https://datatracker.ietf.org/drafts/current/.
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 September 12, 2019.
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 (https://trustee.ietf.org/license-info) 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.
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 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. The EST server is likely collocated with a 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 a PKI component and/or a local asset or inventory management system performing the authorization decision to issue a domain specific certificate to the pledge. This is due to the fact that the EST server terminates the security association with the pledge and thus the binding between the certification request and the authentication of the pledge. Moreover, it may also require to setup a new security association between the EST and the issuing RA/CA. 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 in a timely limited fashion or completely offline. This may be due to higher security requirements for the certification authority. This also means that a PKI component, performing the authorization decision for a certification request from a pledge may not be available on-site at enrollment time. Enrollment, which cannot be performed in a (timely) consistent fashion is considered as asynchronous enrollment in this document. In this case a support of a store and forward functionality of certification request together with the requester authentication information is necessary, to enable the 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 certain tasks. 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:
This document targets environments, in which connectivity to the PKI functionality is only temporary or not directly available by specifying support for handling asynchronous objects supporting enrollment. As it is intended to enhance BRSKI it is named BRSKI-AE, where AE stands for asynchronous enrollment. Note that BRSKI-AE is also intended to be applicable for synchronous enrollment, e.g., if a connection carrying the requester authentication is terminated before the actual registration authority.
/* to be clarified: Describe as abstract type in Yang? */
The ultimate goal is to allow existing certificate management protocols 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.
As BRSKI, BRSKI-AE results in the pledge storing a X.509 root domain certificate sufficient for verifying the domain registrar / proxy identity. In the process a TLS connection is established that can be directly used for certification request/response exchanges. The certification request may be stored on the domain registrar / proxy until connectivity to the PKI (issuing CA) becomes available. With this, BRSKI-AE supports the automated mechanism for asynchronous enrollment of a pledge in a deployment domain utilizing a voucher of the pledge manufacturer resulting in a domain specific X.509 device certificate (LDevID certificate) available on the pledge.
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:
This solution is intended to be used in environments with no or only limited connectivity to backend services provided in the operator domain. Beyond others this comprises cases in which:
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.
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 certificate signing requests, to apply for a new or an updated domain specific device certificate. The authorization of the certificate signing request is done using inventory information available in the backend.
/* to be done: more information to be provided */
Detached building equipped with sensor, actuators, and controllers connected to centralized building management system. Limited/no connectivity to backend during the installation phase and even later. (Example: School, etc.)
/* to be done: more information to be provided */
In substation automation a control center typically hosts PKI services to issue certificates for IEDs in a substation. Communication between the substation and control center is typically done through a proxy/gateway/DMZ, which terminates protocol flows. Note that NERC CIP (reference to be included) requires inspection of protocols at the boundary of a security perimeter. In addition, security 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 IEDs must only support one of the two.
For the electric vehicle charging infrastructure protocols have been defined for the interaction between the electric vehicle and the charging spot (e.g., ISO 15118 [ISO-IEC-15118-2]) as well as between the charging spot and the operator backend (e.g. OCPP [OCPP]). Depending on the charging model, unilateral or mutual authentication is required. In both cases the charging spot authenticates using an X.509 certificate. The management of this certificate depends (beyond others) on the selected backend connectivity protocol. In case of OCPP there is the desire to have a single communication protocol between the charging spot and the backend carrying all information to control and manage the charging operations and the charging spot 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.
Based on the supported environment described in Section 3.1 and the motivated application examples described in Section 3.2 the following base requirements are derived:
The intended architecture for supporting asynchronous enrollment relies architecture defined in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] with certain changes as shown in the placement or enhancements of the logical elements 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 | | . | [alt.]
| IDevID | . | | +------^-----+ . '
| | . +------------+ | . |
| | . | . '
+--------+ ...............................|......... |
"on-site domain" components | '
| |
| '
.............................................|...........|.........
. +---------------------------+ +--------v-----------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 in terms of connected domains. The main difference is the placement of the PKI RA/CA component as well as the connectivity of the RA/CA with an inventory management system. Both are placed in the operator domain , which may have no or only temporary connectivity to the deployment domain of the pledge. Based on the assumed connectivity of the deployment domain, the MASA interaction may also be done asynchronous to the actual deployment domain. The following list describes the deployment domain components:
The following list describes the vendor related components/service outside the deployment domain:
The following list describes the operator related components/service outside the deployment domain in the operator domain:
/* to be done, should contain - review of the domain registrar - MASA interaction regarding offline operation - changes to the enrollment interaction through off-site RA/CA support */
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 a newly defined protocol. */
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.
/* to be done: description of unchanged BRSKI approach */
+--------+ +---------+ +------------+ +------------+ | 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 (include nonce)------>| | /--> | | P [if connection to operator domain is not available] | P<---------- Voucher Waiting -------------| | P | | | P- Voucher Polling (with serial number) ->| | /--> | | | P | /---> | | P | | see Figure 3 below | P | \----> | | P<------voucher---------------------------| | [verify voucher , verify provisional cert] | | |---------------------------------------->| | | [voucher status telemetry] |<-device audit log--| | | [verify audit log and voucher] | |<--------------------------------------->| |
Figure 2: Pledge discovery of domain registrar discovery and voucher exchange
/* to be done: - discuss call flow in the context of asynchronous operation, when the domain registrar works as proxy. The voucher waiting indication can be used in this way to inform the pledge not to expect an immediate response (may contain the time for the polling) - may utilize a parallel provisioning of a voucher request and a certification request by the pledge. - both may be provided when the operator domain is available and processed sequentially by the pledge, first the voucher, second the certification response */
/* to be done: - clarification if BRSKI protocol sequence kept unchanged - changes for complete offline operation may be necessary, verify BRSKI document section 6.2. Pledge security reductions */
+--------+ +---------+ +------------+ +------------+ | 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
/* to be done: overview description of operation */
+--------+ +---------+ +------------+ +------------+ | Pledge | | Circuit | | Domain | | Operator | | | | Join | | Registrar | | RA/CA | | | | Proxy | | (JRC) | | (OPKI) | +--------+ +---------+ +------------+ +------------+ |-------------- 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
/* to be done: - investigation into handling of certificate request retries - message exchange description - confirmation message (necessary? optional? from Registrar and/or PKI?) */
This document requires the following IANA actions:
/* to be done: clarification necessary */
/* to be done: clarification necessary */
/* to be done: clarification necessary */
We would like to thank the various reviewers for their input, in particular ...
| [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-19, March 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. |
| [I-D.gutmann-scep] | Gutmann, P., "Simple Certificate Enrolment Protocol", Internet-Draft draft-gutmann-scep-13, January 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. |
| [OCPP] | Open Charge Alliance, "Open Charge Point Protocol 2.0", April 2018. |
| [RFC5785] | Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010. |