Network File System Version 4                                   C. Lever
Internet-Draft                                                    Oracle
Intended status: Standards Track                            May 29,                      September 24, 2018
Expires: November 30, 2018

        Integrity Measurement March 28, 2019

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

Abstract

   This document specifies an OPTIONAL extension to NFS version 4.2 4 minor
   version 2 that enables Linux Integrity Measurement Architecture metadata (IMA) file provenance information to be conveyed
   between NFSv4.2 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 November 30, 2018. March 28, 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Extension Considerations . . . . . . . . . . . . . .   3
     3.1.  XDR Extraction  . . . . . . . . . . . . . . . . . . . . .   3
   4.  Managing IMA File Provenance Metadata on NFS Files  . . . . . . . . . . . . .   4
     4.1.  XDR Definition  . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Protecting File Content . . . . . . . . . . . . . . . . .   6
     4.3.  Protecting File Attributes  . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12   9

1.  Introduction

   The Linux Integrity Measurement Architecture (IMA) provides assurance
   that the content security of files software distribution systems is unaltered complex and authentic to what was
   originally written
   challenging, especially as software distribution has become
   increasingly decentralized.  An end administrator needs to those files.  In addition, an Extended
   Verification Module (EVM) assures trust that file attribute information
   remains similarly unaltered.

   The primary goal
   she is to detect when a remote attacker, running executables just as they are supplied by a local
   attacker, or unintentional software behavior has
   vendor; in other words, that they have not been modified the content by malicious
   actors, contracted system administration services, or attributes of 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 either in transit or at rest.  This is done
   by separately storing HMAC hashes [RFC2104] data during certain
   portions of a file's byte stream
   content and attribute metadata.  These hashes are updated whenever
   the life cycle:

   o  Whole file is legitimately modified.  The hashes themselves system checksumming can be
   protected by cryptographic signature.

   Subsequent integrity verification verify so-called Golden Master
      installation media before it is not performed by applications or
   by file systems. used to install the software it
      contains.

   o  File systems are responsible only for persistent or block integrity mechanisms can protect data at rest on
      storage of file content and hashes.  When servers.

   o  For a distributed file is read, content,
   attributes, and hashes are passed to IMA and EVM modules for
   measurement and appraisal.  Application access is denied if the
   hashes system such as NFS, transport layer
      security or their signatures cannot be verified.

   Some files may be immutable, in which case their a GSS integrity metadata
   is signed by an RSA public key signature [RFC8017].  Such files can
   be accessed service (as described in read-only mode or deleted by an appropriately
   privileged agent, but cannot otherwise be modified.

   Key material used to sign and verify file content and attribute
   metadata must be protected.  A Trusted Platform Module [TPM-SUM] [RFC7861])
      can
   be used to seal the key material.  This use case is typical for
   providing protect data while it traverses a read-only operating system image that is
   cryptographically verified; for example, in network between a cloud environment or on
   mobile devices.

   On Linux, there are two parts storage
      server and a client.

   A more extensive mechanism is needed to guarantee that no
   modification of a file's IMA metadata:

   o  An HMAC hash, possibly cryptographically signed, particular file has occurred since it was created,
   even perhaps after several generations of copies have been made of
   the file's
      byte stream, stored in the file's security.ima extended attribute.

   o  An HMAC content.

   This guarantee can be accomplished by separately preserving a keyed
   hash, possibly cryptographically signed, such as an HMAC [RFC2104], of a subset of file's byte stream.  This hash
   and its signature are verified as the file's attributes, stored in content is read into
   memory just before it is used.  If verification fails, access to the
   file's security.evm extended
      attribute. content is denied.  The goals hash is updated and use cases re-signed only
   when the file is legitimately modified.

   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 will refer to this
   as file provenance information.  The Linux Integrity Measurement
   Architecture (IMA) are presented in further detail in is an example of a mechanism for assessing file
   content provenance [IMA-WP].

   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 NFS protocol extension specified
   in this document.

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.

