Movatterモバイル変換

[0]ホーム
URL:


Internet-DraftBRSKI-AEMarch 2022
von Oheimb, et al.Expires 8 September 2022[Page]
Workgroup:
ANIMA WG
Internet-Draft:
draft-ietf-anima-brski-async-enroll-05
Published:
Intended Status:
Standards Track
Expires:
Authors:
D. von Oheimb,Ed.
Siemens
S. Fries
Siemens
H. Brockhaus
Siemens
E. Lear
Cisco Systems

BRSKI-AE: Alternative Enrollment Protocols in BRSKI

Abstract

This document enhancesBootstrapping Remote Secure Key Infrastructure (BRSKI,[RFC8995])to allow employing alternative enrollment protocols, such as CMP.

Using self-contained signed objects, the origin of enrollment requests and responsescan be authenticated independently of message transfer.This supports end-to-end security and asynchronous operation of certificate enrollmentand provides flexibility where to authenticate and authorize certification requests.

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 athttps://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 8 September 2022.

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

▲

Table of Contents

1.Introduction

1.1.Motivation

BRSKI, as defined in[RFC8995], specifies a solution forsecure 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 informationnecessary 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[RFC8366].Such a voucher is a self-contained signed objectoriginating from a Manufacturer Authorized Signing Authority (MASA).Therefore, the voucher may be providedin online mode (synchronously) or offline mode (asynchronously).The pledge can authenticate the voucherbecause it is shipped with a trust anchor of its manufacturer such thatit can validate signatures (including related certificates) by the MASA.

Trust by the target domain in a pledge is established by providing the pledgewith a domain-specific LDevID certificate.The certification request of the pledge is signed using its IDevID secret and can bevalidated 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)[RFC7030].EST has its specific characteristics, detailed inAppendix A.In particular, it requires online or on-site availability of the RAfor performing the data origin authentication and final authorization decisionon 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 asthe Certificate Management Protocol (CMP)[RFC4210]profiled in[I-D.ietf-lamps-lightweight-cmp-profile]or Certificate Management over CMS (CMC)[RFC5272].that are more flexible and independent of the transfer mechanism because theyrepresent 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 beprovided by remote backend systems. The registrar or its deployment site may not havean online connection with them or the connectivity may be intermittent.This may be due to security requirements for operating the backend systemsor due to site deployments where on-site or always-online operationmay be not feasible or too costly.In such scenarios, the authentication and authorization of certification requestswill not or can not be performed on-site at enrollment time.In this document, enrollment that is not performed in a (time-wise) consistentway is calledasynchronous enrollment.Asynchronous enrollment requires a store-and-forward transfer of certificationrequests along with the information needed for authenticating the requester.This allows offline processing the request.

Application scenarios may also involve network segmentation, which is utilizedin industrial systems to separate domains with different security needs.Such scenarios lead to similar requirements if the TLS connectioncarrying the requester authentication is terminatedand thus request messages need to be forwarded on further channelsbefore the registrar/RA can authorize the certification request.In order to preserve the requester authentication, authentication informationneeds to be retained and ideally bound directly to the certification request.

There are basically two approaches for forwarding certification requestsalong with requester authentication information:

  • A trusted component (e.g., a local RA) in the target domain is neededthat forwards the certification request combined with the validated identity ofthe requester (e,g., its IDevID certificate)and an indication of successful verification ofthe proof-of-possession (of the corresponding private key) in a waypreventing changes to the combined information.When connectivity is available, the trusted componentforwards 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 resultprovided by the local RAwhen 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 authenticationin 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 informationcan be detected during the validation of the self-contained signed object.

Focus of this document is the support of alternative enrollment protocols that allowusing 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 informationfor authenticating the domain registrar and other target domain componentsas 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 to

  • support alternative enrollment protocols,
  • support end-to-end security for enrollment, and
  • make it applicable to scenarios involving asynchronous enrollment.

This is achieved by

  • extending the well-known URI approach with an additional path elementindicating the enrollment protocol being used, and
  • defining a certificate waiting indication and handling, for the case that thecertifying 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 protocolson the infrastructure side, which enables pledges and their developersto pick the preferred one.

1.2.Supported environment

BRSKI-AE is intended to be used in domains that may have limited supportof on-site PKI services and comprises application scenarios like the following.

  • There are requirements or implementation restrictionsthat do not allow using EST for enrolling an LDevID certificate.
  • Pledges and/or the target domain already have an establishedcertificate 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 usedfor communicating with the off-site services.
  • Authoritative actions of a local RA are limited and may not be sufficientfor authorizing certification requests by pledges.Final authorization is done by an RA residing in the operator domain.

