Internet-Draft BRSKI-AE October 2023
von Oheimb, et al. Expires 22 April 2024 [Page]
Workgroup:
ANIMA WG
Internet-Draft:
draft-ietf-anima-brski-ae-06
Published:
Intended Status:
Standards Track
Expires:
Authors:
D. von Oheimb, Ed.
Siemens
S. Fries
Siemens
H. Brockhaus
Siemens

BRSKI-AE: Alternative Enrollment Protocols in BRSKI

Abstract

This document defines an enhancement of Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC 8995) that supports alternative certificate enrollment protocols, such as CMP. This offers the following advantages.

Using authenticated self-contained signed objects for certification requests and responses, their origin can be authenticated independently of message transfer. This supports end-to-end authentication (proof of origin) also over multiple hops, as well as asynchronous operation of certificate enrollment. This in turn provides architectural flexibility where to ultimately authenticate and authorize certification requests while retaining full-strength integrity and authenticity of certification requests.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/.

Source for this draft and an issue tracker can be found at https://github.com/anima-wg/anima-brski-ae.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any 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 22 April 2024.

▲

Table of Contents

1. Introduction

BRSKI [RFC8995] is typically used with EST as the enrollment protocol for device certificates employing HTTP over TLS for its message transfer. BRSKI-AE is a variant using alternative enrollment protocols with authenticated self-contained objects for device certificate enrollment.

This specification carries over the main characteristics of BRSKI, namely:

The goals of BRSKI-AE are to provide an enhancement of BRSKI for LDevID certificate enrollment using, alternatively to EST, a protocol that

Note: The BRSKI voucher exchange of the pledge with the registrar and MASA uses authenticated self-contained objects, so the voucher exchange already has these properties.

The well-known URI approach of BRSKI and EST messages is extended with an additional path element indicating the enrollment protocol being used.

Based on the definition of the overall approach and specific endpoints, this specification enables the registrar to offer multiple enrollment protocols, from which pledges and their developers can then pick the most suitable one.

Note: BRSKI (RFC 8995) specifies how to use HTTP over TLS, but further variants are known, such as Constrained BRSKI [I-D.ietf-anima-constrained-voucher] using CoAP over DTLS. In the sequel, 'HTTP' and 'TLS' are just references to the most common case, where variants such as using CoAP and/or DTLS are meant to be subsumed - the differences are not relevant here.

1.1. Supported Scenarios

BRSKI-AE is intended to be used situations like the following.

  • pledges and/or the target domain reusing an already established certificate enrollment protocol different from EST, such as CMP

  • scenarios indirectly excluding the use of EST for certificate enrollment, such as:

    • the RA not being co-located with the registrar while requiring end-to-end authentication of requesters, which EST does not support over multiple hops

    • the RA or CA operator requiring auditable proof of origin of CSRs, which is not possible neither with the transient source authentication provided by TLS.

    • certificate requests for types of keys that do not support signing, such as KEM and key agreement keys, which is not supported by EST because it uses PKCS#10 CSRs expecting proof-of-possession via a self-signature

    • pledge implementations using security libraries not providing EST support or a TLS library that does not support providing the so-called tls-unique value [RFC5929] needed by EST for strong binding of the source authentication

  • no full RA functionality being available on-site in the target domain, while connectivity to an off-site RA may be intermittent or entirely offline.

  • authoritative actions of a local RA at the registrar being not sufficient for fully and reliably authorizing pledge certification requests, which may be due to missing data access or due to an insufficient level of security, for instance regarding the local storage of private keys

1.2. List of Application Examples

Bootstrapping can be handled in various ways, depending on the application domains. The informative Appendix A 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 stock

  • building automation

  • electrical substation automation

  • electric vehicle charging infrastructures

  • infrastructure isolation policy

  • sites with insufficient level of operational security

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document relies on the terminology defined in [RFC8995], [RFC5280], and [IEEE_802.1AR-2018]. The following terms are described partly in addition.

asynchronous communication:

time-wise interrupted delivery of messages, here between a pledge and the registrar or an RA

authenticated self-contained object:

data structure that is cryptographically bound to the identity of its originator by an attached digital signature on the actual object, using a private key of the originator such as the IDevID secret.

