Network File System Version 4 C. Lever
Internet-Draft Oracle
Intended status: Standards Track September 24, 2018
Expires: March 28, 2019
File Content Provenance for Network File System version 4
draft-ietf-nfsv4-integrity-measurement-01
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 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.
Lever Expires March 28, 2019 [Page 1]
Internet-Draft File Provenance for NFS September 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Extension Considerations . . . . . . . . . . . . . . 3
4. Managing File Provenance Metadata on NFS Files . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
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,
even perhaps 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 byte stream. This hash
and its signature are verified as the file's content is read into
memory just before it is used. If verification fails, access to the
Lever Expires March 28, 2019 [Page 2]
Internet-Draft File Provenance for NFS September 2018
file's content is denied. The hash is updated and 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) 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 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.
Lever Expires March 28, 2019 [Page 3]
Internet-Draft File Provenance for NFS September 2018
<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.
4. Managing File Provenance Metadata on NFS Files
4.1. XDR Definition
This section defines a new data type to encapsulate and a new
OPTIONAL GETATTR attribute to access and update file provenance
information associated with a particular file.
File provenance information is opaque to the NFS protocol. To ensure
interoperability among accessors of this information when it is
stored on NFS version 4.2 servers, this information MUST be self-
describing.
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 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].
Lever Expires March 28, 2019 [Page 4]
Internet-Draft File Provenance for NFS September 2018
<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 Metadata
/// % */
/// const FATTR4_FILE_PROVENANCE = XXX; /* to be assigned */
///
/// typedef file_prov4 fattr4_file_provenance;
<CODE ENDS>
4.2. Storing File Provenance Metadata
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 associated with the file provenance
information to be stored. This attribute completely replaces any
previous one. To remove this attribute from a file, the client sends
a FATTR4_FILE_PROVENANCE attribute whose length is zero.
When a SETATTR is presented to an NFS version 4.2 server with a
credential that is unauthorized 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_NAMETOOLONG.
When a SETATTR is presented to an NFS version 4.2 server that
supports FATTR4_FILE_PROVENANCE, but the SETATTR targets an object
which does not support this attribute, the server MUST respond with
NFS4ERR_TYPE.
4.3. Retrieving File Provenance Metadata
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 associated with the
Lever Expires March 28, 2019 [Page 5]
Internet-Draft File Provenance for NFS September 2018
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 that
supports the FATTR4_FILE_PROVENANCE attribute, but the GETATTR
targets an object which does not support this attribute, the server
MUST respond with NFS4ERR_TYPE. Otherwise, if no file provenance
information is available for the targeted file handle, the server
returns a FATTR4_FILE_PROVENANCE attribute whose length is zero.
An NFS version 4.2 server MUST NOT prevent an NFS version 4.2 client
from accessing a file based on provenance verification failures on
the server.
4.4. Performance Cost of Using File Provenance Metadata
Computing a file checksum is typically performed on 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 a fresh checksum can be computed to verify the file's content.
This 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).
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
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 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.
5. Security Considerations
An NFS version 4.2 server is REQUIRED to enforce a suitable level of
privilege before permitting a local or remote agent to alter file
provenance information. This document does not specify a policy for
authorizing modification of this information.
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.
Lever Expires March 28, 2019 [Page 6]
Internet-Draft File Provenance for NFS September 2018
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.
In the rare cases when file provenance information is not
cryptographically 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, 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.
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>.
[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>.
Lever Expires March 28, 2019 [Page 7]
Internet-Draft File Provenance for NFS September 2018
[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>.
[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 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.
Lever Expires March 28, 2019 [Page 8]
Internet-Draft File Provenance for NFS September 2018
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
Lever Expires March 28, 2019 [Page 9]