One-time Pad for Authorizing Device Identity
draft-carpenter-anima-otp-casa-01

Autonomic Networking Integrated Model and Approach       B. E. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Standards Track                        3 September 2026
Expires: 7 March 2027

              One-time Pad for Authorizing Device Identity
                   draft-carpenter-anima-otp-casa-01

Abstract

   This document describes how devices joining an autonomic control
   plane as defined in RFC 8994 may use the BRSKI onboarding mechanism
   defined in RFC 8995, even if they cannot provide a manufacturer-
   installed X.509 IDevID 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 7 March 2027                  [Page 1]
Internet-Draft      One-time Pad for Device Identity      September 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 7 March 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Corporate Authorized Signing Authority (CASA) . . . . . . . .   3
   4.  Authorized Installer  . . . . . . . . . . . . . . . . . . . .   4
   5.  Connecting a Pledge . . . . . . . . . . . . . . . . . . . . .   4
   6.  Authorization . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Trust Model . . . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Implementation Status [RFC Editor: please remove] . . . . . .   6
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     11.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Appendix A.  Change Log [RFC Editor: please remove] . . . . . . .   7
     A.1.  Draft-00  . . . . . . . . . . . . . . . . . . . . . . . .   7
     A.2.  Draft-01  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

Carpenter                 Expires 7 March 2027                  [Page 2]
Internet-Draft      One-time Pad for Device Identity      September 2026

1.  Introduction

   The Bootstrapping Remote Secure Key Infrastructure (BRSKI) onboarding
   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 much of 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.  It is in effect
   a one-time pad.

   The CASA is essentially based on a list of randomly generated tokens.
   The tokens MUST be hard to guess, with a minimum size of at least 64
   bits.  They SHOULD be cryptographically strong random or pseudo-
   random numbers (see [RFC4086], Section 6.2).

   The list of tokens 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.

Carpenter                 Expires 7 March 2027                  [Page 3]
Internet-Draft      One-time Pad for Device Identity      September 2026

4.  Authorized Installer

   This is a person or agent that is trusted to authorize new devices to
   connect to the network.  Whenever needed, each Installer is given a
   new batch of random tokens, called an APADL (Agent one-time-PAD List,
   pronounced "a Paddle").  These tokens are also added to the OPADL
   when the APADL is created.  The APADL 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 MUST be made, along with the
   identity of the Installer, for audit purposes.  This record MUST be
   associated with the OPADL, and stored on long-term, backed-up and
   cryptographically secured storage.

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

5.  Connecting a Pledge

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

   1.  The Installer's software picks a token from the APADL.

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

   3.  The pledge then executes code to create and save 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.  However, because the ODevID is
   self-signed and thus has no CA issuer, the RFC8995 voucher request is
   augmented by adding a pledge-self-cert binary element which carries
   the ODevID certificate.  This is used by the registrar to verify the
   signed voucher request, and the registrar *SHOULD* retain this
   certificate (which includes the token, i.e. serial number).

   TBD: update the YANG in RFC8995 accordingly.

Carpenter                 Expires 7 March 2027                  [Page 4]
Internet-Draft      One-time Pad for Device Identity      September 2026

6.  Authorization

   In practice, the CASA and the Registrar will be a single software
   system, so no network protocol is needed between them.  When the
   Registrar receives a voucher request via EST, as per [RFC8995], it
   will pass the request directly to the CASA.  Instead of the checks
   normally carried out by a MASA, the CASA 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
   "claimed" in the OPADL, and issue the required voucher directly to
   the Registrar, 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 "claimed" MUST be an
   atomic operation.

   Clearly, a bogus token will fail.  In the highly unlikely event that
   two pledges try the same token, the second Installer simply tries
   again with another token from their APADL.  The same would apply if a
   voucher request failed in such a way that a token was marked as
   "claimed" by the CASA but the voucher never reached the pledge.

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.  It also removes any security exposures during
   communication between the Registrar and the MASA.

   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
   compromised APADL is real, but can be traced after the event using
   logs from the CASA.  If an APADL should be physically lost, all its
   tokens MUST immediately be marked as claimed in the OPADL.

   The ODevIDs are self-signed.  This is acceptable because each ODevID
   certificate includes a unique token from the OPADL, and so can be
   trusted exactly to the extent that the Installer is trusted.
   However, this means that the BRSKI-EST TLS connection cannot rely on
   a CA-signed IDevID as described in Section 5.1 of [RFC8995].  It
   *SHOULD* rely on whatever corporate or general PKI is already in
   place in the pledge.  In a stand-alone environment, an alternative is
   to accept self-signed CMS structures.

Carpenter                 Expires 7 March 2027                  [Page 5]
Internet-Draft      One-time Pad for Device Identity      September 2026

   The Registrar and the CASA are trustworthy because they constitute a
   corporate entity and can present an end-entity certificate satisfying
   corporate security requirements.

8.  Implementation Status [RFC Editor: please remove]

   See https://github.com/becarpenter/graspy/blob/master/casa for a
   proof of concept.  It's amateur code from a security point of view.
   DO NOT trust it in the slightest.

9.  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 removes the need for some of these
   reductions, since it caters for devices without manufacturer or
   ownership credentials.  For example, nonceless vouchers are never
   needed since the Registrar and the CASA are colocated.

   However, since the pledge is issued a voucher on the basis of a self-
   signed certificate, there is a plausible man-in-the middle attack by
   a rogue BRSKI proxy, if it intercepts a voucher request, extracts the
   token value, creates its own key pair, and simulates all subsequent
   pledge actions.  Similarly, a rogue registrar could accept any pledge
   without checking that its token is known to the genuine CASA
   registrar.  Only good operational security can protect against such
   attacks.

   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.

10.  IANA Considerations

   No IANA actions are required by this document.

11.  References

11.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,
              <https://www.rfc-editor.org/info/rfc2119>.

Carpenter                 Expires 7 March 2027                  [Page 6]
Internet-Draft      One-time Pad for Device Identity      September 2026

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
              Autonomic Signaling Protocol (GRASP)", RFC 8990,
              DOI 10.17487/RFC8990, May 2021,
              <https://www.rfc-editor.org/info/rfc8990>.

   [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, <https://www.rfc-editor.org/info/rfc8995>.

11.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,
              <https://www.rfc-editor.org/info/rfc8366>.

   [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,
              <https://www.rfc-editor.org/info/rfc8993>.

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
              Autonomic Control Plane (ACP)", RFC 8994,
              DOI 10.17487/RFC8994, May 2021,
              <https://www.rfc-editor.org/info/rfc8994>.

Appendix A.  Change Log [RFC Editor: please remove]

A.1.  Draft-00

   *  Original version

A.2.  Draft-01

   *  Many changes after a proof-of-concept implementation

Carpenter                 Expires 7 March 2027                  [Page 7]
Internet-Draft      One-time Pad for Device Identity      September 2026

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 7 March 2027                  [Page 8]