backend:

placement of a domain component separately from the domain registrar; may be on-site or off-site

BRSKI-AE:

BRSKI with Alternative Enrollment, a variation of BRSKI [RFC8995] in which BRSKI-EST, the enrollment protocol between pledge and the registrar, is replaced by enrollment protocols that support end-to-end authentication of the pledge to the RA, such as Lightweight CMP.

local RA (LRA):

a subordinate RA that is close to entities being enrolled and separate from a subsequent RA. In BRSKI-AE it is needed if a backend RA is used, and in this case the LRA is co-located with the registrar.

LCMPP:

Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]

on-site:

locality of a component or service or functionality at the site of the registrar

off-site:

locality of component or service or functionality, such as RA or CA, not at the site of the registrar. This may be a central site or a cloud service, to which connection may be intermittent.

pledge:

device that is to be bootstrapped to a target domain. It requests an LDevID, a Locally significant Device IDentifier, using IDevID credentials installed by its manufacturer.

RA:

Registration Authority, the PKI component to which a CA typically delegates certificate management functions such as authenticating pledges and performing authorization checks on certification requests

registrar:

short for domain registrar

site:

the locality where an entity, such as a pledge, registrar, or PKI component is deployed. The target domain may have multiple sites.

synchronous communication:

time-wise uninterrupted delivery of messages, here between a pledge and a registrar or PKI component

target domain:

the domain that a pledge is going to be bootstrapped to

3. Basic Requirements and Mapping to Solutions

Based on the intended target scenarios described in Section 1.1 and the application examples described in Appendix A, the following requirements are derived to support authenticated self-contained objects as containers carrying certification requests.

At least the following properties are required for a certification request:

The rest of this section gives an non-exhaustive list of solution examples, based on existing technology described in IETF documents:

3.1. Solution Options for Proof of Possession

Certificate signing request (CSR) objects: CSRs are data structures protecting only the integrity of the contained data and providing proof of possession for a (locally generated) private key. Important types of CSR data structures are:

  • PKCS#10 [RFC2986]. This very common form of CSR is self-signed to protect its integrity and to prove possession of the private key that corresponds to the public key included in the request.

  • CRMF [RFC4211]. This less common but more general CSR format supports several ways of integrity protection and proof of possession- Typically a self-signature is used 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 have signing capability. For details see [RFC4211], Section 4.

Note: The integrity protection of CSRs includes the public key because it is part of the data signed by the corresponding private key. Yet this signature does not provide data origin authentication, i.e., proof of identity of the requester because the key pair involved is fresh.

3.2. Solution Options for Proof of Identity

Binding a certificate signing request (CSR) to an existing authenticated credential (the BRSKI context, the IDevID certificate) enables proof of origin, which in turn supports an authorization decision on the CSR.

The binding of data origin authentication to the CSR is typically delegated to the protocol used for certificate management. This binding may be achieved through security options in an underlying transport protocol such as TLS if the authorization of the certification request is (sufficiently) done at the next communication hop. Depending on the key type, the binding can also be done in a stronger, transport-independent way by wrapping the CSR with a signature.

This requirement is addressed by existing enrollment protocols in various ways, such as:

  • EST [RFC7030], also its variant EST-coaps [RFC9148], utilizes PKCS#10 to encode Certificate Signing Requests (CSRs). While such a CSR was not designed to include a proof of origin, there is a limited, indirect way of binding it to the source authentication of the underlying TLS session. This is achieved by including in the CSR the tls-unique value [RFC5929] resulting from the TLS handshake. As this is optionally supported by the EST "/simpleenroll" endpoint used in BRSKI and the TLS handshake employed in BRSKI includes certificate-based client authentication of the pledge with its IDevID credentials, the proof of pledge identity being an authenticated TLS client can be bound to the CSR.

    Yet this binding is only valid in the context of the TLS session established with the registrar acting as the EST server and typically also as an RA. So even such a cryptographic binding of the authenticated pledge identity to the CSR is not visible nor verifiable to authorization points outside the registrar, such as a RA in the backend. What the registrar must do is to authenticate and pre-authorize the pledge and to indicate this to the RA by signing the forwarded certificate request with its private key and a related certificate that has the id-kp-cmcRA extended key usage attribute.

    [RFC7030], Section 2.5 sketches wrapping PKCS#10-formatted CSRs with a Full PKI Request message sent to the "/fullcmc" endpoint. This would allow for source authentication at message level, such that the registrar could forward it to external RAs in a meaningful way. This approach is so far not sufficiently described and likely has not been implemented.

  • SCEP [RFC8894] supports using a shared secret (passphrase) or an existing certificate to protect CSRs based on SCEP Secure Message Objects using CMS wrapping ([RFC5652]). Note that the wrapping using an existing IDevID in SCEP is referred to as 'renewal'. This way SCEP does not rely on the security of the underlying message transfer.

  • CMP [RFC4210] 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 message transfer.

  • CMC [RFC5272] 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 [RFC5652] and signed with an existing IDevID secret. Thus also CMC does not rely on the security of the underlying message transfer.

