draft-ietf-nfsv4-integrity-measurement-05.txt   draft-ietf-nfsv4-integrity-measurement-06.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 June 6, 2019 Intended status: Standards Track September 21, 2019
Expires: December 8, 2019 Expires: March 24, 2020
Integrity Measurement for Network File System version 4 Integrity Measurement for Network File System version 4
draft-ietf-nfsv4-integrity-measurement-05 draft-ietf-nfsv4-integrity-measurement-06
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 Linux Integrity Measurement Architecture version 2 that enables Linux Integrity Measurement Architecture
metadata (IMA) to be conveyed between NFS version 4.2 servers and metadata (IMA) to be conveyed between NFS version 4.2 servers and
clients. Integrity measurement authenticates the creator of a file's clients. Integrity measurement authenticates the creator of a file's
content and helps guarantee the content's integrity end-to-end from content and helps guarantee the content's integrity end-to-end from
creation to use. creation to use.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 December 8, 2019. This Internet-Draft will expire on March 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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. The Linux Integrity Measurement Architecture . . . . . . 3 1.1. The Linux Integrity Measurement Architecture . . . . . . 3
1.1.1. IMA Metadata . . . . . . . . . . . . . . . . . . . . 4 1.1.1. IMA Metadata . . . . . . . . . . . . . . . . . . . . 4
1.1.2. Creating and Verifying IMA Metadata . . . . . . . . . 4 1.1.2. Creating and Verifying IMA Metadata . . . . . . . . . 4
1.1.3. Distributing and Protecting Keying Material . . . . . 5 1.1.3. Distributing and Protecting Keying Material . . . . . 5
1.1.4. Using IMA to Protect NFS Files . . . . . . . . . . . 5 1.1.4. Using IMA to Protect NFS Files . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 1.2. An Illustrative Use Case . . . . . . . . . . . . . . . . 5
3. Protocol Extension Considerations . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
3.1. XDR Extraction . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Extension Considerations . . . . . . . . . . . . . . 6
4. Managing IMA Metadata on NFS Files . . . . . . . . . . . . . 6 3.1. XDR Extraction . . . . . . . . . . . . . . . . . . . . . 7
4.1. XDR Definition . . . . . . . . . . . . . . . . . . . . . 6 4. Managing IMA Metadata on NFS Files . . . . . . . . . . . . . 7
4.1.1. NFS4ERR_INTEGRITY (Error Code YYYYY) . . . . . . . . 7 4.1. XDR Definition . . . . . . . . . . . . . . . . . . . . . 7
4.2. Detecting support for IMA Metadata . . . . . . . . . . . 7 4.1.1. NFS4ERR_INTEGRITY (Error Code YYYYY) . . . . . . . . 8
4.2.1. Reporting Server-Side IMA Appraisal Failures . . . . 7 4.2. Detecting support for IMA Metadata . . . . . . . . . . . 8
4.3. Storing IMA Metadata . . . . . . . . . . . . . . . . . . 8 4.2.1. Reporting Server-Side IMA Appraisal Failures . . . . 9
4.3.1. Sending IMA Metadata When Creating a New Object . . . 9 4.3. Storing IMA Metadata . . . . . . . . . . . . . . . . . . 9
4.3.2. Authorizing Updates to IMA Metadata . . . . . . . . . 9 4.3.1. Sending IMA Metadata When Creating a New Object . . . 10
4.4. Retrieving IMA Metadata . . . . . . . . . . . . . . . . . 10 4.3.2. Authorizing Updates to IMA Metadata . . . . . . . . . 10
4.5. Using NFS Attribute Fencing (VERIFY/NVERIFY) . . . . . . 10 4.4. Retrieving IMA Metadata . . . . . . . . . . . . . . . . . 11
5. Deployment Examples . . . . . . . . . . . . . . . . . . . . . 11 4.5. Using NFS Attribute Fencing (VERIFY/NVERIFY) . . . . . . 12
5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 11 5. Deployment Examples . . . . . . . . . . . . . . . . . . . . . 12
5.2. Instantiating IMA Metadata . . . . . . . . . . . . . . . 12 5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Interaction With Non-Participating Implementations . . . 12 5.2. Instantiating IMA Metadata . . . . . . . . . . . . . . . 13
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 5.3. Interaction With Legacy Implementations . . . . . . . . . 14
6.1. Linux NFS server and client . . . . . . . . . . . . . . . 14 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6.1. Linux NFS server and client . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
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 4, line 7 skipping to change at page 4, line 7
the storage subsystem. the storage subsystem.
An informative description of this mechanism is presented in the An informative description of this mechanism is presented in the
following subsections to provide context for understanding the NFS following subsections to provide context for understanding the NFS
protocol extension described later in this document. As the file protocol extension described later in this document. As the file
system does not interpret IMA metadata, this description is not system does not interpret IMA metadata, this description is not
necessary to implement the extension. necessary to implement the extension.
1.1.1. IMA Metadata 1.1.1. IMA Metadata
A cryptographically signed hash stored separately from a file's First, it is important to understand the distinction between a
content serves as a strong check of file content integrity and checksum, a hash, and a cryptographically-signed hash.
authenticates the identity of the provider of the file's content.
o A checksum, or parity, is designed to detect and possibly correct
one or two bit errors in a fixed amount of content.
o A hash's purpose is to detect both accidental and malicious
alterations. Typically a hash is a small fixed size, but can be
computed over a very large amount of content.
o A cryptographically-signed hash is the basis for a digital
signature. The signatory of a cryptographically-signed hash gives
a guarantee that the hash, and therefore the hashed content, has
not been changed, since the hash was signed.
A cryptographically-signed hash stored separately from a file's
content therefore serves as a strong check of file content integrity
and authenticates the identity of the provider of the file's content.
The signer is verified at time of content use via a web of trust The signer is verified at time of content use via a web of trust
commonly provided by PKI or x.509 certificates [RFC4158]. commonly provided by PKI or x.509 certificates [RFC4158].
The hash is typically computed using either the SHA-1 or SHA-256 The hash is typically computed using either the SHA-1 or SHA-256
algorithm and is stored as an HMAC [RFC2104]. For the purposes of algorithm and is stored as an HMAC [RFC2104]. For the purposes of
this document, the current document refers to this blob as "IMA this document, the current document refers to this blob as "IMA
metadata". metadata".
The precise format of this metadata is determined by policies set by The precise format of this metadata is determined by policies set by
the local security administrator; the metadata and its format are the local security administrator; the metadata and its format are
opaque to the mechanisms that store or transport it (i.e., file opaque to the mechanisms that store or transport it (i.e., file
systems). The particulars of the PKI and the hash algorithm are systems). The particulars of the PKI and the hash algorithm are set
agreed upon out-of-band and recognized by all participating IMA by local policy, which is agreed upon out-of-band and recognized by
subsystems. all participating IMA subsystems.
1.1.2. Creating and Verifying IMA Metadata 1.1.2. Creating and Verifying IMA Metadata
In a typical deployment, an authority (such as a software vendor) In a typical deployment, an authority (such as a software vendor)
computes the hash of a file after its content has been finalized. computes the hash of a file after its content has been finalized.
The hash is then signed and attached to the file. A web of trust The hash is then signed and attached to the file. A web of trust
typically links the signer to the users of the file's content (such typically links the signer to the users of the file's content (such
as customers of the software vendor). as customers of the software vendor).
Directly before file content is to be used, a security module locally Directly before file content is to be used, a security module locally
skipping to change at page 5, line 23 skipping to change at page 5, line 36
1.1.4. Using IMA to Protect NFS Files 1.1.4. Using IMA to Protect NFS Files
The protocol extension in this document enables the storage and use The protocol extension in this document enables the storage and use
of IMA metadata so that measurement and appraisal can occur at point- of IMA metadata so that measurement and appraisal can occur at point-
of-use on NFS client and server hosts. This mechanism is similar to of-use on NFS client and server hosts. This mechanism is similar to
NFSv4 Security Labels (specified in [RFC7862] et al). The purpose of NFSv4 Security Labels (specified in [RFC7862] et al). The purpose of
the mechanism defined in the current document is to store security- the mechanism defined in the current document is to store security-
related file metadata that is not interpreted by the file system related file metadata that is not interpreted by the file system
itself. itself.
1.2. An Illustrative Use Case
To help the reader grasp how IMA on NFS might be used in practice,
this section contains a decription of an IMA use case. The purpose
of using IMA here is to provide a guarantee that a set of users that
are executing a commercial software product are indeed using the same
binary executable and libraries that were developed and tested by the
product's vendor.
To publish a software product, a vendor might do the following:
1. The vendor generates a key pair and publishes the public key.
2. The vendor finalizes a version of its software product.
3. The vendor generates a hash of each file in the product's
distribution manifest, and signs each hash with its private key.
4. The vendor publishes the product's files and the signed hashes.
To install and use the vendor's product, a customer might do the
following:
1. The customer installs the files and the signed hashes in a local
filesystem.
2. When a user executes one of the files, a local security module
reads the file from disk and computes a hash of its content.
This is the measurement step, which happens when each file is
loaded into the system's page cache.
3. The security module uses the vendor's public key to verify the
signature of the file's stored hash, and confirms that the
locally computed hash matches the stored hash. This is the
appraisal step, which happens when each file is about to be
executed.
4. If the locally computed hash is verified, the security module
allows the operating system to execute the program. If not, then
the program fails to execute and an integrity error is logged.
The purpose of the NFS extension specified in the current document is
to enable the signed hashes in the above example to be stored by an
NFS server and retrieved by NFS clients. Each NFS client could then
verify that neither the NFS server nor an active network agent had
altered file content before it was used on the NFS client.
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Protocol Extension Considerations 3. Protocol Extension Considerations
skipping to change at page 8, line 25 skipping to change at page 9, line 32
REMOVE, RENAME, SETATTR, VERIFY, WRITE. The server MUST NOT return REMOVE, RENAME, SETATTR, VERIFY, WRITE. The server MUST NOT return
NFS4ERR_INTEGRITY for any other operation. NFS4ERR_INTEGRITY for any other operation.
The NFS4ERR_INTEGRITY status code is useful to inform the client (or The NFS4ERR_INTEGRITY status code is useful to inform the client (or
the end user, depending on the client implementation) that access to the end user, depending on the client implementation) that access to
the file's content was not blocked because of a permissions setting the file's content was not blocked because of a permissions setting
but rather because an integrity check failed. This distinction can but rather because an integrity check failed. This distinction can
guide the user or client towards a recovery action that is guide the user or client towards a recovery action that is
appropriate. appropriate.
[ cel: this is still an open issue ]
4.3. Storing IMA Metadata 4.3. Storing IMA Metadata
An NFS version 4.2 client stores IMA metadata by sending an NFS An NFS version 4.2 client stores IMA metadata by sending an NFS
SETATTR operation that specifies the FATTR4_IMA attribute and targets SETATTR operation that specifies the FATTR4_IMA attribute and targets
the file system object associated with the metadata to be stored. the file system object associated with the metadata to be stored.
This attribute completely replaces any previous FATTR4_IMA attribute This attribute completely replaces any previous FATTR4_IMA attribute
associated with that object. Modifying an object in any other way associated with that object. Modifying an object in any other way
MUST NOT alter or remove FATTR4_IMA attributes. MUST NOT alter or remove FATTR4_IMA attributes.
To remove IMA metadata from an object, the client sends a FATTR4_IMA To remove IMA metadata from an object, the client sends a FATTR4_IMA
skipping to change at page 9, line 33 skipping to change at page 10, line 39
during an NFS OPEN(CREATE) operation. Upon creation, an object has during an NFS OPEN(CREATE) operation. Upon creation, an object has
no content to protect. If a client presents an FATTR4_IMA attribute no content to protect. If a client presents an FATTR4_IMA attribute
to an NFS version 4.2 server during NFS OPEN(CREATE), the server MUST to an NFS version 4.2 server during NFS OPEN(CREATE), the server MUST
respond with NFS4ERR_INVAL. respond with NFS4ERR_INVAL.
4.3.2. Authorizing Updates to IMA Metadata 4.3.2. Authorizing Updates to IMA Metadata
An NFS version 4.2 server needs to ensure that modifications to IMA An NFS version 4.2 server needs to ensure that modifications to IMA
metadata are done only by appropriately authorized agents. Although metadata are done only by appropriately authorized agents. Although
access to file content is typically controlled by ACLs and permission access to file content is typically controlled by ACLs and permission
bits, these mechanisms do not apply to IMA metadata. The question of bits, these mechanisms do not apply to IMA metadata.
"who is authorized to modify IMA metadata" is left to local security
policy.
Possible implementations include limiting IMA metadata update The question of "who is authorized to modify IMA metadata" is often
authority to: left to the server's local IMA security policy. In addition, the
issue of whether to allow a particular IMA metadata update has no
bearing on protocol interoperability, as long as the server sticks to
returning NFS4ERR_ACCESS or NFS4ERR_INTEGRITY, as appropriate. Thus,
to enable server implementation flexibility, the current document
treats the following recommendations as implementation guidance
rather than as normative protocol requirements.
Possible NFS server implementations include limiting IMA metadata
update authority in the following ways:
Particular users Particular users
The server may allow IMA metadata updates only by UID 0 or by a A server might allow IMA metadata updates only by UID 0 or by a
client's machine principal. client's machine principal.
Particular clients Particular clients
The server may allow IMA metadata updates only from specific A server might allow IMA metadata updates only from specific
client IP addresses. client IP addresses.
File owners File owners
The server may allow IMA metadata updates only by the file's owner A server might allow IMA metadata updates only by the file's owner
or group owner. or group owner.
[ cel: this is still an open issue. ] No remote updates
A server might always return NFS4ERR_ACCESS when an NFS client
sends a SETATTR request that updates IMA metadata.
4.4. Retrieving IMA Metadata 4.4. Retrieving IMA Metadata
An NFS version 4.2 client retrieves IMA metadata by retrieving the An NFS version 4.2 client retrieves IMA metadata by retrieving the
FATTR4_IMA attribute via an NFS GETATTR operation, specifying the FATTR4_IMA attribute via an NFS GETATTR operation, specifying the
file handle of the object associated with the metadata to be file handle of the object associated with the metadata to be
retrieved. retrieved.
The IMA subsystem typically manages its own cache of this metadata to The IMA subsystem typically manages its own cache of this metadata to
maintain reasonable performance. The NFS client implementation MUST maintain reasonable performance. The NFS client implementation MUST
skipping to change at page 11, line 23 skipping to change at page 12, line 36
5. Deployment Examples 5. Deployment Examples
5.1. Terminology 5.1. Terminology
Because the protocol extension described in this document is Because the protocol extension described in this document is
OPTIONAL, clients and servers that support it will necessarily OPTIONAL, clients and servers that support it will necessarily
interact with clients and servers that do not support it. To aid the interact with clients and servers that do not support it. To aid the
discussion in this section, we define the following terms: discussion in this section, we define the following terms:
Integrity Assessor: A security module separate from the file system Appraiser: A security module separate from the storage system that
that appraises file content based on a policy and IMA measurement appraises file content based on a policy and IMA measurement
results. results.
Participating Client: An NFS version 4.2 client that employs a Participating Client: An NFS version 4.2 client that employs an
integrity assessor, supports the OPTIONAL extension described in appraiser, supports the OPTIONAL extension described in this
this document, and indicates this support to servers using the document, and indicates this support to NFS servers using the
handshake described in Section 4.2. handshake described in Section 4.2.
Non-participating Client: An NFS client that does not support the Legacy Client: Any NFS client that does not support the OPTIONAL
OPTIONAL extension described in this document. extension described in this document.
Participating Server: An NFS version 4.2 server that supports the Participating Server: An NFS version 4.2 server that supports the
OPTIONAL extension described in this document, indicates this OPTIONAL extension described in this document, indicates this
support to clients using the handshake described in Section 4.2, support to clients using the handshake described in Section 4.2,
and its shared file systems can store IMA metadata. A and its shared file systems can store IMA metadata. A
participating server is not required to implement an integrity participating server is not required to implement an appraiser.
assessor.
Non-participating Server: An NFS server that does not support the Legacy Server: Any NFS server that does not support the OPTIONAL
OPTIONAL extension described in this document. extension described in this document.
In addition, there are intermediate modes of operation on In addition, there are intermediate modes of operation on
participating peers: participating peers:
Full-function Client: A participating client that can modify IMA Full-function Client: A participating client that can modify IMA
metadata via NFS. metadata via NFS.
Fetch-only Client: A participating client that does not support Fetch-only Client: A participating client that does not support
modifying IMA metadata on a participating server. modifying IMA metadata on a participating server.
Full-function Server: A participating server that has a local user Full-function Server: A participating server that has a local user
execution environment and supports updating IMA metadata that execution environment and supports updating IMA metadata that
resides on local shared file systems. resides on shared local file systems.
Store-only Server: A participating server where there is only remote Store-only Server: A participating server where there is only remote
access to file content and IMA metadata. access to file content and IMA metadata.
Lastly, we provide the following possible simple appraisal policies Lastly, we provide the following possible simple appraisal policies
that might be applied by an integrity assessor: that might be applied by an appraiser:
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
IMA metadata or if the extant IMA metadata fails to verify the IMA metadata or if the extant IMA metadata fails to verify the
file content. Otherwise access to the file's content is not file content. Otherwise access to the file's content 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 IMA metadata or when extant IMA reported when a file has no IMA metadata or when extant IMA
metadata fails to verify the file's content. metadata fails to verify the file's content.
Disabled: Access to file content is never prevented and IMA metadata Disabled: IMA metadata is ignored and access to file content is
is ignored. never prevented.
5.2. Instantiating IMA Metadata 5.2. Instantiating IMA Metadata
Once a file is written and closed, a specialized tool generates and Once a file is written and closed, a specialized tool generates and
signs the IMA metadata and then writes it to the file system. The signs the IMA metadata and then writes it to the file system. The
tool can be used on a full-function client to sign files on a tool can be used on a full-function client to sign files on a
participating server. Or, the tool can be used on a full-function participating server. Or, the tool can be used on a full-function
server to sign local files. The IMA metadata is then visible to server to sign local files. The IMA metadata is then visible to
participating clients and local users on the server (if there are participating clients and local users on the server (if there are
any). any). Or, an enhanced version of cpio or rsync might copy the
metadata into place as part of an installation procedure.
Typically, once IMA metadata is associated with a file, the file's Typically, once IMA metadata is associated with a file, the file's
content is essentially immutable, even if the file's permissions content is essentially immutable, even if the file's permissions
settings permit writing to it. This is because changing the content settings permit writing to it. This is because changing the content
without updating the associated IMA metadata will make the file's without updating the associated IMA metadata will make the file's
content inaccessible, depending on the appraisal policy in effect. content inaccessible, depending on the appraisal policy in effect.
Updating the file content requires generating fresh IMA metadata to
prevent subsequent IMA appraisal failures.
5.3. Interaction With Non-Participating Implementations Updating file content requires access to a signing key in order to
generate fresh IMA metadata to prevent subsequent IMA appraisal
failures. Typically a key like this will be well-protected, and thus
not available on NFS clients.
5.3. Interaction With Legacy Implementations
Given the example policies and definitions we provided earlier, the Given the example policies and definitions we provided earlier, 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, except that a participating server to a legacy client, except that a participating server is allowed
is allowed to respond with NFS4ERR_INTEGRITY to a participating to respond with NFS4ERR_INTEGRITY to a participating client.
client.
o A non-participating client never prevents access to file content o A legacy client never prevents access to file content on a
on a participating server, but a participating server that has a participating server, but a participating server that has a local
local integrity assessor may prevent access to a non-participating appraiser may prevent access of a corrupted file to a legacy
client. client.
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 legacy server.
An integrity assessor on a participating NFS version 4.2 peer needs An appraiser on a participating NFS version 4.2 peer needs to be
to be prepared to deal gracefully with IMA metadata it does not prepared to deal gracefully with IMA metadata it does not recognize
recognize or cannot parse. Its policy may treat this case as a or cannot parse. Its policy may treat this case as an appraisal
appraisal failure. failure.
It is not required for an NFS version 4.2 server to implement an It is not required for an NFS version 4.2 server to implement an
integrity assessor. However, some servers, such as the Linux NFS appraiser. However, some servers, such as the Linux NFS server, do
server, do just that, applying local IMA policy to both local and just that, applying local IMA policy to both local and remote file
remote file accesses. accesses.
If an appraisal failure occurs during a remote access, the server
responds to a non-participating client with NFS4ERR_ACCESS or
NFS4ERR_IO. The server's local policy can decide that a
participating client sees NFS4ERR_INTEGRITY, or rather that the
server allows access to the file content and IMA metadata so that the
client's own IMA policies can be fully applied.
[ cel: Permitting remote access to files that fail a local integrity If an appraisal failure occurs during a remote access, a
check is still an open issue. ] participating server responds to a legacy client with NFS4ERR_ACCESS.
The server's local policy decides exactly what a participating client
sees: Possibilities include an NFS4ERR_INTEGRITY response (and access
to the file is denied), or access to the file content and IMA
metadata may be permitted so that the client's own IMA policies can
be applied.
6. Implementation Status 6. Implementation Status
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. RFCs.
skipping to change at page 14, line 26 skipping to change at page 15, line 43
Licensing: GPLv2 Licensing: GPLv2
Implementation experience: No comments from implementors. Implementation experience: No comments from implementors.
7. Security Considerations 7. Security Considerations
The design of the NFS extension described in this document assumes The design of the NFS extension described in this document assumes
that all IMA metadata is cryptographically signed to prevent unwanted that all IMA metadata is cryptographically signed to prevent unwanted
alteration at rest or in transit. alteration at rest or in transit.
When IMA metadata for a file exists and the end host has an IMA When IMA metadata for a file exists and the end host has an active
assessor, the content of a file is protected from creation to use. appraiser, the content of a file is protected from creation to use.
Receivers can reliably detect unintentional or malicious alteration Receivers can reliably detect unintentional or malicious alteration
of file content by verifying its content using the file's IMA of file content by verifying its content using the file's IMA
metadata. Additional protection of file content while at rest or in metadata. Additional protection of file content while at rest or in
transit on an 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 IMA metadata that is cryptographically malicious alteration of IMA metadata that is cryptographically
signed, simply by verifying its signature. Additional protection of signed, simply by verifying its signature. Additional protection of
signed metadata while at rest or in transit on an untrusted network signed metadata while at rest or in transit on an untrusted network
is unnecessary. is unnecessary.
 End of changes. 32 change blocks. 
92 lines changed or deleted 162 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/