]> 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 IDevID MASA 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 The latest revision of this draft can be found at . 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 The Bootstrapping Remote Secure Key Infrastructure (BRSKI) mechanism is specified in . 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) is known as a "pledge", and the purpose of BRSKI is to authorize a pledge by obtaining a voucher 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 ) is altered as described in .

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.

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.

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.

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 , using the ODevID in place of an IDevID.

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.

Trust Model Section 7.1 of 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.

Security Considerations The security considerations of apply in general. However, the trust model is modified, as discussed in . Also, sections 7.3 and 7.4 of 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???

IANA Considerations No IANA actions are required by this document.

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. 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. This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.

Change Log

Draft-00

• Original version

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