[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

ANIMA WG                                                        S. Fries
Internet-Draft                                              H. Brockhaus
Intended status: Standards Track                                 Siemens
Expires: September 12, 2019                                      E. Lear
                                                           Cisco Systems
                                                          March 11, 2019


              Support of asynchronous Enrollment in BRSKI
                draft-fries-anima-brski-async-enroll-00

Abstract

   This document discusses the enhancement of automated bootstrapping of
   a remote secure key infrastructure (BRSKI) to operate in domains
   featuring no or only timely limited connectivity to backend services
   offering enrollment functionality like a Public Key Infrastructure
   (PKI).  In the context of deploying new devices the design of BRSKI
   allows for online (synchronous object exchange) and offline
   interactions (asynchronous object exchange) with a manufacturer's
   authorization service.  It utilizes a self-contained voucher to
   transport the domain credentials as a signed object to establish an
   initial trust between the pledge and the deployment domain.  The
   currently supported enrollment protocol for request and distribution
   of deployment domain specific device certificates provides only
   limited support for asynchronous PKI interactions.  This memo
   motivates support of self-contained objects also for certificate
   management by using an abstract notation to allow off-site operation
   of PKI services, with only limited connectivity to the pledge
   deployment domain.  This addresses specifically scenarios, in which
   the deployment domain of a pledge does not perform the final
   authorization of a certification request and rather delegates this
   decision to an operator backend.  The goal is to enable the usage of
   existing and potentially new PKI protocols supporting self-
   containment for certificate management.

Status of This Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any



Fries, et al.          Expires September 12, 2019               [Page 1]


Internet-Draft                  BRSKI-AE                      March 2019


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 12, 2019.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Scope of solution . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Supported environment . . . . . . . . . . . . . . . . . .   6
     3.2.  Application Examples  . . . . . . . . . . . . . . . . . .   6
       3.2.1.  Rolling stock . . . . . . . . . . . . . . . . . . . .   6
       3.2.2.  Building automation . . . . . . . . . . . . . . . . .   7
       3.2.3.  Substation automation . . . . . . . . . . . . . . . .   7
       3.2.4.  Electric vehicle charging infrastructure  . . . . . .   7
     3.3.  Requirements for asynchronous operation . . . . . . . . .   8
   4.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   8
     4.1.  Secure Imprinting using Vouchers  . . . . . . . . . . . .  11
     4.2.  Addressing  . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Pledge - Registrar discovery and voucher exchange . . . .  12
     5.2.  Registrar - MASA voucher exchange . . . . . . . . . . . .  14
     5.3.  Pledge - Registrar - RA/CA certificate enrollment . . . .  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  16
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     10.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17




Fries, et al.          Expires September 12, 2019               [Page 2]


Internet-Draft                  BRSKI-AE                      March 2019


1.  Introduction

   BRSKI as defined in [I-D.ietf-anima-bootstrapping-keyinfra] specifies
   a solution for secure zero-touch (automated) bootstrapping of devices
   (pledges) in a target deployment domain.  This includes the discovery
   of network elements in the deployment domain, time synchronization,
   and the exchange of security information necessary to adopt a pledge
   as new network and application element.  Security information about
   the deployment domain, specifically the deployment domain certificate
   (domain root certificate), is exchanged utilizing vouchers as defined
   in [RFC8366].  These vouchers are self-contained objects, which may
   be provided online (synchronous) or offline (asynchronous) via the
   domain registrar to the pledge and originate from a manufacturer's
   authorization service (MASA).  The manufacturer signed voucher
   contains the target domain certificate and can be verified by the
   pledge due to the possession of a manufacturer root certificate.  It
   facilitates the enrollment of the pledge in the deployment domain and
   is used to establish trust.

   For the enrollment of devices BRSKI relies on EST [RFC7030] to
   request and distribute deployment domain specific device
   certificates.  EST in turn relies on a binding of the certification
   request to an underlying TLS connection between the EST client and
   the EST server.  The EST server is likely collocated with a
   registration authority (RA) or local registration authority (LRA).
   The binding to TLS is used to protect the exchange of a certification
   request (for an LDevID certificate) and to provide data origin
   authentication to support the authorization decision for processing
   the certification request.  The TLS connection is mutually
   authenticated and the client side authentication bases on the
   pledge's manufacturer issued device certificate (IDevID certificate).
   This approach requires an on-site availability of a PKI component
   and/or a local asset or inventory management system performing the
   authorization decision to issue a domain specific certificate to the
   pledge.  This is due to the fact that the EST server terminates the
   security association with the pledge and thus the binding between the
   certification request and the authentication of the pledge.
   Moreover, it may also require to setup a new security association
   between the EST and the issuing RA/CA.  This type of enrollment
   utilizing an online connection to the PKI is considered as
   synchronous enrollment.

   For certain use cases on-site support of a RA/CA component and/or an
   asset management is not available and rather provided in a timely
   limited fashion or completely offline.  This may be due to higher
   security requirements for the certification authority.  This also
   means that a PKI component, performing the authorization decision for
   a certification request from a pledge may not be available on-site at



Fries, et al.          Expires September 12, 2019               [Page 3]


Internet-Draft                  BRSKI-AE                      March 2019


   enrollment time.  Enrollment, which cannot be performed in a (timely)
   consistent fashion is considered as asynchronous enrollment in this
   document.  In this case a support of a store and forward
   functionality of certification request together with the requester
   authentication information is necessary, to enable the processing of
   the request at a later point in time.  A similar situation may occur
   through network segmentation, which is utilized in industrial systems
   to separate certain tasks.  Here, a similar requirement arises if the
   communication channel carrying the requester authentication is
   terminated before the RA/CA.  If a second communication channel is
   opened to forward the certification request to the issuing CA, the
   requester authentication information needs to be bound to the
   certification request.  For both cases, it is assumed that the
   requester authentication information is utilized in the process of
   authorization of a certification request.  There are different
   options to perform store and forward of certification requests:

   o  Providing a trusted component (e.g., an LRA) in the deployment
      domain, which handles the storage of the certification request
      combined with the requester authentication information (the
      IDevID) and potentially the information about a successful proof
      of possession in a way prohibiting changes to the combined
      information.  Note that the assumption is that the information
      elements are not cryptographically bound together.  Once the PKI
      functionality (RA/CA)) is available, the trusted component
      forwards the certification request together with the originator
      information and the information about the successful proof of
      possession as triple to the off-site PKI for further processing.
      It is assumed that the off-site PKI in this case relies on the
      local authentication result and thus on the authorization and
      issues the requested certificate.  In BRSKI the trusted component
      may be the EST server residing co-located with the registrar in
      the deployment domain.

   o  Utilization of a self-contained object for the certification
      request, which cryptographically binds the requester
      authentication information to the certification request.  This
      approach reduces the necessary trust in a domain component to
      storage and delivery.  Unauthorized modifications can be detected
      during the verification of the cryptographic binding of the
      certification request in the off-site PKI.

   This document targets environments, in which connectivity to the PKI
   functionality is only temporary or not directly available by
   specifying support for handling asynchronous objects supporting
   enrollment.  As it is intended to enhance BRSKI it is named BRSKI-AE,
   where AE stands for asynchronous enrollment.  Note that BRSKI-AE is
   also intended to be applicable for synchronous enrollment, e.g., if a