4. Adaptations to BRSKI

To enable using alternative certificate enrollment protocols supporting end-to-end authentication, asynchronous enrollment, and more general system architectures, BRSKI-AE provides some generalizations on BRSKI [RFC8995]. This way, authenticated self-contained objects such as those described in Section 3 above can be used for certificate enrollment, and RA functionality can be distributed freely in the target domain.

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 for voucher request and response processing.

4.1. Architecture

The 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 credentials. Consequently, the certification request may be transferred using any mechanism or protocol. Authentication and authorization of the certification request can be done by the domain registrar and/or by backend domain components. As mentioned in Section 1.1, these components may be offline or off-site. The registrar and other on-site domain components may have no or only temporary (intermittent) connectivity to them.

This leads to generalizations in the placement and enhancements of the logical elements as shown in Figure 1.

Drop-Ship Vendor Service M anufacturer A uthorized Ownership S igning Tracker A uthority ......................................... . . BRSKI- . . MASA Pledge . Join Domain Proxy Registrar w/ . . ....... LRA or RA . IDevID . . BRSKI-AE over TLS . using, e.g., [LCMPP] . . . ............................... ......... on-site (local) domain components e.g., [LCMPP] ............................................. .................. . Public-Key Infrastructure . . . . Registration Authority . . CA RA (unless part of Domain Registrar) . . . ................................................................ backend (central or off-site) domain components
Figure 1: Architecture Overview Using Backend PKI Components

The architecture overview in Figure 1 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.

The following list describes the on-site components in the target domain of the pledge shown in Figure 1.

  • Join Proxy: same functionality as described in BRSKI [RFC8995], Section 4

  • Domain Registrar including LRA or RA functionality: in BRSKI-AE, the domain registrar has mostly the same functionality as in BRSKI, namely to act as the gatekeeper of the domain for onboarding new devices and to facilitate the communication of pledges with their MASA and the domain PKI. Yet there are some generalizations and specific requirements:

    1. The registrar MUST support at least one certificate enrollment protocol with authenticated self-contained objects for certification requests. To this end, the URI scheme for addressing endpoints at the registrar is generalized (see Section 4.3).

    2. Rather than having full RA functionality, the registrar MAY act as a local registration authority (LRA) and delegate part of its involvement in certificate enrollment to a backend RA, called RA. In such scenarios the registrar optionally checks certification requests it receives from pledges and forwards them to the RA. The RA performs the remaining parts of the enrollment request validation and authorization. Note that to this end the RA may need information regarding the authorization of pledges from the registrar or from other sources. On the way back, the registrar forwards responses by the PKI to the pledge on the same channel.

      Note: In order to support end-to-end authentication of the pledge across the registrar to the RA, the certification request structure signed by the pledge needs to be retained by the registrar, and the registrar cannot use for its communication with the PKI a enrollment protocol different to the one used by the pledge.

    3. The use of a certificate enrollment protocol with authenticated self-contained objects gives freedom how to transfer enrollment messages between pledge and RA. Regardless how this transfer is protected and how messages are routed, also in case that the RA is not part of the registrar it MUST be guaranteed, like in BRSKI, that the RA accepts certification requests for LDevIDs only with the consent of the registrar. See Section 7 for details how this can be achieved.

