Network File System Version 4                                   C. Lever
Internet-Draft                                                    Oracle
Intended status: Standards Track                        November 7, 2018                          March 27, 2019
Expires: May 11, September 28, 2019

       File Content Provenance

        Integrity Measurement for Network File System version 4
               draft-ietf-nfsv4-integrity-measurement-03
               draft-ietf-nfsv4-integrity-measurement-04

Abstract

   This document specifies an OPTIONAL extension to NFS version 4 minor
   version 2 that enables file provenance information Linux Integrity Measurement Architecture
   metadata (IMA) to be conveyed between NFS version 4.2 servers and
   clients.  File provenance
   information  Integrity measurement authenticates the creator of a file's
   content and helps guarantee the content's integrity end-to-end from
   creation to use.

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 May 11, September 28, 2019.

Copyright Notice

   Copyright (c) 2018 2019 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  The Linux Integrity Measurement Architecture and Terminology  . . . . . . . .  . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Extension Considerations . . . . . . . . . . . . . .   4
     3.1.  XDR Extraction  . . . . . . . . . . . . . . . . . . . . .   4
   4.  Managing File Provenance Information IMA Metadata on NFS Files  . . . . . . . . . . . . .   5
     4.1.  XDR Definition  . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Storing File Provenance Information IMA Metadata  . . . . . . . . . . . . . . . . . .   6
     4.3.  Retrieving File Provenance Information IMA Metadata . . . . . . . . .   7 . . . . . . . .   6
   5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   8   7
     5.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   8   7
     5.2.  Instantiating File Provenance Information IMA Metadata  . . . . . . . . . . . . . . .   8
       5.2.1.  Authorizing Updates to File Provenance Information IMA Metadata .   9 . . . . . . . .   8
     5.3.  Interaction With Non-Participating Implementations  . . .   8
   6.  Implementation Status . . . . . . . . . . . . . . . . . . . .   9
     5.4.  Performance Cost of Provenance Assessment
     6.1.  Linux NFS server and client . . . . . . . . . . . . . . .  10
   6.
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     8.2.  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  14  12
     9.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15  13

1.  Introduction

   The security of software distribution systems is complex and
   challenging, especially as software distribution has become
   increasingly decentralized.  An end administrator needs to trust that
   she is running executables just as they are supplied by a software
   vendor; in other words, that they have not been modified by malicious
   actors, contracted system administration services, or broken hardware
   or software.  Software vendors want a guarantee that customer-
   installed executables that fall under support contracts have
   similarly not been modified.

   There already exist mechanisms that protect file data during certain
   portions of a file's life cycle:

   o  Whole file system checksumming can verify so-called Golden Master
      installation media before it is used to install the software it
      contains.

   o  File or block integrity mechanisms can protect data at rest on
      storage servers.

   o  For a distributed file system such as NFS, transport layer
      security or a GSS integrity service (as described in [RFC7861])
      can protect data while it traverses a network between a storage
      server and a client.

   A more extensive mechanism is needed to guarantee that no
   modification of a particular file has occurred since it was created,
   perhaps even after several generations of copies have been made of
   the file's content.

   This guarantee can be accomplished by separately preserving a keyed
   hash, such as an HMAC [RFC2104], of a file's content.

1.1.  The checksum
   and its signature are verified as Linux Integrity Measurement Architecture

   The Linux Integrity Measurement Architecture (IMA) [1] provides
   assurance that the file's content of files is read into
   memory immediately before it is used.  If verification fails, access unaltered and authentic to the file's content is prevented.
   what was originally written to those files.  The hash primary goal is updated and re-
   signed only to
   detect when a remote attacker, a local attacker, or unintentional
   platform behavior has modified the file's content is legitimately modified.

   Unlike traditional integrity management schemes, the hash is not
   replaced every time of a file is copied.  Instead, the signed checksum
   is copied along with file content and presented whenever the content
   is about to be used.