Fries, et al.          Expires September 12, 2019               [Page 4]


Internet-Draft                  BRSKI-AE                      March 2019


   connection carrying the requester authentication is terminated before
   the actual registration authority.

   /* to be clarified: Describe as abstract type in Yang? */

   The ultimate goal is to allow existing certificate management
   protocols to be applied or to allow other types of encoding for the
   certificate management information exchange.

   Note that in contrast to BRSKI, BRSKI-AE assumes support of multiple
   enrollment protocols on the infrastructure side, allowing the pledge
   manufacturer to select the most appropriate.

   As BRSKI, BRSKI-AE results in the pledge storing a X.509 root domain
   certificate sufficient for verifying the domain registrar / proxy
   identity.  In the process a TLS connection is established that can be
   directly used for certification request/response exchanges.  The
   certification request may be stored on the domain registrar / proxy
   until connectivity to the PKI (issuing CA) becomes available.  With
   this, BRSKI-AE supports the automated mechanism for asynchronous
   enrollment of a pledge in a deployment domain utilizing a voucher of
   the pledge manufacturer resulting in a domain specific X.509 device
   certificate (LDevID certificate) available on the pledge.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   This document relies on the terminology defined in
   [I-D.ietf-anima-bootstrapping-keyinfra].  The following terms are
   defined additionally:

   CA:  Certification authority, issues certificates.

   RA:  Registration authority, an optional system component to which a
      CA delegates certificate management functions such as
      authorization checks.

   LRA:  Local registration authority, an optional RA system component
      with proximity to end entities.

   IED:  Intelligent Electronic Device (in essence a pledge).

   on-site:  Describes a component or service or functionality available
      in the target deployment domain.



