Anima Working Group J. Mohammed Internet-Draft R. Haddad Intended status: Standards Track S. Raghavan Expires: 1 December 2023 S. Rao Cisco Systems 30 May 2023 Security Profiles in Bootstrap Voucher Artifacts draft-mohammed-anima-voucher-security-profile-00 Abstract 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. 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." This Internet-Draft will expire on 1 December 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Mohammed, et al. Expires 1 December 2023 [Page 1] Internet-Draft voucher-security-profile May 2023 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 1.1. Overview of Proposed Solution . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Profile Voucher Artifact . . . . . . . . . . . . . . 4 3.1. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 5 4. Enhanced Pledge Behavior . . . . . . . . . . . . . . . . . . 8 5. Changes to Registrar Behavior . . . . . . . . . . . . . . . . 9 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 9 8.2. YANG Module Names Registry . . . . . . . . . . . . . . . 9 9. Implementation Considerations . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Extra references . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The [RFC8366] 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 ([RFC8995], [I-D.ietf-anima-constrained-voucher]), and SZTP ([RFC8572]). 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: Mohammed, et al. Expires 1 December 2023 [Page 2] Internet-Draft voucher-security-profile May 2023 * 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. 1.1. 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. Mohammed, et al. Expires 1 December 2023 [Page 3] Internet-Draft voucher-security-profile May 2023 * 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. 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. 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. Security Profile Voucher: A security profile voucher is an [RFC8366] 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. 3. Security Profile Voucher Artifact The following tree diagram shows the extensions to the [RFC8366] 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 Mohammed, et al. Expires 1 December 2023 [Page 4] Internet-Draft voucher-security-profile May 2023 module: ietf-voucher-security-profile grouping voucher-security-profile-grouping: +-- voucher +-- created-on yang:date-and-time +-- expires-on? yang:date-and-time +-- serial-number string +-- idevid-issuer? binary +-- pinned-domain-cert? binary +-- domain-cert-revocation-checks? boolean +-- nonce? binary +-- last-renewal-date? yang:date-and-time +-- security-profile-enable-flag? boolean +-- security-profile-selector? bits 3.1. YANG Module This module uses the grouping that was created in [RFC8366] to extend the definition. file "ietf-voucher-security-profile@2022-12-14.yang" module ietf-voucher-security-profile { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-voucher-security-profile"; prefix "security-profile"; import ietf-restconf { prefix rc; description "This import statement is only present to access the yang-data extension defined in RFC 8040."; reference "RFC 8040: RESTCONF Protocol"; } import ietf-voucher { prefix "iv"; } organization "IETF ANIMA Working Group"; contact "WG Web: WG List: Author: Srihari Raghavan "; Mohammed, et al. Expires 1 December 2023 [Page 5] Internet-Draft voucher-security-profile May 2023 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 "2023-05-30" { description "Initial version"; 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 bitmask32 { type uint32; description "The bitmask32 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 bitmask32 type can be used for configuration schema nodes. A default statement can be used in combination with the type bitmask32."; reference "RFC 2578: Structure of Management Information Version 2 (SMIv2)"; } // Grouping for security parameters forming the security profile // Mohammed, et al. Expires 1 December 2023 [Page 6] Internet-Draft voucher-security-profile May 2023 // These are separated into two-groups: standardized and OEM. // // The security-parameters-standard are subject to standards // for inter-operability while the OEM range is expected to be // implementation dependent. // // grouping security-parameters-oem-group { leaf security-params-oem-value { type bitmask32; 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..0x800000000 "; } leaf security-params-oem-mask { type bitmask32; 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 "This grouping represents the OEM group of the security parameters. "; } grouping security-parameters { leaf security-parameters-standard { type bits { bit reserved { position 0; } bit last; } description "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."; } Mohammed, et al. Expires 1 December 2023 [Page 7] Internet-Draft voucher-security-profile May 2023 container security-parameters-oem { uses security-parameters-oem-group; description "This is the overall security parameters for OEMs."; } description "This represents the overall security parameters group that encompasses the standards and oem based 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; } } } } 4. 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. Mohammed, et al. Expires 1 December 2023 [Page 8] Internet-Draft voucher-security-profile May 2023 If the pledge supports this extension, it looks for security-profile- enable-flag and if set, the security-profile-selector MUST be processed. 5. Changes to Registrar Behavior The Registrar is the component that authenticates the pledge, makes authorization decisions, and distributes vouchers. If the extensions are supported, the Registrar MAY process a security profile selector request from owner that identifies what underlying security parameters need to be enabled in the security-profile-selector send down to the pledge as part of these extensions. The registrar MUST enable or disable the underlying security profile parameters to match the security profile selector request. The details of the security profile selector request is beyond the scope of the document, but it is expected that it roughly matches the security-profile-selector fields. 6. Privacy Considerations TBD 7. Security Considerations TBD 8. IANA Considerations This document requires the following IANA actions: 8.1. The IETF XML Registry This document registers a URI in the "IETF XML Registry" [RFC3688]. IANA is asked to register the following: URI: urn:ietf:params:xml:ns:yang:ietf-voucher-security-profile Registrant Contact: The ANIMA WG of the IETF. XML: N/A, the requested URI is an XML namespace. 8.2. YANG Module Names Registry This document registers a YANG module in the "YANG Module Names" registry [RFC6020]. IANA is asked to register the following: Mohammed, et al. Expires 1 December 2023 [Page 9] Internet-Draft voucher-security-profile May 2023 name: ietf-voucher-security-profile namespace:urn:ietf:params:xml:ns:yang:ietf-voucher-security-profile prefix: NONE reference: THIS DOCUMENT 9. Implementation Considerations Implementation of the proposal is under active development. 10. Acknowledgements TBD 11. Changelog 12. References 12.1. Normative References [I-D.ietf-anima-constrained-voucher] Richardson, M., Stok, P. V. D., Kampanakis, P., and E. Dijk, "Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)", Work in Progress, Internet-Draft, draft-ietf-anima-constrained-voucher-20, 7 April 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, May 2018, . [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, . 12.2. Informative References Mohammed, et al. Expires 1 December 2023 [Page 10] Internet-Draft voucher-security-profile May 2023 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero Touch Provisioning (SZTP)", RFC 8572, DOI 10.17487/RFC8572, April 2019, . Appendix A. Extra references RFC Editor, please remove this section. This section lists references in the YANG. [RFC8174], [RFC8040]. Authors' Addresses Jabir Mohammed Cisco Systems Email: jamohamm@cisco.com Reda Haddad Cisco Systems Email: rehaddad@cisco.com Srihari Raghavan Cisco Systems Email: srihari@cisco.com Sandesh Rao Cisco Systems Email: sandeshr@cisco.com Mohammed, et al. Expires 1 December 2023 [Page 11]