< 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/