1.3.List of application examples

Bootstrapping can be handled in various ways, depending on the application domains.The informativeAppendix B provides illustrative examples fromvarious 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 asdescribed in BCP 14[RFC2119][RFC8174] when, and only when, theyappear in all capitals, as shown here.

This document relies on the terminology defined in[RFC8995]and[IEEE.802.1AR_2009].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 systemcomponent to which a CA delegates certificate management functionssuch as authenticating requesters and performing authorization checkson certification requests.

CA:

Certification authority, issues certificatesand 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 orfunctionality available in the target deployment site.

off-site:

Describes a component or service orfunctionality available in an operator site different fromthe target deployment site. This may be a central site or acloud service, to which only a temporary connection is available.

asynchronous communication:

Describes a time-wise interrupted communicationbetween a pledge (EE) and a registrar or PKI component.

synchronous communication:

Describes a time-wise uninterrupted communicationbetween a pledge (EE) and a registrar or PKI component.

authenticated self-contained object:

Describes in this context an objectthat is cryptographically bound to the IDevID certificate of a pledge.The binding is assumed to be provided through a digital signatureof the actual object using the IDevID secret.

3.Requirements discussion and mapping to solution elements

There were two main drivers for the definition of BRSKI-AE:

  • The solution architecture may already use or requirea 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 authorizescertification 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 inSection 1.2 andthe application examples described inAppendix B, the followingrequirements are derived to support authenticated self-contained objectsas containers carrying certification requests.

At least the following properties are required:

  • proof-of-possession: demonstrates access to the privatekey 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 ofthe certification request. This typically is achieved by a signatureusing the IDevID secret of the pledge.

Here is an incomplete list of solution examples,based on existing technology described in IETF documents:

  • Certification request objects: Certification requests aredata structures protecting only the integrity of the contained dataand providing proof-of-possession for a (locally generated) private key.Examples for certification request data structures are:

    • PKCS#10[RFC2986]. This certification request structure is self-signed toprotect its integrity and prove possession of the private keythat corresponds to the public key included in the request.
    • CRMF[RFC4211]. Also this certificate request message format supportsintegrity protection and proof-of-possession,typically by a self-signature generated over (part of) the structurewith the private key corresponding to the included public key.CRMF also supports further proof-of-possession methodsfor types of keys that do not support any signature algorithm.

    The integrity protection of certification request fields includes the publickey 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 dataorigin authentication, i.e., proof-of-identity. This extra property can beachieved by an additional binding to the IDevID of the pledge.This binding to source authentication supports theauthorization decision for the certification request. The binding of dataorigin authentication to the certification request may bedelegated to the protocol used for certificate management.

  • Solution options for proof-of-identity: The certification request should be bound toan existing authenticated credential (here, the IDevID certificate) to enable a proofof identity and, based on it, an authorization of the certification request.The binding may be achieved through security options in anunderlying transport protocol such as TLS if the authorization of thecertification request is (completely) done at the next communication hop.This binding can also be done in a transport-independent way by wrapping thecertification request with signature employing an existing IDevID.the BRSKI context, this will be the IDevID.This requirement is addressed by existing enrollment protocolsin various ways, such as:

    • EST[RFC7030] utilizes PKCS#10 toencode the certification request. The Certificate SigningRequest (CSR) optionally provides a binding to the underlying TLS sessionby 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 clientauthentication 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 underlyingTLS authentication in the transport layer,[RFC7030] sketches wrapping the CSRwith a Full PKI Request message using an existing certificate.
    • SCEP[RFC8894] supports using a shared secret (passphrase) oran existing certificate to protect CSRs based onSCEP Secure Message Objects using CMS wrapping([RFC5652]). Note that the wrapping usingan existing IDevID in SCEP is referred to as renewal.Thus SCEP does not rely on the security of the underlying transfer.
    • CMP[RFC4210] supports using a shared secret (passphrase) or an existingcertificate, which may be an IDevID credential, to authenticatecertification 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[RFC5272] also supports utilizing a shared secret (passphrase) oran 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 CMC does not rely on the security of the underlying transfer protocol.

4.Adaptations to BRSKI

In order to support alternative enrollment protocols, asynchronous enrollment,and more general system architectures,BRSKI-AE lifts some restrictions of BRSKI[RFC8995].This way, authenticated self-contained objects such as those described inSection 3 above can be used for certificate enrollment.

