draft-ietf-nfsv4-integrity-measurement-00.txt   draft-ietf-nfsv4-integrity-measurement-01.txt 
Network File System Version 4 C. Lever Network File System Version 4 C. Lever
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track May 29, 2018 Intended status: Standards Track September 24, 2018
Expires: November 30, 2018 Expires: March 28, 2019
Integrity Measurement for Network File System version 4 File Content Provenance for Network File System version 4
draft-ietf-nfsv4-integrity-measurement-00 draft-ietf-nfsv4-integrity-measurement-01
Abstract Abstract
This document specifies an OPTIONAL extension to NFS version 4.2 that This document specifies an OPTIONAL extension to NFS version 4 minor
enables Linux Integrity Measurement Architecture metadata (IMA) to be version 2 that enables file provenance information to be conveyed
conveyed between NFSv4.2 servers and clients. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 30, 2018. This Internet-Draft will expire on March 28, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 10 skipping to change at page 2, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Extension Considerations . . . . . . . . . . . . . . 3 3. Protocol Extension Considerations . . . . . . . . . . . . . . 3
3.1. XDR Extraction . . . . . . . . . . . . . . . . . . . . . 3 4. Managing File Provenance Metadata on NFS Files . . . . . . . 4
4. Managing IMA Metadata on NFS Files . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4.1. XDR Definition . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.2. Protecting File Content . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Protecting File Attributes . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Linux Integrity Measurement Architecture (IMA) provides assurance The security of software distribution systems is complex and
that the content of files is unaltered and authentic to what was challenging, especially as software distribution has become
originally written to those files. In addition, an Extended increasingly decentralized. An end administrator needs to trust that
Verification Module (EVM) assures that file attribute information she is running executables just as they are supplied by a software
remains similarly unaltered. 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.
The primary goal is to detect when a remote attacker, a local There already exist mechanisms that protect file data during certain
attacker, or unintentional software behavior has modified the content portions of a file's life cycle:
or attributes of a file either in transit or at rest. This is done
by separately storing HMAC hashes [RFC2104] of a file's byte stream
content and attribute metadata. These hashes are updated whenever
the file is legitimately modified. The hashes themselves can be
protected by cryptographic signature.
Subsequent integrity verification is not performed by applications or o Whole file system checksumming can verify so-called Golden Master
by file systems. File systems are responsible only for persistent installation media before it is used to install the software it
storage of file content and hashes. When a file is read, content, contains.
attributes, and hashes are passed to IMA and EVM modules for
measurement and appraisal. Application access is denied if the
hashes or their signatures cannot be verified.
Some files may be immutable, in which case their integrity metadata o File or block integrity mechanisms can protect data at rest on
is signed by an RSA public key signature [RFC8017]. Such files can storage servers.
be accessed 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 o For a distributed file system such as NFS, transport layer
metadata must be protected. A Trusted Platform Module [TPM-SUM] can security or a GSS integrity service (as described in [RFC7861])
be used to seal the key material. This use case is typical for can protect data while it traverses a network between a storage
providing a read-only operating system image that is server and a client.
cryptographically verified; for example, in a cloud environment or on
mobile devices.
On Linux, there are two parts to a file's IMA metadata: 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.
o An HMAC hash, possibly cryptographically signed, of the file's This guarantee can be accomplished by separately preserving a keyed
byte stream, stored in the file's security.ima extended attribute. 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
file's content is denied. The hash is updated and re-signed only
when the file is legitimately modified.
o An HMAC hash, possibly cryptographically signed, of a subset of A keyed hash authenticates the identity of the last modifier of a
the file's attributes, stored in the file's security.evm extended file's content and serves as a strong check of the content's
attribute. 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].
The goals and use cases of the Linux Integrity Measurement A Trusted Platform Module [TPM-SUM] can seal the key material used to
Architecture (IMA) are presented in further detail in [IMA-WP]. 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 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119] document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown [RFC8174] when, and only when, they appear in all capitals, as shown
here. here.
3. Protocol Extension Considerations 3. Protocol Extension Considerations
This document specifies an OPTIONAL extension to NFSv4 minor version This document specifies an OPTIONAL extension to NFS version 4 minor
2 [RFC7862]. NFSv4.2 servers and clients implemented without version 2 [RFC7862], hereafter referred to as NFS version 4.2. NFS
knowledge of this extension will continue to interoperate with version 4.2 servers and clients implemented without knowledge of this
NFSv4.2 clients and servers that are aware of the extension, whether extension will continue to interoperate with NFS version 4.2 clients
or not they support it. and servers that are aware of the extension, whether or not they
support it.
Because [RFC7862] does not define NFSv4.2 as non-extensible, Because [RFC7862] does not define NFS version 4.2 as non-extensible,
[RFC8178] treats it as an extensible minor version. Therefore this [RFC8178] treats it as an extensible minor version. Therefore this
Standards Track RFC extends NFSv4.2 but does not update [RFC7862] or Standards Track RFC extends NFS version 4.2 but does not update
[RFC7863]. [RFC7862] or [RFC7863].
3.1. XDR Extraction 3.1. XDR Extraction
Section 4.1 contains a description of an extension to the NFSv4.2 Section 4.1 contains a description of an extension to the NFS version
protocol, expressed in the External Data Representation (XDR) 4.2 protocol, expressed in the External Data Representation (XDR)
language [RFC4506]. This description is provided in a way that makes language [RFC4506]. This description is provided in a way that makes
it simple to extract into ready-to-compile form. The reader can it simple to extract into ready-to-compile form. The reader can
apply the following sed script to this document to produce a machine- apply the following sed script to this document to produce a machine-
readable XDR description of the extension. readable XDR description of the extension.
<CODE BEGINS> <CODE BEGINS>
sed -E 's:^ */// ?::;t;d' sed -n -e 's:^ */// ::p' -e 's:^ *///$::p'
<CODE ENDS> <CODE ENDS>
That is, if this document is in a file called "integrity- That is, if this document is in a file called "provenance-
extension.txt" then the reader can do the following to extract an XDR extension.txt" then the reader can do the following to extract an XDR
description file: description file:
<CODE BEGINS> <CODE BEGINS>
sed -E 's:^ */// ?::;t;d' < integrity-extension.txt > ima.x sed -n -e 's:^ */// ::p' -e 's:^ *///$::p'
< provenance-extension.txt > ima.x
<CODE ENDS> <CODE ENDS>
Once that extraction is done, these added lines need to be inserted Once that extraction is done, these added lines need to be inserted
into an appropriate base XDR of the generated XDR from [RFC7863] into an appropriate base XDR of the generated XDR from [RFC7863]
together with XDR from any additional extensions to be recognized by together with XDR from any additional extensions to be recognized by
the implementation. This will result in a ready-to-compile XDR file. the implementation. This will result in a ready-to-compile XDR file.
4. Managing IMA Metadata on NFS Files 4. Managing File Provenance Metadata on NFS Files
4.1. XDR Definition 4.1. XDR Definition
This section defines a new data structure used to transport HMAC This section defines a new data type to encapsulate and a new
data, and two new OPTIONAL GETATTR attributes used to access and OPTIONAL GETATTR attribute to access and update file provenance
update HMAC data associated with a file. information associated with a particular file.
HMAC data is a varying length opaque array of octets. To enable a File provenance information is opaque to the NFS protocol. To ensure
single HMAC payload to be retrieved or updated in a single RPC, an interoperability among accessors of this information when it is
HMAC (including signatures) MUST NOT exceed 4096 bytes in length. 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].
<CODE BEGINS> <CODE BEGINS>
/// /* /// /*
/// * Copyright (c) 2018 IETF Trust and the person identified /// * Copyright (c) 2018 IETF Trust and the person identified
/// * as author of the code. All rights reserved. /// * as author of the code. All rights reserved.
/// * /// *
/// * The author of the code is: C. Lever /// * The author of the code is: C. Lever
/// */ /// */
/// ///
/// const IMA_HMAC_MAXSIZE = 4096; /// const FILEPROV4_MAXSIZE = 4096;
/// /// typedef opaque file_prov4<FILEPROV4_MAXSIZE>;
/// 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<>;
/// };
/// ///
/// %/* /// %/*
/// % * New For Integrity Measurement /// % * New For File Provenance Metadata
/// % */ /// % */
/// const FATTR4_IMA_HMAC_CONTENT = 85; /// const FATTR4_FILE_PROVENANCE = XXX; /* to be assigned */
/// const FATTR4_IMA_HMAC_ATTR = 86;
/// const FATTR4_EVM_VERF_LIST = 87;
/// ///
/// typedef ima_hmac4 fattr4_ima_hmac_content; /// typedef file_prov4 fattr4_file_provenance;
/// typedef ima_hmac4 fattr4_ima_hmac_attr;
/// typedef evm_verflist4 fattr4_evm_verf_list;
<CODE ENDS> <CODE ENDS>
+------------------+-----+---------------+------+--------------+ 4.2. Storing File Provenance Metadata
| 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 File Content
4.2.1. Computing an IMA HMAC on an NFS File
Integrity measurement is performed on the entirety of a file's
primary byte stream. When a 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 the file content. This Merkle tree is then used
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 An NFS version 4.2 client stores file provenance information by
sending a SETATTR operation that specifies the sending a SETATTR operation that specifies the FATTR4_FILE_PROVENANCE
FATTR4_IMA_HMAC_CONTENT attribute. This HMAC completely replaces the attribute, targeting the file associated with the file provenance
previous one. To remove the FATTR4_IMA_HMAC_CONTENT attribute from a information to be stored. This attribute completely replaces any
file, the client specifies an ima_hmac_data field whose length is previous one. To remove this attribute from a file, the client sends
zero. a FATTR4_FILE_PROVENANCE attribute whose length is zero.
When a SETATTR is presented to an NFSv4.2 server with a credential When a SETATTR is presented to an NFS version 4.2 server with a
that is unauthorized to replace the FATTR4_IMA_HMAC_CONTENT credential that is unauthorized to replace the FATTR4_FILE_PROVENANCE
attribute, the server MUST respond with NFS4ERR_ACCESS. This attribute, the server MUST respond with NFS4ERR_ACCESS.
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 server with an When a SETATTR is presented to an NFS version 4.2 server with a
ima_hmac_data field that is larger than IMA_HMAC_MAXSIZE, the server fattr4_file_provenance field whose length is larger than
MUST respond with NFS4ERR_NAMETOOLONG. FILEPROV4_MAXSIZE, the server MUST respond with NFS4ERR_NAMETOOLONG.
When a SETATTR is presented to an NFSv4.2 server that supports When a SETATTR is presented to an NFS version 4.2 server that
FATTR4_IMA_HMAC_CONTENT, but the SETATTR targets an object which does supports FATTR4_FILE_PROVENANCE, but the SETATTR targets an object
not support this attribute, the server MUST respond with which does not support this attribute, the server MUST respond with
NFS4ERR_TYPE. NFS4ERR_TYPE.
Likewise, an NFSv4.2 client retrieves the HMAC of an NFS file's byte 4.3. Retrieving File Provenance Metadata
stream by retrieving the FATTR4_IMA_HMAC_CONTENT 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 the server.
4.3. Protecting File Attributes
4.3.1. Computing an EVM HMAC on 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 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
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, 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 an EVM HMAC, the verifier must know 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, the server MUST respond with NFS4ERR_INVAL, as required
by Section 5.5 of [RFC5661]. This document does not specify a policy
for authorizing changes to the FATTR4_EVM_VERF_LIST attribute.
4.3.2. Storing an EVM HMAC 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
information to be retrieved. This information may have been computed
and signed previously on this client or by some other agent.
An NFSv4.2 client stores the HMAC of an NFS file's attributes by When a GETATTR is presented to an NFS version 4.2 server that
sending a SETATTR operation that specifies the FATTR4_IMA_HMAC_ATTR supports the FATTR4_FILE_PROVENANCE attribute, but the GETATTR
attribute. This HMAC completely replaces the previous one. To targets an object which does not support this attribute, the server
remove the FATTR4_IMA_HMAC_ATTR attribute from a file, a client MUST respond with NFS4ERR_TYPE. Otherwise, if no file provenance
specifies an ima_hmac_data field whose length is zero. information is available for the targeted file handle, the server
returns a FATTR4_FILE_PROVENANCE attribute whose length is zero.
When a SETATTR is presented to an NFSv4.2 server with a credential An NFS version 4.2 server MUST NOT prevent an NFS version 4.2 client
that is unauthorized to replace the FATTR4_IMA_HMAC_ATTR attribute, from accessing a file based on provenance verification failures on
the server MUST respond with NFS4ERR_ACCESS. This document does not the server.
specify a policy for authorizing changes to the FATTR4_IMA_HMAC_ATTR
attribute.
When a SETATTR is presented to an NFSv4.2 server with an 4.4. Performance Cost of Using File Provenance Metadata
ima_hmac_data field that is larger than IMA_HMAC_MAXSIZE, the server
MUST respond with NFS4ERR_NAMETOOLONG.
When a SETATTR is presented to an NFSv4.2 server that supports Computing a file checksum is typically performed on the entirety of a
FATTR4_IMA_HMAC_ATTR, but the SETATTR targets an object which does file's content. When a file's content is first accessed, after it
not support this attribute, the server MUST respond with changes, or if any portion of a file is evicted from an NFS version
NFS4ERR_TYPE. 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).
Likewise, an NFSv4.2 client retrieves the HMAC of an NFS file's An NFS version 4.2 client can employ mechanisms not specified here to
attributes by retrieving the FATTR4_IMA_HMAC_ATTR attribute via a reduce this impact. For example, instead of signing a hash of the
GETATTR operation. This HMAC may have been computed (and signed) file's byte stream, a Merkle tree can be constructed that allows
previously on this client or by some other agent. An NFSv4.2 server clients to verify the integrity of smaller portions of a large file
MUST NOT prevent an NFSv4.2 client from accessing a file based on [MERKLE]. The root hash of that tree, being of sufficiently limited
HMAC verification failures on the server. 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 5. Security Considerations
An NFSv4.2 server is required to enforce a suitable level of An NFS version 4.2 server is REQUIRED to enforce a suitable level of
privilege before permiting a local or remote agent to alter IMA or privilege before permitting a local or remote agent to alter file
EVM HMAC hashes. This document does not specify a policy for provenance information. This document does not specify a policy for
authorizing replacement of IMA or EVM HMAC hashes. authorizing modification of this information.
When protected by both IMA and EVM HMAC hashes, the content of a file When file provenance information for a file exists, the content of a
and its attributes are protected from end-to-end. Receivers can file is protected from creation to use. Receivers can reliably
reliably detect unintentional or malicious alteration of file content detect unintentional or malicious alteration of file content by
or attributes by verifying the HMAC hashes that cover them. verifying its content using file provenance information. Additional
Additional protection of such content or attributes while in transit protection of file content while at rest or in transit on an
on an untrusted network is not required. untrusted network is unnecessary.
When an HMAC is cryptographically signed, receivers can reliably Likewise, receivers can also reliably detect unintentional or
detect unintentional or malicious alteration simply by verifying its malicious alteration of file provenance information that is
signature. Additional protection of a signed HMAC while in transit cryptographically signed, simply by verifying its signature.
on an untrusted network is not required. Additional protection of signed file provenance information while at
rest or in transit on an untrusted network is unnecessary.
In cases when IMA and EVM HMAC hashes are not otherwise In the rare cases when file provenance information is not
cryptographically protected, these hashes MUST be protected while in cryptographically self-protected, the information MUST be protected
transit on an untrusted network using a cryptographically strong while in transit on an untrusted network using a cryptographically
transport layer security service that can detect tampering, such as strong transport layer security service that can detect tampering,
RPCSEC with an integrity-protecting service [RFC7861]. such as RPCSEC with an integrity-protecting service [RFC7861].
Like other mechanisms that protect integrity during transit, it is Like other mechanisms that protect data integrity during transit, A
possible for a malicious agent or a network malfunction to create a malicious agent or a network malfunction can create a denial-of-
denial-of-service condition by repeatedly triggering integrity service condition by repeatedly triggering integrity verification
verification failures on clients. failures on NFS version 4.2 clients.
6. IANA Considerations 6. IANA Considerations
This document does not require any actions by IANA. This document does not require any actions by IANA.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation [RFC4506] Eisler, M., Ed., "XDR: External Data Representation
Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
2006, <https://www.rfc-editor.org/info/rfc4506>. 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 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
November 2016, <https://www.rfc-editor.org/info/rfc7862>. November 2016, <https://www.rfc-editor.org/info/rfc7862>.
[RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 External Data Representation Standard (XDR) Version 2 External Data Representation Standard (XDR)
Description", RFC 7863, DOI 10.17487/RFC7863, November Description", RFC 7863, DOI 10.17487/RFC7863, November
2016, <https://www.rfc-editor.org/info/rfc7863>. 2016, <https://www.rfc-editor.org/info/rfc7863>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
skipping to change at page 12, line 10 skipping to change at page 8, line 24
[MERKLE] Merkle, R., ""A Digital Signature Based on a Conventional [MERKLE] Merkle, R., ""A Digital Signature Based on a Conventional
Encryption Function" Advances in Cryptology - CRYPTO '87", Encryption Function" Advances in Cryptology - CRYPTO '87",
DOI 10.1007/3-540-48184-2_32, 1988. DOI 10.1007/3-540-48184-2_32, 1988.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <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) [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", RFC 7861, DOI 10.17487/RFC7861, Security Version 3", RFC 7861, DOI 10.17487/RFC7861,
November 2016, <https://www.rfc-editor.org/info/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) [TPM-SUM] Trusted Computing Group, "Trusted Platform Module (TPM)
Summary", April 2008, <https://trustedcomputinggroup.org/ Summary", April 2008, <https://trustedcomputinggroup.org/
wp-content/uploads/ wp-content/uploads/
Trusted-Platform-Module-Summary_04292008.pdf>. Trusted-Platform-Module-Summary_04292008.pdf>.
Acknowledgments Acknowledgments
The author wishes to thank Mimi Zohar and James Morris for their The author wishes to thank Mimi Zohar and James Morris for their
early review of the concepts in this document, and Wim Coekaerts for early review of the concepts in this document, Wim Coekaerts for his
his encouragement of this work. Great thanks to Calum Mackay for his encouragement of this work, and Dave Noveck for his work on NFS
improved XDR extraction script. 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 Special thanks go to Transport Area Director Spencer Dawkins, NFSV4
Working Group Chair Spencer Shepler, and NFSV4 Working Group Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4
Secretary Thomas Haynes for their support. Working Group Secretary Thomas Haynes for their support.
Author's Address Author's Address
Charles Lever Charles Lever
Oracle Corporation Oracle Corporation
1015 Granger Avenue 1015 Granger Avenue
Ann Arbor, MI 48104 Ann Arbor, MI 48104
United States of America United States of America
Phone: +1 248 816 6463 Phone: +1 248 816 6463
 End of changes. 50 change blocks. 
325 lines changed or deleted 182 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/