Despite of the above generalizations to the enrollment phase, the final step of BRSKI, namely the enrollment status telemetry, is kept as it is.

The following list describes the components provided by the vendor or manufacturer outside the target domain.

  • MASA: functionality as described in BRSKI [RFC8995]. The voucher exchange with the MASA via the domain registrar is performed as described in BRSKI.

    Note: From the definition of the interaction with the MASA in [RFC8995], Section 5 follows that it may be synchronous (using voucher request with nonces) or asynchronous (using nonceless voucher requests).

  • Ownership tracker: as defined in BRSKI.

The following list describes backend target domain components, which may be located on-site or off-site in the target domain.

  • RA: performs centralized certificate management functions as a 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. Otherwise, the RA co-located with the domain registrar directly connects to the CA.

  • CA, also called domain CA: generates domain-specific certificates according to certification requests that have been authenticated and authorized by the registrar and/or and an extra RA.

Based on the diagram in BRSKI [RFC8995], Section 2.1 and the architectural changes, the original protocol flow is divided into several 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).

  • Voucher status telemetry: same as in BRSKI directly after step (4).

  • Certificate enrollment phase: the use of EST in step (5) is changed to employing a certificate enrollment protocol that uses an authenticated self-contained object for requesting the LDevID certificate.

    For transporting the certificate enrollment request and response messages, the (D)TLS channel established between pledge and registrar is RECOMMENDED to use. To this end, the enrollment protocol, the pledge, and the registrar need to support the usage of the existing channel for certificate enrollment. Due to this recommended architecture, typically the pledge does not need to establish additional connections for certificate enrollment and the registrar retains full control over the certificate enrollment traffic.

  • Enrollment status telemetry: the final exchange of BRSKI step (5).

4.2. Message Exchange

The behavior of a pledge described in BRSKI [RFC8995], Section 2.1 is kept, with one major exception. After finishing the Imprint step (4), the Enroll step (5) MUST be performed with an enrollment protocol utilizing authenticated self-contained objects, as explained in Section 3. Section 5 discusses selected suitable enrollment protocols and options applicable.

An abstract overview of the BRSKI-AE protocol can be found at [BRSKI-AE-overview].

4.2.1. Pledge - Registrar Discovery

Pledges may discover registrars using the basic mechanism specified in [RFC8995], which does not provide information on specific capabilities of registrars. This optimistic approach is sufficient in engineered environments where a pledge can simply assume that all registrars discovered this way support the variant of BRSKI-AE with the certificate enrollment protocol it wants to use.

As a more general solution, the BRSKI discovery mechanism can be extended to provide beforehand to the pledge explicit information on the capabilities of a registrar, such as the certificate enrollment protocol(s) it supports. Defining such an extension is out of scope of this document. Future work such as [I-D.eckert-anima-brski-discovery] may provide this. This may be specifically helpful in non-engineered environments where pledges cannot presume that all registrars have the capabilities they need.

In the absence of better discovery mechanisms, BRSKI-AE registrars supporting only CMP but not EST SHOULD be configured to allow for RFC 8995 discovery only in engineered environments where only pledges requiring CMP are deployed. This prevents them from being discovered by pledges that assume the use of EST.

In case a pledge that uses RFC 8995 discovery and supports BRSKI-AE with only CMP gets deployed in a non-engineered environment, it might at first discover registrars that do not support CMP (but only EST). A possible strategy for the pledge in this case is to cycle through the registrars it discovered until it has found a registrar that it was able to use successfully for CMP-based enrollment.
To support such a search strategy, CMP capable BRSKI-AE registrars that are configured to allow for RFC 8995 discovery MUST NOT reject a pledge just because the log from the MASA indicates prior vouchers for this pledge from registrars that are not CMP capable.

4.2.2. Pledge - Registrar - MASA Voucher Exchange

The voucher exchange is performed as specified in [RFC8995].

4.2.3. Pledge - Registrar - MASA Voucher Status Telemetry

The voucher status telemetry is performed as specified in [RFC8995], Section 5.7.

4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment

This replaces the EST integration for PKI bootstrapping described in [RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the final phase, see below).

The certificate enrollment phase may involve transmission of several messages. Details can depend on the application scenario, the employed enrollment protocol, and other factors.