Fries, et al.          Expires September 12, 2019               [Page 5]


Internet-Draft                  BRSKI-AE                      March 2019


   off-site:  Describes a component or service or functionality
      available in a operator domain different from the target
      deployment domain.  This may be a central side, to which only a
      temporarily connection is available or which is in a different
      administrative domain.

   asynchronous communication:  Describes a timely interrupted
      communication between an end entity and a PKI component.

   synchronous communication:  Describes a timely uninterrupted
      communication between an end entity and a PKI component.

3.  Scope of solution

3.1.  Supported environment

   This solution is intended to be used in environments with no or only
   limited connectivity to backend services provided in the operator
   domain.  Beyond others this comprises cases in which:

   o  there is no registration authority available in the deployment
      domain.  The connectivity to the registration authority may only
      be temporarily available.  A local store and forward device is
      used for the communication with the backend services.

   o  authoritive actions of a local registration authority are limited
      and may not comprise local authorization of certification requests
      of enrolling pledges.  Final authorization is done at the
      registration authority residing in the operator domain.

   o  the target deployment domain already uses a certificate management
      approach that shall be kept consistent throughout the lifecycle.

3.2.  Application Examples

   The following examples are intended to motivate the support of
   different enrollment approaches in general and asynchronous
   enrollment specifically, by introducing industrial applications
   cases, which could leverage BRSKI as such but also require support of
   asynchronous operation as intended with BRSKI-AE.

3.2.1.  Rolling stock

   Rolling stock or railroad cars contain a variety of sensors,
   actuators, and controller, which communicate within the railroad car
   but also exchange information between railroad cars building a train
   or with a backend.  These devices are typically unaware of backend
   connectivity.  Managing certificates may be done during maintenance



Fries, et al.          Expires September 12, 2019               [Page 6]


Internet-Draft                  BRSKI-AE                      March 2019


   cycles of the railroad car, but can already be prepared during
   operation.  The preparation may comprise the generation of
   certificate signing requests, to apply for a new or an updated domain
   specific device certificate.  The authorization of the certificate
   signing request is done using inventory information available in the
   backend.

   /* to be done: more information to be provided */

3.2.2.  Building automation

   Detached building equipped with sensor, actuators, and controllers
   connected to centralized building management system.  Limited/no
   connectivity to backend during the installation phase and even later.
   (Example: School, etc.)

   /* to be done: more information to be provided */

3.2.3.  Substation automation

   In substation automation a control center typically hosts PKI
   services to issue certificates for IEDs in a substation.
   Communication between the substation and control center is typically
   done through a proxy/gateway/DMZ, which terminates protocol flows.
   Note that NERC CIP (reference to be included) requires inspection of
   protocols at the boundary of a security perimeter.  In addition,
   security in substation automation assumes central support of
   different enrollment protocols to facilitate the capabilities of IEDs
   from different vendors.  The IEC standard IEC62351-9 [IEC-62351-9]
   specifies the mandatory support of two enrollment protocols, SCEP
   [I-D.gutmann-scep] and EST [RFC7030] for the infrastructure side,
   while the IEDs must only support one of the two.

3.2.4.  Electric vehicle charging infrastructure

   For the electric vehicle charging infrastructure protocols have been
   defined for the interaction between the electric vehicle and the
   charging spot (e.g., ISO 15118 [ISO-IEC-15118-2]) as well as between
   the charging spot and the operator backend (e.g.  OCPP [OCPP]).
   Depending on the charging model, unilateral or mutual authentication
   is required.  In both cases the charging spot authenticates using an
   X.509 certificate.  The management of this certificate depends
   (beyond others) on the selected backend connectivity protocol.  In
   case of OCPP there is the desire to have a single communication
   protocol between the charging spot and the backend carrying all
   information to control and manage the charging operations and the
   charging spot itself.  This means that the certificate management is
   intended to be handled in-band of OCPP.  This requires to be able to



