draft-ietf-nfsv4-integrity-measurement-01.txt   draft-ietf-nfsv4-integrity-measurement-02.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 September 24, 2018 Intended status: Standards Track October 8, 2018
Expires: March 28, 2019 Expires: April 11, 2019
File Content Provenance for Network File System version 4 File Content Provenance for Network File System version 4
draft-ietf-nfsv4-integrity-measurement-01 draft-ietf-nfsv4-integrity-measurement-02
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 file provenance information to be conveyed
between NFS version 4.2 servers and clients. File provenance between NFS version 4.2 servers and clients. File provenance
information authenticates the creator of a file's content and helps information authenticates the creator of a file's content and helps
guarantee the content's integrity from creation to use. guarantee the content's integrity from creation to use.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 March 28, 2019. This Internet-Draft will expire on April 11, 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
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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Extension Considerations . . . . . . . . . . . . . . 3 3. Protocol Extension Considerations . . . . . . . . . . . . . . 4
4. Managing File Provenance Metadata on NFS Files . . . . . . . 4 4. Managing File Provenance Information on NFS Files . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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 2, line 46 skipping to change at page 2, line 47
o File or block integrity mechanisms can protect data at rest on o File or block integrity mechanisms can protect data at rest on
storage servers. storage servers.
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,
even perhaps 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 This guarantee can be accomplished by separately preserving a keyed
hash, such as an HMAC [RFC2104], of a file's byte stream. This hash 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 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 memory immediately before it is used. If verification fails, access
file's content is denied. The hash is updated and re-signed only to the file's content is prevented. The hash is updated and re-
when the file is legitimately modified. signed only when the file is legitimately modified.
1.1. Architecture Summary
A keyed hash authenticates the identity of the last modifier of a 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 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 integrity. For the purposes of this document, we refer to this
as file provenance information. The Linux Integrity Measurement metadata using the generic term "file provenance information".
Architecture (IMA) is an example of a mechanism for assessing file
content provenance [IMA-WP]. File provenance information is generated and signed by a "provenance
authority", and then placed in the file system using special tools.
A security module separate from the file system stack specifies the
format of the file provenance information and enforces a policy for
utilizing it to determine when a protected file's content is safe to
use on the local system. For the purposes of this document, we refer
to this module as a "provenance assessor", and the policy it uses as
the "provenance assessment policy".
NFS acts as a conduit by which file provenance information and file
content move between storage on an NFS server and the provenance
assessor where that content is to be accessed. NFS peers accessing a
set of shared files must all agree on the at-rest file provenance
information format. The format is specified by the provenance
assessor and is therefore not described in this document.
A Trusted Platform Module [TPM-SUM] can seal the key material used to A Trusted Platform Module [TPM-SUM] can seal the key material used to
sign and verify file content. Distributing and protecting such key sign and verify file content. Distributing and protecting such key
material is outside the scope of the NFS protocol extension specified material is outside the scope of the OPTIONAL extension specified in
in this document. this document.
The Linux Integrity Measurement Architecture (IMA) is an example of a
mechanism that provides a full provenance assessment service
[IMA-WP]. The protocol extension in this document enables the
storage and use of file provenance information to protect files
stored on an NFS server.
2. Requirements Language 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
skipping to change at page 4, line 27 skipping to change at page 5, line 5
sed -n -e 's:^ */// ::p' -e 's:^ *///$::p' sed -n -e 's:^ */// ::p' -e 's:^ *///$::p'
< provenance-extension.txt > ima.x < 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 File Provenance Metadata on NFS Files 4. Managing File Provenance Information 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 GETATTR attribute to access and update file provenance OPTIONAL attribute to access and update file provenance information
information associated with a particular file. 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 To enable a single file provenance information payload to be
retrieved or updated via a single RPC, and to constrain the transport retrieved or updated via a single RPC, and to constrain the transport
resources required for the operations defined here, the payload MUST resources required for the operations defined in this section, the
NOT exceed 4096 bytes in length. length of file provenance information MUST NOT exceed 4096 bytes in
length.
When an NFS version 4.2 server does not recognize, or does recognize 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) 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 FILEPROV4_MAXSIZE = 4096; /// const FILEPROV4_MAXSIZE = 4096;
/// typedef opaque file_prov4<FILEPROV4_MAXSIZE>; /// typedef opaque file_prov4<FILEPROV4_MAXSIZE>;
/// ///
/// %/* /// %/*
/// % * New For File Provenance Metadata /// % * New For File Provenance Information
/// % */ /// % */
/// const FATTR4_FILE_PROVENANCE = XXX; /* to be assigned */ /// const FATTR4_FILE_PROVENANCE = XXX; /* to be assigned */
/// ///
/// typedef file_prov4 fattr4_file_provenance; /// typedef file_prov4 fattr4_file_provenance;
<CODE ENDS> <CODE ENDS>
4.2. Storing File Provenance Metadata 4.2. Storing File Provenance Information
An NFS version 4.2 client stores file provenance information by An NFS version 4.2 client stores file provenance information by
sending a SETATTR operation that specifies the FATTR4_FILE_PROVENANCE sending a SETATTR operation that specifies the FATTR4_FILE_PROVENANCE
attribute, targeting the file associated with the file provenance attribute, targeting the file object associated with the file
information to be stored. This attribute completely replaces any provenance information to be stored. This attribute completely
previous one. To remove this attribute from a file, the client sends replaces any previous one.
a FATTR4_FILE_PROVENANCE attribute whose length is zero.
To remove this attribute from a file, the client sends a
FATTR4_FILE_PROVENANCE attribute whose length is zero. [ cel: Does
writing to a file have any effect on IMA metadata? ]
When a SETATTR is presented to an NFS version 4.2 server with a When a SETATTR is presented to an NFS version 4.2 server with a
credential that is unauthorized to replace the FATTR4_FILE_PROVENANCE credential that is not authorized to replace the
attribute, the server MUST respond with NFS4ERR_ACCESS. 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 When a SETATTR is presented to an NFS version 4.2 server with a
fattr4_file_provenance field whose length is larger than fattr4_file_provenance field whose length is larger than
FILEPROV4_MAXSIZE, the server MUST respond with NFS4ERR_NAMETOOLONG. FILEPROV4_MAXSIZE, the server MUST respond with NFS4ERR_INVAL.
When a SETATTR is presented to an NFS version 4.2 server that When a SETATTR is presented to an NFS version 4.2 server and the
supports FATTR4_FILE_PROVENANCE, but the SETATTR targets an object target object resides in a file system which supports
which does not support this attribute, the server MUST respond with FATTR4_FILE_PROVENANCE but the object does not support this
NFS4ERR_TYPE. attribute, the server MUST respond with NFS4ERR_WRONGTYPE.
4.3. Retrieving File Provenance Metadata When a SETATTR is presented to an NFS version 4.2 server but the
target object resides in a file system which does not support
FATTR4_FILE_PROVENANCE, the server MUST respond with
NFS4ERR_ATTRNOTSUPP.
A detailed description of the SETATTR operation can be found in
Section 18.30 of [RFC5661].
4.3. Retrieving File Provenance Information
An NFS version 4.2 client retrieves file provenance information by An NFS version 4.2 client retrieves file provenance information by
retrieving the FATTR4_FILE_PROVENANCE attribute via a GETATTR retrieving the FATTR4_FILE_PROVENANCE attribute via a GETATTR
operation, specifying the file handle of the file associated with the operation, specifying the file handle of the file object associated
information to be retrieved. This information may have been computed with the information to be retrieved. This information may have been
and signed previously on this client or by some other agent. 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 When a GETATTR is presented to an NFS version 4.2 server and the
supports the FATTR4_FILE_PROVENANCE attribute, but the GETATTR target object resides in a file system which supports
targets an object which does not support this attribute, the server FATTR4_FILE_PROVENANCE but the object does not support this
MUST respond with NFS4ERR_TYPE. Otherwise, if no file provenance attribute, the server MUST respond with NFS4ERR_WRONGTYPE.
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 When a GETATTR is presented to an NFS version 4.2 server but the
from accessing a file based on provenance verification failures on target object resides in a file system which does not support
the server. FATTR4_FILE_PROVENANCE, this does not result in an error and the
FATTR4_FILE_PROVENANCE attribute bit is clear in the server's
response.
4.4. Performance Cost of Using File Provenance Metadata Otherwise, if the target object supports FATTR4_FILE_PROVENANCE and
there is no file provenance information is available for the target
object, the server returns a FATTR4_FILE_PROVENANCE attribute whose
length is zero.
Computing a file checksum is typically performed on the entirety of a Provenance assessors operate after file content has been delivered
file's content. When a file's content is first accessed, after it but immediately before that content is to be used. To enable
changes, or if any portion of a file is evicted from an NFS version provenance assessors on NFS clients to verify file provenance
4.2 client's cache, the client must retrieve any missing content information, NFS version 4.2 servers do not prevent access to file
before a fresh checksum can be computed to verify the file's content. content if they have a local provenance assessor and it indicates
This can incur a significant performance impact for large files, that provenance verification has failed.
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 A detailed description of the GETATTR operation can be found in
reduce this impact. For example, instead of signing a hash of the Section 18.7 of [RFC5661].
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 5. Operation
An NFS version 4.2 server is REQUIRED to enforce a suitable level of 5.1. Terminology
privilege before permitting a local or remote agent to alter file
provenance information. This document does not specify a policy for To aid the discussion in this section, we define a few handy terms:
authorizing modification of this information.
o A "participating client" is an NFS version 4.2 client that
supports the OPTIONAL extension described in this document and
employs a provenance assessor.
o A "non-participating client" is an NFS version 4.2 client that
does not support the OPTIONAL extension described in this document
or does not employ a provenance assessor.
o A "participating server" is an NFS version 4.2 server that
supports the OPTIONAL extension described in this document and its
shared filesystems can store file provenance information.
o A "non-participating server" is an NFS version 4.2 server that
does not support the OPTIONAL extension described in this document
or its shared filesystems are not capable of storing file
provenance information.
In addition, there are intermediate modes of operation on
participating peers:
o A "full-function client" is a participating client that supports
updating remote file provenance information.
o A "fetch-only client" is a participating client that does not
support modifying file provenance information on a participating
server.
o A "full-function server" is a participating server that supports
updating file provenance information that resides on local shared
file systems.
o A "store-only server" is a participating server where there is
only remote access to file provenance information.
5.2. Instantiating File Provenance Information
Once a file is written, file provenance information is generated and
signed by an appropriate provenance authority. Using the OPTIONAL
extension specified in this document, the information can be
associated with a file on either a full-function server or client
using a tool with appropriate privileges that writes the provenance
information to the shared file system. When using a store-only
server, only a full-function client can place file provenance
information in the shared file system.
Typically, once file provenance information is associated with a
file, the file's content is essentially immutable, even if the file
has write permissions. This is because changing the content without
updating the associated file provenance information will make the
content inaccessible, depending on the provenance assessment policy
in effect. Thus updating the file content usually requires
generating fresh file provenance information.
5.2.1. Authorizing Updates to File Provenance Information
A participating server should ensure that modifications to file
provenance information are done only by appropriately authorized
agents.
[ cel: TBD. Regular users are probably not able to modify a local
security.ima xattr. What kind of authority should be required to
modify FPI remotely? ]
5.3. Interaction With Non-Participating Implementations
Because the protocol extension described herein is OPTIONAL, clients
and servers that support it must necessarily interact with clients
and servers that do not support it. To set the stage for a
discussion of interactions that might occur, consider the following
possible simple provenance assessment policies that might be adopted
by a provenance assessor (actual polices are left to provenance
assessors):
Strict
Access is prevented to a file's content if the file has no
provenance information or if the provenance information fails to
verify the file content. Otherwise access to the file's content
is not prevented.
Audit
Access to a file's content is never prevented. Warnings are
reported when a file has no provenance information or when
existing provenance information fails to verify the file's
content.
Disabled
Access to file content is never prevented and provenance
information is ignored.
Given the above example policies and the definitions we provided
earlier for participating and non-participating implementations, the
following statements are true:
o A participating client that uses the Disabled policy is equivalent
to a non-participating client.
o A non-participating client never prevents access to file content
on a participating server.
o A participating client using the Strict policy never allows access
to files stored on a non-participating server.
A provenance assessor on an NFS version 4.2 peer needs to be prepared
to deal with file provenance information it does not recognize or
cannot parse. Typically its policy treats this case as a provenance
verification failure.
Note that an NFS version 4.2 server may use a provenance assessor to
prevent access by local users to protected files. To enable NFS
version 4.2 clients to do their own assessment, an NFS version 4.2
server should never prevent remote access to clients if local
provenance assessment fails.
5.4. Performance Cost of Using File Provenance Information
A provenance assessor typically checksums the entirety of a file's
content. When a file's content is first accessed, after it changes,
or if any portion of a file is evicted from an NFS version 4.2
client's cache, the client must retrieve any missing content before
its local provenance assessor can compute a fresh checksum to verify
the file's content.
Thus provenance assessment can incur a significant performance impact
for large files, files that change frequently, or files where only a
portion of the content is used on that client (e.g., software
libraries). A provenance assessor can employ mechanisms not
specified here to reduce this impact.
For example, instead of signing a hash of the file's byte stream, a
Merkle tree can be constructed that allows assessors to verify the
integrity of smaller portions of a large file [MERKLE]. The root
hash of that tree, being of sufficiently limited size, can be signed
and stored as file provenance information. The Merkle tree, which is
stored elsewhere, can be used to verify portions of the file's
content without the need to read the whole file.
6. Security Considerations
The design of the OPTIONAL extension described in this document
assumes that all file provenance information is keyed or otherwise
cryptographically signed by a provenance authority to prevent
unwanted alteration at rest or in transit.
When file provenance information for a file exists, the content of a When file provenance information for a file exists, the content of a
file is protected from creation to use. Receivers can reliably file is protected from creation to use. Receivers can reliably
detect unintentional or malicious alteration of file content by detect unintentional or malicious alteration of file content by
verifying its content using file provenance information. Additional verifying its content using file provenance information. Additional
protection of file content while at rest or in transit on an protection of file content while at rest or in transit on an
untrusted network is unnecessary. 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 file provenance information that is
cryptographically signed, simply by verifying its signature. cryptographically signed, simply by verifying its signature.
Additional protection of signed file provenance information while at Additional protection of signed file provenance information while at
rest or in transit on an untrusted network is unnecessary. 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 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.
6. IANA Considerations To prevent a malicious denial-of-service attempt by altering file
provenance information at rest, an NFS version 4.2 server should
enforce a suitable level of privilege before authorizing a local or
remote agent to alter this information. See Section 5.2.1 for more
detail.
7. IANA Considerations
This document does not require any actions by IANA. This document does not require any actions by IANA.
7. References 8. References
7.1. Normative References 8.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
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>.
7.2. Informative References 8.2. Informative References
[IMA-WP] Safford, D., "An Overview of The Linux Integrity [IMA-WP] Safford, D., "An Overview of The Linux Integrity
Subsystem", <http://downloads.sf.net/project/linux-ima/ Subsystem", <http://downloads.sf.net/project/linux-ima/
linux-ima/Integrity_overview.pdf>. linux-ima/Integrity_overview.pdf>.
[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-
skipping to change at page 8, line 46 skipping to change at page 12, line 32
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, 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,
Craig Everhart, and Bruce Fields which helped to make this a better
document.
The XDR extraction conventions were first described by the authors of The 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 Spencer Dawkins, 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 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
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
 End of changes. 35 change blocks. 
92 lines changed or deleted 268 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/