Bootstrapping Remote Secure Key Infrastructure (BRSKI)
Extracted elements (27)
No key usage restrictions are RECOMMENDED in the IDevID certificate because these long-lived certificates (intended to last the device's lifetime) would be permanently limited by any restrictions added at manufacture time. RFC 5280 Section 4.2.1.3 does not require key usage restrictions for end-entity certificates, and 802.1AR acknowledges that restrictions limit applicability.
Prior approaches (TOFU, call-home, pre-staging) either require human intervention, expose domain identity to the manufacturer, or require real-time manufacturer connectivity and transfer authorization responsibility to the manufacturer. BRSKI uses signed vouchers so the manufacturer authorizes only which registrar the pledge may trust; the registrar retains policy control, connectivity to the MASA is needed only during bootstrapping, and no out-of-band user action is required.
BRSKI as specified is not suitable for constrained devices (below Class 2 per RFC 7228) on challenged networks such as 802.15.4 LLNs. The large credential and key sizes required for device authentication risk congestion collapse or energy exhaustion of battery-powered intermediate routers. Constrained device support requires defining symmetric key techniques with sufficient algorithm agility, which is out of scope for this document.
A pledge with a real-time clock in which it has confidence MUST check time fields in all certificates and signatures it processes, including registrar certificate notBefore/notAfter, voucher created-on/expires-on, and CMS signingTime. A pledge without a reliable clock MAY ignore all timestamps.
Each connection attempt through a distinct Join Proxy MUST have a unique nonce in the voucher-request. The proxy MUST NOT assume any specific TLS version and passes TLS bytes without examination.
For ANI devices, the pledge MUST perform proxy discovery by listening for DULL GRASP M_FLOOD AN_Proxy announcements (RFC 8990). ANI proxies MUST support GRASP discovery of registrars. The ACP-secured instance of GRASP MUST be used for ANI registrar discovery.
If the voucher contains a nonce, the pledge MUST confirm the nonce matches the original pledge voucher-request nonce. This ensures the voucher is fresh and bound to this particular bootstrapping attempt.
The pledge MUST initiate BRSKI after boot if it is unconfigured, and MUST NOT automatically initiate BRSKI if it has been configured or is in the process of being configured.
The pledge voucher-request MUST contain a cryptographically strong random or pseudo-random nonce (per RFC 4086 Section 6.2). Different nonces MUST be generated for each bootstrapping attempt, whether in series or concurrently, to ensure freshness and prevent replay.
The registrar AN_join_registrar M_FLOOD message MUST be sent periodically; the default period SHOULD be 60 seconds, SHOULD be operator configurable, and SHOULD NOT be smaller than 60 seconds. Registrars MUST announce all supported protocols and MUST support TCP traffic.
The registrar MUST use HTTPS for the BRSKI-MASA connection, regardless of what scheme or path may appear in the MASA URI extension. The registrar MUST again extract the serialNumber itself from the pledge's TLS certificate rather than relying on the value in the pledge voucher-request.
The subject field DN encoding in the client TLS certificate MUST include the 'serialNumber' attribute with the device's unique serial number. Registrars SHOULD be configurable on a per-manufacturer basis to look for serial-number equivalents in other certificate fields.
TLS 1.2 or newer is REQUIRED on the pledge side for the BRSKI-EST connection. TLS 1.3 or newer SHOULD be available on both registrar and MASA server interfaces, though TLS 1.2 MAY be used on those interfaces.
Upon successfully validating a voucher artifact, the pledge MUST return a status telemetry message to the registrar (see Section 5.7). ANI pledges MUST also implement the EST automation extensions described in Section 5.9.
The BRSKI-MASA channel reveals the pledge's serial number (and thus device type and manufacturing batch), the registrar's certificate (identifying the domain owner/operator), and timestamps of bootstrapping events to the manufacturer. This gives the manufacturer persistent visibility into where and when devices are deployed, which may be undesirable for competitive or operational-security reasons.
The MASA audit-log records anonymized prior ownership history per device and is accessible by the registrar (Section 5.8). It reveals that a device exists and has been bootstrapped, allowing the manufacturer to infer deployment patterns. The log uses a hashed domainID rather than the raw registrar certificate to limit direct identification of domain owners.
BRSKI defines two HTTP REST channels: BRSKI-EST (between pledge and registrar) using the existing EST URI tree plus new paths under '/.well-known/brski', and BRSKI-MASA (between registrar and MASA) using 'https://' authority '/.well-known/brski'. New BRSKI operations use JSON (RFC 8259) with base64-encoded binary values; existing EST operations retain CMS message formats.
The IDevID is an IEEE 802.1AR X.509v3 certificate installed at the factory that authenticates the pledge to the registrar and MASA, uniquely identifies the pledge via X520SerialNumber (id-at-serialNumber), and carries the MASA URI in a new non-critical PKIX extension (id-pe-masa-url, OID id-pe 32). No key usage restrictions are recommended so that these long-lived certificates remain broadly applicable.
The Join Proxy announces itself using a DULL GRASP M_FLOOD message with objective name 'AN_Proxy', loop-count 1 (one hop), TTL 180,000 ms, and an O_IPv6_LOCATOR specifying the proxy's link-local IPv6 address, transport protocol (mandatory: TCP), and an operator-selected port number. The registrar announces itself within the ACP using 'AN_join_registrar' with loop-count 255 and an objective-value naming supported protocols (e.g., 'EST-TLS').
The pledge requests a voucher via HTTPS POST to '/.well-known/brski/requestvoucher' using Content-Type 'application/voucher-cms+json'. The pledge signs the request with its IDevID credentials, populates the 'proximity' assertion, includes the registrar's end-entity TLS certificate in proximity-registrar-cert, and a mandatory cryptographic nonce.
The voucher-request artifact extends RFC 8366 vouchers with two new YANG leaves: 'proximity-registrar-cert' (the end-entity TLS certificate of the registrar, used in pledge requests to assert proximity) and 'prior-signed-voucher-request' (the pledge's signed request forwarded by the registrar to the MASA). Fields created-on, pinned-domain-cert, last-renewal-date, and domain-cert-revocation-checks are not valid in a voucher-request and MUST be ignored.
This document registers the '/.well-known/brski' URI subtree (Section 8.3), the MASA URL PKIX certificate extension id-pe-masa-url (OID id-pe 32, Section 8.4), the YANG module 'ietf-voucher-request' (Section 8.2), GRASP objective names 'AN_Proxy' and 'AN_join_registrar' (Section 8.7), DNS service names for BRSKI (Section 8.6), and a new BRSKI Status Telemetry registry (Section 8.5).
A malicious domain can cause a Denial of Service against the MASA by repeatedly requesting vouchers for devices it does not own, consuming MASA computational and logging resources. The MASA has limited ability to distinguish legitimate from malicious registrars without sales channel integration, making rate limiting and audit mechanisms important mitigations.
Compromise of manufacturer IDevID signing keys allows an attacker to issue fraudulent IDevIDs and impersonate devices; compromise of MASA signing keys allows issuance of fraudulent vouchers directing pledges to untrusted registrars. Manufacturers must maintain robust key management and revocation procedures for both IDevID CA and MASA signing keys.
The domainID (derived from the registrar's CA certificate, see Section 5.8.2) MUST be computed using a hash function resistant to second-preimage attacks. A collision attack on domainID would allow an attacker to spoof a legitimate domain's identity in the MASA audit-log.
The pledge follows a five-state bootstrap sequence: (1) Discover a registrar via proxy, (2) Identify itself using IDevID in a TLS handshake, (3) Request Join by submitting a voucher-request with a nonce, (4) Imprint by validating the MASA-issued voucher, and (5) Enroll via EST to obtain a domain certificate. The device returns to the Discover state only after a factory reset.
The MASA URI PKIX extension is encoded as an IA5String identified by OID id-pe-masa-url (id-pe 32). Typically only the 'authority' component is stored; the registrar infers scheme 'https://' and path '/.well-known/brski' when no slash character appears in the value. A complete URI including scheme, authority, and path MAY be stored for diagnostics.