Applying COSE Signatures for YANG Data Provenance
draft-lopez-opsawg-yang-provenance-01

Operations and Management Area Working Group                    D. Lopez
Internet-Draft                                                 A. Pastor
Intended status: Informational                                Telefonica
Expires: 25 April 2024                                   23 October 2023

           Applying COSE Signatures for YANG Data Provenance
                 draft-lopez-opsawg-yang-provenance-01

Abstract

   This document defines a mechanism based on COSE signatures to provide
   and verify the provenance of YANG data, so it is possible to verify
   the origin and integrity of a dataset, even when those data are going
   to be processed and/or applied in workflows where a crypto-enabled
   data transport directly from the original data stream is not
   available.  As the application of evidence-based OAM automation and
   the use of tools such as AI/ML grow, provenance validation becomes
   more relevant in all scenarios.  The use of compact signatures
   facilitates the inclusion of provenance strings in any YANG schema
   requiring them.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://dr2lopez.github.io/yang-provenance/draft-lopez-opsawg-yang-
   provenance.html.  Status information for this document may be found
   at https://datatracker.ietf.org/doc/draft-lopez-opsawg-yang-
   provenance/.

   Discussion of this document takes place on the Operations and
   Management Area Working Group Working Group mailing list
   (mailto:opsawg@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/opsawg/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/opsawg/.

   Source for this draft and an issue tracker can be found at
   https://github.com/dr2lopez/yang-provenance.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Lopez & Pastor            Expires 25 April 2024                 [Page 1]
Internet-Draft            yang-data-provenance              October 2023

   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 25 April 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Provenance Elements . . . . . . . . . . . . . . . . . . . . .   4
   4.  Provenance Signature Strings  . . . . . . . . . . . . . . . .   7
     4.1.  Signature and Verification Procedures . . . . . . . . . .   7
     4.2.  Canonicalization  . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

Lopez & Pastor            Expires 25 April 2024                 [Page 2]
Internet-Draft            yang-data-provenance              October 2023

1.  Introduction

   OAM automation, generally based on closed-loop principles, requires
   at least two datasets to be used.  Using the common terms in Control
   Theory, we need those from the plant (the network device or segment
   under control) and those to be used as reference (the desired values
   of the relevant data).  The usual automation behavior compares these
   values and takes a decision, by whatever the method (algorithmic,
   rule-based, an AI model tuned by ML...) to decide on a control action
   according to this comparison.  Assurance of the origin and integrity
   of these datasets, what we refer in this document as "provenance",
   becomes essential to guarantee a proper behavior of closed-loop
   automation.

   When datasets are made available as an online data flow, provenance
   can be assessed by properties of the data transport protocol, as long
   as some kind of cryptographic protocol is used for source
   authentication, with TLS, SSH and IPsec as the main examples.  But
   when these datasets are stored, go through some pre-processing or
   aggregation stages, or even cryptographic data transport is not
   available, provenance must be assessed by other means.

   The original use case for this provenance mechanism is associated
   with [YANGmanifest], in order to provide a proof of the origin and
   integrity of the provided metadata, and therefore the examples in
   this document use the modules described there, but it soon became
   clear that it could be extended to any YANG datamodel to support
   provenance evidence.  An analysis of other potential use cases
   suggested the interest of defining an independent, generally
   applicable mechanism.

   Provenance verification by signatures incorporated in the YANG data
   elements can be applied to any data processing pipeline, whether they
   rely on an online flow or use some kind of data store, such as data
   lakes or time-series databases.  The application of recorded data for
   ML training or validation constitute the most relevant examples of
   these scenarios.

   This document provides a mechanism for including digital signatures
   within YANG data.  It applies COSE [RFC9052] to make the signature
   compact and reduce the resources required for calculating it.  This
   mechanism is applicable to any serialization of the YANG data
   supporting a clear method for canonicalization, but this document
   considers three base ones: CBOR, JSON and XML.

Lopez & Pastor            Expires 25 April 2024                 [Page 3]
Internet-Draft            yang-data-provenance              October 2023

2.  Conventions and Definitions

   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.

   The term "data provenance" refers to a documented trail accounting
   for the origin of a piece of data and where it has moved from to
   where it is presently.  The signature mechanism provided here can be
   recursively applied to allow this accounting for YANG data.

3.  Provenance Elements

   To provide provenance for a YANG element, a new leaf element MUST be
   included, containing the COSE signature bitstring built according to
   the procedure defined in the following section.  The provenance leaf
   MUST be of type provenance-signature, defined as follows:

typedef provenance-signature {
     type binary;
     description
      "The provenance-signature type represents a digital signature
       associated to the enclosing element. The signature is based
       on COSE and generated using a cannonicalized version of the
       enclosing element.";
     reference
      "RFC 9052: CBOR Object Signing and Encryption (COSE): Structures and Process
       draft-lopez-opsawg-yang-provenance";
}

   When using it, a provenance-signature leaf MAY appear at any position
   in the enclosing element, but only one such leaf MUST be defined for
   the enclosing element.  If the enclosing element contains other non-
   leaf elements, they MAY provide their own provenance-signature leaf,
   according to the same rule.  In this case, the provenance-signature
   leaves in the childrem elements are applicable to the specific child
   element where they are enclosed, while the provenance-signature leaf
   enclosed in the top-most element is applicable to the whole element
   contents, including the children provenance-signature leaf
   themselves.  This allows for recursive provenance validation, data
   aggregation, and the application of provenance verification of
   relevant children elements at different stages of any data processing
   pipeline.

Lopez & Pastor            Expires 25 April 2024                 [Page 4]
Internet-Draft            yang-data-provenance              October 2023

   As example, let us consider the two modules proposed in
   [YANGmanifest].  For the platform-manifest module, the provenance for
   a platform would be provided by the optional platform-provenance leaf
   shown below:

   module: ietf-platform-manifest
     +--ro platforms
        +--ro platform* [id]
          +--ro platform-provenance?    provenance-signature
          +--ro id                      string
          +--ro name?                   string
          +--ro vendor?                 string
          +--ro vendor-pen?             uint32
          +--ro software-version?       string
          +--ro software-flavor?        string
          +--ro os-version?             string
          +--ro os-type?                string
          +--ro yang-push-streams
          |  +--ro stream* [name]
          |     +--ro name
          |     +--ro description?
          +--ro yang-library
          + . . .
          .
          .
          .

   For data collections, the provenance of each one would be provided by
   the optional collector-provenance leaf, as shown below:

Lopez & Pastor            Expires 25 April 2024                 [Page 5]
Internet-Draft            yang-data-provenance              October 2023

   module: ietf-data-collection-manifest
     +--ro data-collections
        +--ro data-collection* [platform-id]
        +--ro platform-id
        |       -> /p-mf:platforms/platform/id
        +--ro collector-provenance?   provenance-signature
        +--ro yang-push-subscriptions
          +--ro subscription* [id]
            +--ro id
            |      sn:subscription-id
            +
            .
            .
            .
        + . . .
        |
        .
        .
        .

   In both cases, and for the sake of brevity, the provenance element
   appears at the top of the enclosing element, but it is worth
   remarking they may appear anywhere within it.

   Note that, in application of the recursion mechanism described above,
   a provenance element could be included at the top of any of the
   collections, supporting the verification of the provenance of the
   collection itself (as provided by a specific collector), without
   interfering with the verification of the provenance of each of the
   collection elements.  As an example, in the case of the platform
   manifests it would look like:

   module: ietf-platform-manifest
     +--ro platforms
        +--ro platform-collection-provenance? provenance-signature
        +--ro platform* [id]
          +--ro platform-provenance?          provenance-signature
          +--ro id                            string
          +--ro name?                         string
          +--ro vendor?                       string
          + . . .
          .
          .
          .

Lopez & Pastor            Expires 25 April 2024                 [Page 6]
Internet-Draft            yang-data-provenance              October 2023

4.  Provenance Signature Strings

   Signature strings are COSE single signature messages with [nil]
   payload, according to COSE conventions and registries, and with the
   following structure (as defined by [RFC9052], Section 4.2):

   COSE_Sign1 = [
   protected /algorithm-identifier, kid, serialization-method/
   unprotected /algorithm-parameters/
   signature /using as external data the content
              of the (meta-)data without the signature leaf/
   ]

   The COSE_Sign1 procedure yields a bitstring when building the
   signature and expects a bitstring for checking it, hence the proposed
   type for signature leaves.  The structure of the COSE_Sign1 consists
   of:

   *  The algorithm-identifier, which MUST follow COSE conventions and
      registries.

   *  The kid (Key ID), to be locally agreed, used and interpreted by
      the signer and the signature validator.  URIs [RFC3986] and
      RFC822-style [RFC5322] identifiers are typical values to be used
      as kid.

   *  The serialization-method, a string identifying the YANG
      serialization in use.  It MUST be one of the three possible values
      "xml" (for XML serialization [RFC7950]), "json" (for JSON
      serialization [RFC7951]) or "cbor" (for CBOR serialization
      [RFC9254]).

   *  The value algorithm-parameters, which MUST follow the COSE
      conventions for providing relevant parameters to the signing
      algorithm.

   *  The signature for the enclosing element, to be produced and
      verified according to the procedure described below.

4.1.  Signature and Verification Procedures

   To keep a concise signature and avoid the need for wrapping YANG
   constructs in COSE envelopes, the whole signature MUST be built and
   verified by means of externally supplied data, as defined in
   [RFC9052], Section 4.3, with a [nil] payload.

   The byte strings to be used as input to the signature and
   verification procedures MUST be built by:

Lopez & Pastor            Expires 25 April 2024                 [Page 7]
Internet-Draft            yang-data-provenance              October 2023

   *  Taking the whole element enclosing the signature leaf.

   *  Eliminating the signature leaf element.

   *  Applying the corresponding canonicalization method as described in
      the following section.

4.2.  Canonicalization

   Signature generation and verification require a canonicalization
   method to be applied, that depends on the serialization used.
   According to the three types of serialization defined, the following
   canonicalization methods MUST be applied:

   *  For CBOR, length-first core deterministic encoding, as defined by
      [RFC8949].

   *  For JSON, JSON Canonicalization Scheme (JCS), as defined by
      [RFC8785].

   *  For XML, Exclusive XML Canonicalization 1.0, as defined by
      [XMLSig].

5.  Security Considerations

   The provenance assessment mechanism described in this document relies
   on COSE [RFC9052] and the deterministic encoding or canonicalization
   procedures described by [RFC8949], [RFC8785] and [XMLSig].  The
   security considerations made in these references are fully applicable
   here.

   The verification step depends on the association of the kid (Key ID)
   with the proper public key.  This is a local matter for the verifier
   and its specification is out of the scope of this document.  The use
   of certificates, PKI mechanisms, or any other secure distribution of
   id-public key mappings is RECOMMENDED.

6.  IANA Considerations

   The provenance-signature type might need registration.

   Others?

7.  References

7.1.  Normative References

Lopez & Pastor            Expires 25 April 2024                 [Page 8]
Internet-Draft            yang-data-provenance              October 2023

   [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/rfc/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/rfc/rfc5322>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/rfc/rfc7950>.

   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              RFC 7951, DOI 10.17487/RFC7951, August 2016,
              <https://www.rfc-editor.org/rfc/rfc7951>.

   [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/rfc/rfc8174>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8785>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/rfc/rfc8949>.

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9052>.

   [RFC9254]  Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann,
              C., and M. Richardson, "Encoding of Data Modeled with YANG
              in the Concise Binary Object Representation (CBOR)",
              RFC 9254, DOI 10.17487/RFC9254, July 2022,
              <https://www.rfc-editor.org/rfc/rfc9254>.

Lopez & Pastor            Expires 25 April 2024                 [Page 9]
Internet-Draft            yang-data-provenance              October 2023

   [XMLSig]   "XML Signature Syntax and Processing Version 2.0", n.d.,
              <https://www.w3.org/TR/xmldsig-core2/>.

7.2.  Informative References

   [YANGmanifest]
              Claise, B., Quilbeuf, J., Lopez, D., Martinez-Casanueva,
              I. D., and T. Graf, "A Data Manifest for Contextualized
              Telemetry Data", Work in Progress, Internet-Draft, draft-
              ietf-opsawg-collected-data-manifest-01, 10 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
              collected-data-manifest-01>.

Acknowledgments

   This document is based on work partially funded by the EU H2020
   project SPIRS (grant 952622), and the EU Horizon Europe projects
   PRIVATEER (grant 101096110), HORSE (grant 101096342) and ACROSS
   (grant 101097122).

Authors' Addresses

   Diego Lopez
   Telefonica
   Email: diego.r.lopez@telefonica.com

   Antonio Pastor
   Telefonica
   Email: antonio.pastorperales@telefonica.com

Lopez & Pastor            Expires 25 April 2024                [Page 10]