]> Cisco Systems

jamohamm@cisco.com

Cisco Systems

rehaddad@cisco.com

Cisco Systems

srihari@cisco.com

Cisco Systems

sandeshr@cisco.com

Internet Anima Working Group Internet-Draft This document describes an extension of the RFC8366 Voucher Artifact in order to support security profiles. This allows the owner to change and customize the security posture of the device dynamically and securely. This lets the owner to selectively enable or disable each of the underlying security parameters that make up the security posture of the device.

Introduction The voucher artifact provides a proof from a manufacturer's authorizing signing authority (MASA) of the intended owner of a device. This is used by an onboarding Pledge device in BRSKI (, ), and SZTP (). The security profile for a device can be defined as a sum collection of the settings of the different underlying security parameters that determine the overall security posture of a device. There are many reasons for the need and they include:

• The values and combinations of values of these underlying security parameters are better customized and selected dynamically during run time to allow maximum flexibility for the owner and thus prevent hardcoding during device manufacturing workflows.
• There are cases where the security posture of the devices are not known or not possible to be configured till the end customer takes ownership of the devices. In these cases, it is not possible to do this during manufacturing workflows.
• The value added security profile settings facilitate ease of use for the owner to select the combination of security parameters that best suites the fine-grained security posture requirements for different devices that belong to the owner.
• The scaling requirement to automate customization and configuration of the security posture for each device at scale is made possible.
• The underlying security parameters are envisaged to be types of parameters that influence a system wide security posture of a device that are better configured at the initial provisioning phases.
• The underlying security parameters are sensitive and critical enough that any change to these parameters need to be authenticated before applying the same.
• The enumeration and standardization of the security profiles can potentially help achieve security posture interoperability in devices from different vendors.

Overview of Proposed Solution There are various underlying security parameters that are possible. These can be divided into Common, OEM specific and Reserved (for future use). Some examples of common and standard ones (others may be added in future revisions of the draft) are below.

• Enable or disable Secure Zero Touch Provisioning (SZTP). This could be used in cases where disabling sZTP is required.
• Enable or disable Federal Information Processing Standards (FIPS) mode support. This could be needed where FIPS mode need to be disabled or enabled depending on deployment scenarios.
• Enable or disable Linux Integrity Measurement Architecture (IMA) enforcement. This could be needed where IMA measurement is the need while appraisal is not.

Extensions to standards-based RFC8366 Voucher Artifact handles different and varying security postures for the owner that would have otherwise needed complex manufacturing end-customer security profile handling and tracking. In the context of standalone EST [RFC 7030] or BRSKI-EST [RFC 8995] protocol, the owner's security policies can be sent as a policy update during LDevID renewal via BRSKI-EST link with new actions and the policy data can be an update signed by domain CA. However, to keep it nice and simple and in the context of the nature of the policies addressed here (i.e., may need security gates, under manufacturer's purview, to be opened in the device and licensing aspects to be addressed with the vendor or manufacturer), it is thought that it could be better served via voucher extensions, that includes MASA in the loop. This allows ease of use and management for owners by providing secure ways for dynamic changes and alteration of security postures for the owner, at scale. The OEM specific aspects are kept private while the Reserved aspects are reserved for future use.

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.

Security Profile Voucher:

A security profile voucher is an format voucher that has additional fields to provide configuration details of all the underlying security parameters that determine the overall security posture of the device under consideration.

Security Profile Voucher Artifact The following tree diagram shows the extensions to the voucher. There are a few new fields:

security-profile-enable-flag:

A global enable flag to the pledge that security profiles for this pledge is enabled(true) or not (false). With default, this flag is false, which is consistent with the voucher artifact in RFC8366.

security-profile-selector:

Bitmask value of all the underlying security parameters

