Security Profiles in Bootstrap Voucher Artifacts
draft-mohammed-anima-voucher-security-profile-01

Anima Working Group                                          J. Mohammed
Internet-Draft                                                 R. Haddad
Intended status: Standards Track                             S. Raghavan
Expires: 30 May 2024                                              S. Rao
                                                           Cisco Systems
                                                        27 November 2023

            Security Profiles in Bootstrap Voucher Artifacts
            draft-mohammed-anima-voucher-security-profile-01

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

Copyright Notice

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

Mohammed, et al.           Expires 30 May 2024                  [Page 1]
Internet-Draft          voucher-security-profile           November 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  . . . . . . . . . . . . . . . . . .   9
   5.  Changes to Domain Components' Behavior  . . . . . . . . . . .   9
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  The IETF XML Registry . . . . . . . . . . . . . . . . . .  10
     8.2.  YANG Module Names Registry  . . . . . . . . . . . . . . .  10
   9.  Implementation Considerations . . . . . . . . . . . . . . . .  10
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     12.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  Extra references . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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 30 May 2024                  [Page 2]
Internet-Draft          voucher-security-profile           November 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 30 May 2024                  [Page 3]
Internet-Draft          voucher-security-profile           November 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.

   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.

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

Mohammed, et al.           Expires 30 May 2024                  [Page 4]
Internet-Draft          voucher-security-profile           November 2023

      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

3.1.  YANG Module

   This module uses the grouping that was created in [RFC8366] to extend
   the definition.

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

Mohammed, et al.           Expires 30 May 2024                  [Page 5]
Internet-Draft          voucher-security-profile           November 2023

     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 {

Mohammed, et al.           Expires 30 May 2024                  [Page 6]
Internet-Draft          voucher-security-profile           November 2023

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

Mohammed, et al.           Expires 30 May 2024                  [Page 7]
Internet-Draft          voucher-security-profile           November 2023

         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;

Mohammed, et al.           Expires 30 May 2024                  [Page 8]
Internet-Draft          voucher-security-profile           November 2023

       }
     }

     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

Mohammed, et al.           Expires 30 May 2024                  [Page 9]
Internet-Draft          voucher-security-profile           November 2023

   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:

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:

     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.

Mohammed, et al.           Expires 30 May 2024                 [Page 10]
Internet-Draft          voucher-security-profile           November 2023

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-17, 7 April 2022,
              <https://www.ietf.org/archive/id/draft-ietf-anima-
              constrained-voucher-17.txt>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
              "A Voucher Artifact for Bootstrapping Protocols",
              RFC 8366, DOI 10.17487/RFC8366, May 2018,
              <https://www.rfc-editor.org/info/rfc8366>.

   [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, <https://www.rfc-editor.org/info/rfc8995>.

12.2.  Informative References

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

Mohammed, et al.           Expires 30 May 2024                 [Page 11]
Internet-Draft          voucher-security-profile           November 2023

   [RFC8572]  Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
              Touch Provisioning (SZTP)", RFC 8572,
              DOI 10.17487/RFC8572, April 2019,
              <https://www.rfc-editor.org/info/rfc8572>.

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 30 May 2024                 [Page 12]