File Content Provenance for Network File System version 4
draft-ietf-nfsv4-integrity-measurement-02

Network File System Version 4                                   C. Lever
Internet-Draft                                                    Oracle
Intended status: Standards Track                         October 8, 2018
Expires: April 11, 2019

       File Content Provenance for Network File System version 4
               draft-ietf-nfsv4-integrity-measurement-02

Abstract

   This document specifies an OPTIONAL extension to NFS version 4 minor
   version 2 that enables file provenance information to be conveyed
   between NFS version 4.2 servers and clients.  File provenance
   information authenticates the creator of a file's content and helps
   guarantee the content's integrity 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 April 11, 2019.

Copyright Notice

   Copyright (c) 2018 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.

Lever                    Expires April 11, 2019                 [Page 1]
Internet-Draft           File Provenance for NFS            October 2018

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Extension Considerations . . . . . . . . . . . . . .   4
   4.  Managing File Provenance Information on NFS Files . . . . . .   5
   5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

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.  The checksum
   and its signature are verified as the file's content is read into

Lever                    Expires April 11, 2019                 [Page 2]
Internet-Draft           File Provenance for NFS            October 2018

   memory immediately before it is used.  If verification fails, access
   to the file's content is prevented.  The hash is updated and re-
   signed only when the file is legitimately modified.

1.1.  Architecture Summary

   A keyed hash 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
   metadata using the generic term "file provenance information".

   File provenance information is generated and signed by a "provenance
   authority", and then placed in the file system using special tools.

   A security module separate from the file system stack specifies the
   format of the file provenance information and enforces a policy for
   utilizing it to determine when a protected file's content is safe to
   use on the local system.  For the purposes of this document, we refer
   to this module as a "provenance assessor", and the policy it uses as
   the "provenance assessment policy".

   NFS acts as a conduit by which file provenance information and file
   content move between storage on an NFS server and the provenance
   assessor where that content is to be accessed.  NFS peers accessing a
   set of shared files must all agree on the at-rest file provenance
   information format.  The format is specified by the provenance
   assessor and is therefore not described in this document.

   A Trusted Platform Module [TPM-SUM] 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.

   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 to protect files
   stored on an NFS server.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD 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.

Lever                    Expires April 11, 2019                 [Page 3]
Internet-Draft           File Provenance for NFS            October 2018

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

Lever                    Expires April 11, 2019                 [Page 4]
Internet-Draft           File Provenance for NFS            October 2018

4.  Managing File Provenance Information 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
   associated with a particular file.

   To enable a single file provenance information 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 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 IETF Trust and the person identified
      ///  * as author of the code.  All rights reserved.
      ///  *
      ///  * The author of the code is: C. Lever
      ///  */
      ///
      /// const FILEPROV4_MAXSIZE = 4096;
      /// typedef opaque file_prov4<FILEPROV4_MAXSIZE>;
      ///
      /// %/*
      /// % * New For File Provenance Information
      /// % */
      /// const FATTR4_FILE_PROVENANCE = XXX;   /* to be assigned */
      ///
      /// typedef file_prov4 fattr4_file_provenance;

   <CODE ENDS>

4.2.  Storing File Provenance Information

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

Lever                    Expires April 11, 2019                 [Page 5]
Internet-Draft           File Provenance for NFS            October 2018

   To remove this attribute from a file, the client sends a
   FATTR4_FILE_PROVENANCE attribute whose length is zero.  [ cel: Does
   writing to a file have any effect on IMA metadata? ]

   When a SETATTR is presented to an NFS version 4.2 server with a
   credential that is not authorized to replace the
   FATTR4_FILE_PROVENANCE 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 field whose length is larger than
   FILEPROV4_MAXSIZE, 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 but the object does not support this
   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, 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

   An NFS version 4.2 client retrieves file provenance information by
   retrieving the FATTR4_FILE_PROVENANCE attribute via a GETATTR
   operation, specifying the file handle of the file object associated
   with the information 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 but the object does not support this
   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, this does not result in an error and the
   FATTR4_FILE_PROVENANCE attribute bit is clear in the server's
   response.

   Otherwise, if the target object supports FATTR4_FILE_PROVENANCE and
   there is no file provenance information is available for the target

