Security Profiles in Bootstrap Voucher Artifacts

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 30 May 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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

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:¶

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

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¶

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

<CODE BEGINS> 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:   <http://tools.ietf.org/wg/anima/>
    WG List:  <mailto:anima@ietf.org>
    Author:   Srihari Raghavan
              <mailto:srihari@cisco.com>";

  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";
    }

    revision "2023-11-27" {
      description
        "Updates to security profile aspects";
      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";
    }
  }

  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;
    }
  }

  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;

      }
    }
  }
}

<CODE ENDS>

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

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

6. Privacy Considerations

TBD¶

7. Security Considerations

TBD¶

8. IANA Considerations

This document requires the following IANA actions:¶

     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.

     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

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

11. Changelog

Appendix A. Extra references

RFC Editor, please remove this section. This section lists references in the YANG. [RFC8174], [RFC8040].¶

Authors' Addresses