The enhancements needed are kept to a minimum in order to ensure reuse ofalready defined architecture elements and interactions.In general, the communication follows the BRSKI model and utilizes the existingBRSKI architecture elements.In particular, the pledge initiates communication with the domain registrarand interacts with the MASA as usual.

4.1.Architecture

The key element of BRSKI-AE is that the authorization of a certification requestMUST be performed based on an authenticated self-contained object.The certification request is bound in a self-contained wayto a proof-of-origin based on the IDevID.Consequently, the authentication and authorization of the certification requestMAY be done by the domain registrar and/or by other domain components. These componentsmay be offline or reside in some central backend of the domain operator (off-site)as described inSection 1.2. The registrar and other on-site domain componentsmay have no or only temporary (intermittent) connectivity to them.The certification requestMAY also be piggybacked on another protocol.

This leads to generalizations in theplacement and enhancements of the logical elements as shown inFigure 1.

                                           +------------------------+   +--------------Drop-Ship--------------->| Vendor Service         |   |                                       +------------------------+   |                                       | M anufacturer|         |   |                                       | A uthorized  |Ownership|   |                                       | S igning     |Tracker  |   |                                       | A uthority   |         |   |                                       +--------------+---------+   |                                                      ^   |                                                      |   V                                                      |+--------+     .........................................  ||        |     .                                       .  | BRSKI-|        |     .  +------------+       +------------+  .  | MASA| Pledge |     .  |   Join     |       | Domain     <-----+|        |     .  |   Proxy    |       | Registrar/ |  .|        <-------->............<-------> Enrollment |  .|        |     .  |        BRSKI-AE    | Proxy/LRA  |  .| IDevID |     .  |            |       +------^-----+  .|        |     .  +------------+              |        .|        |     .                              |        .+--------+     ...............................|.........                on-site "domain" components   |                                              | e.g., RFC 4210,                                              |       RFC 7030, ... .............................................|..................... . +---------------------------+     +--------v------------------+ . . | Public-Key Infrastructure <-----+ Registration Authority    | . . | PKI CA                    +-----> PKI RA                    | . . +---------------------------+     +---------------------------+ . ...................................................................         off-site or central "domain" components
Figure 1:Architecture overview using off-site PKI components