Fries, et al.          Expires September 12, 2019               [Page 7]


Internet-Draft                  BRSKI-AE                      March 2019


   encapsulate the certificate management exchanges in a transport
   independent way.  Self-containment will ease this by allowing the
   transport without a separate communication protocol.

3.3.  Requirements for asynchronous operation

   Based on the supported environment described in Section 3.1 and the
   motivated application examples described in Section 3.2 the following
   base requirements are derived:

   o  Certificate management exchanges (e.g., certification request and
      certification response message(s)) are ideally carried in a
      container protecting at least integrity of the exchanges and
      providing source authentication.  /* to be clarified: reference to
      PKCS#10 or CRMF to be used? */

   o  The container with the certification request should provide a
      proof of possession of corresponding private key.  Note: this is
      typically provided by the existing enrollment protocols and is
      stated here for completeness if a different approach (encoding,
      transport) is desired.

   o  The container with the certification request should support a
      cryptographic binding to an existing credential known to the
      operator domain.  /* to be clarified: reference to existing
      enrollment protocols EST, CMC, CMP, SCEP to be used? */

   o  The container with the certification request should support direct
      protection using an existing credential on the pledge verifiable
      in the operator domain.  /* to be clarified: reference to CMS or
      CMP to be used? */

4.  Architectural Overview

   The intended architecture for supporting asynchronous enrollment
   relies architecture defined in BRSKI
   [I-D.ietf-anima-bootstrapping-keyinfra] with certain changes as shown
   in the placement or enhancements of the logical elements in Figure 1.













Fries, et al.          Expires September 12, 2019               [Page 8]


Internet-Draft                  BRSKI-AE                      March 2019


                                              +------------------------+
      +--------------Drop Ship--------------->| Vendor Service         |
      |                                       +------------------------+
      |                                       | M anufacturer|         |
      |                                       | A uthorized  |Ownership|
      |                                       | S igning     |Tracker  |
      |                                       | A uthority   |         |
      |                                       +--------------+---------+
      |                                                      ^
      |                                                      |
      V                                                      |
   +--------+     .........................................  |
   |        |     .                                       .  |
   |        |     .  +------------+       +------------+  .  | BRSKI-
   |        |     .  |            |       |            |  .  | MASA
   | Pledge |     .  |   Join     |       | Domain     <-----+
   |        |     .  |   Proxy    |       | Registrar/ |  .  ^
   |        <-------->............<-------> Proxy      |  .  '
   |        |     .  |        BRSKI-AE    |            |  .  | [alt.]
   | IDevID |     .  |            |       +------^-----+  .  '
   |        |     .  +------------+              |        .  |
   |        |     .                              |        .  '
   +--------+     ...............................|.........  |
                   "on-site domain" components   |           '
                                                 |           |
                                                 |           '
    .............................................|...........|.........
    . +---------------------------+     +--------v-----------v------+ .
    . | Public Key Infrastructure |<----+ PKI RA                    | .
    . | PKI CA                    |---->+ [(Domain) Registrar (opt)]| .
    . +---------------------------+     +--------+--^---------------+ .
    .                                            |  |                 .
    .                                   +--------v--+---------------+ .
    .                                   | Inventory (Asset)         | .
    .                                   | Management                | .
    .                                   +---------------------------+ .
    ...................................................................
            "off-site domain" components

   Figure 1: Architecture overview of BRSKI-AE

   The architecture overview in Figure 1 utilizes the same logical
   elements as BRSKI but with a different placement in the architecture
   for some of the elements in terms of connected domains.  The main
   difference is the placement of the PKI RA/CA component as well as the
   connectivity of the RA/CA with an inventory management system.  Both
   are placed in the operator domain , which may have no or only
   temporary connectivity to the deployment domain of the pledge.  Based



Fries, et al.          Expires September 12, 2019               [Page 9]