Lever                    Expires April 11, 2019                 [Page 6]
Internet-Draft           File Provenance for NFS            October 2018

   object, the server returns a FATTR4_FILE_PROVENANCE attribute whose
   length is zero.

   Provenance assessors operate after file content has been delivered
   but immediately before that content is to be used.  To enable
   provenance assessors on NFS clients to verify file provenance
   information, NFS version 4.2 servers do not prevent access to file
   content if they have a local provenance assessor and it indicates
   that provenance 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.

   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.

   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.

   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.

   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.

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

Lever                    Expires April 11, 2019                 [Page 7]
Internet-Draft           File Provenance for NFS            October 2018

   o  A "full-function server" is a participating server that supports
      updating file provenance information 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.

5.2.  Instantiating File Provenance Information

   Once a file is written, file provenance information is generated and
   signed by an appropriate provenance 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 to the shared file system.  When using a store-only
   server, only a full-function client can place file provenance
   information in the shared file system.

   Typically, once file provenance information 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 will make the
   content inaccessible, depending on the provenance assessment policy
   in effect.  Thus updating the file content usually requires
   generating fresh file provenance information.

5.2.1.  Authorizing Updates to File Provenance Information

   A participating server should ensure that modifications to file
   provenance information are done only by appropriately authorized
   agents.

   [ cel: TBD.  Regular users are probably not able to modify a local
   security.ima xattr.  What kind of authority should be required to
   modify FPI remotely? ]

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 policies that might be adopted
   by a provenance assessor (actual polices are left to provenance
   assessors):

   Strict

Lever                    Expires April 11, 2019                 [Page 8]
Internet-Draft           File Provenance for NFS            October 2018

      Access is prevented to a file's content if the file has no
      provenance information or if the provenance information 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 or when
      existing provenance information fails to verify the file's
      content.

   Disabled
      Access to file content is never prevented and provenance
      information 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 assessor on an NFS version 4.2 peer needs to be prepared
   to deal with file provenance information it does not recognize or
   cannot parse.  Typically its policy treats this case as a provenance
   verification failure.

   Note that an NFS version 4.2 server may use a provenance assessor 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 never prevent remote access to clients if local
   provenance assessment fails.

5.4.  Performance Cost of Using File Provenance Information

   A provenance assessor typically checksums the entirety of a file's
   content.  When a file's content is first accessed, after it changes,
   or if any portion of a file is evicted from an NFS version 4.2
   client's cache, the client must retrieve any missing content before
   its local provenance assessor can compute a fresh checksum to verify
   the file's content.

Lever                    Expires April 11, 2019                 [Page 9]
Internet-Draft           File Provenance for NFS            October 2018

   Thus provenance assessment can incur a significant performance impact
   for large files, files that change frequently, or files where only a
   portion of the content is used on that client (e.g., software
   libraries).  A provenance assessor can employ mechanisms not
   specified here to reduce this impact.

   For example, instead 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.

6.  Security Considerations

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

   When file provenance information for a file exists, 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.  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 that is
   cryptographically signed, simply by verifying its signature.
   Additional protection of signed file provenance information 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 at rest, an NFS version 4.2 server should
   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.

Lever                    Expires April 11, 2019                [Page 10]
Internet-Draft           File Provenance for NFS            October 2018

7.  IANA Considerations

   This document does not require any actions by IANA.

8.  References

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

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

Lever                    Expires April 11, 2019                [Page 11]
Internet-Draft           File Provenance for NFS            October 2018

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

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.

   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, NFSV4
   Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4
   Working Group Secretary Thomas Haynes for their support.

Author's Address

Lever                    Expires April 11, 2019                [Page 12]
Internet-Draft           File Provenance for NFS            October 2018

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

   Phone: +1 248 816 6463
   Email: chuck.lever@oracle.com

Lever                    Expires April 11, 2019                [Page 13]