1.1.  Architecture and Terminology either in
   transit or at rest.

   A keyed hash (e.g., an HMAC [RFC2104]) authenticates the identity of
   the last modifier of a file's content and serves as a strong check of
   the content's integrity.  For the purposes of this document, we refer
   to this hash as "IMA metadata".  Such metadata using the generic term "file provenance information".

   File provenance information is generated and
   signed by a "provenance
   authority", trusted authority and then associated with each file
   using special tools.

   Each hash and its signature are verified as the file's content is
   read into memory immediately before it is used.  If verification
   fails, access to the file's content is prevented.  A security module
   separate from the file system stack specifies the format of the metadata,
   measures file provenance information content, and enforces a policy for
   utilizing it to determine determining when a protected file's
   file content is safe to use on the local system.  For the purposes of
   this document, we refer to this module as a "provenance assessor", the "integrity assessor"
   and the policy it uses as the "provenance assessment "appraisal policy".

   Provenance assessment

   Appraisal is typically performed at the point of content use.  The
   file and storage system play no part in provenance
   assessment decisions.  NFS measurement or appraisal.
   The file system acts only as a conduit by which file
   provenance information IMA metadata and file
   content move between storage on an NFS server and the provenance integrity
   assessor module on the host where that content is to be
   accessed. used.

   NFS peers accessing a set of shared files must all agree on the at-rest file provenance information IMA
   metadata format.  The format is specified by the provenance integrity assessor
   module and is therefore not described in this document.  The Linux Integrity Measurement Architecture (IMA) is an example of a
   mechanism that provides a full provenance assessment service
   [IMA-WP].  The protocol
   extension in this document enables the storage and use of file provenance information IMA
   metadata so that provenance
   assessment measurement and appraisal can occur at point-of-use
   on NFS clients.  The extension does not provide a full assessment
   mechanism.

   A Trusted Platform Module [TPM-SUM] [2] can seal the key material used to sign and
   verify file content.  Distributing and protecting such key material
   is outside the scope of the OPTIONAL extension specified in this document.

2.  Requirements Language

   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.

3.  Protocol Extension Considerations

   This document specifies an OPTIONAL extension to NFS version 4 minor
   version 2 [RFC7862], hereafter referred to as NFS version 4.2.  NFS
   version 4.2 servers and clients implemented without knowledge of this
   extension will continue to interoperate with NFS version 4.2 clients
   and servers that are aware of the extension, whether or not they
   support it.

   Because [RFC7862] does not define NFS version 4.2 as non-extensible,
   [RFC8178] treats it as an extensible minor version.  Therefore this
   Standards Track RFC extends NFS version 4.2 but does not update
   [RFC7862] or [RFC7863].

3.1.  XDR Extraction

   Section 4.1 contains a description of an extension to the NFS version
   4.2 protocol, expressed in the External Data Representation (XDR)
   language [RFC4506].  This description is provided in a way that makes
   it simple to extract into ready-to-compile form.  The reader can
   apply the following sed script to this document to produce a machine-
   readable XDR description of the extension.

   <CODE BEGINS>

   sed -n -e 's:^ */// ::p' -e 's:^ *///$::p'

   <CODE ENDS>

   That is, if this document is in a file called "provenance-
   extension.txt" "ima-extension.txt"
   then the reader can do the following to extract an XDR description
   file:

   <CODE BEGINS>

   sed -n -e 's:^ */// ::p' -e 's:^ *///$::p'
        < provenance-extension.txt ima-extension.txt > ima.x

   <CODE ENDS>

   Once that extraction is done, these added lines need to be inserted
   into an appropriate base XDR of the generated XDR from [RFC7863]
   together with XDR from any additional extensions to be recognized by
   the implementation.  This will result in a ready-to-compile XDR file.

4.  Managing File Provenance Information IMA Metadata on NFS Files

