One-time Pad for Authorizing Device Identity

Status of This Memo

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 22 January 2027.¶

Copyright Notice

Copyright (c) 2026 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.¶

Table of Contents

1. Introduction

The Bootstrapping Remote Secure Key Infrastructure (BRSKI) mechanism is specified in [RFC8995]. It relies on two elements. The first is an X.509v3 certificate formatted as an IEEE 802.1AR IDevID, installed in a device by its manufacturer. The second is a Manufacturer Authorized Signing Authority (MASA), a server that can certify that an IDevID is valid. During the operation of the BRSKI mechanism, a device attempting to join the Autonomic Control Plane (ACP) [RFC8994] is known as a "pledge", and the purpose of BRSKI is to authorize a pledge by obtaining a voucher [RFC8366] from the MASA.¶

In practice, it can happen that either the devices needing to connect do not possess an IDevID, or that the network in question does not have access to a suitable MASA. This document describes a solution for this scenario, while using the existing BRSKI protocol framework.¶

This solution could be applicable to a corporate network that does not use manufacturer-installed IDevIDs at all. Alternatively, in a network using BRSKI for devices with IDevIDs, the solution could be used in a heterogeneous mode for a subset of pledges for which either an IDevID or a MASA is unavailable. In the heterogeneous case, the normal BRSKI trust model for the whole ACP (Section 7.1 of [RFC8995]) is altered as described in Section 7.¶

2. Terminology

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.¶

3. Corporate Authorized Signing Authority (CASA)

This fills the role of the MASA for BRSKI purposes.¶

The CASA is initialized once and once only by creating a list of randomly generated tokens. If the planned network size is N devices, there SHOULD be at least 100N tokens, or at least a million tokens, whichever is greater. This list is referred to as the OPADL (One-time-PAD List, pronounced Oh-Paddle). It MUST be stored on long-term, backed-up and cryptographically secured storage.¶

The tokens MUST be hard to guess, with a minimum size of at least 64 bits.¶

4. Authorized Installer

This is a person or agent that is trusted to authorize new devices to connect to the network. Each Installer is given a batch of tokens randomly chosen from the OPADL, called an APADL (Agent one-time-PAD List, pronounced "a Paddle"). It MUST be stored on secure storage, e.g., an encrypted memory stick in the possession of the Installer.¶

When the CASA creates an APADL, a record of it MUST be made, along with the identity of the Installer, for audit purposes. This record too MUST be stored on long-term, backed-up and cryptographically secured storage.¶

If an APADL is lost or compromised, all the tokens in it MUST be marked as "used" in the OPADL.¶

5. Connecting a Pledge

When an Installer authorizes a new device to connect, the following steps occur:¶

1. The Installer picks a token from the APADL at random.¶

2. This token is installed in the pledge and marked as "used" in the APADL.¶

3. The pledge then executes code to create a key pair and an X.509v3 certificate in IDevID format. It contains contains the token ("serial-number" in BRSKI terms) and the pledge's new public key, and is self-signed. It is referred to as an ODevID (One-time Device ID) but is in effect an LDevID.¶

These steps SHOULD be embedded in code stored on the Installer's secure memory device, such that the token is never viewed by a human.¶

The pledge then starts the normal BRSKI process per [RFC8995], using the ODevID in place of an IDevID.¶

6. Authorization

The CASA will receive a voucher request from the BRKSI Registrar. Instead of the checks normally carried out by a MASA, it will extract the token ("serial-number") from the pledge's ODevID, and check if it is present and unused in the OPADL. If yes, the CASA will mark it as "used" in the OPADL, and issue the required voucher, allowing the BRSKI process to complete. If the token is not available in the OPADL, authorization will fail.¶

The action of checking and marking a token as "used" MUST be an atomic operation.¶

Clearly, a bogus token will fail. In the unlikely event that two agents try the same token, the second agent simply tries again with another token from their APADL.¶

7. Trust Model

Section 7.1 of [RFC8995] summarizes the BRSKI trust model. The present document removes the requirement to trust equipment manufacturers, the integrity of their IDevID creation, and their MASA services. On the other hand, it introduces a need to operate a CASA in a completely secure manner, and a need to trust the authorized Installers, especially their operational security practices that keep the APADLs secure. The risk of fraudulent pledges due to a lost or compromised APADL is real, but can be traced after the event using logs from the CASA.¶

8. Security Considerations

The security considerations of [RFC8995] apply in general. However, the trust model is modified, as discussed in Section 7.¶

Also, sections 7.3 and 7.4 of [RFC8995] allow certain security reductions for BRSKI registrars and MASAs. The mechanism described in the present document reduces the need for such reductions, since it caters for devices without manufacturer or ownership credentials. In addition, the CASA is under local control so could safely be placed on the local side of an air gap. In some scenarios, this may be considered a security advantage.¶

More???¶

9. IANA Considerations

No IANA actions are required by this document.¶

10. References

Appendix A. Change Log

Acknowledgements

Helpful comments were made by Michael Richardson, ...¶

Author's Address