The architecture overview inFigure 1has the same logical elements as BRSKI, but with more flexible placementof the authentication and authorization checks on certification requests.Depending on the application scenario, the registrarMAY still do all of thesechecks (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 domainof the pledge shown inFigure 1.

  • Join Proxy: same functionality as described in BRSKI[RFC8995].

  • Domain Registrar / Enrollment Proxy / LRA: in BRSKI-AE,the domain registrar has mostly the same functionality as in BRSKI, namelyto facilitate the communication of the pledge with the MASA and the PKI.Yet in contrast to BRSKI, the registrar offers different enrollment protocolsandMAY act as a local registration authority (LRA) or simply as an enrollment proxy.In such cases, the domain registrar forwards the certification requestto some off-site RA component, which performs at least part of the authorization.This also covers the case that the registrar has only intermittent connectionand forwards the certification request to the RA upon re-established connectivity.

    Note: To support alternative enrollment protocols, the URI schemefor addressing the domain registrar is generalized (seeSection 4.2.5).

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

  • MASA: general functionality as described in BRSKI[RFC8995].The voucher exchange with the MASA via the domain registraris 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 beoperated in the off-site backend of the target domain.

  • PKI RA: Performs certificate management functions for the domainas a centralized public-key infrastructure for the domain operator.As far as not already done by the domain registrar, it performs the finalvalidation and authorization of certification requests.
  • PKI CA: Performs certificate generation by signing the certificate structurerequested in already authenticated and authorized certification requests.

Based on the diagram in Section 2.1 of BRSKI[RFC8995] and the architectural changes,the original protocol flow is divided into three phases showing commonalitiesand 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 protocolthat uses authenticated self-contained objects.

4.2.Message exchange

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

4.2.1.Pledge - Registrar discovery and voucher exchange

The discovery phase and voucher exchange are applied as specified in[RFC8995].

4.2.2.Registrar - MASA voucher exchange

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

4.2.3.Pledge - Registrar - RA/CA certificate enrollment

As stated inSection 3, the enrollmentMUST beperformed using an authenticated self-contained object providingnot only proof-of-possession but also proof-of-identity (source authentication).

+--------+                        +------------+     +------------+| Pledge |                        | Domain     |     | Operator   ||        |                        | Registrar  |     | RA/CA      ||        |                        |  (JRC)     |     | (OPKI)     |+--------+                        +------------+     +------------+  /-->                                      |                    |[Optional request of CA certificates]       |                    |  |---------- CA Certs Request ------------>|                    |  |              [if connection to operator domain is available] |  |                                         |-Request CA Certs ->|  |                                         |<-CA Certs Response-|  |<-------- CA Certs Response--------------|                    |  /-->                                      |                    |[Optional request of attributes to be included in Cert Request]  |  |---------- Attribute Request ----------->|                    |  |              [if connection to operator domain is available] |  |                                         |-Attribute Request->|  |                                         |<- Attrib Response -|  |<--------- Attribute Response -----------|                    |  /-->                                      |                    |[Certification request]                     |                    |  |-------------- Cert Request ------------>|                    |  |      [when connection to off-site components is unavailable] |  |<----- optional: Cert Waiting Response --|                    |  |                                         |                    |  |-------optional: Cert Polling ---------->|                    |  |                                         |                    |  |        [when connection to off-site components is available] |  |                                         |--- Cert Request -->|  |                                         |<-- Cert Response --|  |<------------- Cert Response ------------|                    |  /-->                                      |                    |[Optional certificate confirmation]         |                    |  |-------------- Cert Confirm ------------>|                    |  |                                         |--- Cert Confirm -->|  |                                         |<-- PKI Confirm ----|  |<------------- PKI/Registrar Confirm ----|                    |
Figure 2:Certificate enrollment

The following list provides an abstract description of the flowdepicted inFigure 2.

  • CA Cert Request: The pledge optionally requests the latest relevantCA certificates. This ensures that the pledge has thecomplete set of current CA certificates beyond thepinned-domain-cert (which is contained in the voucherand may be just the domain registrar certificate).
  • CA Cert Response: ItMUST contain the current root CA certificate,which typically is the LDevID trust anchor, and any additional certificatesthat the pledge may need to validate certificates.
  • Attribute Request: Typically, the automated bootstrapping occurswithout local administrative configuration of the pledge.Nevertheless, there are cases in which the pledge may alsoinclude additional attributes specific to the target domaininto the certification request. To get these attributes inadvance, the attribute request can be used.
  • Attribute Response: ItMUST contain the attributes to be includedin the subsequent certification request.
  • Cert Request: This certification requestMUST contain theauthenticated self-contained object ensuring both proof-of-possession of thecorresponding private key and proof-of-identity of the requester.
  • Cert Response: The certification response messageMUST contain on successthe requested certificate andMAY include further information,like certificates of intermediate CAs.
  • Cert Waiting Response: Optional waiting indication for the pledge,whichSHOULD poll for a Cert Response after a given time.To this end, a request identifier is necessary.The request identifier may be either part of the enrollmentprotocol or can be derived from the certification request.
  • Cert Polling: ThisSHOULD be used by the pledge in reaction toa Cert Waiting Response to query the registrarwhether the certification request meanwhile has been processed.ItMUST be answered either by another Cert Waiting, or the Cert Response.
  • Cert Confirm: An optional confirmation sent after the requested certificatehas been received and validated.It contains a positive or negative confirmation by the pledge whetherthe certificate was successfully enrolled and fits its needs.
  • PKI/Registrar Confirm: An acknowledgment by the PKI or registrarthatMUST be sent on reception of the Cert Confirm.

The generic messages described above may be implemented using variousenrollment protocols supporting authenticated self-contained objects,as described inSection 3. Examples are available inSection 5.

4.2.4.Pledge - Registrar - enrollment status telemetry

The enrollment status telemetry is performed as specified in[RFC8995].In BRSKI this is described as part of the enrollment phase,but due to the generalization on the enrollment protocol described in this documentit fits better as a separate step here.

4.2.5.Addressing scheme enhancements

BRSKI-AE provides generalizations to the addressing scheme defined inBRSKI[RFC8995] to accommodate alternative enrollment protocols thatuse authenticated self-contained objects for certification requests.As this is supported by various existing enrollment protocols,they can be directly employed (see alsoSection 5).

The addressing scheme in BRSKI for certification requests andthe related CA certificates and CSR attributes retrieval functionsuses the definition from EST[RFC7030]; here on theexample 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 sequencethat 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, whichMAY be CMP, CMC, SCEP, EST[RFC7030] as in BRSKI, or a newly defined approach.

    Note: additional endpoints (well-known URIs) at the registrarmay need to be defined by the enrollment protocol being used.

  • <request>: if present, the <request> path componentMUST 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 alsoSection 5).