Internet-Draft                  BRSKI-AE                      March 2019


   on the assumed connectivity of the deployment domain, the MASA
   interaction may also be done asynchronous to the actual deployment
   domain.  The following list describes the deployment domain
   components:

   o  Join Proxy: same functionality as describe in BRSKI

   o  Domain Registrar / Proxy: In general the domain registrar / proxy
      has a similar functionality regarding the imprinting of the pledge
      in the deployment domain.  Differences arise, if the deployment
      domain has temporary or no connectivity to an operator domain and/
      or the manufacturers MASA.  There may be use cases, in which the
      (domain) registrar may even be operated in the operator domain.
      /* to do: needs more description */

      *  Voucher exchange: The voucher exchange with the MASA is
         performed as described in BRSKI
         [I-D.ietf-anima-bootstrapping-keyinfra] .  If the voucher
         exchange is facilitated by the operator domain, additional
         description is necessary.  In Figure 1 this is characterized by
         indicating an alternative path for the voucher request/response
         interaction.

      *  Certificate enrollment: For the pledge enrollment the domain
         registrar in the deployment domain is expected to support the
         authorization of the pledge to be part of the domain, but not
         necessarily to authorize the certification request provided
         during enrollment.  This may be due to lack of authorization
         information in the deployment domain.  If the authorization is
         done in the operator domain, the domain registrar is used as
         store and forward component (or proxy) of the certification
         requests.  To enable this, the domain registrar needs
         functionality enhancements regarding the support of alternative
         enrollment approaches supporting self-containment.  To support
         alternative enrollment approaches (protocols, encodings), it is
         necessary to enhance the addressing scheme at the domain
         registrar.  The communication channel between the pledge and
         the domain registrar may be similarly described within the same
         "/.well-known" tree and may result for instance in "/.well-
         known/enrollment-variant/request".

   The following list describes the vendor related components/service
   outside the deployment domain:

   o  MASA: general functionality as described in BRSKI.  Assumption
      that the interaction may be done synchronous and asynchronous
      based on the general assumption that the deployment domain has




Fries, et al.          Expires September 12, 2019              [Page 10]


Internet-Draft                  BRSKI-AE                      March 2019


      limited outside connectivity.  Note: additional steps for offline
      operation may need to be defined.

   o  Ownership tracker: as defined in BRSKI.

   The following list describes the operator related components/service
   outside the deployment domain in the operator domain:

   o  (Domain) registrar: Optional component if the deployment domain
      does not feature a domain registrar but only a proxy.  In this
      case it is involved in the certification request processing and is
      assumed to be co-located with the PKI RA.  In addition, the
      registrar may be involved in the voucher exchange with the MASA.
      /* to be done: more elaboration necessary */

   o  PKI RA: Perform certificate management functions (validation of
      certification requests, interaction with inventory/asset
      management for authorization, etc.) for issuing, updating, and
      revoking certificates for a domain as a centralized infrastructure
      for the operator.

   o  PKI CA: Perform certificate generation by signing the certificate
      structure management.

   o  Inventory (asset) management: contains information about the known
      devices belonging to the operator.  Specifically, the inventory is
      used to provide the information to authorize issuing a certificate
      based on the certification request of the pledge.  Note: the
      communication between the inventory (asset) management and the PKI
      components (RA/CA) in the operator domain are out of scope for
      this document.

4.1.  Secure Imprinting using Vouchers

   /* to be done, should contain - review of the domain registrar - MASA
   interaction regarding offline operation - changes to the enrollment
   interaction through off-site RA/CA support */

4.2.  Addressing

   For the provisioning of different enrollment options at the domain
   registrar, the addressing approach of BRSKI using a "/.well-known"
   tree from [RFC5785] is enhanced.

   /* to be done: Description of "/.well-known/enrollment-protocol/
   request" in which enrollment-protocol may be an already existing
   protocol like "est" or "scep" or "cmp" or a newly defined protocol.
   */



Fries, et al.          Expires September 12, 2019              [Page 11]


Internet-Draft                  BRSKI-AE                      March 2019


