--- 1/draft-ietf-nfsv4-integrity-measurement-03.txt 2019-03-27 08:13:15.181802043 -0700 +++ 2/draft-ietf-nfsv4-integrity-measurement-04.txt 2019-03-27 08:13:15.209802773 -0700 @@ -1,83 +1,86 @@ Network File System Version 4 C. Lever Internet-Draft Oracle -Intended status: Standards Track November 7, 2018 -Expires: May 11, 2019 +Intended status: Standards Track March 27, 2019 +Expires: September 28, 2019 - File Content Provenance for Network File System version 4 - draft-ietf-nfsv4-integrity-measurement-03 + Integrity Measurement for Network File System version 4 + draft-ietf-nfsv4-integrity-measurement-04 Abstract This document specifies an OPTIONAL extension to NFS version 4 minor - version 2 that enables file provenance information to be conveyed - between NFS version 4.2 servers and clients. File provenance - information authenticates the creator of a file's content and helps - guarantee the content's integrity from creation to use. + version 2 that enables Linux Integrity Measurement Architecture + metadata (IMA) to be conveyed between NFS version 4.2 servers and + clients. Integrity measurement authenticates the creator of a file's + content and helps guarantee the content's integrity end-to-end from + creation to use. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 11, 2019. + This Internet-Draft will expire on September 28, 2019. 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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1. Architecture and Terminology . . . . . . . . . . . . . . 3 + 1.1. The Linux Integrity Measurement Architecture . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Extension Considerations . . . . . . . . . . . . . . 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.2. Storing File Provenance Information . . . . . . . . . . . 6 - 4.3. Retrieving File Provenance Information . . . . . . . . . 7 - 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 - 5.2. Instantiating File Provenance Information . . . . . . . . 8 - 5.2.1. Authorizing Updates to File Provenance Information . 9 - 5.3. Interaction With Non-Participating Implementations . . . 9 - 5.4. Performance Cost of Provenance Assessment . . . . . . . . 10 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 - 8.2. Informative References . . . . . . . . . . . . . . . . . 14 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.2. Storing IMA Metadata . . . . . . . . . . . . . . . . . . 6 + 4.3. Retrieving IMA Metadata . . . . . . . . . . . . . . . . . 6 + 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.2. Instantiating IMA Metadata . . . . . . . . . . . . . . . 8 + 5.2.1. Authorizing Updates to IMA Metadata . . . . . . . . . 8 + 5.3. Interaction With Non-Participating Implementations . . . 8 + 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 + 6.1. Linux NFS server and client . . . . . . . . . . . . . . . 10 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 9.2. Informative References . . . . . . . . . . . . . . . . . 12 + 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The security of software distribution systems is complex and challenging, especially as software distribution has become increasingly decentralized. An end administrator needs to trust that she is running executables just as they are supplied by a software vendor; in other words, that they have not been modified by malicious actors, contracted system administration services, or broken hardware or software. Software vendors want a guarantee that customer- @@ -97,77 +100,70 @@ o For a distributed file system such as NFS, transport layer security or a GSS integrity service (as described in [RFC7861]) can protect data while it traverses a network between a storage server and a client. A more extensive mechanism is needed to guarantee that no modification of a particular file has occurred since it was created, perhaps even after several generations of copies have been made of the file's content. - This guarantee can be accomplished by separately preserving a keyed - hash, such as an HMAC [RFC2104], of a file's 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 +1.1. The Linux Integrity Measurement Architecture - A keyed hash authenticates the identity of the last modifier of a - file's content and serves as a strong check of the content's - integrity. For the purposes of this document, we refer to this - metadata using the generic term "file provenance information". + The Linux Integrity Measurement Architecture (IMA) [1] provides + assurance that the content of files is unaltered and authentic to + what was originally written to those files. The primary goal is to + 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 - authority", and then associated with each file using special tools. + A keyed hash (e.g., an HMAC [RFC2104]) authenticates the identity of + the last modifier of a file's content and serves as a strong check of + the content's integrity. For the purposes of this document, we 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 - 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". + Each hash 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. A security module + separate from the file system specifies the format of the metadata, + measures file content, and enforces a policy for determining when + 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 - use. The file and storage system play no part in provenance - assessment decisions. NFS acts only 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. + Appraisal is typically performed at the point of content use. The + file and storage system play no part in measurement or appraisal. + The file system acts only as a conduit by which IMA metadata and file + content move between storage on an NFS server and the integrity + assessor module on the host where that content is to be used. - 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 so that provenance - assessment can occur at point-of-use on NFS clients. The extension - does not provide a full assessment mechanism. + NFS peers accessing a set of shared files must all agree on the IMA + metadata format. The format is specified by the integrity assessor + module and is therefore not described in this document. The protocol + extension in this document enables the storage and use of IMA + metadata so that measurement and appraisal can occur at point-of-use + 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 - sign and verify file content. Distributing and protecting such key - material is outside the scope of the OPTIONAL extension specified in - this document. + A Trusted Platform Module [2] can seal key material used to sign and + verify file content. Distributing and protecting such key material + is outside the scope of the extension specified in this document. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119] [RFC8174] - when, and only when, they appear in all capitals, as shown here. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. 3. Protocol Extension Considerations This document specifies an OPTIONAL extension to NFS version 4 minor version 2 [RFC7862], hereafter referred to as NFS version 4.2. NFS version 4.2 servers and clients implemented without knowledge of this extension will continue to interoperate with NFS version 4.2 clients and servers that are aware of the extension, whether or not they support it. @@ -183,403 +179,317 @@ language [RFC4506]. This description is provided in a way that makes it simple to extract into ready-to-compile form. The reader can apply the following sed script to this document to produce a machine- readable XDR description of the extension. sed -n -e 's:^ */// ::p' -e 's:^ *///$::p' - That is, if this document is in a file called "provenance- - extension.txt" then the reader can do the following to extract an XDR - description file: + + That is, if this document is in a file called "ima-extension.txt" + then the reader can do the following to extract an XDR description + file: sed -n -e 's:^ */// ::p' -e 's:^ *///$::p' - < provenance-extension.txt > ima.x + < ima-extension.txt > ima.x Once that extraction is done, these added lines need to be inserted into an appropriate base XDR of the generated XDR from [RFC7863] together with XDR from any additional extensions to be recognized by the implementation. This will result in a ready-to-compile XDR file. -4. Managing File Provenance Information on NFS Files +4. Managing IMA Metadata on NFS Files 4.1. XDR Definition This section defines a new data type to encapsulate and a new - OPTIONAL attribute to access and update file provenance information - associated with a particular file. + OPTIONAL attribute to access and update IMA metadata associated with + a particular file. - To enable a single file provenance information payload to be - retrieved or updated via a single RPC, and to constrain the transport - resources required for the operations defined in this section, the - length of file provenance information MUST NOT exceed 4096 bytes in - length. + To enable a single IMA metadata payload to be retrieved or updated + via a single RPC, and to constrain the transport resources required + for the operations defined in this section, the length of IMA + metadata MUST NOT exceed 4096 bytes in length. When an NFS version 4.2 server does not recognize, or does recognize but does not support, this new attribute, the server responds in accordance with the requirements specified in Section 4.3 of [RFC8178]. /// /* - /// * 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. /// * /// * 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 */ -4.2. Storing File Provenance Information +4.2. Storing IMA Metadata - An NFS version 4.2 client stores file provenance information by - sending a SETATTR operation that specifies the FATTR4_FILE_PROVENANCE - attribute and an fpv_type, targeting the file object associated with - the file provenance information to be stored. This attribute - completely replaces any previous one with the same fpv_type field. + An NFS version 4.2 client stores IMA metadata by sending a SETATTR + operation that specifies the FATTR4_LINUX_IMA attribute, targeting + the file object associated with the metadata to be stored. This + attribute completely replaces any previous one. - To remove a file provenance attribute from a file, the client sends a - FATTR4_FILE_PROVENANCE attribute whose length is zero. Modifying the - file in any other way MUST NOT alter or remove FATTR4_FILE_PROVENANCE + To remove IMA metadata from a file, the client sends a + FATTR4_LINUX_IMA attribute whose length is zero. Modifying the file + in any other way MUST NOT alter or remove FATTR4_LINUX_IMA attributes. 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. 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 - size specified in Table 1 for that fpv_type, the server MUST respond - with NFS4ERR_INVAL. + fattr4_linux_ima field whose length is larger than 4096 bytes, the + server MUST respond with NFS4ERR_INVAL. When a SETATTR is presented to an NFS version 4.2 server and the target object resides in a file system which supports - FATTR4_FILE_PROVENANCE but the object does not support - FATTR4_FILE_PROVENANCE attributes, the server MUST respond with + FATTR4_LINUX_IMA but the object itself does not support the + FATTR4_LINUX_IMA attribute, the server MUST respond with NFS4ERR_WRONGTYPE. 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 or does not support the format associated with - the specified fpv_type, the server MUST respond with + target object resides in a file system which does not support the + FATTR4_LINUX_IMA attribute, 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 +4.3. Retrieving IMA Metadata - An NFS version 4.2 client retrieves file provenance information by - retrieving the FATTR4_FILE_PROVENANCE attribute via a GETATTR - operation, specifying an fpv_type and the file handle of the file - object associated with the information to be retrieved. This - information may have been computed and signed previously on this - client or by some other agent. + An NFS version 4.2 client retrieves IMA metadata by retrieving the + FATTR4_LINUX_IMA attribute via a GETATTR operation, specifying the + file handle of the file object associated with the metadata to be + retrieved. This information may have been computed and signed + previously on this client or by some other agent. When a GETATTR is presented to an NFS version 4.2 server and the - target object resides in a file system which supports - FATTR4_FILE_PROVENANCE but the object does not support - FATTR4_FILE_PROVENANCE attributes, the server MUST respond with + target object resides in a file system which supports the + FATTR4_LINUX_IMA attribute but the object does not support the + FATTR4_LINUX_IMA attribute, the server MUST respond with NFS4ERR_WRONGTYPE. 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 - FATTR4_FILE_PROVENANCE or does not support the format associated with - the specified fpv_type, this does not result in an error and the - FATTR4_FILE_PROVENANCE attribute bit is clear in the server's + FATTR4_LINUX_IMA, this does not result in an error and the + FATTR4_FILE_PROVENANCE attribute bit is cleared in the server's response. - 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. + Otherwise, if the target object supports FATTR4_LINUX_IMA and there + is no IMA metadata is available for the target object, the server + returns a FATTR4_LINUX_IMA attribute whose length is zero. - Provenance assessors operate after file content has been delivered - but immediately before that content is to be used. To enable - provenance assessors on NFS clients to verify file provenance - information, NFS version 4.2 servers do not prevent access to file - content if they have a local provenance assessor and it indicates - that provenance verification has failed. + Integrity assessment occurs after file content has been delivered but + immediately before that content is to be used. To enable integrity + assessment on NFS clients to verify IMA metadata, NFS version 4.2 + servers should not prevent access to file content if they have a + local appraisal policy and it indicates that integrity verification + has failed. A detailed description of the GETATTR operation can be found in Section 18.7 of [RFC5661]. 5. Operation 5.1. Terminology 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 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 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 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 does not support the OPTIONAL extension described in this document - or its shared filesystems are not capable of storing file - provenance information. + or its shared filesystems are not capable of storing IMA metadata. 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. + updating remote IMA metadata. o A "fetch-only client" is a participating client that does not - support modifying file provenance information on a participating - server. + support modifying IMA metadata 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. + updating IMA metadata 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. + 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 - 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. + Once a file is written, IMA metadata is generated and signed by an + appropriate trust 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 IMA metadata to the shared file system. When + using a store-only server, only a full-function client can place IMA + metadata 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. + Typically, once IMA metadata 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 IMA metadata will make the content inaccessible, + depending on the appraisal policy in effect. Thus updating the file + content usually requires generating fresh IMA metadata. -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 - provenance information are done only by appropriately authorized - agents. Such agents usually include only the owner of a file and - agents with super-user privileges. + A participating server should ensure that modifications to IMA + metadata are done only by appropriately authorized agents. Such + agents usually include only agents with super-user privileges. The + 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 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): + possible simple appraisal policies that might be adopted by an + integrity assessment module: 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. + IMA metadata or if the extant IMA metadata 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. + reported when a file has no IMA metadata or when extant IMA + metadata fails to verify the file's content. - Disabled: Access to file content is never prevented and provenance - information is ignored. + Disabled: Access to file content is never prevented and IMA metadata + 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. + A integrity assessor module on an NFS version 4.2 peer needs to be + prepared to deal with IMA metadata it does not recognize or cannot + parse. Its policy may treat this case as a appraisal 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 not prevent remote access to participating clients if - local provenance assessment fails. + Note that an NFS version 4.2 server may use a integrity assessor + module 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 not prevent remote access to participating + 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 - 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. + This section records the status of known implementations of the + protocol defined by this specification at the time of posting of this + Internet-Draft, and is based on a proposal described in [RFC7942]. + The description of implementations in this section is intended to + assist the IETF in its decision processes in progressing drafts to + RFCs. - 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. + Please note that the listing of any individual implementation here + does not imply endorsement by the IETF. Furthermore, no effort has + been spent to verify the information presented here that was supplied + by IETF contributors. This is not intended as, and must not be + 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 - 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.1. Linux NFS server and client - NFS can provide an offload mechanism to mitigate some of the network - 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. + Organization: The Linux Foundation -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 - 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. + assumes that all IMA metadata is keyed or otherwise cryptographically + signed by a trust authority to prevent unwanted alteration at rest or + in transit. - When file provenance information for a file exists, the content of a - file is protected from creation to use. Receivers can reliably - detect unintentional or malicious alteration of file content by - verifying its content using file provenance information. Additional - protection of file content while at rest or in transit on an - untrusted network is unnecessary. + When IMA metadata for a file exists and the end host has adopted an + IMA policy, the content of a file is protected from creation to use. + Receivers can reliably detect unintentional or malicious alteration + of file content by verifying its content using the file's IMA + metadata. Additional protection of file content while at rest or in + transit on an untrusted network is unnecessary. Likewise, receivers can also reliably detect unintentional or - malicious alteration of file provenance information that is - cryptographically signed, simply by verifying its signature. - Additional protection of signed file provenance information while at - rest or in transit on an untrusted network is unnecessary. + malicious alteration of IMA metadata that is cryptographically + signed, simply by verifying its signature. Additional protection of + signed metadata while at rest or in transit on an untrusted network + is unnecessary. Like other mechanisms that protect data integrity during transit, A malicious agent or a network malfunction can create a denial-of- service condition by repeatedly triggering integrity verification failures on NFS version 4.2 clients. - 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 - - 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. + To prevent a malicious denial-of-service attempt by altering IMA + metadata at rest, an NFS version 4.2 server can 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. - For registration requests where a Designated Expert should be - 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. +8. IANA Considerations - A request to modify either the Description or the published file - 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. + This document requests no action from IANA. -8. References +9. References -8.1. Normative References +9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 2006, . @@ -590,82 +500,74 @@ [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, . [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description", RFC 7863, DOI 10.17487/RFC7863, November 2016, . - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for - Writing an IANA Considerations Section in RFCs", BCP 26, - RFC 8126, DOI 10.17487/RFC8126, June 2017, - . + [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running + Code: The Implementation Status Section", BCP 205, + RFC 7942, DOI 10.17487/RFC7942, July 2016, + . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, . -8.2. Informative References - - [IMA-WP] Safford, D., "An Overview of The Linux Integrity - Subsystem", . - - [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. +9.2. Informative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description", RFC 5662, DOI 10.17487/RFC5662, January 2010, . [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) Security Version 3", RFC 7861, DOI 10.17487/RFC7861, November 2016, . - [TPM-SUM] Trusted Computing Group, "Trusted Platform Module (TPM) - Summary", April 2008, . +9.3. URIs + + [1] http://downloads.sf.net/project/linux-ima/linux-ima/ + Integrity_overview.pdf + + [2] https://trustedcomputinggroup.org/wp-content/uploads/Trusted- + Platform-Module-Summary_04292008.pdf Acknowledgments The author wishes to thank Mimi Zohar and James Morris for their early review of the concepts in this document, Wim Coekaerts for his encouragement of this work, and Dave Noveck for his work on NFS version 4 extensibility. The author wishes to acknowledge review comments from Dave Noveck, Craig Everhart, and Bruce Fields which helped to make this a better - document. Benjamin Kaduk proposed the File Provenance Information - Registry. + document. The XDR extraction conventions were first described by the authors of the NFS version 4.1 XDR specification [RFC5662]. Herbert van den Bergh suggested the replacement sed script used in this document. - Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 + Special thanks go to Transport Area Director Magnus Westerlund, NFSV4 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their support. Author's Address Charles Lever Oracle Corporation - 1015 Granger Avenue - Ann Arbor, MI 48104 United States of America Email: chuck.lever@oracle.com