The only message exchange REQUIRED is for the actual certificate request and response. Further message exchanges MAY be performed as needed.

Note: The message exchanges marked OPTIONAL in the below Figure 2 cover all those supported by the use of EST in BRSKI. The last OPTIONAL one, namely certificate confirmation, is not supported by EST, but by CMP and other enrollment protocols.

Pledge Domain Operator Registrar RA/CA (JRC) (PKI) [OPTIONAL request of CA certificates] CA Certs Request (1) [OPTIONAL forwarding] CA Certs Request CA Certs Response CA Certs Response (2) [OPTIONAL request of attributes to include in Certificate Request] Attribute Request (3) [OPTIONAL forwarding] Attribute Req. Attribute Resp. Attribute Response (4) [REQUIRED certificate request] Certificate Request (5) [OPTIONAL forwarding] Certificate Req Certificate Resp Certificate Response (6) [OPTIONAL certificate confirmation] Certificate Confirm (7) [OPTIONAL forwarding] Certificate Conf PKI Confirm PKI/Registrar Confirm (8)
Figure 2: Certificate Enrollment

Note: Connections between the registrar and the PKI components of the operator (RA, CA, etc.) may be intermittent or off-line. Messages should be sent as soon as sufficient transfer capacity is available.

The label [OPTIONAL forwarding] in Figure 2 means that on receiving from a pledge a request message of the given type, the registrar MAY answer the request directly itself. In this case, it MUST authenticate its responses with the same credentials as used for authenticating itself at TLS level for the voucher exchange. Otherwise the registrar MUST forward the request to the RA and forward any resulting response back to the pledge.

Note: The decision whether to forward a request or to answer it directly can depend on various static and dynamic factors. They include the application scenario, the capabilities of the registrar and of the local RA possibly co-located with the registrar, the enrollment protocol being used, and the specific contents of the request.

Note: There are several options how the registrar could be able to directly answer requests for CA certificates or for certificate request attributes. It could cache responses obtained from the domain PKI and later use their contents for responding to requests asking for the same data. The contents could also be explicit provisioned at the registrar.

Note: Certificate requests typically need to be handled by the backend PKI, but the registrar can answer them directly with an error response in case it determines that such a request should be rejected, for instance because is not properly authenticated or not authorized.
Also certificate confirmation messages will usually be forwarded to the backend PKI, but if the registrar knows that they are not needed or wanted there it can acknowledge such messages directly.

The following list provides an abstract description of the flow depicted in Figure 2.

  • CA Certs Request (1): 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 (2): This MUST contain any intermediate CA certificates that the pledge may need to validate certificates and MAY contain the LDevID trust anchor.

  • Attribute Request (3): 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 may be used.

    For example, [RFC8994], Section 6.11.7.2 specifies how the attribute request is used to signal to the pledge the acp-node-name field required for enrollment into an ACP domain.

  • Attribute Response (4): This MUST contain the attributes to be included in the subsequent certification request.

  • Certificate Request (5): This 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 (6): This MUST contain on success the requested certificate and MAY include further information, like certificates of intermediate CAs and any additional trust anchors.

  • Certificate Confirm (7): An optional confirmation sent after the requested certificate has been received and validated. If sent, it MUST contain a positive or negative confirmation by the pledge to the PKI whether the certificate was successfully enrolled and fits its needs.

  • PKI/Registrar Confirm (8): An acknowledgment by the PKI that MUST be sent on reception of the Cert Confirm.

The generic messages described above may be implemented using any certificate enrollment protocol that supports authenticated self-contained objects for the certificate request as described in Section 3. Examples are available in Section 5.

Note that the optional certificate confirmation by the pledge to the PKI described above is independent of the mandatory enrollment status telemetry done between the pledge and the registrar in the final phase of BRSKI-AE, described next.

4.2.5. Pledge - Registrar Enrollment Status Telemetry

The enrollment status telemetry is performed as specified in [RFC8995], Section 5.9.4.

In BRSKI this is described as part of the certificate enrollment step, but due to the generalization on the enrollment protocol described in this document its regarded as a separate phase here.

4.3. Enhancements to the Endpoint Addressing Scheme of BRSKI