3.  Protocol Extension Considerations

   This document specifies an OPTIONAL extension to NFSv4 NFS version 4 minor
   version 2 [RFC7862].  NFSv4.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
   NFSv4.2 NFS version 4.2 clients
   and servers that are aware of the extension, whether or not they
   support it.

   Because [RFC7862] does not define NFSv4.2 NFS version 4.2 as non-extensible,
   [RFC8178] treats it as an extensible minor version.  Therefore this
   Standards Track RFC extends NFSv4.2 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 NFSv4.2 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 -E -n -e 's:^ */// ?::;t;d' ::p' -e 's:^ *///$::p'

   <CODE ENDS>

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

   <CODE BEGINS>

   sed -E -n -e 's:^ */// ?::;t;d' ::p' -e 's:^ *///$::p'
        < integrity-extension.txt 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.

4.  Managing IMA File Provenance Metadata on NFS Files

4.1.  XDR Definition

   This section defines a new data structure used type to transport HMAC
   data, encapsulate and two a new
   OPTIONAL GETATTR attributes used attribute to access and update HMAC data file provenance
   information associated with a particular file.

   HMAC data

   File provenance information is a varying length opaque array to the NFS protocol.  To ensure
   interoperability among accessors of octets. this information when it is
   stored on NFS version 4.2 servers, this information MUST be self-
   describing.

   To enable a single HMAC file provenance information payload to be
   retrieved or updated in via a single RPC, an
   HMAC (including signatures) and to constrain the transport
   resources required for the operations defined here, the payload 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 IMA_HMAC_MAXSIZE FILEPROV4_MAXSIZE = 4096;
      ///
      /// typedef opaque             ima_hmac4<IMA_HMAC_MAXSIZE>;
      /// typedef opaque             uuid4[16];
      /// typedef opaque             verified_attribute4<>;
      ///
      /// struct evm_verflist4 {
      ///       uuid4                *evm_uuid;
      ///       verified_attribute4  evm_attrlist<>;
      /// }; file_prov4<FILEPROV4_MAXSIZE>;
      ///
      /// %/*
      /// % * New For Integrity Measurement File Provenance Metadata
      /// % */
      /// const FATTR4_IMA_HMAC_CONTENT = 85;
      /// const FATTR4_IMA_HMAC_ATTR    = 86;
      /// const FATTR4_EVM_VERF_LIST FATTR4_FILE_PROVENANCE = 87;
      ///
      /// typedef ima_hmac4          fattr4_ima_hmac_content; XXX;   /* to be assigned */
      /// typedef ima_hmac4          fattr4_ima_hmac_attr;
      /// typedef evm_verflist4      fattr4_evm_verf_list; file_prov4 fattr4_file_provenance;

   <CODE ENDS>

     +------------------+-----+---------------+------+--------------+
     | Name             | Id  | Data Type     | Acc  | Defined in   |
     +------------------+-----+---------------+------+--------------+
     | IMA_HMAC_CONTENT | 85  | ima_hmac4     | W    | Section 4.2  |
     | IMA_HMAC_ATTR    | 86  | ima_hmac4     | W    | Section 4.3  |
     | EVM_VERF_LIST    | 87  | evm_verflist4 | W    | Section 4.3  |
     +------------------+-----+---------------+------+--------------+

                                  Table 1

   When an NFSv4.2 server does not recognize, or does recognize but does
   not support, these new attributes, it must respond according to the
   requirements defined in Section 4.3 of [RFC8178].

4.2.  Protecting  Storing File Content

4.2.1.  Computing an IMA HMAC on an Provenance Metadata

   An NFS File

   Integrity measurement is performed on the entirety of a file's
   primary byte stream.  When version 4.2 client stores file provenance information by
   sending a SETATTR operation that specifies the FATTR4_FILE_PROVENANCE
   attribute, targeting the file is first accessed, after file
   content changes, or if any portion of a file is evicted from an
   NFSv4.2 client's cache, the file's entire byte stream must be read in
   order for the IMA module to verify that the stored HMAC matches the
   just-computed HMAC.  This requirement can incur a significant
   performance impact for large files or files that change frequently.

   An NFSv4.2 client may employ mechanisms, not specified here, to
   reduce this performance impact.  For example, instead of signing a
   hash of the file's byte stream, a Merkle tree can be constructed that
   allows clients to verify the integrity of smaller portions of a large
   file [MERKLE].  The top hash of that tree can be signed instead of
   signing the HMAC of associated with the file content.  This Merkle tree is then used provenance
   information to verify subsections of the file's byte stream that are needed by
   applications running on an NFSv4.2 client.

