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

Introduction The Bootstrapping Remote Secure Key Infrastructure (BRSKI) onboarding 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 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 ) 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. 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 , 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.

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.

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 , 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). At this point, the ODevID becomes functionally equivalent to the LDevID (Local Device Identifier) discussed in RFC8995. TBD: update the YANG in RFC8995 accordingly.

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

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. 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 . 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. The Registrar and the CASA are trustworthy because they constitute a corporate entity and can present an end-entity certificate satisfying corporate security requirements.

Implementation Status [RFC Editor: please remove] See for a proof of concept. It's amateur code from a security point of view. DO NOT trust it in the slightest.

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

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. 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 [RFC Editor: please remove]

Draft-00

• Original version

Draft-01

• Many changes after a proof-of-concept implementation.

Draft-02

• Indicate that ODevID is also an LDevID

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