BRSKI-AE provides generalizations to the addressing scheme defined in BRSKI [RFC8995], Section 5 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 employed without modifications to existing RAs/CAs supporting the respective enrollment protocol (see also Section 5).

The addressing scheme in BRSKI for certification requests and the related CA certificates and CSR attributes retrieval functions uses the definition from EST [RFC7030], 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 to provide maximal compatibility with BRSKI:

  • <enrollment-protocol>: MUST reference the protocol being used. Existing values include 'est' [RFC7030] as in BRSKI and 'cmp' as in [I-D.ietf-lamps-lightweight-cmp-profile] and Section 5.1 below. Values for other existing protocols such as CMC and SCEP, or for newly defined protocols are outside the scope of this document. For use of the <enrollment-protocol> and <request> URI components, they would need to specified in a suitable RFC and placed into the Well-Known URIs registry, like done for EST in [RFC7030].

  • <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 Section 5).

Well-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.

A pledge SHOULD use the endpoints defined for the enrollment protocol(s) that it is capable of and is willing to use. It will recognize whether its preferred protocol or the request that it tries to perform is understood and supported by the domain registrar by sending a request to its preferred enrollment endpoint according to the above addressing scheme and evaluating the HTTP status code in the response. If the pledge uses endpoints that are not standardized, it risks that the registrar does not recognize and accept them even if supporting the intended protocol and operation.

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 [I-D.ietf-lamps-cmp-updates] and the Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile].

  </brski/voucherrequest>,ct=voucher-cms+json
  </brski/voucher_status>,ct=json
  </brski/enrollstatus>,ct=json
  </est/cacerts>;ct=pkcs7-mime
  </est/csrattrs>;ct=pkcs7-mime
  </est/fullcmc>;ct=pkcs7-mime
  </cmp/getcacerts>;ct=pkixcmp
  </cmp/getcertreqtemplate>;ct=pkixcmp
  </cmp/initialization>;ct=pkixcmp
  </cmp/p10>;ct=pkixcmp

5. Instantiation to Existing Enrollment Protocols

This section maps the generic requirements to support proof of possession and proof of identity to selected existing certificate enrollment protocols and specifies further aspects of using such enrollment protocols in BRSKI-AE.

5.1. BRSKI-CMP: Instantiation to CMP

Instead of referring to CMP as specified in [RFC4210] and [I-D.ietf-lamps-cmp-updates], this document refers to the Lightweight CMP Profile (LCMPP) [I-D.ietf-lamps-lightweight-cmp-profile] because the subset of CMP defined there is sufficient for the functionality needed here.

When using CMP, adherence to the LCMPP [I-D.ietf-lamps-lightweight-cmp-profile] is mandatory. In particular, the following specific requirements apply (cf. Figure 2).

Note: The way in which messages are exchanged between the registrar and backend PKI components (i.e., RA or CA) is out of scope of this document. Due to the general independence of CMP of message transfer, it can be freely chosen according to the needs of the application scenario (e.g., using HTTP), while security considerations apply, see Section 7, and guidance can be found in [I-D.ietf-lamps-lightweight-cmp-profile], Section 6.

BRSKI-AE with CMP can also be combined with Constrained BRSKI [I-D.ietf-anima-constrained-voucher], using CoAP for enrollment message transport as described by CoAP Transport for CMP [I-D.ietf-ace-cmpv2-coap-transport]. In this scenario, of course the EST-specific parts of [I-D.ietf-anima-constrained-voucher] do not apply.

5.2. Support of Other Enrollment Protocols

Further instantiations of BRSKI-AE can be done. They are left for future work.

In particular, CMC [RFC5272] (using its in-band source authentication options) and SCEP [RFC8894] (using its 'renewal' option) could be used.

The fullCMC variant of EST sketched in [RFC7030], Section 2.5 might also be used here. For EST-fullCMC further specification is necessary.

6. IANA Considerations

This document does not require IANA actions.

7. Security Considerations

The security considerations laid out in BRSKI [RFC8995] apply for the discovery and voucher exchange as well as for the status exchange information.