4.1.  XDR Definition

   This section defines a new data type to encapsulate and a new
   OPTIONAL attribute to access and update file provenance information IMA metadata associated with
   a particular file.

   To enable a single file provenance information IMA metadata payload to be retrieved or updated
   via a single RPC, and to constrain the transport resources required
   for the operations defined in this section, the length of file provenance information IMA
   metadata MUST NOT exceed 4096 bytes in length.

   When an NFS version 4.2 server does not recognize, or does recognize
   but does not support, this new attribute, the server responds in
   accordance with the requirements specified in Section 4.3 of
   [RFC8178].

   <CODE BEGINS>

      /// /*
      ///  * Copyright (c) 2018 2019 IETF Trust and the person identified
      ///  * as author of the code.  All rights reserved.
      ///  *
      ///  * The author of the code is: C. Lever
      ///  */
      ///
      /// struct file_prov4 {
      ///         uint32_t                 fpv_type;
      ///         opaque                   fpv_data<>;
      /// };
      ///
      /// %/*
      /// % * New For File Provenance Information Linux IMA support
      /// % */
      /// typedef file_prov4               fattr4_file_provenance; opaque                           ima_data<4096>;
      ///
      /// const FATTR4_FILE_PROVENANCE FATTR4_LINUX_IMA = XXX;    /* to be assigned */

   <CODE ENDS>

4.2.  Storing File Provenance Information IMA Metadata

   An NFS version 4.2 client stores file provenance information IMA metadata by sending a SETATTR
   operation that specifies the FATTR4_FILE_PROVENANCE
   attribute and an fpv_type, FATTR4_LINUX_IMA attribute, targeting
   the file object associated with the file provenance information metadata to be stored.  This
   attribute completely replaces any previous one with the same fpv_type field. one.

   To remove a file provenance attribute IMA metadata from a file, the client sends a
   FATTR4_FILE_PROVENANCE
   FATTR4_LINUX_IMA attribute whose length is zero.  Modifying the file
   in any other way MUST NOT alter or remove FATTR4_FILE_PROVENANCE FATTR4_LINUX_IMA
   attributes.

   When a SETATTR is presented to an NFS version 4.2 server with a
   credential that is not authorized to replace a FATTR4_FILE_PROVENANCE FATTR4_LINUX_IMA
   attribute, the server MUST respond with NFS4ERR_ACCESS.

   When a SETATTR is presented to an NFS version 4.2 server with a
   fattr4_file_provenance
   fattr4_linux_ima field whose length is larger than the maximum
   size specified in Table 1 for that fpv_type, 4096 bytes, the
   server MUST respond with NFS4ERR_INVAL.

   When a SETATTR is presented to an NFS version 4.2 server and the
   target object resides in a file system which supports
   FATTR4_FILE_PROVENANCE
   FATTR4_LINUX_IMA but the object itself does not support
   FATTR4_FILE_PROVENANCE attributes, the
   FATTR4_LINUX_IMA attribute, the server MUST respond with
   NFS4ERR_WRONGTYPE.

   When a SETATTR is presented to an NFS version 4.2 server but the
   target object resides in a file system which does not support
   FATTR4_FILE_PROVENANCE or does not support the format associated with the specified fpv_type,
   FATTR4_LINUX_IMA attribute, the server MUST respond with
   NFS4ERR_ATTRNOTSUPP.

   A detailed description of the SETATTR operation can be found in
   Section 18.30 of [RFC5661].

