< draft-fries-anima-brski-async-enroll-00.txt   draft-fries-anima-brski-async-enroll-01.txt >
ANIMA WG S. Fries ANIMA WG S. Fries
Internet-Draft H. Brockhaus Internet-Draft H. Brockhaus
Intended status: Standards Track Siemens Intended status: Standards Track Siemens
Expires: September 12, 2019 E. Lear Expires: January 9, 2020 E. Lear
Cisco Systems Cisco Systems
March 11, 2019 July 8, 2019
Support of asynchronous Enrollment in BRSKI Support of asynchronous Enrollment in BRSKI
draft-fries-anima-brski-async-enroll-00 draft-fries-anima-brski-async-enroll-01
Abstract Abstract
This document discusses the enhancement of automated bootstrapping of This document discusses an enhancement of automated bootstrapping of
a remote secure key infrastructure (BRSKI) to operate in domains a remote secure key infrastructure (BRSKI) to operate in domains
featuring no or only timely limited connectivity to backend services featuring no or only timely limited connectivity to backend services
offering enrollment functionality like a Public Key Infrastructure offering enrollment functionality, specifically a Public Key
(PKI). In the context of deploying new devices the design of BRSKI Infrastructure (PKI). In the context of deploying new devices the
allows for online (synchronous object exchange) and offline design of BRSKI allows for online (synchronous object exchange) and
interactions (asynchronous object exchange) with a manufacturer's offline interactions (asynchronous object exchange) with a
authorization service. It utilizes a self-contained voucher to manufacturer's authorization service. For this it utilizes a self-
transport the domain credentials as a signed object to establish an contained voucher to transport the domain credentials as a signed
initial trust between the pledge and the deployment domain. The object to establish an initial trust between the pledge and the
currently supported enrollment protocol for request and distribution deployment domain. The currently supported enrollment protocol for
of deployment domain specific device certificates provides only request and distribution of deployment domain specific device
limited support for asynchronous PKI interactions. This memo certificates provides only limited support for asynchronous PKI
motivates support of self-contained objects also for certificate interactions. This memo motivates the enhancement of supporting
management by using an abstract notation to allow off-site operation self-contained objects for certificate management by using an
of PKI services, with only limited connectivity to the pledge abstract notation. This allows off-site operation of PKI services
deployment domain. This addresses specifically scenarios, in which outside the deployment domain of the pledge. This addresses
the deployment domain of a pledge does not perform the final specifically scenarios, in which the final authorization of
authorization of a certification request and rather delegates this certification request of a pledge cannot be made in the deployment
decision to an operator backend. The goal is to enable the usage of domain and is therefore delegated to a operator backend. The goal is
existing and potentially new PKI protocols supporting self- to enable the usage of existing and potentially new PKI protocols
containment for certificate management. supporting self-containment for certificate management.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. History of changes . . . . . . . . . . . . . . . . . . . . . 5
3. Scope of solution . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Supported environment . . . . . . . . . . . . . . . . . . 6 4. Scope of solution . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Application Examples . . . . . . . . . . . . . . . . . . 6 4.1. Supported environment . . . . . . . . . . . . . . . . . . 6
3.2.1. Rolling stock . . . . . . . . . . . . . . . . . . . . 6 4.2. Application Examples . . . . . . . . . . . . . . . . . . 7
3.2.2. Building automation . . . . . . . . . . . . . . . . . 7 4.2.1. Rolling stock . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Substation automation . . . . . . . . . . . . . . . . 7 4.2.2. Building automation . . . . . . . . . . . . . . . . . 7
3.2.4. Electric vehicle charging infrastructure . . . . . . 7 4.2.3. Substation automation . . . . . . . . . . . . . . . . 8
3.3. Requirements for asynchronous operation . . . . . . . . . 8 4.2.4. Electric vehicle charging infrastructure . . . . . . 8
4. Architectural Overview . . . . . . . . . . . . . . . . . . . 8 4.2.5. Infrastructure isolation policy . . . . . . . . . . . 8
4.1. Secure Imprinting using Vouchers . . . . . . . . . . . . 11 4.2.6. Less operational security in the deployment domain . 9
4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Requirement discussion and mapping to solution elements . 9
5. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Architectural Overview . . . . . . . . . . . . . . . . . . . 11
5.1. Pledge - Registrar discovery and voucher exchange . . . . 12 5.1. Behavior of a pledge . . . . . . . . . . . . . . . . . . 14
5.2. Registrar - MASA voucher exchange . . . . . . . . . . . . 14 5.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 14
5.3. Pledge - Registrar - RA/CA certificate enrollment . . . . 14 5.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 15
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 6.1. Pledge - Registrar discovery and voucher exchange . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6.2. Registrar - MASA voucher exchange . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Pledge - Registrar - RA/CA certificate enrollment . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Mapping to exisitng enrollment protocols . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 7.1. EST Handling . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 17 7.2. CMP Handling . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
BRSKI as defined in [I-D.ietf-anima-bootstrapping-keyinfra] specifies BRSKI as defined in [I-D.ietf-anima-bootstrapping-keyinfra] specifies
a solution for secure zero-touch (automated) bootstrapping of devices a solution for secure zero-touch (automated) bootstrapping of devices
(pledges) in a target deployment domain. This includes the discovery (pledges) in a target deployment domain. This includes the discovery
of network elements in the deployment domain, time synchronization, of network elements in the deployment domain, time synchronization,
and the exchange of security information necessary to adopt a pledge and the exchange of security information necessary to establish trust
as new network and application element. Security information about between a pledge and the domain and to adopt a pledge as new network
the deployment domain, specifically the deployment domain certificate and application element. Security information about the deployment
(domain root certificate), is exchanged utilizing vouchers as defined domain, specifically the deployment domain certificate (domain root
in [RFC8366]. These vouchers are self-contained objects, which may certificate), is exchanged utilizing vouchers as defined in
be provided online (synchronous) or offline (asynchronous) via the [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 domain registrar to the pledge and originate from a manufacturer's
authorization service (MASA). The manufacturer signed voucher authorization service (MASA). The manufacturer signed voucher
contains the target domain certificate and can be verified by the contains the target domain certificate and can be verified by the
pledge due to the possession of a manufacturer root certificate. It pledge due to the possession of a manufacturer root certificate. It
facilitates the enrollment of the pledge in the deployment domain and facilitates the enrollment of the pledge in the deployment domain and
is used to establish trust. is used to establish trust.
For the enrollment of devices BRSKI relies on EST [RFC7030] to For the enrollment of devices BRSKI relies on EST [RFC7030] to
request and distribute deployment domain specific device request and distribute deployment domain specific device
certificates. EST in turn relies on a binding of the certification certificates. EST in turn relies on a binding of the certification
request to an underlying TLS connection between the EST client and request to an underlying TLS connection between the EST client and
the EST server. The EST server is likely collocated with a the EST server. According to BRSKI the domain registrar acts as EST
registration authority (RA) or local registration authority (LRA). server and is also acting as registration authority (RA) or local
The binding to TLS is used to protect the exchange of a certification registration authority (LRA). The binding to TLS is used to protect
request (for an LDevID certificate) and to provide data origin the exchange of a certification request (for an LDevID certificate)
authentication to support the authorization decision for processing and to provide data origin authentication to support the
the certification request. The TLS connection is mutually authorization decision for processing the certification request. The
authenticated and the client side authentication bases on the TLS connection is mutually authenticated and the client side
pledge's manufacturer issued device certificate (IDevID certificate). authentication bases on the pledge's manufacturer issued device
This approach requires an on-site availability of a PKI component certificate (IDevID certificate). This approach requires an on-site
and/or a local asset or inventory management system performing the availability of the RA as PKI component and/or a local asset or
authorization decision to issue a domain specific certificate to the inventory management system performing the authorization decision
pledge. This is due to the fact that the EST server terminates the based on the certification request to issue a domain specific
security association with the pledge and thus the binding between the certificate to the pledge. This is due to the EST server terminating
certification request and the authentication of the pledge. the security association with the pledge and thus the binding between
Moreover, it may also require to setup a new security association the certification request and the authentication of the pledge. This
between the EST and the issuing RA/CA. This type of enrollment type of enrollment utilizing an online connection to the PKI is
utilizing an online connection to the PKI is considered as considered as synchronous enrollment.
synchronous enrollment.
For certain use cases on-site support of a RA/CA component and/or an 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 asset management is not available and rather provided by an operators
limited fashion or completely offline. This may be due to higher backend and may be provided timely limited or completely through
security requirements for the certification authority. This also offline interactions. This may be due to higher security
means that a PKI component, performing the authorization decision for requirements for operating the certification authority. The
a certification request from a pledge may not be available on-site at authorization of a certification request based on an asset management
enrollment time. Enrollment, which cannot be performed in a (timely) in this case will not / can not be performed on-site at enrollment
consistent fashion is considered as asynchronous enrollment in this time. Enrollment, which cannot be performed in a (timely) consistent
document. In this case a support of a store and forward fashion is considered as asynchronous enrollment in this document.
functionality of certification request together with the requester It requires the support of a store and forward functionality of
authentication information is necessary, to enable the processing of certification request together with the requester authentication
the request at a later point in time. A similar situation may occur information. This enables processing of the request at a later point
through network segmentation, which is utilized in industrial systems in time. A similar situation may occur through network segmentation,
to separate certain tasks. Here, a similar requirement arises if the 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 communication channel carrying the requester authentication is
terminated before the RA/CA. If a second communication channel is terminated before the RA/CA. If a second communication channel is
opened to forward the certification request to the issuing CA, the opened to forward the certification request to the issuing CA, the
requester authentication information needs to be bound to the requester authentication information needs to be bound to the
certification request. For both cases, it is assumed that the certification request. For both cases, it is assumed that the
requester authentication information is utilized in the process of requester authentication information is utilized in the process of
authorization of a certification request. There are different authorization of a certification request. There are different
options to perform store and forward of certification requests: options to perform store and forward of certification requests
including the requester authentication information:
o Providing a trusted component (e.g., an LRA) in the deployment o Providing a trusted component (e.g., an LRA) in the deployment
domain, which handles the storage of the certification request domain, which stores the certification request combined with the
combined with the requester authentication information (the requester authentication information (the IDevID) and potentially
IDevID) and potentially the information about a successful proof the information about a successful proof of possession (of the
of possession in a way prohibiting changes to the combined corresponding private key) in a way prohibiting changes to the
information. Note that the assumption is that the information combined information. Note that the assumption is that the
elements are not cryptographically bound together. Once the PKI information elements may not be cryptographically bound together.
functionality (RA/CA)) is available, the trusted component Once connectivity to the backend is available, the trusted
forwards the certification request together with the originator component forwards the certification request together with the
information and the information about the successful proof of requester information (authentication and proof of possesion) to
possession as triple to the off-site PKI for further processing. the off-site PKI for further processing. It is assumed that the
It is assumed that the off-site PKI in this case relies on the off-site PKI in this case relies on the local authentication
local authentication result and thus on the authorization and result and thus performs the authorization and issues the
issues the requested certificate. In BRSKI the trusted component requested certificate. In BRSKI the trusted component may be the
may be the EST server residing co-located with the registrar in EST server residing co-located with the registrar in the
the deployment domain. deployment domain.
o Utilization of a self-contained object for the certification o Utilization of self-contained objects binding the certification
request, which cryptographically binds the requester request and the requester authentication in a cryptographic way.
authentication information to the certification request. This This approach reduces the necessary trust in a domain component to
approach reduces the necessary trust in a domain component to storage and delivery. Unauthorized modifications of the requestor
storage and delivery. Unauthorized modifications can be detected information (request and authentication) can be detected during
during the verification of the cryptographic binding of the the verification of the cryptographic binding of the self-
certification request in the off-site PKI. contained object in the off-site PKI.
This document targets environments, in which connectivity to the PKI This document targets environments, in which connectivity to the PKI
functionality is only temporary or not directly available by functionality is only temporary or not directly available by
specifying support for handling asynchronous objects supporting specifying support for handling self-contained objects supporting
enrollment. As it is intended to enhance BRSKI it is named BRSKI-AE, asynchronous enrollment. As it is intended to enhance BRSKI it is
where AE stands for asynchronous enrollment. Note that BRSKI-AE is named BRSKI-AE, where AE stands for asynchronous enrollment. As
also intended to be applicable for synchronous enrollment, e.g., if a BRSKI, BRSKI-AE results in the pledge storing a X.509 root
connection carrying the requester authentication is terminated before certificate sufficient for verifying the domain registrar / proxy
the actual registration authority. identity as well as an domain specific X.509 device certificate
(LDevID certificate).
/* to be clarified: Describe as abstract type in Yang? */
The ultimate goal is to allow existing certificate management The goal is to enhance BRSKI to either allow other existing
protocols to be applied or to allow other types of encoding for the certificate management protocols supporting self-contained objects to
certificate management information exchange. 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 Note that in contrast to BRSKI, BRSKI-AE assumes support of multiple
enrollment protocols on the infrastructure side, allowing the pledge enrollment protocols on the infrastructure side, allowing the pledge
manufacturer to select the most appropriate. manufacturer to select the most appropriate. Thus, BRSKI-AE can be
applied for both, asynchronous and synchronous enrollment.
As BRSKI, BRSKI-AE results in the pledge storing a X.509 root domain 2. History of changes
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.
2. Terminology From version 00 -> 01:
o Update of examples, specifically for building automation as well
as two new application use cases in Section 4.2.
o Deletion of asynchronous interaction with MASA to not complicate
the use case. Note that the voucher exchange can already be
handled in an asynchronous manner and is therefore not considered
further. This resulted in removal of the alternative path the
MASA in Figure 1 and the associated description in Section 5.
o Enhancement of description of architecture elements and changes to
BRSKI in Section 5.
o Consideration of existing enrollment protocols in the context of
mapping the requirements to existing solutions in Section 4.3.
o New section starting Section 7 with the mapping to existing
enrollment protocols by collecting boundary conditions.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This document relies on the terminology defined in This document relies on the terminology defined in
[I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are
defined additionally: defined additionally:
skipping to change at page 6, line 6 skipping to change at page 6, line 31
LRA: Local registration authority, an optional RA system component LRA: Local registration authority, an optional RA system component
with proximity to end entities. with proximity to end entities.
IED: Intelligent Electronic Device (in essence a pledge). IED: Intelligent Electronic Device (in essence a pledge).
on-site: Describes a component or service or functionality available on-site: Describes a component or service or functionality available
in the target deployment domain. in the target deployment domain.
off-site: Describes a component or service or functionality off-site: Describes a component or service or functionality
available in a operator domain different from the target available in an operator domain different from the target
deployment domain. This may be a central side, to which only a deployment domain. This may be a central side, to which only a
temporarily connection is available or which is in a different temporarily connection is available or which is in a different
administrative domain. administrative domain.
asynchronous communication: Describes a timely interrupted asynchronous communication: Describes a timely interrupted
communication between an end entity and a PKI component. communication between an end entity and a PKI component.
synchronous communication: Describes a timely uninterrupted synchronous communication: Describes a timely uninterrupted
communication between an end entity and a PKI component. communication between an end entity and a PKI component.
3. Scope of solution 4. Scope of solution
3.1. Supported environment 4.1. Supported environment
This solution is intended to be used in environments with no or only This solution is intended to be used in domains with limited support
limited connectivity to backend services provided in the operator of on-site PKI services and comprises use cases in which:
domain. Beyond others this comprises cases in which:
o there is no registration authority available in the deployment o there is no registration authority available in the deployment
domain. The connectivity to the registration authority may only domain. The connectivity to the backend RA may only be
be temporarily available. A local store and forward device is temporarily available. A local store and forward device is used
used for the communication with the backend services. for the communication with the backend services.
o authoritive actions of a local registration authority are limited o authoritive actions of a LRA are limited and may not comprise
and may not comprise local authorization of certification requests authorization of certification requests of pledges. Final
of enrolling pledges. Final authorization is done at the authorization is done at the RA residing in the backend operator
registration authority residing in the operator domain. domain.
o the target deployment domain already uses a certificate management o the target deployment domain already uses a certificate management
approach that shall be kept consistent throughout the lifecycle. approach that shall be reused to be consistent throughout the
lifecycle.
3.2. Application Examples 4.2. Application Examples
The following examples are intended to motivate the support of The following examples are intended to motivate the support of
different enrollment approaches in general and asynchronous different enrollment approaches in general and asynchronous
enrollment specifically, by introducing industrial applications enrollment specifically, by introducing industrial applications
cases, which could leverage BRSKI as such but also require support of cases, which could leverage BRSKI as such but also require support of
asynchronous operation as intended with BRSKI-AE. asynchronous operation as intended with BRSKI-AE.
3.2.1. Rolling stock 4.2.1. Rolling stock
Rolling stock or railroad cars contain a variety of sensors, Rolling stock or railroad cars contain a variety of sensors,
actuators, and controller, which communicate within the railroad car actuators, and controller, which communicate within the railroad car
but also exchange information between railroad cars building a train but also exchange information between railroad cars building a train
or with a backend. These devices are typically unaware of backend or with a backend. These devices are typically unaware of backend
connectivity. Managing certificates may be done during maintenance connectivity. Managing certificates may be done during maintenance
cycles of the railroad car, but can already be prepared during cycles of the railroad car, but can already be prepared during
operation. The preparation may comprise the generation of operation. The preparation may comprise the generation of
certificate signing requests, to apply for a new or an updated domain certification requests by the components which are collected and
specific device certificate. The authorization of the certificate forwarded for processing once the railroad car is connected to the
signing request is done using inventory information available in the operator backend. The authorization of the certification request is
backend. then done based on the operators asset/inventory information.
/* to be done: more information to be provided */
3.2.2. Building automation
Detached building equipped with sensor, actuators, and controllers 4.2.2. Building automation
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 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.
3.2.3. Substation automation 4.2.3. Substation automation
In substation automation a control center typically hosts PKI In substation automation a control center typically hosts PKI
services to issue certificates for IEDs in a substation. services to issue certificates for Intelligent Electronic Devices
Communication between the substation and control center is typically (IED)s in a substation. Communication between the substation and
done through a proxy/gateway/DMZ, which terminates protocol flows. control center is done through a proxy/gateway/DMZ, which terminates
Note that NERC CIP (reference to be included) requires inspection of protocol flows. Note that NERC CIP-005-5 [NERC-CIP-005-5] requires
protocols at the boundary of a security perimeter. In addition, inspection of protocols at the boundary of a security perimeter (the
security in substation automation assumes central support of substation in this case). In addition, security management in
different enrollment protocols to facilitate the capabilities of IEDs substation automation assumes central support of different enrollment
from different vendors. The IEC standard IEC62351-9 [IEC-62351-9] protocols to facilitate the capabilities of IEDs from different
specifies the mandatory support of two enrollment protocols, SCEP 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, [I-D.gutmann-scep] and EST [RFC7030] for the infrastructure side,
while the IEDs must only support one of the two. while the IED must only support one of the two.
3.2.4. Electric vehicle charging infrastructure 4.2.4. Electric vehicle charging infrastructure
For the electric vehicle charging infrastructure protocols have been For the electric vehicle charging infrastructure protocols have been
defined for the interaction between the electric vehicle and the defined for the interaction between the electric vehicle (EV) and the
charging spot (e.g., ISO 15118 [ISO-IEC-15118-2]) as well as between charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as
the charging spot and the operator backend (e.g. OCPP [OCPP]). between the charging point and the charging point operator (e.g.
Depending on the charging model, unilateral or mutual authentication OCPP [OCPP]). Depending on the authentication model, unilateral or
is required. In both cases the charging spot authenticates using an mutual authentication is required. In both cases the charging point
X.509 certificate. The management of this certificate depends authenticates uses an X.509 certificate to authenticate in the
(beyond others) on the selected backend connectivity protocol. In context of a TLS connection between the EV and the charging point.
case of OCPP there is the desire to have a single communication The management of this certificate depends (beyond others) on the
protocol between the charging spot and the backend carrying all selected backend connectivity protocol. Specifically in case of OCPP
information to control and manage the charging operations and the it is intended as single communication protocol between the charging
charging spot itself. This means that the certificate management is point and the backend carrying all information to control the
intended to be handled in-band of OCPP. This requires to be able to charging operations and maintain the charging point itself. This
encapsulate the certificate management exchanges in a transport means that the certificate management is intended to be handled in-
independent way. Self-containment will ease this by allowing the band of OCPP. This requires to be able to encapsulate the
transport without a separate communication protocol. 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.
3.3. Requirements for asynchronous operation 4.2.5. Infrastructure isolation policy
Based on the supported environment described in Section 3.1 and the This refers to any case in which network infrastructure is normally
motivated application examples described in Section 3.2 the following isolated from the Internet as a matter of policy, most likely for
base requirements are derived: 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.
o Certificate management exchanges (e.g., certification request and 4.2.6. Less operational security in the deployment domain
certification response message(s)) are ideally carried in a
container protecting at least integrity of the exchanges and
providing source authentication. /* to be clarified: reference to
PKCS#10 or CRMF to be used? */
o The container with the certification request should provide a The registration point performing the authorization of a certificate
proof of possession of corresponding private key. Note: this is request is a critical PKI component and therefore implicates higher
typically provided by the existing enrollment protocols and is operational security than other components utilizing the issued
stated here for completeness if a different approach (encoding, certificates for their security features. CAs may also demand higher
transport) is desired. 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.
o The container with the certification request should support a 4.3. Requirement discussion and mapping to solution elements
cryptographic binding to an existing credential known to the
operator domain. /* to be clarified: reference to existing
enrollment protocols EST, CMC, CMP, SCEP to be used? */
o The container with the certification request should support direct For the requirements discussion it is assumed that the entity
protection using an existing credential on the pledge verifiable receiving the self-contained object in the deployment domain is not
in the operator domain. /* to be clarified: reference to CMS or the authorization point for the certification request contained in
CMP to be used? */ the object. If the entity is the authorization point, BRSKI can be
used directly. Note that BRSKI-AE could address both cases.
4. Architectural Overview 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:
The intended architecture for supporting asynchronous enrollment o Certification requests are structures protecting at least
relies architecture defined in BRSKI integrity of the contained data combined with a proof-of-private-
[I-D.ietf-anima-bootstrapping-keyinfra] with certain changes as shown key-possession for locally generated key pairs. Examples for
in the placement or enhancements of the logical elements in Figure 1. certification requests
* PKCS#10 [RFC2986]: Defines a structure for a certification
request. The structure must be signed to ensure integrity
protection and proof-of-private-key-possession. Hence, the
signature is performed by using the private key of the
requestor (corresponding to the contained public key).
* CRMF [RFC4211]: Defines a structure for the certification
request. The structure also typically contains an integrity
protection and a proof of possession, in which a signature
value is generated by using the corresponding private key to
the contained public key. This self-signature can also be
replaced by the RA after verification, if the RA intends to
update or alter the request message.
Note that the integrity is bound to the public key contained in
the certification request. In the considered application
examples, this is not sufficient and needs to be bound to the data
origin authentication (IDevID). This binding also supports the
authorization decision for the certification request. The binding
of data origin authentication to the certification request is
delegated to the management protocol.
o The container carrying the certification request should support a
binding to an existing credential known to the peer performing the
authoriation of the certification request as proof of identity.
The binding may be transport dependent if the endpoint at the next
communication hop is authorizing the certification request. This
requirements is addressed by existing enrollment protocols in
different ways, for instance:
* EST [RFC7030]: Utilizes PKCS#10 to encode the certification
request. The Certificate Signing Request (CSR) contains a
binding to the underlying TLS by including the tls-unique value
in the self-signed CSR structure. The tls-unique value is one
result of the TLS handshake. As the TLS handshake is performed
mutually authenticated and the pledge utilized its IDevID for
it, the proof of identity can be provided by the binding to the
TLS session.
* SCEP [I-D.gutmann-scep]: Provides the option to utilize either
an existing secret (password) or an existing certificate to
protect the CSR based on SCEP Secure Message Objects using CMS
([RFC5652]). Note that the wrapping using an existing IDevID
credential is not specified directly in SCEP.
* CMP [RFC4210] Provides the option to utilize either an existing
secret (password) or an existing certificate to protect the
PKIMessage containing the certification request. The
certification request is encoded utilizing CRMF. PKCS#10 is
optionally supported. The proof of identity of the PKIMessage
containing the certification request can be achieved by using
IDevID credentials to calculate a signature over the header and
the body of the PKIMessage utilizing the protectionAlg signaled
in the PKIMessage header and the PKIProtection carrying the
actual signature value.
* CMC [RFC5272] Provides the option to utilize either an existing
secret (password) or an existing certificate to protect the
certification request (either in CRMF or PKCS#10) based on CMS
[RFC5652]). Here a FullCMCRequest would be used, which allows
signing with an existing IDevID credential to provide a proof
of identity.
o The container carrying the certification request should support
transport independent protection using an existing credential of
the pledge verifiable at the authorization point of the
certification request (typically the RA in conjunction with an
inventory). This requirements is addressed by existing enrollment
protocols in different ways, for instance:
* EST [RFC7030]: Not supported.
* SCEP [I-D.gutmann-scep]: Not specified in SCEP, could be done
using message wrapping with signature (based on CMS).
* CMP [RFC4210]: Message wrapping with signature.
* CMC [RFC5272]: Message wrapping with signature.
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 | +--------------Drop Ship--------------->| Vendor Service |
| +------------------------+ | +------------------------+
| | M anufacturer| | | | M anufacturer| |
| | A uthorized |Ownership| | | A uthorized |Ownership|
| | S igning |Tracker | | | S igning |Tracker |
| | A uthority | | | | A uthority | |
| +--------------+---------+ | +--------------+---------+
| ^ | ^
| | | |
V | V |
+--------+ ......................................... | +--------+ ......................................... |
| | . . | | | . . |
| | . +------------+ +------------+ . | BRSKI- | | . +------------+ +------------+ . | BRSKI-
| | . | | | | . | MASA | | . | | | | . | MASA
| Pledge | . | Join | | Domain <-----+ | Pledge | . | Join | | Domain <-----+
| | . | Proxy | | Registrar/ | . ^ | | . | Proxy | | Registrar/ | .
| <-------->............<-------> Proxy | . ' | <-------->............<-------> Proxy | .
| | . | BRSKI-AE | | . | [alt.] | | . | BRSKI-AE | | .
| IDevID | . | | +------^-----+ . ' | IDevID | . | | +------^-----+ .
| | . +------------+ | . | | | . +------------+ | .
| | . | . ' | | . | .
+--------+ ...............................|......... | +--------+ ...............................|.........
"on-site domain" components | ' "on-site domain" components |
| | |
| ' |
.............................................|...........|......... .............................................|.....................
. +---------------------------+ +--------v-----------v------+ . . +---------------------------+ +--------v------------------+ .
. | Public Key Infrastructure |<----+ PKI RA | . . | Public Key Infrastructure |<----+ PKI RA | .
. | PKI CA |---->+ [(Domain) Registrar (opt)]| . . | PKI CA |---->+ [(Domain) Registrar (opt)]| .
. +---------------------------+ +--------+--^---------------+ . . +---------------------------+ +--------+--^---------------+ .
. | | . . | | .
. +--------v--+---------------+ . . +--------v--+---------------+ .
. | Inventory (Asset) | . . | Inventory (Asset) | .
. | Management | . . | Management | .
. +---------------------------+ . . +---------------------------+ .
................................................................... ...................................................................
"off-site domain" components "off-site domain" components
Figure 1: Architecture overview of BRSKI-AE Figure 1: Architecture overview of BRSKI-AE
The architecture overview in Figure 1 utilizes the same logical The architecture overview in Figure 1 utilizes the same logical
elements as BRSKI but with a different placement in the architecture elements as BRSKI but with a different placement in the architecture
for some of the elements in terms of connected domains. The main for some of the elements. The main difference is the placement of
difference is the placement of the PKI RA/CA component as well as the the PKI RA/CA component, which is actually performing the
connectivity of the RA/CA with an inventory management system. Both authorization decision for the certification request message. Also
are placed in the operator domain , which may have no or only shown is the connectivity of the RA/CA with an inventory management
temporary connectivity to the deployment domain of the pledge. Based system, which is expected to be utilized in the authorization
on the assumed connectivity of the deployment domain, the MASA decision. Note that this may also be an integrated functionality of
interaction may also be done asynchronous to the actual deployment the RA. Both components are placed in the off-site domain of the
domain. The following list describes the deployment domain operator (not the deployment site directly), which may have no or
components: 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:
o Join Proxy: same functionality as describe in BRSKI o Join Proxy: same functionality as described in BRSKI
o Domain Registrar / Proxy: In general the domain registrar / proxy o Domain Registrar / Proxy: In general the domain registrar / proxy
has a similar functionality regarding the imprinting of the pledge has a similar functionality regarding the imprinting of the pledge
in the deployment domain. Differences arise, if the deployment in the deployment domain to facilitate the communication of the
domain has temporary or no connectivity to an operator domain and/ pledge with the MASA and the PKI. Different is the authorization
or the manufacturers MASA. There may be use cases, in which the of the certification request. BRSKI-AE allows to perform this in
(domain) registrar may even be operated in the operator domain. the operators backend (off-site), even if the deployment domain
/* to do: needs more description */ has only temporary or no connectivity to an operator domain.
* Voucher exchange: The voucher exchange with the MASA is * Voucher exchange: The voucher exchange with the MASA via the
performed as described in BRSKI domain registrar is performed as described in BRSKI
[I-D.ietf-anima-bootstrapping-keyinfra] . If the voucher [I-D.ietf-anima-bootstrapping-keyinfra] .
exchange is facilitated by the operator domain, additional
description is necessary. In Figure 1 this is characterized by
indicating an alternative path for the voucher request/response
interaction.
* Certificate enrollment: For the pledge enrollment the domain * Certificate enrollment: For the pledge enrollment the domain
registrar in the deployment domain is expected to support the registrar in the deployment domain support the authorization of
authorization of the pledge to be part of the domain, but not the pledge to be part of the domain, but not necessarily to
necessarily to authorize the certification request provided authorize the certification request provided during enrollment.
during enrollment. This may be due to lack of authorization This may be due to lack of authorization information in the
information in the deployment domain. If the authorization is deployment domain. If the authorization is done in the
done in the operator domain, the domain registrar is used as operator domain, the domain registrar is used to forward the
store and forward component (or proxy) of the certification certification request to the RA. Thus it basically works as a
requests. To enable this, the domain registrar needs proxy. In the case of no connectivity, the domain registrar
functionality enhancements regarding the support of alternative stores the certification request and forwards it to the RA upon
connectivity. As this requires the certification request to be
self-contained, the domain registrar needs functionality
enhancements with respect to the support of alternative
enrollment approaches supporting self-containment. To support enrollment approaches supporting self-containment. To support
alternative enrollment approaches (protocols, encodings), it is alternative enrollment approaches (protocols, encodings), it is
necessary to enhance the addressing scheme at the domain necessary to enhance the addressing scheme at the domain
registrar. The communication channel between the pledge and registrar. The communication channel between the pledge and
the domain registrar may be similarly described within the same the domain registrar may be similarly described as in BRSKI
"/.well-known" tree and may result for instance in "/.well- within the same "/.well-known" tree and may result in "/.well-
known/enrollment-variant/request". known/enrollment-variant/request".
The following list describes the vendor related components/service The following list describes the vendor related components/service
outside the deployment domain: outside the deployment domain:
o MASA: general functionality as described in BRSKI. Assumption o MASA: general functionality as described in BRSKI. Assumption
that the interaction may be done synchronous and asynchronous that the interaction with the MASA may be synchronous (voucher
based on the general assumption that the deployment domain has request with nonce) or asynchronous (voucher request without
limited outside connectivity. Note: additional steps for offline nonce).
operation may need to be defined.
o Ownership tracker: as defined in BRSKI. o Ownership tracker: as defined in BRSKI.
The following list describes the operator related components/service The following list describes the operator related components/service
outside the deployment domain in the operator domain: operated in the backend:
o (Domain) registrar: Optional component if the deployment domain
does not feature a domain registrar but only a proxy. In this
case it is involved in the certification request processing and is
assumed to be co-located with the PKI RA. In addition, the
registrar may be involved in the voucher exchange with the MASA.
/* to be done: more elaboration necessary */
o PKI RA: Perform certificate management functions (validation of o PKI RA: Performs certificate management functions (validation of
certification requests, interaction with inventory/asset certification requests, interaction with inventory/asset
management for authorization, etc.) for issuing, updating, and management for authorization of certification requests, etc.) for
revoking certificates for a domain as a centralized infrastructure issuing, updating, and revoking certificates for a domain as a
for the operator. centralized infrastructure for the operator.
o PKI CA: Perform certificate generation by signing the certificate o PKI CA: Performs certificate generation by signing the certificate
structure management. structure provided in the certification request.
o Inventory (asset) management: contains information about the known o Inventory (asset) management: contains information about the known
devices belonging to the operator. Specifically, the inventory is devices belonging to the operator. Specifically, the inventory is
used to provide the information to authorize issuing a certificate used to provide the information to authorize issuing a certificate
based on the certification request of the pledge. Note: the based on the certification request of the pledge. Note: the
communication between the inventory (asset) management and the PKI communication between the inventory (asset) management and the PKI
components (RA/CA) in the operator domain are out of scope for components (RA/CA) are out of scope of this document.
this document.
4.1. Secure Imprinting using Vouchers o (Domain) registrar: Optional component if the deployment domain
does not feature a domain registrar but only a proxy. In this
case it is involved in the certification request processing and is
assumed to be co-located with the PKI RA.
/* to be done, should contain - review of the domain registrar - MASA 5.1. Behavior of a pledge
interaction regarding offline operation - changes to the enrollment
interaction through off-site RA/CA support */
4.2. Addressing 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 For the provisioning of different enrollment options at the domain
registrar, the addressing approach of BRSKI using a "/.well-known" registrar, the addressing approach of BRSKI using a "/.well-known"
tree from [RFC5785] is enhanced. tree from [RFC5785] is enhanced.
/* to be done: Description of "/.well-known/enrollment-protocol/ /* to be done: Description of "/.well-known/enrollment-protocol/
request" in which enrollment-protocol may be an already existing request" in which enrollment-protocol may be an already existing
protocol like "est" or "scep" or "cmp" or a newly defined protocol. protocol like "est" or "scep" or "cmp" or "cms" or a newly defined
*/ protocol. */
5. Protocol Flow 6. Protocol Flows
Based on BRSKI and the architectural changes the original protocol Based on BRSKI and the architectural changes the original protocol
flow is divided into three phases showing commonalities and flow is divided into three phases showing commonalities and
differences to the original approach as depicted in the following. differences to the original approach as depicted in the following.
o Discovery phase (same as BRSKI) o Discovery phase (same as BRSKI)
o Voucher exchange with deployment domain registrar (may have o Voucher exchange with deployment domain registrar (same as BRSKI).
changes due the handling of phases without communication to the
operator domain.
o Enrollment phase (changed to accompany the asynchronous operation) o Enrollment phase (changed to accompany the application of self-
contained objects for the enrollment).
5.1. Pledge - Registrar discovery and voucher exchange 6.1. Pledge - Registrar discovery and voucher exchange
/* to be done: description of unchanged BRSKI approach */ 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 | | Pledge | | Circuit | | Domain | | Vendor |
| | | Join | | Registrar | | Service | | | | Join | | Registrar | | Service |
| | | Proxy | | (JRC) | | (MASA) | | | | Proxy | | (JRC) | | (MASA) |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| | | Internet | | | | Internet |
|<-RFC4862 IPv6 addr | | | |<-RFC4862 IPv6 addr | | |
|<-RFC3927 IPv4 addr | Appendix A | Legend | |<-RFC3927 IPv4 addr | Appendix A | Legend |
|-------------------->| | C - circuit | |-------------------->| | C - circuit |
| optional: mDNS query| Appendix B | join proxy | | optional: mDNS query| Appendix B | join proxy |
| RFC6763/RFC6762 | | P - provisional | | RFC6763/RFC6762 | | P - provisional |
|<--------------------| | TLS connection | |<--------------------| | TLS connection |
| GRASP M_FLOOD | | | | GRASP M_FLOOD | | |
| periodic broadcast| | | | periodic broadcast| | |
|<------------------->C<----------------->| | |<------------------->C<----------------->| |
| TLS via the Join Proxy | | | TLS via the Join Proxy | |
|<--Registrar TLS server authentication---| | |<--Registrar TLS server authentication---| |
[PROVISIONAL accept of server cert] | | [PROVISIONAL accept of server cert] | |
P---X.509 client authentication---------->| | P---X.509 client authentication---------->| |
P | | | P | | |
P---Voucher Request (include nonce)------>| | P--Voucher Request (w/nonce for voucher)->| |
/--> | |
P [if connection to operator domain is not available] |
P<---------- Voucher Waiting -------------| |
P | | |
P- Voucher Polling (with serial number) ->| |
/--> | | |
P | /---> | | P | /---> | |
P | | see Figure 3 below | P | | see Figure 3 below |
P | \----> | | P | \----> | |
P<------voucher---------------------------| | P<------voucher---------------------------| |
[verify voucher , verify provisional cert] | | [verify voucher, imprint] | |
|---------------------------------------->| | |---------------------------------------->| |
| [voucher status telemetry] |<-device audit log--| | [voucher status telemetry] |<-device audit log--|
| | [verify audit log and voucher] | | | [verify audit log and voucher] |
|<--------------------------------------->| | |<--------------------------------------->| |
Figure 2: Pledge discovery of domain registrar discovery and voucher Figure 2: Pledge discovery of domain registrar discovery and voucher
exchange exchange
/* to be done: - discuss call flow in the context of asynchronous 6.2. Registrar - MASA voucher exchange
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 */
5.2. Registrar - MASA voucher exchange
/* 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 */
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 | | Pledge | | Circuit | | Domain | | Vendor |
| | | Join | | Registrar | | Service | | | | Join | | Registrar | | Service |
| | | Proxy | | (JRC) | | (MASA) | | | | Proxy | | (JRC) | | (MASA) |
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
P | /---> | | P | /---> | |
P | | [accept device in domain] | P | | [accept device in domain] |
P | | [contact Vendor] | P | | [contact Vendor] |
P | | |--Pledge ID-------->| P | | |--Pledge ID-------->|
P | | |--Domain ID-------->| P | | |--Domain ID-------->|
P | | |--optional:nonce--->| P | | |--optional:nonce--->|
P | | | [extract DomainID] P | | | [extract DomainID]
P | optional: | [update audit log] P | optional: | [update audit log]
P | can occur in advance if nonceless | P | can occur in advance if nonceless |
Figure 3: Domain registrar - MASA voucher exchange Figure 3: Domain registrar - MASA voucher exchange
5.3. Pledge - Registrar - RA/CA certificate enrollment 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:
o Proof of Possession: utilizing the private key corresponding to
the public key contained in the certification request.
o Proof of Identity: utilizing the existing IDevID credential to
generate a signature of the certification request.
o /* further parameter to be specified */.
/* to be done: overview description of operation */
+--------+ +---------+ +------------+ +------------+ +--------+ +---------+ +------------+ +------------+
| Pledge | | Circuit | | Domain | | Operator | | Pledge | | Circuit | | Domain | | Operator |
| | | Join | | Registrar | | RA/CA | | | | Join | | Registrar | | RA/CA |
| | | Proxy | | (JRC) | | (OPKI) | | | | 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 ------------>| | |-------------- Cert Request ------------>| |
| [if connection to operator domain is available] | | [if connection to operator domain is available] |
| |--- Cert Request -->| | |--- Cert Request -->|
| |<-- Cert Response --| | |<-- Cert Response --|
/--> | | /--> | |
| [if connection to operator domain is not available] | | [if connection to operator domain is not available] |
| | | | | |
|<---------- Cert Waiting ----------------| | |<---------- Cert Waiting ----------------| |
|-- Cert Polling (with orig request ID) ->| | |-- Cert Polling (with orig request ID) ->| |
| [if connection to operator domain is available] | | [if connection to operator domain is available] |
skipping to change at page 15, line 32 skipping to change at page 18, line 45
|<------------- Cert Response ------------| | |<------------- Cert Response ------------| |
|-------------- Cert Confirm ------------>| | |-------------- Cert Confirm ------------>| |
| /--> | | /--> |
| |[optional] | | |[optional] |
| |--- Cert Confirm -->| | |--- Cert Confirm -->|
| |<-- PKI Confirm ----| | |<-- PKI Confirm ----|
|<------------- PKI/Registrar Confirm ----| | |<------------- PKI/Registrar Confirm ----| |
Figure 4: Certificate enrollment Figure 4: Certificate enrollment
The following list provides an abstract description of the flow
depicted in Figure 4.
o CA Cert Request: The pledge SHOULD request the full distribution
of CA Certificates message. This ensures that the pledge has the
complete set of current CA certificates beyond the pinned-domain-
cert.
o Attribute Request: Typically, the automated bootstrapping occurs
without local administrative configuration of the pledge.
Nevertheless, there are cases, in which the pledge should also
include additional attributes specific to the deployment domain
into the certification request. To get these attributes in
advance, the attribute request SHOULD be used.
o Cert Request: certification request message (to be done: reference o Cert Request: certification request message (to be done: reference
to PKCS#10 or CRMF, proof of possession, pledge authentication) to PKCS#10 or CRMF, proof of possession, pledge authentication)
o Cert Response: certification response message containing the o Cert Response: certification response message containing the
requested certificate and potentially further information like requested certificate and potentially further information like
certificates of intermediary CAs on the certification path. certificates of intermediary CAs on the certification path.
o Cert Waiting: waiting indication for the pledge to retry after a o Cert Waiting: waiting indication for the pledge to retry after a
given time. given time. For this a request identifier is necessary. This
request identifier may bei either part of the enrollment protocol
or build based on the certification request.
o Cert Poling: querying the registrar, if the certificate request o Cert Poling: querying the registrar, if the certificate request
was already processed; can be answered either with another Cert was already processed; can be answered either with another Cert
Waiting, or a Cert Response. Waiting, or a Cert Response.
o Cert Confirm: confirmation message from pledge after receiving and o Cert Confirm: confirmation message from pledge after receiving and
verifying the certificate. verifying the certificate.
o PKI/Registrar Confirm: confirmation message from PKI/registrar o PKI/Registrar Confirm: confirmation message from PKI/registrar
about reception of the pledge's certificate confirmation. about reception of the pledge's certificate confirmation.
/* to be done: - investigation into handling of certificate request /* to be done: - investigation into handling of certificate request
retries - message exchange description - confirmation message retries - message exchange description - confirmation message
(necessary? optional? from Registrar and/or PKI?) */ (necessary? optional? from Registrar and/or PKI?) */
6. IANA Considerations 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:
o Proof of possession is provided by using the specified PKCS #10
structure in the request method.
o For proof of identit only the /fullcmc endpoint should be used
with a fullcmc request. This contains sufficient information for
the RA/CA to make an authorization decision on the received
certification request. Note that EST references CMC [RFC5272] for
the definition of the full PKI request. For proof of identity,
the signature of the SignedData of the Full PKI Request would be
calculated using the IDEVID credential of the pledge. /*TBD: in
this case the binding to the underlying TLS connection may not be
necessary */
o When the CA/CA is not available, as per [RFC7030] Section 4.2.3, a
202 return code should be returned by the Join Registrar. The
pledge in this case would retry with the same PKCS#10 request as
in the initial simpleentroll run. Note that if the TLS connection
is teared down for the waiting time, the PKCS#10 request would
need to be rebuild as it contains the unique identifier
(tls_unique) from the underlying TLS connection for the binding.
7.2. CMP Handling
When using the CMP protocol [RFC4210], the following constrains
should be observed:
o For proof of posession, the defined approach in CMP [RFC4210]
section 4.3 should be supported. This can be achieved by using
either CRMF or PKCS#10 to specify the certification request.
o Proof of identity can be provided by using the MSG_SIG_ALG to
protect the certificate request message with signatures as
outlined in section D.5.
o When the CA/CA is not available, as per [RFC4210] Section 5.2.3, a
waiting indication should be returned in the PKIStatus by the Join
Registrar. The pledge in this case would retry using the
PollReqContent with a request identifier certReqId provided in the
initial CertRequest message as specified in section 5.3.22.
8. IANA Considerations
This document requires the following IANA actions: This document requires the following IANA actions:
/* to be done: clarification necessary */ /* to be done: clarification necessary */
7. Privacy Considerations 9. Privacy Considerations
/* to be done: clarification necessary */ /* to be done: clarification necessary */
8. Security Considerations 10. Security Considerations
/* to be done: clarification necessary */ /* to be done: clarification necessary */
9. Acknowledgements 11. Acknowledgements
We would like to thank the various reviewers for their input, in We would like to thank the various reviewers for their input, in
particular ... particular Brian E. Carpenter, Giorgio Romanenghi, Oskar Camenzind
for their input and discussion on use cases and call flows.
10. References 12. References
10.1. Normative References 12.1. Normative References
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-19 (work in progress), March 2019. keyinfra-22 (work in progress), June 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
10.2. Informative References 12.2. Informative References
[I-D.gutmann-scep] [I-D.gutmann-scep]
Gutmann, P., "Simple Certificate Enrolment Protocol", Gutmann, P., "Simple Certificate Enrolment Protocol",
draft-gutmann-scep-13 (work in progress), January 2019. draft-gutmann-scep-14 (work in progress), June 2019.
[IEC-62351-9] [IEC-62351-9]
International Electrotechnical Commission, "IEC 62351 - International Electrotechnical Commission, "IEC 62351 -
Power systems management and associated information Power systems management and associated information
exchange - Data and communications security - Part 9: exchange - Data and communications security - Part 9:
Cyber security key management for power system equipment", Cyber security key management for power system equipment",
IEC 62351-9 , May 2017. IEC 62351-9 , May 2017.
[ISO-IEC-15118-2] [ISO-IEC-15118-2]
International Standardization Organization / International International Standardization Organization / International
Electrotechnical Commission, "ISO/IEC 15118-2 Road Electrotechnical Commission, "ISO/IEC 15118-2 Road
vehicles - Vehicle-to-Grid Communication Interface - Part vehicles - Vehicle-to-Grid Communication Interface - Part
2: Network and application protocol requirements", ISO/ 2: Network and application protocol requirements", ISO/
IEC 15118 , April 2014. 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", [OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0",
April 2018. 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,
<https://www.rfc-editor.org/info/rfc2986>.
[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,
<https://www.rfc-editor.org/info/rfc4210>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/info/rfc4211>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/info/rfc5272>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>. <https://www.rfc-editor.org/info/rfc5785>.
Authors' Addresses Authors' Addresses
Steffen Fries Steffen Fries
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: steffen.fries@siemens.com Email: steffen.fries@siemens.com
URI: http://www.siemens.com/ URI: http://www.siemens.com/
Hendrik Brockhaus Hendrik Brockhaus
 End of changes. 87 change blocks. 
329 lines changed or deleted 573 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/