| Internet-Draft | BRSKI-PRM | March 2022 |
| Fries, et al. | Expires 5 September 2022 | [Page] |
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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 September 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
BRSKI as defined in [RFC8995] specifies a solution for secure zero-touch (automated) bootstrapping of devices (pledges) in a (customer) site domain. This includes the discovery of network elements in the target domain, time synchronization, and the exchange of security information necessary to establish trust between a pledge and the domain. Security information about the target domain, specifically the target domain certificate, is exchanged utilizing voucher 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).¶
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 request objects to be bootstrapped in the registrar's 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 tool or it may be even co-located with the registrar. In contrast to BRSKI the registrar-agent performs the object exchange with the pledge and provides/retrieves data objects to/from 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. This is addressed by¶
For the enrollment of devices BRSKI relies on EST [RFC7030] to request and distribute target 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 target 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. As the described solution will rely on additional wrapping signature it will require pre-processing specifically for EST, as it currently uses PKCS#10 requests only.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document relies on the terminology defined in [RFC8995]. The following terms are defined additionally:¶
Describes a timely interrupted communication between an end entity and a PKI component.¶
Describes an object, which is cryptographically bound to the EE certificate (IDevID certificate or LDEVID certificate) of a pledge. The binding is assumed to be provided through a digital signature of the actual object using the corresponding private key of the EE certificate.¶
Certification authority, issues certificates.¶
End entity¶
Describes a component or service or functionality available in the target deployment domain.¶
Describes a component or service or functionality available in an operator domain different from the target deployment domain. This may be a central site or a cloud service, to which only a temporary connection is available, or which is in a different administrative domain.¶
Pledge-enrollment-request¶
Prove of possession (of a private key)¶
Prove of identity¶
Pledge-voucher-request¶
Intelligent Electronic Device (in essence a pledge).¶
Registration authority, an optional system component to which a CA delegates certificate management functions such as authorization checks.¶
Registrar-enrollment-request¶
Registrar-voucher-request¶
Describes a timely uninterrupted communication between an end entity and a PKI component.¶
The described solution is applicable in domains in which pledges have no direct connection to the domain registrar, but are expected to be managed by this registrar. This can be motivated by pledges featuring a different technology stack or by pledges without an existing connection to the domain registrar during bootstrapping. These pledges are likely to act in a server role. Therefore, the pledge has to offer endpoints on which it can be triggered for the generation of pledge-voucher-request objects and certification objects as well as to provide the response objects to the pledge.¶
The following examples are intended to motivate the support of additional bootstrapping approaches in general by introducing industrial applications cases, which could leverage BRSKI as such but also require support a pledge acting as server and only answers requests as well as scenarios with limited connectivity to the registrar.¶
In building automation, a use case can be described by a detached building (or a cabinet) or the basement of a building equipped with sensor, actuators, and controllers connected, but with only limited or no connection to the centralized building management system. This limited connectivity may be during the installation time but also during operation time. During the installation in the basement, a service technician collects the 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. A domain registrar may be part of the central building management system and already be operational in the installation network. The central building management system can then provide operational parameters for the specific devices in the basement. This operational parameters may comprise values and settings required in the operational phase of the sensors/actuators, beyond them a certificate issued by the operator to authenticate against other components and services. These operational parameters are then provided to the devices in the basement facilitated by the service technician's laptop.¶
This refers to any case in which network infrastructure is normally isolated from the Internet as a matter of policy, most likely for security reasons. In such a case, limited access to a domain registrar may be allowed in carefully controlled short periods of time, for example when a batch of new devices are deployed, but impossible at other times.¶
The registration authority (RA) performing the authorization of a certificate request is a critical PKI component and therefore implicates higher operational security than other components utilizing the issued certificates . CAs may also demand higher security in the registration procedures. Especially the CA/Browser forum currently increases the security requirements in the certificate issuance procedures for publicly trusted certificates. There may be the situation in which the target domain does not offer enough security to operate a RA/CA and therefore this service is transferred to a backend that offers a higher level of operational security.¶
The mechanisms in this draft 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.¶
Based on the intended target environment described in Section 3.1 and the motivated application examples described in Section 3.2 the following base requirements are derived to support the communication between a pledge and a registrar via a registrar-agent.¶
At least the following properties are required by the voucher handling and the enrollment:¶
Solution examples based on existing technology are provided with the focus on existing IETF documents:¶
For BRSKI with pledge in responder mode, the base system architecture defined in BRSKI [RFC8995] is enhanced to facilitate the new use case. 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.¶
Necessary enhancements to support authenticated self-contained objects for certificate enrollment are kept at a minimum to enable reuse of already defined architecture elements and interactions.¶
For the authenticated self-contained objects used for the certification request, BRSKI-PRM relies on the defined message wrapping mechanisms of the enrollment protocols stated in Section 4 above.¶
The security used within the document for bootstrapping objects produced or consumed by the pledge bases on JOSE. In constraint environments it may provided based on COSE.¶
To support mutual trust establishment of pledges, not directly connected to the domain registrar, this document relies on the exchange of authenticated self-contained objects (the voucher request/response objects as known from BRSKI and the enrollment request/response objects as introduced by BRSKI-PRM) with the help of a registrar-agent. This allows independence from protection provided by the utilized transport protocol.¶
The registrar-agent may be an integrated functionality of a commissioning tool or be co-located with the registrar itself. This leads to enhancements of the logical elements in the BRSKI architecture as shown in Figure 1. The registrar-agent interacts with the pledge to acquire and to supply the required data objects for bootstrapping, which are also exchanged between the registrar-agent and the domain registrar. Moreover, the addition of the registrar-agent influences the sequences of the data exchange between the pledge and the domain registrar described in [RFC8995]. A general goal for the registrar-agent application is the reuse of already defined endpoints of the domain registrar side. The functionality of the already existing registrar endpoints may need small enhancements to cope with the additional signatures.¶
+------------------------+
+--------------Drop Ship---------------| Vendor Service |
| +------------------------+
| | M anufacturer| |
| | A uthorized |Ownership|
| | S igning |Tracker |
| | A uthority | |
| +--------------+---------+
| ^
| | BRSKI-
V BRSKI-PRM | MASA
+-------+ +---------+ .............................|.........
| | | | . | .
| | | | . +-----------+ +-----v-----+ .
| | |Registrar| . | | | | .
|Pledge | |Agent | . | Join | | Domain | .
| | | | . | Proxy | | Registrar | .
| <----->.........<------>...........<-------> (PKI RA) | .
| | | | . | | | | .
| | | | . | | +-----+-----+ .
|IDevID | | LDevID | . +-----------+ | .
| | | | . +------------------+-----+ .
+-------+ +---------+ . | Key Infrastructure | .
. | (e.g., PKI Certificate | .
. | Authority) | .
. +------------------------+ .
.......................................
"Domain" components
For authentication towards the domain registrar, the registrar-agent uses its LDevID. The provisioning of the registrar-agent LDevID 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 of days or weeks.¶
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 the registrar-agent to perform additional authorization of a pledge bootstrapping action. Examples for such user level authentication may be HTTP authentication or the usage of authorization tokens or other. This is out of scope of this document.¶
The following list describes the components in a (customer) site domain:¶
Pledge: The pledge is expected to respond with the necessary data objects for bootstrapping to the registrar-agent. The transport protocol used between the pledge and the registrar-agent is assumed to be HTTP in the context of this document. Other transport protocols may be used like CoAP, Bluetooth, or NFC, but are out of scope of this document. A pledge acting as a server during bootstrapping leads to some differences to BRSKI:¶
"Agent-proximity" is a weaker assertion then "proximity". It is defined as additional assertion type in [I-D.richardson-anima-rfc8366bis] In case of "agent-proximity" it is a statement, that the proximity-registrar-certificate was provided via the registrar-agent and not directly to the pledge. This can be verified by the registrar and also by the MASA during the voucher-request processing. Note that at the time of creating the voucher-request, the pledge cannot verify the registrar's LDevID(Reg) EE certificate and has no proof-of-possession of the corresponding private key for the certificate.¶
Trust handover to the domain is established via the "pinned-domain-certificate" in the voucher.¶
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) EE certificate can be verified after the voucher has been processed by the pledge through a verification of an additional signature of the returned voucher by the registrar if contained (optional feature).¶
In contrast to BRSKI the pledge acts as a server component. It is triggered by the registrar-agent for the generation of pledge-voucher-request and pledge-enrollment-request objects as well as for the processing of the response objects 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 Figure 4. To enable interaction with the registrar-agent, the pledge provides endpoints using the BRSKI interface based on the "/.well-known/brski" URI tree.¶
The following endpoints are defined for the pledge in this document. The URI path begins with "http://www.example.com/.well-known/brski" followed by a path-suffix that indicates the intended operation.¶
Operations and their corresponding URIs: +------------------------+----------------------------+---------+ | Operation |Operation path | Details | +========================+============================+=========+ | Trigger pledge-voucher-| /pledge-voucher-request | Section | | request creation | | 5.1.4.1 | | Returns | | | | pledge-voucher-request | | | ++------------------------+----------------------------+---------+ | Trigger pledge- | /pledge-enrollment-request | Section | | enrollment-request | | 5.1.4.1 | | Returns pledge- | | | | enrollment-request | | | +------------------------+----------------------------+---------+ | Provide voucher to | /pledge-voucher | Section | | pledge | | 5.1.4.3 | | Returns | | | | pledge-voucher-status | | | +------------------------+----------------------------+---------+ | Provide enrollment | /pledge-enrollment | Section | | response to pledge | | 5.1.4.3 | | Returns pledge- | | | | enrollment-status | | | +------------------------+----------------------------+---------+ | Provide CA certs to | /pledge-CACerts | | | pledge (OPTIONAL) | | | +------------------------+----------------------------+---------+
The registrar-agent is a new component in the BRSKI context. It provides connectivity between the pledge and the domain registrar and reuses the endpoints of the domain registrar side already specified in [RFC8995]. It facilitates the exchange of data objects between the pledge and the domain registrar, which are the voucher request/response objects, the enrollment request/response objects, as well as related status objects. For the communication the registrar-agent utilizes communication endpoints provided by the pledge. The transport in this specification is based on HTTP but may also be done using other transport mechanisms. This new component changes the general interaction between the pledge and the domain registrar as shown in Figure 10.¶
The registrar-agent is expected to already possess an LDevID(RegAgt) to authenticate towards the domain registrar. The registrar-agent will use this LDevID(RegAgt) when establishing the TLS session with the domain registrar in the context of for TLS client-side authentication. The LDevID(RegAgt) EE certificate MUST include a SubjectKeyIdentifier (SKID), which is used as reference in the context of an agent-signed-data object as defined in Section 5.1.4.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-side 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 request object 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, like scanning of product-serial-number information using a QR code or similar.¶
According to [RFC8995] section 5.3, the domain registrar performs the pledge authorization for bootstrapping within his domain based on the pledge voucher-request object.¶
The following information must therefore be available at the registrar-agent:¶
The discovery of the domain registrar may be done as specified in [RFC8995] with the deviation that it is done between the registrar-agent and the domain registrar. Alternatively, the registrar-agent may be configured with the address of the domain registrar and the certificate of the domain registrar.¶
The discovery of the pledge by registrar-agent should be done by using DNS-based Service Discovery [RFC6763] over Multicast DNS [RFC6762] to discover the pledge at "product-serial-number.brski-pledge._tcp.local." The pledge constructs a local host name based on device local information (product-serial-number), which results in "product-serial-number.brski-pledge._tcp.local." It can then be discovered by the registrar-agent via mDNS. Note that other mechanisms for discovery may be used.¶
The registrar-agent is able to build the same information based on the provided list of 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. 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) EE certificate) to the pledge to be included into the "agent-provided-proximity-registrar-certificate" leaf of the pledge-voucher-request object. 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 pledge-voucher-request. Optionally the registrar-agent may provide its LDevID(RegAgt) EE certificate (and optionally also the issuing CA certificate) to the pledge to be used in the "agent-sign-cert" component of the pledge-voucher-request. If contained, the LDevID(RegAgt) EE certificate MUST be the first certificate in the array. Note, this may be omitted in constraint environments to safe bandwidth between the registrar-agent and the pledge. If not contained, the registrar-agent MUST fetch the LDevID(RegAgt) EE certificate based on the SubjectKeyIdentifier (SKID) in the header of the agent-signed-data of the pledge-voucher-request. The registrar includes the LDevID(RegAgt) EE certificate information into the registrar-voucher-request if the pledge-voucher-requests requests the assertion of "agent-proximity".¶
The MASA in turn verifies the LDevID(Reg) EE certificate is included in the pledge-voucher-request (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. If the LDevID(RegAgt) EE certificate information is contained in the "agent-sign-cert" component of the registrar-voucher-request, 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". The voucher can then be supplied via the registrar to the registrar-agent.¶
Figure 3 provides an overview of the exchanges detailed in the following sub sections.¶
+--------+ +-----------+ +-----------+ +--------+ +---------+
| Pledge | | Registrar | | Domain | | Domain | | Vendor |
| | | Agent | | Registrar | | CA | | Service |
| | | (RegAgt) | | (JRC) | | | | (MASA) |
+--------+ +-----------+ +-----------+ +--------+ +---------+
| | | | Internet |
[discovery of pledge]
| mDNS query | | | |
|<-------------| | | |
|------------->| | | |
| | | | |
[trigger pledge-voucher-request and
pledge-enrollment-request generation]
|<- vTrigger --| | | |
|-Voucher-Req->| | | |
| | | | |
|<- eTrigger --| | | |
|- Enroll-Req->| | | |
~ ~ ~ ~ ~
[provide pledge-voucher-request to infrastructure]
| |<------ TLS ----->| | |
| | [Reg-Agt auth+authz?] | |
| |-- Voucher-Req -->| | |
| | [Reg-Agt authorized?] | |
| | [accept device?] | |
| | [contact vendor] | |
| | |------- Voucher-Req ------>|
| | | [extract DomainID]
| | | [update audit log]
| | |<-------- Voucher ---------|
| |<---- Voucher ----| | |
| | | | |
[provide pledge enrollment request to infrastructure]
| |-- Enroll-Req --->| | |
| | |- Cert-Req -->| |
| | |<-Certificate-| |
| |<-- Enroll-Resp --| | |
~ ~ ~ ~ ~
[provide voucher and certificate
to pledge and collect status info]
|<-- Voucher --| | | |
|-- vStatus -->| | | |
|<-Enroll-Resp-| | | |
|-- eStatus -->| | | |
~ ~ ~ ~ ~
[provide voucher-status and enrollment status to registrar]
| |<------ TLS ----->| | |
| |---- vStatus --->| | |
| | |-- req. device audit log ->|
| | |<---- device audit log ----|
| | [verify audit log]
| | | | |
| |---- eStatus --->| | |
| | | | |
The following sub sections split the interactions between the different components into:¶
The following description assumes that the registrar-agent already discovered the pledge. This may be done as described in Section 5.1.3.2 based on mDNS.¶
The focus is on the exchange of signature-wrapped objects using endpoints defined for the pledge in Section 5.1.2.¶
Preconditions:¶
+--------+ +-----------+
| Pledge | | Registrar |
| | | Agent |
| | | (RegAgt) |
+--------+ +-----------+
| |-create
| | agent-signed-data
|<--- trigger pledge-voucher-request ----|
|-agent-provided-proximity-registrar-cert|
|-agent-signed-data |
|-agent-sign-cert (optional) |
| |
|----- pledge-voucher-request ---------->|-store
| | pledge-voucher-request
|<----- trigger enrollment request ------|
| (empty) |
| |
|------ pledge-enrollment-request ------>|-store
| | pledge-enrollment-req.
Triggering the pledge to create the pledge-voucher-request is done using HTTP POST on the defined pledge endpoint "/.well-known/brski/pledge-voucher-request".¶
The registrar-agent pledge-voucher-request Content-Type header is: application/json. It defines a JSON document to provide three parameter:¶
The the trigger for the pledge to create a pledge-voucher-request is depicted in the following figure:¶
{
"agent-provided-proximity-registrar-cert": "base64encodedvalue==",
"agent-signed-data": "base64encodedvalue==",
"agent-sign-cert": ["base64encodedvalue==", "base64encodedvalue==", "..."]
}
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) EE 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 agent-signed-data is a JOSE object and contains the following information:¶
The header of the agent-signed-data contains:¶
The body of the agent-signed-data contains an ietf-voucher-request-prm:agent-signed-data element (defined in Section 6.1):¶
{
"payload": {
"ietf-voucher-request-prm:agent-signed-data": {
"created-on": "2021-04-16T00:00:01.000Z",
"serial-number": "callee4711"
},
"signatures": [
{
"protected": {
"alg": "ES256",
"kid": "base64encodedvalue=="
},
"signature": "base64encodedvalue=="
}
]
}
}
Upon receiving the voucher-request trigger, the pledge SHOULD construct the body of the pledge-voucher-request object as defined in [RFC8995]. It will contain additional information provided by the 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 the pledge is unable to construct the pledge-voucher-request it SHOULD respond with HTTP 406 error code to the registrar-agent to indicate that it is not able to create the pledge-voucher-request.¶
The header of the pledge-voucher-request SHALL contain the following parameter as defined in [RFC7515]:¶
The payload of the pledge-voucher-request (PVR) object MUST contain the following parameter as part of the ietf-voucher-request-prm:voucher as defined in [RFC8995]:¶
The ietf-voucher-request:voucher is enhanced with additional parameters:¶
The enhancements of the YANG module for the ietf-voucher-request with these new leafs are defined in Section 6.1.¶
The object is signed using the pledge's IDevID credential contained as x5c parameter of the JOSE header.¶
{
"payload": {
"ietf-voucher-request-prm:voucher": {
"created-on": "2021-04-16T00:00:02.000Z",
"nonce": "eDs++/FuDHGUnRxN3E14CQ==",
"serial-number": "callee4711",
"assertion": "agent-proximity",
"agent-provided-proximity-registrar-cert": "base64encodedvalue==",
"agent-signed-data": "base64encodedvalue==",
"agent-sign-cert": [
"base64encodedvalue==",
"base64encodedvalue==",
"..."
]
},
"signatures": [
{
"protected": {
"alg": "ES256",
"x5c": [ "MIIB2jCC...dA==" ]
},
"signature": "base64encodedvalue=="
}
]
}
}
The pledge-voucher-request Content-Type is defined in [I-D.ietf-anima-jws-voucher] as:¶
application/voucher-jws+json¶
The pledge SHOULD include this Content-Type header field indicating the included media type for the voucher response. Note that this is also an indication regarding the acceptable format of the voucher response. This format is included by the registrar as described in Section 5.1.4.2.¶
Once the registrar-agent has received the pledge-voucher-request it can trigger the pledge to generate an enrollment-request object. As in BRSKI the enrollment request object is a PKCS#10, but additionally signed using the pledge's IDevID. Note, as the initial enrollment aims to request a generic certificate, no certificate attributes are provided to the pledge.¶
Triggering the pledge to create the enrollment-request is done using HTTP POST on the defined pledge endpoint "/.well-known/brski/pledge-enrollment-request".¶
The registrar-agent pledge-enrollment-request Content-Type header is: application/json
with an empty body.
Note that using HTTP POST allows for an empty body, but also to provide additional data, like CSR attributes or information about the enroll type: initial or re-enroll as shown in Figure 8.¶
{
"enroll-type" = "intial"
}
In the following the enrollment is described as initial enrollment with an empty body.¶
Upon receiving the enrollment-trigger, the pledge SHALL construct the pledge-enrollment-request as authenticated self-contained object. The CSR already assures proof of possession of the private key corresponding to the contained public key. In addition, based on the additional signature using the IDevID, proof of identity is provided. Here, a JOSE object is being created in which the body utilizes the YANG module ietf-ztp-types with the grouping for csr-grouping for the CSR as defined in [I-D.ietf-netconf-sztp-csr].¶
Depending on the capability of the pledge, it constructs the enrollment request as plain PKCS#10. Note that the focus in this use case is placed on PKCS#10 as PKCS#10 can be transmitted in different enrollment protocols in the infrastructure like EST, CMP, CMS, and SCEP. If the pledge is already implementing an enrollment protocol, it may leverage that functionality for the creation of the enrollment request object. Note also that [I-D.ietf-netconf-sztp-csr] also allows for inclusion of certification request objects such as CMP or CMC.¶
The pledge SHOULD construct the pledge-enrollment-request as PKCS#10 object. In BRSKI-PRM it MUST sign it additionally with its IDevID credential to provide proof-of-identity bound to the PKCS#10 as described below.¶
If the pledge is unable to construct the enrollment-request it SHOULD respond with HTTP 406 error code to the registrar-agent to indicate that it is not able to create the enrollment-request.¶
A successful enrollment will result in a generic LDevID certificate for the pledge in the new domain, which can be used to request further (application specific) LDevID certificates if necessary for its operation. The registrar-agent may use the endpoints specified in this document.¶
[I-D.ietf-netconf-sztp-csr] considers PKCS#10 but also CMP and CMC as certification request format. Note that the wrapping signature is only necessary for plain PKCS#10 as other request formats like CMP and CMS support the signature wrapping as part of their own certificate request format.¶
The registrar-agent enrollment-request Content-Type header for a wrapped PKCS#10 is: application/jose¶
The header of the pledge enrollment-request SHALL contain the following parameter as defined in [RFC7515]:¶
The body of the pledge enrollment-request object SHOULD contain a P10 parameter (for PKCS#10) as defined for ietf-ztp-types:p10-csr in [I-D.ietf-netconf-sztp-csr]:¶
The JOSE object is signed using the pledge's IDevID credential, which corresponds to the certificate signaled in the JOSE header.¶
{
"payload": {
"ietf-ztp-types": {
"p10-csr": "base64encodedvalue=="
},
"signatures": [
{
"protected": {
"alg": "ES256",
"x5c": [ "MIIB2jCC...dA==" ]
},
"signature": "base64encodedvalue=="
}
]
}
}
With the collected pledge-voucher-request object and the pledge-enrollment-request object, the registrar-agent starts the interaction with the domain registrar.¶
Once the registrar-agent has collected the pledge-voucher-request and pledge-enrollment-request objects, it connects to the registrar and sends the request objects. As the registrar-agent is intended to work between the pledge and the domain registrar, a collection of requests from more than one pledge is possible, allowing a bulk bootstrapping of multiple pledges using the same connection between the registrar-agent and the domain registrar.¶
The BRSKI-PRM bootstrapping exchanges between registrar-agent and domain registrar resemble the BRSKI exchanges between pledge and domain registrar (pledge-initiator-mode) with some deviations.¶
Preconditions:¶
+-----------+ +-----------+ +--------+ +---------+
| Registrar-| | Domain | | Domain | | Vendor |
| agent | | Registrar | | CA | | Service |
| (RegAgt) | | (JRC) | | | | (MASA) |
+-----------+ +-----------+ +--------+ +---------+
| | | Internet |
[exchange between pledge and ] | |
[registrar-agent done. ] | |
| | | |
|<------ TLS ----->| | |
| [Reg-Agt auth+authz?] | |
| | | |
|-- Voucher-Req -->| | |
| (PVR) | | |
| [Reg-Agt authorized?] | |
| [accept device?] | |
| [contact vendor] | |
| |------------ TLS --------->|
| |-- Voucher-Req ----------->|
| | (RVR) |
| | [extract DomainID]
| | [update audit log]
| |<-------- Voucher ---------|
|<---- Voucher ----| |
| | |
[certification request handling registrar-agent] |
[and site infrastructure] |
|--- Enroll-Req -->| | |
| (PER) | | |
| |---- TLS ---->| |
| |- Enroll-Req->| |
| | (RER) | |
| |<-Enroll-Resp-| |
|<-- Enroll-Resp---| | |
| | | |
The registrar-agent establishes a TLS connection with the registrar. 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 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 MASA, but TLS 1.2 MAY be used.¶
In contrast to [RFC8995] TLS client authentication is achieved by using registrar-agent LDevID(RegAgt) credentials instead of pledge IDevID credentials. This allows the registrar to distinguish between BRSKI (pledge-initiator-mode) and BRSKI-PRM (pledge-responder-mode). The registrar SHOULD verify that the registrar-agent is authorized to connect to the registrar based on the LDevID(RegAgt). Note, the authorization will be verified based on the agent-signed-data carried in the pledge-voucher-request. As short-lived certificates are recommended for the registrar-agent, the LDevID(RegAgt) EE certificate used in the TLS handshake may be newer than the one of in the pledge-voucher-request.¶
The registrar can received request objects in different forms as defined in [RFC8995]. Specifically, the registrar will receive JSON-in-JWS objects generated by the pledge for voucher-request and enrollment-request (instead of BRSKI voucher-request as CMS-signed JSON and enrollment-request as PKCS#10 objects).¶
The registrar-agent sends the pledge-voucher-request to the registrar by HTTP POST to the endpoint: "/.well-known/brski/requestvoucher"¶
The pledge-voucher-request Content-Type header field used for pledge-responder-mode is defined in [I-D.ietf-anima-jws-voucher] as: application/voucher-jws+json (see Figure 7 for the content definition).¶
The registrar-agent SHOULD include the Accept request-header field indicating the pledge acceptable Content-Type for the voucher-response. The voucher-response Content-Type header field "application/voucher-jws+json" is defined in [I-D.ietf-anima-jws-voucher].¶
Upon reception of the pledge-voucher-request, the registrar SHALL perform the verification of the voucher-request parameter as defined in section 5.3 of [RFC8995]. In addition, the registrar shall verify the following parameters from the pledge-voucher-request:¶
If validation fails the registrar SHOULD respond with HTTP 404 error code to the registrar-agent. HTTP 406 error code is more appropriate, if the format of pledge-voucher-request is unknown.¶
If validation succeeds, the registrar will accept the pledge's request to join the domain as defined in section 5.3 of [RFC8995]. The registrar then establishes a TLS connection with the MASA as described in section 5.4 of [RFC8995] to obtain a voucher for the pledge.¶
The registrar SHALL construct the body of the registrar-voucher-request object as defined in [RFC8995]. The encoding SHALL be done as JSON-in-JWS object as defined in [I-D.ietf-anima-jws-voucher].¶
The header of the registrar-voucher-request SHALL contain the following parameter as defined in [RFC7515]:¶
The payload of the registrar-voucher-request (RVR) object MUST contain the following parameter as part of the voucher request as defined in [RFC8995]:¶
The voucher request can be enhanced optionally with the following additional parameter as defined in Section 6.1:¶
If only a single object is contained in the list it MUST be the base64-encoded LDevID(RegAgt) EE certificate. If multiple certificates are included, the first MUST be the base64-encoded LDevID(RegAgt) EE certificate.¶
The MASA uses this information for the verification of agent proximity to issue the corresponding assertion "agent-proximity". If the agent-sign-cert is not contained in the registrar-voucher-request, it is contained in the prior-signed-voucher from the pledge.¶
The object is signed using the registrar LDevID(Reg) credential, which corresponds to the certificate signaled in the JOSE header.¶
{
"payload": {
"ietf-voucher-request-prm:voucher": {
"created-on": "2022-01-04T02:37:39.235Z",
"nonce": "eDs++/FuDHGUnRxN3E14CQ==",
"serial-number": "callee4711",
"assertion": "agent-proximity",
"prior-signed-voucher-request": "base64encodedvalue==",
"agent-sign-cert": [
"base64encodedvalue==",
"base64encodedvalue==",
"..."
]
},
"signatures": [
{
"protected": {
"alg": "ES256",
"x5c": [ "MIIB2jCC...dA==" ]
},
"signature": "base64encodedvalue=="
}
]
}
}
The registrar sends the registrar-voucher-request to the MASA by HTTP POST to the endpoint "/.well-known/brski/requestvoucher".¶
The registrar-voucher-request Content-Type header field is defined in [I-D.ietf-anima-jws-voucher] as: application/voucher-jws+json¶
The registrar SHOULD include an Accept request-header field indicating the acceptable media type for the voucher-response. The media type "application/voucher-jws+json" is defined in [I-D.ietf-anima-jws-voucher].¶
Once the MASA receives the registrar-voucher-request it SHALL perform the verification of the contained components as described in section 5.5 in [RFC8995].¶
In addition, the following processing SHALL be performed for data contained in the prior-signed-voucher-request:¶
If validation fails, the MASA SHOULD respond with an HTTP error code to the registrar. The HTTP error codes are kept as defined in section 5.6 of [RFC8995], and comprise the codes: 403, 404, 406, and 415.¶
The expected voucher response format is indicated by the Accept request-header field or based on the MASA's prior understanding of proper format for this pledge. Specifically for the pledge-responder-mode the "application/voucher-jws+json" as defined in [I-D.ietf-anima-jws-voucher] is applied. The voucher syntax is described in detail by [RFC8366]. Figure 12 shows an example of the contents of a voucher.¶
{
"payload": {
"ietf-voucher:voucher": {
"assertion": "agent-proximity",
"serial-number": "callee4711",
"nonce": "eDs++/FuDHGUnRxN3E14CQ==",
"created-on": "2022-01-04T00:00:02.000Z",
"pinned-domain-cert": "MIIBpDCCA...w=="
},
"signatures": [
{
"protected": {
"alg": "ES256",
"x5c": [ "MIIB2jCC...dA==" ]
},
"signature": "base64encodedvalue=="
}
]
}
}
The MASA responds the voucher to the registrar.¶
After receiving the voucher the registrar SHOULD evaluate it for transparency and logging purposes as outlined in section 5.6 of [RFC8995]. The registrar MAY provide an additional signature of the voucher. This signature is done over the same content as the MASA signature of the voucher and provides a proof of possession of the private key corresponding to the LDevID(Reg) the pledge received in the trigger for the PVR (see Figure 5). The registrar MUST use the same LDevID(Reg) credential that is used for authentication in the TLS handshake to authenticate towards the registrar-agent. This ensures that the same LDevID(Reg) certificate can be used to verify the signature as transmitted in the voucher request as is transferred in the pledge-voucher-request in the agent-provided-proximity-registrar-cert component. Figure Figure 13 below provides an example of the voucher with two signatures.¶
{
"payload": {
"ietf-voucher:voucher": {
"assertion": "agent-proximity",
"serial-number": "callee4711",
"nonce": "eDs++/FuDHGUnRxN3E14CQ==",
"created-on": "2022-01-04T00:00:02.000Z",
"pinned-domain-cert": "MIIBpDCCA...w=="
},
"signatures": [
{
"protected": {
"alg": "ES256",
"x5c": [ "MIIB2jCC...dA==" ]
},
"signature": "base64encodedvalue=="
},
{
"protected": {
"alg": "ES256",
"x5c": [ "xURZmcWS...dA==" ]
},
"signature": "base64encodedvalue=="
}
]
}
}
Depending on the security policy of the operator, this signature can also be interpreted as explicit authorization of the registrar to install the contained trust anchor.¶
The registrar forwards the voucher to the registrar-agent.¶
After receiving the voucher, the registrar-agent sends the pledge-enrollment-request (PER) to the registrar. Deviating from BRSKI the pledge-enrollment-request is not a raw PKCS#10 object. As the 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 to ensure proof-of-identity as outlined in Figure 9.¶
When using EST, the standard endpoint on the registrar cannot be used. EST requires to sent a raw PKCS#10 request to the simpleenroll endpoint. This document makes an enhancement by utilizing EST but with the exception to transport a signature wrapped PKCS#10 request. Therefore a new endpoint for the registrar is defined as "/.well-known/brski/requestenroll"¶
The PER Content-Type header is: application/jose.¶
This results in a deviation from the content types used in [RFC7030] and in additional processing at the domain registrar as EST server as following. Note, the registrar is already aware that the bootstrapping is performed in a pledge-responder-mode due to the use of the LDevID(RegAgt) EE certificate in the TLS establishment and the provided pledge-voucher-request as JWS object.¶
The registrar-agent sends the PER to the registrar by HTTP POST to the endpoint: "/.well-known/brski/requestenroll"¶
If validation of the wrapping signature fails, the registrar SHOULD respond with HTTP 404 error code.
HTTP 406 error code is more appropriate, if the pledge-enrollment-request is in an unknown format.
A situation that could be resolved with administrative action (such as adding a vendor/manufacturer IDevID CA as trusted party) MAY be responded with HTTP 403 error code.¶
A successful interaction with the domain CA will result in a pledge LDevID EE certificate, which is then forwarded by the registrar to the registrar-agent using the Content-Type header: "application/pkcs7-mime".¶
The registrar-agent has now finished the exchanges with the domain registrar and can supply the voucher-response (from MASA via Registrar) and the enrollment-response (LDevID EE certificate) to the pledge. It can close the TLS connection to the domain registrar and provide the objects to the pledge(s). The content of the response objects is defined through the voucher [RFC8366] and the certificate [RFC5280].¶
The following description assumes that the registrar-agent has obtained the response objects from the domain registrar. It will re-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 stored information from the first contact with the pledge.¶
Preconditions in addition to Section 5.1.4.2:¶
+--------+ +-----------+
| Pledge | | Registrar-|
| | | Agent |
| | | (RegAgt) |
+--------+ +-----------+
| |
|<------- supply voucher -----------|
| |
|--------- voucher-status --------->| - store
| | pledge voucher-status
|<--- supply enrollment response ---|
| |
|--------- enroll-status ---------->| - store
| | pledge enroll-status
The registrar-agent provides the information via two distinct endpoints to the pledge as following.¶
The voucher response is provided with a HTTP POST using the operation path value of "/.well-known/brski/pledge-voucher".¶
The registrar-agent voucher-response Content-Type header is "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 voucher and in Figure Figure 13 for multiple signatures.¶
If a single signature is contained, the pledge receives the voucher and verifies it as described in section 5.6.1 in [RFC8995].¶
If multiple signatures are contained in the voucher, the pledge SHALL perform the signature verification in the following order:¶
When all verification steps stated above have been performed successfully, the pledge SHALL end the provisional accept state for the domain trust anchor and the LDevID(Reg). When multiple signatures are contained in the voucher-response, the pledge MUST verify all successfully.¶
When an error occurs during the verification it SHALL be signaled in the reason field of the pledge voucher-status object.¶
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-object and provides it as JOSE object with the wrapping signature in the response message to the registrar-agent.¶
The response has the Content-Type "application/jose" and is signed 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 success.¶
{
"payload": {
"version": 1,
"status": true,
"reason": "Informative human readable message",
"reason-context": {
"additional": "JSON"
}
},
"signatures": [
{
"protected": {
"alg": "ES256",
"x5c": [ "MIIB2jCC...dA==" ]
},
"signature": "base64encodedvalue=="
}
]
}
The enrollment response is provided with a HTTP POST using the operation path value of "/.well-known/brski/pledge-enrollment".¶
The registrar-agent enroll-response Content-Type header, when using EST [RFC7030] as enrollment protocol between the registrar-agent and the infrastructure, is:¶
application/pkcs7-mime: note that it only contains the LDevID certificate for the pledge, not the certificate chain.¶
Upon reception, the pledge verifies the LDevID certificate. When an error occurs during the verification it SHALL be signaled in the reason field of the pledge enroll-status object.¶
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 object is provided with an additional signature using JOSE. The pledge generates the enrollment status and provides it in the response message to the registrar-agent.¶
The response has the Content-Type "application/jose", signed using 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": {
"version": 1,
"status": true,
"reason": "Informative human readable message",
"reason-context": {
"additional": "JSON"
}
},
"signatures": [
{
"protected": {
"alg": "ES256",
"x5c": [ "MIIB2jCC...dA==" ]
},
"signature": "base64encodedvalue=="
}
]
}
Once the registrar-agent has collected the information, it can connect to the registrar agent to provide the status responses to the registrar.¶
The following description assumes that the registrar-agent has collected the status objects from the pledge. It will provide the status objects to the registrar for further processing and audit log information of voucher-status for MASA.¶
Preconditions in addition to Section 5.1.4.2:¶
+-----------+ +-----------+ +--------+ +---------+
| Registrar | | Domain | | Domain | | Vendor |
| Agent | | Registrar | | CA | | Service |
| RegAgt) | | (JRC) | | | | (MASA) |
+-----------+ +-----------+ +--------+ +---------+
| | | Internet |
| | | |
|<------ TLS ----->| | |
| | | |
|--Voucher-Status->| | |
| |<---- device audit log ----|
| [verify audit log ]
| | | |
|--Enroll-Status-->| | |
| | | |
| | | |
The registrar-agent MUST provide the collected pledge voucher-status to the registrar. This status indicates if the pledge could process the voucher successfully or not.¶
If the TLS connection to the registrar was closed, the registrar-agent establishes a TLS connection with the registrar as stated in Section 5.1.4.2.¶
The registrar-agent sends the pledge voucher-status object without modification to the registrar with an HTTP-over-TLS POST using the operation path value of "/.well-known/brski/voucher_status". The Content-Type header is kept as "application/jose" as described in Figure 14 and depicted in the example in Figure 15.¶
The registrar SHALL verify the signature of the pledge voucher-status and validate that it belongs to an accepted device in his domain based on the contained "serial-number" in the IDevID certificate referenced in the header of the voucher-status object.¶
According to [RFC8995] section 5.7, the registrar SHOULD respond 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 the service technician operating the registrar agent. Within the server logs the server SHOULD capture this telemetry information.¶
The registrar SHOULD proceed with collecting and logging status information by requesting the MASA audit-log from the MASA service as described in section 5.8 of [RFC8995].¶
The registrar-agent MUST provide the pledge's enroll-status object to the registrar. The status indicates the pledge could process the enroll-response object and holds the corresponding private key.¶
The registrar-agent sends the pledge enroll-status object without modification to the registrar with an HTTP-over-TLS POST using the operation path value of "/.well-known/brski/enrollstatus". The Content-Type header is kept as "application/jose" as described in Figure 14 and depicted in the example in Figure 16.¶
The registrar SHALL verify the signature of the pledge enroll-status object and validate that it belongs to an accepted device in his domain based on the contained product-serial-number in the LDevID EE certificate referenced in the header of the enroll-status object. Note that the verification of a signature of the object is a deviation form the described handling in section 5.9.4 of [RFC8995].¶
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 registrar-agent may use the response to signal success / failure to the service technician operating the registrar agent. Within the server log the registrar SHOULD capture this telemetry information.¶
The following enhancement extends the voucher-request as defined in [RFC8995] to include additional fields necessary for handling bootstrapping in the pledge-responder-mode.¶
The following tree diagram is mostly a duplicate of the contents of [RFC8995], with the addition of the fields agent-signed-data, the registrar-proximity-certificate, and agent-signing certificate. The tree diagram is described in [RFC8340]. Each node in the diagram is fully described by the YANG module in Section Section 6.1.2.¶
module: ietf-voucher-request-prm
grouping voucher-request-prm-grouping
+-- voucher
+-- created-on? yang:date-and-time
+-- expires-on? yang:date-and-time
+-- assertion? enumeration
+-- serial-number string
+-- idevid-issuer? binary
+-- pinned-domain-cert? binary
+-- domain-cert-revocation-checks? boolean
+-- nonce? binary
+-- last-renewal-date? yang:date-and-time
+-- prior-signed-voucher-request? binary
+-- proximity-registrar-cert? binary
+-- agent-signed-data? binary
+-- agent-provided-proximity-registrar-cert? binary
+-- agent-sign-cert? binary
¶
The following YANG module extends the [RFC8995] Voucher Request to include a signed artifact from the registrar-agent (agent-signed-data) as well as the registrar-proximity-certificate and the agent-signing certificate.¶
<CODE BEGINS> file "ietf-voucher-request-prm@2021-12-16.yang"
module ietf-voucher-request-prm {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-voucher-request-prm";
prefix vrprm;
import ietf-restconf {
prefix rc;
description
"This import statement is only present to access
the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol";
}
import ietf-voucher-request {
prefix vcr;
description
"This module defines the format for a voucher request,
which is produced by a pledge as part of the RFC8995
onboarding process.";
reference
"RFC 8995: Bootstrapping Remote Secure Key Infrastructure";
}
organization
"IETF ANIMA Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/anima/>
WG List: <mailto:anima@ietf.org>
Author: Steffen Fries
<mailto:steffen.fries@siemens.com>
Author: Eliot Lear
<mailto: lear@cisco.com>
Author: Thomas Werner
<mailto: thomas-werner@siemens.com>
Author: Michael Richardson
<mailto: mcr+ietf@sandelman.ca>";
description
"This module defines the format for a voucher-request.
It is a superset of the voucher itself.
It provides content to the MASA for consideration
during a voucher-request.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8995; see the
RFC itself for full legal notices.";
revision 2021-12-16 {
description
"Initial version";
reference
"RFC XXXX: BRSKI for Pledge in Responder Mode";
}
// Top-level statement
rc:yang-data voucher-request-prm-artifact {
// YANG data template for a voucher-request.
uses voucher-request-prm-grouping;
}
// Grouping defined for future usage
grouping voucher-request-prm-grouping {
description
"Grouping to allow reuse/extensions in future work.";
uses vcr:voucher-request-grouping {
refine "voucher/expires-on" {
mandatory false;
description
"An expires-on field is not valid in a
voucher-request, and any occurrence MUST be ignored.";
}
refine "voucher/pinned-domain-cert" {
mandatory false;
description
"A pinned-domain-cert field is not valid in a
voucher-request, and any occurrence MUST be ignored.";
}
refine "voucher/last-renewal-date" {
description
"A last-renewal-date field is not valid in a
voucher-request, and any occurrence MUST be ignored.";
}
refine "voucher/domain-cert-revocation-checks" {
description
"The domain-cert-revocation-checks field is not valid in a
voucher-request, and any occurrence MUST be ignored.";
}
refine "voucher/assertion" {
mandatory false;
description
"Any assertion included in registrar voucher-requests
SHOULD be ignored by the MASA.";
}
augment voucher {
description "Base the voucher-request-prm upon the
regular one";
leaf agent-signed-data {
type binary;
description
"The agent-signed-data field contains a JOSE [RFC7515]
object provided by the Registrar-Agent to the Pledge.
This artifact is signed by the Registrar-Agent
and contains a copy of the pledge's serial-number.";
}
leaf agent-provided-proximity-registrar-cert {
type binary;
description
"An X.509 v3 certificate structure, as specified by
RFC 5280, Section 4, encoded using the ASN.1
distinguished encoding rules (DER), as specified
in ITU X.690.
The first certificate in the registrar TLS server
certificate_list sequence (the end-entity TLS
certificate; see RFC 8446) presented by the
registrar to the registrar-agent and provided to
the pledge.
This MUST be populated in a pledge's voucher-request
when an agent-proximity assertion is requested.";
reference
"ITU X.690: Information Technology - ASN.1 encoding
rules: Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)
RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile
RFC 8446: The Transport Layer Security (TLS)
Protocol Version 1.3";
}
leaf-list agent-sign-cert {
type binary;
min-elements 1;
description
"An X.509 v3 certificate structure, as specified by
RFC 5280, Section 4, encoded using the ASN.1
distinguished encoding rules (DER), as specified
in ITU X.690.
This certificate can be used by the pledge,
the registrar, and the MASA to verify the signature
of agent-signed-data. It is an optional component
for the pledge-voucher request.
This MUST be populated in a registrar's
voucher-request when an agent-proximity assertion
is requested.
It is defined as list to enable inclusion of further
certificates along the certificate chain if different
issuing CAs have been used for the registrar-agent
and the registrar.";
reference
"ITU X.690: Information Technology - ASN.1 encoding
rules: Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)
RFC 5280: Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile";
}
}
}
}
}
<CODE ENDS>¶
Examples for the pledge-voucher-request are provided in Section 5.1.4.2.¶
This document requires the following IANA actions:¶
IANA is requested to enhance the Registry entitled: "BRSKI well-known URIs" with the following:¶
URI document description pledge-voucher-request [THISRFC] create pledge-voucher-request pledge-enrollment-request [THISRFC] create pledge-enrollment-request pledge-voucher [THISRFC] supply voucher response pledge-enrollment [THISRFC] supply enrollment response pledge-CACerts [THISRFC] supply CA certs to pledge requestenroll [THISRFC] supply PER to registrar¶
The credential used by the registrar-agent to sign the data for the pledge in case of the pledge-initiator-mode should not contain personal information. Therefore, it is recommended to use an LDevID certificate associated with the device instead of a potential service technician operating the device, to avoid revealing this information to the MASA.¶
Exhaustion attack on pledge based on DoS attack (connection establishment, etc.)¶
A Registrar-agent that uses acquired voucher and enrollment response for domain 1 in domain 2 can be detected by the pledge-voucher-request processing on the domain registrar side. This requires the domain registrar to verify the proximity-registrar-cert leaf in the pledge-voucher-request against his own LDevID(Reg). In addition, the domain registrar has to verify the association of the pledge to his domain based on the product-serial-number contained in the pledge-voucher-request and in the IDevID certificate of the pledge. Moreover, the registrar verifies the authorization of the registrar agent to deliver pledge-voucher-requests, based on the LDevID(RegAgt) EE certificate information contained in this request.¶
Misbinding of a pledge by a faked domain registrar is countered as described in BRSKI security considerations (section 11.4).¶
Concerns have been raised, that there may be opportunities to misuse the registrar-agent with a valid LDevID. This may be addressed by utilizing short-lived certificates (e.g., valid for a day) to authenticate the registrar-agent against the domain registrar. The LDevID certificate for the registrar-agent may be provided by a prior BRSKI execution based on an existing IDevID. Alternatively, the LDevID may be acquired by a service technician after authentication against the issuing CA.¶
The enhanced voucher-request described in section Section 6.1 bases on [RFC8995], but uses a different encoding, based on [I-D.ietf-anima-jws-voucher]. Therefore, similar considerations as described in Section 11.7 (Security Considerations) of [RFC8995] apply. The YANG module specified in this document defines the schema for data that is subsequently encapsulated by a JOSE signed-data content type, as described [I-D.ietf-anima-jws-voucher]. As such, all of the YANG-modeled data is protected from modification. The use of YANG to define data structures, via the "yang-data" statement, is relatively new and distinct from the traditional use of YANG to define an API accessed by network management protocols such as NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason, these guidelines do not follow the template described by Section 3.7 of [RFC8407].¶
We would like to thank the various reviewers, in particular Brian E. Carpenter and Oskar Camenzind, for their input and discussion on use cases and call flows.¶
From IETF draft 01 -> IETF draft 02:¶
From IETF draft 00 -> IETF draft 01:¶
From IETF draft-ietf-anima-brski-async-enroll-03 -> IETF anima-brski-prm-00:¶
From IETF draft 02 -> IETF draft 03:¶
From IETF draft 01 -> IETF draft 02:¶
From IETF draft 00 -> IETF draft 01:¶
From individual version 03 -> IETF draft 00:¶
From individual version 02 -> 03:¶
From individual version 01 -> 02:¶
From individual version 00 -> 01:¶