4.2.2.  Storing an IMA HMAC

   An NFSv4.2 client stores the HMAC of an NFS file's byte stream by
   sending a SETATTR operation that specifies the
   FATTR4_IMA_HMAC_CONTENT attribute. be stored.  This HMAC attribute completely replaces the any
   previous one.  To remove the FATTR4_IMA_HMAC_CONTENT this attribute from a file, the client specifies an ima_hmac_data field sends
   a FATTR4_FILE_PROVENANCE attribute whose length is zero.

   When a SETATTR is presented to an NFSv4.2 NFS version 4.2 server with a
   credential that is unauthorized to replace the FATTR4_IMA_HMAC_CONTENT FATTR4_FILE_PROVENANCE
   attribute, the server MUST respond with NFS4ERR_ACCESS.  This
   document does not specify a policy for authorizing changes to the
   FATTR4_IMA_HMAC_CONTENT attribute.

   When a SETATTR is presented to an NFSv4.2 NFS version 4.2 server with an
   ima_hmac_data a
   fattr4_file_provenance field that whose length is larger than IMA_HMAC_MAXSIZE,
   FILEPROV4_MAXSIZE, the server MUST respond with NFS4ERR_NAMETOOLONG.

   When a SETATTR is presented to an NFSv4.2 NFS version 4.2 server that
   supports
   FATTR4_IMA_HMAC_CONTENT, FATTR4_FILE_PROVENANCE, but the SETATTR targets an object
   which does not support this attribute, the server MUST respond with
   NFS4ERR_TYPE.

   Likewise, an NFSv4.2

4.3.  Retrieving File Provenance Metadata

   An NFS version 4.2 client retrieves the HMAC of an NFS file's byte
   stream file provenance information by
   retrieving the FATTR4_IMA_HMAC_CONTENT FATTR4_FILE_PROVENANCE attribute via a GETATTR operation.
   operation, specifying the file handle of the file associated with the
   information to be retrieved.  This HMAC information may have been computed (and signed)
   and signed previously on this client or by some other agent.  An NFSv4.2 server
   MUST NOT prevent an NFSv4.2 client from accessing

   When a file based on
   HMAC verification failures on the server.

4.3.  Protecting File Attributes