5.  Protocol Flow

   Based on BRSKI and the architectural changes the original protocol
   flow is divided into three phases showing commonalities and
   differences to the original approach as depicted in the following.

   o  Discovery phase (same as BRSKI)

   o  Voucher exchange with deployment domain registrar (may have
      changes due the handling of phases without communication to the
      operator domain.

   o  Enrollment phase (changed to accompany the asynchronous operation)

5.1.  Pledge - Registrar discovery and voucher exchange

   /* to be done: description of unchanged BRSKI approach */


































Fries, et al.          Expires September 12, 2019              [Page 12]


Internet-Draft                  BRSKI-AE                      March 2019


   +--------+         +---------+    +------------+     +------------+
   | Pledge |         | Circuit |    | Domain     |     | Vendor     |
   |        |         | Join    |    | Registrar  |     | Service    |
   |        |         | Proxy   |    |  (JRC)     |     | (MASA)     |
   +--------+         +---------+    +------------+     +------------+
     |                     |                   |           Internet |
     |<-RFC4862 IPv6 addr  |                   |                    |
     |<-RFC3927 IPv4 addr  | Appendix A        |  Legend            |
     |-------------------->|                   |  C - circuit       |
     | optional: mDNS query| Appendix B        |      join proxy    |
     | RFC6763/RFC6762     |                   |  P - provisional   |
     |<--------------------|                   |    TLS connection  |
     | GRASP M_FLOOD       |                   |                    |
     |   periodic broadcast|                   |                    |
     |<------------------->C<----------------->|                    |
     |              TLS via the Join Proxy     |                    |
     |<--Registrar TLS server authentication---|                    |
   [PROVISIONAL accept of server cert]         |                    |
     P---X.509 client authentication---------->|                    |
     P                     |                   |                    |
     P---Voucher Request (include nonce)------>|                    |
     /-->                                      |                    |
     P          [if connection to operator domain is not available] |
     P<---------- Voucher Waiting -------------|                    |
     P                     |                   |                    |
     P- Voucher Polling (with serial number) ->|                    |
     /-->                  |                   |                    |
     P                     |       /--->       |                    |
     P                     |       |      see Figure 3 below        |
     P                     |       \---->      |                    |
     P<------voucher---------------------------|                    |
   [verify voucher , verify provisional cert]  |                    |
     |---------------------------------------->|                    |
     |      [voucher status telemetry]         |<-device audit log--|
     |                     |       [verify audit log and voucher]   |
     |<--------------------------------------->|                    |


   Figure 2: Pledge discovery of domain registrar discovery and voucher
   exchange

   /* to be done: - discuss call flow in the context of asynchronous
   operation, when the domain registrar works as proxy.  The voucher
   waiting indication can be used in this way to inform the pledge not
   to expect an immediate response (may contain the time for the
   polling) - may utilize a parallel provisioning of a voucher request
   and a certification request by the pledge.  - both may be provided




Fries, et al.          Expires September 12, 2019              [Page 13]


Internet-Draft                  BRSKI-AE                      March 2019


   when the operator domain is available and processed sequentially by
   the pledge, first the voucher, second the certification response */

5.2.  Registrar - MASA voucher exchange

   /* to be done: - clarification if BRSKI protocol sequence kept
   unchanged - changes for complete offline operation may be necessary,
   verify BRSKI document section 6.2.  Pledge security reductions */

   +--------+         +---------+    +------------+     +------------+
   | Pledge |         | Circuit |    | Domain     |     | Vendor     |
   |        |         | Join    |    | Registrar  |     | Service    |
   |        |         | Proxy   |    |  (JRC)     |     | (MASA)     |
   +--------+         +---------+    +------------+     +------------+
     P                     |       /--->       |                    |
     P                     |       |      [accept device in domain] |
     P                     |       |      [contact Vendor]          |
     P                     |       |           |--Pledge ID-------->|
     P                     |       |           |--Domain ID-------->|
     P                     |       |           |--optional:nonce--->|
     P                     |       |           |     [extract DomainID]
     P                     |    optional:      |     [update audit log]
     P                     |      can occur in advance if nonceless |

   Figure 3: Domain registrar - MASA voucher exchange

5.3.  Pledge - Registrar - RA/CA certificate enrollment

   /* to be done: overview description of operation */






















Fries, et al.          Expires September 12, 2019              [Page 14]


Internet-Draft                  BRSKI-AE                      March 2019


   +--------+         +---------+    +------------+     +------------+
   | Pledge |         | Circuit |    | Domain     |     | Operator   |
   |        |         | Join    |    | Registrar  |     | RA/CA      |
   |        |         | Proxy   |    |  (JRC)     |     | (OPKI)     |
   +--------+         +---------+    +------------+     +------------+
     |-------------- Cert Request ------------>|                    |
     |              [if connection to operator domain is available] |
     |                                         |--- Cert Request -->|
     |                                         |<-- Cert Response --|
     /-->                                      |                    |
     |          [if connection to operator domain is not available] |
     |                                         |                    |
     |<---------- Cert Waiting ----------------|                    |
     |-- Cert Polling (with orig request ID) ->|                    |
     |              [if connection to operator domain is available] |
     |                                         |--- Cert Request -->|
     |                                         |<-- Cert Response --|
     /-->                                      |                    |
     |<------------- Cert Response ------------|                    |
     |-------------- Cert Confirm ------------>|                    |
     |                                         /-->                 |
     |                                         |[optional]          |
     |                                         |--- Cert Confirm -->|
     |                                         |<-- PKI Confirm ----|
     |<------------- PKI/Registrar Confirm ----|                    |


   Figure 4: Certificate enrollment

   o  Cert Request: certification request message (to be done: reference
      to PKCS#10 or CRMF, proof of possession, pledge authentication)

   o  Cert Response: certification response message containing the
      requested certificate and potentially further information like
      certificates of intermediary CAs on the certification path.

   o  Cert Waiting: waiting indication for the pledge to retry after a
      given time.

   o  Cert Poling: querying the registrar, if the certificate request
      was already processed; can be answered either with another Cert
      Waiting, or a Cert Response.

   o  Cert Confirm: confirmation message from pledge after receiving and
      verifying the certificate.

   o  PKI/Registrar Confirm: confirmation message from PKI/registrar
      about reception of the pledge's certificate confirmation.



Fries, et al.          Expires September 12, 2019              [Page 15]


Internet-Draft                  BRSKI-AE                      March 2019


   /* to be done: - investigation into handling of certificate request
   retries - message exchange description - confirmation message
   (necessary? optional? from Registrar and/or PKI?) */

6.  IANA Considerations

   This document requires the following IANA actions:

   /* to be done: clarification necessary */

7.  Privacy Considerations

   /* to be done: clarification necessary */

8.  Security Considerations

   /* to be done: clarification necessary */

9.  Acknowledgements

   We would like to thank the various reviewers for their input, in
   particular ...

10.  References

10.1.  Normative References

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
              S., and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-19 (work in progress), March 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/info/rfc7030>.

   [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
              "A Voucher Artifact for Bootstrapping Protocols",
              RFC 8366, DOI 10.17487/RFC8366, May 2018,
              <https://www.rfc-editor.org/info/rfc8366>.




Fries, et al.          Expires September 12, 2019              [Page 16]


Internet-Draft                  BRSKI-AE                      March 2019


10.2.  Informative References

   [I-D.gutmann-scep]
              Gutmann, P., "Simple Certificate Enrolment Protocol",
              draft-gutmann-scep-13 (work in progress), January 2019.

   [IEC-62351-9]
              International Electrotechnical Commission, "IEC 62351 -
              Power systems management and associated information
              exchange - Data and communications security - Part 9:
              Cyber security key management for power system equipment",
              IEC 62351-9 , May 2017.

   [ISO-IEC-15118-2]
              International Standardization Organization / International
              Electrotechnical Commission, "ISO/IEC 15118-2 Road
              vehicles - Vehicle-to-Grid Communication Interface - Part
              2: Network and application protocol requirements", ISO/
              IEC 15118 , April 2014.

   [OCPP]     Open Charge Alliance, "Open Charge Point Protocol 2.0",
              April 2018.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              DOI 10.17487/RFC5785, April 2010,
              <https://www.rfc-editor.org/info/rfc5785>.

Authors' Addresses

   Steffen Fries
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: steffen.fries@siemens.com
   URI:   http://www.siemens.com/


   Hendrik Brockhaus
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: hendrik.brockhaus@siemens.com
   URI:   http://www.siemens.com/



Fries, et al.          Expires September 12, 2019              [Page 17]


Internet-Draft                  BRSKI-AE                      March 2019


   Eliot Lear
   Cisco Systems
   Richtistrasse 7
   Wallisellen  CH-8304
   Switzerland

   Phone: +41 44 878 9200
   Email: lear@cisco.com











































Fries, et al.          Expires September 12, 2019              [Page 18]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/