4.3.  Retrieving File Provenance Information IMA Metadata

   An NFS version 4.2 client retrieves file provenance information IMA metadata by retrieving the FATTR4_FILE_PROVENANCE
   FATTR4_LINUX_IMA attribute via a GETATTR operation, specifying an fpv_type and the
   file handle of the file object associated with the information metadata to be
   retrieved.  This information may have been computed and signed
   previously on this client or by some other agent.

   When a GETATTR is presented to an NFS version 4.2 server and the
   target object resides in a file system which supports
   FATTR4_FILE_PROVENANCE the
   FATTR4_LINUX_IMA attribute but the object does not support
   FATTR4_FILE_PROVENANCE attributes, the
   FATTR4_LINUX_IMA attribute, the server MUST respond with
   NFS4ERR_WRONGTYPE.

   When a GETATTR is presented to an NFS version 4.2 server but the
   target object resides in a file system which does not support
   FATTR4_FILE_PROVENANCE or does not support the format associated with
   the specified fpv_type,
   FATTR4_LINUX_IMA, this does not result in an error and the
   FATTR4_FILE_PROVENANCE attribute bit is clear cleared in the server's
   response.

   Otherwise, if the target object supports FATTR4_FILE_PROVENANCE FATTR4_LINUX_IMA and there
   is no file provenance information IMA metadata is available for the target object, the server
   returns a FATTR4_FILE_PROVENANCE FATTR4_LINUX_IMA attribute whose length is zero.

   Provenance assessors operate

   Integrity assessment occurs after file content has been delivered but
   immediately before that content is to be used.  To enable
   provenance assessors integrity
   assessment on NFS clients to verify file provenance
   information, IMA metadata, NFS version 4.2
   servers do should not prevent access to file content if they have a
   local provenance assessor appraisal policy and it indicates that provenance integrity verification
   has failed.

   A detailed description of the GETATTR operation can be found in
   Section 18.7 of [RFC5661].

5.  Operation

5.1.  Terminology

   To aid the discussion in this section, we define a few handy terms:

   o  A "participating client" is an NFS version 4.2 client that
      supports the OPTIONAL extension described in this document and
      employs a provenance assessor. integrity assessor module.

   o  A "non-participating client" is an NFS version 4.2 client that
      does not support the OPTIONAL extension described in this document
      or does not employ a provenance assessor. integrity assessor module.

   o  A "participating server" is an NFS version 4.2 server that
      supports the OPTIONAL extension described in this document and its
      shared filesystems can store file provenance information. IMA metadata.  A participating server
      is not required to implement an integrity assessor module.

   o  A "non-participating server" is an NFS version 4.2 server that
      does not support the OPTIONAL extension described in this document
      or its shared filesystems are not capable of storing file
      provenance information. IMA metadata.

   In addition, there are intermediate modes of operation on
   participating peers:

   o  A "full-function client" is a participating client that supports
      updating remote file provenance information. IMA metadata.

   o  A "fetch-only client" is a participating client that does not
      support modifying file provenance information IMA metadata on a participating server.

   o  A "full-function server" is a participating server that supports
      updating file provenance information IMA metadata that resides on local shared file systems.

   o  A "store-only server" is a participating server where there is
      only remote access to file provenance information. IMA metadata.

5.2.  Instantiating File Provenance Information IMA Metadata

   Once a file is written, file provenance information IMA metadata is generated and signed by an
   appropriate provenance trust authority.  Using the OPTIONAL extension specified
   in this document, the information can be associated with a file on
   either a full-function server or client using a tool with appropriate
   privileges that writes the provenance
   information IMA metadata to the shared file system.  When
   using a store-only server, only a full-function client can place file provenance
   information IMA
   metadata in the shared file system.

   Typically, once file provenance information IMA metadata is associated with a file, the file's
   content is essentially immutable, even if the file has write
   permissions.  This is because changing the content without updating
   the associated file provenance information IMA metadata will make the content inaccessible,
   depending on the provenance assessment appraisal policy in effect.  Thus updating the file
   content usually requires generating fresh file provenance information. IMA metadata.

5.2.1.  Authorizing Updates to File Provenance Information IMA Metadata

   A participating server should ensure that modifications to file
   provenance information IMA
   metadata are done only by appropriately authorized agents.  Such
   agents usually include only the owner of a file and agents with super-user privileges.  The
   NFS server MAY confirm that the new IMA metadata actually verifies
   the file content correctly before storing it.