YANG Module This module uses the grouping that was created in to extend the definition. WG List: Author: Srihari Raghavan "; description "This module extends the RFC8366 voucher format to provide a mechanism by which the authority can configure the security posture of the device. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described in BCP 14 RFC 2119, and RFC8174."; revision "2024-05-26" { description "Updates to security profile aspects"; reference "RFC XXXX: Voucher extensions for security profile"; } revision "2023-11-27" { description "Updates to security profile aspects"; reference "RFC XXXX: Voucher extensions for security profile"; } revision "2023-05-30" { description "Initial version"; reference "RFC XXXX: Voucher extensions for security profile"; } feature security-profile-ietf { description "This feature indicates that the IETF version of the security profile feature is supported"; reference "RFC XXXX: Voucher extensions for security profile"; } feature security-profile-oem { description "This feature indicates that the oem version of the security profile feature is supported. The OEM list is expected to be based on https://www.iana.org/assignments/enterprise-numbers/ (PENs)."; reference "RFC XXXX: Voucher extensions for security profile"; } rc:yang-data voucher-security-profile-artifact { // YANG data template for a voucher. uses voucher-security-profile-grouping; } typedef bitmask64 { type uint64; description "The bitmask64 type represents a non-negative integer that represents a bit mask type field with each bit set (or unset) representing a different intent along with a range of bits/values representing a group. Using an appropriate mask, the individual bits can be set/reset. In addition, a range of bits can also be manipulated using an appropriate mask. The 'type bits' and 'position' yang based bit fields do not lend itself easily to range based comparisons and hence the need for a customized type definition. The bitmask64 type can be used for configuration schema nodes. A default statement can be used in combination with the type bitmask64."; reference "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; } // Grouping for security parameters forming the security profile // // These are separated into two-groups: standardized and OEM. // // The security-parameters-standard are subject to standards definition // for inter-operability while the OEM range is expected to be // implementation dependent. // // // The specific bits are expected to be defined // following discussions with WG members and some examples // could be FIPS mode handling, SELinux handling, // Linux IMA handling etc., which could decide the // overall security posture of a device."; // // grouping security-parameters-group { leaf security-params-value { type bitmask64; description "Bit map for the different underlying security parameters. This is only valid if security-profile-enable-flag is true. Range: - 0x1, 0x2, 0x4..0x8000..0x10000.. "; } leaf security-params-mask { type bitmask64; description "This represents the mask for the value above. If this mask is on for a bit, the corresponding value of the bit will be treated accordingly. If the mask is off, the value of the bit could be treated as a don't care or default value"; } description "The underlying security profile parameters."; } grouping security-parameters { container security-parameters-standard { if-feature security-profile-ietf; description "Security profiles based on IETF version."; leaf enabled { type boolean; default false; description "When true, IETF version of security profiles MUST be processed."; } uses security-parameters-group; } container security-parameters-oem { if-feature security-profile-oem; description "Security profiles based on OEM version."; leaf enabled { type boolean; default false; description "When true, OEM version of security profiles MUST be processed."; } uses security-parameters-group; } description "Security profile parameters."; } grouping voucher-security-profile-grouping { description "Grouping to allow reuse/extensions in future work."; uses iv:voucher-artifact-grouping { augment "voucher" { description "Base the security profile voucher upon the regular voucher"; leaf security-profile-enable-flag { type boolean; description "A global enable flag to the pledge that security profiles for this pledge is enabled(true) or not (false). With default, this flag is false, which is consistent with the voucher artifact in RFC8366. "; } uses security-parameters; } } } } ]]>

Enhanced Pledge Behavior The use of a security profile voucher requires changes to how the pledge evaluates the voucher that is returned to by the Registrar. If the pledge supports this extension, it looks for security-profile-enable-flag and if set, the security-profile-selector MUST be processed.

Changes to Domain Components' Behavior The Registrar (Join Registrar or Co-ordinator) is the representative of the domain that is configured to decide whether a new device is allowed to join a domain. The Manufacturer Authorized Signing Authority (MASA) signs vouchers and if the extensions are supported, it MUST process a security profile selector request from owner that identifies what underlying security parameters need to be enabled in the security-profile-selector to be sent down to the pledge as part of these extensions. As outlined in RFC 8995, the domain Registrar authenticates the pledge, makes authorization decisions, and distributes vouchers obtained from the MASA service and this is not expected to change. The security profile selector request from owner could take the form of a programmatic API based parameterized interaction with the MASA service.

Privacy Considerations TBD

Security Considerations TBD

IANA Considerations This document requires the following IANA actions:

The IETF XML Registry This document registers a URI in the "IETF XML Registry" . IANA is asked to register the following:

YANG Module Names Registry This document registers a YANG module in the "YANG Module Names" registry . IANA is asked to register the following:

Implementation Considerations Implementation of the proposal is under active development.

Acknowledgements The authors would like to thank Michael Richardson and Esko Dijk for their valuable comments and guidance.

Changelog

References Normative References 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. 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. 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. Sandelman Software Works vanderstok consultancy Cisco Systems IoTconsultancy.nl This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (Constrained BRSKI) protocol, which provides a solution for secure zero-touch bootstrapping of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. Constrained BRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher is typically encoded in JSON, Constrained BRSKI defines a compact CBOR-encoded voucher. The BRSKI voucher is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS. 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. Informative References This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems. This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]

Extra references RFC Editor, please remove this section. This section lists references in the YANG. , .