4.3.Domain registrar support of alternative enrollment protocols

Well-known URIs for various endpoints on the domain registrar arealready defined as part of the base BRSKI specification or indirectly by EST.In addition, alternative enrollment endpointsMAY be supported at the registrar.The pledge will recognize whether itspreferred enrollment option is supported by the domain registrarby sending a request to its preferred enrollment endpointand evaluating the HTTP response status code.

The following list of endpoints provides an illustrative example fora domain registrar supporting several options for EST as well as forCMP to be used in BRSKI-AE. The listing contains the supportedendpoints to which the pledge may connect for bootstrapping. Thisincludes the voucher handling as well as the enrollment endpoints.The CMP related enrollment endpoints are defined as well-known URIsin 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/fullcmc>;ct=pkcs7-mime  </est/csrattrs>;ct=pkcs7-mime  </cmp/initialization>;ct=pkixcmp  </cmp/p10>;ct=pkixcmp  </cmp/getcacerts>;ct=pkixcmp  </cmp/getcertreqtemplate>;ct=pkixcmp

5.Examples for signature-wrapping using existing enrollment protocols

This section maps the requirements to support proof-of-possession andproof-of-identity to selected existing enrollment protocols.

5.1.Instantiation to EST (informative)

When using EST[RFC7030], the following aspects and constraintsneed to be considered and the given extra requirements need to be fulfilled,which adapt Section 5.9.3 of BRSKI[RFC8995]:

  • proof-of-possession is provided typically by using the specified PKCS#10structure in the request.Together with Full PKI requests, also CRMF can be used.

  • proof-of-identity needs to be achieved by signing the certification requestobject using the Full PKI Request option (including the /fullcmc endpoint).This provides sufficient information for the RA to authenticate the pledgeas the origin of the request and to make an authorization decision on thereceived certification request.Note: EST references CMC[RFC5272] for thedefinition of the Full PKI Request. For proof-of-identity, thesignature of the SignedData of the Full PKI Request isperformed 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[RFC7030],an HTTP status code 202 should be returned by the registrar,and the pledge will repeat the initial Full PKI Request

5.2.Instantiation to CMP (normative if CMP is chosen)

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

