Draft: draft-ietf-anima-brski-prm

Commentary: These proposed changes are mostly typos , with a few places where sentences were re - organized to make them less awkward . There should be no technical content changes , but rewording should be double checked . Diagrams were marked with aasvg so they look cool in the HTML output , and slightly tweaked to produce better SVG . There could still be some useful changes to the diagrams . A table was turned from artwork into a markdown table , which also allows for the forward references to be done by reference rather than literally .
This document defines enhancements to bootstrapping a remote secure
key infrastructure (BRSKI, RFC8995) to facilitate bootstrapping in
domains featuring no or only timely limited connectivity between a
pledge and the domain registrar.  It specifically targets situations,
in which the interaction model changes from a pledge-initiator-mode,
as used in BRSKI, to a pledge-responder-mode as described in this
document.  To support both, BRSKI-PRM introduces a new registrar-
agent component, which facilitates the communication between pledge
and registrar during the bootstrapping phase.  For the establishment
of a trust relation between pledge and domain registrar, BRSKI-PRM
relies on the exchange of authenticated self-contained objects
(signature-wrapped objects).  The defined approach is agnostic
regarding the utilized enrollment protocol, deployed by the domain
registrar to communicate with the Domain CA.
This document defines enhancements to bootstrapping a remote secure
key infrastructure (BRSKI, RFC8995) to facilitate bootstrapping in
domains featuring no or only time limited connectivity between a
pledge and the domain registrar.  It specifically targets situations,
in which the interaction model changes from a pledge-initiated-mode,
as used in BRSKI, to a pledge-responding-mode as described in this
document.  To support both, BRSKI-PRM introduces a new component, the
registrar-agent, which facilitates the communication between pledge
and registrar during the bootstrapping phase.  To establishment the
trust relation between pledge and domain registrar, BRSKI-PRM relies
on the exchange of authenticated self-contained objects -- object
security rather than transport security.
The approach defined here is agnostic with respect to the underlying
enrollment protocol which connects the pledge, and domain registrar
to the Domain CA.
BRSKI addresses scenarios in which the pledge acts as client for the
bootstrapping and is the initiator of the bootstrapping (this
document refers to the approach as pledge-initiator-mode).  In
industrial environments the pledge may behave as a server and thus
does not initiate the bootstrapping with the domain registrar.  In
this scenarios it is expected that the pledge will be triggered to
generate requests to be bootstrapped in the customer site/domain
(this document refers to the approach as pledge-responder-mode).  For
this, an additional component is introduced acting as an agent for
the domain registrar (registrar-agent) towards the pledge.  This may
be a functionality of a commissioning or configuration tool or it may
be even co-located with the registrar.
BRSKI addresses scenarios in which the pledge acts as client for the
bootstrapping and is the initiator of the bootstrapping (this
document refers to the approach as pledge-initiator-mode).  In
industrial environments the pledge may behave as a server and thus
does not initiate the bootstrapping with the domain registrar.  In
this scenarios it is expected that the pledge will be triggered to
generate requests for bootstrapped in the customer site/domain.  This
document refers to the approach as pledge-responder-mode.  For this,
an additional component is introduced to act as an agent for the
domain registrar.  This new registrar-agent, initiates towards the
pledge.  This may be included in the functionality of a commissioning
or configuration tool or it may be even co-located with the
registrar.
introducing the registrar-agent as new component to facilitate the
communication between the pledge and the registrar, if the pledge
is in responder mode (acting as server).
The goal is to enhance BRSKI to support pledges in responder mode.
introducing the registrar-agent as new component to facilitate the
communication between the pledge and the registrar, as the pledge
is in responder mode, and acts as server.
allowing to utilize credentials different from the pledge's IDevID
to establish a TLS connection to the domain registrar, which is
necessary in case of using a registrar-agent.
For the enrollment of devices BRSKI relies on EST RFC7030 to request
and distribute customer site/domain specific device certificates.
EST in turn relies on a binding of the certification request to an
underlying TLS connection between the EST client and the EST server.
According to BRSKI the domain registrar acts as EST server and is
also acting as registration authority (RA) for its domain.  To
utilize the EST server endpoints on the domain-registrar, the
registrar-agent defined in this document will act as client towards
the domain registrar.  The registrar-agent will also act as client
when communicating with the pledge in responder mode.  Here, TLS with
server-side, certificate-based authentication is not directly
applicable, as the pledge only possesses an IDevID certificate, which
does not contain a subject alternative name (SAN) for the customer
site/domain and does also not contain a TLS server flag.  This is one
reason for relying on higher layer security by using signature
wrapped objects for the exchange between the pledge and the registrar
agent.  A further reason is the application on different transports,
for which TLS may not be available, like Bluetooth or NFC.  Instead
of using TLS to provide secure transport between the pledge and the
registrar-agent, BRSKI-PRM will rely on an additional wrapping
signature of the enrollment request by the pledge.  For EST RFC7030
the registrar then needs to do additional pre-processing by verifying
this signature, which is not present in EST.
having the registrar-agent utilize credentials different from the
pledge's IDevID when establishing a TLS connection to the domain
registrar.
For the enrollment of devices, BRSKI relies on EST RFC7030 to request
and distribute customer site/domain specific device certificates.
EST in turn relies on a binding of the certification request to an
underlying TLS connection between the EST client and the EST server.
According to BRSKI the domain registrar, acting as an EST server, is
therefore in the role of registration authority (RA) for its domain.
To utilize the EST server endpoints on the domain-registrar, the
registrar-agent defined in this document will act as client towards
the domain registrar.
The registrar-agent also acts as a client when communicating with a
pledge in responder mode.  Here, TLS with server-side, certificate-
based authentication is not directly applicable, as the pledge only
possesses an IDevID certificate.  The IDevID does not contain any
anchor for which any kind of RFC6125 validation can be done.  Second,
the registrar-agent may not even have a list of manufacturer trust
anchors that would be able to validate the IDevID.  Finally, IDevID
are not typically given Exteded Key Usage (EKU) TLS WWW Server
authentication usage.
The inability to effectively do TLS in responder mode is one reason
for relying on object security.
A further reason is the application on different transports, for
which TLS may not be available, such as Bluetooth and NFC.
So, instead of using TLS to provide secure transport between the
pledge and the registrar-agent, BRSKI-PRM relies on an addition
wrapped signature of the enrollment request by the pledge.  For EST
RFC7030 the registrar then needs to do additional pre-processing by
verifying this signature, which is not present in EST.
This document includes many examples that would contain many long
sequences of base64 encoded objects with no content directly
comprehendable to a human reader.  In order to keep them readable the
examples use the token "base64encodedvalue==" whenever such a thing
occurs.  This token is in fact valid base64.  The full examples are
in appendix.
BRSKI-PRM is applicable to environments where pledges may have
different behavior: pledge-responder-mode, or pledges may have no
direct connection to the domain registrar.  Either way pledges are
expected to be managed by the same registrar.  This can be motivated
by pledges deployed in environments not yet connected to the
operational customer site/domain network, e.g., at construction time.
Another environment relates to the assembly of cabinets, which are
prepared in advance to be installed on a customer site/domain.  As
there is no direct connection to the registrar available in these
environments the solution specified allows the pledges to act in a
server role so they can be triggered for bootstrapping e.g., by a
commissioning tool.  As BRSKI focuses on the pledge in a client role,
initiating the bootstrapping (pledge-initiator-mode), BRSKI-PRM
defines pledges acting as a server (pledge-responder-mode) responding
to PVR and PER and consumption of the results.
While BRSKI-PRM defines support for pledges in responder mode, there
may be pledges, which can act in both modes, initiator and responder.
In these cases BRSKI-PRM can be combined with BRSKI as defined in
RFC8995 or BRSKI-AE I-D.ietf-anima-brski-ae to allow for more
bootstrapping flexibility.  Once a pledge with such combined
functionality has been bootstrapped, it may act as client for
enrollment or re-enrollment of further certificates needed, e.g.,
using the enrollment protocol of choice.  If it still acts as server,
the defined endpoints can be used to trigger a PER for further
certificates.
BRSKI-PRM is applicable to environments where pledges may have
different behavior: pledge-responder-mode, or pledges may have no
direct connection to the domain registrar.  Either way pledges are
expected to be managed by the same registrar.
This can be motivated by pledges deployed in environments not yet
connected to the operational customer site/domain network, e.g., at a
construction site where a building is going up.
Another environment relates to the assembly of cabinets, which are
prepared in advance to be installed on a customer site/domain.
As there is no direct connection to the registrar available in these
environments the solution specified allows the pledges to act in a
server role so they can be triggered for bootstrapping e.g., by a
commissioning tool.
As BRSKI focuses on the pledge in a client role, initiating the
bootstrapping (pledge-initiated-mode), BRSKI-PRM defines pledges
acting as a server (pledge-responder-mode) responding to PVR and PER
and consumption of the results.
While BRSKI-PRM defines support for pledges in responder mode, there
may be pledges, which can act as both initiator or responder.  In
these cases BRSKI-PRM can be combined with BRSKI as defined in
RFC8995 or BRSKI-AE I-D.ietf-anima-brski-ae to allow for more
bootstrapping flexibility.
A pledge which can initiate, SHOULD listen for BRSKI messages as
describe in RFC8995.  Upon discovery of a potential Registrar, it
SHOULD initiate to that Registrar.  At the same time (so as to avoid
the Slowloris-attack described in RFC8995), it SHOULD also respond to
the pledge-responder-mode connections described in this document.
Once a pledge with such combined functionality has been bootstrapped,
it may act as client for enrollment or re-enrollment of further
certificates needed, e.g., using the enrollment protocol of choice.
If it still acts as server, the defined endpoints can be used to
trigger a Pledge-Enrollment-Request (PER) for further certificates.
In building automation a typical use case exists where a detached
building (or a cabinet) or the basement of a building is equipped
with sensors, actuators and controllers, but with only limited or no
connection to the central building management system.  This limited
connectivity may exist during installation time or also during
operation time.  During the installation in the basement, a service
technician collects the device specific information from the basement
network and provides them to the central building management system,
e.g., using a laptop or a mobile device to transport the information.
In building automation a typical use case exists where a detached
building (or a cabinet) or the basement of a building is equipped
with sensors, actuators and controllers, but with only limited or no
connection to the central building management system.  This limited
connectivity may exist during installation time or also during
operation time.
During the installation, for instance, in the basement, a service
technician collects the device specific information from the basement
network and provides them to the central building management system.
This could be done using a laptop, common mobile device, or dedicated
commissioning tool to transport the information.  The service
technician may visit every new house in a subdivision collecting
device specific information before connecting to the Registrar.
The mechanism described in this document presume the availability of
the pledge to communicate with the registrar-agent.
This may not be possible in constrained environments where, in
particular, power must be conserved.
In these situations, it is anticipated that the transceiver will be
powered down most of the time.
This presents a rendezvous problem: the pledge is unavailable for
certain periods of time, and the registrar-agent is similarly
presumed to be unavailable for certain periods of time.
The mechanism described in this document presume the availability of
the pledge to communicate with the registrar-agent.  This may not be
possible in constrained environments where, in particular, power must
be conserved.  In these situations, it is anticipated that the
transceiver will be powered down most of the time.  This presents a
rendezvous problem: the pledge is unavailable for certain periods of
time, and the registrar-agent is similarly presumed to be unavailable
for certain periods of time.
To facilitate the communication between a pledge in responder mode
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 requests for voucher and enrollment.  These requests
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.
To facilitate the communication between a pledge in responder mode
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 new
component, the registrar-agent, acts as an agent of the registrar
to trigger the pledge to generate requests for voucher and
enrollment.  These requests are than to be provided by the
registrar-agent to the registrar.  This requires the definition of
endpoints on the pledge to interact with.
The communication between the registrar-agent and the pledge MUST
not rely on transport layer security (TLS) because the pledge does
not have a that can easily be verified by RFC6125 methods.  It is
also more difficult to use TLS over other technology stacks (e.g.,
BTLE).
The use authenticated self-contained objects provides a work
around for both the TLS challenges, and the technology stack
challenge.
By contrast, the registrar-agent can 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.
It would be inaccurate for the voucher request and voucher
response to use an assertion with value "proximity" in the
voucher, as the pledge was not in direct contact with the
registrar for bootstrapping.  Therefore a new "agent-proximity"
assertion value is necessary for distinguishing assertions the
MASA can state.
Certification requests are data structures containing the
information from a requester for a CA to create a certificate.
The certification request format in BRSKI is PKCS#10 RFC2986.  In
PKCS#10, the structure is signed to ensure integrity protection
and proof of possession of the private key of the requester that
corresponds to the contained public key.  In the application
examples, this POP alone is not sufficient.  POI is also required
for the certification request and therefore needs to be
additionally bound to the existing credential of the pledge
(IDevID).  This binding supports the authorization decision for
the certification request through a proof of identity (POI).  The
binding of data origin authentication or POI to the certification
request may be provided directly by with the certification
request.  While BRSKI uses the binding to TLS, BRSKI-PRM aims at
an additional signature of the PKCS#10 using existing credentials
on the pledge (IDevID).  This ensures independence of the selected
transport.
Certification requests are data structures containing the
information from a requester for a CA to create a certificate.
The certification request format in BRSKI is PKCS#10 RFC2986.  In
PKCS#10, the structure is signed to ensure integrity protection
and proof of possession of the private key of the requester that
corresponds to the contained public key.  In the application
examples, this POP alone is not sufficient.  A Proof of Identity
(POI) is also required for the certification request and therefore
needs to be additionally bound to the existing credential of the
pledge (IDevID).  This binding supports the authorization decision
for the certification request through a proof of identity (POI).
The binding of data origin authentication or POI to the
certification request may be provided directly by with the
certification request.  While BRSKI uses the binding to TLS,
BRSKI-PRM aims at an additional signature of the PKCS#10 using
existing credentials on the pledge (IDevID).  This allows the
process to be independent of the selected transport.
For BRSKI with pledge in responder mode, the base system architecture
defined in BRSKI RFC8995 is enhanced to facilitate the new use cases.
The pledge-responder-mode allows delegated bootstrapping using a
registrar-agent instead of a direct connection between the pledge and
the domain registrar.  The communication model between registrar-
agent and pledge in this document assumes that the pledge is acting
as server and responds to requests.
For BRSKI with pledge in responder mode, the base system architecture
defined in BRSKI RFC8995 is enhanced to facilitate the new use cases.
The pledge-responder-mode allows delegated bootstrapping using a
registrar-agent instead of a direct connection between the pledge and
the domain registrar.  As indicated above, the communication model
between registrar-agent and pledge assumes that the pledge acts as
server and responds to requests.
For authentication to the domain registrar, the registrar-agent uses
its LDevID(RegAgt).  The provisioning of the registrar-agent LDevID
is out of scope for this document, but may be done in advance using a
separate BRSKI run or by other means like configuration.
It is recommended to use short lived registrar-agent LDevIDs in the
range of days or weeks as outlined in sec_cons_reg-agt.
If a registrar detects a request that 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 LDevID(RegAgt) certificate.
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.
For authentication to the domain registrar, the registrar-agent uses
its LDevID(RegAgt).  The provisioning of the registrar-agent LDevID
is out of scope for this document, but may be done in advance using a
separate BRSKI run or by other means like configuration.  It is
recommended to use short lived registrar-agent LDevIDs in the range
of days or weeks as outlined in sec_cons_reg-agt.
If a registrar detects a request that 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 LDevID(RegAgt) certificate.
Alternatively, the domain may feature a CA specifically for issuing
registrar-agent LDevID certificates.  This allows the registrar to
detect registrar-agents based on the issuing CA.
Order of exchanges in the call flow may be different as the
registrar-agent collects both, PVR and PER, at once and
provides them to the registrar.  This approach may also be used
to perform a bulk bootstrapping of several devices.
Order of exchanges in the call flow may be different as the
registrar-agent collects both, PVR and PER, at once and
provides them to the registrar.  This approach is used in order
to allow for bulk bootstrapping of several devices in a single
pass through a new site by the commissioning personnel.
Registrar-agent: provides a communication path to exchange data
objects between the pledge and the domain registrar.  The
registrar-agent brokers in situations, in which the domain
registrar is not directly reachable by the pledge, either due to a
different technology stack or due to missing connectivity.  The
registrar-agent triggers a pledge to create bootstrapping
artifacts such as voucher-request and enrollment-request on one or
multiple pledges and performs a (bulk) bootstrapping based on the
collected data.  The registrar-agent is expected to possess
information of the domain registrar (i.e., 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 the
registrar-agent as only authenticated self-contained objects are
used, which are transported via the registrar-agent and provided
either by the pledge or the registrar.  The trust assumption
between the registrar-agent and the registrar is based on the
LDevID of the registrar-agent, provided by the PKI responsible for
the domain.
This allows the registrar-agent to authenticate towards the
registrar, e.g., in a TLS handshake.  Based on this, the registrar
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.
Registrar-agent: provides a communication path to exchange data
objects between the pledge and the domain registrar.  The
registrar-agent brokers in situations in which the domain
registrar is not directly reachable by the pledge.  This may be
due to a different technology stack or due to missing
connectivity.  The registrar-agent triggers a pledge to create
bootstrapping artifacts such as the voucher-request and the
enrollment-request on one or multiple pledges and performs a
(bulk) bootstrapping based on the collected data.  The registrar-
agent is expected to possess information about the domain
registrar: the LDevID(Reg) certificate, LDevID(CA) certificate, IP
address, either by configuration or by using the discovery
mechanism defined in RFC8995.  There is no trust assumption
between the pledge and the registrar-agent as only authenticated
self-contained objects are used, which are transported via the
registrar-agent and provided either by the pledge or the
registrar.  The trust assumption between the registrar-agent and
the registrar is based on the LDevID of the registrar-agent,
provided by the PKI responsible for the domain.  This allows the
registrar-agent to authenticate towards the registrar, e.g., in a
TLS handshake.  Based on this, the registrar 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.
In contrast, "proximity" provides a statement, that the pledge was in
direct contact with the registrar and was able to verify proof-of-
possession of the private key in the context of the TLS handshake.
The provisionally accepted LDevID(Reg) certificate can be verified
after the voucher has been processed by the pledge.  As the returned
voucher includes an additional signature by the registrar, the pledge
can also verify that the registrar possesses the corresponding
private key.
In contrast to BRSKI the pledge acts as server.  It is triggered by
the registrar-agent for the generation of the PVR and PER as well as
for the processing of the responses and the generation of status
information.  Due to the use of the registrar-agent, the interaction
with the domain registrar is changed as shown in exchangesfig_uc2_1.
To enable interaction with the registrar-agent, the pledge provides
endpoints using the BRSKI defined endpoints based on the "/.well-
known/brski" URI tree.
In contrast to the above, "proximity" provides a statement, that the
pledge was in direct contact with the registrar and was able to
verify proof-of-possession of the private key in the context of the
TLS handshake.  The provisionally accepted LDevID(Reg) certificate
can be verified after the voucher has been processed by the pledge.
As the returned voucher includes an additional signature by the
registrar, the pledge can also verify that the registrar possesses
the corresponding private key.
In contrast to BRSKI the pledge acts as server.
This is triggered by the registrar-agent to generate the PVR and PER
as well as for the processing of the responses and the generation of
status information.  Due to the use of the registrar-agent, the
interaction with the domain registrar is changed as shown in
exchangesfig_uc2_1.  To enable interaction with the registrar-agent,
the pledge provides endpoints using the BRSKI defined endpoints based
on the "/.well-known/brski" URI tree.
The registrar-agent is expected to already possess an LDevID(RegAgt)
to authenticate to the domain registrar.  The registrar-agent will
use this LDevID(RegAgt) when establishing the TLS session with the
domain registrar for TLS client authentication.  The LDevID(RegAgt)
certificate MUST include a SubjectKeyIdentifier (SKID), which is used
as reference in the context of an agent-signed-data object as defined
in exchanges_uc2_1.  Note that this is an additional requirement for
issuing the certificate, as IEEE-802.1AR only requires the SKID to be
included for intermediate CA certificates.  In BRSKI-PRM, the SKID is
used in favor of a certificate fingerprint to avoid additional
computations.
Using an LDevID for TLS client authentication is a deviation from
RFC8995, in which the pledge's IDevID credential is used to perform
TLS client authentication.  The use of the LDevID(RegAgt) allows the
domain registrar to distinguish, if bootstrapping is initiated from a
pledge or from a registrar-agent and adopt the internal handling
accordingly.  As BRSKI-PRM uses authenticated self-contained data
objects between the pledge and the domain registrar, the binding of
the pledge identity to the requests is provided by the data object
signature employing the pledge's IDevID.  The objects exchanged
between the pledge and the domain registrar used in the context of
this specifications are JOSE objects.
In addition to the LDevID(RegAgt), the registrar-agent is provided
with the product-serial-numbers of the pledges to be bootstrapped.
This is necessary to allow the discovery of pledges by the registrar-
agent using mDNS.  The list may be provided by administrative means
or the registrar agent may get the information via an interaction
with the pledge.  For instance, RFC9238 describes scanning of a QR
code, the product-serial-number would be initialized from the 12N
B005 Product Serial Number.
The registrar-agent is expected to already possess an LDevID(RegAgt)
to authenticate to the domain registrar.  The registrar-agent will
use this LDevID(RegAgt) when establishing the TLS session with the
domain registrar for TLS client authentication.  The LDevID(RegAgt)
certificate MUST include a SubjectKeyIdentifier (SKID), which is used
as reference in the context of an agent-signed-data object as defined
in exchanges_uc2_1.  Note that this is an additional requirement for
issuing the certificate, as IEEE-802.1AR only requires the SKID to be
included for intermediate CA certificates.  (Note that RFC8995 makes
a similar requirement) In BRSKI-PRM, the SKID is used in favor of a
certificate fingerprint to avoid additional computations.
Using an LDevID for TLS client authentication of the registrar-agent
is a deviation from RFC8995, in which the pledge's IDevID credential
is used to perform TLS client authentication.  The use of the
LDevID(RegAgt) allows the domain registrar to distinguish, if
bootstrapping is initiated from a pledge or from a registrar-agent
and adopt different internal handling accordingly.  As BRSKI-PRM uses
authenticated self-contained data objects between the pledge and the
domain registrar, the binding of the pledge identity to the requests
is provided by the data object signature employing the pledge's
IDevID.  The objects exchanged between the pledge and the domain
registrar used in the context of this specifications are JOSE
objects.
In addition to the LDevID(RegAgt), the registrar-agent is provided
with the product-serial-numbers of the pledges to be bootstrapped.
This is necessary to allow the discovery of pledges by the registrar-
agent using mDNS (see discovery_uc2_ppa) The list may be provided by
administrative means or the registrar agent may get the information
via an interaction with the pledge.  For instance, RFC9238 describes
scanning of a QR code, the product-serial-number would be initialized
from the 12N B005 Product Serial Number.
The interaction of the pledge with the registrar-agent may be
accomplished using different transport means (protocols and or
network technologies).  For this document the usage of HTTP is
targeted as in BRSKI.  Alternatives may be CoAP, Bluetooth Low Energy
(BLE), or Nearfield Communication (NFC).  This requires independence
of the exchanged data objects between the pledge and the registrar
from transport security.  These transport means may differ from, and
are independent from, the ones used between the registrar-agent and
the registrar.  Therefore, authenticated self-contained objects
(here: signature-wrapped objects) are applied in the data exchange
between the pledge and the registrar.
The registrar-agent provides the domain-registrar certificate
(LDevID(Reg) certificate) to the pledge to be included into the
"agent-provided-proximity-registrar-certificate" leaf of the PVR.
This enables the registrar to verify, that it is the target registrar
for handling the request.  The registrar certificate may be
configured at the registrar-agent or may be fetched by the registrar-
agent based on a prior TLS connection establishment with the domain
registrar.  In addition, the registrar-agent provides agent-signed-
data containing the product-serial-number in the body, signed with
the LDevID(RegAgt).  This enables the registrar to verify and log,
which registrar-agent was in contact with the pledge, when verifying
the PVR.  Optionally the registrar-agent may provide its
LDevID(RegAgt) certificate (and optionally also the issuing CA
certificate) to the pledge to be used in the "agent-sign-cert"
component of the PVR.  If contained, the LDevID(RegAgt) certificate
MUST be the first certificate in the array.  Note, this may be
omitted in constraint environments to save bandwidth between the
registrar-agent and the pledge.  If not contained, the registrar MUST
fetch the LDevID(RegAgt) certificate based on the
SubjectKeyIdentifier (SKID) in the header of the agent-signed-data of
the PVR.  The registrar includes the LDevID(RegAgt) certificate
information into the RVR if the PVRs contains the assertion of
"agent-proximity".
The interaction of the pledge with the registrar-agent may be
accomplished using different transport means (protocols and or
network technologies).  For this document the usage of HTTP is
targeted as in BRSKI.  Alternatives may be CoAP, Bluetooth Low Energy
(BLE), or Nearfield Communication (NFC).  This transport independence
is enabled by the independence of the exchanged data objects from a
specific transport security.  These transport means may differ from,
and are independent from, the ones used between the registrar-agent
and the registrar.  Therefore, authenticated self-contained objects
(here: signature-wrapped objects) are applied in the data exchange
between the pledge and the registrar.
The registrar-agent provides the domain-registrar certificate
(LDevID(Reg) certificate) to the pledge to be included into the
"agent-provided-proximity-registrar-certificate" leaf of the PVR.
This enables the registrar to verify that it is the target registrar
for handling the request.
The registrar certificate may be configured at the registrar-agent or
may be fetched by the registrar-agent based on a prior TLS connection
establishment with the domain registrar.  In addition, the registrar-
agent provides agent-signed-data containing the product-serial-number
in the body, signed with the LDevID(RegAgt).  This enables the
registrar to verify and log, which registrar-agent was in contact
with the pledge, when verifying the PVR.
Optionally the registrar-agent may provide its LDevID(RegAgt)
certificate (and optionally also the issuing CA certificate) to the
pledge to be used in the "agent-sign-cert" component of the PVR.  If
contained, the LDevID(RegAgt) certificate MUST be the first
certificate in the array.  Note, this may be omitted in constraint
environments to save bandwidth between the registrar-agent and the
pledge.  If not included in the "agent-sign-cert", the registrar MUST
fetch the LDevID(RegAgt) certificate based on the
SubjectKeyIdentifier (SKID) in the header of the agent-signed-data of
the PVR.  The registrar includes the LDevID(RegAgt) certificate
information into the RVR if the PVRs contains the assertion of
"agent-proximity".
The MASA in turn verifies the LDevID(Reg) certificate is included in
the PVR (prior-signed-voucher-request) in the "agent-provided-
proximity-registrar-certificate" leaf and may assert in the voucher
"verified" or "logged" instead of "proximity", as there is no direct
connection between the pledge and the registrar.  In addition, the
MASA can provide the assertion "agent-proximity" as following.  If
the LDevID(RegAgt) certificate information is contained in the
"agent-sign-cert" component of the RVR, the MASA can verify the
signature of the agent-signed-data contained in the prior-signed-
voucher-request.  If both can be verified successfully, the MASA can
assert "agent-proximity" in the voucher.  Otherwise, it may assert
"verified" or "logged".  Depending on the MASA verification policy,
it may also respond with a suitable 4xx or 5xx status code as
described in section 5.6 of RFC8995.
The voucher can then be supplied via the registrar to the registrar-
agent.
The MASA in turn verifies the LDevID(Reg) certificate is included in
the PVR (prior-signed-voucher-request) in the "agent-provided-
proximity-registrar-certificate" leaf and may assert in the voucher
"verified" or "logged" instead of "proximity", as there is no direct
connection between the pledge and the registrar.
In addition, the MASA can provide the assertion "agent-proximity" as
follows: If the LDevID(RegAgt) certificate information is contained
in the "agent-sign-cert" component of the RVR, the MASA can verify
the signature of the agent-signed-data contained in the prior-signed-
voucher-request.  If both can be verified successfully, the MASA can
assert "agent-proximity" in the voucher.  Otherwise, it may assert
"verified" or "logged".  Depending on the MASA verification policy,
it may also respond with a suitable 4xx or 5xx status code as
described in section 5.6 of RFC8995.  The voucher can then be
supplied via the registrar to the registrar-agent.
Note that the registrar-agent may trigger the pledge for the PVR or
the PER or both.  It is expected that this will be aligned with a
service technician workflow doing the pledge installation.
Note that the registrar-agent may trigger the pledge for the PVR or
the PER or both.  It is expected that this will be aligned with a
service technician workflow, visiting and installing each pledge.
The pledge provisionally accepts the agent-provided-proximity-
registrar-cert and can verify it once it has received the voucher.
If the optionally agent-sign-cert data is included the pledge MAY
verify at least the signature of the agent-signed-data using the
first contained certificate, which is the LDevID(RegAgt) certificate.
If further certificates are contained in the agent-sign-cert, they
enable also the certificate chain validation.  The pledge may not
verify the agent-sign-cert itself as the domain trust has not been
established at this point of the communication.  It can be done,
after the voucher has been received.
The pledge provisionally accepts the agent-provided-proximity-
registrar-cert, as it can only verify it once it has received the
voucher.  If the agent-sign-cert (it is optional) data is included,
the pledge MAY verify at least the signature of the agent-signed-data
using the first contained certificate, which is the LDevID(RegAgt)
certificate.  If further certificates are contained in the agent-
sign-cert, they enable also the certificate chain validation of the
agent's certificate.  The pledge will be unable to verify the agent-
sign-cert chain itself as the domain trust has not been established
at this point of the communication.  It can be done, after the
voucher has been received.
nonce: SHALL contain a cryptographically strong random or pseudo-
random number.
nonce: SHALL contain a cryptographically strong pseudo-random
number.
agent-sign-cert: MAY contain the certificate or certificate chain
of the registrar-agent as array of base64encoded certificate
information.  It starts from the base64-encoded LDevID(RegAgt)
certificate optionally followed by the issuing CA certificate and
potential further certificates.  If supported, it MUST at least
contain the LDevID(RegAgt) certificate provided as trigger
parameter.
agent-sign-cert: MAY contain the certificate or certificate chain
of the registrar-agent as array of base64encoded certificate
information.  The first entry MUST be the base64-encoded
LDevID(RegAgt) certificate, MAY be optionally followed by the
issuing CA certificate and potential further certificates.
agent-sign-cert: MAY contain an array of base64-encoded
certificate data starting with the LDevID(RegAgt) certificate.  If
contained the registrar MUST verify that the LDevID(ReAgt)
certificate, used to sign the data, is still valid.  If the
certificate is already expired, the registrar SHALL reject the
request.  Validity of used signing certificates at the time of
signing the agent-signed-data is necessary to avoid that a rogue
registrar-agent generates agent-signed-data objects to onboard
arbitrary pledges at a later point in time, see also sec_cons_reg-
agt.
If the agent-signed-cert is not provided, the registrar MUST fetch
the LDevID(RegAgt) certificate, based on the provided
SubjectKeyIdentifier (SKID) contained in the kid header of the
agent-signed-data, and perform this verification.  This requires,
that the registrar can fetch the LDevID(RegAgt) certificate data
(including intermediate CA certificates if existent) based on the
SKID.
agent-sign-cert: MAY contain an array of base64-encoded
certificate data starting with the LDevID(RegAgt) certificate.  If
contained the registrar MUST verify that the LDevID(ReAgt)
certificate, used to sign the data, is still valid.  If the
certificate is already expired, the registrar SHALL reject the
request.  Validity of used signing certificates at the time of
signing the agent-signed-data is necessary to avoid that a rogue
registrar-agent generates agent-signed-data objects to onboard
arbitrary pledges at a later point in time, see also sec_cons_reg-
agt.  If the agent-signed-cert is not provided, the registrar MUST
fetch the LDevID(RegAgt) certificate, based on the provided
SubjectKeyIdentifier (SKID) contained in the kid header of the
agent-signed-data, and perform this verification.  This requires,
that the registrar can fetch the LDevID(RegAgt) certificate data
(including intermediate CA certificates if existent) based on the
SKID.
After verification the pledge MUST reply with a status telemetry
message as defined in section 5.7 of RFC8995.
The pledge generates the voucher status and provides it as JOSE
object with the wrapping signature in the response message to the
registrar-agent.
After verification the pledge MUST reply with a status telemetry
message as defined in section 5.7 of RFC8995.  The pledge generates
the voucher status and provides it as JOSE object with the wrapping
signature in the response message to the registrar-agent.
The following Concise Data Definition Language (CDDL) RFC8610
explains the structure of the format for the pledge-status request.
It is defined following the status telemetry definitions in BRSKI
RFC8995.  Consequently, format and semantics of pledge-status
requests below are for version 1.
The version field is included to permit significant changes to the
pledge-status request and response in the future.
A pledge or a registrar-agent that receives a pledge-status request
with a version larger than it knows about SHOULD log the contents and
alert a human.
The following Concise Data Definition Language (CDDL) RFC8610
explains the structure of the format for the pledge-status request.
It is defined following the status telemetry definitions in BRSKI
RFC8995.  Consequently, format and semantics of pledge-status
requests below are for version 1.  The version field is included to
permit significant changes to the pledge-status request and response
in the future.  A pledge or a registrar-agent that receives a pledge-
status request with a version larger than it knows about SHOULD log
the contents and alert a human.
The credential used by the registrar-agent to sign the data for the
pledge should not contain any personal information.  Therefore, it is
recommended to use an LDevID certificate associated with the device
instead of an LDevID certificate associated with a potential service
technician operating the device.  This avoids revealing personal
information to Registrar and MASA.
Pledge product-serial-number is contained in the trigger message
for the PVR and in all responses from the pledge.  This
information reveals the identity of the devices being bootstrapped
and allows deduction of products an operator is using in his
environment.  As the communication between the pledge and the
registrar-agent may be realized over wireless link, this
information could be easily be eavesdropped, if the wireless
interface does not apply security measures.
Timestamp data could reveal the activation time of the device.
Status data of the device could reveal information about the
current state of the device in the domain network.
The credential used by the registrar-agent to sign the data for the
pledge should not contain any personal information.  Therefore, it is
recommended to use an LDevID certificate associated with the
commissioning device instead of an LDevID certificate associated with
the service technician operating the device.  This avoids revealing
personal information to Registrar and MASA.
the Pledge product-serial-number is contained in the trigger
message for the PVR and in all responses from the pledge.  This
information reveals the identity of the devices being bootstrapped
and allows deduction of which products an operator is using in
their environment.  As the communication between the pledge and
the registrar-agent may be realized over wireless link, this
information could be easily be eavesdropped, if the wireless
network is unencrypted.  Even if the wireless network is
encrypted, if it uses a network-wide key, then layer-2 attacks
(ARP/ND spoofing) could insert on-path observer into the path.
the Timestamp data could reveal the activation time of the device.
the Status data of the device could reveal information about the
current state of the device in the domain network.
A DoS attack with a faked registrar-agent may block the bootstrapping
of the pledge due to state creation on the pledge (only vouchered).
Mitigation may be that the pledge does not create a state if the
bootstrapping is not finished after certain time.
A registrar-agent that uses formerly acquired PVR and PER for
domain-A in domain-B can be detected by the domain registrar while
PVR processing.  This requires the domain registrar to verify the
"proximity-registrar-cert" field in the PVR matches its own
LDevID(Reg) certificate.  In addition, the domain registrar has to
verify the association of the pledge to its domain based on the
product-serial-number contained in the PVR and in the IDevID
certificate of the pledge.  Moreover, the domain registrar verifies
if the registrar-agent is authorized to interact with the pledge for
voucher-requests and enroll-requests, based on the LDevID(RegAgt)
certificate data contained in the PVR.
A DoS attack with a faked registrar-agent may block the bootstrapping
of the pledge due to state creation on the pledge (the pledge may
produce a voucher, and refuse to produce another one).  One
mitigation may be that the pledge does does not limited the number of
voucher requests it creates until at least one has finished, or a
single onboarding state may expire after a certain time.
A registrar-agent that uses previously requested PVR and PER for
domain-A, may attempt to onboard the device into domain-B.  This can
be detected by the domain registrar while PVR processing.  The domain
registrar needs to verify that the "proximity-registrar-cert" field
in the PVR matches its own LDevID(Reg) certificate.  In addition, the
domain registrar needs to verify the association of the pledge to its
domain based on the product-serial-number contained in the PVR and in
the IDevID certificate of the pledge.  (This is just part of the
supply chain integration) Moreover, the domain registrar verifies if
the registrar-agent is authorized to interact with the pledge for
voucher-requests and enroll-requests, based on the LDevID(RegAgt)
certificate data contained in the PVR.
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 at a
later point in time.  As "agent-signed-data" could be dated after the
validity time of the LDevID(RegAgt) 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) certificate used in the
TLS handshake with the registrar-agent.  If both certificates are
verified successfully, the registrar-agents signature can be
considered as valid.
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 at a
later point in time.  As "agent-signed-data" could be dated after the
validity time of the LDevID(RegAgt) 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) certificate used in the TLS handshake
with the registrar-agent.  If both certificates are verified
successfully, the registrar-agents signature can be considered as
valid.