Autonomic Networking Integrated Model and Approach B. E. Carpenter Internet-Draft Univ. of Auckland Intended status: Standards Track 17 September 2026 Expires: 21 March 2027 Quick and Dirty Secure Autonomic Control Plane for GRASP draft-carpenter-anima-quads-grasp-04 Abstract A secure substrate known as the Autonomic Control Plane (ACP) is required by the Generic Autonomic Signaling Protocol (GRASP) used by Autonomic Service Agents. This document describes QUADS, a QUick And Dirty Secure ACP using symmetric cryptography and preconfigured key material. It also describes a secure mechanism for providing the prefconfigured key material to enrolled ACP nodes via EST. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-carpenter-anima-quads-grasp/. 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/. 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." Carpenter Expires 21 March 2027 [Page 1] Internet-Draft Quick and Dirty Secure ACP September 2026 This Internet-Draft will expire on 21 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. QUick And Dirty Security ACP Method . . . . . . . . . . . . . 3 4. QUick And Dirty Security Key Distribution (QUADSKD) . . . . . 4 5. Implementation Status [RFC Editor: please remove] . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Change Log [RFC Editor: please remove] . . . . . . . 7 A.1. Draft-00 . . . . . . . . . . . . . . . . . . . . . . . . 7 A.2. Draft-01 . . . . . . . . . . . . . . . . . . . . . . . . 7 A.3. Draft-02 . . . . . . . . . . . . . . . . . . . . . . . . 7 A.4. Draft-03 . . . . . . . . . . . . . . . . . . . . . . . . 7 A.5. Draft-04 . . . . . . . . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction As defined in [RFC8993], the Autonomic Service Agent (ASA) is the atomic entity of an autonomic function, and it is instantiated on autonomic nodes. When ASAs communicate with each other, they should use the Generic Autonomic Signaling Protocol (GRASP) [RFC8990]. It is essential that such communication is strongly secured to avoid malicious interference with the Autonomic Network Infrastructure (ANI). This includes link-local multicast messages which are an essential part of GRASP. Carpenter Expires 21 March 2027 [Page 2] Internet-Draft Quick and Dirty Secure ACP September 2026 For this reason, GRASP must run over a secure substrate that is isolated from regular data plane traffic. This substrate is known as the Autonomic Control Plane (ACP). A method for constructing an ACP at the network layer is described in [RFC8994]. The present document describes a simple method of forming an ACP immediately above the transport layer, known as QUADS (QUick And Dirty Security) ACP for GRASP. QUADS depends on all ACP nodes sharing preconfigured key material for symmetric cryptography. This document also describes a secure mechanism to distribute this key material to all ACP nodes that have duly enrolled using the Bootstrapping Remote Secure Key Infrastructure (BRSKI) onboarding mechanism specified in [RFC8995] or a variant such as [I-D.carpenter-anima-otp-casa]. 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. [RFC8995] uses the term "pledge" to refer to a node that onboards itself via the BRSKI process. 3. QUick And Dirty Security ACP Method Every GRASP message, whether unicast or multicast, is encrypted immediately before transmission, and decrypted immediately after reception, using the same symmetric encryption algorithm and domain- wide shared key material. This applies to all unicast and multicast messages sent over either UDP or TCP. Typically encryption will take place immediately after a message is encoded as CBOR [RFC7049], and decryption will take place immediately before a message is decoded from CBOR. There is no attempt to specify an automatic algorithm choice. Every instance of GRASP in a given Autonomic Network (AN) must be pre- configured with the choice of encryption algorithm and any necessary parameters, and provided with the same key material. Carpenter Expires 21 March 2027 [Page 3] Internet-Draft Quick and Dirty Secure ACP September 2026 An alternative to configuring the key material is that every instance of GRASP is pre-configured with a fixed salt value and the key material is created from a domain-wide keying password, using a pre- defined hash algorithm and a common salt value. Note that the salt value cannot then be secret as it must be the same in all GRASP implementations. In this model the secrecy depends entirely on the keying password. This method is therefore vulnerable and *NOT RECOMMENDED*. The choice of algorithms should follow best current practice, e.g. [RFC8221]. At present the following choices are suggested: AES/CBC, key length 32 bytes, initialisation vector length 16 bytes, padding PKCS7(128). 4. QUick And Dirty Security Key Distribution (QUADSKD) The QUADS key material is distributed by an extension to the EST server mechanism used by the BRSKI registrar described in [RFC8995]. When a BRSKI pledge requires the QUADS key material, either as the last step in onboarding or at any later time, it uses an EST POST request [RFC7030] to obtain the key material. The request and response are protected by TLS like any other EST exchange. This is done with an HTTP POST using the operation path value of "/.well-known/brski/requestkey". The media type "application/request-cms+json" is used. It is a JSON document that has been signed by the pledge using a CMS structure. The body of the request is a JSON structure: {"request_key": serial- number} where the serial-number is the pledge's serial number string as defined in [RFC8995]. The registrar *MUST* verify the signature and that the pledge is already enrolled. The body of the response is a JSON structure: {"key": key-value, "iv": iv-value} where the key and initialization vector values are binary objects encoded once in base64 in order to be transported in this JSON container. It is signed by the BRSKI registrar using a CMS structure. On receipt, the pledge *MUST* verify the signature and save these values as securely as possible for use by GRASP instances within the pledge. TBD: consider extending the requestkey response format to specify the symmetric algorithm choices. TBD: extend the YANG in RFC8995 accordingly. Carpenter Expires 21 March 2027 [Page 4] Internet-Draft Quick and Dirty Secure ACP September 2026 5. Implementation Status [RFC Editor: please remove] QUADS for GRASP has been implemented as a small extension to the Python GRASP prototype, using the Python 'cryptography' module. The encryption algorithm choice was: AES/CBC, key lengths 32/16, padding PKCS7(128). See https://github.com/becarpenter/graspy/tree/master/casa for a proof of concept of the key distribution mechanism, associated with the CASA mechanism [I-D.carpenter-anima-otp-casa]. It's amateur code from a security point of view. Do not trust it in the slightest. 6. Security Considerations QUADS provides secrecy for all GRASP messages, against any party not in possession of the relevant shared key material. However, before a GRASP message is encrypted or after it is decrypted, it is not protected within the host. Therefore, secrecy is only effective against nodes that do not contain a GRASP instance in possession of the key material. Those nodes cannot send valid GRASP messages, and they cannot interpret intercepted GRASP messages, including multicasts. However, they might attempt traffic analysis. A weakness is that QUADS uses a shared and constant initialization vector for CBC. This is not considered best practice as it assists post facto cryptanalysis, especially since many GRASP messages start with the same or similar plaintext. QUADS provides authentication of GRASP instances to the extent that they must be in possession of the relevant shared key material. QUADS depends on pre-configuration of key material, or on password entry and a public salt value, for each autonomic node, unless QUADSKD (Section 4) is in use. QUADS offers no defence against denial of service attacks. QUADSKD securely avoids the need for pre-configuration of keys except in a central server. It could also form the basis for defining a re- keying mechanism. 7. IANA Considerations TBD 8. References 8.1. Normative References Carpenter Expires 21 March 2027 [Page 5] Internet-Draft Quick and Dirty Secure ACP September 2026 [I-D.carpenter-anima-otp-casa] Carpenter, B. E., "One-time Pad for Authorizing Device Identity", Work in Progress, Internet-Draft, draft- carpenter-anima-otp-casa-01, 3 September 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, . [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic Autonomic Signaling Protocol (GRASP)", RFC 8990, DOI 10.17487/RFC8990, May 2021, . [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, . Carpenter Expires 21 March 2027 [Page 6] Internet-Draft Quick and Dirty Secure ACP September 2026 8.2. Informative References [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [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 [RFC Editor: please remove] A.1. Draft-00 Initial version A.2. Draft-01 Added QUADSKI A.3. Draft-02 Added crypto details on QUADSKI Minor corrections and clarifications A.4. Draft-03 Added ACP terminology Updated to xml2rfcv3 A.5. Draft-04 Scrapped QUADSKI (would only work for RSA, incompatible with ECDSA) Deprecated password-based manual keying. Added QUADSKD (BRSKI/EST based) Fixed many details and references Carpenter Expires 21 March 2027 [Page 7] Internet-Draft Quick and Dirty Secure ACP September 2026 Updated to kramdown-rfc Acknowledgements Helpful comments were made by TBD, ... 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 21 March 2027 [Page 8]