Support of asynchronous Enrollment in BRSKI (BRSKI-AE)
draft-ietf-anima-brski-async-enroll-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Steffen Fries , Hendrik Brockhaus , Eliot Lear | ||
| Last updated | 2020-07-10 | ||
| Replaced by | draft-ietf-anima-brski-prm, draft-ietf-anima-brski-ae | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-anima-brski-async-enroll-00
#x27;s asset/inventory information in the backend. 3.2.2. Building automation In building automation a use case can be described by a detached building or the basement of a building equipped with sensor, actuators, and controllers connected, but with only limited or no connection to the centralized building management system. This limited connectivity may be during the installation time but also during operation time. During the installation in the basement, a service technician collects the necessary information from the basement network and provides them to the central building management system, e.g., using a laptop or even a mobile phone to transport the information. This information may comprise parameters and settings required in the operational phase of the sensors/actuators, like a certificate issued by the operator to authenticate against other components and services. The collected information may be provided by a domain registrar already existing in the installation network. In this case connectivity to the backend PKI may be facilitated by the service technician's laptop. Contrary, the information can also be collected from the pledges directly and provided to a domain registrar deployed in the main network. In this cases connectivity to the domain registrar may be facilitated by the service technician's laptop. 3.2.3. Substation automation In substation automation a control center typically hosts PKI services to issue certificates for Intelligent Electronic Devices (IED)s in a substation. Communication between the substation and control center is done through a proxy/gateway/DMZ, which terminates protocol flows. Note that NERC CIP-005-5 [NERC-CIP-005-5] requires inspection of protocols at the boundary of a security perimeter (the substation in this case). In addition, security management in substation automation assumes central support of different enrollment protocols to facilitate the capabilities of IEDs from different vendors. The IEC standard IEC62351-9 [IEC-62351-9] specifies the mandatory support of two enrollment protocols, SCEP [I-D.gutmann-scep] and EST [RFC7030] for the infrastructure side, while the IED must only support one of the two. 3.2.4. Electric vehicle charging infrastructure For the electric vehicle charging infrastructure protocols have been defined for the interaction between the electric vehicle (EV) and the charging point (e.g., ISO 15118-2 [ISO-IEC-15118-2]) as well as Fries, et al. Expires January 11, 2021 [Page 8] Internet-Draft BRSKI-AE July 2020 between the charging point and the charging point operator (e.g. OCPP [OCPP]). Depending on the authentication model, unilateral or mutual authentication is required. In both cases the charging point authenticates uses an X.509 certificate to authenticate in the context of a TLS connection between the EV and the charging point. The management of this certificate depends (beyond others) on the selected backend connectivity protocol. Specifically, in case of OCPP it is intended as single communication protocol between the charging point and the backend carrying all information to control the charging operations and maintain the charging point itself. This means that the certificate management is intended to be handled in- band of OCPP. This requires to be able to encapsulate the certificate management exchanges in a transport independent way. Authenticated self-containment will ease this by allowing the transport without a separate communication protocol. For the purpose of certificate management CMP [RFC4210] is intended to be used. 3.2.5. Infrastructure isolation policy This refers to any case in which network infrastructure is normally isolated from the Internet as a matter of policy, most likely for security reasons. In such a case, limited access to external PKI resources will be allowed in carefully controlled short periods of time, for example when a batch of new devices are deployed, but impossible at other times. 3.2.6. Less operational security in the deployment domain The registration point performing the authorization of a certificate request is a critical PKI component and therefore implicates higher operational security than other components utilizing the issued certificates for their security features. CAs may also demand higher security in the registration procedures. Especially the CA/Browser forum currently increases the security requirements in the certificate issuance procedures for publicly trusted certificates. There may be the situation that the deployment domain does not offer enough security to operate a registration point and therefore wants to transfer this service to a backend. 4. Requirement discussion and mapping to solution elements For the requirements discussion it is assumed that the domain registrar receiving a certification request as authenticated self- contained object is not the authorization point for this certification request. If the domain registrar is the authorization point, BRSKI can be used directly. Note that BRSKI-AE could also be used in this case. Fries, et al. Expires January 11, 2021 [Page 9] Internet-Draft BRSKI-AE July 2020 Based on the intended deployment environment described in Section 3.1 and the motivated application examples described in Section 3.2 the following base requirements are derived to support authenticated self-contained objects as container carrying the certification request and further information to support asynchronous operation. At least the following properties are required: o Proof of Possession: utilizing the private key corresponding to the public key contained in the certification request. o Proof of Identity: utilizing an existing IDevID credential bound to the certification request. Certificate updates may utilize the LDevID credential. Solution examples (not complete) based on existing technology are provided with the focus on existing IETF documents: o Certification request objects: Certification requests are structures protecting only the integrity of the contained data providing a proof-of-private-key-possession for locally generated key pairs. Examples for certification requests are: * PKCS#10 [RFC2986]: Defines a structure for a certification request. The structure is signed to ensure integrity protection and proof of possession of the private key of the requester that corresponds to the contained public key. * CRMF [RFC4211]: Defines a structure for the certification request message. The structure supports integrity protection and proof of possession, through a signature generated over parts of the structure by using the private key corresponding to the contained public key. Note that the integrity of the certification request is bound to the public key contained in the certification request by performing the signature operation with the corresponding private key. In the considered application examples, this is not sufficient and needs to be bound to the existing credential of the pledge (IDevID) additionally. This binding supports the authorization decision for the certification request through the provisioning of a proof of identity. The binding of data origin authentication to the certification request may be delegated to the protocol used for certificate management. o Proof of Identity options: The certification request should be bound to an existing credential (here IDevID) to enable a proof of identity and based on it an the authorization of the certification Fries, et al. Expires January 11, 2021 [Page 10] Internet-Draft BRSKI-AE July 2020 request. The binding may be realized through a security options in an underlying transport protocol if the authorization of the the certification request is done at the next communication hop. Alternatively, this binding can be done by a wrapping signature employing an existing credential (initial: IDevID, renewal: LDevID). This requirement is addressed by existing enrollment protocols in different ways, for instance: * EST [RFC7030]: Utilizes PKCS#10 to encode the certification request. The Certificate Signing Request (CSR) may contain a binding to the underlying TLS by including the tls-unique value in the self-signed CSR structure. The tls-unique value is one result of the TLS handshake. As the TLS handshake is performed mutually authenticated and the pledge utilized its IDevID for it, the proof of identity can be provided by the binding to the TLS session. This is supported in EST using simpleenroll. To avoid the binding to the underlying authentication in the transport layer EST offers the support of a wrapping the CSR with an existing certificate by using fullcmc. * SCEP [I-D.gutmann-scep]: Provides the option to utilize either an existing secret (password) or an existing certificate to protect the CSR based on SCEP Secure Message Objects using CMS wrapping ([RFC5652]). Note that the wrapping using an existing IDevID credential in SCEP is referred to as renewal. SCEP therefore does not rely on the security of an underlying transport. * CMP [RFC4210] Provides the option to utilize either an existing secret (password) or an existing certificate to protect the PKIMessage containing the certification request. The certification request is encoded utilizing CRMF. PKCS#10 is optionally supported. The proof of identity of the PKIMessage containing the certification request can be achieved by using IDevID credentials to calculate a signature over the header and the body of the PKIMessage utilizing the protectionAlg signaled in the PKIMessage header and the PKIProtection carrying the actual signature value. CMP therefore does not rely on the security of an underlying transport. * CMC [RFC5272] Provides the option to utilize either an existing secret (password) or an existing certificate to protect the certification request (either in CRMF or PKCS#10) based on CMS [RFC5652]). Here a FullCMCRequest can be used, which allows signing with an existing IDevID credential to provide a proof of identity. CMC therefore does not rely on the security of an underlying transport. Fries, et al. Expires January 11, 2021 [Page 11] Internet-Draft BRSKI-AE July 2020 Note that besides the already existing enrollment protocols there ongoing work in the ACE WG to define an encapsulation of EST in OSCORE to result in a TLS independent way of protecting EST. This approach [I-D.selander-ace-coap-est-oscore] may be considered as further variant. 5. Architectural Overview and Communication Exchanges To support asynchronous enrollment, the base system architecture defined in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] is enhanced to facilitate the two target use cases. o Use case 1 (PULL case): the pledge requests certificates from a PKI operated off-site via the domain registrar. o Use case 2 (PUSH/PULL case): allows delayed (delegated) onboarding using a pledge-agent instead a direct connection to the domain registrar. The communication model between pledge-agent and pledge depends on the specified interface and may use a PULL or PUSH approach. This interaction in terms of a protocol specification is out of scope of this document. Note that the terminology PUSH and PULL relates to the pledge behavior. In PULL the pledge requests data objects as in BRSKI, while in the PUSH case the pledge may be provisioned with the necessary data objects. The pledge-agent as it represents the pledge always acts in a PULL mode to the domain registrar. Both use cases are described in the next subsections. They utilize the existing BRSKI architecture elements as much as possible. Necessary enhancements to support authenticated self-contained objects for certificate enrollment are kept on a minimum to ensure reuse of already defined architecture elements and interactions. For the authenticated self-contained objects used for the certification request, BRSKI-AE relies on the defined message wrapping mechanisms of the enrollment protocols stated in Section 4 above. 5.1. Use Case 1: Support of off-site PKI service One assumption of BRSKI-AE is that the authorization of a certification request is performed based on an authenticated self- contained object, binding the certification request to the authentication using the IDevID. This supports interaction with off- site or off-line PKI (RA/CA) components. In addition, the authorization of the certification request may not be done by the domain registrar but by a PKI residing in the backend of the domain operator (off-site) as described in Section 3.1. This leads to Fries, et al. Expires January 11, 2021 [Page 12] Internet-Draft BRSKI-AE July 2020 changes in the placement or enhancements of the logical elements as shown in Figure 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 | . | IDevID | . | | +------^-----+ . | | . +------------+ | . | | . | . +--------+ ...............................|......... "on-site domain" components | |e.g., RFC 7030, | RFC 4210, ... .............................................|..................... . +---------------------------+ +--------v------------------+ . . | Public Key Infrastructure |<----+ PKI RA | . . | PKI CA |---->+ | . . +---------------------------+ +---------------------------+ . ................................................................... "off-site domain" components Figure 1: Architecture overview using off-site PKI components The architecture overview in Figure 1 utilizes the same logical elements as BRSKI but with a different placement in the deployment architecture for some of the elements. The main difference is the placement of the PKI RA/CA component, which is performing the authorization decision for the certification request message. It is placed in the off-site domain of the operator (not the deployment site directly), which may have no or only temporary connectivity to the deployment or on-site domain of the pledge. This is to underline the authorization decision for the certification request in the Fries, et al. Expires January 11, 2021 [Page 13] Internet-Draft BRSKI-AE July 2020 backend rather than on-site. The following list describes the components in the deployment domain: o Join Proxy: same functionality as described in BRSKI. o Domain Registrar / Enrollment Proxy: In general the domain registrar proxy has a similar functionality regarding the imprinting of the pledge in the deployment domain to facilitate the communication of the pledge with the MASA and the PKI. Different is the authorization of the certification request. BRSKI-AE allows to perform this in the operators backend (off- site), and not directly at the domain registrar. * Voucher exchange: The voucher exchange with the MASA via the domain registrar is performed as described in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] . * Certificate enrollment: For the pledge enrollment the domain registrar in the deployment domain supports the adoption of the pledge in the domain based on the voucher request. Nevertheless, it may not have sufficient information for authorizing the certification request. If the authorization is done in the off-site domain, the domain registrar forwards the certification request to the RA to perform the authorization. The domain registrar in this acts as an enrollment proxy or local registration authority. It is also able to handle the case having temporarily no connection to an off-site PKI by storing the certification request and forwarding it to the RA upon regaining connectivity. As authenticated self-contained objects are used, it requires an enhancement of the domain registrar. This is done by supporting alternative enrollment approaches (protocol options, protocols, encoding) by enhancing the addressing scheme to communicate with the domain registrar (see Section 5.1.5) and also by providing a discover scheme to allow the pledge to enumerate the supported enrollment options (see Section 5.3). The following list describes the vendor related components/service outside the deployment domain: o MASA: general functionality as described in BRSKI. Assumption that the interaction with the MASA may be synchronous (voucher request with nonce) or asynchronous (voucher request without nonce). o Ownership tracker: as defined in BRSKI. Fries, et al. Expires January 11, 2021 [Page 14] Internet-Draft BRSKI-AE July 2020 The following list describes the operator related components/service operated in the backend: o PKI RA: Performs certificate management functions (validation of certification requests, interaction with inventory/asset management for authorization of certification requests, etc.) for issuing, updating, and revoking certificates for a domain as a centralized infrastructure for the domain operator. The inventory (asset) management may be a separate component or integrated into the RA directly. o PKI CA: Performs certificate generation by signing the certificate structure provided in the certification request. Based on BRSKI and the architectural changes the original protocol flow is divided into three phases showing commonalities and differences to the original approach as depicted in the following. o Discovery phase (same as BRSKI) o Voucher exchange with deployment domain registrar (same as BRSKI). o Enrollment phase (changed to accompany the application of authenticated self-contained objects). 5.1.1. Behavior of a pledge The behavior of a pledge as described in [I-D.ietf-anima-bootstrapping-keyinfra] is kept with one exception. After finishing the imprinting phase (4) the enrollment phase (5) is performed with a method supporting authenticated self-contained objects. Using EST with simpleenroll cannot be applied here, as it binds the pledge authentication with the existing IDevID to the transport channel (TLS) rather than to the certification request object directly. This authentication in the transport layer is not visible / verifiable at the authorization point in the off-site domain. Section 6 discusses potential enrollment protocols and options applicable. 5.1.2. Pledge - Registrar discovery and voucher exchange The discovery phase is applied as specified in [I-D.ietf-anima-bootstrapping-keyinfra]. Fries, et al. Expires January 11, 2021 [Page 15] Internet-Draft BRSKI-AE July 2020 5.1.3. Registrar - MASA voucher exchange The voucher exchange is performed as specified in [I-D.ietf-anima-bootstrapping-keyinfra]. 5.1.4. Pledge - Registrar - RA/CA certificate enrollment As stated in Section 4 the enrollment shall be performed using an authenticated self-contained object providing: o Proof of Possession: utilizing the private key corresponding to the public key contained in the certification request. o Proof of Identity: utilizing the existing IDevID credential to generate a signature of the initial certification request. Certificate updates may utilize the LDevID credential. Fries, et al. Expires January 11, 2021 [Page 16] Internet-Draft BRSKI-AE July 2020 +--------+ +---------+ +------------+ +------------+ | Pledge | | Circuit | | Domain | | Operator | | | | Join | | Registrar | | RA/CA | | | | Proxy | | (JRC) | | (OPKI) | +--------+ +---------+ +------------+ +------------+ /--> | | [Request of CA Certificates] | | |---------- CA Certs Request ------------>| | | [if connection to operator domain is available] | | |-Request CA Certs ->| | |<- CA Certs Response| |<-------- CA Certs Response--------------| | /--> | | [Request of Certificate Attributes to be included] | |---------- Attribute Request ----------->| | | [if connection to operator domain is available] | | |Attribute Request ->| | |<-Attribute Response| |<--------- Attribute Response -----------| | /--> | | [Certification request] | | |-------------- Cert Request ------------>| | | [if connection to operator domain is available] | | |--- Cert Request -->| | |<-- Cert Response --| [Optional Certification waiting indication] | | /--> | | |<---------- Cert Waiting ----------------| | |-- Cert Polling (with orig request ID) ->| | | [if connection to operator domain is available] | | |--- Cert Request -->| | |<-- Cert Response --| /--> | | |<------------- Cert Response ------------| | /--> | | [Certification confirmation] | | |-------------- Cert Confirm ------------>| | | /--> | | |[optional] | | |--- Cert Confirm -->| | |<-- PKI Confirm ----| |<------------- PKI/Registrar Confirm ----| | Figure 2: Certificate enrollment The following list provides an abstract description of the flow depicted in Figure 2. Fries, et al. Expires January 11, 2021 [Page 17] Internet-Draft BRSKI-AE July 2020 o CA Cert Request: The pledge SHOULD request the full distribution of CA Certificates. This ensures that the pledge has the complete set of current CA certificates beyond the pinned-domain-cert. o CA Cert Response: Contains at least one CA certificate of the issuing CA. o Attribute Request: Typically, the automated bootstrapping occurs without local administrative configuration of the pledge. Nevertheless, there are cases, in which the pledge may also include additional attributes specific to the deployment domain into the certification request. To get these attributes in advance, the attribute request SHOULD be used. o Attribute Response: Contains the attributes to be included in the certification request message. o Cert Request: Depending on the utilized enrollment protocol, this certification request contains the authenticated self-contained object ensuring both, proof-of-possession of the corresponding private key and proof-of-identity of the requester. o Cert Response: certification response message containing the requested certificate and potentially further information like certificates of intermediary CAs on the certification path. o Cert Waiting: waiting indication for the pledge to retry after a given time. For this a request identifier is necessary. This request identifier may bei either part of the enrollment protocol or build based on the certification request. o Cert Polling: querying the registrar, if the certificate request was already processed; can be answered either with another Cert Waiting, or a Cert Response. o Cert Confirm: confirmation message from pledge after receiving and verifying the certificate. o PKI/Registrar Confirm: confirmation message from PKI/registrar about reception of the pledge's certificate confirmation. [RFC Editor: please delete] /* Open Issues: o Description of certificate waiting and retries. Fries, et al. Expires January 11, 2021 [Page 18] Internet-Draft BRSKI-AE July 2020 o Message exchange description is expected to be done by the utilized enrollment protocol based on the addressing scheme (see also Section 6. o Handling of certificate/PKI confirmation message between pledge and domain registrar and PKI (treated optional?). */ 5.1.5. Addressing Scheme Enhancements BRSKI-AE requires enhancements to the addressing scheme defined in [I-D.ietf-anima-bootstrapping-keyinfra] to accommodate the additional handling of authenticated self-contained objects for the certification request. As this is supported by different enrollment protocols, they can be directly employed (see also Section 6). For the support of different enrollment options at the domain registrar, the addressing approach of BRSKI using a "/.well-known" tree from [RFC5785] is enhanced. The current addressing scheme in BRSKI for the client certificate request function during the enrollment is using the definition from EST [RFC7030], here on the example on simple enroll: "/.well- known/est/simpleenroll" This approach is generalized to the following notation: "/.well-known/enrollment-protocol/request" in which enrollment-protocol may be an already existing protocol or a newly defined approach. Note that enrollment is considered here as a sequence of at least a certification request and a certification response. In case of existing enrollment protocols the following notation is used proving compatibility to BRSKI: o enrollment-protocol: references either EST [RFC7030] as in BRSKI or CMP, CMC, SCEP, or newly defined approaches as alternatives. Note: the IANA registration of the well-known URI is expected to be done by the enrollment protocol. For CMP a lightweight profile is defined, which provides the definition of the well-known URI in Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile]. o request: depending on the utilized enrollment protocol, the request describes the required operation at the registrar side. Enrollment protocols are expected to define the request endpoints as done by existing protocols (see also Section 6). 5.2. Use Case 2: pledge-agent To support mutual trust establishment of pledges, not directly connected to the domain registrar, a similar approach is applied as discussed for the use case 1. It relies on the exchange of Fries, et al. Expires January 11, 2021 [Page 19] Internet-Draft BRSKI-AE July 2020 authenticated self-contained objects (the voucher request/response objects as known from BRSKI and the certification request/response objects as introduced by BRSKI-AE). This allows independence from the protection provided by the underlying transport. In contrast to BRSKI, the exchange of these objects is performed with the help of a pledge-agent, supporting the interaction of the pledge with the domain registrar. It may be an integrated functionality of a commissioning tool. This leads to enhancements of the logical elements in the BRSKI architecture as shown in Figure 3. The pledge- agent provides an interface to the pledge to enable creation or consumption of required data objects, which are exchanged with the domain registrar. Moreover, the addition of the pledge-agent also influences the sequences for the data exchange between the pledge and the domain registrar described in [I-D.ietf-anima-bootstrapping-keyinfra]. The general goal for the pledge-agent application is the reuse of already defined endpoints on the domain registrar side. The behavior of the endpoint may need to be adapted. Fries, et al. Expires January 11, 2021 [Page 20] Internet-Draft BRSKI-AE July 2020 +------------------------+ +--------------Drop Ship---------------| Vendor Service | | +------------------------+ | | M anufacturer| | | | A uthorized |Ownership| | | S igning |Tracker | | | A uthority | | | +--------------+---------+ | ^ | | BRSKI- V | MASA +-------+ +-------+ .............................|......... | | | | . | . | | | | . +-----------+ +-----v-----+ . | | |Pledge | . | | | | . |Pledge | | Agent | . | Join | | Domain | . | | | | . | Proxy | | Registrar | . | <----->.......<-------->...........<-------> (PKI RA) | . | | | | . | BRSKI-AE | | . | | | | . | | +-----+-----+ . |IDevID | |opt. | . +-----------+ | . | | |IDevID | . +------------------+-----+ . | | |or | . | Key Infrastructure | . | | |LDevID | . | (e.g., PKI Certificate | . +-------+ +-------+ . | Authority) | . . +------------------------+ . ....................................... "Domain" components Figure 3: Architecture overview using a pledge-agent The architecture overview in Figure 3 utilizes the same logical elements as BRSKI with the addition of the pledge-agent. The pledge- agent, may originate from the pledge manufacturer and may have either an own IDevID credential issued by the manufacturer or an LDevID issued already by the deployment (on-site) domain. For authentication towards the domain registrar, the pledge-agent may use the IDevID or LDevID credentials, which are verified by the domain registrar as part of the TLS establishment. The provisioning of this credential to the pledge-agent is out of scope for this specification. Alternatively, the domain registrar may authenticate the user operating the pledge-agent to perform authorization of pledge onboarding. Examples for such a user level authentication are the application of HTTP authentication or the usage of SAML tokens or the application of a user related certificates in the TLS handshake or other. If the pledge-agent utilizes a certificate, the domain Fries, et al. Expires January 11, 2021 [Page 21] Internet-Draft BRSKI-AE July 2020 registrar must be able to verify the certificate by possessing the corresponding root certificate. The following list describes the components in the deployment domain: o Pledge: The pledge is expected to communicate with the pledge- agent for providing the necessary data objects for onboarding. The exact protocol used between the pledge and the pledge-agent is out of scope for this document but may consider: If the pledge is triggered/PUSHED by the pledge-agent, it becomes a callee. There are some differences to BRSKI: * Discovery of the domain registrar will be omitted as the pledge is expected to be triggered by the pledge-agent. * The pledge-agent is expected to provide an option to trigger the onboarding by pushing data objects to the pledge. * Order of exchanges in the call flow is different as the pledge- agent collects both voucher request objects and certification request objects at once. * The data objects utilized are the same objects already applied in use case 1 Section 5.1. o Pledge-Agent: provides a communication path to exchange data objects between the pledge and the domain registrar. The pledge- agent facilitates situations, in which the domain registrar is not directly reachable by the pledge, either due to a different technology stack or due to missing connectivity (e.g., if the domain registrar resides in the cloud and the pledge has no connectivity, yet). The pledge-agent in this cases can easily collect voucher request objects and certification request objects from one or multiple pledges at once and perform a bulk onboarding based on the collected data. The pledge-agent may be configured with the domain registrar information or may use the discovery mechanism. o Join Proxy: same functionality as described in BRSKI. o Domain Registrar: In general the domain registrar fulfills the same functionality regarding the onboarding of the pledge in the deployment domain by facilitating the communication of the pledge with the MASA and the PKI. In contrast to BRSKI, the domain registrar does not interact with a pledge directly but through the pledge-agent. This prohibits a pledge authentication using its IDevID during TLS establishment towards the registrar. If the pledge-agent has an IDevID or is already possessing a LDevID valid Fries, et al. Expires January 11, 2021 [Page 22] Internet-Draft BRSKI-AE July 2020 in the deployment domain, it is expected to use this authentication towards the domain registrar. The manufacturer provided components/services (MASA and Ownership tracker) are used as defined in BRSKI. 5.2.1. Behavior of a pledge The behavior of a pledge as described for use case 1 Section 5.1 is basically kept regarding the generation of voucher request/response objects and certificate request/response objects. Due to the use of the pledge-agent, the interaction with the domain registrar is changed as shown in Figure 4. The interaction of the pledge with the pledge-agent in terms of utilized protocols or discovery options is out of scope of this document. This document concentrates on the exchanged data objects between the pledge and the domain registrar via the pledge-agent. The pledge-agent should be able to authenticate the pledge-agent either based on security mechanisms as part of the communication channel between the pledge and the pledge-agent or based on the data (request) objects. The pledge-agent should provide the proximity-registrar-cert to the pledge to enable embedding in the voucher request object. The registrar certificate may be configured at the pledge-agent or may be fetched by the pledge-agent based on the TLS connection establishment with the domain registrar. The pledge interacts with the pledge-agent, to generate a voucher request object (VouReq) and a certification request object (CR), which are provided to the domain registrar through the pledge-agent. The pledge shall generate the voucher request object as described in [I-D.ietf-anima-bootstrapping-keyinfra] and provide this information to the pledge-agent. After the voucher request exchange the pledge will be triggered by to generate a certification request object. For this, the pledge-agent may have been pre-configured with the certification request attributes, that it may provide to the pledge. The certification request is generated as authenticated self-signed object, which assures proof of possession of the private key corresponding to the contained public key in the certification request as well as a proof of identity, based on the IDevID of the pledge. This is done as described for use case 1 Section 5.1. Fries, et al. Expires January 11, 2021 [Page 23] Internet-Draft BRSKI-AE July 2020 5.2.2. Behavior of a pledge-agent The pledge-agent is a new component in the BRSKI context. It provides connectivity between the pledge and the domain registrar and utilizes the endpoints already specified in [I-D.ietf-anima-bootstrapping-keyinfra]. The pledge-agent is expected to interact with the pledge independent of the domain registrar. As stated before, data exchange is only defined based on the data objects, which are the voucher request/response objects and the certification request/response objects. The transport mechanism is out of scope here. This changes the general interaction as shown in Figure 4. The pledge-agent may have an own IDevID or a deployment domain issued LDevID to be utilized in the TLS communication establishment towards the domain registrar. Note that the pledge-agent may also be used without client side authentication if no suitable credential is available on transport layer. As BRSKI-AE utilizes authenticated self-contained data objects, which bind the pledge authentication (proof of identity) directly to the objects (voucher request and certification request), the TLS client authentication may be neglected. This is a deviation from the BRSKI approach in which the pledge's IDevID credential is used to perform TLS client authentication. According to [I-D.ietf-anima-bootstrapping-keyinfra] section 5.3, the domain registrar performs the pledge authorization for onboarding within his domain based on the provided voucher request. 5.2.3. Registrar discovery The discovery phase may be applied as specified in [I-D.ietf-anima-bootstrapping-keyinfra] with the deviation that it is done between the pledge-agent and the domain registrar. Alternatively, the domain registrar may be configured in the pledge- agent. The discovery of the pledge-agent by the pledge belongs to the communication between the two instances and is out of scope for this specification. 5.2.4. Handling voucher request and certification requests The BRSKI-AE exchange of voucher requests and certification requests utilizes authenticated self-contained objects independent of transport protection. +--------+ +-------+ +-----------+ +--------+ +---------+ | Pledge | | Pledge| | Domain | | Domain | | Vendor | Fries, et al. Expires January 11, 2021 [Page 24] Internet-Draft BRSKI-AE July 2020 | | | Agent | | Registrar | | CA | | Service | | | | | | (JRC) | | | | (MASA) | +--------+ +-------+ +-----------+ +--------+ +---------+ | | | | Internet | | opt: configure | | | | - proximity-registrar-cert | | | | - CSR attributes | | | | | | | | [example: trigger voucher and certification request generation ] | | | | | | |<--trigger VouReq--| | | | |(o: proximity-cert)| | | | |- Voucher Request->| | | | | | | | | |<--trigger CR------| | | | |(o: attributes) | | | | |----Cert Request-->| | | | | |<---- TLS --->| | | | | | | | [Start known BRSKI interaction ] | | | | | | | | | |--- VouReq -->| | | | | [accept device?] | | | | [contact vendor] | | | | |----- Voucher Request ------>| | | |----- Pledge ID ------------>| | | |----- Domain ID ------------>| | | |----- optional: nonce ------>| | | | [extract DomainID] | | | [update audit log] | | |<--------- Voucher ---------| | |<-- Voucher --| | | | | |<----- device audit log ----| | | | | | [optional retrieve CA certs] | | | | |- CACertReq ->| | | | | |- CACertReq -->| | | | |<-CACertResp --| | | |< CACertResp -| | | | | | | | [certification request] | | | | |-- CertReq -->| | | | | |-- CertReq --->| | | | |<--CertResp----| | | |<-- CertResp -| | | | | | | | [Stop known BRSKI interaction ] | | | | | | | | Fries, et al. Expires January 11, 2021 [Page 25] Internet-Draft BRSKI-AE July 2020 [push voucher and certificate to pledge, optionally push CA certs] | | | | | | |<---post Voucher---| | | | |- Voucher Status-->| | | | | | | | | |<---post CACerts---| | | | |- CACerts Status-->| | | | | | | | | | | | | | |<--post CertResp---| | | | |---- CertConf ---->| | | | | | | | | | [voucher status telemetry ] | | | |VoucherStatus>| | | | |[verify audit log and voucher]| | | | | | | | | [enroll Status] | | | |-- CertConf ->| | | | | |-- CertConf -->| | | | | | | Figure 4: Request handling of the pledge using a pledge-agent As shown in Figure 4 the pledge-agent collects the voucher request and certification request objects from a pledge. As the pledge-agent (e.g., as part of a commissioning tool) is intended to work between the pledge and the domain registrar, a collection of requests from multiple pledges is possible, allowing a bulk onboarding of multiple pledges using the connection between the pledge-agent and the domain registrar. The information exchange between the pledge-agent and the domain registrar resembles the exchanges between the pledge and the domain registrar from BRSKI with one exception. As authenticated self- contained objects are used consequently, the authentication of the pledge-agent to the domain registrar may be neglected. Note that this allows to employ simple applications as pledge-agent. The authentication of the pledge-agent is recommended if it is desired to perform the onboarding with an authorized pledge-agent or to support advanced auditing in case a user based authentication is done. As stated above, the authentication may be realized by device (IDevID or LDevID) or user related credentials in the context of the TLS handshake, HTTP based authentication, SAML tokens or other. [RFC Editor: please delete] /* to be discussed: Description on how the registrar makes the decision if he is connected with pledge directly or with a pledge-agent. This may result in a case statement (client side authentication in TLS, user authentication above TLS, Fries, et al. Expires January 11, 2021 [Page 26] Internet-Draft BRSKI-AE July 2020 etc.) for the TLS connection establishment in the original BRSKI document in section 5.1 */ Once the pledge-agent has finished the exchanges with the domain registrar to get the voucher and the certificate object, it can close the TLS connection to the domain registrar and provide the objects to the pledge(s). The transport of the objects to the pledge is out of scope. The content of the response objects is defined through the voucher [RFC8366] and the certificate [RFC5280]. 5.3. Discovery of supported enrollment options at domain registrar Well-know URIs for different endpoints on the domain registrar are already defined as part of the base BRSKI specification. In addition, this document utilizes well-known URIs to allow for alternative enrollment options at the domain registrar. The discovery of supported endpoints will therefore provide the information to the pledge, how to contact the domain registrar. Querying the registrar, the pledge will get a list of potential endpoints supported by the domain registrar. To allow for a BRSKI specific discovery of endpoints/resources, this document specifies a new URI for the discovery as "/.well-known/brski". Performing a GET on "/.well-known/brski" to the default port returns a set of links to endpoints available from the server. In addition to the link also the expected format of the data object is provided as content type (ct). The following provides an illustrative example for a domain registrar supporting different options for EST as well as CMP to be used in BRSKI-AE. The listing contains the supported endpoints for the onboarding: REQ: GET /.well-known/brski Fries, et al. Expires January 11, 2021 [Page 27] Internet-Draft BRSKI-AE July 2020 RES: Content </brski/voucherrequest>,ct=voucher-cms+json </brski/voucher_status>,ct=json </brski/requestauditlog>,ct=json </brski/enrollstatus>,ct=json </est/cacerts>;ct=pkcs7-mime </est/cacerts>;ct=pkcs7-mime </est/simpleenroll>;ct=pkcs7-mime </est/simplereenroll>;ct=pkcs7-mime </est/fullcmc>;ct=pkcs7-mime </est/serverkeygen>;ct= pkcs7-mime </est/csrattrs>;ct=pkcs7-mime </cmp/initialization>;ct=pkixcmp </cmp/certification>;ct=pkixcmp </cmp/keyupdate>;ct=pkixcmp </cmp/p10>;ct=pkixcmp </cmp/getCAcert>;ct=pkixcmp </cmp/getCSRparam>;ct=pkixcmp [RFC Editor: please delete] /* Open Issues: o Change path from /est to /brski to be protocol agnostic o Define new well-know URI as above or reuse core approach as described in RFC 6690 with /.well-known/core and the already defined functionality? o In addition to the current content types, we may specify that the response provide information about different content types as multiple values. This would allow to further adopt the encoding of the objects exchanges (ASN.1, JSON, CBOR, ...). */ 6. Example mappings to existing enrollment protocols This sections maps the requirements to support proof of possession and proof of identity to selected existing enrollment protocols. Note that that the work in the ACE WG described in [I-D.selander-ace-coap-est-oscore] may be considered here as well, as it also addresses the encapsulation of EST in a way to make it independent from the underlying TLS using OSCORE resulting in an authenticated self-contained object. Fries, et al. Expires January 11, 2021 [Page 28] Internet-Draft BRSKI-AE July 2020 6.1. EST Handling When using EST [RFC7030], the following constrains should be considered: o Proof of possession is provided by using the specified PKCS#10 structure in the request. o Proof of identity is achieved by signing the certification request object, which is only supported when the /fullcmc endpoint is used. This contains sufficient information for the RA to make an authorization decision on the received certification request. Note: EST references CMC [RFC5272] for the definition of the Full PKI Request. For proof of identity, the signature of the SignedData of the Full PKI Request would be calculated using the IDevID credential of the pledge. o [RFC Editor: please delete] /* TBD: in this case the binding to the underlying TLS connection is not be necessary. */ o When the RA is not available, as per [RFC7030] Section 4.2.3, a 202 return code should be returned by the Registrar. The pledge in this case would retry a simpleenroll with a PKCS#10 request. Note that if the TLS connection is teared down for the waiting time, the PKCS#10 request would need to be rebuild if it contains the unique identifier (tls_unique) from the underlying TLS connection for the binding. o [RFC Editor: please delete] /* TBD: clarification of retry for fullcmc is necessary as not specified in the context of EST */ 6.2. Lightweight CMP Handling Instead of using CMP [RFC4210], this specification refers to the lightweight CMP profile [I-D.ietf-lamps-lightweight-cmp-profile], as it restricts the full featured CMP to the functionality needed here. For this, the following constrains should be observed: o For proof of possession, the defined approach in Lightweight CMP section 5.1.1 (based on CRMF) and 5.1.5 based on PCKS#10 should be supported. o Proof of identity can be provided by using the signatures to protect the certificate request message as outlined in section 4.2. o When the RA/CA is not available, a waiting indication should be returned in the PKIStatus by the Registrar. The pledge in this Fries, et al. Expires January 11, 2021 [Page 29] Internet-Draft BRSKI-AE July 2020 case would retry using the PollReqContent with a request identifier certReqId provided in the initial CertRequest message as specified in section 6.1.4 with delayed enrollemnt. 7. IANA Considerations This document requires the following IANA actions: [RFC Editor: please delete] /* to be done: IANA consideration to be included for the defined namespaces in Section 5.1.5 and Section 5.3 . */ 8. Privacy Considerations [RFC Editor: please delete] /* to be done: clarification necessary */ 9. Security Considerations [RFC Editor: please delete] /* to be done: clarification necessary */ 10. Acknowledgments We would like to thank the various reviewers for their input, in particular Brian E. Carpenter, Giorgio Romanenghi, Oskar Camenzind, for their input and discussion on use cases and call flows. 11. References 11.1. Normative References [I-D.ietf-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- keyinfra-41 (work in progress), April 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>. Fries, et al. Expires January 11, 2021 [Page 30] Internet-Draft BRSKI-AE July 2020 [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>. 11.2. Informative References [I-D.gutmann-scep] Gutmann, P., "Simple Certificate Enrolment Protocol", draft-gutmann-scep-16 (work in progress), March 2020. [I-D.ietf-lamps-lightweight-cmp-profile] Brockhaus, H., Fries, S., and D. Oheimb, "Lightweight CMP Profile", draft-ietf-lamps-lightweight-cmp-profile-01 (work in progress), March 2020. [I-D.selander-ace-coap-est-oscore] Selander, G., Raza, S., Furuhed, M., Vucinic, M., and T. Claeys, "Protecting EST Payloads with OSCORE", draft- selander-ace-coap-est-oscore-03 (work in progress), March 2020. [IEC-62351-9] International Electrotechnical Commission, "IEC 62351 - Power systems management and associated information exchange - Data and communications security - Part 9: Cyber security key management for power system equipment", IEC 62351-9 , May 2017. [ISO-IEC-15118-2] International Standardization Organization / International Electrotechnical Commission, "ISO/IEC 15118-2 Road vehicles - Vehicle-to-Grid Communication Interface - Part 2: Network and application protocol requirements", ISO/ IEC 15118 , April 2014. [NERC-CIP-005-5] North American Reliability Council, "Cyber Security - Electronic Security Perimeter", CIP 005-5, December 2013. [OCPP] Open Charge Alliance, "Open Charge Point Protocol 2.0 (Draft)", April 2018. [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/info/rfc2986>. Fries, et al. Expires January 11, 2021 [Page 31] Internet-Draft BRSKI-AE July 2020 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, DOI 10.17487/RFC4210, September 2005, <https://www.rfc-editor.org/info/rfc4210>. [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, <https://www.rfc-editor.org/info/rfc4211>. [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, <https://www.rfc-editor.org/info/rfc5272>. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>. Appendix A. History of changes [RFC Editor: please delete] From individual version 03 -> IETF draft 00: o Inclusion of discovery options of enrollment endpoints at the domain registrar based on well-known endpoints in Section 5.3 as replacement of section 5.1.3 in the individual draft. This is intended to support both use cases in the document. An illustrative example is provided. o Missing details provided for the description and call flow in pledge-agent use case Section 5.2, e.g. to accommodate distribution of CA certificates. o Updated CMP example in Section 6 to use lightweight CMP instead of CMP, as the draft already provides the necessary /.well-known endpoints. Fries, et al. Expires January 11, 2021 [Page 32] Internet-Draft BRSKI-AE July 2020 o Requirements discussion moved to separate section in Section 4. Shortened description of proof of identity binding and mapping to existing protocols. o Removal of copied call flows for voucher exchange and registrar discovery flow from [I-D.ietf-anima-bootstrapping-keyinfra] in Section 5.1 to avoid doubling or text or inconsistencies. o Reworked abstract and introduction to be more crisp regarding the targeted solution. Several structural changes in the document to have a better distinction between requirements, use case description, and solution description as separate sections. History moved to appendix. From individual version 02 -> 03: o Update of terminology from self-contained to authenticated self- contained object to be consistent in the wording and to underline the protection of the object with an existing credential. Note that the naming of this object may be discussed. An alternative name may be attestation object. o Simplification of the architecture approach for the initial use case having an offsite PKI. o Introduction of a new use case utilizing authenticated self- contain objects to onboard a pledge using a commissioning tool containing a pledge-agent. This requires additional changes in the BRSKI call flow sequence and led to changes in the introduction, the application example,and also in the related BRSKI-AE call flow. o Update of provided examples of the addressing approach used in BRSKI to allow for support of multiple enrollment protocols in Section 5.1.5. From individual version 01 -> 02: o Update of introduction text to clearly relate to the usage of IDevID and LDevID. o Definition of the addressing approach used in BRSKI to allow for support of multiple enrollment protocols in Section 5.1.5. This section also contains a first discussion of an optional discovery mechanism to address situations in which the registrar supports more than one enrollment approach. Discovery should avoid that the pledge performs a trial and error of enrollment protocols. Fries, et al. Expires January 11, 2021 [Page 33] Internet-Draft BRSKI-AE July 2020 o Update of description of architecture elements and changes to BRSKI in Section 5. o Enhanced consideration of existing enrollment protocols in the context of mapping the requirements to existing solutions in Section 4 and in Section 6. From individual version 00 -> 01: o Update of examples, specifically for building automation as well as two new application use cases in Section 3.2. o Deletion of asynchronous interaction with MASA to not complicate the use case. Note that the voucher exchange can already be handled in an asynchronous manner and is therefore not considered further. This resulted in removal of the alternative path the MASA in Figure 1 and the associated description in Section 5. o Enhancement of description of architecture elements and changes to BRSKI in Section 5. o Consideration of existing enrollment protocols in the context of mapping the requirements to existing solutions in Section 4. o New section starting Section 6 with the mapping to existing enrollment protocols by collecting boundary conditions. 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 January 11, 2021 [Page 34] Internet-Draft BRSKI-AE July 2020 Eliot Lear Cisco Systems Richtistrasse 7 Wallisellen CH-8304 Switzerland Phone: +41 44 878 9200 Email: lear@cisco.com Fries, et al. Expires January 11, 2021 [Page 35]