In particular, even if the registrar delegates part or all of its RA role during certificate enrollment to a separate system, it still must be made sure that the registrar takes part in the decision on accepting or declining a request to join the domain, as required in [RFC8995], Section 5.3. As this pertains also to obtaining a valid domain-specific certificate, it must be made sure that a pledge cannot circumvent the registrar in the decision whether it is granted an LDevID certificate by the CA. There are various ways how to fulfill this, including:

Note: If EST was used, the registrar could give implicit consent on a certification request by forwarding the request to a PKI entity using a connection authenticated with a certificate containing an id-kp-cmcRA extension.

When CMP is used, the security considerations laid out in the LCMPP [I-D.ietf-lamps-lightweight-cmp-profile] apply.

Note that CMP messages are not encrypted. This may give eavesdroppers insight on which devices are bootstrapped in the domain, and this in turn might also be used to selectively block the enrollment of certain devices. To prevent this, the underlying message transport channel can be encrypted, for instance by employing TLS. On the link between the pledge and the registrar this is easily achieved by reusing the existing TLS channel between them.

8. Acknowledgments

We thank Eliot Lear for his contributions as a co-author at an earlier draft stage.

We thank Brian E. Carpenter, Michael Richardson, and Giorgio Romanenghi for their input and discussion on use cases and call flows.

Moreover, we thank Toerless Eckert, Barry Lea, Michael Richardson, Rajeev Ranjan, and Rufus Buschart for their reviews with suggestions for improvements.

9. References

9.1. Normative References