5.3.  Interaction With Non-Participating Implementations

   Because the protocol extension described herein is OPTIONAL, clients
   and servers that support it must necessarily interact with clients
   and servers that do not support it.  To set the stage for a
   discussion of interactions that might occur, consider the following
   possible simple provenance assessment appraisal policies that might be adopted by a provenance assessor (actual polices are left to provenance
   assessors): an
   integrity assessment module:

   Strict:  Access is prevented to a file's content if the file has no
      provenance information
      IMA metadata or if the provenance information extant IMA metadata fails to verify the
      file content.  Otherwise access to the file's content is not
      prevented.

   Audit:  Access to a file's content is never prevented.  Warnings are
      reported when a file has no provenance information IMA metadata or when
      existing provenance information extant IMA
      metadata fails to verify the file's content.

   Disabled:  Access to file content is never prevented and provenance
      information IMA metadata
      is ignored.

   Given the above example policies and the definitions we provided
   earlier for participating and non-participating implementations, the
   following statements are true:

   o  A participating client that uses the Disabled policy is equivalent
      to a non-participating client.

   o  A non-participating client never prevents access to file content
      on a participating server.

   o  A participating client using the Strict policy never allows access
      to files stored on a non-participating server.

   A provenance integrity assessor module on an NFS version 4.2 peer needs to be
   prepared to deal with file provenance information IMA metadata it does not recognize or cannot
   parse.  Typically its  Its policy treats may treat this case as a provenance
   verification appraisal failure.

   Note that an NFS version 4.2 server may use a provenance integrity assessor
   module to prevent access by local users to protected files.  To
   enable NFS version 4.2 clients to do their own assessment, an NFS
   version 4.2 server should not prevent remote access to participating
   clients if local provenance integrity assessment fails.

5.4.  Performance Cost

6.  Implementation Status

   This section records the status of Provenance Assessment

   A provenance assessor typically checksums known implementations of the
   protocol defined by this specification at the entirety time of a file's
   content.  When a file's content is first accessed, after it changes,
   or if any portion posting of this
   Internet-Draft, and is based on a file proposal described in [RFC7942].
   The description of implementations in this section is evicted from an NFS version 4.2
   client's cache, intended to
   assist the client must retrieve any missing content before IETF in its local provenance assessor can compute a fresh checksum decision processes in progressing drafts to
   RFCs.

   Please note that the listing of any individual implementation here
   does not imply endorsement by the IETF.  Furthermore, no effort has
   been spent to verify the file's content.

   Thus provenance assessment can incur a significant performance impact
   for large files, files information presented here that change frequently, or files where only was supplied
   by IETF contributors.  This is not intended as, and must not be
   construed to be, a
   portion catalog of the content is used on available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

6.1.  Linux NFS server and client (e.g.,

   Organization:  The Linux Foundation

   URL:       https://www.kernel.org

   Maturity:  Prototype software
   libraries).  A provenance assessor can employ mechanisms not
   specified here to reduce based on early versions of this impact.

   For example, instead
              document.

   Coverage:  The bulk of signing a hash of the file's byte stream, a
   Merkle tree can be constructed that allows assessors to verify the
   integrity of smaller portions of a large file [MERKLE].  The root
   hash of that tree, being of sufficiently limited size, can be signed
   and stored as file provenance information.  The Merkle tree, which is
   stored elsewhere, can be used to verify portions of the file's
   content without the need to read the whole file.

   NFS can provide an offload mechanism to mitigate some of the network
   and CPU utilization costs of provenance assessment on clients.  If
   there is a strong trust relationship between clients and server, and
   the network transport is of very high integrity, the NFS server can
   perform provenance assessment in lieu of exposing file provenance
   information to clients.

6.  Security Considerations

   The design this specification is implemented.

   Licensing: GPLv2

   Implementation experience:  No comments from implementors.

