]> The University of Auckland

School of Computer Science The University of Auckland PB 92019 Auckland 1142 New Zealand brian.e.carpenter@gmail.com

Operations and Management Autonomic Networking Integrated Model and Approach BRSKI ACP 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 Status information for this document may be found at . Discussion of this document takes place on the Autonomic Networking Integrated Model and Approach Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction As defined in , 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) . 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. 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 . 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 or a variant such as .

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 when, and only when, they appear in all capitals, as shown here. uses the term "pledge" to refer to a node that onboards itself via the BRSKI process.

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 , 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. 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. . At present the following choices are suggested: AES/CBC, key length 32 bytes, initialisation vector length 16 bytes, padding PKCS7(128).

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

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 for a proof of concept of the key distribution mechanism, associated with the CASA mechanism . It's amateur code from a security point of view. Do not trust it in the slightest.

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 () 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.

IANA Considerations TBD

References Normative References This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and Autonomic Service Agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features. This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. The University of Auckland 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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes a reference model for Autonomic Networking for managed networks. It defines the behavior of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure. Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.

Change Log [RFC Editor: please remove]

Draft-00 Initial version

Draft-01 Added QUADSKI

Draft-02 Added crypto details on QUADSKI Minor corrections and clarifications

Draft-03 Added ACP terminology Updated to xml2rfcv3

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 Updated to kramdown-rfc

Acknowledgements Helpful comments were made by TBD, ...