[I-D.ietf-lamps-cmp-updates]
Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate Management Protocol (CMP) Updates", Work in Progress, Internet-Draft, draft-ietf-lamps-cmp-updates-23, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates-23>.
[I-D.ietf-lamps-lightweight-cmp-profile]
Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight Certificate Management Protocol (CMP) Profile", Work in Progress, Internet-Draft, draft-ietf-lamps-lightweight-cmp-profile-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile-21>.
[IEEE_802.1AR-2018]
IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity", IEEE 802.1AR-2018, DOI 10.1109/IEEESTD.2018.8423794, , <https://doi.org/10.1109/IEEESTD.2018.8423794>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[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, , <https://www.rfc-editor.org/rfc/rfc4210>.
[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, , <https://www.rfc-editor.org/rfc/rfc5280>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8995]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, , <https://www.rfc-editor.org/rfc/rfc8995>.

9.2. Informative References

[BRSKI-AE-overview]
S. Fries and D. von Oheimb, "BRSKI-AE Protocol Overview", , <https://datatracker.ietf.org/meeting/116/materials/slides-116-anima-update-on-brski-ae-alternative-enrollment-protocols-in-brski-00>. Graphics on slide 4 of the BRSKI-AE draft 04 status update at IETF 116.
[I-D.eckert-anima-brski-discovery]
Eckert, T. T., "Discovery for BRSKI variations", Work in Progress, Internet-Draft, draft-eckert-anima-brski-discovery-00, , <https://datatracker.ietf.org/doc/html/draft-eckert-anima-brski-discovery-00>.
[I-D.ietf-ace-cmpv2-coap-transport]
Sahni, M. and S. Tripathi, "CoAP Transfer for the Certificate Management Protocol", Work in Progress, Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-cmpv2-coap-transport-10>.
[I-D.ietf-anima-constrained-voucher]
Richardson, M., Van der Stok, P., Kampanakis, P., and E. Dijk, "Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)", Work in Progress, Internet-Draft, draft-ietf-anima-constrained-voucher-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher-21>.
[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, .
[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-2, .
[NERC-CIP-005-5]
North American Reliability Council, "Cyber Security - Electronic Security Perimeter", CIP 005-5, .
[OCPP]
Open Charge Alliance, "Open Charge Point Protocol 2.0.1 (Draft)", .
[RFC2986]
Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, , <https://www.rfc-editor.org/rfc/rfc2986>.
[RFC4211]
Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, , <https://www.rfc-editor.org/rfc/rfc4211>.
[RFC5272]
Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, , <https://www.rfc-editor.org/rfc/rfc5272>.
[RFC5652]
Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, , <https://www.rfc-editor.org/rfc/rfc5652>.
[RFC5929]
Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, , <https://www.rfc-editor.org/rfc/rfc5929>.
[RFC7030]
Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, , <https://www.rfc-editor.org/rfc/rfc7030>.
[RFC8894]
Gutmann, P., "Simple Certificate Enrolment Protocol", RFC 8894, DOI 10.17487/RFC8894, , <https://www.rfc-editor.org/rfc/rfc8894>.
[RFC8994]
Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An Autonomic Control Plane (ACP)", RFC 8994, DOI 10.17487/RFC8994, , <https://www.rfc-editor.org/rfc/rfc8994>.
[RFC9148]
van der Stok, P., Kampanakis, P., Richardson, M., and S. Raza, "EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol", RFC 9148, DOI 10.17487/RFC9148, , <https://www.rfc-editor.org/rfc/rfc9148>.
[UNISIG-Subset-137]
UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management FFFIS; V1.0.0", , <https://www.era.europa.eu/sites/default/files/filesystem/ertms/ccs_tsi_annex_a_-_mandatory_specifications/set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-_subset-137_v100.pdf>. http://www.kmc-subset137.eu/index.php/download/

Appendix A. Application Examples

This informative annex provides some detail to the application examples listed in Section 1.2.

A.1. Rolling Stock

Rolling 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 forming a train, with track-side equipment, and/or possibly with backend systems. These devices are typically unaware of backend system connectivity. Enrolling certificates may be done during maintenance cycles of the railroad car, but can already be prepared during operation. Such asynchronous enrollment will include generating certification requests, which are collected and later forwarded for processing whenever the railroad car gets connectivity with the backend PKI of the operator. 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 client and server X.509 certificates of on-board and track-side components in the Subset-137 specifying the ETRAM/ETCS online key management for train control systems [UNISIG-Subset-137].

A.2. Building Automation

In 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.

A.3. Substation Automation

In electrical substation automation scenarios, a control center typically hosts PKI services to issue certificates for Intelligent Electronic Devices operated in a substation. Communication between the substation and control center is performed through a proxy/gateway/DMZ, which terminates protocol flows. Note that [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 several enrollment protocols in order to support the various capabilities of IEDs from different vendors. The IEC standard IEC62351-9 [IEC-62351-9] specifies for the infrastructure side mandatory support of two enrollment protocols: SCEP [RFC8894] and EST [RFC7030], while an Intelligent Electronic Device may support only one of them.

A.4. Electric Vehicle Charging Infrastructure

For electric vehicle charging infrastructure, protocols have been defined for the interaction between the electric vehicle 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 uses an X.509 certificate to authenticate itself in TLS channels 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.

A.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 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.

A.6. Sites with Insufficient Level of Operational Security

The RA 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 from RAs, which domain registrars with co-located RAs may not be able to fulfill. Especially the CA/Browser forum currently increases the security requirements in the certificate issuance procedures for publicly trusted certificates, i.e., those placed in trust stores of browsers, which may be used to connect with devices in the domain. In case the on-site components of the target domain cannot be operated securely enough for the needs of an RA, this service should be transferred to an off-site backend component that has a sufficient level of security.

Appendix B. History of Changes TBD RFC Editor: please delete

List of reviewers:

IETF draft ae-05 -> ae-06:

IETF draft ae-04 -> ae-05:

IETF draft ae-03 -> ae-04:

IETF draft ae-02 -> ae-03:

IETF draft ae-01 -> ae-02:

From IETF draft 05 -> IETF draft ae-01:

From IETF draft 04 -> IETF draft 05:

From IETF draft 03 -> IETF draft 04:

From IETF draft 02 -> IETF draft 03:

From IETF draft 01 -> IETF draft 02:

From IETF draft 00 -> IETF draft 01:

From individual version 03 -> IETF draft 00:

From individual version 02 -> 03:

From individual version 01 -> 02:

From individual version 00 -> 01:

Contributors

Eliot Lear
Cisco Systems
Richtistrasse 7
CH-8304 Wallisellen
Switzerland
Phone: +41 44 878 9200

Authors' Addresses

David von Oheimb (editor)
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
URI: https://www.siemens.com/
Steffen Fries
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
URI: https://www.siemens.com/
Hendrik Brockhaus
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
URI: https://www.siemens.com/