4.3.1.  Computing an EVM HMAC on GETATTR is presented to an NFS File

   The EVM HMAC protects a subset of file attributes, referred to as
   "verified attributes".  There are several categories of verified
   attributes:

   o  Normal (N).  Such an attribute is always present on a file, and is
      always verified by the file's EVM HMAC hash.

   o  Extended (E).  Such an attribute is a Linux extended attribute
      that may be present on a file.  If this attribute is present on a
      file, it is always verified by the file's EVM HMAC hash.

   o  File system (F).  Such an attribute is a file system attribute
      (ie., its value is the same for all files that share the same
      FSID).  If the local system configuration calls for it, this
      attribute is verified by a file's EVM HMAC hash.

   o  Optional (O).  Such an attribute is a Linux extended attribute
      that may be present on a file.  If the local system configuration
      calls for it, this attribute is verified by a file's EVM HMAC
      hash.

   The following table enumerates all attributes that may be a verified
   attribute.  File attributes not listed in this table are never
   included when computing an EVM HMAC hash.

   +---------------------------+-----+-------------------------+-------+
   | Name                      | Cat | NFSv4 equivalent        | Notes |
   +---------------------------+-----+-------------------------+-------+
   | inode number              | N   | fattr4_fileid           | 1     |
   | inode generation          | N   | fattr4_change           | 1     |
   | UID                       | N   | fattr4_owner            | 2     |
   | GID                       | N   | fattr4_owner_group      | 2     |
   | file mode                 | N   | fattr4_mode             | 3     |
   | security.selinux          | E   | NFSv4 SecLabel          | 4     |
   | security.ima              | E   | fattr4_ima_hmac_content |       |
   | security.SMACK64          | E   | None                    | 5     |
   | security.capabilities     | E   | None                    | 5     |
   | File system UUID          | F   | fattr4_evm_verf_list    |       |
   | security.SMACK64EXEC      | O   | None                    | 5     |
   | security.SMACK64TRANSMUTE | O   | None                    | 5     |
   | security.SMACK64MMAP      | O   | None                    | 5     |
   +---------------------------+-----+-------------------------+-------+

                                  Table 2

   Notes:

   1.  NFSv4.2 version 4.2 server and client implementations are responsible for
       ensuring that the native representation of these values correctly
       correspond anywhere that an EVM HMAC is to be computed.

   2.  The NFSv4 ID mapping configuration must ensure that numeric user
       ID values map identically whereever an EVM HMAC is to be
       computed.

   3.  Some implementations may alter the file mode bits depending on
   supports the presence of ACLs or a umask.

   4.  The security.selinux extended attribute typically maps to NFSv4
       Security Label LFS value 0.

   5.  This attribute is not exposed in current versions of NFSv4, FATTR4_FILE_PROVENANCE attribute, but
       may be exposed by future extensions to the NFSv4 protocol, or it
       may be accessible by other means.

   The EVM HMAC for a file must be updated whenever one or more verified
   attributes changes.  Whenever a verified attribute is present on a
   stored file, it MUST be accessible to the NFSv4.2 client computing
   that HMAC.  Otherwise, if that attribute is present and is not
   accessible when the HMAC is verified, the client's EVM module denies
   access to that file.

   To verify GETATTR
   targets an EVM HMAC, the verifier must know object which optional
   attributes were included when the hash was originally computed.  An
   NFSv4.2 server advertises this via the per file system
   FATTR4_EVM_VERF_LIST attribute (Section 5.4 of [RFC5661] defines the
   meaning of the term "per file system attribute").  If EVM HMACs are
   supported on a file system, the server MUST also support and expose
   FATTR4_EVM_VERF_LIST.

   If an FS UUID is included in the EVM HMACs on this file system, the
   server MUST fill in the evm_uuid field with its value.  The server
   MUST leave this field empty if the FS UUID is not included in EVM
   HMACs.  The server MUST append the names of all optional extended
   attributes included in the EVM HMACs on this file system.

   EVM HMAC hashes may be computed either on the NFSv4.2 server that
   contains the files, or by NFSv4.2 clients.  If an NFSv4.2 server or a
   shared file system can store these hashes, but the hashes are always
   computed elsewhere, the server still has to advertise the attribute
   input set that is used to compute EVM HMACs on this file system.

   An NFSv4.2 server MAY allow modifications of FATTR4_EVM_VERF_LIST by
   NFSv4.2 clients.  Changes to the value of this attribute render
   existing EVM HMACs on this file system invalid.  The format of the
   FATTR4_EVM_VERF_LIST attribute a client submits via SETATTR is the
   same as the the format the server uses when returning this attribute
   via GETATTR.

   If an NFSv4.2 client attempts to update this attribute and provides
   one or more unrecognized optional extended attributes, the server
   MUST respond with NFS4ERR_INVAL.  If an NFSv4.2 client attempts to
   update this attribute and the server does not support changes to it
   by clients, this attribute, the server
   MUST respond with NFS4ERR_INVAL, as required
   by Section 5.5 of [RFC5661].  This document does not specify a policy NFS4ERR_TYPE.  Otherwise, if no file provenance
   information is available for authorizing changes to the FATTR4_EVM_VERF_LIST attribute.

4.3.2.  Storing an EVM HMAC

   An NFSv4.2 client stores targeted file handle, the HMAC of server
   returns a FATTR4_FILE_PROVENANCE attribute whose length is zero.

   An NFS version 4.2 server MUST NOT prevent an NFS file's attributes by
   sending version 4.2 client
   from accessing a SETATTR operation that specifies the FATTR4_IMA_HMAC_ATTR
   attribute.  This HMAC completely replaces file based on provenance verification failures on
   the previous one.  To
   remove server.

