Internet DRAFT - draft-fries-anima-brski-async-enroll
draft-fries-anima-brski-async-enroll
ANIMA WG S. Fries
Internet-Draft H. Brockhaus
Intended status: Standards Track Siemens
Expires: September 7, 2020 E. Lear
Cisco Systems
March 6, 2020
Support of asynchronous Enrollment in BRSKI
draft-fries-anima-brski-async-enroll-03
Abstract
This document discusses enhancements of bootstrapping of a remote
secure key infrastructure (BRSKI) to also operate in domains
featuring no or only timely limited connectivity to backend services
offering enrollment functionality, specifically a Public Key
Infrastructure (PKI). The enhancements proposed to enable this are
also applied to further set of use cases in which a pledge may not
have a direct connection to the registrar and is served by for
instance by a commissioning tool as an agent providing registrar
connectivity. In the context of deploying new devices the design of
BRSKI allows for online (synchronous object exchange) and offline
interactions (asynchronous object exchange) with a manufacturer's
authorization service. For this it utilizes an authenticated self-
contained voucher to transport the domain credentials as a signed
object to establish an initial trust between a pledge and the target
deployment domain. The currently supported enrollment protocol for
request and distribution of deployment domain specific device
certificates provides only limited support for asynchronous PKI
interactions. This memo motivates the enhancement of supporting
authenticated self-contained objects for certificate management by
using an abstract notation. The enhancement allows on one hand off-
site operation of PKI services outside the deployment domain of the
pledge. This addresses specifically scenarios, in which the final
authorization of a certification request of a pledge cannot be made
in the deployment domain and is therefore delegated to a operator
backend. On the other hand, this enhancement also facilitates the
exchange of certificate management information via a pledge agent.
The goal is to enable the usage of existing and potentially new PKI
protocols supporting authenticated self-containment for certificate
management exchanges.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Fries, et al. Expires September 7, 2020 [Page 1]
Internet-Draft BRSKI-AE March 2020
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2020.
Copyright Notice
Copyright (c) 2020 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. History of changes . . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Scope of solution . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Supported environment . . . . . . . . . . . . . . . . . . 8
4.2. Application Examples . . . . . . . . . . . . . . . . . . 9
4.2.1. Rolling stock . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Building automation . . . . . . . . . . . . . . . . . 9
4.2.3. Substation automation . . . . . . . . . . . . . . . . 10
4.2.4. Electric vehicle charging infrastructure . . . . . . 10
4.2.5. Infrastructure isolation policy . . . . . . . . . . . 11
4.2.6. Less operational security in the deployment domain . 11
4.3. Requirement discussion and mapping to solution elements . 11
5. Architectural Overview and Communication Exchanges . . . . . 13
5.1. Use Case 1: Off-site PKI components . . . . . . . . . . . 14
5.1.1. Behavior of a pledge . . . . . . . . . . . . . . . . 17
5.1.2. Pledge - Registrar discovery and voucher exchange . . 17
5.1.3. Registrar - MASA voucher exchange . . . . . . . . . . 18
5.1.4. Pledge - Registrar - RA/CA certificate enrollment . . 19
Fries, et al. Expires September 7, 2020 [Page 2]
Internet-Draft BRSKI-AE March 2020
5.1.5. Addressing Scheme for the Enrollment . . . . . . . . 21
5.1.6. Discovery of Enrollment Protocol Support . . . . . . 22
5.2. Use Case 2: Pledge Agent . . . . . . . . . . . . . . . . 23
5.2.1. Behavior of a pledge . . . . . . . . . . . . . . . . 25
5.2.2. Behavior of a pledge agent . . . . . . . . . . . . . 26
5.2.3. Registrar discovery . . . . . . . . . . . . . . . . . 26
5.2.4. Handling voucher request and certification requests . 26
6. Example mappings to existing enrollment protocols . . . . . . 28
6.1. EST Handling . . . . . . . . . . . . . . . . . . . . . . 29
6.2. CMP Handling . . . . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction
BRSKI as defined in [I-D.ietf-anima-bootstrapping-keyinfra] specifies
a solution for secure zero-touch (automated) bootstrapping of devices
(pledges) in a target deployment domain. This includes the discovery
of network elements in the deployment domain, time synchronization,
and the exchange of security information necessary to establish trust
between a pledge and the domain and to adopt a pledge as new network
and application element. Security information about the deployment
domain, specifically the deployment domain certificate (domain root
certificate), is exchanged utilizing voucher objects as defined in
[RFC8366]. These vouchers are authenticated self-contained (signed)
objects, which may be provided online (synchronous) or offline
(asynchronous) via the domain registrar to the pledge and originate
from a Manufacturer's Authorized Signing Authority (MASA). The MASA
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 from the pledge to
the domain.
For the enrollment of devices BRSKI relies on EST [RFC7030] to
request and distribute deployment domain specific device
certificates. EST in turn relies on a binding of the certification
request to an underlying TLS connection between the EST client and
the EST server. According to BRSKI the domain registrar acts as EST
server and is also acting as registration authority (RA) or local
registration authority (LRA). The binding to TLS is used to protect
the exchange of a certification request (for an LDevID certificate)
Fries, et al. Expires September 7, 2020 [Page 3]
Internet-Draft BRSKI-AE March 2020
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 local asset or inventory management system
performing the authorization decision based on tuple of the
certification request and the pledge authentication using the IDevID
certificate, to issue a domain specific certificate to the pledge.
The reason bases on the EST server (the domain registrar) terminating
the security association with the pledge and thus the local binding
between the certification request and the authentication of the
pledge. This type of enrollment utilizing an online connection to
the PKI is considered as synchronous enrollment.
For certain use cases on-site support of a RA/CA component and/or an
asset management is not available and rather provided by an
operator's backend and may be provided timely limited or completely
through offline interactions. This may be due to higher security
requirements for operating the certification authority. The
authorization of a certification request based on an asset management
in this case will not / can not be performed on-site at enrollment
time. Enrollment, which cannot be performed in a (timely) consistent
fashion is considered as asynchronous enrollment in this document.
It requires the support of a store and forward functionality of
certification request together with the requester authentication
information. This enables processing of the request at a later point
in time. A similar situation may occur through network segmentation,
which is utilized in industrial systems to separate domains with
different security needs. Here, a similar requirement arises if the
communication channel carrying the requester authentication is
terminated before the RA/CA handling the certification request. If a
second communication channel is opened to forward the certification
request to the issuing RA/ CA, the requester authentication
information needs to be bound to the certification request. This
uses case is independent from the timely limitations of the first use
case. For both cases, it is assumed that the requester
authentication information is utilized in the process of
authorization of a certification request. There are different
options to perform store and forward of certification requests
including the requester authentication information:
o Providing a trusted component (e.g., an LRA) in the deployment
domain, which stores the certification request combined with the
requester authentication information (based on the IDevID) and
potentially the information about a successful proof of possession
(of the corresponding private key) in a way prohibiting changes to
the combined information. Note that the assumption is that the
Fries, et al. Expires September 7, 2020 [Page 4]
Internet-Draft BRSKI-AE March 2020
information elements may not be cryptographically bound together.
Once connectivity to the backend is available, the trusted
component forwards the certification request together with the
requester information (authentication and proof of possession) to
the off-site PKI for further processing. It is assumed that the
off-site PKI in this case relies on the local pledge
authentication result and thus performs 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 authenticated self-contained objects binding the
certification request and the requester authentication in a
cryptographic way. This approach reduces the necessary trust in a
domain component to storage and delivery. Unauthorized
modifications of the requester information (request and
authentication) can be detected during the verification of the
cryptographic binding of the authenticated self-contained object
in the off-site PKI. An example for a authenticated self-
contained object is a signed CMS wrapped object.
This document targets environments, in which connectivity to the PKI
functionality is only temporary or not directly available by
specifying support for handling authenticated self-contained objects
supporting asynchronous enrollment. As it is intended to enhance
BRSKI it is named BRSKI-AE, where AE stands for asynchronous
enrollment. As BRSKI, BRSKI-AE results in the pledge storing a X.509
root certificate sufficient for verifying the domain registrar /
proxy identity (LDevID CA Certificate) as well as an domain specific
X.509 device certificate (LDevID EE certificate).
Based on the proposed approach, a second set of scenarios can be
addressed, in which the pledge has a different technology stack as
the domain registrar, but is considered to be managed by the domain
registrar regarding the utilized credentials of this pledge with the
help of an additional component, e.g., a commissioning tool acting as
a agent for the pledge towards the domain registrar. This enable the
re-use of the BRSKI functionality also in scenarios, in which the
pledge has a different technology stack or does not have direct
connectivity to the domain registrar.
The goal is to enhance BRSKI to either allow other existing
certificate management protocols supporting authenticated self-
contained objects to be applied or to allow other types of encoding
for the certificate management information exchange. This is
addressed by
Fries, et al. Expires September 7, 2020 [Page 5]
Internet-Draft BRSKI-AE March 2020
o enhancing the well-known URI approach with additional settings for
the utilized enrollment protocol.
o defining a certificate waiting indication and handling, if the
certifying component is (temporarily) not available.
o allowing to utilize credentials different from the pledge's IDevID
to establish a connection to the domain registrar.
Note that in contrast to BRSKI, BRSKI-AE assumes support of multiple
enrollment protocols on the infrastructure side, allowing the pledge
manufacturer to select the most appropriate. Thus, BRSKI-AE can be
applied for both, asynchronous and synchronous enrollment.
2. History of changes
From version 02 -> 03:
o Update of terminology from self-contained to authenticated self-
contained object to be consistent in the wording and to underline
the protection of the object with an existing credential. Note
that the naming of this object may be discussed. An alternative
name may be attestation object.
o Simplification of the architecture approach for the initial use
case having an offsite PKI.
o Introduction of a new use case utilizing authenticated self-
contain objects to onboard a pledge using a commissioning tool
containing a pledge agent. This requires additional changes in
the BRSKI call flow sequence and led to changes in the
introduction, the application example,and also in the related
BRSKI-AE call flow.
o Update of provided examples of the addressing approach used in
BRSKI to allow for support of multiple enrollment protocols in
Section 5.1.5.
From version 01 -> 02:
o Update of introduction text to clearly relate to the usage of
IDevID and LDevID.
o Definition of the addressing approach used in BRSKI to allow for
support of multiple enrollment protocols in Section 5.1.5. This
section also contains a first discussion of an optional discovery
mechanism to address situations in which the registrar supports
Fries, et al. Expires September 7, 2020 [Page 6]
Internet-Draft BRSKI-AE March 2020
more than one enrollment approach. Discovery should avoid that
the pledge performs a trial and error of enrollment protocols.
o Update of description of architecture elements and changes to
BRSKI in Section 5.
o Enhanced consideration of existing enrollment protocols in the
context of mapping the requirements to existing solutions in
Section 4.3 and in Section 6.
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 6 with the mapping to existing
enrollment protocols by collecting boundary conditions.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
This document relies on the terminology defined in
[I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are
defined additionally:
CA: Certification authority, issues certificates.
RA: Registration authority, an optional system component to which a
CA delegates certificate management functions such as
authorization checks.
Fries, et al. Expires September 7, 2020 [Page 7]
Internet-Draft BRSKI-AE March 2020
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.
off-site: Describes a component or service or functionality
available in an operator domain different from the target
deployment domain. This may be a central side, to which only a
temporarily connection is available, or which is in a different
administrative domain.
asynchronous communication: Describes a timely interrupted
communication between an end entity and a PKI component.
synchronous communication: Describes a timely uninterrupted
communication between an end entity and a PKI component.
authenticated self-contained object: Describes an object, which is
cryptographically bound to the IDevID EE credential of a pledge.
The binding is assumed to be provided through a digital signature
using the corresponding private key of the IDevID to wrap the
actual object. Note that depending on the availability of a
LDevID EE credential, the binding may also be achieved using
corresponding private key of the LDevID. This can be utilized in
for instance in the context of an initial certification request or
a certificate update.
4. Scope of solution
4.1. Supported environment
This solution is intended to be used in domains with limited support
of on-site PKI services and comprises use cases in which:
o there is no registration authority available in the deployment
domain. The connectivity to the backend RA may only be
temporarily available. A local store and forward device is used
for the communication with the backend services.
o authoritative actions of a LRA are limited and may not comprise
authorization of certification requests of pledges. Final
authorization is done at the RA residing in the backend operator
domain.
Fries, et al. Expires September 7, 2020 [Page 8]
Internet-Draft BRSKI-AE March 2020
o the target deployment domain already uses a certificate management
approach that shall be reused to be consistent throughout the life
cycle.
In addition, the solution is intended to be applicable in domains in
which the pledges have no direct connection to the domain registrar,
but are expected to be managed by the registrar. This can be
motivated by pledges featuring a different technology stack or by
pledges without an existing connection to the domain registrar during
onboarding.
4.2. Application Examples
The following examples are intended to motivate the support of
different enrollment approaches in general and asynchronous
enrollment specifically, by introducing industrial applications
cases, which could leverage BRSKI as such but also require support of
asynchronous operation as intended with BRSKI-AE.
4.2.1. Rolling stock
Rolling stock or railroad cars contain a variety of sensors,
actuators, and controller, which communicate within the railroad car
but also exchange information between railroad cars building a train
or with a backend. These devices are typically unaware of backend
connectivity. Managing certificates may be done during maintenance
cycles of the railroad car, but can already be prepared during
operation. The preparation may comprise the generation of
certification requests by the components, which are collected and
forwarded for processing once the railroad car is connected to the
operator backend. The authorization of the certification request is
then done based on the operator's asset/inventory information in the
backend.
4.2.2. Building automation
In building automation a use case can be described by a detached
building or the basement of a building equipped with sensor,
actuators, and controllers connected, but with only limited or no
connection to the centralized building management system. This
limited connectivity may be during the installation time but also
during operation time. During the installation in the basement, a
service technician collects the necessary information from the
basement network and provides them to the central building management
system, e.g., using a laptop or even a mobile phone to transport the
information. This information may comprise parameters and settings
required in the operational phase of the sensors/actuators, like a
Fries, et al. Expires September 7, 2020 [Page 9]
Internet-Draft BRSKI-AE March 2020
certificate issued by the operator to authenticate against other
components and services.
The collected information may be provided by a domain registrar
already existing in the installation network. In this case
connectivity to the backend PKI may be facilitated by the service
technician's laptop. Contrary, the information can also be collected
from the pledges directly and provided to a domain registrar deployed
in the main network. In this cases connectivity to the domain
registrar may be facilitated by the service technician's laptop.
4.2.3. Substation automation
In substation automation a control center typically hosts PKI
services to issue certificates for Intelligent Electronic Devices
(IED)s in a substation. Communication between the substation and
control center is done through a proxy/gateway/DMZ, which terminates
protocol flows. Note that NERC CIP-005-5 [NERC-CIP-005-5] requires
inspection of protocols at the boundary of a security perimeter (the
substation in this case). In addition, security management in
substation automation assumes central support of different enrollment
protocols to facilitate the capabilities of IEDs from different
vendors. The IEC standard IEC62351-9 [IEC-62351-9] specifies the
mandatory support of two enrollment protocols, SCEP
[I-D.gutmann-scep] and EST [RFC7030] for the infrastructure side,
while the IED must only support one of the two.
4.2.4. Electric vehicle charging infrastructure
For the electric vehicle charging infrastructure protocols have been
defined for the interaction between the electric vehicle (EV) and the
charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as
between the charging point and the charging point operator (e.g.
OCPP [OCPP]). Depending on the authentication model, unilateral or
mutual authentication is required. In both cases the charging point
authenticates uses an X.509 certificate to authenticate in the
context of a TLS connection between the EV and the charging point.
The management of this certificate depends (beyond others) on the
selected backend connectivity protocol. Specifically, in case of
OCPP it is intended as single communication protocol between the
charging point and the backend carrying all information to control
the charging operations and maintain the charging point itself. This
means that the certificate management is intended to be handled in-
band of OCPP. This requires to be able to encapsulate the
certificate management exchanges in a transport independent way.
Authenticated 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.
Fries, et al. Expires September 7, 2020 [Page 10]
Internet-Draft BRSKI-AE March 2020
4.2.5. Infrastructure isolation policy
This refers to any case in which network infrastructure is normally
isolated from the Internet as a matter of policy, most likely for
security reasons. In such a case, limited access to external PKI
resources will be allowed in carefully controlled short periods of
time, for example when a batch of new devices are deployed, but
impossible at other times.
4.2.6. Less operational security in the deployment domain
The registration point performing the authorization of a certificate
request is a critical PKI component and therefore implicates higher
operational security than other components utilizing the issued
certificates for their security features. CAs may also demand higher
security in the registration procedures. Especially the CA/Browser
forum currently increases the security requirements in the
certificate issuance procedures for publicly trusted certificates.
There may be the situation that the deployment domain does not offer
enough security to operate a registration point and therefore wants
to transfer this service to a backend.
4.3. Requirement discussion and mapping to solution elements
For the requirements discussion it is assumed that the entity
receiving the authenticated self-contained object in the deployment
domain is not the authorization point for the certification request
contained in the object. If the entity is the authorization point,
BRSKI can be used directly. Note that BRSKI-AE could also be used in
this case.
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
authenticated 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:
o Certification requests are structures protecting at least
integrity of the contained data combined with a proof-of-private-
key-possession for locally generated key pairs. Examples for
certification requests are:
* 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
Fries, et al. Expires September 7, 2020 [Page 11]
Internet-Draft BRSKI-AE March 2020
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 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 may also be
replaced by the RA after verification, if the RA intends to
update or alter the request message.
Note that the integrity of the certification request is bound to
the public key contained in the certification request by
performing the signature operation with the corresponding private
key. In the considered application examples, this is not
sufficient and needs to be bound to the existing credential of the
pledge (IDevID). This binding supports the authorization decision
for the certification request. The binding of data origin
authentication to the certification request may be delegated to
the management protocol.
o The container carrying the certification request should support a
binding to an existing credential (here IDevID) known to the peer
performing the authorization 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 requirement 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) may contain 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 referred to as re-enroll.
* 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
Fries, et al. Expires September 7, 2020 [Page 12]
Internet-Draft BRSKI-AE March 2020
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 can 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 requirement is addressed by existing enrollment
protocols in different ways, for instance:
* EST [RFC7030]: Not supported natively. Requires support of
FullCMCRequest.
* SCEP [I-D.gutmann-scep]: Not specified in SCEP, could be done
using message wrapping with signature (based on CMS). Note
that in the current definition of SCEP this could be supported
using a re-enroll request.
* CMP [RFC4210]: Message wrapping with signature.
* CMC [RFC5272]: Message wrapping with signature.
Note that besides the already existing enrollment protocols there
ongoing work in the ACE WG to define an encapsulation of EST in
OSCORE to result in a TLS independent way of protecting EST. This
approach [I-D.selander-ace-coap-est-oscore] is intended to be
considered in the future as well. /* note: to be verified if this
activity proceeds */
5. Architectural Overview and Communication Exchanges
To support asynchronous enrollment, the base system architecture
defined in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] is changed
for two target use cases.
o allow for off-site operation of the PKI components.
Fries, et al. Expires September 7, 2020 [Page 13]
Internet-Draft BRSKI-AE March 2020
o allow delayed (delegated) onboarding without initial direct
connection to the domain registrar.
Both use cases are described in the next subsections. They utilize
the existing BRSKI architecture elements as much as possible.
Necessary enhancements regarding support of authenticated self-
contained objects for are adoptions of exchanges to achieve the
targeted functionality are kept on a minimum to ensure reuse of
already defined architecture elements and interactions.
5.1. Use Case 1: Off-site PKI components
To support off-site operation of PKI components, one assumption of
BRSKI-AE is that the authorization for a certification request is
performed based on an authenticated self-contained object binding the
certification request to the authentication using the IDevID. In
addition, the authorization may be handled by 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.
Fries, et al. Expires September 7, 2020 [Page 14]
Internet-Draft BRSKI-AE March 2020
+------------------------+
+--------------Drop Ship--------------->| Vendor Service |
| +------------------------+
| | M anufacturer| |
| | A uthorized |Ownership|
| | S igning |Tracker |
| | A uthority | |
| +--------------+---------+
| ^
| |
V |
+--------+ ......................................... |
| | . . |
| | . +------------+ +------------+ . | BRSKI-
| | . | | | | . | MASA
| Pledge | . | Join | | Domain <-----+
| | . | Proxy | | Registrar/ | .
| <-------->............<-------> Proxy | .
| | . | BRSKI-AE | | .
| IDevID | . | | +------^-----+ .
| | . +------------+ | .
| | . | .
+--------+ ...............................|.........
"on-site domain" components |
|e.g., RFC 7030,
| RFC 4210
.............................................|.....................
. +---------------------------+ +--------v------------------+ .
. | Public Key Infrastructure |<----+ PKI RA | .
. | PKI CA |---->+ [(Domain) Registrar (opt)]| .
. +---------------------------+ +---------------------------+ .
...................................................................
"off-site domain" components
Figure 1: Architecture overview using off-site PKI components
The architecture overview in Figure 1 utilizes the same logical
elements as BRSKI but with a different placement in the deployment
architecture for some of the elements. The main difference is the
placement of the PKI RA/CA component, which is performing the
authorization decision for the certification request message. Also
shown is the connectivity of the RA/CA with an inventory management
system, which is expected to be utilized in the authorization
decision. Note that this may also be an integrated functionality of
the RA. Both components are placed in the off-site domain of the
operator (not the deployment site directly), which may have no or
only temporary connectivity to the deployment domain of the pledge.
This is to underline the authorization decision for the certification
Fries, et al. Expires September 7, 2020 [Page 15]
Internet-Draft BRSKI-AE March 2020
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 described 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 to facilitate the communication of the
pledge with the MASA and the PKI. Different is the authorization
of the certification request. BRSKI-AE allows to perform this in
the operators backend (off-site), even if the deployment domain
has only temporary or no connectivity to an operator domain.
* Voucher exchange: The voucher exchange with the MASA via the
domain registrar is performed as described in BRSKI
[I-D.ietf-anima-bootstrapping-keyinfra] .
* Certificate enrollment: For the pledge enrollment the domain
registrar in the deployment domain supports the adoption 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 to forward the
certification request to the RA. Thus, it basically works as a
proxy. In the case of no connectivity, the domain registrar
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
alternative enrollment approaches (protocol options, protocols,
encodings), it is necessary to enhance the addressing scheme at
the domain registrar. This is addressed in Section 5.1.5.
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 with the MASA may be synchronous (voucher
request with nonce) or asynchronous (voucher request without
nonce).
o Ownership tracker: as defined in BRSKI.
The following list describes the operator related components/service
operated in the backend:
Fries, et al. Expires September 7, 2020 [Page 16]
Internet-Draft BRSKI-AE March 2020
o PKI RA: Performs certificate management functions (validation of
certification requests, interaction with inventory/asset
management for authorization of certification requests, etc.) for
issuing, updating, and revoking certificates for a domain as a
centralized infrastructure for the operator. The inventory
(asset) management may be a separate component or integrated into
the RA directly.
o PKI CA: Performs certificate generation by signing the certificate
structure provided in the certification request.
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.
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 (same as BRSKI).
o Enrollment phase (changed to accompany the application of
authenticated self-contained objects for the enrollment).
5.1.1. Behavior of a pledge
The behavior of a pledge as described in
[I-D.ietf-anima-bootstrapping-keyinfra] is kept with one exception.
After finishing the imprinting phase (4) the enrollment phase (5) is
performed with a method supporting authenticated self-contained
objects. Using EST with simpleenroll cannot be applied here, as it
binds the pledge authentication with the existing IDevID to the
transport channel rather than the certification request object
directly. This authentication is not visible / verifiable at the
authorization point in the off-site domain. Section 6 discusses
potential protocols and EST protocol options applicable.
5.1.2. Pledge - Registrar discovery and voucher exchange
The discovery phase is applied as specified in
[I-D.ietf-anima-bootstrapping-keyinfra].
/* for discussion: is a reference to BRSKI sufficient here or is it
helpful to provide additional information and the figure? */
Fries, et al. Expires September 7, 2020 [Page 17]
Internet-Draft BRSKI-AE March 2020
+--------+ +---------+ +------------+ +------------+
| Pledge | | Circuit | | Domain | | Vendor |
| | | Join | | Registrar | | Service |
| | | Proxy | | (JRC) | | (MASA) |
+--------+ +---------+ +------------+ +------------+
| | | Internet |
|<-RFC4862 IPv6 addr | | |
|<-RFC3927 IPv4 addr | Appendix A | Legend |
|-------------------->| | C - circuit |
| optional: mDNS query| Appendix B | join proxy |
| RFC6763/RFC6762 | | P - provisional |
|<--------------------| | TLS connection |
| GRASP M_FLOOD | | |
| periodic broadcast| | |
|<------------------->C<----------------->| |
| TLS via the Join Proxy | |
|<--Registrar TLS server authentication---| |
[PROVISIONAL accept of server cert] | |
P---X.509 client authentication---------->| |
P | | |
P--Voucher Request (w/nonce for voucher)->| |
P | /---> | |
P | | see Figure 3 below |
P | \----> | |
P<------voucher---------------------------| |
[verify voucher, imprint] | |
|---------------------------------------->| |
| [voucher status telemetry] |<-device audit log--|
| | [verify audit log and voucher] |
|<--------------------------------------->| |
Figure 2: Pledge discovery of domain registrar discovery and voucher
exchange
5.1.3. Registrar - MASA voucher exchange
The voucher exchange is performed as specified in
[I-D.ietf-anima-bootstrapping-keyinfra].
/* for discussion: is a reference to BRSKI sufficient here or is it
helpful to provide additional information and the figure? */
Fries, et al. Expires September 7, 2020 [Page 18]
Internet-Draft BRSKI-AE March 2020
+--------+ +---------+ +------------+ +------------+
| 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.1.4. Pledge - Registrar - RA/CA certificate enrollment
The enrollment for BRSKI-AE will be performed using an authenticated
self-contained object. This object contains the certification
request and shall support at least the following properties:
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 initial certification request.
certificate updates may utilize the LDevID credential.
o /* further parameter to be specified if necessary */.
Fries, et al. Expires September 7, 2020 [Page 19]
Internet-Draft BRSKI-AE March 2020
+--------+ +---------+ +------------+ +------------+
| Pledge | | Circuit | | Domain | | Operator |
| | | Join | | Registrar | | RA/CA |
| | | Proxy | | (JRC) | | (OPKI) |
+--------+ +---------+ +------------+ +------------+
/--> | |
|---------- Request CA Certs ------------>| |
| [if connection to operator domain is available] |
| |-Request CA Certs ->|
| |<- CA Certs Response|
|<-------- CA Certs Response--------------| |
|---------- Attribute Request ----------->| |
| [if connection to operator domain is available] |
| |Attribute Request ->|
| |<-Attribute Response|
|<--------- Attribute Response -----------| |
/--> | |
|-------------- Cert Request ------------>| |
| [if connection to operator domain is available] |
| |--- Cert Request -->|
| |<-- Cert Response --|
/--> | |
| [if connection to operator domain is not available] |
| | |
|<---------- Cert Waiting ----------------| |
|-- Cert Polling (with orig request ID) ->| |
| [if connection to operator domain is available] |
| |--- Cert Request -->|
| |<-- Cert Response --|
/--> | |
|<------------- Cert Response ------------| |
|-------------- Cert Confirm ------------>| |
| /--> |
| |[optional] |
| |--- Cert Confirm -->|
| |<-- PKI Confirm ----|
|<------------- PKI/Registrar Confirm ----| |
Figure 4: Certificate enrollment
The following list provides an abstract description of the flow
depicted in Figure 4.
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.
Fries, et al. Expires September 7, 2020 [Page 20]
Internet-Draft BRSKI-AE March 2020
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. Depending on the
utilized enrollment protocol, this certification request contains
the authenticated self-signed object ensuring both, proof-of-
posession of the corresponding private key and proof-of-identity
of the requester.
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. 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 Polling: 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.
/* to be done:
o Investigation into handling of certificate request retries.
o Message exchange description.
o Confirmation message (necessary? optional? from Registrar and/or
PKI?).
*/
5.1.5. Addressing Scheme for the Enrollment
The realization of BRSKI-AE requires enhancements to the addressing
scheme defined in [I-D.ietf-anima-bootstrapping-keyinfra]. This is
due to the additions of authenticated self-contained object handling
Fries, et al. Expires September 7, 2020 [Page 21]
Internet-Draft BRSKI-AE March 2020
to BRSKI. BRSKI itself utilizes EST as enrollment protocol, which
can be enabled to support authenticated self-contained objects by
utilizing the FullCMCRequest instead of simpleenroll. Besides EST
there are further enrollment protocols, which also support the
handling of authenticated self-contained objects and which can be
employed here. The approach of BRSKI-AE is to allow additional
enrollment options to be supported. 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.
The current addressing scheme in BRSKI for the client certificate
request function during the enrollment is using the definition from
EST [RFC7030], here on the example on simple enroll: "/.well-
known/est/simpleenroll" This approach is generalized to the following
notation: "/.well-known/enrollment-protocol/request" in which
enrollment-protocol may be an already existing protocol or a newly
defined approach. Note that enrollment is considered here as a
sequence of at least a certification request and a certification
response. In case of existing enrollment protocols the following
notation is used proving compatibility to BRSKI:
o enrollment-protocol: references EST [RFC7030] as in BRSKI directly
or CMP, CMC, SCEP, or newly defined approaches as alternatives for
support in BRSKI-AE.
o request: depending on the utilized enrollment protocol, the
request describes the required operation at the registrar side.
For BRSKI the request would be a "simpleenroll" for the base
behavior and a "FullCMCRequest" for the support of authenticated
self-contained objects
/* to be done:
o Consideration of different transport options. BRSKI utilizes EST
over HTTP but there is also the definition of EST over CoAP. This
has been defined in the draft from the ACE WG and utilizes CoAPS
instead in https in the URI. Do we want to support this in this
document as well?
*/
5.1.6. Discovery of Enrollment Protocol Support
If the registrar supports multiple enrollment protocols, specifically
beyond the required mechanisms, it is more efficient to also support
an optional discovery mechanism. By querying the registrar, the
Fries, et al. Expires September 7, 2020 [Page 22]
Internet-Draft BRSKI-AE March 2020
pledge gets an enumeration of potential options, based on the defined
namespace.
/* the discover mechanism needs to be defined in terms of message
exchanges. */
5.2. Use Case 2: Pledge Agent
To support mutual trust establishment of pledges, not directly
connected to the domain registrar, a similar approach is applied as
discussed for the use case 1. BRSKI-AE relies on authenticated self-
contained objects (the voucher request/response objects and the
certification request/response objects) for the onboarding. This
allows independence from the protection provided by the underlying
transport.
The exchange of the objects is performed with the help of a pledge
agent, which can be an integrated functionality of a commissioning
tool supporting the interaction of the pledge with the domain
registrar. This leads to enhancements of the logical elements with
the additional tool as shown in Figure 5. Specifically the pledge
agent provides an option to trigger or PUSH the pledge to create or
consume the required objects, which can be exchanged with the domain
registrar. Moreover, it also influences the sequences for the data
exchange between the pledge and the domain registrar described in
[I-D.ietf-anima-bootstrapping-keyinfra]. In general, the approach
targets to reuse the already defined interfaces on the domain
registrar side.
Fries, et al. Expires September 7, 2020 [Page 23]
Internet-Draft BRSKI-AE March 2020
+------------------------+
+--------------Drop Ship---------------| Vendor Service |
| +------------------------+
| | M anufacturer| |
| | A uthorized |Ownership|
| | S igning |Tracker |
| | A uthority | |
| +--------------+---------+
| ^
| | BRSKI-
V | MASA
+-------+ +-------+ .............................|.........
| | | | . | .
| | | | . +-----------+ +-----v-----+ .
| | |Pledge | . | | | | .
|Pledge | | Agent | . | Join | | Domain | .
| | | | . | Proxy | | Registrar | .
| <----->.......<-------->...........<-------> (PKI RA) | .
| | | | . | BRSKI-AE | | .
| | | | . | | +-----+-----+ .
|IDevID | |opt. | . +-----------+ e.g. RFC7030 .
| | |IDevID | . +-----------------+------+ .
| | |or | . | Key Infrastructure | .
| | |LDevID | . | (e.g., PKI Certificate | .
+-------+ +-------+ . | Authority) | .
. +------------------------+ .
.......................................
"Domain" components
Figure 5: Architecture overview using a pledge agent
The architecture overview in Figure 5 utilizes the same logical
elements as BRSKI with the addition of a pledge agent. The pledge
agent as part of a commissioning tool, may originate from the pledge
manufacturer and may have either an IDevID credential issued by the
manufacturer or an LDevID issued by the deployment domain
(potentially upfront). In either way, if the pledge agent possesses
a certificate, the domain registrar must be able to verify the
certificate by possessing the corresponding root certificate. The
following list describes the components in the deployment domain:
o Pledge Agent: provides a communication path to exchange data
between the pledge and the domain registrar. The pledge agent
facilitates situations, in which the domain registrar is not
directly reachable by the pledge, either due to a different
technology stack or due to missing connectivity (e.g., if the
domain registrar resides in the cloud and the pledge has no
connectivity, yet). The pledge agent in this cases can easily
Fries, et al. Expires September 7, 2020 [Page 24]
Internet-Draft BRSKI-AE March 2020
collect voucher requests and certification requests from one or
multiple pledges at once and perform a bulk onboarding based on
the collected data.
o Join Proxy: same functionality as described in BRSKI.
o Domain Registrar: In general the domain registrar fulfills the
same functionality regarding the imprinting of the pledge in the
deployment domain by facilitating the communication of the pledge
with the MASA and the PKI. The difference to BRSKI is the fact
that the Domain Registrar interacts not directly with the pledge
but with a pledge representative namely the pledge agent. This
has some implications on the utilized credentials for the
communications exchanges.
The manufacturer provided components/services (MASA and Ownership
tracker) are used as defined in BRSKI.
5.2.1. Behavior of a pledge
The behavior of a pledge as described in
[I-D.ietf-anima-bootstrapping-keyinfra] is basically kept regarding
the handling of voucher request/response objects and certificate
request/response objects. In contrast to BRSKI, the interaction is
done with a pledge agent and not with the domain registrar directly.
This changes the general interaction as shown in Figure 6.
In BRSKI the pledge is expected to start the communication with the
domain registrar by opening a TLS connection. This can be considered
as PULL as the pledge triggers the domain registrar. In use case 2
of BRSKI-AE the pledge is expected to be triggered by the pledge
agent to generate a voucher request and a certification request,
which can be considered a PUSH. The pledge agent should provide the
proximity-registrar-cert to the pledge to enable embedding in the
voucher request. The registrar certificate may be configured at the
pledge agent or may be fetched by the pledge agent based on the TLS
connection establishment with the domain registrar.
Also, the pledge will be triggered by the pledge agent to generate a
certification request message. For this, the pledge agent may have
been pre-configured with the certification request attributes, that
it may provide to the pledge. The pledge is then requested to
generate a certification request as authenticated self-signed object,
which assures proof of possession of the private key corresponding to
the contained public key in the certification request as well as a
proof of identity, based on the IDevID available on the pledge.
Fries, et al. Expires September 7, 2020 [Page 25]
Internet-Draft BRSKI-AE March 2020
5.2.2. Behavior of a pledge agent
The pledge agent is a new component in the BRSKI context. It
provides connectivity between the pledge and the domain registrar and
utilizes the interfaces already specified in
[I-D.ietf-anima-bootstrapping-keyinfra]. The pledge agent is
expected to interact with the pledge independent of the domain
registrar. The utilized communication between the pledge and the
pledge agent is only defined based on the information objects, which
are the voucher request/response objects and the certification
request/response objects. The transport mechanism is out of scope
here. This changes the general interaction as shown in Figure 6.
The pledge agent may have an own IDevID or a deployment domain issued
LDevID to be utilized in the TLS communication establishment. Note
that the pledge agent may also be used without client side
authentication if no suitable credential is available. As BRSKI-AE
utilizes data object, which bind the pledge authentication directly
to the object, the TLS client authentication may be neglected. This
is possible as the pledge proof of identity is bound to the voucher
request and the certification request objects. This is a deviation
from the BRSKI approach in which the pledge's IDevID credential is
used to perform TLS client authentication. According to
[I-D.ietf-anima-bootstrapping-keyinfra] section 5.3, the domain
registrar performs the pledge authorization based on the provided
voucher request.
5.2.3. Registrar discovery
The discovery phase may be applied as specified in
[I-D.ietf-anima-bootstrapping-keyinfra] with the deviation that it is
done between the pledge agent and the pledge. Alternatively, the
domain registrar is be configured in the pledge agent.
The pledge is expected to be discovered by the pledge agent tool.
This is out of scope for this specification.
5.2.4. Handling voucher request and certification requests
The BRSKI-AE exchange of voucher requests and certification requests
utilizes authenticated self-contained objects independent of
transport protection.
+--------+ +-------+ +-----------+ +--------+ +---------+
| Pledge | | Plegde| | Domain | | Domain | | Vendor |
| | | Agent | | Registrar | | CA | | Service |
| | | | | (JRC) | | | | (MASA) |
+--------+ +-------+ +-----------+ +--------+ +---------+
Fries, et al. Expires September 7, 2020 [Page 26]
Internet-Draft BRSKI-AE March 2020
| | | | Internet |
| opt: configure | | |
| - proximity-registrar-cert | | |
| - CSR attributes | | |
| | | | |
|<--trigger VouReq--| | | |
|(o: proximity-cert)| | | |
|- Voucher Request->| | | |
| | | | |
|<--trigger CR------| | | |
|(o: attributes) | | | |
|----Cert Request-->| | | |
| |<---- TLS --->| | |
| | | | |
| |--- VouReq -->| | |
| | [accept device?] | |
| | [contact vendor] | |
| | |----- Voucher Request ------>|
| | |----- Pledge ID ------------>|
| | |----- Domain ID ------------>|
| | |----- optional: nonce ------>|
| | | [extract DomainID]
| | | [update audit log]
| | |<--------- Voucher ---------|
| |<-- Voucher --| | |
| | |<----- device audit log ----|
| | | | |
| |-- CertReq -->| | |
| | |-- CertReq --->| |
| | |<--CertResp----| |
| |<-- CertResp -| | |
| | | | |
|<---post Voucher---| | | |
|- Voucher Status-->| | | |
| | | | |
|<--post CertResp---| | | |
|---- CertConf ---->| | | |
| | | | |
| [voucher status telemetry ] | |
| |VoucherStatus>| | |
| |[verify audit log and voucher]| |
| | | | |
| | [enroll Status] | |
| |-- CertConf ->| | |
| | |-- CertConf -->| |
| | | | |
Figure 6: Request handling of the pledge using a pledge agent
Fries, et al. Expires September 7, 2020 [Page 27]
Internet-Draft BRSKI-AE March 2020
As shown in Figure 6 the pledge agent collects the voucher request
and certification request objects from a pledge. As the pledge agent
(e.g., as part of a commissioning tool) is intended to work between
the pledge and the domain registrar, a collection of requests from
multiple pledges is possible, allowing a bulk onboarding of multiple
pledges using the connection between the pledge agent and the domain
registrar. The communication protocol between the pledge agent and
the pledge is out of scope here.
The information exchange between the pledge agent and the domain
registrar resembles the exchanges between the pledge and the domain
registrar from BRSKI with one exception. As authenticated self-
contained objects are used consequently, the authentication of the
pledge agent to the domain registrar may be neglected. Note that
this allows to employ simple applications as pledge agent. The
authentication of the pledge agent is recommended if it is desired to
perform the onboarding with an authorized pledge agent or to support
advanced auditing. To achieve the authentication the pledge agent
may possess either an IDevID or LDevID credential, which can be
verified by the domain registrar. The provisioning of this
credential to the pledge agent is out of scope for this
specification. Alternatively, the domain registrar may authenticated
the user connected with the pledge agent to perform authorization of
pledge onboarding.
/* to be discussed: Description on how the registrar makes the
decision if he is connected with pledge directly or with a pledge
agent. This may result in a case statement (client side
authentication in TLS, user authentication above TLS, etc.) for the
TLS connection establishment in the original BRSKI document in
section 5.1 */
Once the pledge agent has finished the exchanges with the domain
registrar to get the voucher and the certificate object, it can close
the TLS connection to the domain registrar and provide the objects to
the pledge(s). The transport of the objects to the pledge is out of
scope. The objects are defined through the voucher [RFC8366] and the
certificate [RFC5280].
6. Example mappings to existing enrollment protocols
This sections maps the requirements and the approach described in
Section 5.1.4 to already existing enrollment protocols. Note that
that the work in the ACE WG described in
[I-D.selander-ace-coap-est-oscore] may be considered here as well, as
it also addresses the encapsulation of EST in a way to make it
independent from the underlying TLS using OSCORE resulting in an
authenticated self-contained object.
Fries, et al. Expires September 7, 2020 [Page 28]
Internet-Draft BRSKI-AE March 2020
6.1. EST Handling
When using the EST protocol [RFC7030], the following constrains
should be considered:
o Proof of possession is provided by using the specified PKCS #10
structure in the request.
o For proof of identity only the /fullcmc endpoint should be used
with a fullcmc request. This contains sufficient information for
the RA 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 RA is not available, as per [RFC7030] Section 4.2.3, a
202 return code should be returned by the Registrar. The pledge
in this case would retry a simpleenroll with a PKCS#10 request.
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.
6.2. CMP Handling
When using the CMP protocol [RFC4210], the following constrains
should be observed:
o For proof of possession, 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 RA/CA is not available, as per [RFC4210] Section 5.2.3, a
waiting indication should be returned in the PKIStatus by the
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.
Note that there is a lightweight profile for CMP defined, which
provides a subset of the CMP specification as profile for leaner
Fries, et al. Expires September 7, 2020 [Page 29]
Internet-Draft BRSKI-AE March 2020
implementation and easier interoperability in Lightweight CMP Profile
[I-D.ietf-lamps-lightweight-cmp-profile] .
7. IANA Considerations
This document requires the following IANA actions:
/* to be done: IANA consideration to be included for the defined
namespaces in Section 5.1.5. */
8. Privacy Considerations
/* to be done: clarification necessary */
9. Security Considerations
/* to be done: clarification necessary */
10. Acknowledgments
We would like to thank the various reviewers for their input, in
particular Brian E. Carpenter, Giorgio Romanenghi, Oskar Camenzind
for their input and discussion on use cases and call flows.
11. References
11.1. Normative References
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-35 (work in progress), February 2020.
[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 7, 2020 [Page 30]
Internet-Draft BRSKI-AE March 2020
11.2. Informative References
[I-D.gutmann-scep]
Gutmann, P., "Simple Certificate Enrolment Protocol",
draft-gutmann-scep-15 (work in progress), February 2020.
[I-D.ietf-lamps-lightweight-cmp-profile]
Brockhaus, H., Fries, S., and D. Oheimb, "Lightweight CMP
Profile", draft-ietf-lamps-lightweight-cmp-profile-00
(work in progress), February 2020.
[I-D.selander-ace-coap-est-oscore]
Selander, G., Raza, S., Furuhed, M., and M. Vucinic,
"Protecting EST payloads with OSCORE", draft-selander-ace-
coap-est-oscore-02 (work in progress), March 2019.
[IEC-62351-9]
International Electrotechnical Commission, "IEC 62351 -
Power systems management and associated information
exchange - Data and communications security - Part 9:
Cyber security key management for power system equipment",
IEC 62351-9 , May 2017.
[ISO-IEC-15118-2]
International Standardization Organization / International
Electrotechnical Commission, "ISO/IEC 15118-2 Road
vehicles - Vehicle-to-Grid Communication Interface - Part
2: Network and application protocol requirements", ISO/
IEC 15118 , April 2014.
[NERC-CIP-005-5]
North American Reliability Council, "Cyber Security -
Electronic Security Perimeter", CIP 005-5, December 2013.
[OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0
(Draft)", 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>.
Fries, et al. Expires September 7, 2020 [Page 31]
Internet-Draft BRSKI-AE March 2020
[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>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[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
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 7, 2020 [Page 32]
Internet-Draft BRSKI-AE March 2020
Eliot Lear
Cisco Systems
Richtistrasse 7
Wallisellen CH-8304
Switzerland
Phone: +41 44 878 9200
Email: lear@cisco.com
Fries, et al. Expires September 7, 2020 [Page 33]
