Support of asynchronous Enrollment in BRSKI
draft-fries-anima-brski-async-enroll-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Steffen Fries , Hendrik Brockhaus , Eliot Lear | ||
| Last updated | 2019-03-11 | ||
| Replaced by | draft-ietf-anima-brski-async-enroll, draft-ietf-anima-brski-async-enroll, draft-ietf-anima-brski-async-enroll | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-fries-anima-brski-async-enroll-00
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
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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
Fries, et al. Expires September 12, 2019 [Page 1]
Internet-Draft BRSKI-AE March 2019
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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope of solution . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Supported environment . . . . . . . . . . . . . . . . . . 6
3.2. Application Examples . . . . . . . . . . . . . . . . . . 6
3.2.1. Rolling stock . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Building automation . . . . . . . . . . . . . . . . . 7
3.2.3. Substation automation . . . . . . . . . . . . . . . . 7
3.2.4. Electric vehicle charging infrastructure . . . . . . 7
3.3. Requirements for asynchronous operation . . . . . . . . . 8
4. Architectural Overview . . . . . . . . . . . . . . . . . . . 8
4.1. Secure Imprinting using Vouchers . . . . . . . . . . . . 11
4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 11
5. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Pledge - Registrar discovery and voucher exchange . . . . 12
5.2. Registrar - MASA voucher exchange . . . . . . . . . . . . 14
5.3. Pledge - Registrar - RA/CA certificate enrollment . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Fries, et al. Expires September 12, 2019 [Page 2]
Internet-Draft BRSKI-AE March 2019
1. Introduction
BRSKI as defined in [I-D.ietf-anima-bootstrapping-keyinfra] specifies
a solution for secure zero-touch (automated) bootstrapping of devices
(pledges) in a target deployment domain. This includes the discovery
of network elements in the deployment domain, time synchronization,
and the exchange of security information necessary to 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
Fries, et al. Expires September 12, 2019 [Page 3]
Internet-Draft BRSKI-AE March 2019
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:
o Providing a trusted component (e.g., an LRA) in the deployment
domain, which handles the storage of the certification request
combined with the requester authentication information (the
IDevID) and potentially the information about a successful proof
of possession in a way prohibiting changes to the combined
information. Note that the assumption is that the information
elements are not cryptographically bound together. Once the PKI
functionality (RA/CA)) is available, the trusted component
forwards the certification request together with the originator
information and the information about the successful proof of
possession as triple to the off-site PKI for further processing.
It is assumed that the off-site PKI in this case relies on the
local authentication result and thus on the authorization and
issues the requested certificate. In BRSKI the trusted component
may be the EST server residing co-located with the registrar in
the deployment domain.
o Utilization of a self-contained object for the certification
request, which cryptographically binds the requester
authentication information to the certification request. This
approach reduces the necessary trust in a domain component to
storage and delivery. Unauthorized modifications can be detected
during the verification of the cryptographic binding of the
certification request in the off-site PKI.
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
Fries, et al. Expires September 12, 2019 [Page 4]
Internet-Draft BRSKI-AE March 2019
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.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
This document relies on the terminology defined in
[I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are
defined additionally:
CA: Certification authority, issues certificates.
RA: Registration authority, an optional system component to which a
CA delegates certificate management functions such as
authorization checks.
LRA: Local registration authority, an optional RA system component
with proximity to end entities.
IED: Intelligent Electronic Device (in essence a pledge).
on-site: Describes a component or service or functionality available
in the target deployment domain.
Fries, et al. Expires September 12, 2019 [Page 5]
Internet-Draft BRSKI-AE March 2019
off-site: Describes a component or service or functionality
available in a operator domain different from the target
deployment domain. This may be a central side, to which only a
temporarily connection is available or which is in a different
administrative domain.
asynchronous communication: Describes a timely interrupted
communication between an end entity and a PKI component.
synchronous communication: Describes a timely uninterrupted
communication between an end entity and a PKI component.
3. Scope of solution
3.1. Supported environment
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:
o there is no registration authority available in the deployment
domain. The connectivity to the registration authority may only
be temporarily available. A local store and forward device is
used for the communication with the backend services.
o authoritive actions of a local registration authority are limited
and may not comprise local authorization of certification requests
of enrolling pledges. Final authorization is done at the
registration authority residing in the operator domain.
o the target deployment domain already uses a certificate management
approach that shall be kept consistent throughout the lifecycle.
3.2. Application Examples
The following examples are intended to motivate the support of
different enrollment approaches in general and asynchronous
enrollment specifically, by introducing industrial applications
cases, which could leverage BRSKI as such but also require support of
asynchronous operation as intended with BRSKI-AE.
3.2.1. Rolling stock
Rolling stock or railroad cars contain a variety of sensors,
actuators, and controller, which communicate within the railroad car
but also exchange information between railroad cars building a train
or with a backend. These devices are typically unaware of backend
connectivity. Managing certificates may be done during maintenance
Fries, et al. Expires September 12, 2019 [Page 6]
Internet-Draft BRSKI-AE March 2019
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 */
3.2.2. Building automation
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 */
3.2.3. Substation automation
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.
3.2.4. Electric vehicle charging infrastructure
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
Fries, et al. Expires September 12, 2019 [Page 7]
Internet-Draft BRSKI-AE March 2019
encapsulate the certificate management exchanges in a transport
independent way. Self-containment will ease this by allowing the
transport without a separate communication protocol.
3.3. Requirements for asynchronous operation
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:
o Certificate management exchanges (e.g., certification request and
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
proof of possession of corresponding private key. Note: this is
typically provided by the existing enrollment protocols and is
stated here for completeness if a different approach (encoding,
transport) is desired.
o The container with the certification request should support a
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
protection using an existing credential on the pledge verifiable
in the operator domain. /* to be clarified: reference to CMS or
CMP to be used? */
4. Architectural Overview
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.
Fries, et al. Expires September 12, 2019 [Page 8]
Internet-Draft BRSKI-AE March 2019
+------------------------+
+--------------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
Fries, et al. Expires September 12, 2019 [Page 9]
Internet-Draft BRSKI-AE March 2019
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:
o Join Proxy: same functionality as describe in BRSKI
o Domain Registrar / Proxy: In general the domain registrar / proxy
has a similar functionality regarding the imprinting of the pledge
in the deployment domain. Differences arise, if the deployment
domain has temporary or no connectivity to an operator domain and/
or the manufacturers MASA. There may be use cases, in which the
(domain) registrar may even be operated in the operator domain.
/* to do: needs more description */
* Voucher exchange: The voucher exchange with the MASA is
performed as described in BRSKI
[I-D.ietf-anima-bootstrapping-keyinfra] . If the voucher
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
registrar in the deployment domain is expected to support the
authorization of the pledge to be part of the domain, but not
necessarily to authorize the certification request provided
during enrollment. This may be due to lack of authorization
information in the deployment domain. If the authorization is
done in the operator domain, the domain registrar is used as
store and forward component (or proxy) of the certification
requests. To enable this, the domain registrar needs
functionality enhancements regarding the support of alternative
enrollment approaches supporting self-containment. To support
alternative enrollment approaches (protocols, encodings), it is
necessary to enhance the addressing scheme at the domain
registrar. The communication channel between the pledge and
the domain registrar may be similarly described within the same
"/.well-known" tree and may result for instance in "/.well-
known/enrollment-variant/request".
The following list describes the vendor related components/service
outside the deployment domain:
o MASA: general functionality as described in BRSKI. Assumption
that the interaction may be done synchronous and asynchronous
based on the general assumption that the deployment domain has
Fries, et al. Expires September 12, 2019 [Page 10]
Internet-Draft BRSKI-AE March 2019
limited outside connectivity. Note: additional steps for offline
operation may need to be defined.
o Ownership tracker: as defined in BRSKI.
The following list describes the operator related components/service
outside the deployment domain in the operator domain:
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
certification requests, interaction with inventory/asset
management for authorization, etc.) for issuing, updating, and
revoking certificates for a domain as a centralized infrastructure
for the operator.
o PKI CA: Perform certificate generation by signing the certificate
structure management.
o Inventory (asset) management: contains information about the known
devices belonging to the operator. Specifically, the inventory is
used to provide the information to authorize issuing a certificate
based on the certification request of the pledge. Note: the
communication between the inventory (asset) management and the PKI
components (RA/CA) in the operator domain are out of scope for
this document.
4.1. Secure Imprinting using Vouchers
/* 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 */
4.2. Addressing
For the provisioning of different enrollment options at the domain
registrar, the addressing approach of BRSKI using a "/.well-known"
tree from [RFC5785] is enhanced.
/* to be done: Description of "/.well-known/enrollment-protocol/
request" in which enrollment-protocol may be an already existing
protocol like "est" or "scep" or "cmp" or a newly defined protocol.
*/
Fries, et al. Expires September 12, 2019 [Page 11]
Internet-Draft BRSKI-AE March 2019
5. Protocol Flow
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.
o Discovery phase (same as BRSKI)
o Voucher exchange with deployment domain registrar (may have
changes due the handling of phases without communication to the
operator domain.
o Enrollment phase (changed to accompany the asynchronous operation)
5.1. Pledge - Registrar discovery and voucher exchange
/* to be done: description of unchanged BRSKI approach */
Fries, et al. Expires September 12, 2019 [Page 12]
Internet-Draft BRSKI-AE March 2019
+--------+ +---------+ +------------+ +------------+
| 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
Fries, et al. Expires September 12, 2019 [Page 13]
Internet-Draft BRSKI-AE March 2019
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 */
+--------+ +---------+ +------------+ +------------+
| 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
5.3. Pledge - Registrar - RA/CA certificate enrollment
/* to be done: overview description of operation */
Fries, et al. Expires September 12, 2019 [Page 14]
Internet-Draft BRSKI-AE March 2019
+--------+ +---------+ +------------+ +------------+
| 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
o Cert Request: certification request message (to be done: reference
to PKCS#10 or CRMF, proof of possession, pledge authentication)
o Cert Response: certification response message containing the
requested certificate and potentially further information like
certificates of intermediary CAs on the certification path.
o Cert Waiting: waiting indication for the pledge to retry after a
given time.
o Cert Poling: querying the registrar, if the certificate request
was already processed; can be answered either with another Cert
Waiting, or a Cert Response.
o Cert Confirm: confirmation message from pledge after receiving and
verifying the certificate.
o PKI/Registrar Confirm: confirmation message from PKI/registrar
about reception of the pledge's certificate confirmation.
Fries, et al. Expires September 12, 2019 [Page 15]
Internet-Draft BRSKI-AE March 2019
/* to be done: - investigation into handling of certificate request
retries - message exchange description - confirmation message
(necessary? optional? from Registrar and/or PKI?) */
6. IANA Considerations
This document requires the following IANA actions:
/* to be done: clarification necessary */
7. Privacy Considerations
/* to be done: clarification necessary */
8. Security Considerations
/* to be done: clarification necessary */
9. Acknowledgements
We would like to thank the various reviewers for their input, in
particular ...
10. References
10.1. Normative References
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-19 (work in progress), 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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>.
Fries, et al. Expires September 12, 2019 [Page 16]
Internet-Draft BRSKI-AE March 2019
10.2. Informative References
[I-D.gutmann-scep]
Gutmann, P., "Simple Certificate Enrolment Protocol",
draft-gutmann-scep-13 (work in progress), 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,
<https://www.rfc-editor.org/info/rfc5785>.
Authors' Addresses
Steffen Fries
Siemens AG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: steffen.fries@siemens.com
URI: http://www.siemens.com/
Hendrik Brockhaus
Siemens AG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: hendrik.brockhaus@siemens.com
URI: http://www.siemens.com/
Fries, et al. Expires September 12, 2019 [Page 17]
Internet-Draft BRSKI-AE March 2019
Eliot Lear
Cisco Systems
Richtistrasse 7
Wallisellen CH-8304
Switzerland
Phone: +41 44 878 9200
Email: lear@cisco.com
Fries, et al. Expires September 12, 2019 [Page 18]