4.4.  Performance Cost of Using File Provenance Metadata

   Computing a file checksum is typically performed on the FATTR4_IMA_HMAC_ATTR attribute from entirety of a file,
   file's content.  When a client
   specifies an ima_hmac_data field whose length file's content is zero.

   When first accessed, after it
   changes, or if any portion of a SETATTR file is presented to evicted from an NFSv4.2 server with NFS version
   4.2 client's cache, the client must retrieve any missing content
   before a credential
   that is unauthorized fresh checksum can be computed to replace the FATTR4_IMA_HMAC_ATTR attribute, verify the server MUST respond with NFS4ERR_ACCESS. file's content.
   This document does not
   specify can incur a policy significant performance impact for authorizing changes to the FATTR4_IMA_HMAC_ATTR
   attribute.

   When large files,
   files that change frequently, or files where only a SETATTR portion of the
   content is presented to an NFSv4.2 server with an
   ima_hmac_data field used on that is larger than IMA_HMAC_MAXSIZE, client (e.g., software libraries).

   An NFS version 4.2 client can employ mechanisms not specified here to
   reduce this impact.  For example, instead of signing a hash of the server
   MUST respond with NFS4ERR_NAMETOOLONG.

   When
   file's byte stream, a SETATTR is presented to an NFSv4.2 server Merkle tree can be constructed that supports
   FATTR4_IMA_HMAC_ATTR, but allows
   clients to verify the SETATTR targets an object 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 does
   not support this attribute, the server MUST respond with
   NFS4ERR_TYPE.

   Likewise, an NFSv4.2 client retrieves the HMAC is stored elsewhere, can be used to verify
   portions of an NFS the file's
   attributes by retrieving content without the FATTR4_IMA_HMAC_ATTR attribute via a
   GETATTR operation.  This HMAC may have been computed (and signed)
   previously on this client or by some other agent.  An NFSv4.2 server
   MUST NOT prevent an NFSv4.2 client from accessing a file based on
   HMAC verification failures on need to read the server. whole
   file.

5.  Security Considerations

   An NFSv4.2 NFS version 4.2 server is required REQUIRED to enforce a suitable level of
   privilege before permiting permitting a local or remote agent to alter IMA or
   EVM HMAC hashes. file
   provenance information.  This document does not specify a policy for
   authorizing replacement modification of IMA or EVM HMAC hashes. this information.

   When protected by both IMA and EVM HMAC hashes, file provenance information for a file exists, the content of a
   file
   and its attributes are is protected from end-to-end. creation to use.  Receivers can reliably
   detect unintentional or malicious alteration of file content
   or attributes by
   verifying the HMAC hashes that cover them. its content using file provenance information.  Additional
   protection of such file content or attributes while at rest or in transit on an
   untrusted network is not required.

   When an HMAC is cryptographically signed, 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 a signed HMAC file provenance information while at
   rest or in transit on an untrusted network is not required. unnecessary.

   In the rare cases when IMA and EVM HMAC hashes are file provenance information is not otherwise
   cryptographically protected, these hashes self-protected, the information MUST be protected
   while in transit on an untrusted network using a cryptographically
   strong transport layer security service that can detect tampering,
   such as RPCSEC with an integrity-protecting service [RFC7861].

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

6.  IANA Considerations

   This document does not require any actions by IANA.

7.  References

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

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

   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
              "PKCS #1: RSA Cryptography Specifications Version 2.2",
              RFC 8017, DOI 10.17487/RFC8017, November 2016,
              <https://www.rfc-editor.org/info/rfc8017>.

   [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, and Wim Coekaerts for his
   encouragement of this work.  Great thanks to Calum Mackay work, and Dave Noveck for his
   improved work on NFS
   version 4 extensibility.

   The XDR extraction script. 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 Chair Chairs Spencer Shepler, 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

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