7.  Security Considerations

   The design of the OPTIONAL extension described in this document
   assumes that all file provenance information IMA metadata is keyed or otherwise cryptographically
   signed by a provenance trust authority to prevent unwanted alteration at rest or
   in transit.

   When file provenance information IMA metadata for a file exists, exists and the end host has adopted an
   IMA policy, the content of a file is protected from creation to use.
   Receivers can reliably detect unintentional or malicious alteration
   of file content by verifying its content using file provenance information. the file's IMA
   metadata.  Additional protection of file content while at rest or in
   transit on an untrusted network is unnecessary.

   Likewise, receivers can also reliably detect unintentional or
   malicious alteration of file provenance information IMA metadata that is cryptographically
   signed, simply by verifying its signature.  Additional protection of
   signed file provenance information metadata while at rest or in transit on an untrusted network
   is unnecessary.

   Like other mechanisms that protect data integrity during transit, A
   malicious agent or a network malfunction can create a denial-of-
   service condition by repeatedly triggering integrity verification
   failures on NFS version 4.2 clients.

   To prevent a malicious denial-of-service attempt by altering file
   provenance information IMA
   metadata at rest, an NFS version 4.2 server should can enforce a suitable
   level of privilege before authorizing a local or remote agent to
   alter this information.  See Section 5.2.1 for more detail.

7.  IANA Considerations

   In accordance with [RFC8126], the author requests that the Internet
   Assigned Numbers Authority (IANA) create a new registry in the
   "Network File System version 4" Protocol Category Group.  The new
   registry is to be called the "File Provenance Information Format
   Registry".

   The new registry has the following fields:

   Code Point:  An integer that maps to a particular File Provenance
      Information format.  The namespace of this identifier has the
      range 0..4204067295.  Or, a range of values to be used for the
      same purpose.

   Description:  A human-readable ASCII text string that concisely
      describes the File Provenance Information format.  The length of
      this field is limited to 128 bytes.

   Max Size:  An integer that expresses the largest possible size, in
      octets, required to store a single item of File Provenance
      Information.  Typical values are 4096 or 9000.  A hyphen is stored
      here when the Code Point column contains a range.

   Reference:  A reference to a stable public document that requested
      this entry.  The document should describe the File Provenance
      Information format and any specialized storage requirements, or
      should reference other public documents as appropriate.

   The initial assignments of the registry appear in Table 1.

   +--------------+----------------------------+----------+------------+
   | Code Point   | Description                | Max Size | Reference  |
   +--------------+----------------------------+----------+------------+
   | 0            | Linux IMA                  | 4096     | [RFC-TBD]  |
   | 1 - 2^31-1   | Available for IANA         | -        | [RFC-TBD]  |
   |              | Assignment                 |          |            |
   | 2^31 -       | Private and Experimental   | -        | [RFC-TBD]  |
   | 2^32-1       | Use                        |          |            |
   +--------------+----------------------------+----------+------------+

           Table 1: File Provenance Information Format Registry

   A format specification document is recommended to add a new entry to
   the "File Provenance Information Registry".  If the format document
   is inside the RFC track, then the

8.  IANA Considerations section of the
   format

   This document should reference the "File Provenance Information
   Registry" and request allocation of a new entry.  The well-known IANA
   policy Expert Review, as defined in Section 4.5 of [RFC8126] is to be
   used to handle requests to add new entries to the "File Provenance
   Information Registry".

   When reviewing published file provenance specifications, the
   Designated Expert should consider whether or not the specified file
   provenance format allows a correct and complete implementation of the
   protocol to process this information as a policy administration
   mechanism.  To reduce interoperability issues, the reviewer must
   determine if the file provenance information format specification has
   clearly defined syntax and semantics.

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert.  Allocation of ranges of code points (more than
   one for a given purpose) should require IETF Consensus.  Code point
   allocations SHOULD NOT be made for purposes unrelated to managing
   file provenance information.

   A request to modify either the Description or the published file
   provenance information format specification requires the Expert
   Review IANA policy to be applied.  If the format document is inside
   the RFC track, the IANA Considerations section of the updated
   specification should be explicit regarding which old label selector
   assignment it modifies.

