| < draft-ietf-anima-brski-prm-02.txt | draft-ietf-anima-brski-prm-03.txt > | |||
|---|---|---|---|---|
| ANIMA WG S. Fries | ANIMA WG S. Fries | |||
| Internet-Draft T. Werner | Internet-Draft T. Werner | |||
| Intended status: Standards Track Siemens | Intended status: Standards Track Siemens | |||
| Expires: 5 September 2022 E. Lear | Expires: 31 October 2022 E. Lear | |||
| Cisco Systems | Cisco Systems | |||
| M. Richardson | M. Richardson | |||
| Sandelman Software Works | Sandelman Software Works | |||
| 4 March 2022 | 29 April 2022 | |||
| BRSKI with Pledge in Responder Mode (BRSKI-PRM) | BRSKI with Pledge in Responder Mode (BRSKI-PRM) | |||
| draft-ietf-anima-brski-prm-02 | draft-ietf-anima-brski-prm-03 | |||
| Abstract | Abstract | |||
| This document defines enhancements to bootstrapping a remote secure | This document defines enhancements to bootstrapping a remote secure | |||
| key infrastructure (BRSKI, [RFC8995]) to facilitate bootstrapping in | key infrastructure (BRSKI, [RFC8995]) to facilitate bootstrapping in | |||
| domains featuring no or only timely limited connectivity between a | domains featuring no or only timely limited connectivity between a | |||
| pledge and the domain registrar. It specifically targets situations, | pledge and the domain registrar. It specifically targets situations, | |||
| in which the interaction model changes from a pledge-initiator-mode, | in which the interaction model changes from a pledge-initiator-mode, | |||
| as used in BRSKI, to a pledge-responder-mode as described in this | as used in BRSKI, to a pledge-responder-mode as described in this | |||
| document. To support both, BRSKI-PRM introduces a new registrar- | document. To support both, BRSKI-PRM introduces a new registrar- | |||
| skipping to change at page 1, line 47 ¶ | skipping to change at page 1, line 47 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 5 September 2022. | This Internet-Draft will expire on 31 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 31 ¶ | skipping to change at page 2, line 31 ¶ | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Scope of Solution . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Scope of Solution . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3.1. Supported Environment . . . . . . . . . . . . . . . . . . 6 | 3.1. Supported Environment . . . . . . . . . . . . . . . . . . 6 | |||
| 3.2. Application Examples . . . . . . . . . . . . . . . . . . 6 | 3.2. Application Examples . . . . . . . . . . . . . . . . . . 6 | |||
| 3.2.1. Building Automation . . . . . . . . . . . . . . . . . 6 | 3.2.1. Building Automation . . . . . . . . . . . . . . . . . 6 | |||
| 3.2.2. Infrastructure Isolation Policy . . . . . . . . . . . 7 | 3.2.2. Infrastructure Isolation Policy . . . . . . . . . . . 7 | |||
| 3.2.3. Less Operational Security in the Target-Domain . . . 7 | 3.2.3. Less Operational Security in the Target-Domain . . . 7 | |||
| 3.3. Limitations . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.3. Limitations . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4. Requirements Discussion and Mapping to Solution-Elements . . 7 | 4. Requirements Discussion and Mapping to Solution-Elements . . 7 | |||
| 5. Architectural Overview and Communication Exchanges . . . . . 8 | 5. Architectural Overview and Communication Exchanges . . . . . 9 | |||
| 5.1. Pledge-responder-mode (PRM): Registrar-agent Communication | 5.1. Pledge-responder-mode (PRM): Registrar-agent Communication | |||
| with Pledges . . . . . . . . . . . . . . . . . . . . . . 9 | with Pledges . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 5.1.1. Agent-Proximity . . . . . . . . . . . . . . . . . . . 12 | 5.2. Agent-Proximity Assertion . . . . . . . . . . . . . . . . 13 | |||
| 5.1.2. Behavior of Pledge in Pledge-Responder-Mode . . . . . 13 | 5.3. Behavior of Pledge in Pledge-Responder-Mode . . . . . . . 14 | |||
| 5.1.3. Behavior of Registrar-Agent . . . . . . . . . . . . . 14 | 5.4. Behavior of Registrar-Agent . . . . . . . . . . . . . . . 15 | |||
| 5.1.4. Bootstrapping Objects and Corresponding Exchanges . . 16 | 5.4.1. Discovery of Registrar by Registrar-Agent . . . . . . 17 | |||
| 6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 42 | 5.4.2. Discovery of Pledge by Registrar-Agent . . . . . . . 17 | |||
| 6.1. Voucher Request Artifact . . . . . . . . . . . . . . . . 42 | 5.5. Bootstrapping Objects and Corresponding Exchanges . . . . 17 | |||
| 6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 42 | 5.5.1. Request Objects Acquisition by Registrar-Agent from | |||
| 6.1.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 43 | Pledge . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 | 5.5.2. Request Processing by the Registrar-Agent . . . . . . 28 | |||
| 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 47 | 5.5.3. Response Object Supply by Registrar-Agent to | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 47 | Pledge . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
| 9.1. Exhaustion Attack on Pledge . . . . . . . . . . . . . . . 48 | 5.5.4. Telemetry status handling (registrar-agent - domain | |||
| 9.2. Misuse of acquired Voucher and Enrollment responses by | registrar) . . . . . . . . . . . . . . . . . . . . . 42 | |||
| Registrar-Agent . . . . . . . . . . . . . . . . . . . . . 48 | 6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 44 | |||
| 9.3. Misuse of Registrar-Agent Credentials . . . . . . . . . . 48 | 6.1. Voucher Request Artifact . . . . . . . . . . . . . . . . 44 | |||
| 9.4. YANG Module Security Considerations . . . . . . . . . . . 48 | 6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 44 | |||
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 | 6.1.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 44 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 49 | 7.1. BRSKI .well-known Registry . . . . . . . . . . . . . . . 48 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 50 | ||||
| Appendix A. History of Changes [RFC Editor: please delete] . . . 51 | 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 | |||
| 9.1. Exhaustion Attack on Pledge . . . . . . . . . . . . . . . 49 | ||||
| 9.2. Misuse of acquired Voucher and Enrollment objects by | ||||
| Registrar-Agent . . . . . . . . . . . . . . . . . . . . . 49 | ||||
| 9.3. Misuse of Registrar-Agent Credentials . . . . . . . . . . 50 | ||||
| 9.4. YANG Module Security Considerations . . . . . . . . . . . 50 | ||||
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 | ||||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 | ||||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 51 | ||||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 52 | ||||
| Appendix A. History of Changes [RFC Editor: please delete] . . . 53 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 | ||||
| 1. Introduction | 1. Introduction | |||
| BRSKI as defined in [RFC8995] specifies a solution for secure zero- | BRSKI as defined in [RFC8995] specifies a solution for secure zero- | |||
| touch (automated) bootstrapping of devices (pledges) in a (customer) | touch (automated) bootstrapping of devices (pledges) in a (customer) | |||
| site domain. This includes the discovery of network elements in the | site domain. This includes the discovery of network elements in the | |||
| target domain, time synchronization, and the exchange of security | customer site/domain and the exchange of security information | |||
| information necessary to establish trust between a pledge and the | necessary to establish trust between a pledge and the domain. | |||
| domain. Security information about the target domain, specifically | ||||
| the target domain certificate, is exchanged utilizing voucher objects | Security information about the customer site/domain, specifically the | |||
| as defined in [RFC8366]. These vouchers are signed objects, provided | customer site/domain certificate, is exchanged utilizing voucher | |||
| via the domain registrar to the pledge and originate from a | objects as defined in [RFC8366]. These vouchers are signed objects, | |||
| provided via the domain registrar to the pledge and originate from a | ||||
| Manufacturer's Authorized Signing Authority (MASA). | Manufacturer's Authorized Signing Authority (MASA). | |||
| BRSKI addresses scenarios in which the pledge acts as client for the | BRSKI addresses scenarios in which the pledge acts as client for the | |||
| bootstrapping and is the initiator of the bootstrapping (this | bootstrapping and is the initiator of the bootstrapping (this | |||
| document refers to the approach as pledge-initiator-mode). In | document refers to the approach as pledge-initiator-mode). In | |||
| industrial environments the pledge may behave as a server and thus | industrial environments the pledge may behave as a server and thus | |||
| does not initiate the bootstrapping with the domain registrar. In | does not initiate the bootstrapping with the domain registrar. In | |||
| this scenarios it is expected that the pledge will be triggered to | this scenarios it is expected that the pledge will be triggered to | |||
| generate request objects to be bootstrapped in the registrar's domain | generate request objects to be bootstrapped in the customer site/ | |||
| (this document refers to the approach as pledge-responder-mode). For | domain (this document refers to the approach as pledge-responder- | |||
| this, an additional component is introduced acting as an agent for | mode). For this, an additional component is introduced acting as an | |||
| the domain registrar (registrar-agent) towards the pledge. This may | agent for the domain registrar (registrar-agent) towards the pledge. | |||
| be a functionality of a commissioning tool or it may be even co- | This may be a functionality of a commissioning or configuration tool | |||
| located with the registrar. In contrast to BRSKI the registrar-agent | or it may be even co-located with the registrar. | |||
| performs the object exchange with the pledge and provides/retrieves | ||||
| data objects to/from the domain registrar. For the interaction with | In contrast to BRSKI the registrar-agent facilitates the object | |||
| the domain registrar the registrar-agent will use existing BRSKI | exchange with the pledge and provides/retrieves data objects to/from | |||
| [RFC8995] endpoints. | the domain registrar. For the interaction with the domain registrar | |||
| the registrar-agent will use existing BRSKI [RFC8995] endpoints. | ||||
| The goal is to enhance BRSKI to support pledges in responder mode. | The goal is to enhance BRSKI to support pledges in responder mode. | |||
| This is addressed by | This is addressed by | |||
| * introducing the registrar-agent as new component to facilitate the | * introducing the registrar-agent as new component to facilitate the | |||
| communication between the pledge and the registrar, when the | communication between the pledge and the registrar, if the pledge | |||
| pledge is in responder mode (acting as server). | is in responder mode (acting as server). | |||
| * handling the security on application layer only to enable | * handling the security on application layer only to enable | |||
| application of arbitrary transport means between the pledge and | application of arbitrary transport means between the pledge and | |||
| the domain registrar, by keeping the registrar-agent in the | the domain registrar, by keeping the registrar-agent in the | |||
| communication path. Examples may be connectivity via IP based | communication path. Examples may be connectivity via IP based | |||
| networks (wired or wireless) but also connectivity via Bluetooth | networks (wired or wireless) but also connectivity via Bluetooth | |||
| or NFC between the pledge and the registrar-agent. | or NFC between the pledge and the registrar-agent. | |||
| * allowing to utilize credentials different from the pledge's IDevID | * allowing to utilize credentials different from the pledge's IDevID | |||
| to establish a TLS connection to the domain registrar, which is | to establish a TLS connection to the domain registrar, which is | |||
| necessary in case of using a registrar-agent. | necessary in case of using a registrar-agent. | |||
| * defining the interaction (data exchange and data objects) between | * defining the interaction (data exchange and data objects) between | |||
| a pledge acting as server and a registrar-agent and the domain | a pledge acting as server and a registrar-agent and the domain | |||
| registrar. | registrar. | |||
| For the enrollment of devices BRSKI relies on EST [RFC7030] to | For the enrollment of devices BRSKI relies on EST [RFC7030] to | |||
| request and distribute target domain specific device certificates. | request and distribute customer site/domain specific device | |||
| EST in turn relies on a binding of the certification request to an | certificates. EST in turn relies on a binding of the certification | |||
| underlying TLS connection between the EST client and the EST server. | request to an underlying TLS connection between the EST client and | |||
| According to BRSKI the domain registrar acts as EST server and is | the EST server. According to BRSKI the domain registrar acts as EST | |||
| also acting as registration authority (RA) for its domain. To | server and is also acting as registration authority (RA) for its | |||
| utilize the EST server endpoints on the domain-registrar, the | domain. To utilize the EST server endpoints on the domain-registrar, | |||
| registrar-agent defined in this document will act as client towards | the registrar-agent defined in this document will act as client | |||
| the domain registrar. The registrar-agent will also act as client | towards the domain registrar. The registrar-agent will also act as | |||
| when communicating with the pledge in responder mode. Here, TLS with | client when communicating with the pledge in responder mode. Here, | |||
| server-side, certificate-based authentication is not directly | TLS with server-side, certificate-based authentication is not | |||
| applicable, as the pledge only possesses an IDevID certificate, which | directly applicable, as the pledge only possesses an IDevID | |||
| does not contain a subject alternative name (SAN) for the target | certificate, which does not contain a subject alternative name (SAN) | |||
| domain and does also not contain a TLS server flag. This is one | for the customer site/domain and does also not contain a TLS server | |||
| reason for relying on higher layer security by using signature | flag. This is one reason for relying on higher layer security by | |||
| wrapped objects for the exchange between the pledge and the registrar | using signature wrapped objects for the exchange between the pledge | |||
| agent. A further reason is the application on different transports, | and the registrar agent. A further reason is the application on | |||
| for which TLS may not be available, like Bluetooth or NFC. As the | different transports, for which TLS may not be available, like | |||
| described solution will rely on additional wrapping signature it will | Bluetooth or NFC. As the described solution will rely on additional | |||
| require pre-processing specifically for EST, as it currently uses | wrapping signature it will require pre-processing specifically for | |||
| PKCS#10 requests only. | EST. EST simpleenroll uses PKCS#10 requests only. | |||
| 2. Terminology | 2. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| This document relies on the terminology defined in [RFC8995]. The | This document relies on the terminology defined in [RFC8995], section | |||
| following terms are defined additionally: | 1.2. The following terms are defined additionally: | |||
| asynchronous communication: Describes a timely interrupted | ||||
| communication between an end entity and a PKI component. | ||||
| authenticated self-contained object: Describes an object, which is | authenticated self-contained object: Describes an object, which is | |||
| cryptographically bound to the EE certificate (IDevID certificate | cryptographically bound to the end entity (EE) certificate (IDevID | |||
| or LDEVID certificate) of a pledge. The binding is assumed to be | certificate or LDEVID certificate). The binding is assumed to be | |||
| provided through a digital signature of the actual object using | provided through a digital signature of the actual object using | |||
| the corresponding private key of the EE certificate. | the corresponding private key of the EE certificate. | |||
| CA: Certification authority, issues certificates. | CA: Certification authority, issues certificates. | |||
| Commissioning tool: Tool to interact with devices to provide | ||||
| configuration data | ||||
| EE: End entity | EE: End entity | |||
| on-site: Describes a component or service or functionality available | on-site: Describes a component or service or functionality available | |||
| in the target deployment domain. | in the customer site/domain. | |||
| off-site: Describes a component or service or functionality | off-site: Describes a component or service or functionality not | |||
| available in an operator domain different from the target | available in the customer site/domain. This may be a central site | |||
| deployment domain. This may be a central site or a cloud service, | or a cloud service, to which only a temporary connection is | |||
| to which only a temporary connection is available, or which is in | available, or which is in a different administrative domain. | |||
| a different administrative domain. | ||||
| PER: Pledge-enrollment-request | PER: Pledge-enrollment-request | |||
| POP: Prove of possession (of a private key) | POP: Proof of possession (of a private key) | |||
| POI: Prove of identity | POI: Proof of identity | |||
| PVR: Pledge-voucher-request | PVR: Pledge-voucher-request | |||
| IED: Intelligent Electronic Device (in essence a pledge). | ||||
| RA: Registration authority, an optional system component to which a | RA: Registration authority, an optional system component to which a | |||
| CA delegates certificate management functions such as | CA delegates certificate management functions such as | |||
| authorization checks. | authorization checks. | |||
| RER: Registrar-enrollment-request | RER: Registrar-enrollment-request | |||
| RVR: Registrar-voucher-request | RVR: Registrar-voucher-request | |||
| synchronous communication: Describes a timely uninterrupted | ||||
| communication between an end entity and a PKI component. | ||||
| 3. Scope of Solution | 3. Scope of Solution | |||
| 3.1. Supported Environment | 3.1. Supported Environment | |||
| The described solution is applicable in domains in which pledges have | The described solution is applicable in environments in which pledges | |||
| no direct connection to the domain registrar, but are expected to be | have a different technology stack or pledges have no direct | |||
| managed by this registrar. This can be motivated by pledges | connection to the domain registrar, but are expected to be managed by | |||
| featuring a different technology stack or by pledges without an | this registrar. This can be motivated by pledges deployed in | |||
| existing connection to the domain registrar during bootstrapping. | networks not connected to the operational customer site/domain, e.g., | |||
| These pledges are likely to act in a server role. Therefore, the | during construction of a site. Another application is the | |||
| pledge has to offer endpoints on which it can be triggered for the | preparation of cabinets, which are to be prepared to be installed on | |||
| generation of pledge-voucher-request objects and certification | a customer site/domain. As there is no direct connection to the | |||
| objects as well as to provide the response objects to the pledge. | registrar available in these environments the solution specified in | |||
| this document lets the pledges act in a server role so that they can | ||||
| be accessed by a commissioning tool to trigger the bootstrapping. As | ||||
| BRSKI focuses on the pledge in a client role, initiating the | ||||
| bootstrapping, this document defines pledges acting as a server | ||||
| answering to requests for pledge-voucher-request objects and | ||||
| certification objects. | ||||
| 3.2. Application Examples | 3.2. Application Examples | |||
| The following examples are intended to motivate the support of | The following examples are intended to motivate the support of | |||
| additional bootstrapping approaches in general by introducing | additional bootstrapping approaches. Industrial application use | |||
| industrial applications cases, which could leverage BRSKI as such but | cases are introduced, which could leverage BRSKI as such but | |||
| also require support a pledge acting as server and only answers | additionally require to support pledges acting as server only | |||
| requests as well as scenarios with limited connectivity to the | responding to requests, as well as scenarios with limited | |||
| registrar. | connectivity to the registrar. | |||
| 3.2.1. Building Automation | 3.2.1. Building Automation | |||
| In building automation, a use case can be described by a detached | In building automation a typical use case exists where a detached | |||
| building (or a cabinet) or the basement of a building equipped with | building (or a cabinet) or the basement of a building is equipped | |||
| sensor, actuators, and controllers connected, but with only limited | with sensors, actuators and controllers, but with only limited or no | |||
| or no connection to the centralized building management system. This | connection to the central building management system. This limited | |||
| limited connectivity may be during the installation time but also | connectivity may exist during installation time or also during | |||
| during operation time. During the installation in the basement, a | operation time. During the installation in the basement, a service | |||
| service technician collects the device specific information from the | technician collects the device specific information from the basement | |||
| basement network and provides them to the central building management | network and provides them to the central building management system, | |||
| system, e.g., using a laptop or a mobile device to transport the | e.g., using a laptop or a mobile device to transport the information. | |||
| information. A domain registrar may be part of the central building | A domain registrar may be part of the central building management | |||
| management system and already be operational in the installation | system and already be operational in the installation network. The | |||
| network. The central building management system can then provide | central building management system can then provide operational | |||
| operational parameters for the specific devices in the basement. | parameters for the specific devices in the basement. This | |||
| This operational parameters may comprise values and settings required | operational parameters may comprise values and settings required in | |||
| in the operational phase of the sensors/actuators, beyond them a | the operational phase of the sensors/actuators, among them a | |||
| certificate issued by the operator to authenticate against other | certificate issued by the operator to authenticate against other | |||
| components and services. These operational parameters are then | components and services. These operational parameters are then | |||
| provided to the devices in the basement facilitated by the service | provided to the devices in the basement facilitated by the service | |||
| technician's laptop. | technician's laptop. | |||
| 3.2.2. Infrastructure Isolation Policy | 3.2.2. Infrastructure Isolation Policy | |||
| This refers to any case in which network infrastructure is normally | This refers to any case in which the network infrastructure is | |||
| isolated from the Internet as a matter of policy, most likely for | normally isolated from the Internet as a matter of policy, most | |||
| security reasons. In such a case, limited access to a domain | likely for security reasons. In such a case, limited access to a | |||
| registrar may be allowed in carefully controlled short periods of | domain registrar may be allowed in carefully controlled short periods | |||
| time, for example when a batch of new devices are deployed, but | of time, for example when a batch of new devices are deployed, but | |||
| impossible at other times. | prohibited at other times. | |||
| 3.2.3. Less Operational Security in the Target-Domain | 3.2.3. Less Operational Security in the Target-Domain | |||
| The registration authority (RA) performing the authorization of a | The registration authority (RA) performing the authorization of a | |||
| certificate request is a critical PKI component and therefore | certificate request is a critical PKI component and therefore | |||
| implicates higher operational security than other components | requires higher operational security than other components utilizing | |||
| utilizing the issued certificates . CAs may also demand higher | the issued certificates . CAs may also require higher security in the | |||
| security in the registration procedures. Especially the CA/Browser | registration procedures. Especially the CA/Browser forum currently | |||
| forum currently increases the security requirements in the | increases the security requirements in the certificate issuance | |||
| certificate issuance procedures for publicly trusted certificates. | procedures for publicly trusted certificates. There may be | |||
| There may be the situation in which the target domain does not offer | situations in which the customer site/domain does not offer enough | |||
| enough security to operate a RA/CA and therefore this service is | security to operate a RA/CA and therefore this service is transferred | |||
| transferred to a backend that offers a higher level of operational | to a backend that offers a higher level of operational security. | |||
| security. | ||||
| 3.3. Limitations | 3.3. Limitations | |||
| The mechanisms in this draft presume the availability of the pledge | The mechanisms in this draft presume the availability of the pledge | |||
| to communicate with the registrar-agent. | to communicate with the registrar-agent. | |||
| This may not be possible in constrained environments where, in | This may not be possible in constrained environments where, in | |||
| particular, power must be conserved. | particular, power must be conserved. | |||
| In these situations, it is anticipated that the transceiver will be | In these situations, it is anticipated that the transceiver will be | |||
| powered down most of the time. | powered down most of the time. | |||
| This presents a rendezvous problem: the pledge is unavailable for | This presents a rendezvous problem: the pledge is unavailable for | |||
| certain periods of time, and the registrar-agent is similarly | certain periods of time, and the registrar-agent is similarly | |||
| presumed to be unavailable for certain periods of time. | presumed to be unavailable for certain periods of time. | |||
| 4. Requirements Discussion and Mapping to Solution-Elements | 4. Requirements Discussion and Mapping to Solution-Elements | |||
| Based on the intended target environment described in Section 3.1 and | Based on the intended target environment described in Section 3.1 and | |||
| the motivated application examples described in Section 3.2 the | the application examples described in Section 3.2 the following | |||
| following base requirements are derived to support the communication | requirements are derived to support bootstrapping of pledges in | |||
| between a pledge and a registrar via a registrar-agent. | responder mode (acting as server). | |||
| At least the following properties are required by the voucher | * To facilitate the communication between a pledge in responder mode | |||
| handling and the enrollment: | and registrar, additional functionality is needed either on the | |||
| registrar (if the registrar needs to interact with pledge in | ||||
| responder mode directly) or as a stand-alone component. This | ||||
| component acts as an agent of the registrar to trigger the pledge | ||||
| to generate request objects for voucher and enrollment. These | ||||
| voucher an enrollment request objects are than to be provided by | ||||
| the so called registrar-agent to the registrar. This requires the | ||||
| definition of endpoints on the pledge. | ||||
| * The communication between the registrar-agent and the pledge MUST | ||||
| not rely on transport layer security (TLS) to support also other | ||||
| technology stacks (e.g., BTLE). Therefore authenticated self- | ||||
| contained objects are required. | ||||
| * The registrar-agent must be authenticated by the registrar as a | ||||
| component, acting on behalf of the registrar. In addition the | ||||
| registrar must be able to verify, which registrar-agent was in | ||||
| direct contact with the pledge. | ||||
| * The pledge cannot get the assertion with value "proximity" in the | ||||
| voucher, as it was not in direct contact with the registrar for | ||||
| bootstrapping. Therefore the "agent-proximity" assertion value is | ||||
| necessary for distinguishing assertions the MASA can state. | ||||
| At least the following properties are required for the voucher and | ||||
| enrollment objects: | ||||
| * Proof of Identity (POI): provides data-origin authentication of a | ||||
| data object, e.g., a voucher request or an enrollment request, | ||||
| utilizing an existing IDevID. Certificate updates may utilize the | ||||
| certificate that is to be updated. | ||||
| * Proof of Possession (POP): proves that an entity possesses and | * Proof of Possession (POP): proves that an entity possesses and | |||
| controls the private key corresponding to the public key contained | controls the private key corresponding to the public key contained | |||
| in the certification request, typically by adding a signature | in the certification request, typically by adding a signature | |||
| using the private key. | using the private key to the enrollment request object. | |||
| * Proof of Identity (POI): provides data-origin authentication of a | ||||
| data object, e.g., a certificate request, utilizing an existing | ||||
| IDevID. Certificate updates may utilize the certificate that is | ||||
| to be updated. | ||||
| Solution examples based on existing technology are provided with the | Solution examples based on existing technology are provided with the | |||
| focus on existing IETF documents: | focus on existing IETF RFCs: | |||
| * Voucher request and response objects as used in [RFC8995] already | * Voucher request and response objects as used in [RFC8995] already | |||
| provide both, POP and POI, through a digital signature to protect | provide both, POP and POI, through a digital signature to protect | |||
| the integrity of the voucher object, while the corresponding | the integrity of the voucher object, while the corresponding | |||
| signing certificate contains the identity of the signer. | signing certificate contains the identity of the signer. | |||
| * Certification request objects: Certification requests are data | * Certification request objects: Certification requests are data | |||
| structures containing the information from a requester for a CA to | structures containing the information from a requester for a CA to | |||
| create a certificate. The certification request format in BRSKI | create a certificate. The certification request format in BRSKI | |||
| utilizes PKCS#10 [RFC2986]. Here, the structure is signed to | is PKCS#10 [RFC2986]. In PKCS#10, the structure is signed to | |||
| ensure integrity protection and proof of possession of the private | ensure integrity protection and proof of possession of the private | |||
| key of the requester that corresponds to the contained public key. | key of the requester that corresponds to the contained public key. | |||
| In the application examples, this POP alone is not sufficient. | In the application examples, this POP alone is not sufficient. | |||
| POI is also required for the certification request object and | POI is also required for the certification request object and | |||
| therefore needs to be additionally bound to the existing | therefore needs to be additionally bound to the existing | |||
| credential of the pledge (IDevID). This binding supports the | credential of the pledge (IDevID). This binding supports the | |||
| authorization decision for the certification request through a | authorization decision for the certification request through a | |||
| proof of identity (POI). The binding of data origin | proof of identity (POI). The binding of data origin | |||
| authentication or POI to the certification request may be | authentication or POI to the certification request may be provided | |||
| delegated to the protocol used for certificate management or it | directly by the certification request object. While BRSKI uses | |||
| may be provided directly by the certification request object. | the binding to TLS, BRSKI-PRM aims at an additional signature of | |||
| While BRSKI uses the binding to TLS, BRSKI-PRM aims at an | the PCKS#10 object using existing credentials on the pledge | |||
| additional signature of the PCKS#10 object using the existing | (IDevID). This ensures independence of the selected transport. | |||
| credential on the pledge (IDevID). This supports independence | ||||
| from the selected transport. | ||||
| 5. Architectural Overview and Communication Exchanges | 5. Architectural Overview and Communication Exchanges | |||
| For BRSKI with pledge in responder mode, the base system architecture | For BRSKI with pledge in responder mode, the base system architecture | |||
| defined in BRSKI [RFC8995] is enhanced to facilitate the new use | defined in BRSKI [RFC8995] is enhanced to facilitate the new use | |||
| case. The pledge-responder-mode allows delegated bootstrapping using | cases. The pledge-responder-mode allows delegated bootstrapping | |||
| a registrar-agent instead of a direct connection between the pledge | using a registrar-agent instead of a direct connection between the | |||
| and the domain registrar. The communication model between registrar- | pledge and the domain registrar. The communication model between | |||
| agent and pledge in this document assumes that the pledge is acting | registrar-agent and pledge in this document assumes that the pledge | |||
| as server and responds to requests. | is acting as server and responds to requests. | |||
| Necessary enhancements to support authenticated self-contained | Necessary enhancements to support authenticated self-contained | |||
| objects for certificate enrollment are kept at a minimum to enable | objects for certificate enrollment are kept at a minimum to enable | |||
| reuse of already defined architecture elements and interactions. | reuse of already defined architecture elements and interactions. | |||
| For the authenticated self-contained objects used for the | For the authenticated self-contained objects used for the | |||
| certification request, BRSKI-PRM relies on the defined message | certification request, BRSKI-PRM relies on the defined message | |||
| wrapping mechanisms of the enrollment protocols stated in Section 4 | wrapping mechanisms of the enrollment protocols stated in Section 4 | |||
| above. | above. | |||
| The security used within the document for bootstrapping objects | The security used within the document for bootstrapping objects | |||
| produced or consumed by the pledge bases on JOSE. In constraint | produced or consumed by the pledge bases on JOSE [RFC7515]. In | |||
| environments it may provided based on COSE. | constraint environments it may provided based on COSE [RFC8152]. | |||
| An abstract overview of the BRSKI-PRM protocol can be found in | ||||
| [BRSKI-PRM-abstract]. | ||||
| 5.1. Pledge-responder-mode (PRM): Registrar-agent Communication with | 5.1. Pledge-responder-mode (PRM): Registrar-agent Communication with | |||
| Pledges | Pledges | |||
| To support mutual trust establishment of pledges, not directly | To support mutual trust establishment between the domain registrar | |||
| connected to the domain registrar, this document relies on the | and pledges not directly connected to the customer site/domain, this | |||
| exchange of authenticated self-contained objects (the voucher | document specifies the exchange of authenticated self-contained | |||
| request/response objects as known from BRSKI and the enrollment | objects (the voucher request/response objects as known from BRSKI and | |||
| request/response objects as introduced by BRSKI-PRM) with the help of | the enrollment request/response objects as introduced by BRSKI-PRM) | |||
| a registrar-agent. This allows independence from protection provided | with the help of a registrar-agent. This allows independence from | |||
| by the utilized transport protocol. | protection provided by the utilized transport protocol. | |||
| The registrar-agent may be an integrated functionality of a | The registrar-agent may be implemented as an integrated functionality | |||
| commissioning tool or be co-located with the registrar itself. This | of a commissioning tool or be co-located with the registrar itself. | |||
| leads to enhancements of the logical elements in the BRSKI | This leads to extensions of the logical components in the BRSKI | |||
| architecture as shown in Figure 1. The registrar-agent interacts | architecture as shown in Figure 1. The registrar-agent interacts | |||
| with the pledge to acquire and to supply the required data objects | with the pledge to transfer the required data objects for | |||
| for bootstrapping, which are also exchanged between the registrar- | bootstrapping, which are then also exchanged between the registrar- | |||
| agent and the domain registrar. Moreover, the addition of the | agent and the domain registrar. The addition of the registrar-agent | |||
| registrar-agent influences the sequences of the data exchange between | influences the sequences of the data exchange between the pledge and | |||
| the pledge and the domain registrar described in [RFC8995]. A | the domain registrar as described in [RFC8995]. A general goal for | |||
| general goal for the registrar-agent application is the reuse of | the registrar-agent implementation is the reuse of already defined | |||
| already defined endpoints of the domain registrar side. The | endpoints of the domain registrar. The already existing registrar | |||
| functionality of the already existing registrar endpoints may need | endpoints have been enhanced to provide distinct endpoints for | |||
| small enhancements to cope with the additional signatures. | providing objects with additional signatures for the enrollment | |||
| objects in Section 5.3. | ||||
| +------------------------+ | +------------------------+ | |||
| +--------------Drop Ship---------------| Vendor Service | | +--------------Drop Ship---------------| Vendor Service | | |||
| | +------------------------+ | | +------------------------+ | |||
| | | M anufacturer| | | | | M anufacturer| | | |||
| | | A uthorized |Ownership| | | | A uthorized |Ownership| | |||
| | | S igning |Tracker | | | | S igning |Tracker | | |||
| | | A uthority | | | | | A uthority | | | |||
| | +--------------+---------+ | | +--------------+---------+ | |||
| | ^ | | ^ | |||
| skipping to change at page 10, line 36 ¶ | skipping to change at page 11, line 36 ¶ | |||
| | | | | . +------------------+-----+ . | | | | | . +------------------+-----+ . | |||
| +-------+ +---------+ . | Key Infrastructure | . | +-------+ +---------+ . | Key Infrastructure | . | |||
| . | (e.g., PKI Certificate | . | . | (e.g., PKI Certificate | . | |||
| . | Authority) | . | . | Authority) | . | |||
| . +------------------------+ . | . +------------------------+ . | |||
| ....................................... | ....................................... | |||
| "Domain" components | "Domain" components | |||
| Figure 1: Architecture overview using registrar-agent | Figure 1: Architecture overview using registrar-agent | |||
| For authentication towards the domain registrar, the registrar-agent | For authentication to the domain registrar, the registrar-agent uses | |||
| uses its LDevID. The provisioning of the registrar-agent LDevID may | its LDevID(RegAgt). The provisioning of the registrar-agent LDevID | |||
| be done by a separate BRSKI run or other means in advance. It is | may be done by a separate BRSKI run or other means in advance. It is | |||
| recommended to use short lived registrar-agent LDevIDs in the range | recommended to use short lived registrar-agent LDevIDs in the range | |||
| of days or weeks. | of days or weeks as outlined in Section 9.3. | |||
| If a registrar detects a request originates from a registrar-agent it | ||||
| is able to switch the operational mode from BRSKI to BRSKI-PRM. This | ||||
| may be supported by a specific naming in the SAN (subject alternative | ||||
| name) component of the LDeID(RegAgt) certificate. Alternatively, the | ||||
| domain may feature an own issuing CA for registrar agent LDevID | ||||
| certificates. | ||||
| In addition, the domain registrar may authenticate the user operating | If a registrar detects a request that originates from a registrar- | |||
| the registrar-agent to perform additional authorization of a pledge | agent it is able to switch the operational mode from BRSKI to BRSKI- | |||
| bootstrapping action. Examples for such user level authentication | PRM. This may be supported by a specific naming in the SAN (subject | |||
| may be HTTP authentication or the usage of authorization tokens or | alternative name) component of the LDevID(RegAgt) certificate. | |||
| other. This is out of scope of this document. | Alternatively, the domain may feature an own issuing CA for | |||
| registrar-agent LDevID certificates. This allows the registrar to | ||||
| detect registrar-agents based on the issuing CA. | ||||
| The following list describes the components in a (customer) site | The following list describes the components in a (customer) site | |||
| domain: | domain: | |||
| * Pledge: The pledge is expected to respond with the necessary data | * Pledge: The pledge is expected to respond with the necessary data | |||
| objects for bootstrapping to the registrar-agent. The transport | objects for bootstrapping to the registrar-agent. The protocol | |||
| protocol used between the pledge and the registrar-agent is | used between the pledge and the registrar-agent is assumed to be | |||
| assumed to be HTTP in the context of this document. Other | HTTP in the context of this document. Other protocols may be used | |||
| transport protocols may be used like CoAP, Bluetooth, or NFC, but | like CoAP, Bluetooth, or NFC, but are out of scope of this | |||
| are out of scope of this document. A pledge acting as a server | document. A pledge acting as a server during bootstrapping leads | |||
| during bootstrapping leads to some differences to BRSKI: | to some differences to BRSKI: | |||
| - Discovery of the domain registrar by the pledge is not needed | - Discovery of the domain registrar by the pledge is not needed | |||
| as the pledge will be triggered by the registrar-agent. | as the pledge will be triggered by the registrar-agent. This | |||
| enables the registrar to verify that the pledge was contacted | ||||
| by an authorized registrar. In addition, it enables the MASA | ||||
| to provide an agent-proximity assertion. | ||||
| - Discovery of the pledge by the registrar-agent must be | - Discovery of the pledge by the registrar-agent must be | |||
| possible. | possible. | |||
| - As the registrar-agent must be able to request data objects for | - As the registrar-agent must be able to request data objects for | |||
| bootstrapping of the pledge, the pledge must offer | bootstrapping of the pledge, the pledge must offer | |||
| corresponding endpoints. | corresponding endpoints. | |||
| - The registrar-agent may provide additional data to the pledge, | - The registrar-agent may provide additional data to the pledge | |||
| in the context of the triggering request, to make itself | in the context of the triggering request, to make itself | |||
| visible to the domain registrar. | visible to the domain registrar. | |||
| - Order of exchanges in the call flow may be different as the | - Order of exchanges in the call flow may be different as the | |||
| registrar-agent collects both objects, pledge-voucher-request | registrar-agent collects both objects, pledge-voucher-request | |||
| objects and pledge-enrollment-request objects, at once and | objects and pledge-enrollment-request objects, at once and | |||
| provides them to the registrar. This approach may also be used | provides them to the registrar. This approach may also be used | |||
| to perform a bulk bootstrapping of several devices. | to perform a bulk bootstrapping of several devices. | |||
| - The data objects utilized for the data exchange between the | - The data objects utilized for the data exchange between the | |||
| pledge and the registrar are self-contained authenticated | pledge and the registrar are self-contained authenticated | |||
| objects (signature-wrapped objects). | objects (signature-wrapped objects). | |||
| * Registrar-agent: provides a communication path to exchange data | * Registrar-agent: provides a communication path to exchange data | |||
| objects between the pledge and the domain registrar. The | objects between the pledge and the domain registrar. The | |||
| registrar-agent facilitates situations, in which the domain | registrar-agent brokers in situations, in which the domain | |||
| registrar is not directly reachable by the pledge, either due to a | registrar is not directly reachable by the pledge, either due to a | |||
| different technology stack or due to missing connectivity. The | different technology stack or due to missing connectivity. The | |||
| registrar-agent triggers a pledge to create bootstrapping | registrar-agent triggers a pledge to create bootstrapping | |||
| information such as voucher-request objects and enrollment-request | artifacts such as voucher-request objects and enrollment-request | |||
| objects on one or multiple pledges at performs may perform a bulk | objects on one or multiple pledges and performs a (bulk) | |||
| bootstrapping based on the collected data. The registrar-agent is | bootstrapping based on the collected data. The registrar-agent is | |||
| expected to possess information of the domain registrar, either by | expected to possess information of the domain registrar (i.e., | |||
| configuration or by using the discovery mechanism defined in | LDevID(Reg) certificate, LDevID(CA) certificate, address), either | |||
| by configuration or by using the discovery mechanism defined in | ||||
| [RFC8995]. There is no trust assumption between the pledge and | [RFC8995]. There is no trust assumption between the pledge and | |||
| the registrar-agent as only authenticated self-contained objects | the registrar-agent as only authenticated self-contained objects | |||
| are applied, which are transported via the registrar-agent and | are used, which are transported via the registrar-agent and | |||
| provided either by the pledge or the registrar. The trust | provided either by the pledge or the registrar. The trust | |||
| assumption between the registrar-agent and the registrar bases on | assumption between the registrar-agent and the registrar is based | |||
| the LDevID of the registrar-agent, provided by the PKI responsible | on the LDevID of the registrar-agent, provided by the PKI | |||
| for the domain. This allows the registrar-agent to authenticate | responsible for the domain. | |||
| towards the registrar, e.g., in a TLS handshake. Based on this, | This allows the registrar-agent to authenticate towards the | |||
| the registrar is able to distinguish a pledge from a registrar- | registrar, e.g., in a TLS handshake. Based on this, the registrar | |||
| agent during the session establishment. | is able to distinguish a pledge from a registrar-agent during the | |||
| session establishment and also to verify that the registrar-agent | ||||
| is authorized to perform the bootstrapping of the distinct pledge. | ||||
| * Join Proxy: same functionality as described in [RFC8995]. Note | * Join Proxy: same functionality as described in [RFC8995]. Note | |||
| that it may be used by the registrar-agent instead of the pledge | that it may be used by the registrar-agent instead of the pledge | |||
| to find the registrar, if not configured. | to find the registrar, if not configured. | |||
| * Domain Registrar: In general the domain registrar fulfills the | * Domain Registrar: In general the domain registrar fulfills the | |||
| same functionality regarding the bootstrapping of the pledge in a | same functionality regarding the bootstrapping of the pledge in a | |||
| (customer) site domain by facilitating the communication of the | (customer) site domain by facilitating the communication of the | |||
| pledge with the MASA service and the domain PKI service. In | pledge with the MASA service and the domain PKI service. In | |||
| contrast to [RFC8995], the domain registrar does not interact with | contrast to [RFC8995], the domain registrar does not interact with | |||
| a pledge directly but through the registrar-agent. The registrar | a pledge directly but through the registrar-agent. The registrar | |||
| detects if the bootstrapping is performed by the pledge directly | detects if the bootstrapping is performed by the pledge directly | |||
| or by the registrar-agent. The manufacturer provided components/ | or by the registrar-agent. The manufacturer provided components/ | |||
| services (MASA and Ownership tracker) are used as defined in | services (MASA and Ownership tracker) are used as defined in | |||
| [RFC8995]. For issuing a voucher, the MASA may perform additional | [RFC8995]. For issuing a voucher, the MASA may perform additional | |||
| checks on voucher-request objects, to issue a voucher indicating | checks on voucher-request objects, to issue a voucher indicating | |||
| agent-proximity instead of (registrar-)proximity. | agent-proximity instead of (registrar-)proximity. | |||
| 5.1.1. Agent-Proximity | 5.2. Agent-Proximity Assertion | |||
| "Agent-proximity" is a weaker assertion then "proximity". It is | "Agent-proximity" is a weaker assertion then "proximity". It is | |||
| defined as additional assertion type in | defined as additional assertion type in [I-D.ietf-anima-rfc8366bis] | |||
| [I-D.richardson-anima-rfc8366bis] In case of "agent-proximity" it is | "agent-proximity" is a statement, that the proximity registrar | |||
| a statement, that the proximity-registrar-certificate was provided | certificate was provided via the registrar-agent and not directly to | |||
| via the registrar-agent and not directly to the pledge. This can be | the pledge as defined in Section 5.5. This can be verified by the | |||
| verified by the registrar and also by the MASA during the voucher- | registrar and also by the MASA during the voucher-request processing. | |||
| request processing. Note that at the time of creating the voucher- | Note that at the time of creating the voucher-request, the pledge | |||
| request, the pledge cannot verify the registrar's LDevID(Reg) EE | cannot verify the registrar's LDevID(Reg) EE certificate and has no | |||
| certificate and has no proof-of-possession of the corresponding | proof-of-possession of the corresponding private key for the | |||
| private key for the certificate. | certificate. The pledge accepts the LDevID(Reg) provisionally until | |||
| it receives the voucher as described in Section 5.5.3. | ||||
| Trust handover to the domain is established via the "pinned-domain- | Trust handover to the domain is established via the "pinned-domain- | |||
| certificate" in the voucher. | certificate" in the voucher. | |||
| In contrast, "proximity" provides a statement, that the pledge was in | In contrast, "proximity" provides a statement, that the pledge was in | |||
| direct contact with the registrar and was able to verify proof-of- | direct contact with the registrar and was able to verify proof-of- | |||
| possession of the private key in the context of the TLS handshake. | possession of the private key in the context of the TLS handshake. | |||
| The provisionally accepted LDevID(Reg) EE certificate can be verified | The provisionally accepted LDevID(Reg) EE certificate can be verified | |||
| after the voucher has been processed by the pledge through a | after the voucher has been processed by the pledge through a | |||
| verification of an additional signature of the returned voucher by | verification of an additional signature of the returned voucher by | |||
| the registrar if contained (optional feature). | the registrar if contained (optional feature). | |||
| 5.1.2. Behavior of Pledge in Pledge-Responder-Mode | 5.3. Behavior of Pledge in Pledge-Responder-Mode | |||
| In contrast to BRSKI the pledge acts as a server component. It is | In contrast to BRSKI the pledge acts as server. It is triggered by | |||
| triggered by the registrar-agent for the generation of pledge- | the registrar-agent for the generation of the pledge-voucher-request | |||
| voucher-request and pledge-enrollment-request objects as well as for | and pledge-enrollment-request objects as well as for the processing | |||
| the processing of the response objects and the generation of status | of the response objects and the generation of status information. | |||
| information. Due to the use of the registrar-agent, the interaction | Due to the use of the registrar-agent, the interaction with the | |||
| with the domain registrar is changed as shown in Figure 4. To enable | domain registrar is changed as shown in Figure 4. To enable | |||
| interaction with the registrar-agent, the pledge provides endpoints | interaction with the registrar-agent, the pledge provides endpoints | |||
| using the BRSKI interface based on the "/.well-known/brski" URI tree. | using the BRSKI defined endpoints based on the "/.well-known/brski" | |||
| URI tree. | ||||
| The following endpoints are defined for the _pledge_ in this | The following endpoints are defined for the _pledge_ in this | |||
| document. The URI path begins with "http://www.example.com/.well- | document. The URI path begins with "http://www.example.com/.well- | |||
| known/brski" followed by a path-suffix that indicates the intended | known/brski" followed by a path-suffix that indicates the intended | |||
| operation. | operation. | |||
| Operations and their corresponding URIs: | Operations and their corresponding URIs: | |||
| +------------------------+----------------------------+---------+ | +------------------------+----------------------------+---------+ | |||
| | Operation |Operation path | Details | | | Operation |Operation path | Details | | |||
| +========================+============================+=========+ | +========================+============================+=========+ | |||
| | Trigger pledge-voucher-| /pledge-voucher-request | Section | | | Trigger pledge-voucher-| /pledge-voucher-request | Section | | |||
| | request creation | | 5.1.4.1 | | | request creation | | 5.5.1 | | |||
| | Returns | | | | | Returns | | | | |||
| | pledge-voucher-request | | | | | pledge-voucher-request | | | | |||
| ++------------------------+----------------------------+---------+ | ++------------------------+----------------------------+---------+ | |||
| | Trigger pledge- | /pledge-enrollment-request | Section | | | Trigger pledge- | /pledge-enrollment-request | Section | | |||
| | enrollment-request | | 5.1.4.1 | | | enrollment-request | | 5.5.1 | | |||
| | Returns pledge- | | | | | Returns pledge- | | | | |||
| | enrollment-request | | | | | enrollment-request | | | | |||
| +------------------------+----------------------------+---------+ | +------------------------+----------------------------+---------+ | |||
| | Provide voucher to | /pledge-voucher | Section | | | Provide voucher to | /pledge-voucher | Section | | |||
| | pledge | | 5.1.4.3 | | | pledge | | 5.5.3 | | |||
| | Returns | | | | | Returns | | | | |||
| | pledge-voucher-status | | | | | pledge-voucher-status | | | | |||
| +------------------------+----------------------------+---------+ | +------------------------+----------------------------+---------+ | |||
| | Provide enrollment | /pledge-enrollment | Section | | | Provide enrollment | /pledge-enrollment | Section | | |||
| | response to pledge | | 5.1.4.3 | | | response to pledge | | 5.5.3 | | |||
| | Returns pledge- | | | | | Returns pledge- | | | | |||
| | enrollment-status | | | | | enrollment-status | | | | |||
| +------------------------+----------------------------+---------+ | +------------------------+----------------------------+---------+ | |||
| | Provide CA certs to | /pledge-CACerts | | | | Provide CA certs to | /pledge-CACerts | | | |||
| | pledge (OPTIONAL) | | | | | pledge (OPTIONAL) | | | | |||
| +------------------------+----------------------------+---------+ | +------------------------+----------------------------+---------+ | |||
| Figure 2: Endpoints on the pledge | Figure 2: Endpoints on the pledge | |||
| 5.1.3. Behavior of Registrar-Agent | 5.4. Behavior of Registrar-Agent | |||
| The registrar-agent is a new component in the BRSKI context. It | The registrar-agent is a new component in the BRSKI context. It | |||
| provides connectivity between the pledge and the domain registrar and | provides connectivity between the pledge and the domain registrar and | |||
| reuses the endpoints of the domain registrar side already specified | reuses the endpoints of the domain registrar side already specified | |||
| in [RFC8995]. It facilitates the exchange of data objects between | in [RFC8995]. It facilitates the exchange of data objects between | |||
| the pledge and the domain registrar, which are the voucher request/ | the pledge and the domain registrar, which are the voucher request/ | |||
| response objects, the enrollment request/response objects, as well as | response objects, the enrollment request/response objects, as well as | |||
| related status objects. For the communication the registrar-agent | related status objects. For the communication with the pledge the | |||
| utilizes communication endpoints provided by the pledge. The | registrar-agent utilizes communication endpoints provided by the | |||
| transport in this specification is based on HTTP but may also be done | pledge. The transport in this specification is based on HTTP but may | |||
| using other transport mechanisms. This new component changes the | also be done using other transport mechanisms. This new component | |||
| general interaction between the pledge and the domain registrar as | changes the general interaction between the pledge and the domain | |||
| shown in Figure 10. | registrar as shown in Figure 1. | |||
| The registrar-agent is expected to already possess an LDevID(RegAgt) | The registrar-agent is expected to already possess an LDevID(RegAgt) | |||
| to authenticate towards the domain registrar. The registrar-agent | to authenticate to the domain registrar. The registrar-agent will | |||
| will use this LDevID(RegAgt) when establishing the TLS session with | use this LDevID(RegAgt) when establishing the TLS session with the | |||
| the domain registrar in the context of for TLS client-side | domain registrar for TLS client authentication. The LDevID(RegAgt) | |||
| authentication. The LDevID(RegAgt) EE certificate MUST include a | EE certificate MUST include a SubjectKeyIdentifier (SKID), which is | |||
| SubjectKeyIdentifier (SKID), which is used as reference in the | used as reference in the context of an agent-signed-data object as | |||
| context of an agent-signed-data object as defined in Section 5.1.4.1. | defined in Section 5.5.1. Note that this is an additional | |||
| Note that this is an additional requirement for issuing the | requirement for issuing the certificate, as [IEEE-802.1AR] only | |||
| certificate, as [IEEE-802.1AR] only requires the SKID to be included | requires the SKID to be included for intermediate CA certificates. | |||
| for intermediate CA certificates. In BRSKI-PRM, the SKID is used in | In BRSKI-PRM, the SKID is used in favor of a certificate fingerprint | |||
| favor of a certificate fingerprint to avoid additional computations. | to avoid additional computations. | |||
| Using an LDevID for TLS client-side authentication is a deviation | Using an LDevID for TLS client authentication is a deviation from | |||
| from [RFC8995], in which the pledge's IDevID credential is used to | [RFC8995], in which the pledge's IDevID credential is used to perform | |||
| perform TLS client authentication. The use of the LDevID(RegAgt) | TLS client authentication. The use of the LDevID(RegAgt) allows the | |||
| allows the domain registrar to distinguish, if bootstrapping is | domain registrar to distinguish, if bootstrapping is initiated from a | |||
| initiated from a pledge or from a registrar-agent and adopt the | pledge or from a registrar-agent and adopt the internal handling | |||
| internal handling accordingly. As BRSKI-PRM uses authenticated self- | accordingly. As BRSKI-PRM uses authenticated self-contained data | |||
| contained data objects between the pledge and the domain registrar, | objects between the pledge and the domain registrar, the binding of | |||
| the binding of the pledge identity to the request object is provided | the pledge identity to the request object is provided by the data | |||
| by the data object signature employing the pledge's IDevID. The | object signature employing the pledge's IDevID. The objects | |||
| objects exchanged between the pledge and the domain registrar used in | exchanged between the pledge and the domain registrar used in the | |||
| the context of this specifications are JOSE objects | context of this specifications are JOSE objects | |||
| In addition to the LDevID(RegAgt), the registrar-agent is provided | In addition to the LDevID(RegAgt), the registrar-agent is provided | |||
| with the product-serial-numbers of the pledges to be bootstrapped. | with the product-serial-numbers of the pledges to be bootstrapped. | |||
| This is necessary to allow the discovery of pledges by the registrar- | This is necessary to allow the discovery of pledges by the registrar- | |||
| agent using mDNS. The list may be provided by administrative means | agent using mDNS. The list may be provided by administrative means | |||
| or the registrar agent may get the information via an interaction | or the registrar agent may get the information via an interaction | |||
| with the pledge, like scanning of product-serial-number information | with the pledge, like scanning of product-serial-number information | |||
| using a QR code or similar. | using a QR code or similar. | |||
| According to [RFC8995] section 5.3, the domain registrar performs the | According to [RFC8995] section 5.3, the domain registrar performs the | |||
| skipping to change at page 16, line 5 ¶ | skipping to change at page 17, line 5 ¶ | |||
| The following information must therefore be available at the | The following information must therefore be available at the | |||
| registrar-agent: | registrar-agent: | |||
| * LDevID(RegAgt): own operational key pair. | * LDevID(RegAgt): own operational key pair. | |||
| * LDevID(reg) certificate: certificate of the domain registrar. | * LDevID(reg) certificate: certificate of the domain registrar. | |||
| * Serial-number(s): product-serial-number(s) of pledge(s) to be | * Serial-number(s): product-serial-number(s) of pledge(s) to be | |||
| bootstrapped. | bootstrapped. | |||
| 5.1.3.1. Discovery of Registrar by Registrar-Agent | 5.4.1. Discovery of Registrar by Registrar-Agent | |||
| The discovery of the domain registrar may be done as specified in | The discovery of the domain registrar may be done as specified in | |||
| [RFC8995] with the deviation that it is done between the registrar- | [RFC8995] with the deviation that it is done between the registrar- | |||
| agent and the domain registrar. Alternatively, the registrar-agent | agent and the domain registrar. Alternatively, the registrar-agent | |||
| may be configured with the address of the domain registrar and the | may be configured with the address of the domain registrar and the | |||
| certificate of the domain registrar. | certificate of the domain registrar. | |||
| 5.1.3.2. Discovery of Pledge by Registrar-Agent | 5.4.2. Discovery of Pledge by Registrar-Agent | |||
| The discovery of the pledge by registrar-agent should be done by | The discovery of the pledge by registrar-agent should be done by | |||
| using DNS-based Service Discovery [RFC6763] over Multicast DNS | using DNS-based Service Discovery [RFC6763] over Multicast DNS | |||
| [RFC6762] to discover the pledge at "product-serial-number.brski- | [RFC6762] to discover the pledge at "product-serial-number.brski- | |||
| pledge._tcp.local." The pledge constructs a local host name based on | pledge._tcp.local." The pledge constructs a local host name based on | |||
| device local information (product-serial-number), which results in | device local information (product-serial-number), which results in | |||
| "product-serial-number.brski-pledge._tcp.local." It can then be | "product-serial-number.brski-pledge._tcp.local." It can then be | |||
| discovered by the registrar-agent via mDNS. Note that other | discovered by the registrar-agent via mDNS. Note that other | |||
| mechanisms for discovery may be used. | mechanisms for discovery may be used. | |||
| The registrar-agent is able to build the same information based on | The registrar-agent is able to build the same information based on | |||
| the provided list of product-serial-number. | the provided list of product-serial-number. | |||
| 5.1.4. Bootstrapping Objects and Corresponding Exchanges | 5.5. Bootstrapping Objects and Corresponding Exchanges | |||
| The interaction of the pledge with the registrar-agent may be | The interaction of the pledge with the registrar-agent may be | |||
| accomplished using different transport means (protocols and or | accomplished using different transport means (protocols and or | |||
| network technologies). For this document the usage of HTTP is | network technologies). For this document the usage of HTTP is | |||
| targeted as in BRSKI. Alternatives may be CoAP, Bluetooth Low Energy | targeted as in BRSKI. Alternatives may be CoAP, Bluetooth Low Energy | |||
| (BLE), or Nearfield Communication (NFC). This requires independence | (BLE), or Nearfield Communication (NFC). This requires independence | |||
| of the exchanged data objects between the pledge and the registrar | of the exchanged data objects between the pledge and the registrar | |||
| from transport security. Therefore, authenticated self-contained | from transport security. Therefore, authenticated self-contained | |||
| objects (here: signature-wrapped objects) are applied in the data | objects (here: signature-wrapped objects) are applied in the data | |||
| exchange between the pledge and the registrar. | exchange between the pledge and the registrar. | |||
| skipping to change at page 17, line 7 ¶ | skipping to change at page 18, line 7 ¶ | |||
| establishment with the domain registrar. In addition, the registrar- | establishment with the domain registrar. In addition, the registrar- | |||
| agent provides agent-signed-data containing the product-serial-number | agent provides agent-signed-data containing the product-serial-number | |||
| in the body, signed with the LDevID(RegAgt). This enables the | in the body, signed with the LDevID(RegAgt). This enables the | |||
| registrar to verify and log, which registrar-agent was in contact | registrar to verify and log, which registrar-agent was in contact | |||
| with the pledge, when verifying the pledge-voucher-request. | with the pledge, when verifying the pledge-voucher-request. | |||
| Optionally the registrar-agent may provide its LDevID(RegAgt) EE | Optionally the registrar-agent may provide its LDevID(RegAgt) EE | |||
| certificate (and optionally also the issuing CA certificate) to the | certificate (and optionally also the issuing CA certificate) to the | |||
| pledge to be used in the "agent-sign-cert" component of the pledge- | pledge to be used in the "agent-sign-cert" component of the pledge- | |||
| voucher-request. If contained, the LDevID(RegAgt) EE certificate | voucher-request. If contained, the LDevID(RegAgt) EE certificate | |||
| MUST be the first certificate in the array. Note, this may be | MUST be the first certificate in the array. Note, this may be | |||
| omitted in constraint environments to safe bandwidth between the | omitted in constraint environments to save bandwidth between the | |||
| registrar-agent and the pledge. If not contained, the registrar- | registrar-agent and the pledge. If not contained, the registrar- | |||
| agent MUST fetch the LDevID(RegAgt) EE certificate based on the | agent MUST fetch the LDevID(RegAgt) EE certificate based on the | |||
| SubjectKeyIdentifier (SKID) in the header of the agent-signed-data of | SubjectKeyIdentifier (SKID) in the header of the agent-signed-data of | |||
| the pledge-voucher-request. The registrar includes the | the pledge-voucher-request. The registrar includes the | |||
| LDevID(RegAgt) EE certificate information into the registrar-voucher- | LDevID(RegAgt) EE certificate information into the registrar-voucher- | |||
| request if the pledge-voucher-requests requests the assertion of | request if the pledge-voucher-requests contains the assertion of | |||
| "agent-proximity". | "agent-proximity". | |||
| The MASA in turn verifies the LDevID(Reg) EE certificate is included | The MASA in turn verifies the LDevID(Reg) EE certificate is included | |||
| in the pledge-voucher-request (prior-signed-voucher-request) in the | in the pledge-voucher-request (prior-signed-voucher-request) in the | |||
| "agent-provided-proximity-registrar-certificate" leaf and may assert | "agent-provided-proximity-registrar-certificate" leaf and may assert | |||
| in the voucher "verified" or "logged" instead of "proximity", as | in the voucher "verified" or "logged" instead of "proximity", as | |||
| there is no direct connection between the pledge and the registrar. | there is no direct connection between the pledge and the registrar. | |||
| If the LDevID(RegAgt) EE certificate information is contained in the | In addition, the MASA can provide the assertion "agent-proximity" as | |||
| "agent-sign-cert" component of the registrar-voucher-request, the | following. If the LDevID(RegAgt) EE certificate information is | |||
| MASA can verify the signature of the agent-signed-data contained in | contained in the "agent-sign-cert" component of the registrar- | |||
| the prior-signed-voucher-request. If both can be verified | voucher-request, the MASA can verify the signature of the agent- | |||
| successfully, the MASA can assert "agent-proximity" in the voucher. | signed-data contained in the prior-signed-voucher-request. If both | |||
| Otherwise, it may assert "verified" or "logged". The voucher can | can be verified successfully, the MASA can assert "agent-proximity" | |||
| then be supplied via the registrar to the registrar-agent. | in the voucher. Otherwise, it may assert "verified" or "logged". | |||
| The voucher can then be supplied via the registrar to the registrar- | ||||
| agent. | ||||
| Figure 3 provides an overview of the exchanges detailed in the | Figure 3 provides an overview of the exchanges detailed in the | |||
| following sub sections. | following sub sections. | |||
| +--------+ +-----------+ +-----------+ +--------+ +---------+ | +--------+ +-----------+ +-----------+ +--------+ +---------+ | |||
| | Pledge | | Registrar | | Domain | | Domain | | Vendor | | | Pledge | | Registrar | | Domain | | Domain | | Vendor | | |||
| | | | Agent | | Registrar | | CA | | Service | | | | | Agent | | Registrar | | CA | | Service | | |||
| | | | (RegAgt) | | (JRC) | | | | (MASA) | | | | | (RegAgt) | | (JRC) | | | | (MASA) | | |||
| +--------+ +-----------+ +-----------+ +--------+ +---------+ | +--------+ +-----------+ +-----------+ +--------+ +---------+ | |||
| | | | | Internet | | | | | | Internet | | |||
| skipping to change at page 18, line 5 ¶ | skipping to change at page 19, line 7 ¶ | |||
| [trigger pledge-voucher-request and | [trigger pledge-voucher-request and | |||
| pledge-enrollment-request generation] | pledge-enrollment-request generation] | |||
| |<- vTrigger --| | | | | |<- vTrigger --| | | | | |||
| |-Voucher-Req->| | | | | |-Voucher-Req->| | | | | |||
| | | | | | | | | | | | | |||
| |<- eTrigger --| | | | | |<- eTrigger --| | | | | |||
| |- Enroll-Req->| | | | | |- Enroll-Req->| | | | | |||
| ~ ~ ~ ~ ~ | ~ ~ ~ ~ ~ | |||
| [provide pledge-voucher-request to infrastructure] | [provide pledge-voucher-request to infrastructure] | |||
| | |<------ TLS ----->| | | | | |<------ TLS ----->| | | | |||
| | | [Reg-Agt auth+authz?] | | | | | [Reg-Agt authenticated | | | |||
| | | and authorized?] | | | ||||
| | |-- Voucher-Req -->| | | | | |-- Voucher-Req -->| | | | |||
| | | [Reg-Agt authorized?] | | | | | [Reg-Agt authorized?] | | | |||
| | | [accept device?] | | | | | [accept device?] | | | |||
| | | [contact vendor] | | | | | [contact vendor] | | | |||
| | | |------- Voucher-Req ------>| | | | |------- Voucher-Req ------>| | |||
| | | | [extract DomainID] | | | | [extract DomainID] | |||
| | | | [update audit log] | | | | [update audit log] | |||
| | | |<-------- Voucher ---------| | | | |<-------- Voucher ---------| | |||
| | |<---- Voucher ----| | | | | |<---- Voucher ----| | | | |||
| | | | | | | | | | | | | |||
| skipping to change at page 18, line 29 ¶ | skipping to change at page 19, line 32 ¶ | |||
| | | |<-Certificate-| | | | | |<-Certificate-| | | |||
| | |<-- Enroll-Resp --| | | | | |<-- Enroll-Resp --| | | | |||
| ~ ~ ~ ~ ~ | ~ ~ ~ ~ ~ | |||
| [provide voucher and certificate | [provide voucher and certificate | |||
| to pledge and collect status info] | to pledge and collect status info] | |||
| |<-- Voucher --| | | | | |<-- Voucher --| | | | | |||
| |-- vStatus -->| | | | | |-- vStatus -->| | | | | |||
| |<-Enroll-Resp-| | | | | |<-Enroll-Resp-| | | | | |||
| |-- eStatus -->| | | | | |-- eStatus -->| | | | | |||
| ~ ~ ~ ~ ~ | ~ ~ ~ ~ ~ | |||
| [provide voucher-status and enrollment status to registrar] | [provide voucher status and enroll status to registrar] | |||
| | |<------ TLS ----->| | | | | |<------ TLS ----->| | | | |||
| | |---- vStatus --->| | | | | |---- vStatus --->| | | | |||
| | | |-- req. device audit log ->| | | | |-- req. device audit log ->| | |||
| | | |<---- device audit log ----| | | | |<---- device audit log ----| | |||
| | | [verify audit log] | | | [verify audit log] | |||
| | | | | | | | | | | | | |||
| | |---- eStatus --->| | | | | |---- eStatus --->| | | | |||
| | | | | | | | | | | | | |||
| Figure 3: Overview pledge-responder-mode exchanges | Figure 3: Overview pledge-responder-mode exchanges | |||
| The following sub sections split the interactions between the | The following sub sections split the interactions between the | |||
| different components into: | different components into: | |||
| * Request objects acquisition targets exchanges and objects between | * Section 5.5.1 describes objects exchanged between the registrar- | |||
| the registrar-agent and the pledge. | agent and the pledge. | |||
| * Request handling targets exchanges and objects between the | * Section 5.5.2 describes objects exchanged between the registrar- | |||
| registrar-agent and the registrar and also the interaction of the | agent and the registrar and also the interaction of the registrar | |||
| registrar with the MASA and the domain CA. | with the MASA and the domain CA. | |||
| * Response object supply targets the exchanges and objects between | * Section 5.5.3 describes objects exchanged between the registrar- | |||
| the registrar-agent and the pledge including the status objects. | agent and the pledge including the status objects. | |||
| * Status handling addresses the exchanges between the registrar- | * Section 5.5.4 describes the status handling addresses the | |||
| agent and the registrar. | exchanges between the registrar-agent and the registrar. | |||
| 5.1.4.1. Request Objects Acquisition by Registrar-Agent from Pledge | 5.5.1. Request Objects Acquisition by Registrar-Agent from Pledge | |||
| The following description assumes that the registrar-agent already | The following description assumes that the registrar-agent already | |||
| discovered the pledge. This may be done as described in | discovered the pledge. This may be done as described in | |||
| Section 5.1.3.2 based on mDNS. | Section 5.4.2 based on mDNS. | |||
| The focus is on the exchange of signature-wrapped objects using | The focus is on the exchange of signature-wrapped objects using | |||
| endpoints defined for the pledge in Section 5.1.2. | endpoints defined for the pledge in Section 5.3. | |||
| Preconditions: | Preconditions: | |||
| * Pledge: possesses IDevID | * Pledge: possesses IDevID | |||
| * Registrar-agent: possesses IDevID CA certificate and an own | * Registrar-agent: possesses/trusts IDevID CA certificate and an own | |||
| LDevID(RegAgt) EE credential for the registrar domain. In | LDevID(RegAgt) EE credential for the registrar domain. In | |||
| addition, the registrar-agent can be configured with the product- | addition, the registrar-agent MAY be configured with the product- | |||
| serial-number(s) of the pledge(s) to be bootstrapped. Note that | serial-number(s) of the pledge(s) to be bootstrapped. Note that | |||
| the product-serial-number may have been used during the pledge | the product-serial-number may have been used during the pledge | |||
| discovery already. | discovery already. | |||
| * Registrar: possesses IDevID CA certificate and an own LDevID(Reg) | * Registrar: possesses/trusts IDevID CA certificate and an own | |||
| credential. | LDevID(Reg) credential. | |||
| * MASA: possesses own credentials (voucher signing key, TLS server | * MASA: possesses own credentials (voucher signing key, TLS server | |||
| certificate) as well as IDevID CA certificate of pledge vendor / | certificate) as well as IDevID CA certificate of pledge vendor / | |||
| manufacturer and site-specific LDevID CA certificate. | manufacturer and site-specific LDevID CA certificate. | |||
| +--------+ +-----------+ | +--------+ +-----------+ | |||
| | Pledge | | Registrar | | | Pledge | | Registrar | | |||
| | | | Agent | | | | | Agent | | |||
| | | | (RegAgt) | | | | | (RegAgt) | | |||
| +--------+ +-----------+ | +--------+ +-----------+ | |||
| skipping to change at page 22, line 25 ¶ | skipping to change at page 23, line 25 ¶ | |||
| "kid": "base64encodedvalue==" | "kid": "base64encodedvalue==" | |||
| }, | }, | |||
| "signature": "base64encodedvalue==" | "signature": "base64encodedvalue==" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| Figure 6: Representation of agent-signed-data | Figure 6: Representation of agent-signed-data | |||
| Upon receiving the voucher-request trigger, the pledge SHOULD | Upon receiving the voucher-request trigger, the pledge SHALL | |||
| construct the body of the pledge-voucher-request object as defined in | construct the body of the pledge-voucher-request object as defined in | |||
| [RFC8995]. It will contain additional information provided by the | [RFC8995]. It will contain additional information provided by the | |||
| registrar-agent as specified in the following. This object becomes a | registrar-agent as specified in the following. This object becomes a | |||
| JSON-in-JWS object as defined in [I-D.ietf-anima-jws-voucher]. If | JSON-in-JWS object as defined in [I-D.ietf-anima-jws-voucher]. If | |||
| the pledge is unable to construct the pledge-voucher-request it | the pledge is unable to construct the pledge-voucher-request it | |||
| SHOULD respond with HTTP 406 error code to the registrar-agent to | SHOULD respond with HTTP 406 error code to the registrar-agent to | |||
| indicate that it is not able to create the pledge-voucher-request. | indicate that it is not able to create the pledge-voucher-request. | |||
| The header of the pledge-voucher-request SHALL contain the following | The header of the pledge-voucher-request SHALL contain the following | |||
| parameter as defined in [RFC7515]: | parameters as defined in [RFC7515]: | |||
| * alg: algorithm used for creating the object signature. | * alg: algorithm used for creating the object signature. | |||
| * x5c: contains the base64-encoded pledge IDevID certificate. It | * x5c: contains the base64-encoded pledge IDevID certificate. It | |||
| may optionally contain the certificate chain for this certificate. | may optionally contain the certificate chain for this certificate. | |||
| The payload of the pledge-voucher-request (PVR) object MUST contain | The payload of the pledge-voucher-request (PVR) object MUST contain | |||
| the following parameter as part of the ietf-voucher-request- | the following parameters as part of the ietf-voucher-request- | |||
| prm:voucher as defined in [RFC8995]: | prm:voucher as defined in [RFC8995]: | |||
| * created-on: contains the current date and time in yang:date-and- | * created-on: SHALL contain the current date and time in yang:date- | |||
| time format. | and-time format. | |||
| * nonce: contains a cryptographically strong random or pseudo-random | * nonce: SHALL contain a cryptographically strong random or pseudo- | |||
| number. | random number. | |||
| * serial-number: contains the pledge product-serial-number. | * serial-number: SHALL contain the pledge product-serial-number as | |||
| X520SerialNumber. | ||||
| * assertion: contains the requested voucher assertion. | * assertion: SHALL contain the requested voucher assertion "agent- | |||
| proximity". | ||||
| The ietf-voucher-request:voucher is enhanced with additional | The ietf-voucher-request:voucher is enhanced with additional | |||
| parameters: | parameters: | |||
| * agent-provided-proximity-registrar-cert: MUST be included and | * agent-provided-proximity-registrar-cert: MUST be included and | |||
| contains the base64-encoded LDevID(Reg) EE certificate (provided | contains the base64-encoded LDevID(Reg) EE certificate (provided | |||
| as trigger parameter by the registrar-agent). | as trigger parameter by the registrar-agent). | |||
| * agent-signed-data: MUST contain the base64-encoded agent-signed- | * agent-signed-data: MUST contain the base64-encoded agent-signed- | |||
| data (as defined in Figure 6) and provided as trigger parameter. | data (as defined in Figure 6) and provided as trigger parameter. | |||
| skipping to change at page 24, line 35 ¶ | skipping to change at page 25, line 35 ¶ | |||
| }, | }, | |||
| "signature": "base64encodedvalue==" | "signature": "base64encodedvalue==" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| Figure 7: Representation of pledge-voucher-request | Figure 7: Representation of pledge-voucher-request | |||
| The pledge-voucher-request Content-Type is defined in | The pledge-voucher-request Content-Type is defined in | |||
| [I-D.ietf-anima-jws-voucher] as: | [I-D.ietf-anima-jws-voucher] as application/voucher-jws+json. | |||
| application/voucher-jws+json | ||||
| The pledge SHOULD include this Content-Type header field indicating | The pledge SHOULD include this Content-Type header field indicating | |||
| the included media type for the voucher response. Note that this is | the included media type for the voucher response. Note that this is | |||
| also an indication regarding the acceptable format of the voucher | also an indication regarding the acceptable format of the voucher | |||
| response. This format is included by the registrar as described in | response. This format is included by the registrar as described in | |||
| Section 5.1.4.2. | Section 5.5.2. | |||
| Once the registrar-agent has received the pledge-voucher-request it | Once the registrar-agent has received the pledge-voucher-request it | |||
| can trigger the pledge to generate an enrollment-request object. As | can trigger the pledge to generate an enrollment-request object. As | |||
| in BRSKI the enrollment request object is a PKCS#10, but additionally | in BRSKI the enrollment request object is a PKCS#10, but additionally | |||
| signed using the pledge's IDevID. Note, as the initial enrollment | signed using the pledge's IDevID. Note, as the initial enrollment | |||
| aims to request a generic certificate, no certificate attributes are | aims to request a generic certificate, no certificate attributes are | |||
| provided to the pledge. | provided to the pledge. | |||
| Triggering the pledge to create the enrollment-request is done using | Triggering the pledge to create the enrollment-request is done using | |||
| HTTP POST on the defined pledge endpoint "/.well-known/brski/pledge- | HTTP POST on the defined pledge endpoint "/.well-known/brski/pledge- | |||
| skipping to change at page 26, line 8 ¶ | skipping to change at page 26, line 51 ¶ | |||
| credential to provide proof-of-identity bound to the PKCS#10 as | credential to provide proof-of-identity bound to the PKCS#10 as | |||
| described below. | described below. | |||
| If the pledge is unable to construct the enrollment-request it SHOULD | If the pledge is unable to construct the enrollment-request it SHOULD | |||
| respond with HTTP 406 error code to the registrar-agent to indicate | respond with HTTP 406 error code to the registrar-agent to indicate | |||
| that it is not able to create the enrollment-request. | that it is not able to create the enrollment-request. | |||
| A successful enrollment will result in a generic LDevID certificate | A successful enrollment will result in a generic LDevID certificate | |||
| for the pledge in the new domain, which can be used to request | for the pledge in the new domain, which can be used to request | |||
| further (application specific) LDevID certificates if necessary for | further (application specific) LDevID certificates if necessary for | |||
| its operation. The registrar-agent may use the endpoints specified | its operation. The registrar-agent SHALL use the endpoints specified | |||
| in this document. | in this document. | |||
| [I-D.ietf-netconf-sztp-csr] considers PKCS#10 but also CMP and CMC as | [I-D.ietf-netconf-sztp-csr] considers PKCS#10 but also CMP and CMC as | |||
| certification request format. Note that the wrapping signature is | certification request format. Note that the wrapping signature is | |||
| only necessary for plain PKCS#10 as other request formats like CMP | only necessary for plain PKCS#10 as other request formats like CMP | |||
| and CMS support the signature wrapping as part of their own | and CMS support the signature wrapping as part of their own | |||
| certificate request format. | certificate request format. | |||
| The registrar-agent enrollment-request Content-Type header for a | The registrar-agent enrollment-request Content-Type header for a | |||
| wrapped PKCS#10 is: application/jose | wrapped PKCS#10 is: application/jose+json | |||
| The header of the pledge enrollment-request SHALL contain the | The header of the pledge enrollment-request SHALL contain the | |||
| following parameter as defined in [RFC7515]: | following parameter as defined in [RFC7515]: | |||
| * alg: algorithm used for creating the object signature. | * alg: algorithm used for creating the object signature. | |||
| * x5c: contains the base64-encoded pledge IDevID certificate. It | * x5c: contains the base64-encoded pledge IDevID certificate. It | |||
| may optionally contain the certificate chain for this certificate. | may optionally contain the certificate chain for this certificate. | |||
| The body of the pledge enrollment-request object SHOULD contain a P10 | The body of the pledge enrollment-request object SHOULD contain a P10 | |||
| skipping to change at page 27, line 4 ¶ | skipping to change at page 27, line 47 ¶ | |||
| { | { | |||
| "protected": { | "protected": { | |||
| "alg": "ES256", | "alg": "ES256", | |||
| "x5c": [ "MIIB2jCC...dA==" ] | "x5c": [ "MIIB2jCC...dA==" ] | |||
| }, | }, | |||
| "signature": "base64encodedvalue==" | "signature": "base64encodedvalue==" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| Figure 9: Representation of pledge-enrollment-request | Figure 9: Representation of pledge-enrollment-request | |||
| With the collected pledge-voucher-request object and the pledge- | With the collected pledge-voucher-request object and the pledge- | |||
| enrollment-request object, the registrar-agent starts the interaction | enrollment-request object, the registrar-agent starts the interaction | |||
| with the domain registrar. | with the domain registrar. | |||
| Once the registrar-agent has collected the pledge-voucher-request and | As the registrar-agent is intended to facilitate communication | |||
| pledge-enrollment-request objects, it connects to the registrar and | between the pledge and the domain registrar, a collection of requests | |||
| sends the request objects. As the registrar-agent is intended to | from more than one pledge is possible, allowing a bulk bootstrapping | |||
| work between the pledge and the domain registrar, a collection of | of multiple pledges using the same connection between the registrar- | |||
| requests from more than one pledge is possible, allowing a bulk | agent and the domain registrar. | |||
| bootstrapping of multiple pledges using the same connection between | ||||
| the registrar-agent and the domain registrar. | ||||
| 5.1.4.2. Request Handling - Registrar-Agent (Infrastructure) | 5.5.2. Request Processing by the Registrar-Agent | |||
| The BRSKI-PRM bootstrapping exchanges between registrar-agent and | The BRSKI-PRM bootstrapping exchanges between registrar-agent and | |||
| domain registrar resemble the BRSKI exchanges between pledge and | domain registrar resemble the BRSKI exchanges between pledge and | |||
| domain registrar (pledge-initiator-mode) with some deviations. | domain registrar (pledge-initiator-mode) with some deviations. | |||
| Preconditions: | Preconditions: | |||
| * Registrar-agent: possesses IDevID CA certificate and it's own | * Registrar-agent: possesses it's own LDevID(RegAgt) credentials of | |||
| LDevID(RegAgt) credentials of site domain. It has the address of | the site domain. In addition, it may possess the IDevID CA | |||
| the domain registrar through configuration or by discovery, e.g., | certificate of the pledge vendor/manufacturer to verify the pledge | |||
| mDNS/DNSSD. The registrar-agent has acquired pledge-voucher- | certificate in the received request messages. It has the address | |||
| request and pledge-enrollment-request objects(s). | of the domain registrar through configuration or by discovery, | |||
| e.g., mDNS/DNSSD. The registrar-agent has acquired pledge- | ||||
| voucher-request and pledge-enrollment-request objects(s). | ||||
| * Registrar: possesses IDevID CA certificate of pledge vendor/ | * Registrar: possesses the IDevID CA certificate of the pledge | |||
| manufacturer and an it's own LDevID(Reg) credentials. | vendor/manufacturer and an it's own LDevID(Reg) credentials of the | |||
| site domain. | ||||
| * MASA: possesses it's own vendor/manufacturer credentials (voucher | * MASA: possesses it's own vendor/manufacturer credentials (voucher | |||
| signing key, TLS server certificate) related to pledges IDevID and | signing key, TLS server certificate) related to pledges IDevID and | |||
| site-specific LDevID CA certificate. | the site-specific LDevID CA certificate. | |||
| +-----------+ +-----------+ +--------+ +---------+ | +-----------+ +-----------+ +--------+ +---------+ | |||
| | Registrar-| | Domain | | Domain | | Vendor | | | Registrar-| | Domain | | Domain | | Vendor | | |||
| | agent | | Registrar | | CA | | Service | | | agent | | Registrar | | CA | | Service | | |||
| | (RegAgt) | | (JRC) | | | | (MASA) | | | (RegAgt) | | (JRC) | | | | (MASA) | | |||
| +-----------+ +-----------+ +--------+ +---------+ | +-----------+ +-----------+ +--------+ +---------+ | |||
| | | | Internet | | | | | Internet | | |||
| [exchange between pledge and ] | | | [voucher + enrollment] | | | | |||
| [registrar-agent done. ] | | | [objects available. ] | | | | |||
| | | | | | | | | | | |||
| |<------ TLS ----->| | | | |<----- mTLS ----->| | | | |||
| | [Reg-Agt auth+authz?] | | | | [Reg-Agt authenticated | | | |||
| | and authorized?] | | | ||||
| | | | | | | | | | | |||
| |-- Voucher-Req -->| | | | |-- Voucher-Req -->| | | | |||
| | (PVR) | | | | | (PVR) | | | | |||
| | [Reg-Agt authorized?] | | | | [Reg-Agt authorized?] | | | |||
| | [accept device?] | | | | [accept device?] | | | |||
| | [contact vendor] | | | | [contact vendor] | | | |||
| | |------------ TLS --------->| | | |----------- mTLS --------->| | |||
| | |-- Voucher-Req ----------->| | | |-- Voucher-Req ----------->| | |||
| | | (RVR) | | | | (RVR) | | |||
| | | [extract DomainID] | | | [extract DomainID] | |||
| | | [update audit log] | | | [update audit log] | |||
| | |<-------- Voucher ---------| | | |<-------- Voucher ---------| | |||
| |<---- Voucher ----| | | |<---- Voucher ----| | | |||
| | | | | | | | | |||
| [certification request handling registrar-agent] | | ||||
| [and site infrastructure] | | ||||
| |--- Enroll-Req -->| | | | |--- Enroll-Req -->| | | | |||
| | (PER) | | | | | (PER) | | | | |||
| | |---- TLS ---->| | | | |--- mTLS ---->| | | |||
| | |- Enroll-Req->| | | | |- Enroll-Req->| | | |||
| | | (RER) | | | | | (RER) | | | |||
| | |<-Enroll-Resp-| | | | |<-Enroll-Resp-| | | |||
| |<-- Enroll-Resp---| | | | |<-- Enroll-Resp---| | | | |||
| | | | | | | | | | | |||
| Figure 10: Request processing between registrar-agent and | Figure 10: Request processing between registrar-agent and | |||
| infrastructure bootstrapping services | infrastructure bootstrapping services | |||
| The registrar-agent establishes a TLS connection with the registrar. | The registrar-agent establishes a TLS connection with the registrar. | |||
| As already stated in [RFC8995], the use of TLS 1.3 (or newer) is | As already stated in [RFC8995], the use of TLS 1.3 (or newer) is | |||
| encouraged. TLS 1.2 or newer is REQUIRED on the registrar-agent | encouraged. TLS 1.2 or newer is REQUIRED on the registrar-agent | |||
| side. TLS 1.3 (or newer) SHOULD be available on the registrar, but | side. TLS 1.3 (or newer) SHOULD be available on the registrar, but | |||
| TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be available on the | TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be available on the | |||
| MASA, but TLS 1.2 MAY be used. | MASA, but TLS 1.2 MAY be used. | |||
| In contrast to [RFC8995] TLS client authentication is achieved by | In contrast to [RFC8995] TLS client authentication to the registrar | |||
| using registrar-agent LDevID(RegAgt) credentials instead of pledge | is achieved by using registrar-agent LDevID(RegAgt) credentials | |||
| IDevID credentials. This allows the registrar to distinguish between | instead of pledge IDevID credentials. Consequently BRSKI (pledge- | |||
| BRSKI (pledge-initiator-mode) and BRSKI-PRM (pledge-responder-mode). | initiator-mode) is distinguishable from BRSKI-PRM (pledge-responder- | |||
| The registrar SHOULD verify that the registrar-agent is authorized to | mode) by the registrar. The registrar SHOULD verify that the | |||
| connect to the registrar based on the LDevID(RegAgt). Note, the | registrar-agent is authorized to establish a connection to the | |||
| authorization will be verified based on the agent-signed-data carried | registrar by TLS client authentication using LDevID(RegAgt) | |||
| in the pledge-voucher-request. As short-lived certificates are | credentials. If the connection form registrar-agent to registrar is | |||
| recommended for the registrar-agent, the LDevID(RegAgt) EE | established, the authorization SHALL be verified again based on the | |||
| certificate used in the TLS handshake may be newer than the one of in | agent-signed-data contained in the pledge-voucher-request (PVR). | |||
| the pledge-voucher-request. | This ensures that the pledge has been triggered by an authorized | |||
| registrar-agent. | ||||
| The registrar can received request objects in different forms as | The registrar can receive request objects in different formats as | |||
| defined in [RFC8995]. Specifically, the registrar will receive JSON- | defined in [RFC8995]. Specifically, the registrar will receive JSON- | |||
| in-JWS objects generated by the pledge for voucher-request and | in-JWS objects generated by the pledge for voucher-request and | |||
| enrollment-request (instead of BRSKI voucher-request as CMS-signed | enrollment-request (instead of BRSKI voucher-request as CMS-signed | |||
| JSON and enrollment-request as PKCS#10 objects). | JSON and enrollment-request as PKCS#10 objects). | |||
| The registrar-agent sends the pledge-voucher-request to the registrar | The registrar-agent SHALL send the pledge-voucher-request by HTTP | |||
| by HTTP POST to the endpoint: "/.well-known/brski/requestvoucher" | POST to the registrar endpoint: "/.well-known/brski/requestvoucher" | |||
| The pledge-voucher-request Content-Type header field used for pledge- | The Content-Type header field for JSON-in-JWS pledge-voucher-request | |||
| responder-mode is defined in [I-D.ietf-anima-jws-voucher] as: | is: application/voucher-jws+json (see Figure 7 for the content | |||
| application/voucher-jws+json (see Figure 7 for the content | definition), as defined in [I-D.ietf-anima-jws-voucher]. | |||
| definition). | ||||
| The registrar-agent SHOULD include the Accept request-header field | The registrar-agent SHOULD set the Accept field in the request-header | |||
| indicating the pledge acceptable Content-Type for the voucher- | indicating the acceptable Content-Type for the voucher-response. The | |||
| response. The voucher-response Content-Type header field | voucher-response Content-Type header field SHOULD be set to | |||
| "application/voucher-jws+json" is defined in | application/voucher-jws+json as defined in | |||
| [I-D.ietf-anima-jws-voucher]. | [I-D.ietf-anima-jws-voucher]. | |||
| Upon reception of the pledge-voucher-request, the registrar SHALL | After receiving the pledge-voucher-request from registrar-agent, the | |||
| perform the verification of the voucher-request parameter as defined | registrar SHALL perform the verification as defined in section 5.3 of | |||
| in section 5.3 of [RFC8995]. In addition, the registrar shall verify | [RFC8995]. In addition, the registrar shall verify the following | |||
| the following parameters from the pledge-voucher-request: | parameters from the pledge-voucher-request (PVR): | |||
| * agent-provided-proximity-registrar-cert: MUST contain registrars | * agent-provided-proximity-registrar-cert: MUST contain registrar's | |||
| own LDevID(Reg) EE certificate to ensure the registrar in | own LDevID(Reg) EE certificate to ensure the registrar in | |||
| proximity is the target registrar for the request. | proximity of the registrar-agent is the destination for this PVR. | |||
| * agent-signed-data: The registrar MUST verify that the agent | * agent-signed-data: The registrar MUST verify that the agent | |||
| provided data has been signed with the LDevID(RegAgt) credential | provided data has been signed with the LDevID(RegAgt) credential | |||
| indicated in the "kid" JOSE header parameter. If the certificate | indicated in the "kid" JOSE header parameter. If the certificate | |||
| is not included in the agent-sign-cert properties of the pledge- | is not included in the agent-sign-cert properties of the pledge- | |||
| voucher-request, it must be fetched from a repository by the | voucher-request, it must be fetched out-of-band by the registrar | |||
| registrar if "agent-proximity" assertion is requested. | if "agent-proximity" assertion is requested. | |||
| * agent-sign-cert: MAY contain an array of base64-encoded | * agent-sign-cert: MAY contain an array of base64-encoded | |||
| certificate data starting with the LDevID(RegAgt) EE certificate. | certificate data starting with the LDevID(RegAgt) EE certificate. | |||
| If contained the registrar MUST verify that the credentials | If contained the registrar MUST verify that the LDevID(ReAgt) EE | |||
| (LDevID(ReAgt) EE certificate and optionally the certificate | certificate, used to sign the data, is still valid. If the | |||
| chain), used to sign the data, have been valid at signature | certificate is already expired, the registrar SHALL reject the | |||
| creation time and the corresponding registrar-agent was authorized | request. Validity of used signing certificates during | |||
| for involvement in the bootstrapping process. If the agent- | bootstrapping is necessary as no trusted timestamp is available, | |||
| signed-cert is not provided, the registrar MUST fetch the | see also Section 9.3. | |||
| LDevID(RegAgt) EE certificate and perform this verification, based | If the agent-signed-cert is not provided, the registrar MUST fetch | |||
| on the provided SubjectKeyIdentifier (SKID) contained in the kid | the LDevID(RegAgt) EE certificate, based on the provided | |||
| header of the agent-signed-data. This requires, that the | SubjectKeyIdentifier (SKID) contained in the kid header of the | |||
| registrar can fetch the LDevID(RegAgt) certificate data (including | agent-signed-data, and perform this verification. This requires, | |||
| intermediate CA certificates if existent) based on the SKID. | that the registrar can fetch the LDevID(RegAgt) certificate data | |||
| (including intermediate CA certificates if existent) based on the | ||||
| SKID. | ||||
| If validation fails the registrar SHOULD respond with HTTP 404 error | If the validation fails the registrar SHOULD respond with HTTP 404 | |||
| code to the registrar-agent. HTTP 406 error code is more | error code to the registrar-agent. HTTP 406 error code SHOULD be | |||
| appropriate, if the format of pledge-voucher-request is unknown. | used if the format of pledge-voucher-request is unknown. | |||
| If validation succeeds, the registrar will accept the pledge's | If the validation succeeds, the registrar SHOULD accept the pledge- | |||
| request to join the domain as defined in section 5.3 of [RFC8995]. | voucher-request (PVR) to join the domain as defined in section 5.3 of | |||
| The registrar then establishes a TLS connection with the MASA as | [RFC8995]. The registrar then establishes a TLS connection to MASA | |||
| described in section 5.4 of [RFC8995] to obtain a voucher for the | as described in section 5.4 of [RFC8995] to obtain a voucher for the | |||
| pledge. | pledge. | |||
| The registrar SHALL construct the body of the registrar-voucher- | The registrar SHALL construct the payload of the registrar-voucher- | |||
| request object as defined in [RFC8995]. The encoding SHALL be done | request (RVR) object as defined in [RFC8995]. The RVR object | |||
| as JSON-in-JWS object as defined in [I-D.ietf-anima-jws-voucher]. | encoding SHALL be JSON-in-JWS as defined in | |||
| [I-D.ietf-anima-jws-voucher]. | ||||
| The header of the registrar-voucher-request SHALL contain the | The header of the registrar-voucher-request (RVR) SHALL contain the | |||
| following parameter as defined in [RFC7515]: | following parameter as defined in [RFC7515]: | |||
| * alg: algorithm used to create the object signature. | * alg: algorithm used to create the object signature. | |||
| * x5c: contains the base64-encoded registrar LDevID certificate(s). | * x5c: contains the base64-encoded registrar LDevID certificate(s). | |||
| It may optionally contain the certificate chain for this | It may optionally contain the certificate chain for this | |||
| certificate. | certificate. | |||
| The payload of the registrar-voucher-request (RVR) object MUST | The payload of the registrar-voucher-request (RVR) object MUST | |||
| contain the following parameter as part of the voucher request as | contain the following parameter as part of the voucher request as | |||
| skipping to change at page 31, line 18 ¶ | skipping to change at page 32, line 18 ¶ | |||
| serial-number value contained in the agent-signed data of PVR. | serial-number value contained in the agent-signed data of PVR. | |||
| * assertion: contains the voucher assertion requested by the pledge | * assertion: contains the voucher assertion requested by the pledge | |||
| (agent-proximity). The registrar provides this information to | (agent-proximity). The registrar provides this information to | |||
| assure successful verification of agent proximity based on the | assure successful verification of agent proximity based on the | |||
| agent-signed-data. | agent-signed-data. | |||
| * prior-signed-voucher-request: contains the pledge-voucher-request | * prior-signed-voucher-request: contains the pledge-voucher-request | |||
| provided by the registrar-agent. | provided by the registrar-agent. | |||
| The voucher request can be enhanced optionally with the following | The registrar-voucher-request (RVR) can be enhanced optionally with | |||
| additional parameter as defined in Section 6.1: | the following parameter as defined in Section 6.1: | |||
| * agent-sign-cert: contains the certificate or the certificate | * agent-sign-cert: contains the LDevID(RegAgt) EE certificate or the | |||
| including the chain of the registrar-agent. In the context of | LDevID(RegAgt) EE certificate including the certificate chain. In | |||
| this document it is a JSON array of base64encoded certificate | the context of this document it is a JSON array of base64encoded | |||
| information and handled in the same way as x5c header objects. | certificate information and handled in the same way as x5c header | |||
| objects. | ||||
| If only a single object is contained in the list it MUST be the | If only a single object is contained in the x5c it MUST be the | |||
| base64-encoded LDevID(RegAgt) EE certificate. If multiple | base64-encoded LDevID(RegAgt) EE certificate. If multiple | |||
| certificates are included, the first MUST be the base64-encoded | certificates are included in the x5c, the first MUST be the | |||
| LDevID(RegAgt) EE certificate. | base64-encoded LDevID(RegAgt) EE certificate. | |||
| The MASA uses this information for the verification of agent | The MASA uses this information for verification of the agent is in | |||
| proximity to issue the corresponding assertion "agent-proximity". If | proximity to the registrar to state the corresponding assertion | |||
| the agent-sign-cert is not contained in the registrar-voucher- | "agent-proximity". If the agent-sign-cert is not included in the | |||
| request, it is contained in the prior-signed-voucher from the pledge. | registrar-voucher-request (RVR), it is also contained in the "prior- | |||
| signed-voucher-request" field carrying the pledge-voucher-request | ||||
| PVR. | ||||
| The object is signed using the registrar LDevID(Reg) credential, | The object is signed using the registrar LDevID(Reg) credential, | |||
| which corresponds to the certificate signaled in the JOSE header. | which corresponds to the certificate signaled in the JOSE header. | |||
| { | { | |||
| "payload": { | "payload": { | |||
| "ietf-voucher-request-prm:voucher": { | "ietf-voucher-request-prm:voucher": { | |||
| "created-on": "2022-01-04T02:37:39.235Z", | "created-on": "2022-01-04T02:37:39.235Z", | |||
| "nonce": "eDs++/FuDHGUnRxN3E14CQ==", | "nonce": "eDs++/FuDHGUnRxN3E14CQ==", | |||
| "serial-number": "callee4711", | "serial-number": "callee4711", | |||
| skipping to change at page 32, line 23 ¶ | skipping to change at page 33, line 23 ¶ | |||
| "agent-sign-cert": [ | "agent-sign-cert": [ | |||
| "base64encodedvalue==", | "base64encodedvalue==", | |||
| "base64encodedvalue==", | "base64encodedvalue==", | |||
| "..." | "..." | |||
| ] | ] | |||
| }, | }, | |||
| "signatures": [ | "signatures": [ | |||
| { | { | |||
| "protected": { | "protected": { | |||
| "alg": "ES256", | "alg": "ES256", | |||
| "x5c": [ "MIIB2jCC...dA==" ] | "x5c": [ "base64encodedvalue==" ] | |||
| }, | }, | |||
| "signature": "base64encodedvalue==" | "signature": "base64encodedvalue==" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| Figure 11: Representation of registrar-voucher-request | Figure 11: Representation of registrar-voucher-request | |||
| The registrar sends the registrar-voucher-request to the MASA by HTTP | The registrar SHALL send the registrar-voucher-request (RVR) to the | |||
| POST to the endpoint "/.well-known/brski/requestvoucher". | MASA endpoint by HTTP POST: "/.well-known/brski/requestvoucher" | |||
| The registrar-voucher-request Content-Type header field is defined in | The registrar-voucher-request Content-Type header field is defined in | |||
| [I-D.ietf-anima-jws-voucher] as: application/voucher-jws+json | [I-D.ietf-anima-jws-voucher] as: application/voucher-jws+json | |||
| The registrar SHOULD include an Accept request-header field | The registrar-voucher-request (RVR) SHOULD set the Accept header | |||
| indicating the acceptable media type for the voucher-response. The | indicating the desired media type for the voucher-response. The | |||
| media type "application/voucher-jws+json" is defined in | media type is application/voucher-jws+json as defined in | |||
| [I-D.ietf-anima-jws-voucher]. | [I-D.ietf-anima-jws-voucher]. | |||
| Once the MASA receives the registrar-voucher-request it SHALL perform | Once the MASA receives the registrar-voucher-request (RVR) it SHALL | |||
| the verification of the contained components as described in section | perform the verification as described in section 5.5 in [RFC8995]. | |||
| 5.5 in [RFC8995]. | ||||
| In addition, the following processing SHALL be performed for data | In addition, the following processing SHALL be performed for PVR data | |||
| contained in the prior-signed-voucher-request: | contained in RVR "prior-signed-voucher-request" field: | |||
| * agent-provided-proximity-registrar-cert: The MASA MAY verify that | * agent-provided-proximity-registrar-cert: The MASA MAY verify that | |||
| this field contains the LDevID(Reg) certificate. If so, it MUST | this field contains the LDevID(Reg) certificate. If so, it MUST | |||
| correspond to the certificate used to sign the registrar-voucher- | correspond to the LDevID(Reg) certificate used to sign the | |||
| request. | registrar-voucher-request (RVR). Note: Correspond here relates to | |||
| the case that a single LDevID(Reg) certificate is used or that | ||||
| different LDevID(Reg) certificates are used, which are issued by | ||||
| the same CA. | ||||
| * agent-signed-data: The MASA MAY verify this field to issue "agent- | * agent-signed-data: The MASA MAY verify this field to issue "agent- | |||
| proximity" assertion. If so, the agent-signed-data MUST contain | proximity" assertion. If so, the agent-signed-data MUST contain | |||
| the pledge product-serial-number, contained in the serial-number | the pledge product-serial-number, contained in the "serial-number" | |||
| properties of the prior-signed-voucher and also in serial-number | field of the PVR (from "prior-signed-voucher-request" field) and | |||
| properties of the registrar-voucher-request. The LDevID(RegAgt) | also in "serial-number" field of the registrar-voucher-request | |||
| EE certificate used to generate the signature is identified by the | (RVR). The LDevID(RegAgt) EE certificate used to generate the | |||
| "kid" parameter of the JOSE header (agent-signed-data). If the | signature is identified by the "kid" parameter of the JOSE header | |||
| assertion "agent-proximity" is requested, the registrar-voucher- | (agent-signed-data). If the assertion "agent-proximity" is | |||
| request MUST contain the corresponding LDevID(RegAgt) certificate | requested, the registrar-voucher-request MUST contain the | |||
| data in the agent-sign-cert. Either in the LDevID(RegAgt) EE | corresponding LDevID(RegAgt) certificate data in the "agent-sign- | |||
| certificate of registrar-voucher-request or of the prior-signed- | cert" field of either the LDevID(RegAgt) EE certificate of | |||
| voucher can be verified by the MASA as issued by the same domain | registrar-voucher-request (RVR) or of pledge-voucher-request (PVR) | |||
| CA as the LDevID(Reg) EE certificate. | from "prior-signed-voucher-request" field. It can be verified by | |||
| If the agent-sign-cert information is not provided, the MASA MAY | the MASA that it was issued by the same domain CA as the | |||
| provide a lower level assertion, e.g.: "logged" or "verified" | LDevID(Reg) EE certificate. | |||
| Note, in case the LDevID(RegAgt) EE certificate is issued by a | If the "agent-sign-cert" field is not provided, the MASA MAY state | |||
| sub-CA and not the domain CA known to the MASA, sub-CA | a lower level assertion value, e.g.: "logged" or "verified" Note: | |||
| certificate(s) MUST also be presented in the agent-sign-cert. As | Sub-CA certificate(s) MUST also be carried by "agent-sign-cert", | |||
| this field is defined as array, it can handle multiple | in case the LDevID(RegAgt) EE certificate is issued by a sub-CA | |||
| and not the domain CA known to the MASA. As the "agent-sign-cert" | ||||
| field is defined as array (x5c), it can handle multiple | ||||
| certificates. | certificates. | |||
| If validation fails, the MASA SHOULD respond with an HTTP error code | If validation fails, the MASA SHOULD respond with an HTTP error code | |||
| to the registrar. The HTTP error codes are kept as defined in | to the registrar. The HTTP error codes are kept the same as defined | |||
| section 5.6 of [RFC8995], and comprise the codes: 403, 404, 406, and | in section 5.6 of [RFC8995], and comprise the codes: 403, 404, 406, | |||
| 415. | and 415. | |||
| The expected voucher response format is indicated by the Accept | The expected voucher-response format is indicated by the Accept | |||
| request-header field or based on the MASA's prior understanding of | header field of the RVR or MASA SHOULD respond with the same format | |||
| proper format for this pledge. Specifically for the pledge- | as the PVR was (default "JSON-in-JWS") Specifically for the pledge- | |||
| responder-mode the "application/voucher-jws+json" as defined in | responder-mode the application/voucher-jws+json as defined in | |||
| [I-D.ietf-anima-jws-voucher] is applied. The voucher syntax is | [I-D.ietf-anima-jws-voucher] is applied. The voucher syntax is | |||
| described in detail by [RFC8366]. Figure 12 shows an example of the | described in detail by [RFC8366]. Figure 12 shows an example of the | |||
| contents of a voucher. | contents of a voucher. | |||
| { | { | |||
| "payload": { | "payload": { | |||
| "ietf-voucher:voucher": { | "ietf-voucher:voucher": { | |||
| "assertion": "agent-proximity", | "assertion": "agent-proximity", | |||
| "serial-number": "callee4711", | "serial-number": "callee4711", | |||
| "nonce": "eDs++/FuDHGUnRxN3E14CQ==", | "nonce": "eDs++/FuDHGUnRxN3E14CQ==", | |||
| "created-on": "2022-01-04T00:00:02.000Z", | "created-on": "2022-01-04T00:00:02.000Z", | |||
| "pinned-domain-cert": "MIIBpDCCA...w==" | "pinned-domain-cert": "MIIBpDCCA...w==" | |||
| }, | }, | |||
| "signatures": [ | "signatures": [ | |||
| { | { | |||
| "protected": { | "protected": { | |||
| "alg": "ES256", | "alg": "ES256", | |||
| "x5c": [ "MIIB2jCC...dA==" ] | "x5c": [ "base64encodedvalue==" ] | |||
| }, | }, | |||
| "signature": "base64encodedvalue==" | "signature": "base64encodedvalue==" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| Figure 12: Representation of MASA issued voucher | Figure 12: Representation of MASA issued voucher | |||
| The MASA responds the voucher to the registrar. | The MASA returns the voucher-response object to the registrar. | |||
| After receiving the voucher the registrar SHOULD evaluate it for | After receiving the voucher the registrar SHOULD evaluate it for | |||
| transparency and logging purposes as outlined in section 5.6 of | transparency and logging purposes as outlined in section 5.6 of | |||
| [RFC8995]. The registrar MAY provide an additional signature of the | [RFC8995]. The registrar MAY add an additional signature to the | |||
| voucher. This signature is done over the same content as the MASA | voucher-response object, by signing it using its registrar | |||
| signature of the voucher and provides a proof of possession of the | credentials (LDevID(Reg)). This signature is done over the same | |||
| private key corresponding to the LDevID(Reg) the pledge received in | content as the MASA signature of the voucher and provides a proof of | |||
| the trigger for the PVR (see Figure 5). The registrar MUST use the | possession of the private key corresponding to the LDevID(Reg) the | |||
| same LDevID(Reg) credential that is used for authentication in the | pledge received in the trigger for the PVR (see Figure 5). The | |||
| TLS handshake to authenticate towards the registrar-agent. This | registrar MUST use the same LDevID(Reg) credential that is used for | |||
| ensures that the same LDevID(Reg) certificate can be used to verify | authentication in the TLS handshake to authenticate towards the | |||
| the signature as transmitted in the voucher request as is transferred | registrar-agent. This ensures that the same LDevID(Reg) certificate | |||
| in the pledge-voucher-request in the agent-provided-proximity- | can be used to verify the signature as transmitted in the voucher | |||
| registrar-cert component. Figure Figure 13 below provides an example | request as is transferred in the pledge-voucher-request in the agent- | |||
| of the voucher with two signatures. | provided-proximity-registrar-cert component. Figure Figure 13 below | |||
| provides an example of the voucher with two signatures. | ||||
| { | { | |||
| "payload": { | "payload": { | |||
| "ietf-voucher:voucher": { | "ietf-voucher:voucher": { | |||
| "assertion": "agent-proximity", | "assertion": "agent-proximity", | |||
| "serial-number": "callee4711", | "serial-number": "callee4711", | |||
| "nonce": "eDs++/FuDHGUnRxN3E14CQ==", | "nonce": "eDs++/FuDHGUnRxN3E14CQ==", | |||
| "created-on": "2022-01-04T00:00:02.000Z", | "created-on": "2022-01-04T00:00:02.000Z", | |||
| "pinned-domain-cert": "MIIBpDCCA...w==" | "pinned-domain-cert": "MIIBpDCCA...w==" | |||
| }, | }, | |||
| "signatures": [ | "signatures": [ | |||
| { | { | |||
| "protected": { | "protected": { | |||
| "alg": "ES256", | "alg": "ES256", | |||
| "x5c": [ "MIIB2jCC...dA==" ] | "x5c": [ "base64encodedvalue==" ] | |||
| }, | }, | |||
| "signature": "base64encodedvalue==" | "signature": "base64encodedvalue==" | |||
| }, | }, | |||
| { | { | |||
| "protected": { | "protected": { | |||
| "alg": "ES256", | "alg": "ES256", | |||
| "x5c": [ "xURZmcWS...dA==" ] | "x5c": [ "base64encodedvalue==" ] | |||
| }, | }, | |||
| "signature": "base64encodedvalue==" | "signature": "base64encodedvalue==" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| Figure 13: Representation of MASA issued voucher with additional | Figure 13: Representation of MASA issued voucher with additional | |||
| registrar signature | registrar signature | |||
| Depending on the security policy of the operator, this signature can | Depending on the security policy of the operator, this signature can | |||
| also be interpreted as explicit authorization of the registrar to | also be interpreted by the pledge explicit authorization of the | |||
| install the contained trust anchor. | registrar to install the contained trust anchor. The registrar sends | |||
| the voucher to the registrar-agent. | ||||
| The registrar forwards the voucher to the registrar-agent. | ||||
| After receiving the voucher, the registrar-agent sends the pledge- | After receiving the voucher, the registrar-agent sends the pledge- | |||
| enrollment-request (PER) to the registrar. Deviating from BRSKI the | enrollment-request (PER) to the registrar. Deviating from BRSKI the | |||
| pledge-enrollment-request is not a raw PKCS#10 object. As the | pledge-enrollment-request (PER) is not a raw PKCS#10 object. As the | |||
| registrar-agent is involved in the exchange, the PKCS#10 is wrapped | registrar-agent is involved in the exchange, the PKCS#10 is wrapped | |||
| in a JWS object. The JWS object is signed with the pledge's IDevID | in a JWS object by the pledge and signed with pledge's IDevID to | |||
| to ensure proof-of-identity as outlined in Figure 9. | ensure proof-of-identity as outlined in Figure 9. | |||
| When using EST, the standard endpoint on the registrar cannot be | [RFC7030] EST standard endpoints (/simpleenroll, /simplereenroll, | |||
| used. EST requires to sent a raw PKCS#10 request to the simpleenroll | /serverkeygen) on the registrar cannot be used for BRSKI-PRM. As EST | |||
| endpoint. This document makes an enhancement by utilizing EST but | requires to sent a raw PKCS#10 request to the /simpleenroll endpoint. | |||
| with the exception to transport a signature wrapped PKCS#10 request. | This document makes an enhancement by utilizing EST but with the | |||
| Therefore a new endpoint for the registrar is defined as "/.well- | exception to transport a signature wrapped PKCS#10 request. | |||
| known/brski/requestenroll" | Therefore a new endpoint for BRSKI-PRM on the registrar is defined as | |||
| "/.well-known/brski/requestenroll" | ||||
| The PER Content-Type header is: application/jose. | The Content-Type header of PER is: application/jose+json. | |||
| This results in a deviation from the content types used in [RFC7030] | This is a deviation from the Content-Type header values used in | |||
| and in additional processing at the domain registrar as EST server as | [RFC7030] and results in additional processing at the domain | |||
| following. Note, the registrar is already aware that the | registrar (as EST server). Note, the registrar is already aware that | |||
| bootstrapping is performed in a pledge-responder-mode due to the use | the bootstrapping is performed in a pledge-responder-mode due to the | |||
| of the LDevID(RegAgt) EE certificate in the TLS establishment and the | use of the LDevID(RegAgt) EE certificate in the TLS establishment and | |||
| provided pledge-voucher-request as JWS object. | the provided pledge-voucher-request (PVR) as JSON-in-JWS object. | |||
| * If the registrar receives a pledge-enrollment-request with | * If the registrar receives a pledge-enrollment-request (PER) with | |||
| Content-Type header field "application/jose", it MUST verify the | Content-Type header: application/jose+json, it MUST verify the | |||
| wrapping signature using the certificate indicated in the JOSE | wrapping signature using the certificate indicated in the JOSE | |||
| header. | header. | |||
| * The registrar verifies that the pledge's IDevID certificate of the | * The registrar verifies that the pledge's certificate (here | |||
| x5c header field, is accepted to join the domain, based on the | IDevID), carried in "x5c" header field, is accepted to join the | |||
| verification of the pledge-voucher-request. | domain after successful validation of the pledge-voucher-request. | |||
| * If both succeed, the registrar utilizes the PKCS#10 request | * If both succeed, the registrar utilizes the PKCS#10 request | |||
| contained in the JWS object body as "P10" parameter of "ietf-sztp- | contained in the JWS object body as "P10" parameter of "ietf-sztp- | |||
| csr:csr" for further processing of the enrollment request with the | csr:csr" for further processing of the enrollment request with the | |||
| domain CA. It will construct a registrar-enrollment-request (RER) | corresponding domain CA. It creates a registrar-enrollment- | |||
| by utilizing the enrollment protocol expected by the domain CA. | request (RER) by utilizing the protocol expected by the domain CA. | |||
| The domain registrar may either enhance the PKCS#10 request or | The domain registrar may either enhance the PKCS#10 request or | |||
| generate a structure containing the attributes to be included by | generate a structure containing the attributes to be included by | |||
| the CA into the requested LDevID EE certificate and sends both | the CA into the requested LDevID EE certificate and sends both | |||
| (the original PKCS#10 request and the enhancements) to the domain | (the original PKCS#10 request and the enhancements) to the domain | |||
| CA. As enhancing the PKCS#10 request destroys the initial proof | CA. As enhancing the PKCS#10 request destroys the initial proof | |||
| of possession of the corresponding private key, the CA would need | of possession of the corresponding private key, the CA would need | |||
| to accept RA-verified requests. This handling is out of scope for | to accept RA-verified requests. This request handling to the | |||
| this document. | domain CA is out of scope for this document. | |||
| The registrar-agent sends the PER to the registrar by HTTP POST to | The registrar-agent SHALL send the PER to the registrar by HTTP POST | |||
| the endpoint: "/.well-known/brski/requestenroll" | to the endpoint: "/.well-known/brski/requestenroll" | |||
| If validation of the wrapping signature fails, the registrar SHOULD | If validation of the wrapping signature fails, the registrar SHOULD | |||
| respond with HTTP 404 error code. HTTP 406 error code is more | respond with the HTTP 404 error code. The HTTP 406 error code SHOULD | |||
| appropriate, if the pledge-enrollment-request is in an unknown | be used, if the pledge-enrollment-request (PER) is in an unknown | |||
| format. | format. | |||
| A situation that could be resolved with administrative action (such | A situation that could be resolved with administrative action (such | |||
| as adding a vendor/manufacturer IDevID CA as trusted party) MAY be | as adding a vendor/manufacturer IDevID CA as trusted party) MAY be | |||
| responded with HTTP 403 error code. | responded with the HTTP 403 error code. | |||
| A successful interaction with the domain CA will result in a pledge | A successful interaction with the domain CA will result in a pledge | |||
| LDevID EE certificate, which is then forwarded by the registrar to | LDevID EE certificate, which is then forwarded by the registrar to | |||
| the registrar-agent using the Content-Type header: "application/ | the registrar-agent using the Content-Type header: application/ | |||
| pkcs7-mime". | pkcs7-mime. | |||
| The registrar-agent has now finished the exchanges with the domain | The registrar-agent has now finished the exchanges with the domain | |||
| registrar and can supply the voucher-response (from MASA via | registrar and can supply the voucher-response (from MASA via | |||
| Registrar) and the enrollment-response (LDevID EE certificate) to the | Registrar) and the enrollment-response (LDevID EE certificate, from | |||
| pledge. It can close the TLS connection to the domain registrar and | CA via Registrar) to the pledge. It can close the TLS connection to | |||
| provide the objects to the pledge(s). The content of the response | the domain registrar and provide the objects to the pledge(s). The | |||
| objects is defined through the voucher [RFC8366] and the certificate | content of the response objects is defined by the voucher [RFC8366] | |||
| [RFC5280]. | and the certificate [RFC5280]. | |||
| 5.1.4.3. Response Object Supply by Registrar-Agent to Pledge | 5.5.3. Response Object Supply by Registrar-Agent to Pledge | |||
| The following description assumes that the registrar-agent has | The following description assumes that the registrar-agent has | |||
| obtained the response objects from the domain registrar. It will re- | obtained the response objects from the domain registrar. It will re- | |||
| start the interaction with the pledge. To contact the pledge, it may | start the interaction with the pledge. To contact the pledge, it may | |||
| either discover the pledge as described in Section 5.1.3.2 or use | either discover the pledge as described in Section 5.4.2 or use | |||
| stored information from the first contact with the pledge. | stored information from the first contact with the pledge. | |||
| Preconditions in addition to Section 5.1.4.2: | Preconditions in addition to Section 5.5.2: | |||
| * Registrar-agent: possesses voucher and LDevID certificate. | * Registrar-agent: possesses voucher and LDevID certificate. | |||
| +--------+ +-----------+ | +--------+ +-----------+ | |||
| | Pledge | | Registrar-| | | Pledge | | Registrar-| | |||
| | | | Agent | | | | | Agent | | |||
| | | | (RegAgt) | | | | | (RegAgt) | | |||
| +--------+ +-----------+ | +--------+ +-----------+ | |||
| | [voucher and enrollment] | ||||
| | [responses available] | ||||
| | | | | | | |||
| |<------- supply voucher -----------| | |<------- supply voucher -----------| | |||
| | | | | | | |||
| |--------- voucher-status --------->| - store | |--------- voucher status --------->| - store | |||
| | | pledge voucher-status | | | pledge voucher status | |||
| |<--- supply enrollment response ---| | |<--- supply enrollment response ---| | |||
| | | | | | | |||
| |--------- enroll-status ---------->| - store | |--------- enroll status ---------->| - store | |||
| | | pledge enroll-status | | | pledge enroll status | |||
| Figure 14: Response and status handling between pledge and | Figure 14: Response and status handling between pledge and | |||
| registrar-agent | registrar-agent | |||
| The registrar-agent provides the information via two distinct | The registrar-agent provides the information via two distinct pledge | |||
| endpoints to the pledge as following. | endpoints as following. | |||
| The voucher response is provided with a HTTP POST using the operation | The registrar-agent SHALL send the voucher-response to the pledge by | |||
| path value of "/.well-known/brski/pledge-voucher". | HTTP POST to the endpoint: "/.well-known/brski/pledge-voucher". | |||
| The registrar-agent voucher-response Content-Type header is | The registrar-agent voucher-response Content-Type header is | |||
| "application/voucher-jws+json and contains the voucher as provided by | application/voucher-jws+json and contains the voucher as provided by | |||
| the MASA. An example if given in Figure 12 for a MASA only signed | the MASA. An example if given in Figure 12 for a MASA only signed | |||
| voucher and in Figure Figure 13 for multiple signatures. | voucher and in Figure Figure 13 for multiple signatures. | |||
| If a single signature is contained, the pledge receives the voucher | If a single signature is contained, the pledge receives the voucher | |||
| and verifies it as described in section 5.6.1 in [RFC8995]. | and verifies it as described in section 5.6.1 in [RFC8995]. | |||
| If multiple signatures are contained in the voucher, the pledge SHALL | If multiple signatures are contained in the voucher, the pledge SHALL | |||
| perform the signature verification in the following order: | perform the signature verification in the following order: | |||
| 1. Verify MASA signature as described in section 5.6.1 in [RFC8995] | 1. Validate MASA signature as described in section 5.6.1 in | |||
| successfully. | [RFC8995] successfully. | |||
| 2. Install contained trust anchor provisionally. | 2. Install contained trust anchor provisionally. | |||
| 3. Verify registrar signature as described in section 5.6.1 in | 3. Verify registrar signature as described in section 5.6.1 in | |||
| [RFC8995] successfully, but take the registrar certificate | [RFC8995] successfully, but take the registrar certificate | |||
| instead of the MASA certificate for verification. | instead of the MASA certificate for verification. | |||
| 4. Verify the registrar certificate received in the agent-provided- | 4. Validate the registrar certificate received in the agent- | |||
| proximity-registrar-cert in the voucher request successfully. | provided-proximity-registrar-cert in the voucher request | |||
| successfully, including revocation state of the certificate, | ||||
| validity, and authorization to bootstrap the particular pledge. | ||||
| When all verification steps stated above have been performed | If all verification steps stated above have been performed | |||
| successfully, the pledge SHALL end the provisional accept state for | successfully, the pledge SHALL end the provisional accept state for | |||
| the domain trust anchor and the LDevID(Reg). When multiple | the domain trust anchor and the LDevID(Reg). If multiple signatures | |||
| signatures are contained in the voucher-response, the pledge MUST | are contained in the voucher-response, the pledge MUST verify all | |||
| verify all successfully. | successfully. | |||
| When an error occurs during the verification it SHALL be signaled in | If an error occurs during the verification it SHALL be signaled in | |||
| the reason field of the pledge voucher-status object. | the reason field of the pledge voucher status object. | |||
| After verification the pledge MUST reply with a status telemetry | After verification the pledge MUST reply with a status telemetry | |||
| message as defined in section 5.7 of [RFC8995]. | message as defined in section 5.7 of [RFC8995]. | |||
| The pledge generates the voucher-status-object and provides it as | The pledge generates the voucher status object and provides it as | |||
| JOSE object with the wrapping signature in the response message to | JOSE object with the wrapping signature in the response message to | |||
| the registrar-agent. | the registrar-agent. | |||
| The response has the Content-Type "application/jose" and is signed | The response has the Content-Type application/jose+json and is signed | |||
| using the IDevID of the pledge as shown in Figure 15. As the reason | using the IDevID of the pledge as shown in Figure 15. As the reason | |||
| field is optional (see [RFC8995]), it MAY be omitted in case of | field is optional (see [RFC8995]), it MAY be omitted in case of | |||
| success. | success. | |||
| { | { | |||
| "payload": { | "payload": { | |||
| "version": 1, | "version": 1, | |||
| "status": true, | "status": true, | |||
| "reason": "Informative human readable message", | "reason": "Informative human readable message", | |||
| "reason-context": { | "reason-context": { | |||
| "additional": "JSON" | "additional": "JSON" | |||
| } | } | |||
| }, | }, | |||
| "signatures": [ | "signatures": [ | |||
| { | { | |||
| "protected": { | "protected": { | |||
| "alg": "ES256", | "alg": "ES256", | |||
| "x5c": [ "MIIB2jCC...dA==" ] | "x5c": [ "base64encodedvalue==" ] | |||
| }, | }, | |||
| "signature": "base64encodedvalue==" | "signature": "base64encodedvalue==" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| Figure 15: Representation of pledge voucher-status telemetry | Figure 15: Representation of pledge voucher status telemetry | |||
| The enrollment response is provided with a HTTP POST using the | The registrar-agent SHALL send the enroll-response to the pledge by | |||
| operation path value of "/.well-known/brski/pledge-enrollment". | HTTP POST to the endpoint: "/.well-known/brski/pledge-enrollment". | |||
| The registrar-agent enroll-response Content-Type header, when using | The registrar-agent enroll-response Content-Type header, when using | |||
| EST [RFC7030] as enrollment protocol between the registrar-agent and | EST [RFC7030] as enrollment protocol between the registrar-agent and | |||
| the infrastructure, is: | the infrastructure, is application/pkcs7-mime. Note that it only | |||
| contains the LDevID certificate for the pledge, not the certificate | ||||
| application/pkcs7-mime: note that it only contains the LDevID | chain. | |||
| certificate for the pledge, not the certificate chain. | ||||
| Upon reception, the pledge verifies the LDevID certificate. When an | Upon reception, the pledge SHALL verify the received LDevID EE | |||
| error occurs during the verification it SHALL be signaled in the | certificate. The pledge MAY omit the revocation check as the EE | |||
| reason field of the pledge enroll-status object. | LDevID certificate was freshly issued.. The pledge SHALL generate | |||
| the enroll status object and provide it in the response message to | ||||
| the registrar-agent. If the verification of the LDevID EE | ||||
| certificate succeeds, the status SHALL be set to true, otherwise to | ||||
| FALSE. | ||||
| The pledge MUST reply with a status telemetry message as defined in | The pledge MUST reply with a status telemetry message as defined in | |||
| section 5.9.4 of [RFC8995]. As for the other objects, the defined | section 5.9.4 of [RFC8995]. As for the other objects, the enrollment | |||
| object is provided with an additional signature using JOSE. The | status object is provided with an additional signature using JOSE. | |||
| pledge generates the enrollment status and provides it in the | If the pledge verified the received LDevID EE certificate | |||
| response message to the registrar-agent. | successfully it SHALL sign the response using the LDevID of the | |||
| pledge as shown in Figure 16. In the failure case, the pledge SHALL | ||||
| use the available IdevID credentials. As the reason field is | ||||
| optional, it MAY be omitted in case of success. | ||||
| The response has the Content-Type "application/jose", signed using | The response has the Content-Type application/jose+json. | |||
| the freshly provided LDevID of the pledge as shown in Figure 16. As | ||||
| the reason field is optional, it MAY be omitted in case of success. | ||||
| { | { | |||
| "payload": { | "payload": { | |||
| "version": 1, | "version": 1, | |||
| "status": true, | "status": true, | |||
| "reason": "Informative human readable message", | "reason": "Informative human readable message", | |||
| "reason-context": { | "reason-context": { | |||
| "additional": "JSON" | "additional": "JSON" | |||
| } | } | |||
| }, | }, | |||
| "signatures": [ | "signatures": [ | |||
| { | { | |||
| "protected": { | "protected": { | |||
| "alg": "ES256", | "alg": "ES256", | |||
| "x5c": [ "MIIB2jCC...dA==" ] | "x5c": [ "base64encodedvalue==" ] | |||
| }, | }, | |||
| "signature": "base64encodedvalue==" | "signature": "base64encodedvalue==" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| Figure 16: Representation of pledge enroll status telemetry | ||||
| Figure 16: Representation of pledge enroll-status telemetry | ||||
| Once the registrar-agent has collected the information, it can | Once the registrar-agent has collected the information, it can | |||
| connect to the registrar agent to provide the status responses to the | connect to the registrar-agent to provide the status responses to the | |||
| registrar. | registrar. | |||
| 5.1.4.4. Telemetry status handling (registrar-agent - domain registrar) | 5.5.4. Telemetry status handling (registrar-agent - domain registrar) | |||
| The following description assumes that the registrar-agent has | The following description requires that the registrar-agent has | |||
| collected the status objects from the pledge. It will provide the | collected the status objects from the pledge. It SHALL provide the | |||
| status objects to the registrar for further processing and audit log | status objects to the registrar for further processing. | |||
| information of voucher-status for MASA. | ||||
| Preconditions in addition to Section 5.1.4.2: | Preconditions in addition to Section 5.5.2: | |||
| * Registrar-agent: possesses voucher-status and enroll-status | * Registrar-agent: possesses voucher status and enroll status | |||
| objects from pledge. | objects from pledge. | |||
| +-----------+ +-----------+ +--------+ +---------+ | +-----------+ +-----------+ +--------+ +---------+ | |||
| | Registrar | | Domain | | Domain | | Vendor | | | Registrar | | Domain | | Domain | | Vendor | | |||
| | Agent | | Registrar | | CA | | Service | | | Agent | | Registrar | | CA | | Service | | |||
| | RegAgt) | | (JRC) | | | | (MASA) | | | RegAgt) | | (JRC) | | | | (MASA) | | |||
| +-----------+ +-----------+ +--------+ +---------+ | +-----------+ +-----------+ +--------+ +---------+ | |||
| | | | Internet | | | | | Internet | | |||
| [voucher + enroll ] | | | | ||||
| [status objects avail.]| | | | ||||
| | | | | | | | | | | |||
| |<------ TLS ----->| | | | |<----- mTLS ----->| | | | |||
| | | | | | | | | | | |||
| |--Voucher-Status->| | | | |--Voucher Status->| | | | |||
| | |<---- device audit log ----| | | |<---- device audit log ----| | |||
| | [verify audit log ] | | [verify audit log ] | |||
| | | | | | | | | | | |||
| |--Enroll-Status-->| | | | |--Enroll Status-->| | | | |||
| | | | | | | | | | | |||
| | | | | | | | | | | |||
| Figure 17: Bootstrapping status handling | Figure 17: Bootstrapping status handling | |||
| The registrar-agent MUST provide the collected pledge voucher-status | The registrar-agent MUST provide the collected pledge voucher status | |||
| to the registrar. This status indicates if the pledge could process | object to the registrar. This status indicates if the pledge could | |||
| the voucher successfully or not. | process the voucher successfully or not. | |||
| If the TLS connection to the registrar was closed, the registrar- | If the TLS connection to the registrar was closed, the registrar- | |||
| agent establishes a TLS connection with the registrar as stated in | agent establishes a TLS connection with the registrar as stated in | |||
| Section 5.1.4.2. | Section 5.5.2. | |||
| The registrar-agent sends the pledge voucher-status object without | The registrar-agent sends the pledge voucher status object without | |||
| modification to the registrar with an HTTP-over-TLS POST using the | modification to the registrar with an HTTP-over-TLS POST using the | |||
| operation path value of "/.well-known/brski/voucher_status". The | registrar endpoint "/.well-known/brski/voucher_status". The Content- | |||
| Content-Type header is kept as "application/jose" as described in | Type header is kept as application/jose+json as described in | |||
| Figure 14 and depicted in the example in Figure 15. | Figure 14 and depicted in the example in Figure 15. | |||
| The registrar SHALL verify the signature of the pledge voucher-status | The registrar SHALL verify the signature of the pledge voucher status | |||
| and validate that it belongs to an accepted device in his domain | object and validate that it belongs to an accepted device in his | |||
| based on the contained "serial-number" in the IDevID certificate | domain based on the contained "serial-number" in the IDevID | |||
| referenced in the header of the voucher-status object. | certificate referenced in the header of the voucher status object. | |||
| According to [RFC8995] section 5.7, the registrar SHOULD respond with | According to [RFC8995] section 5.7, the registrar SHOULD respond with | |||
| an HTTP 200 but MAY simply fail with an HTTP 404 error. The | an HTTP 200 but MAY simply fail with an HTTP 404 error. The | |||
| registrar-agent may use the response to signal success / failure to | registrar-agent may use the response to signal success / failure to | |||
| the service technician operating the registrar agent. Within the | the service technician operating the registrar agent. Within the | |||
| server logs the server SHOULD capture this telemetry information. | server logs the server SHOULD capture this telemetry information. | |||
| The registrar SHOULD proceed with collecting and logging status | The registrar SHOULD proceed with collecting and logging status | |||
| information by requesting the MASA audit-log from the MASA service as | information by requesting the MASA audit-log from the MASA service as | |||
| described in section 5.8 of [RFC8995]. | described in section 5.8 of [RFC8995]. | |||
| The registrar-agent MUST provide the pledge's enroll-status object to | The registrar-agent MUST provide the pledge's enroll status object to | |||
| the registrar. The status indicates the pledge could process the | the registrar. The status indicates the pledge could process the | |||
| enroll-response object and holds the corresponding private key. | enroll-response object and holds the corresponding private key. | |||
| The registrar-agent sends the pledge enroll-status object without | The registrar-agent sends the pledge enroll status object without | |||
| modification to the registrar with an HTTP-over-TLS POST using the | modification to the registrar with an HTTP-over-TLS POST using the | |||
| operation path value of "/.well-known/brski/enrollstatus". The | registrar endpoint "/.well-known/brski/enrollstatus". The Content- | |||
| Content-Type header is kept as "application/jose" as described in | Type header is kept as application/jose+json as described in | |||
| Figure 14 and depicted in the example in Figure 16. | Figure 14 and depicted in the example in Figure 16. | |||
| The registrar SHALL verify the signature of the pledge enroll-status | The registrar SHALL verify the signature of the pledge enroll status | |||
| object and validate that it belongs to an accepted device in his | object. In case the enroll status object indicates success the | |||
| domain based on the contained product-serial-number in the LDevID EE | registrar SHALL validate that the pledge belongs to an accepted | |||
| certificate referenced in the header of the enroll-status object. | device in his domain based on the contained product-serial-number in | |||
| Note that the verification of a signature of the object is a | the LDevID EE certificate referenced in the header of the enroll | |||
| deviation form the described handling in section 5.9.4 of [RFC8995]. | status object. In case the enroll status object indicates a failure, | |||
| the pledge was unable to verify the received LDevID EE certificate | ||||
| and therefore signed the enroll status objects with its IDevID | ||||
| credential. Note that the verification of a signature of the object | ||||
| is a deviation from the described handling in section 5.9.4 of | ||||
| [RFC8995]. | ||||
| According to [RFC8995] section 5.9.4, the registrar SHOULD respond | According to [RFC8995] section 5.9.4, the registrar SHOULD respond | |||
| with an HTTP 200 but MAY simply fail with an HTTP 404 error. The | with an HTTP 200 but MAY simply fail with an HTTP 404 error. The | |||
| registrar-agent may use the response to signal success / failure to | registrar-agent may use the response to signal success / failure to | |||
| the service technician operating the registrar agent. Within the | the service technician operating the registrar agent. Within the | |||
| server log the registrar SHOULD capture this telemetry information. | server log the registrar SHOULD capture this telemetry information. | |||
| 6. Artifacts | 6. Artifacts | |||
| 6.1. Voucher Request Artifact | 6.1. Voucher Request Artifact | |||
| skipping to change at page 47, line 4 ¶ | skipping to change at page 48, line 19 ¶ | |||
| RFC 5280, Section 4, encoded using the ASN.1 | RFC 5280, Section 4, encoded using the ASN.1 | |||
| distinguished encoding rules (DER), as specified | distinguished encoding rules (DER), as specified | |||
| in ITU X.690. | in ITU X.690. | |||
| This certificate can be used by the pledge, | This certificate can be used by the pledge, | |||
| the registrar, and the MASA to verify the signature | the registrar, and the MASA to verify the signature | |||
| of agent-signed-data. It is an optional component | of agent-signed-data. It is an optional component | |||
| for the pledge-voucher request. | for the pledge-voucher request. | |||
| This MUST be populated in a registrar's | This MUST be populated in a registrar's | |||
| voucher-request when an agent-proximity assertion | voucher-request when an agent-proximity assertion | |||
| is requested. | is requested. | |||
| It is defined as list to enable inclusion of further | It is defined as list to enable inclusion of further | |||
| certificates along the certificate chain if different | certificates along the certificate chain if different | |||
| issuing CAs have been used for the registrar-agent | issuing CAs have been used for the registrar-agent | |||
| and the registrar."; | and the registrar."; | |||
| reference | reference | |||
| "ITU X.690: Information Technology - ASN.1 encoding | "ITU X.690: Information Technology - ASN.1 encoding | |||
| rules: Specification of Basic Encoding Rules (BER), | rules: Specification of Basic Encoding Rules (BER), | |||
| Canonical Encoding Rules (CER) and Distinguished | Canonical Encoding Rules (CER) and Distinguished | |||
| Encoding Rules (DER) | Encoding Rules (DER) | |||
| RFC 5280: Internet X.509 Public Key Infrastructure | RFC 5280: Internet X.509 Public Key Infrastructure | |||
| Certificate and Certificate Revocation List (CRL) | Certificate and Certificate Revocation List (CRL) | |||
| Profile"; | Profile"; | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| } | } | |||
| <CODE ENDS> | <CODE ENDS> | |||
| Examples for the pledge-voucher-request are provided in | Examples for the pledge-voucher-request are provided in | |||
| Section 5.1.4.2. | Section 5.5.2. | |||
| 7. IANA Considerations | 7. IANA Considerations | |||
| This document requires the following IANA actions: | This document requires the following IANA actions. | |||
| IANA is requested to enhance the Registry entitled: "BRSKI well-known | 7.1. BRSKI .well-known Registry | |||
| URIs" with the following: | ||||
| URI document description | IANA is requested to enhance the Registry entitled: "BRSKI Well-Known | |||
| pledge-voucher-request [THISRFC] create pledge-voucher-request | URIs" with the following endpoints: | |||
| pledge-enrollment-request [THISRFC] create pledge-enrollment-request | ||||
| pledge-voucher [THISRFC] supply voucher response | URI Description Reference | |||
| pledge-enrollment [THISRFC] supply enrollment response | pledge-voucher-request create pledge-voucher-request [THISRFC] | |||
| pledge-CACerts [THISRFC] supply CA certs to pledge | pledge-enrollment-request create pledge-enrollment-request [THISRFC] | |||
| requestenroll [THISRFC] supply PER to registrar | pledge-voucher supply voucher response [THISRFC] | |||
| pledge-enrollment supply enrollment response [THISRFC] | ||||
| pledge-CACerts supply CA certs to pledge [THISRFC] | ||||
| requestenroll supply PER to registrar [THISRFC] | ||||
| 8. Privacy Considerations | 8. Privacy Considerations | |||
| The credential used by the registrar-agent to sign the data for the | The credential used by the registrar-agent to sign the data for the | |||
| pledge in case of the pledge-initiator-mode should not contain | pledge in case of the pledge-initiator-mode should not contain | |||
| personal information. Therefore, it is recommended to use an LDevID | personal information. Therefore, it is recommended to use an LDevID | |||
| certificate associated with the device instead of a potential service | certificate associated with the device instead of a potential service | |||
| technician operating the device, to avoid revealing this information | technician operating the device, to avoid revealing this information | |||
| to the MASA. | to the MASA. | |||
| skipping to change at page 48, line 4 ¶ | skipping to change at page 49, line 23 ¶ | |||
| 8. Privacy Considerations | 8. Privacy Considerations | |||
| The credential used by the registrar-agent to sign the data for the | The credential used by the registrar-agent to sign the data for the | |||
| pledge in case of the pledge-initiator-mode should not contain | pledge in case of the pledge-initiator-mode should not contain | |||
| personal information. Therefore, it is recommended to use an LDevID | personal information. Therefore, it is recommended to use an LDevID | |||
| certificate associated with the device instead of a potential service | certificate associated with the device instead of a potential service | |||
| technician operating the device, to avoid revealing this information | technician operating the device, to avoid revealing this information | |||
| to the MASA. | to the MASA. | |||
| 9. Security Considerations | 9. Security Considerations | |||
| 9.1. Exhaustion Attack on Pledge | 9.1. Exhaustion Attack on Pledge | |||
| Exhaustion attack on pledge based on DoS attack (connection | Exhaustion attack on pledge based on DoS attack (connection | |||
| establishment, etc.) | establishment, etc.) | |||
| 9.2. Misuse of acquired Voucher and Enrollment responses by Registrar- | 9.2. Misuse of acquired Voucher and Enrollment objects by Registrar- | |||
| Agent | Agent | |||
| A Registrar-agent that uses acquired voucher and enrollment response | A Registrar-agent that uses acquired voucher and enrollment objects | |||
| for domain 1 in domain 2 can be detected by the pledge-voucher- | for domain-A in domain-B can be avoided by the pledge-voucher-request | |||
| request processing on the domain registrar side. This requires the | processing on the domain registrar side. This requires the domain | |||
| domain registrar to verify the proximity-registrar-cert leaf in the | registrar to verify the "proximity-registrar-cert" field in the | |||
| pledge-voucher-request against his own LDevID(Reg). In addition, the | pledge-voucher-request (PVR) against his own LDevID(Reg). In | |||
| domain registrar has to verify the association of the pledge to his | addition, the domain registrar has to verify the association of the | |||
| domain based on the product-serial-number contained in the pledge- | pledge to his domain based on the product-serial-number contained in | |||
| voucher-request and in the IDevID certificate of the pledge. | the pledge-voucher-request (PvR) and in the pledge IDevID | |||
| Moreover, the registrar verifies the authorization of the registrar | certificate. Moreover, the registrar verifies if the registrar-agent | |||
| agent to deliver pledge-voucher-requests, based on the LDevID(RegAgt) | is authorized to interact with the pledge for voucher-requests, based | |||
| EE certificate information contained in this request. | on the LDevID(RegAgt) EE certificate information contained in the | |||
| pledge-voucher-request (PVR). | ||||
| Misbinding of a pledge by a faked domain registrar is countered as | Misbinding of a pledge by a faked domain registrar is countered as | |||
| described in BRSKI security considerations (section 11.4). | described in BRSKI security considerations (section 11.4). | |||
| 9.3. Misuse of Registrar-Agent Credentials | 9.3. Misuse of Registrar-Agent Credentials | |||
| Concerns have been raised, that there may be opportunities to misuse | Concerns on opportunities to misuse the registrar-agent with a valid | |||
| the registrar-agent with a valid LDevID. This may be addressed by | LDevID, may be addressed by utilizing short-lived certificates (e.g., | |||
| utilizing short-lived certificates (e.g., valid for a day) to | valid for a day) to authenticate the registrar-agent against the | |||
| authenticate the registrar-agent against the domain registrar. The | domain registrar. The LDevID(RegAgt) certificate may be acquired by | |||
| LDevID certificate for the registrar-agent may be provided by a prior | a prior BRSKI run for the registrar-agent, if IDevID is available on | |||
| BRSKI execution based on an existing IDevID. Alternatively, the | registrar-agent. Alternatively, the LDevID may be acquired by a | |||
| LDevID may be acquired by a service technician after authentication | service technician from the domain PKI system. | |||
| against the issuing CA. | ||||
| In addition it is required that the LDevID(RegAgt) certificate is | ||||
| valid for the complete bootstrapping phase. This avoids a registrar- | ||||
| agent could be misused to create arbitrary "agent-signed-data" | ||||
| objects to perform an authorized bootstrapping of a rouge pledge. As | ||||
| "agent-signed-data" could be dated after the validity time of the | ||||
| LDevID(RegAgt) EE certificate, due to missing trusted timestamp in | ||||
| the registrar-agents signature. | ||||
| To address this, the registrar SHOULD verify the certificate used to | ||||
| create the signature on "agent-signed-data". Furthermore the | ||||
| registrar also verifies the LDevID(RegAgt) EE certificate used in the | ||||
| TLS handshake. If both certificates are successfully verified, the | ||||
| registrar-agents signature can be considered as valid. | ||||
| 9.4. YANG Module Security Considerations | 9.4. YANG Module Security Considerations | |||
| The enhanced voucher-request described in section Section 6.1 bases | The enhanced voucher-request described in section Section 6.1 is | |||
| on [RFC8995], but uses a different encoding, based on | bases on [RFC8995], but uses a different encoding based on | |||
| [I-D.ietf-anima-jws-voucher]. Therefore, similar considerations as | [I-D.ietf-anima-jws-voucher]. Therefore similar considerations as | |||
| described in Section 11.7 (Security Considerations) of [RFC8995] | described in Section 11.7 (Security Considerations) of [RFC8995] | |||
| apply. The YANG module specified in this document defines the schema | apply. The YANG module specified in this document defines the schema | |||
| for data that is subsequently encapsulated by a JOSE signed-data | for data that is subsequently encapsulated by a JOSE signed-data | |||
| content type, as described [I-D.ietf-anima-jws-voucher]. As such, | Content-type as described in [I-D.ietf-anima-jws-voucher]. As such, | |||
| all of the YANG-modeled data is protected from modification. The use | all of the YANG-modeled data is protected against modification. The | |||
| of YANG to define data structures, via the "yang-data" statement, is | use of YANG to define data structures via the "yang-data" statement, | |||
| relatively new and distinct from the traditional use of YANG to | is relatively new and distinct from the traditional use of YANG to | |||
| define an API accessed by network management protocols such as | define an API accessed by network management protocols such as | |||
| NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason, these | NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason these | |||
| guidelines do not follow the template described by Section 3.7 of | guidelines do not follow the template described by Section 3.7 of | |||
| [RFC8407]. | [RFC8407]. | |||
| 10. Acknowledgments | 10. Acknowledgments | |||
| We would like to thank the various reviewers, in particular Brian E. | We would like to thank the various reviewers, in particular Brian E. | |||
| Carpenter and Oskar Camenzind, for their input and discussion on use | Carpenter and Oskar Camenzind, for their input and discussion on use | |||
| cases and call flows. | cases and call flows. | |||
| 11. References | 11. References | |||
| skipping to change at page 49, line 14 ¶ | skipping to change at page 51, line 4 ¶ | |||
| guidelines do not follow the template described by Section 3.7 of | guidelines do not follow the template described by Section 3.7 of | |||
| [RFC8407]. | [RFC8407]. | |||
| 10. Acknowledgments | 10. Acknowledgments | |||
| We would like to thank the various reviewers, in particular Brian E. | We would like to thank the various reviewers, in particular Brian E. | |||
| Carpenter and Oskar Camenzind, for their input and discussion on use | Carpenter and Oskar Camenzind, for their input and discussion on use | |||
| cases and call flows. | cases and call flows. | |||
| 11. References | 11. References | |||
| 11.1. Normative References | 11.1. Normative References | |||
| [I-D.ietf-anima-jws-voucher] | [I-D.ietf-anima-jws-voucher] | |||
| Richardson, M. and T. Werner, "JWS signed Voucher | Richardson, M. and T. Werner, "JWS signed Voucher | |||
| Artifacts for Bootstrapping Protocols", Work in Progress, | Artifacts for Bootstrapping Protocols", Work in Progress, | |||
| Internet-Draft, draft-ietf-anima-jws-voucher-02, 4 March | Internet-Draft, draft-ietf-anima-jws-voucher-03, 7 March | |||
| 2022, <https://www.ietf.org/archive/id/draft-ietf-anima- | 2022, <https://www.ietf.org/archive/id/draft-ietf-anima- | |||
| jws-voucher-02.txt>. | jws-voucher-03.txt>. | |||
| [I-D.ietf-anima-rfc8366bis] | ||||
| Watsen, K., Richardson, M. C., Pritikin, M., Eckert, T., | ||||
| and Q. Ma, "A Voucher Artifact for Bootstrapping | ||||
| Protocols", Work in Progress, Internet-Draft, draft-ietf- | ||||
| anima-rfc8366bis-00, 31 January 2022, | ||||
| <https://www.ietf.org/archive/id/draft-ietf-anima- | ||||
| rfc8366bis-00.txt>. | ||||
| [I-D.ietf-netconf-sztp-csr] | [I-D.ietf-netconf-sztp-csr] | |||
| Watsen, K., Housley, R., and S. Turner, "Conveying a | Watsen, K., Housley, R., and S. Turner, "Conveying a | |||
| Certificate Signing Request (CSR) in a Secure Zero Touch | Certificate Signing Request (CSR) in a Secure Zero Touch | |||
| Provisioning (SZTP) Bootstrapping Request", Work in | Provisioning (SZTP) Bootstrapping Request", Work in | |||
| Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14, | Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14, | |||
| 2 March 2022, <https://www.ietf.org/archive/id/draft-ietf- | 2 March 2022, <https://www.ietf.org/archive/id/draft-ietf- | |||
| netconf-sztp-csr-14.txt>. | netconf-sztp-csr-14.txt>. | |||
| [I-D.richardson-anima-rfc8366bis] | ||||
| Watsen, K., Richardson, M. C., Pritikin, M., and T. | ||||
| Eckert, "A Voucher Artifact for Bootstrapping Protocols", | ||||
| Work in Progress, Internet-Draft, draft-richardson-anima- | ||||
| rfc8366bis-04, 1 December 2021, | ||||
| <https://www.ietf.org/archive/id/draft-richardson-anima- | ||||
| rfc8366bis-04.txt>. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | |||
| and A. Bierman, Ed., "Network Configuration Protocol | and A. Bierman, Ed., "Network Configuration Protocol | |||
| (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | |||
| <https://www.rfc-editor.org/info/rfc6241>. | <https://www.rfc-editor.org/info/rfc6241>. | |||
| skipping to change at page 50, line 47 ¶ | skipping to change at page 52, line 34 ¶ | |||
| DOI 10.17487/RFC8407, October 2018, | DOI 10.17487/RFC8407, October 2018, | |||
| <https://www.rfc-editor.org/info/rfc8407>. | <https://www.rfc-editor.org/info/rfc8407>. | |||
| [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., | [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., | |||
| and K. Watsen, "Bootstrapping Remote Secure Key | and K. Watsen, "Bootstrapping Remote Secure Key | |||
| Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, | Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, | |||
| May 2021, <https://www.rfc-editor.org/info/rfc8995>. | May 2021, <https://www.rfc-editor.org/info/rfc8995>. | |||
| 11.2. Informative References | 11.2. Informative References | |||
| [BRSKI-PRM-abstract] | ||||
| "Abstract BRSKI-PRM Protocol Overview", April 2022, | ||||
| <https://raw.githubusercontent.com/anima-wg/anima-brski- | ||||
| prm/main/pics/brski_prm_overview.png>. | ||||
| [IEEE-802.1AR] | [IEEE-802.1AR] | |||
| Institute of Electrical and Electronics Engineers, "IEEE | Institute of Electrical and Electronics Engineers, "IEEE | |||
| 802.1AR Secure Device Identifier", IEEE 802.1AR, June | 802.1AR Secure Device Identifier", IEEE 802.1AR, June | |||
| 2018. | 2018. | |||
| [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification | [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification | |||
| Request Syntax Specification Version 1.7", RFC 2986, | Request Syntax Specification Version 1.7", RFC 2986, | |||
| DOI 10.17487/RFC2986, November 2000, | DOI 10.17487/RFC2986, November 2000, | |||
| <https://www.rfc-editor.org/info/rfc2986>. | <https://www.rfc-editor.org/info/rfc2986>. | |||
| [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
| Housley, R., and W. Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, "Internet X.509 Public Key | |||
| Infrastructure Certificate and Certificate Revocation List | Infrastructure Certificate and Certificate Revocation List | |||
| (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | |||
| <https://www.rfc-editor.org/info/rfc5280>. | <https://www.rfc-editor.org/info/rfc5280>. | |||
| [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", | ||||
| RFC 8152, DOI 10.17487/RFC8152, July 2017, | ||||
| <https://www.rfc-editor.org/info/rfc8152>. | ||||
| [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", | [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", | |||
| BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, | BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, | |||
| <https://www.rfc-editor.org/info/rfc8340>. | <https://www.rfc-editor.org/info/rfc8340>. | |||
| Appendix A. History of Changes [RFC Editor: please delete] | Appendix A. History of Changes [RFC Editor: please delete] | |||
| From IETF draft 02 -> IETF draft 03: | ||||
| * Updated examples to state "base64encodedvalue==" for x5c | ||||
| occurrences | ||||
| * Include link to SVG graphic as general overview | ||||
| * Restructuring of section 5 to flatten hierarchy | ||||
| * Enhanced requirements and motivation in Section 4 | ||||
| * Several editorial improvements based on review comments | ||||
| From IETF draft 01 -> IETF draft 02: | From IETF draft 01 -> IETF draft 02: | |||
| * Issue #15 included additional signature on voucher from registrar | * Issue #15 included additional signature on voucher from registrar | |||
| in section Section 5.1.4.2 and section Section 5.1.1 The | in section Section 5.5.2 and section Section 5.2 The verification | |||
| verification of multiple signatures is described in section | of multiple signatures is described in section Section 5.5.3 | |||
| Section 5.1.4.3 | ||||
| * Included representation for General JWS JSON Serialization for | * Included representation for General JWS JSON Serialization for | |||
| examples | examples | |||
| * Included error responses from pledge if it is not able to create a | * Included error responses from pledge if it is not able to create a | |||
| pledge-voucher request or an enrollment request in section | pledge-voucher request or an enrollment request in section | |||
| Section 5.1.4.1 | Section 5.5.1 | |||
| * Removed open issue regarding handling of multiple CSRs and | * Removed open issue regarding handling of multiple CSRs and | |||
| enrollment responses during the bootstrapping as the initial | enrollment responses during the bootstrapping as the initial | |||
| target it the provisioning of a generic LDevID certificate. The | target it the provisioning of a generic LDevID certificate. The | |||
| defined endpoint on the pledge may also be used for management of | defined endpoint on the pledge may also be used for management of | |||
| further certificates. | further certificates. | |||
| From IETF draft 00 -> IETF draft 01: | From IETF draft 00 -> IETF draft 01: | |||
| * Issue #15 lead to the inclusion of an option for an additional | * Issue #15 lead to the inclusion of an option for an additional | |||
| signature of the registrar on the voucher received from the MASA | signature of the registrar on the voucher received from the MASA | |||
| before forwarding to the registrar-agent to support verification | before forwarding to the registrar-agent to support verification | |||
| of POP of the registrars private key in section Section 5.1.4.2 | of POP of the registrars private key in section Section 5.5.2 and | |||
| and Section 5.1.4.3. | Section 5.5.3. | |||
| * Based on issue #11, a new endpoint was defined for the registrar | * Based on issue #11, a new endpoint was defined for the registrar | |||
| to enable delivery of the wrapped enrollment request from the | to enable delivery of the wrapped enrollment request from the | |||
| pledge (in contrast to plain PKCS#10 in simple enroll). | pledge (in contrast to plain PKCS#10 in simple enroll). | |||
| * Decision on issue #8 to not provide an additional signature on the | * Decision on issue #8 to not provide an additional signature on the | |||
| enrollment-response object by the registrar. As the enrollment | enrollment-response object by the registrar. As the enrollment | |||
| response will only contain the generic LDevID EE certificate. | response will only contain the generic LDevID EE certificate. | |||
| This credential builds the base for further configuration outside | This credential builds the base for further configuration outside | |||
| the initial enrollment. | the initial enrollment. | |||
| skipping to change at page 52, line 28 ¶ | skipping to change at page 54, line 40 ¶ | |||
| * Housekeeping: Removed already addressed open issues stated in the | * Housekeeping: Removed already addressed open issues stated in the | |||
| draft directly. | draft directly. | |||
| * Reworked text in from introduction to section pledge-responder- | * Reworked text in from introduction to section pledge-responder- | |||
| mode | mode | |||
| * Fixed "serial-number" encoding in PVR/RVR | * Fixed "serial-number" encoding in PVR/RVR | |||
| * Added prior-signed-voucher-request in the parameter description of | * Added prior-signed-voucher-request in the parameter description of | |||
| the registrar-voucher-request in Section 5.1.4.2. | the registrar-voucher-request in Section 5.5.2. | |||
| * Note added in Section 5.1.4.2 if sub-CAs are used, that the | * Note added in Section 5.5.2 if sub-CAs are used, that the | |||
| corresponding information is to be provided to the MASA. | corresponding information is to be provided to the MASA. | |||
| * Inclusion of limitation section (pledge sleeps and needs to be | * Inclusion of limitation section (pledge sleeps and needs to be | |||
| waked up. Pledge is awake but registrar-agent is not available) | waked up. Pledge is awake but registrar-agent is not available) | |||
| (Issue #10). | (Issue #10). | |||
| * Assertion-type aligned with voucher in RFC8366bis, deleted related | * Assertion-type aligned with voucher in RFC8366bis, deleted related | |||
| open issues. (Issue #4) | open issues. (Issue #4) | |||
| * Included table for endpoints in Section 5.1.2 for better | * Included table for endpoints in Section 5.3 for better | |||
| readability. | readability. | |||
| * Included registrar authorization check for registrar-agent during | * Included registrar authorization check for registrar-agent during | |||
| TLS handshake in section Section 5.1.4.2. Also enhanced figure | TLS handshake in section Section 5.5.2. Also enhanced figure | |||
| Figure 10 with the authorization step on TLS level. | Figure 10 with the authorization step on TLS level. | |||
| * Enhanced description of registrar authorization check for | * Enhanced description of registrar authorization check for | |||
| registrar-agent based on the agent-signed-data in section | registrar-agent based on the agent-signed-data in section | |||
| Section 5.1.4.2. Also enhanced figure Figure 10 with the | Section 5.5.2. Also enhanced figure Figure 10 with the | |||
| authorization step on pledge-voucher-request level. | authorization step on pledge-voucher-request level. | |||
| * Changed agent-signed-cert to an array to allow for providing | * Changed agent-signed-cert to an array to allow for providing | |||
| further certificate information like the issuing CA cert for the | further certificate information like the issuing CA cert for the | |||
| LDevID(RegAgt) EE certificate in case the registrar and the | LDevID(RegAgt) EE certificate in case the registrar and the | |||
| registrar-agent have different issuing CAs in Figure 10 (issue | registrar-agent have different issuing CAs in Figure 10 (issue | |||
| #12). This also required changes in the YANG module in | #12). This also required changes in the YANG module in | |||
| Section 6.1.2 | Section 6.1.2 | |||
| * Addressed YANG warning (issue #1) | * Addressed YANG warning (issue #1) | |||
| skipping to change at page 53, line 43 ¶ | skipping to change at page 56, line 6 ¶ | |||
| * Utilized ietf-voucher-request-async instead of ietf-voucher- | * Utilized ietf-voucher-request-async instead of ietf-voucher- | |||
| request in voucher exchanges to utilize the enhanced voucher- | request in voucher exchanges to utilize the enhanced voucher- | |||
| request. | request. | |||
| * Included changes from draft-ietf-netconf-sztp-csr-06 regarding the | * Included changes from draft-ietf-netconf-sztp-csr-06 regarding the | |||
| YANG definition of csr-types into the enrollment request exchange. | YANG definition of csr-types into the enrollment request exchange. | |||
| From IETF draft 02 -> IETF draft 03: | From IETF draft 02 -> IETF draft 03: | |||
| * Housekeeping, deleted open issue regarding YANG voucher-request in | * Housekeeping, deleted open issue regarding YANG voucher-request in | |||
| Section 5.1.4.1 as voucher-request was enhanced with additional | Section 5.5.1 as voucher-request was enhanced with additional | |||
| leaf. | leaf. | |||
| * Included open issues in YANG model in Section 5.1 regarding | * Included open issues in YANG model in Section 5.1 regarding | |||
| assertion value agent-proximity and csr encapsulation using SZTP | assertion value agent-proximity and csr encapsulation using SZTP | |||
| sub module). | sub module). | |||
| From IETF draft 01 -> IETF draft 02: | From IETF draft 01 -> IETF draft 02: | |||
| * Defined call flow and objects for interactions in UC2. Object | * Defined call flow and objects for interactions in UC2. Object | |||
| format based on draft for JOSE signed voucher artifacts and | format based on draft for JOSE signed voucher artifacts and | |||
| aligned the remaining objects with this approach in Section 5.1.4 | aligned the remaining objects with this approach in Section 5.5 . | |||
| . | ||||
| * Terminology change: issue #2 pledge-agent -> registrar-agent to | * Terminology change: issue #2 pledge-agent -> registrar-agent to | |||
| better underline agent relation. | better underline agent relation. | |||
| * Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode | * Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode | |||
| and pledge-responder-mode to better address the pledge operation. | and pledge-responder-mode to better address the pledge operation. | |||
| * Communication approach between pledge and registrar-agent changed | * Communication approach between pledge and registrar-agent changed | |||
| by removing TLS-PSK (former section TLS establishment) and | by removing TLS-PSK (former section TLS establishment) and | |||
| associated references to other drafts in favor of relying on | associated references to other drafts in favor of relying on | |||
| skipping to change at page 54, line 35 ¶ | skipping to change at page 56, line 44 ¶ | |||
| * Recommendation regarding short-lived certificates for registrar- | * Recommendation regarding short-lived certificates for registrar- | |||
| agent authentication towards registrar (issue #7) in the security | agent authentication towards registrar (issue #7) in the security | |||
| considerations. | considerations. | |||
| * Introduction of reference to agent signing certificate using SKID | * Introduction of reference to agent signing certificate using SKID | |||
| in agent signed data (issue #11). | in agent signed data (issue #11). | |||
| * Enhanced objects in exchanges between pledge and registrar-agent | * Enhanced objects in exchanges between pledge and registrar-agent | |||
| to allow the registrar to verify agent-proximity to the pledge | to allow the registrar to verify agent-proximity to the pledge | |||
| (issue #1) in Section 5.1.4. | (issue #1) in Section 5.5. | |||
| * Details on trust relationship between registrar-agent and pledge | * Details on trust relationship between registrar-agent and pledge | |||
| (issue #5) included in Section 5.1. | (issue #5) included in Section 5.1. | |||
| * Split of use case 2 call flow into sub sections in Section 5.1.4. | * Split of use case 2 call flow into sub sections in Section 5.5. | |||
| From IETF draft 00 -> IETF draft 01: | From IETF draft 00 -> IETF draft 01: | |||
| * Update of scope in Section 3.1 to include in which the pledge acts | * Update of scope in Section 3.1 to include in which the pledge acts | |||
| as a server. This is one main motivation for use case 2. | as a server. This is one main motivation for use case 2. | |||
| * Rework of use case 2 in Section 5.1 to consider the transport | * Rework of use case 2 in Section 5.1 to consider the transport | |||
| between the pledge and the pledge-agent. Addressed is the TLS | between the pledge and the pledge-agent. Addressed is the TLS | |||
| channel establishment between the pledge-agent and the pledge as | channel establishment between the pledge-agent and the pledge as | |||
| well as the endpoint definition on the pledge. | well as the endpoint definition on the pledge. | |||
| End of changes. 222 change blocks. | ||||
| 635 lines changed or deleted | 739 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||