When using CMP, the following requirementsSHALL be fulfilled:

  • For proof-of-possession, the approach defined in Section 4.1.1 (based on CRMF)or Section 4.1.4 (based on PKCS#10) of the Lightweight CMP Profile[I-D.ietf-lamps-lightweight-cmp-profile]SHALL be applied.
  • proof-of-identitySHALL be provided by using signature-basedprotection of the certification request message as outlined inSection 3.2. of[I-D.ietf-lamps-lightweight-cmp-profile] using the IDevID secret.
  • When the Cert Response from the RA/CA is not available and if polling is supported,the registrarSHALL a Cert Waiting Response as specified inSections 4.4 and 5.1.2 of[I-D.ietf-lamps-lightweight-cmp-profile].
  • As far as requesting CA certificates or certificate request attributes is supported,theySHALL be implemented as specified inSections 4.3.1 and 4.3.3 of[I-D.ietf-lamps-lightweight-cmp-profile].

TBD RFC Editor: please delete /* ToDo:The following aspects need to be further specified:* Whether to use /getcacerts or the caPubs and extraCerts fields to return trust anchor and CA Certificates* Whether to use /getcertreqtemplate or modify the CRMF and use raVerified* Whether to specify the usage of /p10 */

6.IANA Considerations

This document does not require IANA actions.

7.Security Considerations

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

The security considerations as laid out in the Lightweight CMP Profile[I-D.ietf-lamps-lightweight-cmp-profile] apply as far as CMP is used.

8.Acknowledgments

We would like to thankBrian E. Carpenter, Michael Richardson, and Giorgio Romanenghifor their input and discussion on use cases and call flows.

9.References

9.1.Normative References

[I-D.ietf-lamps-cmp-updates]
Brockhaus, H.,Oheimb, D. V., andJ. Gray,"Certificate Management Protocol (CMP) Updates",Work in Progress,Internet-Draft, draft-ietf-lamps-cmp-updates-17,,<https://www.ietf.org/archive/id/draft-ietf-lamps-cmp-updates-17.txt>.
[I-D.ietf-lamps-lightweight-cmp-profile]
Brockhaus, H.,Oheimb, D. V., andS. Fries,"Lightweight Certificate Management Protocol (CMP) Profile",Work in Progress,Internet-Draft, draft-ietf-lamps-lightweight-cmp-profile-10,,<https://www.ietf.org/archive/id/draft-ietf-lamps-lightweight-cmp-profile-10.txt>.
[IEEE.802.1AR_2009]
IEEE,"IEEE Standard for Local and metropolitan area networks - Secure Device Identity",IEEE 802.1AR-2009,DOI 10.1109/ieeestd.2009.5367679,,<http://ieeexplore.ieee.org/servlet/opac?punumber=5367676>.
[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/info/rfc2119>.
[RFC4210]
Adams, C.,Farrell, S.,Kause, T., andT. Mononen,"Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)",RFC 4210,DOI 10.17487/RFC4210,,<https://www.rfc-editor.org/info/rfc4210>.
[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/info/rfc8174>.
[RFC8366]
Watsen, K.,Richardson, M.,Pritikin, M., andT. Eckert,"A Voucher Artifact for Bootstrapping Protocols",RFC 8366,DOI 10.17487/RFC8366,,<https://www.rfc-editor.org/info/rfc8366>.
[RFC8995]
Pritikin, M.,Richardson, M.,Eckert, T.,Behringer, M., andK. Watsen,"Bootstrapping Remote Secure Key Infrastructure (BRSKI)",RFC 8995,DOI 10.17487/RFC8995,,<https://www.rfc-editor.org/info/rfc8995>.

9.2.Informative References

[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. andB. Kaliski,"PKCS #10: Certification Request Syntax Specification Version 1.7",RFC 2986,DOI 10.17487/RFC2986,,<https://www.rfc-editor.org/info/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/info/rfc4211>.
[RFC5272]
Schaad, J. andM. Myers,"Certificate Management over CMS (CMC)",RFC 5272,DOI 10.17487/RFC5272,,<https://www.rfc-editor.org/info/rfc5272>.
[RFC5652]
Housley, R.,"Cryptographic Message Syntax (CMS)",STD 70,RFC 5652,DOI 10.17487/RFC5652,,<https://www.rfc-editor.org/info/rfc5652>.
[RFC5929]
Altman, J.,Williams, N., andL. Zhu,"Channel Bindings for TLS",RFC 5929,DOI 10.17487/RFC5929,,<https://www.rfc-editor.org/info/rfc5929>.
[RFC7030]
Pritikin, M., Ed.,Yee, P., Ed., andD. Harkins, Ed.,"Enrollment over Secure Transport",RFC 7030,DOI 10.17487/RFC7030,,<https://www.rfc-editor.org/info/rfc7030>.
[RFC8894]
Gutmann, P.,"Simple Certificate Enrolment Protocol",RFC 8894,DOI 10.17487/RFC8894,,<https://www.rfc-editor.org/info/rfc8894>.
[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.Using EST for certificate enrollment

When 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 requestthe so-called tls-unique value[RFC5929] of the underlying TLS channel.This binding of the proof-of-identity of the TLS client, which is supposed tobe the certificate requester, to the proof-of-possession for the private key isconceptually non-trivial and requires specific support by TLS implementations.

The registrar terminates the security association with the pledge at TLS leveland thus the binding between the certification request and the authenticationof the pledge.The EST server uses the authenticated pledge identity provided by the IDevIDfor checking the authorization of the pledge for the given certification requestbefore issuing to the pledge a domain-specific certificate (LDevID certificate).This approach typically requires online or on-site availability of the RAfor performing the final authorization decision for the certification request.

Using EST for BRSKI has the advantage that the mutually authenticated TLSconnection established between the pledge and the registrar can be reusedfor 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 auditabilitynor end-to-end security for the certificate enrollment requestbecause 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 thatdue to using PKCS#10 structures in enrollment requests,the only possible proof-of-possession method is a self-signature, whichexcludes requesting certificates for key types that do not support signing.

Appendix B.Application examples

This informative annex provides some detail tothe application examples listed inSection 1.3.

B.1.Rolling stock

Rolling stock or railroad cars contain a variety of sensors,actuators, and controllers, which communicate within the railroad carbut 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 systemconnectivity. Managing certificates may be done during maintenancecycles of the railroad car, but can already be prepared duringoperation. Preparation will include generating certification requests,which are collected and later forwarded forprocessing, once the railroad car is connected to the operator backend.The authorization of the certification request is then done based onthe operator's asset/inventory information in the backend.

UNISIG has included a CMP profile for enrollment of TLS certificates ofon-board and track-side components in the Subset-137 specifying the ETRAM/ETCSon-line key management for train control systems[UNISIG-Subset-137].

B.2.Building automation

In building automation scenarios, a detachedbuilding or the basement of a building may be equipped with sensors, actuators,and controllers that are connected with each other in a local network butwith 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 dataand transfers it between the local network and the central building managementsystem, e.g., using a laptop or a mobile phone.This data may comprise parameters and settingsrequired in the operational phase of the sensors/actuators, like acomponent certificate issued by the operator to authenticate against othercomponents and services.

The collected data may be provided by a domain registraralready existing in the local network. In this caseconnectivity to the backend PKI may be facilitated by the servicetechnician's laptop.Alternatively, the data can also be collected from thepledges directly and provided to a domain registrar deployed in adifferent network as preparation for the operational phase.In this case, connectivity to the domain registrarmay also be facilitated by the service technician's laptop.

B.3.Substation automation

In electrical substation automation scenarios, a control center typically hostsPKI services to issue certificates for Intelligent Electronic Devices(IEDs) operated in a substation. Communication between the substationand control center is performed through a proxy/gateway/DMZ, whichterminates protocol flows. Note that[NERC-CIP-005-5] requiresinspection of protocols at the boundary of a securityperimeter (the substation in this case).In addition, security management in substation automation assumescentral support of several enrollment protocols in order to support thevarious capabilities of IEDs from different vendors. The IEC standardIEC62351-9[IEC-62351-9] specifies mandatorysupport of two enrollment protocols: SCEP[RFC8894] and EST[RFC7030] for the infrastructure side, whilethe IED must only support one of the two.

B.4.Electric vehicle charging infrastructure

For electric vehicle charging infrastructure, protocols have beendefined for the interaction between the electric vehicle and thecharging 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 authenticationmodel, unilateral or mutual authentication is required. In both casesthe charging point uses an X.509 certificate to authenticate itselfin TLS connections between the electric vehicle andthe 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 communicationprotocol between the charging point and the backend, carrying allinformation to control the charging operations and maintain thecharging point itself. This means that the certificate managementneeds to be handled in-band of OCPP. This requires the ability toencapsulate the certificate management messages in a transport-independent way.Authenticated self-containment will support this byallowing the transport without a separate enrollment protocol,binding the messages to the identity of the communicating endpoints.

B.5.Infrastructure isolation policy

This refers to any case in which network infrastructure is normallyisolated from the Internet as a matter of policy, most likely forsecurity reasons. In such a case, limited access to external PKIservices will be allowed in carefully controlled short periods oftime, for example when a batch of new devices is deployed, andforbidden or prevented at other times.

B.6.Sites with insufficient level of operational security

The registration authority performing (at least part of) the authorization of acertification request is a critical PKI component and therefore requires higheroperational security than components utilizing the issuedcertificates for their security features. CAs may also demand highersecurity in the registration procedures. Especially the CA/Browserforum currently increases the security requirements in the certificateissuance procedures for publicly trusted certificates.In case the on-site components of the target domain cannot be operated securelyenough for the needs of a registration authority, this service should betransferred to an off-site backend component that has a sufficient level of security.

Appendix C.History of changes TBD RFC Editor: please delete

From 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 aseparate document. This required changes and adaptations in severalsections. Main changes concerned the removal of the subsection for UC2as well as the removal of the YANG model related text as it is notapplicable 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-requestin UC2 as voucher-request was enhanced with additional leaf.
  • Included open issues in YANG model in UC2 regarding assertionvalue 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 formatbased on draft for JOSE signed voucher artifacts and aligned theremaining objects with this approach in UC2 .
  • Terminology change: issue #2 pledge-agent -> registrar-agent tobetter underline agent relation.
  • Terminology change: issue #3 PULL/PUSH -> pledge-initiator-modeand pledge-responder-mode to better address the pledge operation.
  • Communication approach between pledge and registrar-agentchanged by removing TLS-PSK (former section TLS establishment)and associated references to other drafts in favor of relying onhigher layer exchange of signed data objects. These data objectsare included also in the pledge-voucher-request and lead to anextension of the YANG module for the voucher-request (issue #12).
  • Details on trust relationship between registrar-agent andregistrar (issue #4, #5, #9) included in UC2.
  • Recommendation regarding short-lived certificates forregistrar-agent authentication towards registrar (issue #7) inthe security considerations.
  • Introduction of reference to agent signing certificate using SKIDin agent signed data (issue #11).
  • Enhanced objects in exchanges between pledge and registrar-agentto allow the registrar to verify agent-proximity to the pledge(issue #1) in UC2.
  • Details on trust relationship between registrar-agent andpledge (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 inSection 1.2 to include inwhich the pledge acts as a server. This is one main motivationfor use case 2.
  • Rework of use case 2 to consider thetransport between the pledge and the pledge-agent. Addressed isthe TLS channel establishment between the pledge-agent and thepledge 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 atthe domain registrar based on well-known endpoints inSection 4.3 do not result in additional/.well-known URIs. Update of the illustrative example.Note that the change to /brski for the voucher related endpointshas 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 atthe domain registrar based on well-known endpoints inSection 4.3 as replacement of section 5.1.3in the individual draft. This is intended to support both usecases in the document. An illustrative example is provided.
  • Missing details provided for the description and call flow inpledge-agent use case UC2, e.g. toaccommodate distribution of CA certificates.
  • Updated CMP example inSection 5 to useLightweight CMP instead of CMP, as the draft already providesthe necessary /.well-known endpoints.
  • Requirements discussion moved to separate section inSection 3. Shortened description of proofof identity binding and mapping to existing protocols.
  • Removal of copied call flows for voucher exchange and registrardiscovery flow from[RFC8995] inSection 4 to avoid doubling or text orinconsistencies.
  • Reworked abstract and introduction to be more crisp regardingthe targeted solution. Several structural changes in the documentto have a better distinction between requirements, use casedescription, and solution description as separate sections.History moved to appendix.

From individual version 02 -> 03:

  • Update of terminology from self-contained to authenticatedself-contained object to be consistent in the wording and tounderline the protection of the object with an existingcredential. 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 usecase having an offsite PKI.
  • Introduction of a new use case utilizing authenticatedself-contain objects to onboard a pledge using a commissioningtool containing a pledge-agent. This requires additional changesin the BRSKI call flow sequence and led to changes in theintroduction, the application example,and also in therelated BRSKI-AE call flow.
  • Update of provided examples of the addressing approach used inBRSKI to allow for support of multiple enrollment protocols inSection 4.2.5.

From individual version 01 -> 02:

  • Update of introduction text to clearly relate to the usage ofIDevID and LDevID.
  • Definition of the addressing approach used in BRSKI to allow forsupport of multiple enrollment protocols inSection 4.2.5. Thissection also contains a firstdiscussion of an optional discovery mechanism to addresssituations in which the registrar supports more than one enrollmentapproach. Discovery should avoid that the pledge performs a trialand error of enrollment protocols.
  • Update of description of architecture elements andchanges to BRSKI inSection 4.1.
  • Enhanced consideration of existing enrollment protocols in thecontext of mapping the requirements to existing solutions inSection 3 and inSection 5.

From individual version 00 -> 01:

  • Update of examples, specifically for building automation aswell as two new application use cases inAppendix B.
  • Deletion of asynchronous interaction with MASA to notcomplicate the use case. Note that the voucher exchange canalready be handled in an asynchronous manner and is thereforenot considered further. This resulted in removal of thealternative path the MASA in Figure 1 and the associateddescription inSection 4.1.
  • Enhancement of description of architecture elements andchanges to BRSKI inSection 4.1.
  • Consideration of existing enrollment protocols in the contextof mapping the requirements to existing solutions inSection 3.
  • New section startingSection 5 with themapping to existing enrollment protocols by collectingboundary conditions.

Authors' Addresses

David von Oheimb (editor)
Siemens AG
Otto-Hahn-Ring 6
81739Munich
Germany
Steffen Fries
Siemens AG
Otto-Hahn-Ring 6
81739Munich
Germany
Hendrik Brockhaus
Siemens AG
Otto-Hahn-Ring 6
81739Munich
Germany
Eliot Lear
Cisco Systems
Richtistrasse 7
CH-8304Wallisellen
Switzerland
Datatracker

draft-ietf-anima-brski-async-enroll-05
Replaced Internet-Draft (anima WG)

DocumentDocument typeReplaced Internet-Draft (anima WG)
Expired & archived
Select version
Compare versions
AuthorsDavid von Oheimb,Steffen Fries,Hendrik Brockhaus,Eliot Lear
Email authors
Replacesdraft-fries-anima-brski-async-enroll
Replaced bydraft-ietf-anima-brski-prm
draft-ietf-anima-brski-ae
RFC streamIETF LogoIETF Logo
Intended RFC status (None)
Other formats
Additional resources GitHub Repository
Mailing list discussion
Report a datatracker bug
[8]ページ先頭
©2009-2026 Movatter.jp