8. no action from IANA.

9.  References

8.1.

9.1.  Normative References

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

   [RFC4506]  Eisler, M., Ed., "XDR: External Data Representation
              Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
              2006, <https://www.rfc-editor.org/info/rfc4506>.

   [RFC5661]  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
              "Network File System (NFS) Version 4 Minor Version 1
              Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
              <https://www.rfc-editor.org/info/rfc5661>.

   [RFC7862]  Haynes, T., "Network File System (NFS) Version 4 Minor
              Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
              November 2016, <https://www.rfc-editor.org/info/rfc7862>.

   [RFC7863]  Haynes, T., "Network File System (NFS) Version 4 Minor
              Version 2 External Data Representation Standard (XDR)
              Description", RFC 7863, DOI 10.17487/RFC7863, November
              2016, <https://www.rfc-editor.org/info/rfc7863>.

   [RFC8126]  Cotton, M., Leiba, B.,

   [RFC7942]  Sheffer, Y. and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 26, 205,
              RFC 8126, 7942, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>. 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

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

   [RFC8178]  Noveck, D., "Rules for NFSv4 Extensions and Minor
              Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017,
              <https://www.rfc-editor.org/info/rfc8178>.

8.2.

9.2.  Informative References

   [IMA-WP]   Safford, D., "An Overview of The Linux Integrity
              Subsystem", <http://downloads.sf.net/project/linux-ima/
              linux-ima/Integrity_overview.pdf>.

   [MERKLE]   Merkle, R., ""A Digital Signature Based on a Conventional
              Encryption Function" Advances in Cryptology - CRYPTO '87",
              DOI 10.1007/3-540-48184-2_32, 1988.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC5662]  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
              "Network File System (NFS) Version 4 Minor Version 1
              External Data Representation Standard (XDR) Description",
              RFC 5662, DOI 10.17487/RFC5662, January 2010,
              <https://www.rfc-editor.org/info/rfc5662>.

   [RFC7861]  Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
              Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
              November 2016, <https://www.rfc-editor.org/info/rfc7861>.

   [TPM-SUM]  Trusted Computing Group, "Trusted Platform Module (TPM)
              Summary", April 2008, <https://trustedcomputinggroup.org/
              wp-content/uploads/
              Trusted-Platform-Module-Summary_04292008.pdf>.

9.3.  URIs

   [1] http://downloads.sf.net/project/linux-ima/linux-ima/
       Integrity_overview.pdf

   [2] https://trustedcomputinggroup.org/wp-content/uploads/Trusted-
       Platform-Module-Summary_04292008.pdf

Acknowledgments

   The author wishes to thank Mimi Zohar and James Morris for their
   early review of the concepts in this document, Wim Coekaerts for his
   encouragement of this work, and Dave Noveck for his work on NFS
   version 4 extensibility.

   The author wishes to acknowledge review comments from Dave Noveck,
   Craig Everhart, and Bruce Fields which helped to make this a better
   document.  Benjamin Kaduk proposed the File Provenance Information
   Registry.

   The XDR extraction conventions were first described by the authors of
   the NFS version 4.1 XDR specification [RFC5662].  Herbert van den
   Bergh suggested the replacement sed script used in this document.

   Special thanks go to Transport Area Director Spencer Dawkins, Magnus Westerlund, NFSV4
   Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4
   Working Group Secretary Thomas Haynes for their support.

Author's Address

   Charles Lever
   Oracle Corporation
   1015 Granger Avenue
   Ann Arbor, MI  48104
   United States of America

   Email: chuck.lever@oracle.com