BRSKI-AE: Alternative Enrollment Protocols in BRSKISiemens AGOtto-Hahn-Ring 6Munich81739Germanydavid.von.oheimb@siemens.comhttps://www.siemens.com/Siemens AGOtto-Hahn-Ring 6Munich81739Germanysteffen.fries@siemens.comhttps://www.siemens.com/Siemens AGOtto-Hahn-Ring 6Munich81739Germanyhendrik.brockhaus@siemens.comhttps://www.siemens.com/Cisco SystemsRichtistrasse 7WallisellenCH-8304Switzerland+41 44 878 9200lear@cisco.com
Operations and Management
ANIMA WGInternet-DraftThis document enhances
Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995)
to allow employing alternative enrollment protocols, such as CMP.Using self-contained signed objects, the origin of enrollment requests and responses
can be authenticated independently of message transfer.
This supports end-to-end security and asynchronous operation of certificate enrollment
and provides flexibility where to authenticate and authorize certification requests.IntroductionMotivationBRSKI, as defined in , specifies a solution for
secure automated zero-touch bootstrapping of new devices, so-called pledges.
This includes the discovery of the registrar in the target domain,
time synchronization, and the exchange of security information
necessary to establish mutual trust between pledges and the target domain.A pledge gains trust in the target domain via the domain registrar as follows.
It obtains security information about the domain,
specifically a domain certificate to be trusted,
by requesting a voucher object defined in .
Such a voucher is a self-contained signed object
originating from a Manufacturer Authorized Signing Authority (MASA).
Therefore, the voucher may be provided
in online mode (synchronously) or offline mode (asynchronously).
The pledge can authenticate the voucher
because it is shipped with a trust anchor of its manufacturer such that
it can validate signatures (including related certificates) by the MASA.Trust by the target domain in a pledge is established by providing the pledge
with a domain-specific LDevID certificate.
The certification request of the pledge is signed using its IDevID secret and can be
validated by the target domain using the trust anchor of the pledge manufacturer,
which needs to pre-installed in the domain.For enrolling devices with LDevID certificates,
BRSKI typically utilizes Enrollment over Secure Transport (EST) .
EST has its specific characteristics, detailed in .
In particular, it requires online or on-site availability of the RA
for performing the data origin authentication and final authorization decision
on the certification request.
This type of enrollment can be called 'synchronous enrollment'.
For various reasons,
it may be preferable to use alternative enrollment protocols such as
the Certificate Management Protocol (CMP)
profiled in
or Certificate Management over CMS (CMC) .
that are more flexible and independent of the transfer mechanism because they
represent certification request messages as authenticated self-contained objects.Depending on the application scenario,
the required RA/CA components may not be part of the registrar.
They even may not be available on-site but rather be
provided by remote backend systems. The registrar or its deployment site may not have
an online connection with them or the connectivity may be intermittent.
This may be due to security requirements for operating the backend systems
or due to site deployments where on-site or always-online operation
may be not feasible or too costly.
In such scenarios, the authentication and authorization of certification requests
will not or can not be performed on-site at enrollment time.
In this document, enrollment that is not performed in a (time-wise) consistent
way is called 'asynchronous enrollment'.
Asynchronous enrollment requires a store-and-forward transfer of certification
requests along with the information needed for authenticating the requester.
This allows offline processing the request.Application scenarios may also involve network segmentation, which is utilized
in industrial systems to separate domains with different security needs.
Such scenarios lead to similar requirements if the TLS connection
carrying the requester authentication is terminated
and thus request messages need to be forwarded on further channels
before the registrar/RA can authorize the certification request.
In order to preserve the requester authentication, authentication information
needs to be retained and ideally bound directly to the certification request.There are basically two approaches for forwarding certification requests
along with requester authentication information:A trusted component (e.g., a local RA) in the target domain is needed
that forwards the certification request combined with the validated identity of
the requester (e,g., its IDevID certificate)
and an indication of successful verification of
the proof-of-possession (of the corresponding private key) in a way
preventing changes to the combined information.
When connectivity is available, the trusted component
forwards the certification request together with the requester information
(authentication and proof-of-possession) for further processing.
This approach offers only hop-by-hop security.
The backend PKI must rely on the local pledge authentication result
provided by the local RA
when performing the authorization of the certification request.
In BRSKI, the EST server is such a trusted component,
being co-located with the registrar in the target domain.Involved components use authenticated self-contained objects for the enrollment,
directly binding the certification request and the requester authentication
in a cryptographic way.
This approach supports end-to-end security,
without the need to trust in intermediate domain components.
Manipulation of the request and the requester identity information
can be detected during the validation of the self-contained signed object.Focus of this document is the support of alternative enrollment protocols that allow
using authenticated self-contained objects for device credential bootstrapping.
This enhancement of BRSKI is named BRSKI-AE,
where AE stands for alternative enrollment protocols and for asynchronous enrollment.
This specification carries over the main characteristics of BRSKI,
namely that the pledge obtains trust anchor information
for authenticating the domain registrar and other target domain components
as well as a domain-specific X.509 device certificate (the LDevID certificate)
along with the corresponding private key (the LDevID secret) and certificate chain.The goals are to enhance BRSKI tosupport alternative enrollment protocols,support end-to-end security for enrollment, andmake it applicable to scenarios involving asynchronous enrollment.This is achieved byextending the well-known URI approach with an additional path element
indicating the enrollment protocol being used, anddefining a certificate waiting indication and handling, for the case that the
certifying component is (temporarily) not available.This specification can be applied to both synchronous and asynchronous enrollment.In contrast to BRSKI, this specification supports offering multiple enrollment protocols
on the infrastructure side, which enables pledges and their developers
to pick the preferred one.Supported EnvironmentBRSKI-AE is intended to be used in domains that may have limited support
of on-site PKI services and comprises application scenarios like the following.There are requirements or implementation restrictions
that do not allow using EST for enrolling an LDevID certificate.Pledges and/or the target domain already have an established
certificate management approach different from EST that shall be reused
(e.g., in brownfield installations).There is no registration authority available on site in the target domain.
Connectivity to an off-site RA is intermittent or entirely offline.
A store-and-forward mechanism is used
for communicating with the off-site services.Authoritative actions of a local RA are limited and may not be sufficient
for authorizing certification requests by pledges.
Final authorization is done by an RA residing in the operator domain.List of Application ExamplesBootstrapping can be handled in various ways, depending on the application domains.
The informative provides illustrative examples from
various industrial control system environments and operational setups.
They motivate the support of alternative enrollment protocols,
based on the following examples of operational environments:Rolling stockBuilding automationElectrical substation automationElectric vehicle charging infrastructuresInfrastructure isolation policySites with insufficient level of operational securityTerminologyThe 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 BCP 14 when, and only when, they
appear in all capitals, as shown here.This document relies on the terminology defined in
and .
The following terms are defined in addition:
EE:
End entity, in the BRSKI context called pledge.
It is the entity that is bootstrapped to the target domain.
It holds a public-private key pair, for which it requests a public-key certificate.
An identifier for the EE is given as the subject name of the certificate.
RA:
Registration authority, an optional system
component to which a CA delegates certificate management functions
such as authenticating requesters and performing authorization checks
on certification requests.
CA:
Certification authority, issues certificates
and provides certificate status information.
target domain:
The set of entities that share a common local trust anchor,
independent of where the entities are deployed.
site:
Describes the locality where an entity, e.g., pledge, registrar, RA, CA, is deployed.
Different sites can belong to the same target domain.
on-site:
Describes a component or service or
functionality available in the target deployment site.
off-site:
Describes a component or service or
functionality available in an operator site different from
the target deployment site. This may be a central site or a
cloud service, to which only a temporary connection is available.
asynchronous communication:
Describes a time-wise interrupted communication
between a pledge (EE) and a registrar or PKI component.
synchronous communication:
Describes a time-wise uninterrupted communication
between a pledge (EE) and a registrar or PKI component.
authenticated self-contained object:
Describes in this context an object
that is cryptographically bound to the IDevID certificate of a pledge.
The binding is assumed to be provided through a digital signature
of the actual object using the IDevID secret.
Requirements and Mapping to SolutionsBasic RequirementsThere were two main drivers for the definition of BRSKI-AE:The solution architecture may already use or require
a certificate management protocol other than EST.
Therefore, this other protocol should be usable for requesting LDevID certificates.The domain registrar may not be the (final) point that authenticates and authorizes
certification requests and the pledge may not have a direct connection to it.
Therefore, certification requests should be self-contained signed objects.Based on the intended target environment described in and
the application examples described in , the following
requirements are derived to support authenticated self-contained objects
as containers carrying certification requests.At least the following properties are required:proof-of-possession: demonstrates access to the private
key corresponding to the public key contained in a certification request.
This is typically achieved by a self-signature using the corresponding private key.proof-of-identity: provides data origin authentication of
the certification request. This typically is achieved by a signature
using the IDevID secret of the pledge.The rest of this section gives an incomplete list of solution examples,
based on existing technology described in IETF documents:Solution Options for Proof-of-possessionCertification request objects: Certification requests are
data structures protecting only the integrity of the contained data
and providing proof-of-possession for a (locally generated) private key.
Examples for certification request data structures are:PKCS#10 . This certification request structure is self-signed to
protect its integrity and prove possession of the private key
that corresponds to the public key included in the request.CRMF . Also this certificate request message format supports
integrity protection and proof-of-possession,
typically by a self-signature generated over (part of) the structure
with the private key corresponding to the included public key.
CRMF also supports further proof-of-possession methods
for types of keys that do not support any signature algorithm.The integrity protection of certification request fields includes the public
key because it is part of the data signed by the corresponding private key.
Yet note that for the above examples this is not sufficient to provide data
origin authentication, i.e., proof-of-identity. This extra property can be
achieved by an additional binding to the IDevID of the pledge.
This binding to source authentication supports the
authorization decision for the certification request. The binding of data
origin authentication to the certification request may be
delegated to the protocol used for certificate management.Solution Options for Proof-of-identityThe certification request should be bound to
an existing authenticated credential (here, the IDevID certificate) to enable a proof
of identity and, based on it, an authorization of the certification request.
The binding may be achieved through security options in an
underlying transport protocol such as TLS if the authorization of the
certification request is (completely) done at the next communication hop.
This binding can also be done in a transport-independent way by wrapping the
certification request with signature employing an existing IDevID.
the BRSKI context, this will be the IDevID.
This requirement is addressed by existing enrollment protocols
in various ways, such as:EST utilizes PKCS#10 to
encode the certification request. The Certificate Signing
Request (CSR) optionally provides a binding to the underlying TLS session
by including the tls-unique value in the self-signed PKCS#10 structure.
The tls-unique value results from the TLS handshake.
Since the TLS handshake includes client
authentication and the pledge utilizes its IDevID for it,
the proof-of-identity is provided by such a binding to the TLS session.
This can be supported using the EST /simpleenroll endpoint.
Note that the binding of the TLS handshake to the CSR is optional in EST.
As an alternative to binding to the underlying
TLS authentication in the transport layer, sketches wrapping the CSR
with a Full PKI Request message using an existing certificate.SCEP supports using a shared secret (passphrase) or
an existing certificate to protect CSRs based on
SCEP Secure Message Objects using CMS wrapping
(). Note that the wrapping using
an existing IDevID in SCEP is referred to as renewal.
Thus SCEP does not rely on the security of the underlying transfer.CMP supports using a shared secret (passphrase) or an existing
certificate, which may be an IDevID credential, to authenticate
certification requests via the PKIProtection structure in a PKIMessage.
The certification request is typically encoded utilizing CRMF,
while PKCS#10 is supported as an alternative.
Thus CMP does not rely on the security of the underlying transfer protocol.CMC also supports utilizing a shared secret (passphrase) or
an existing certificate to protect certification requests,
which can be either in CRMF or PKCS#10 structure.
The proof-of-identity can be provided as part of a FullCMCRequest,
based on CMS and signed with an existing IDevID secret.
Thus CMC does not rely on the security of the underlying transfer protocol.Adaptations to BRSKIIn order to support alternative enrollment protocols, asynchronous enrollment,
and more general system architectures,
BRSKI-AE lifts some restrictions of BRSKI .
This way, authenticated self-contained objects such as those described in
above can be used for certificate enrollment.The enhancements needed are kept to a minimum in order to ensure reuse of
already defined architecture elements and interactions.
In general, the communication follows the BRSKI model and utilizes the existing
BRSKI architecture elements.
In particular, the pledge initiates communication with the domain registrar
and interacts with the MASA as usual.ArchitectureThe key element of BRSKI-AE is that the authorization of a certification request
MUST be performed based on an authenticated self-contained object.
The certification request is bound in a self-contained way
to a proof-of-origin based on the IDevID.
Consequently, the authentication and authorization of the certification request
MAY be done by the domain registrar and/or by other domain components. These components
may be offline or reside in some central backend of the domain operator (off-site)
as described in . The registrar and other on-site domain components
may have no or only temporary (intermittent) connectivity to them.
The certification request MAY also be piggybacked on another protocol.This leads to generalizations in the
placement and enhancements of the logical elements as shown in .The architecture overview in
has the same logical elements as BRSKI, but with more flexible placement
of the authentication and authorization checks on certification requests.
Depending on the application scenario, the registrar MAY still do all of these
checks (as is the case in BRSKI), or part of them, or none of them.The following list describes the on-site components in the target domain
of the pledge shown in .Join Proxy: same functionality as described in BRSKI .Domain Registrar including RA, LRA, or Enrollment Proxy: in BRSKI-AE,
the domain registrar has mostly the same functionality as in BRSKI, namely
to facilitate the communication of the pledge with the MASA and the PKI.
Yet there are two generalizations.
The registrar MAY offer different enrollment protocols. For supporting this,
the URI scheme for addressing the domain registrar is generalized
(see ).
The registrar MAY also delegate (part of) its certificate enrollment support
to a separate system. That is, alternatively to having full RA functionality,
the registrar may act as a local registration authority (LRA)
or just as an enrollment proxy.
In such cases, the domain registrar may forward the certification request to
some off-site RA component that performs part of the enrollment authorization.
This also covers the case that the registrar has only intermittent connection
and forwards certification requests to the RA upon re-established connectivity.
Still all certificate enrollment traffic goes via the registrar, such that
from the pledge perspective there is no difference in connectivity and
the registrar is involved in all steps, including enrollment status telemetry.The following list describes the components provided by the vendor or manufacturer
outside the target domain.MASA: general functionality as described in BRSKI .
The voucher exchange with the MASA via the domain registrar
is performed as described in BRSKI.
Note: The interaction with the MASA may be synchronous (voucher request with nonce)
or asynchronous (voucher request without nonce).Ownership tracker: as defined in BRSKI.The following list describes the target domain components that can optionally be
operated in the off-site backend of the target domain.PKI RA: Performs certificate management functions for the domain
as a centralized public-key infrastructure for the domain operator.
As far as not already done by the domain registrar, it performs the final
validation and authorization of certification requests.PKI CA: Performs certificate generation by signing the certificate structure
requested in already authenticated and authorized certification requests.Based on the diagram in Section 2.1 of BRSKI and the architectural changes,
the original protocol flow is divided into three phases showing commonalities
and differences to the original approach as follows.Discovery phase: same as in BRSKI steps (1) and (2)Voucher exchange phase: same as in BRSKI steps (3) and (4).Enrollment phase: step (5) is changed to employing an alternative enrollment protocol
that uses authenticated self-contained objects.Message ExchangeThe behavior of a pledge described in Section 2.1 of BRSKI
is kept with one exception.
After finishing the Imprint step (4), the Enroll step (5) MUST be performed
with an enrollment protocol utilizing authenticated self-contained objects.
discusses selected suitable enrollment protocols and options applicable.Pledge - registrar discovery and voucher exchangeThe discovery phase and voucher exchange are applied as specified in .Registrar - MASA voucher exchangeThis voucher exchange is performed as specified in .Pledge - registrar - RA/CA certificate enrollmentAs stated in , the enrollment MUST be
performed using an authenticated self-contained object providing
not only proof-of-possession but also proof-of-identity (source authentication).The following list provides an abstract description of the flow
depicted in .CA Certs Request: The pledge optionally requests the latest relevant
CA certificates. This ensures that the pledge has the
complete set of current CA certificates beyond the
pinned-domain-cert (which is contained in the voucher
and may be just the domain registrar certificate).CA Certs Response: It MUST contain the current root CA certificate,
which typically is the LDevID trust anchor, and any additional certificates
that the pledge may need to validate certificates.Attribute Request: Typically, the automated bootstrapping occurs
without local administrative configuration of the pledge.
Nevertheless, there are cases in which the pledge may also
include additional attributes specific to the target domain
into the certification request. To get these attributes in
advance, the attribute request can be used.Attribute Response: It MUST contain the attributes to be included
in the subsequent certification request.Certificate Request: This certification request MUST contain the
authenticated self-contained object ensuring both proof-of-possession of the
corresponding private key and proof-of-identity of the requester.Certificate Response: The certification response message MUST contain on success
the requested certificate and MAY include further information,
like certificates of intermediate CAs.Certificate Confirm: An optional confirmation sent
after the requested certificate has been received and validated.
It contains a positive or negative confirmation by the pledge whether
the certificate was successfully enrolled and fits its needs.PKI/Registrar Confirm: An acknowledgment by the PKI or registrar
that MUST be sent on reception of the Cert Confirm.The generic messages described above may be implemented using various
enrollment protocols supporting authenticated self-contained objects,
as described in . Examples are available in .Pledge - registrar - enrollment status telemetryThe enrollment status telemetry is performed as specified in .
In BRSKI this is described as part of the enrollment phase,
but due to the generalization on the enrollment protocol described in this document
it fits better as a separate step here.Enhancements to Addressing SchemeBRSKI-AE provides generalizations to the addressing scheme defined in
BRSKI to accommodate alternative enrollment protocols that
use authenticated self-contained objects for certification requests.
As this is supported by various existing enrollment protocols,
they can be directly employed (see also ).The addressing scheme in BRSKI for certification requests and
the related CA certificates and CSR attributes retrieval functions
uses the definition from EST ,
here on the example of simple enrollment: "/.well-known/est/simpleenroll".
This approach is generalized to the following notation:
"/.well-known/<enrollment-protocol>/<request>"
in which <enrollment-protocol> refers to a certificate enrollment protocol.
Note that enrollment is considered here a message sequence
that contains at least a certification request and a certification response.
The following conventions are used in order to provide maximal compatibility to BRSKI:<enrollment-protocol>: MUST reference the protocol being used, which
MAY be CMP, CMC, SCEP, EST as in BRSKI, or a newly defined approach.
Note: additional endpoints (well-known URIs) at the registrar
may need to be defined by the enrollment protocol being used.<request>: if present, this path component MUST describe,
depending on the enrollment protocol being used, the operation requested.
Enrollment protocols are expected to define their request endpoints,
as done by existing protocols (see also ).Domain Registrar Support of Alternative Enrollment ProtocolsWell-known URIs for various endpoints on the domain registrar are
already defined as part of the base BRSKI specification or indirectly by EST.
In addition, alternative enrollment endpoints MAY be supported at the registrar.
The pledge will recognize whether its
preferred enrollment option is supported by the domain registrar
by sending a request to its preferred enrollment endpoint
and evaluating the HTTP response status code.The following list of endpoints provides an illustrative example for
a domain registrar supporting several options for EST as well as for
CMP to be used in BRSKI-AE. The listing contains the supported
endpoints to which the pledge may connect for bootstrapping. This
includes the voucher handling as well as the enrollment endpoints.
The CMP-related enrollment endpoints are defined as well-known URIs
in CMP Updates
and the Lightweight CMP profile .Instantiation to Existing Enrollment ProtocolsThis section maps the requirements to support proof-of-possession and
proof-of-identity to selected existing enrollment protocols
handles provides further aspects of instantiating them in BRSKI-AE.BRSKI-EST-fullCMC: Instantiation to EST (informative)When using EST , the following aspects and constraints
need to be considered and the given extra requirements need to be fulfilled,
which adapt Section 5.9.3 of BRSKI :proof-of-possession is provided typically by using the specified PKCS#10
structure in the request.
Together with Full PKI requests, also CRMF can be used.proof-of-identity needs to be achieved by signing the certification request
object using the Full PKI Request option (including the /fullcmc endpoint).
This provides sufficient information for the RA to authenticate the pledge
as the origin of the request and to make an authorization decision on the
received certification request.
Note: EST references CMC for the
definition of the Full PKI Request. For proof-of-identity, the
signature of the SignedData of the Full PKI Request is
performed using the IDevID secret of the pledge.
Note: In this case the binding to the underlying TLS connection is not necessary.When the RA is temporarily not available, as per Section 4.2.3 of ,
an HTTP status code 202 should be returned by the registrar,
and the pledge will repeat the initial Full PKI RequestBRSKI-CMP: Instantiation to CMP (normative if CMP is chosen)Note: Instead of referring to CMP
as specified in and ,
this document refers to the Lightweight CMP Profile
because
the subset of CMP defined there is sufficient for the functionality needed here.When using CMP, the following specific implementation requirements apply
(cf. ).CA Certs Request
Requesting CA certificates over CMP is OPTIONAL.
If supported, it SHALL be implemented as specified in
Section 4.3.1 of .Attribute Request
Requesting certificate request attributes over CMP is OPTIONAL.
If supported, it SHALL be implemented as specified in
Section 4.3.3 of .
Note that alternatively the registrar MAY modify the contents of requested certificate contents
as specified in Section 5.2.3.2 of .Certificate Request
Proof-of-possession SHALL be provided as defined in Section 4.1.1 (based on CRMF)
or Section 4.1.4 (based on PKCS#10) of the Lightweight CMP Profile
.
The caPubs field of certificate response messages SHOULD NOT be used.Proof-of-identity SHALL be provided by using signature-based
protection of the certification request message as outlined in
Section 3.2. of using the IDevID secret.Certificate Confirm
Explicit confirmation of new certificates to the RA
MAY be used as specified in Section 4.1.1
of the Lightweight CMP Profile .
Note that independently of certificate confirmation within CMP,
enrollment status telemetry with the registrar will be performed
as described in Section 5.9.4 of BRSKI .If delayed delivery of responses (for instance, to support asynchronous enrollment)
within CMP is needed, it SHALL be performed
as specified in Sections 4.4 and 5.1.2 of .BRSKI-AE with CMP can also be combined with
Constrained BRSKI ,
using CoAP for enrollment message transport as described by
CoAP Transport for CMPV2 .
In this scenario, of course the EST-specific parts
of do not apply.IANA ConsiderationsThis document does not require IANA actions.Security ConsiderationsThe security considerations as laid out in BRSKI apply for
the discovery and voucher exchange as well as for the status exchange information.The security considerations as laid out in the Lightweight CMP Profile
apply as far as CMP is used.AcknowledgmentsWe would like to thank
Brian E. Carpenter, Michael Richardson, and Giorgio Romanenghi
for their input and discussion on use cases and call flows.Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]A Voucher Artifact for Bootstrapping ProtocolsThis document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher".This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)).This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.Bootstrapping Remote Secure Key Infrastructure (BRSKI)This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well.Certificate Management Protocol (CMP) UpdatesSiemens AGSiemens AGEntrust This document contains a set of updates to the syntax and transfer of
Certificate Management Protocol (CMP) version 2. This document
updates RFC 4210, RFC 5912, and RFC 6712.
The aspects of CMP updated in this document are using EnvelopedData
instead of EncryptedValue, clarifying the handling of p10cr messages,
improving the crypto agility, as well as adding new general message
types, extended key usages to identify certificates for use with CMP,
and well-known URI path segments.
To properly differentiate the support of EnvelopedData instead of
EncryptedValue, the CMP version 3 is introduced in case a transaction
is supposed to use EnvelopedData.
CMP version 3 is introduced to enable signaling support of
EnvelopedData instead of EncryptedValue and signaling the use of an
explicit hash AlgorithmIdentifier in certConf messages, as far as
needed.
Lightweight Certificate Management Protocol (CMP) ProfileSiemens AGSiemens AGSiemens AG This document aims at simple, interoperable, and automated PKI
management operations covering typical use cases of industrial and
IoT scenarios. This is achieved by profiling the Certificate
Management Protocol (CMP), the related Certificate Request Message
Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct
but sufficiently detailed and self-contained way. To make secure
certificate management for simple scenarios and constrained devices
as lightweight as possible, only the most crucial types of operations
and options are specified as mandatory. More special and complex use
cases are supported as well, by features specified as recommended or
optional.
CoAP Transport for CMPV2Palo Alto NetworksPalo Alto Networks This document specifies the use of Constrained Application Protocol
(CoAP) as a transport medium for the Certificate Management Protocol
Version 2 (CMPv2) and Lightweight CMP Profile
[Lightweight-CMP-Profile] CMPv2 defines the interaction between
various PKI entities for the purpose of certificate creation and
management. CoAP is an HTTP like client-server protocol used by
various constrained devices in IoT space.
Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)Sandelman Software Worksvanderstok consultancyCisco SystemsIoTconsultancy.nl This document defines the Constrained Bootstrapping Remote Secure Key
Infrastructure (Constrained BRSKI) protocol, which provides a
solution for secure zero-touch bootstrapping of resource-constrained
(IoT) devices into the network of a domain owner. This protocol is
designed for constrained networks, which may have limited data
throughput or may experience frequent packet loss. Constrained BRSKI
is a variant of the BRSKI protocol, which uses an artifact signed by
the device manufacturer called the "voucher" which enables a new
device and the owner's network to mutually authenticate. While the
BRSKI voucher is typically encoded in JSON, Constrained BRSKI defines
a compact CBOR-encoded voucher. The BRSKI voucher is extended with
new data types that allow for smaller voucher sizes. The Enrollment
over Secure Transport (EST) protocol, used in BRSKI, is replaced with
EST-over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS.
IEEE Standard for Local and metropolitan area networks - Secure Device IdentityIEEEA secure device identifier (DevID) is cryptographically bound to a device and supports authentication of the devices identity. Locally significant identities can be securely associated with an initial manufacturer-provisioned DevID and used in provisioning and authentication protocols toallow a network administrator to establish the trustworthiness of a device and select appropriate policies for transmission and reception of data and control protocols to and from the device.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.PKCS #10: Certification Request Syntax Specification Version 1.7This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK]Certificate Management over CMS (CMC)This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK]Cryptographic Message Syntax (CMS)This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]Channel Bindings for TLSThis document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding).Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [STANDARDS-TRACK]Enrollment over Secure TransportThis document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.Simple Certificate Enrolment ProtocolThis document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates.IEC 62351 - Power systems management and associated information exchange - Data and communications security - Part 9: Cyber security key management for power system equipmentInternational Electrotechnical CommissionCyber Security - Electronic Security PerimeterNorth American Reliability CouncilISO/IEC 15118-2 Road vehicles - Vehicle-to-Grid Communication Interface - Part 2: Network and application protocol requirementsInternational Standardization Organization / International Electrotechnical CommissionSubset-137; ERTMS/ETCS On-line Key Management FFFIS; V1.0.0UNISIGhttp://www.kmc-subset137.eu/index.php/download/Open Charge Point Protocol 2.0.1 (Draft)Open Charge AllianceUsing EST for Certificate EnrollmentWhen using EST with BRSKI, pledges interact via TLS with the domain registrar,
which acts both as EST server and as registration authority (RA).
The TLS connection is mutually authenticated,
where the pledge uses its IDevID certificate issued by its manufacturer.In order to provide a strong proof-of-origin of the certification request,
EST has the option to include in the certification request
the so-called tls-unique value of the underlying TLS channel.
This binding of the proof-of-identity of the TLS client, which is supposed to
be the certificate requester, to the proof-of-possession for the private key is
conceptually non-trivial and requires specific support by TLS implementations.The registrar terminates the security association with the pledge at TLS level
and thus the binding between the certification request and the authentication
of the pledge.
The EST server uses the authenticated pledge identity provided by the IDevID
for checking the authorization of the pledge for the given certification request
before issuing to the pledge a domain-specific certificate (LDevID certificate).
This approach typically requires online or on-site availability of the RA
for performing the final authorization decision for the certification request.Using EST for BRSKI has the advantage that the mutually authenticated TLS
connection established between the pledge and the registrar can be reused
for protecting the message exchange needed for enrolling the LDevID certificate.
This strongly simplifies the implementation of the enrollment message exchange.Yet the use of TLS has the limitation that this cannot provide auditability
nor end-to-end security for the certificate enrollment request
because the TLS session is transient and terminates at the registrar.
This is a problem in particular if the enrollment is done via multiple hops,
part of which may not even be network-based.A further limitation of using EST as the certificate enrollment protocol is that
due to using PKCS#10 structures in enrollment requests,
the only possible proof-of-possession method is a self-signature, which
excludes requesting certificates for key types that do not support signing.Application ExamplesThis informative annex provides some detail to
the application examples listed in .Rolling StockRolling stock or railroad cars contain a variety of sensors,
actuators, and controllers, which communicate within the railroad car
but also exchange information between railroad cars building a train,
with track-side equipment, and/or possibly with backend systems.
These devices are typically unaware of backend system
connectivity. Managing certificates may be done during maintenance
cycles of the railroad car, but can already be prepared during
operation. Preparation will include generating certification requests,
which are collected and later 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.UNISIG has included a CMP profile for enrollment of TLS certificates of
on-board and track-side components in the Subset-137 specifying the ETRAM/ETCS
on-line key management for train control systems .Building AutomationIn building automation scenarios, a detached
building or the basement of a building may be equipped with sensors, actuators,
and controllers that are connected with each other in a local network but
with only limited or no connectivity to a central building management system.
This problem may occur during installation time but also during operation.
In such a situation a service technician collects the necessary data
and transfers it between the local network and the central building management
system, e.g., using a laptop or a mobile phone.
This data may comprise parameters and settings
required in the operational phase of the sensors/actuators, like a
component certificate issued by the operator to authenticate against other
components and services.The collected data may be provided by a domain registrar
already existing in the local network. In this case
connectivity to the backend PKI may be facilitated by the service
technician's laptop.
Alternatively, the data can also be collected from the
pledges directly and provided to a domain registrar deployed in a
different network as preparation for the operational phase.
In this case, connectivity to the domain registrar
may also be facilitated by the service technician's laptop.Substation AutomationIn electrical substation automation scenarios, a control center typically hosts
PKI services to issue certificates for Intelligent Electronic Devices
(IEDs) operated in a substation. Communication between the substation
and control center is performed through a proxy/gateway/DMZ, which
terminates protocol flows. Note that 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 several enrollment protocols in order to support the
various capabilities of IEDs from different vendors. The IEC standard
IEC62351-9 specifies mandatory
support of two enrollment protocols: SCEP and EST
for the infrastructure side, while
the IED must only support one of the two.Electric Vehicle Charging InfrastructureFor electric vehicle charging infrastructure, protocols have been
defined for the interaction between the electric vehicle and the
charging point (e.g., ISO 15118-2 )
as well as between the charging point and the charging point operator
(e.g. OCPP ). Depending on the authentication
model, unilateral or mutual authentication is required. In both cases
the charging point uses an X.509 certificate to authenticate itself
in TLS connections between the electric vehicle and
the charging point. The management of this certificate depends,
among others, on the selected backend connectivity protocol.
In the case of OCPP, this protocol is meant to be the only 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
needs to be handled in-band of OCPP. This requires the ability to
encapsulate the certificate management messages in a transport-independent way.
Authenticated self-containment will support this by
allowing the transport without a separate enrollment protocol,
binding the messages to the identity of the communicating endpoints.Infrastructure Isolation PolicyThis 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
services will be allowed in carefully controlled short periods of
time, for example when a batch of new devices is deployed, and
forbidden or prevented at other times.Sites with Insufficient Level of Operational SecurityThe registration authority performing (at least part of) the authorization of a
certification request is a critical PKI component and therefore requires higher
operational security than 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.
In case the on-site components of the target domain cannot be operated securely
enough for the needs of a registration authority, this service should be
transferred to an off-site backend component that has a sufficient level of security.History of Changes TBD RFC Editor: please deleteFrom IETF draft 01 -> IETF draft 02:Architecture: clarify registrar role including RA/LRA/enrollment proxyCMP: add reference to CoAP Transport for CMPV2 and Constrained BRSKIFrom IETF draft 05 -> IETF draft ae-01:Renamed the repo and files from anima-brski-async-enroll to anima-brski-aeAdded graphics for abstract protocol overview as suggested by Toerless EckertBalanced (sub-)sections and their headersAdded details on CMP instance, now called BRSKI-CMPFrom IETF draft 04 -> IETF draft 05:David von Oheimb became the editor.Streamline wording, consolidate terminology, improve grammar, etc.Shift the emphasis towards supporting alternative enrollment protocols.Update the title accordingly - preliminary change to be approved.Move comments on EST and detailed application examples to informative annex.Move the remaining text of section 3 as two new sub-sections of section 1.From IETF draft 03 -> IETF draft 04:Moved UC2-related parts defining the pledge in responder mode to a
separate document. This required changes and adaptations in several
sections. Main changes concerned the removal of the subsection for UC2
as well as the removal of the YANG model related text as it is not
applicable in UC1.Updated references to the Lightweight CMP Profile.Added David von Oheimb as co-author.From IETF draft 02 -> IETF draft 03:Housekeeping, deleted open issue regarding YANG voucher-request
in UC2 as voucher-request was enhanced with additional leaf.Included open issues in YANG model in UC2 regarding assertion
value agent-proximity and CSR encapsulation using SZTP sub module).From IETF draft 01 -> IETF draft 02:Defined call flow and objects for interactions in UC2. Object format
based on draft for JOSE signed voucher artifacts and aligned the
remaining objects with this approach in UC2 .Terminology change: issue #2 pledge-agent -> registrar-agent to
better underline agent relation.Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode
and pledge-responder-mode to better address the pledge operation.Communication approach between pledge and registrar-agent
changed by removing TLS-PSK (former section TLS establishment)
and associated references to other drafts in favor of relying on
higher layer exchange of signed data objects. These data objects
are included also in the pledge-voucher-request and lead to an
extension of the YANG module for the voucher-request (issue #12).Details on trust relationship between registrar-agent and
registrar (issue #4, #5, #9) included in UC2.Recommendation regarding short-lived certificates for
registrar-agent authentication towards registrar (issue #7) in
the security considerations.Introduction of reference to agent signing certificate using SKID
in agent signed data (issue #11).Enhanced objects in exchanges between pledge and registrar-agent
to allow the registrar to verify agent-proximity to the pledge
(issue #1) in UC2.Details on trust relationship between registrar-agent and
pledge (issue #5) included in UC2.Split of use case 2 call flow into sub sections in UC2.From IETF draft 00 -> IETF draft 01:Update of scope in to include in
which the pledge acts as a server. This is one main motivation
for use case 2.Rework of use case 2 to consider the
transport between the pledge and the pledge-agent. Addressed is
the TLS channel establishment between the pledge-agent and the
pledge as well as the endpoint definition on the pledge.First description of exchanged object types (needs more work)Clarification in discovery options for enrollment endpoints at
the domain registrar based on well-known endpoints in
do not result in additional
/.well-known URIs. Update of the illustrative example.
Note that the change to /brski for the voucher-related endpoints
has been taken over in the BRSKI main document.Updated references.Included Thomas Werner as additional author for the document.From individual version 03 -> IETF draft 00:Inclusion of discovery options of enrollment endpoints at
the domain registrar based on well-known endpoints in
as replacement of section 5.1.3
in the individual draft. This is intended to support both use
cases in the document. An illustrative example is provided.Missing details provided for the description and call flow in
pledge-agent use case UC2, e.g. to
accommodate distribution of CA certificates.Updated CMP example in to use
Lightweight CMP instead of CMP, as the draft already provides
the necessary /.well-known endpoints.Requirements discussion moved to separate section in
. Shortened description of proof
of identity binding and mapping to existing protocols.Removal of copied call flows for voucher exchange and registrar
discovery flow from in to avoid doubling or text or
inconsistencies.Reworked abstract and introduction to be more crisp regarding
the targeted solution. Several structural changes in the document
to have a better distinction between requirements, use case
description, and solution description as separate sections.
History moved to appendix.From individual version 02 -> 03: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.Simplification of the architecture approach for the initial use
case having an offsite PKI.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.Update of provided examples of the addressing approach used in
BRSKI to allow for support of multiple enrollment protocols in
.From individual version 01 -> 02:Update of introduction text to clearly relate to the usage of
IDevID and LDevID.Definition of the addressing approach used in BRSKI to allow for
support of multiple enrollment protocols in . This
section also contains a first
discussion of an optional discovery mechanism to address
situations in which the registrar supports more than one enrollment
approach. Discovery should avoid that the pledge performs a trial
and error of enrollment protocols.Update of description of architecture elements and
changes to BRSKI in .Enhanced consideration of existing enrollment protocols in the
context of mapping the requirements to existing solutions in
and in .From individual version 00 -> 01:Update of examples, specifically for building automation as
well as two new application use cases in .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 .Enhancement of description of architecture elements and
changes to BRSKI in .Consideration of existing enrollment protocols in the context
of mapping the requirements to existing solutions in .New section starting with the
mapping to existing enrollment protocols by collecting
boundary conditions.