draft-ietf-nfsv4-integrity-measurement-03.txt   draft-ietf-nfsv4-integrity-measurement-04.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 November 7, 2018 Intended status: Standards Track March 27, 2019
Expires: May 11, 2019 Expires: September 28, 2019
File Content Provenance for Network File System version 4 Integrity Measurement for Network File System version 4
draft-ietf-nfsv4-integrity-measurement-03 draft-ietf-nfsv4-integrity-measurement-04
Abstract Abstract
This document specifies an OPTIONAL extension to NFS version 4 minor This document specifies an OPTIONAL extension to NFS version 4 minor
version 2 that enables file provenance information to be conveyed version 2 that enables Linux Integrity Measurement Architecture
between NFS version 4.2 servers and clients. File provenance metadata (IMA) to be conveyed between NFS version 4.2 servers and
information authenticates the creator of a file's content and helps clients. Integrity measurement authenticates the creator of a file's
guarantee the content's integrity from creation to use. content and helps guarantee the content's integrity end-to-end 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 May 11, 2019. This Internet-Draft will expire on September 28, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
1.1. Architecture and Terminology . . . . . . . . . . . . . . 3 1.1. The Linux Integrity Measurement Architecture . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Extension Considerations . . . . . . . . . . . . . . 4 3. Protocol Extension Considerations . . . . . . . . . . . . . . 4
3.1. XDR Extraction . . . . . . . . . . . . . . . . . . . . . 4 3.1. XDR Extraction . . . . . . . . . . . . . . . . . . . . . 4
4. Managing File Provenance Information on NFS Files . . . . . . 5 4. Managing IMA Metadata on NFS Files . . . . . . . . . . . . . 5
4.1. XDR Definition . . . . . . . . . . . . . . . . . . . . . 5 4.1. XDR Definition . . . . . . . . . . . . . . . . . . . . . 5
4.2. Storing File Provenance Information . . . . . . . . . . . 6 4.2. Storing IMA Metadata . . . . . . . . . . . . . . . . . . 6
4.3. Retrieving File Provenance Information . . . . . . . . . 7 4.3. Retrieving IMA Metadata . . . . . . . . . . . . . . . . . 6
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Instantiating File Provenance Information . . . . . . . . 8 5.2. Instantiating IMA Metadata . . . . . . . . . . . . . . . 8
5.2.1. Authorizing Updates to File Provenance Information . 9 5.2.1. Authorizing Updates to IMA Metadata . . . . . . . . . 8
5.3. Interaction With Non-Participating Implementations . . . 9 5.3. Interaction With Non-Participating Implementations . . . 8
5.4. Performance Cost of Provenance Assessment . . . . . . . . 10 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.1. Linux NFS server and client . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The security of software distribution systems is complex and The security of software distribution systems is complex and
challenging, especially as software distribution has become challenging, especially as software distribution has become
increasingly decentralized. An end administrator needs to trust that increasingly decentralized. An end administrator needs to trust that
she is running executables just as they are supplied by a software she is running executables just as they are supplied by a software
vendor; in other words, that they have not been modified by malicious vendor; in other words, that they have not been modified by malicious
actors, contracted system administration services, or broken hardware actors, contracted system administration services, or broken hardware
or software. Software vendors want a guarantee that customer- or software. Software vendors want a guarantee that customer-
skipping to change at page 3, line 15 skipping to change at page 3, line 18
o For a distributed file system such as NFS, transport layer o For a distributed file system such as NFS, transport layer
security or a GSS integrity service (as described in [RFC7861]) security or a GSS integrity service (as described in [RFC7861])
can protect data while it traverses a network between a storage can protect data while it traverses a network between a storage
server and a client. server and a client.
A more extensive mechanism is needed to guarantee that no A more extensive mechanism is needed to guarantee that no
modification of a particular file has occurred since it was created, modification of a particular file has occurred since it was created,
perhaps even after several generations of copies have been made of perhaps even after several generations of copies have been made of
the file's content. the file's content.
This guarantee can be accomplished by separately preserving a keyed 1.1. The Linux Integrity Measurement Architecture
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
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's content is legitimately modified.
Unlike traditional integrity management schemes, the hash is not
replaced every time a file is copied. Instead, the signed checksum
is copied along with file content and presented whenever the content
is about to be used.
1.1. Architecture and Terminology
A keyed hash authenticates the identity of the last modifier of a The Linux Integrity Measurement Architecture (IMA) [1] provides
file's content and serves as a strong check of the content's assurance that the content of files is unaltered and authentic to
integrity. For the purposes of this document, we refer to this what was originally written to those files. The primary goal is to
metadata using the generic term "file provenance information". detect when a remote attacker, a local attacker, or unintentional
platform behavior has modified the content of a file either in
transit or at rest.
File provenance information is generated and signed by a "provenance A keyed hash (e.g., an HMAC [RFC2104]) authenticates the identity of
authority", and then associated with each file using special tools. the last modifier of a file's content and serves as a strong check of
the content's integrity. For the purposes of this document, we refer
to this hash as "IMA metadata". Such metadata is generated and
signed by a trusted authority and then associated with each file
using special tools.
A security module separate from the file system stack specifies the Each hash and its signature are verified as the file's content is
format of the file provenance information and enforces a policy for read into memory immediately before it is used. If verification
utilizing it to determine when a protected file's content is safe to fails, access to the file's content is prevented. A security module
use on the local system. For the purposes of this document, we refer separate from the file system specifies the format of the metadata,
to this module as a "provenance assessor", and the policy it uses as measures file content, and enforces a policy for determining when
the "provenance assessment policy". file content is safe to use on the local system. For the purposes of
this document, we refer to this module as the "integrity assessor"
and the policy it uses as the "appraisal policy".
Provenance assessment is typically performed at the point of content Appraisal is typically performed at the point of content use. The
use. The file and storage system play no part in provenance file and storage system play no part in measurement or appraisal.
assessment decisions. NFS acts only as a conduit by which file The file system acts only as a conduit by which IMA metadata and file
provenance information and file content move between storage on an content move between storage on an NFS server and the integrity
NFS server and the provenance assessor where that content is to be assessor module on the host where that content is to be used.
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.
The Linux Integrity Measurement Architecture (IMA) is an example of a NFS peers accessing a set of shared files must all agree on the IMA
mechanism that provides a full provenance assessment service metadata format. The format is specified by the integrity assessor
[IMA-WP]. The protocol extension in this document enables the module and is therefore not described in this document. The protocol
storage and use of file provenance information so that provenance extension in this document enables the storage and use of IMA
assessment can occur at point-of-use on NFS clients. The extension metadata so that measurement and appraisal can occur at point-of-use
does not provide a full assessment mechanism. on NFS clients. The extension does not provide a full assessment
mechanism.
A Trusted Platform Module [TPM-SUM] can seal the key material used to A Trusted Platform Module [2] can seal key material used to sign and
sign and verify file content. Distributing and protecting such key verify file content. Distributing and protecting such key material
material is outside the scope of the OPTIONAL extension specified in is outside the scope of the extension specified in this document.
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119] [RFC8174] "OPTIONAL" in this document are to be interpreted as described in BCP
when, and only when, they appear in all capitals, as shown here. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Protocol Extension Considerations 3. Protocol Extension Considerations
This document specifies an OPTIONAL extension to NFS version 4 minor This document specifies an OPTIONAL extension to NFS version 4 minor
version 2 [RFC7862], hereafter referred to as NFS version 4.2. NFS version 2 [RFC7862], hereafter referred to as NFS version 4.2. NFS
version 4.2 servers and clients implemented without knowledge of this version 4.2 servers and clients implemented without knowledge of this
extension will continue to interoperate with NFS version 4.2 clients extension will continue to interoperate with NFS version 4.2 clients
and servers that are aware of the extension, whether or not they and servers that are aware of the extension, whether or not they
support it. support it.
skipping to change at page 5, line 4 skipping to change at page 4, line 48
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 -n -e 's:^ */// ::p' -e 's:^ *///$::p' sed -n -e 's:^ */// ::p' -e 's:^ *///$::p'
<CODE ENDS> <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 That is, if this document is in a file called "ima-extension.txt"
description file: then the reader can do the following to extract an XDR description
file:
<CODE BEGINS> <CODE BEGINS>
sed -n -e 's:^ */// ::p' -e 's:^ *///$::p' sed -n -e 's:^ */// ::p' -e 's:^ *///$::p'
< provenance-extension.txt > ima.x < ima-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 File Provenance Information on NFS Files 4. Managing IMA Metadata on NFS Files
4.1. XDR Definition 4.1. XDR Definition
This section defines a new data type to encapsulate and a new This section defines a new data type to encapsulate and a new
OPTIONAL attribute to access and update file provenance information OPTIONAL attribute to access and update IMA metadata associated with
associated with a particular file. a particular file.
To enable a single file provenance information payload to be To enable a single IMA metadata payload to be retrieved or updated
retrieved or updated via a single RPC, and to constrain the transport via a single RPC, and to constrain the transport resources required
resources required for the operations defined in this section, the for the operations defined in this section, the length of IMA
length of file provenance information MUST NOT exceed 4096 bytes in metadata MUST NOT exceed 4096 bytes in length.
length.
When an NFS version 4.2 server does not recognize, or does recognize When an NFS version 4.2 server does not recognize, or does recognize
but does not support, this new attribute, the server responds in but does not support, this new attribute, the server responds in
accordance with the requirements specified in Section 4.3 of accordance with the requirements specified in Section 4.3 of
[RFC8178]. [RFC8178].
<CODE BEGINS> <CODE BEGINS>
/// /* /// /*
/// * Copyright (c) 2018 IETF Trust and the person identified /// * Copyright (c) 2019 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
/// */ /// */
/// ///
/// struct file_prov4 {
/// uint32_t fpv_type;
/// opaque fpv_data<>;
/// };
///
/// %/* /// %/*
/// % * New For File Provenance Information /// % * New For Linux IMA support
/// % */ /// % */
/// typedef file_prov4 fattr4_file_provenance; /// opaque ima_data<4096>;
/// ///
/// const FATTR4_FILE_PROVENANCE = XXX; /* to be assigned */ /// const FATTR4_LINUX_IMA = XXX; /* to be assigned */
<CODE ENDS> <CODE ENDS>
4.2. Storing File Provenance Information 4.2. Storing IMA Metadata
An NFS version 4.2 client stores file provenance information by An NFS version 4.2 client stores IMA metadata by sending a SETATTR
sending a SETATTR operation that specifies the FATTR4_FILE_PROVENANCE operation that specifies the FATTR4_LINUX_IMA attribute, targeting
attribute and an fpv_type, targeting the file object associated with the file object associated with the metadata to be stored. This
the file provenance information to be stored. This attribute attribute completely replaces any previous one.
completely replaces any previous one with the same fpv_type field.
To remove a file provenance attribute from a file, the client sends a To remove IMA metadata from a file, the client sends a
FATTR4_FILE_PROVENANCE attribute whose length is zero. Modifying the FATTR4_LINUX_IMA attribute whose length is zero. Modifying the file
file in any other way MUST NOT alter or remove FATTR4_FILE_PROVENANCE in any other way MUST NOT alter or remove FATTR4_LINUX_IMA
attributes. attributes.
When a SETATTR is presented to an NFS version 4.2 server with a When a SETATTR is presented to an NFS version 4.2 server with a
credential that is not authorized to replace a FATTR4_FILE_PROVENANCE credential that is not authorized to replace a FATTR4_LINUX_IMA
attribute, the server MUST respond with NFS4ERR_ACCESS. attribute, the server MUST respond with NFS4ERR_ACCESS.
When a SETATTR is presented to an NFS version 4.2 server with a When a SETATTR is presented to an NFS version 4.2 server with a
fattr4_file_provenance field whose length is larger than the maximum fattr4_linux_ima field whose length is larger than 4096 bytes, the
size specified in Table 1 for that fpv_type, the server MUST respond server MUST respond with NFS4ERR_INVAL.
with NFS4ERR_INVAL.
When a SETATTR is presented to an NFS version 4.2 server and the When a SETATTR is presented to an NFS version 4.2 server and the
target object resides in a file system which supports target object resides in a file system which supports
FATTR4_FILE_PROVENANCE but the object does not support FATTR4_LINUX_IMA but the object itself does not support the
FATTR4_FILE_PROVENANCE attributes, the server MUST respond with FATTR4_LINUX_IMA attribute, the server MUST respond with
NFS4ERR_WRONGTYPE. NFS4ERR_WRONGTYPE.
When a SETATTR is presented to an NFS version 4.2 server but the 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 target object resides in a file system which does not support the
FATTR4_FILE_PROVENANCE or does not support the format associated with FATTR4_LINUX_IMA attribute, the server MUST respond with
the specified fpv_type, the server MUST respond with
NFS4ERR_ATTRNOTSUPP. NFS4ERR_ATTRNOTSUPP.
A detailed description of the SETATTR operation can be found in A detailed description of the SETATTR operation can be found in
Section 18.30 of [RFC5661]. Section 18.30 of [RFC5661].
4.3. Retrieving File Provenance Information 4.3. Retrieving IMA Metadata
An NFS version 4.2 client retrieves file provenance information by An NFS version 4.2 client retrieves IMA metadata by retrieving the
retrieving the FATTR4_FILE_PROVENANCE attribute via a GETATTR FATTR4_LINUX_IMA attribute via a GETATTR operation, specifying the
operation, specifying an fpv_type and the file handle of the file file handle of the file object associated with the metadata to be
object associated with the information to be retrieved. This retrieved. This information may have been computed and signed
information may have been computed and signed previously on this previously on this client or by some other agent.
client or by some other agent.
When a GETATTR is presented to an NFS version 4.2 server and the When a GETATTR is presented to an NFS version 4.2 server and the
target object resides in a file system which supports target object resides in a file system which supports the
FATTR4_FILE_PROVENANCE but the object does not support FATTR4_LINUX_IMA attribute but the object does not support the
FATTR4_FILE_PROVENANCE attributes, the server MUST respond with FATTR4_LINUX_IMA attribute, the server MUST respond with
NFS4ERR_WRONGTYPE. NFS4ERR_WRONGTYPE.
When a GETATTR is presented to an NFS version 4.2 server but the 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 target object resides in a file system which does not support
FATTR4_FILE_PROVENANCE or does not support the format associated with FATTR4_LINUX_IMA, this does not result in an error and the
the specified fpv_type, this does not result in an error and the FATTR4_FILE_PROVENANCE attribute bit is cleared in the server's
FATTR4_FILE_PROVENANCE attribute bit is clear in the server's
response. response.
Otherwise, if the target object supports FATTR4_FILE_PROVENANCE and Otherwise, if the target object supports FATTR4_LINUX_IMA and there
there is no file provenance information is available for the target is no IMA metadata is available for the target object, the server
object, the server returns a FATTR4_FILE_PROVENANCE attribute whose returns a FATTR4_LINUX_IMA attribute whose length is zero.
length is zero.
Provenance assessors operate after file content has been delivered Integrity assessment occurs after file content has been delivered but
but immediately before that content is to be used. To enable immediately before that content is to be used. To enable integrity
provenance assessors on NFS clients to verify file provenance assessment on NFS clients to verify IMA metadata, NFS version 4.2
information, NFS version 4.2 servers do not prevent access to file servers should not prevent access to file content if they have a
content if they have a local provenance assessor and it indicates local appraisal policy and it indicates that integrity verification
that provenance verification has failed. has failed.
A detailed description of the GETATTR operation can be found in A detailed description of the GETATTR operation can be found in
Section 18.7 of [RFC5661]. Section 18.7 of [RFC5661].
5. Operation 5. Operation
5.1. Terminology 5.1. Terminology
To aid the discussion in this section, we define a few handy terms: 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 o A "participating client" is an NFS version 4.2 client that
supports the OPTIONAL extension described in this document and supports the OPTIONAL extension described in this document and
employs a provenance assessor. employs a integrity assessor module.
o A "non-participating client" is an NFS version 4.2 client that o A "non-participating client" is an NFS version 4.2 client that
does not support the OPTIONAL extension described in this document does not support the OPTIONAL extension described in this document
or does not employ a provenance assessor. or does not employ a integrity assessor module.
o A "participating server" is an NFS version 4.2 server that o A "participating server" is an NFS version 4.2 server that
supports the OPTIONAL extension described in this document and its supports the OPTIONAL extension described in this document and its
shared filesystems can store file provenance information. shared filesystems can store IMA metadata. A participating server
is not required to implement an integrity assessor module.
o A "non-participating server" is an NFS version 4.2 server that o A "non-participating server" is an NFS version 4.2 server that
does not support the OPTIONAL extension described in this document does not support the OPTIONAL extension described in this document
or its shared filesystems are not capable of storing file or its shared filesystems are not capable of storing IMA metadata.
provenance information.
In addition, there are intermediate modes of operation on In addition, there are intermediate modes of operation on
participating peers: participating peers:
o A "full-function client" is a participating client that supports o A "full-function client" is a participating client that supports
updating remote file provenance information. updating remote IMA metadata.
o A "fetch-only client" is a participating client that does not o A "fetch-only client" is a participating client that does not
support modifying file provenance information on a participating support modifying IMA metadata on a participating server.
server.
o A "full-function server" is a participating server that supports o A "full-function server" is a participating server that supports
updating file provenance information that resides on local shared updating IMA metadata that resides on local shared file systems.
file systems.
o A "store-only server" is a participating server where there is o A "store-only server" is a participating server where there is
only remote access to file provenance information. only remote access to IMA metadata.
5.2. Instantiating File Provenance Information 5.2. Instantiating IMA Metadata
Once a file is written, file provenance information is generated and Once a file is written, IMA metadata is generated and signed by an
signed by an appropriate provenance authority. Using the OPTIONAL appropriate trust authority. Using the OPTIONAL extension specified
extension specified in this document, the information can be in this document, the information can be associated with a file on
associated with a file on either a full-function server or client either a full-function server or client using a tool with appropriate
using a tool with appropriate privileges that writes the provenance privileges that writes IMA metadata to the shared file system. When
information to the shared file system. When using a store-only using a store-only server, only a full-function client can place IMA
server, only a full-function client can place file provenance metadata in the shared file system.
information in the shared file system.
Typically, once file provenance information is associated with a Typically, once IMA metadata is associated with a file, the file's
file, the file's content is essentially immutable, even if the file content is essentially immutable, even if the file has write
has write permissions. This is because changing the content without permissions. This is because changing the content without updating
updating the associated file provenance information will make the the associated IMA metadata will make the content inaccessible,
content inaccessible, depending on the provenance assessment policy depending on the appraisal policy in effect. Thus updating the file
in effect. Thus updating the file content usually requires content usually requires generating fresh IMA metadata.
generating fresh file provenance information.
5.2.1. Authorizing Updates to File Provenance Information 5.2.1. Authorizing Updates to IMA Metadata
A participating server should ensure that modifications to file A participating server should ensure that modifications to IMA
provenance information are done only by appropriately authorized metadata are done only by appropriately authorized agents. Such
agents. Such agents usually include only the owner of a file and agents usually include only agents with super-user privileges. The
agents with super-user privileges. NFS server MAY confirm that the new IMA metadata actually verifies
the file content correctly before storing it.
5.3. Interaction With Non-Participating Implementations 5.3. Interaction With Non-Participating Implementations
Because the protocol extension described herein is OPTIONAL, clients Because the protocol extension described herein is OPTIONAL, clients
and servers that support it must necessarily interact with clients and servers that support it must necessarily interact with clients
and servers that do not support it. To set the stage for a and servers that do not support it. To set the stage for a
discussion of interactions that might occur, consider the following discussion of interactions that might occur, consider the following
possible simple provenance assessment policies that might be adopted possible simple appraisal policies that might be adopted by an
by a provenance assessor (actual polices are left to provenance integrity assessment module:
assessors):
Strict: Access is prevented to a file's content if the file has no Strict: Access is prevented to a file's content if the file has no
provenance information or if the provenance information fails to IMA metadata or if the extant IMA metadata fails to verify the
verify the file content. Otherwise access to the file's content file content. Otherwise access to the file's content is not
is not prevented. prevented.
Audit: Access to a file's content is never prevented. Warnings are Audit: Access to a file's content is never prevented. Warnings are
reported when a file has no provenance information or when reported when a file has no IMA metadata or when extant IMA
existing provenance information fails to verify the file's metadata fails to verify the file's content.
content.
Disabled: Access to file content is never prevented and provenance Disabled: Access to file content is never prevented and IMA metadata
information is ignored. is ignored.
Given the above example policies and the definitions we provided Given the above example policies and the definitions we provided
earlier for participating and non-participating implementations, the earlier for participating and non-participating implementations, the
following statements are true: following statements are true:
o A participating client that uses the Disabled policy is equivalent o A participating client that uses the Disabled policy is equivalent
to a non-participating client. to a non-participating client.
o A non-participating client never prevents access to file content o A non-participating client never prevents access to file content
on a participating server. on a participating server.
o A participating client using the Strict policy never allows access o A participating client using the Strict policy never allows access
to files stored on a non-participating server. to files stored on a non-participating server.
A provenance assessor on an NFS version 4.2 peer needs to be prepared A integrity assessor module on an NFS version 4.2 peer needs to be
to deal with file provenance information it does not recognize or prepared to deal with IMA metadata it does not recognize or cannot
cannot parse. Typically its policy treats this case as a provenance parse. Its policy may treat this case as a appraisal failure.
verification failure.
Note that an NFS version 4.2 server may use a provenance assessor to Note that an NFS version 4.2 server may use a integrity assessor
prevent access by local users to protected files. To enable NFS module to prevent access by local users to protected files. To
version 4.2 clients to do their own assessment, an NFS version 4.2 enable NFS version 4.2 clients to do their own assessment, an NFS
server should not prevent remote access to participating clients if version 4.2 server should not prevent remote access to participating
local provenance assessment fails. clients if local integrity assessment fails.
5.4. Performance Cost of Provenance Assessment 6. Implementation Status
A provenance assessor typically checksums the entirety of a file's This section records the status of known implementations of the
content. When a file's content is first accessed, after it changes, protocol defined by this specification at the time of posting of this
or if any portion of a file is evicted from an NFS version 4.2 Internet-Draft, and is based on a proposal described in [RFC7942].
client's cache, the client must retrieve any missing content before The description of implementations in this section is intended to
its local provenance assessor can compute a fresh checksum to verify assist the IETF in its decision processes in progressing drafts to
the file's content. RFCs.
Thus provenance assessment can incur a significant performance impact Please note that the listing of any individual implementation here
for large files, files that change frequently, or files where only a does not imply endorsement by the IETF. Furthermore, no effort has
portion of the content is used on that client (e.g., software been spent to verify the information presented here that was supplied
libraries). A provenance assessor can employ mechanisms not by IETF contributors. This is not intended as, and must not be
specified here to reduce this impact. construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
For example, instead of signing a hash of the file's byte stream, a 6.1. Linux NFS server and client
Merkle tree can be constructed that allows assessors to verify the
integrity of smaller portions of a large file [MERKLE]. The root
hash of that tree, being of sufficiently limited size, can be signed
and stored as file provenance information. The Merkle tree, which is
stored elsewhere, can be used to verify portions of the file's
content without the need to read the whole file.
NFS can provide an offload mechanism to mitigate some of the network Organization: The Linux Foundation
and CPU utilization costs of provenance assessment on clients. If
there is a strong trust relationship between clients and server, and
the network transport is of very high integrity, the NFS server can
perform provenance assessment in lieu of exposing file provenance
information to clients.
6. Security Considerations URL: https://www.kernel.org
Maturity: Prototype software based on early versions of this
document.
Coverage: The bulk of this specification is implemented.
Licensing: GPLv2
Implementation experience: No comments from implementors.
7. Security Considerations
The design of the OPTIONAL extension described in this document The design of the OPTIONAL extension described in this document
assumes that all file provenance information is keyed or otherwise assumes that all IMA metadata is keyed or otherwise cryptographically
cryptographically signed by a provenance authority to prevent signed by a trust authority to prevent unwanted alteration at rest or
unwanted alteration at rest or in transit. in transit.
When file provenance information for a file exists, the content of a When IMA metadata for a file exists and the end host has adopted an
file is protected from creation to use. Receivers can reliably IMA policy, the content of a file is protected from creation to use.
detect unintentional or malicious alteration of file content by Receivers can reliably detect unintentional or malicious alteration
verifying its content using file provenance information. Additional of file content by verifying its content using the file's IMA
protection of file content while at rest or in transit on an metadata. Additional protection of file content while at rest or in
untrusted network is unnecessary. transit on an untrusted network is unnecessary.
Likewise, receivers can also reliably detect unintentional or Likewise, receivers can also reliably detect unintentional or
malicious alteration of file provenance information that is malicious alteration of IMA metadata that is cryptographically
cryptographically signed, simply by verifying its signature. signed, simply by verifying its signature. Additional protection of
Additional protection of signed file provenance information while at signed metadata while at rest or in transit on an untrusted network
rest or in transit on an untrusted network is unnecessary. is unnecessary.
Like other mechanisms that protect data integrity during transit, A Like other mechanisms that protect data integrity during transit, A
malicious agent or a network malfunction can create a denial-of- malicious agent or a network malfunction can create a denial-of-
service condition by repeatedly triggering integrity verification service condition by repeatedly triggering integrity verification
failures on NFS version 4.2 clients. failures on NFS version 4.2 clients.
To prevent a malicious denial-of-service attempt by altering file To prevent a malicious denial-of-service attempt by altering IMA
provenance information at rest, an NFS version 4.2 server should metadata at rest, an NFS version 4.2 server can enforce a suitable
enforce a suitable level of privilege before authorizing a local or level of privilege before authorizing a local or remote agent to
remote agent to alter this information. See Section 5.2.1 for more alter this information. See Section 5.2.1 for more detail.
detail.
7. IANA Considerations
In accordance with [RFC8126], the author requests that the Internet
Assigned Numbers Authority (IANA) create a new registry in the
"Network File System version 4" Protocol Category Group. The new
registry is to be called the "File Provenance Information Format
Registry".
The new registry has the following fields:
Code Point: An integer that maps to a particular File Provenance
Information format. The namespace of this identifier has the
range 0..4204067295. Or, a range of values to be used for the
same purpose.
Description: A human-readable ASCII text string that concisely
describes the File Provenance Information format. The length of
this field is limited to 128 bytes.
Max Size: An integer that expresses the largest possible size, in
octets, required to store a single item of File Provenance
Information. Typical values are 4096 or 9000. A hyphen is stored
here when the Code Point column contains a range.
Reference: A reference to a stable public document that requested
this entry. The document should describe the File Provenance
Information format and any specialized storage requirements, or
should reference other public documents as appropriate.
The initial assignments of the registry appear in Table 1.
+--------------+----------------------------+----------+------------+
| Code Point | Description | Max Size | Reference |
+--------------+----------------------------+----------+------------+
| 0 | Linux IMA | 4096 | [RFC-TBD] |
| 1 - 2^31-1 | Available for IANA | - | [RFC-TBD] |
| | Assignment | | |
| 2^31 - | Private and Experimental | - | [RFC-TBD] |
| 2^32-1 | Use | | |
+--------------+----------------------------+----------+------------+
Table 1: File Provenance Information Format Registry
A format specification document is recommended to add a new entry to
the "File Provenance Information Registry". If the format document
is inside the RFC track, then the IANA Considerations section of the
format document should reference the "File Provenance Information
Registry" and request allocation of a new entry. The well-known IANA
policy Expert Review, as defined in Section 4.5 of [RFC8126] is to be
used to handle requests to add new entries to the "File Provenance
Information Registry".
When reviewing published file provenance specifications, the
Designated Expert should consider whether or not the specified file
provenance format allows a correct and complete implementation of the
protocol to process this information as a policy administration
mechanism. To reduce interoperability issues, the reviewer must
determine if the file provenance information format specification has
clearly defined syntax and semantics.
For registration requests where a Designated Expert should be 8. IANA Considerations
consulted, the responsible IESG area director should appoint the
Designated Expert. Allocation of ranges of code points (more than
one for a given purpose) should require IETF Consensus. Code point
allocations SHOULD NOT be made for purposes unrelated to managing
file provenance information.
A request to modify either the Description or the published file This document requests no action from IANA.
provenance information format specification requires the Expert
Review IANA policy to be applied. If the format document is inside
the RFC track, the IANA Considerations section of the updated
specification should be explicit regarding which old label selector
assignment it modifies.
8. References 9. References
8.1. Normative References 9.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>.
skipping to change at page 13, line 42 skipping to change at page 11, line 36
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Writing an IANA Considerations Section in RFCs", BCP 26, Code: The Implementation Status Section", BCP 205,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor [RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor
Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017,
<https://www.rfc-editor.org/info/rfc8178>. <https://www.rfc-editor.org/info/rfc8178>.
8.2. Informative References 9.2. Informative References
[IMA-WP] Safford, D., "An Overview of The Linux Integrity
Subsystem", <http://downloads.sf.net/project/linux-ima/
linux-ima/Integrity_overview.pdf>.
[MERKLE] Merkle, R., ""A Digital Signature Based on a Conventional
Encryption Function" Advances in Cryptology - CRYPTO '87",
DOI 10.1007/3-540-48184-2_32, 1988.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [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., [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"Network File System (NFS) Version 4 Minor Version 1 "Network File System (NFS) Version 4 Minor Version 1
External Data Representation Standard (XDR) Description", External Data Representation Standard (XDR) Description",
RFC 5662, DOI 10.17487/RFC5662, January 2010, RFC 5662, DOI 10.17487/RFC5662, January 2010,
<https://www.rfc-editor.org/info/rfc5662>. <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>.
[TPM-SUM] Trusted Computing Group, "Trusted Platform Module (TPM) 9.3. URIs
Summary", April 2008, <https://trustedcomputinggroup.org/
wp-content/uploads/ [1] http://downloads.sf.net/project/linux-ima/linux-ima/
Trusted-Platform-Module-Summary_04292008.pdf>. Integrity_overview.pdf
[2] https://trustedcomputinggroup.org/wp-content/uploads/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, Wim Coekaerts for his early review of the concepts in this document, Wim Coekaerts for his
encouragement of this work, and Dave Noveck for his work on NFS encouragement of this work, and Dave Noveck for his work on NFS
version 4 extensibility. version 4 extensibility.
The author wishes to acknowledge review comments from Dave Noveck, The author wishes to acknowledge review comments from Dave Noveck,
Craig Everhart, and Bruce Fields which helped to make this a better Craig Everhart, and Bruce Fields which helped to make this a better
document. Benjamin Kaduk proposed the File Provenance Information document.
Registry.
The XDR extraction conventions were first described by the authors of The XDR extraction conventions were first described by the authors of
the NFS version 4.1 XDR specification [RFC5662]. Herbert van den the NFS version 4.1 XDR specification [RFC5662]. Herbert van den
Bergh suggested the replacement sed script used in this document. 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 Magnus Westerlund, NFSV4
Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4
Working Group 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
Ann Arbor, MI 48104
United States of America United States of America
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
 End of changes. 78 change blocks. 
328 lines changed or deleted 230 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/