Autonomic Networking Integrated Model and Approach B. E. Carpenter Internet-Draft Univ. of Auckland Intended status: Standards Track 21 July 2026 Expires: 22 January 2027 One-time Pad for Authorizing Device Identity draft-carpenter-anima-otp-casa-00 Abstract This document describes how devices joining an autonomic control plane as defined in RFC 8994 may use the bootstrapping mechanism defined in RFC 8995 even if they cannot use a manufacturer-installed X.509 certificate. Instead, such devices may generate a self-signed certificate embedding a unique token selected from a one-time pad. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://becarpenter.github.io/otp-casa/draft-carpenter-anima-otp- casa.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-carpenter-anima-otp-casa/. Discussion of this document takes place on the Autonomic Networking Integrated Model and Approach Working Group mailing list (mailto:anima@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/anima/. Subscribe at https://www.ietf.org/mailman/listinfo/anima/. Source for this draft and an issue tracker can be found at https://github.com/becarpenter/otp-casa. 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/. Carpenter Expires 22 January 2027 [Page 1] Internet-Draft One-time Pad for Device Identity July 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Corporate Authorized Signing Authority (CASA) . . . . . . . . 3 4. Authorized Installer . . . . . . . . . . . . . . . . . . . . 3 5. Connecting a Pledge . . . . . . . . . . . . . . . . . . . . . 4 6. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 10.2. Informative References . . . . . . . . . . . . . . . . . 6 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 6 A.1. Draft-00 . . . . . . . . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 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 Carpenter Expires 22 January 2027 [Page 2] Internet-Draft One-time Pad for Device Identity July 2026 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. Carpenter Expires 22 January 2027 [Page 3] Internet-Draft One-time Pad for Device Identity July 2026 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. Carpenter Expires 22 January 2027 [Page 4] Internet-Draft One-time Pad for Device Identity July 2026 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 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021, . Carpenter Expires 22 January 2027 [Page 5] Internet-Draft One-time Pad for Device Identity July 2026 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, May 2021, . 10.2. Informative References [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, May 2018, . [RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, L., and J. Nobre, "A Reference Model for Autonomic Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021, . [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An Autonomic Control Plane (ACP)", RFC 8994, DOI 10.17487/RFC8994, May 2021, . Appendix A. Change Log A.1. Draft-00 * Original version Acknowledgements Helpful comments were made by Michael Richardson, ... Author's Address Brian E. Carpenter The University of Auckland School of Computer Science The University of Auckland PB 92019 Auckland 1142 New Zealand Email: brian.e.carpenter@gmail.com Carpenter Expires 22 January 2027 [Page 6]