idnits 2.17.1 draft-ietf-nfsv4-integrity-measurement-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 30, 2019) is 1669 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 778 ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 C. Lever 3 Internet-Draft Oracle 4 Intended status: Standards Track September 30, 2019 5 Expires: April 2, 2020 7 Integrity Measurement for Network File System version 4 8 draft-ietf-nfsv4-integrity-measurement-07 10 Abstract 12 This document specifies an OPTIONAL extension to NFS version 4 minor 13 version 2 that enables Linux Integrity Measurement Architecture 14 metadata (IMA) to be conveyed between NFS version 4.2 servers and 15 clients. Integrity measurement authenticates the creator of a file's 16 content and helps guarantee the content's integrity end-to-end from 17 creation to use. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 2, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. The Linux Integrity Measurement Architecture . . . . . . 3 55 1.1.1. IMA Metadata . . . . . . . . . . . . . . . . . . . . 4 56 1.1.2. Creating and Verifying IMA Metadata . . . . . . . . . 4 57 1.1.3. Distributing and Protecting Keying Material . . . . . 5 58 1.1.4. Using IMA to Protect NFS Files . . . . . . . . . . . 5 59 1.2. An Illustrative Use Case . . . . . . . . . . . . . . . . 5 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 61 3. Protocol Extension Considerations . . . . . . . . . . . . . . 6 62 3.1. XDR Extraction . . . . . . . . . . . . . . . . . . . . . 7 63 4. Managing IMA Metadata on NFS Files . . . . . . . . . . . . . 7 64 4.1. XDR Definition . . . . . . . . . . . . . . . . . . . . . 7 65 4.1.1. NFS4ERR_INTEGRITY (Error Code YYYYY) . . . . . . . . 8 66 4.2. Detecting support for IMA Metadata . . . . . . . . . . . 8 67 4.2.1. Reporting Server-Side IMA Appraisal Failures . . . . 9 68 4.3. Storing IMA Metadata . . . . . . . . . . . . . . . . . . 9 69 4.3.1. Sending IMA Metadata When Creating a New Object . . . 10 70 4.3.2. Authorizing Updates to IMA Metadata . . . . . . . . . 10 71 4.4. Retrieving IMA Metadata . . . . . . . . . . . . . . . . . 11 72 4.5. Using NFS Attribute Fencing (VERIFY/NVERIFY) . . . . . . 11 73 5. Deployment Examples . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.2. Instantiating IMA Metadata . . . . . . . . . . . . . . . 13 76 5.3. Interaction With Legacy Implementations . . . . . . . . . 14 77 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 78 6.1. Linux NFS server and client . . . . . . . . . . . . . . . 15 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 83 9.2. Informative References . . . . . . . . . . . . . . . . . 17 84 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 The security of software distribution systems is complex and 91 challenging, especially as software distribution has become 92 increasingly decentralized. An end administrator needs to trust that 93 she is running executables just as they are supplied by a software 94 vendor; in other words, that they have not been modified by malicious 95 actors, contracted system administration services, or broken hardware 96 or software. Software vendors want a guarantee that customer- 97 installed executables that fall under support contracts have 98 similarly not been modified. 100 There already exist mechanisms that protect file data during certain 101 portions of a file's life cycle: 103 o Whole file system checksumming can verify so-called Golden Master 104 installation media before it is used to install the software it 105 contains. 107 o File or block integrity mechanisms can protect data at rest on 108 storage servers. 110 o For a distributed file system such as NFS, transport layer 111 security or a GSS integrity service (as described in [RFC7861]) 112 can protect data while it traverses a network between a storage 113 server and a client. 115 A more extensive mechanism is needed to guarantee that no 116 modification of a particular file has occurred since it was created, 117 perhaps even after several generations of copies have been made of 118 the file's content. 120 1.1. The Linux Integrity Measurement Architecture 122 The Linux Integrity Measurement Architecture (IMA) [SAILER] provides 123 assurance that the content of a file is unaltered and authentic to 124 what was originally written to that file. The goal is to detect when 125 an attacker, unintentional platform behavior, or local tinkering has 126 modified the content of a file, either in transit or at rest. 128 This is done by separately storing metadata about a file's content 129 and then using that metadata to verify the content before it is used. 130 Verification of the content is entirely independent of the file 131 system. File systems, both local and remote, act simply as storage 132 for both the content and the metadata, both of which are opaque to 133 the storage subsystem. 135 An informative description of this mechanism is presented in the 136 following subsections to provide context for understanding the NFS 137 protocol extension described later in this document. As the file 138 system does not interpret IMA metadata, this description is not 139 necessary to implement the extension. 141 1.1.1. IMA Metadata 143 First, it is important to understand the distinction between a 144 checksum, a hash, and a cryptographically-signed hash. 146 o A checksum, or parity, is designed to detect and possibly correct 147 one or two bit errors in a fixed amount of content. 149 o A hash's purpose is to detect both accidental and malicious 150 alterations. Typically a hash is a small fixed size, but can be 151 computed over a very large amount of content. 153 o A cryptographically-signed hash is the basis for a digital 154 signature. The signatory of a cryptographically-signed hash gives 155 a guarantee that the hash, and therefore the hashed content, has 156 not been changed, since the hash was signed. 158 A cryptographically-signed hash stored separately from a file's 159 content therefore serves as a strong check of file content integrity 160 and authenticates the identity of the provider of the file's content. 161 The signer is verified at time of content use via a web of trust 162 commonly provided by PKI or x.509 certificates [RFC4158]. 164 The hash is typically computed using either the SHA-1 or SHA-256 165 algorithm and is stored as an HMAC [RFC2104]. For the purposes of 166 this document, the current document refers to this blob as "IMA 167 metadata". 169 The precise format of this metadata is determined by policies set by 170 the local security administrator; the metadata and its format are 171 opaque to the mechanisms that store or transport it (i.e., file 172 systems). The particulars of the PKI and the hash algorithm are set 173 by local policy, which is agreed upon out-of-band and recognized by 174 all participating IMA subsystems. 176 1.1.2. Creating and Verifying IMA Metadata 178 In a typical deployment, an authority (such as a software vendor) 179 computes the hash of a file after its content has been finalized. 180 The hash is then signed and attached to the file. A web of trust 181 typically links the signer to the users of the file's content (such 182 as customers of the software vendor). 184 Directly before file content is to be used, a security module locally 185 re-computes the hash of the file content and stores it in a cache. 186 This step is known as "measurement". 188 The next step is referred to as "appraisal". The security module 189 then reads the associated IMA metadata and validates its signature. 190 If the signature is invalid or the locally computed hash does not 191 match the stored hash, the security module applies an appraisal 192 policy. The file may be flagged in an audit log or access to the 193 file may be denied. 195 Underlying file and storage systems play no part in measurement or 196 appraisal. They act only as a conduit by which file content and IMA 197 metadata move between at-rest storage and the security module on the 198 host where that content is to be used. Both IMA metadata and file 199 content are opaque to storage subsystems. 201 1.1.3. Distributing and Protecting Keying Material 203 A Trusted Platform Module [1] can seal key material used to sign and 204 appraise file content. Unprotected keys are not stored in or 205 distributed via file systems. Distributing and protecting such key 206 material is outside the scope of the extension specified in this 207 document. 209 1.1.4. Using IMA to Protect NFS Files 211 The protocol extension in this document enables the storage and use 212 of IMA metadata so that measurement and appraisal can occur at point- 213 of-use on NFS client and server hosts. This mechanism is similar to 214 NFSv4 Security Labels (specified in [RFC7862] et al). The purpose of 215 the mechanism defined in the current document is to store security- 216 related file metadata that is not interpreted by the file system 217 itself. 219 1.2. An Illustrative Use Case 221 To help the reader grasp how IMA on NFS might be used in practice, 222 this section contains a decription of an IMA use case. The purpose 223 of using IMA here is to provide a guarantee that a set of users that 224 are executing a commercial software product are indeed using the same 225 binary executable and libraries that were developed and tested by the 226 product's vendor. 228 To publish a software product, a vendor might do the following: 230 1. The vendor generates a key pair and publishes the public key. 232 2. The vendor finalizes a version of its software product. 234 3. The vendor generates a hash of each file in the product's 235 distribution manifest, and signs each hash with its private key. 237 4. The vendor publishes the product's files and the signed hashes. 239 To install and use the vendor's product, a customer might do the 240 following: 242 1. The customer installs the files and the signed hashes in a local 243 filesystem. 245 2. When a user executes one of the files, a local security module 246 reads the file from disk and computes a hash of its content. 247 This is the measurement step, which happens when each file is 248 loaded into the system's page cache. 250 3. The security module uses the vendor's public key to verify the 251 signature of the file's stored hash, and confirms that the 252 locally computed hash matches the stored hash. This is the 253 appraisal step, which happens when each file is about to be 254 executed. 256 4. If the locally computed hash is verified, the security module 257 allows the operating system to execute the program. If not, then 258 the program fails to execute and an integrity error is logged. 260 The purpose of the NFS extension specified in the current document is 261 to enable the signed hashes in the above example to be stored by an 262 NFS server and retrieved by NFS clients. Each NFS client could then 263 verify that neither the NFS server nor an active network agent had 264 altered file content before it was used on the NFS client. 266 2. Requirements Language 268 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 269 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 270 "OPTIONAL" in this document are to be interpreted as described in BCP 271 14 [RFC2119] [RFC8174] when, and only when, they appear in all 272 capitals, as shown here. 274 3. Protocol Extension Considerations 276 This document specifies an OPTIONAL extension to NFS version 4 minor 277 version 2 [RFC7862], hereafter referred to as NFS version 4.2. NFS 278 version 4.2 servers and clients implemented without knowledge of this 279 extension will continue to interoperate with NFS version 4.2 clients 280 and servers that are aware of the extension, whether or not they 281 support it. 283 Because [RFC7862] does not define NFS version 4.2 as non-extensible, 284 [RFC8178] treats it as an extensible minor version. Therefore this 285 Standards Track RFC extends NFS version 4.2 but does not update 286 [RFC7862] or [RFC7863]. 288 3.1. XDR Extraction 290 Section 4.1 contains a description of an extension to the NFS version 291 4.2 protocol, expressed in the External Data Representation (XDR) 292 language [RFC4506]. This description is provided in a way that makes 293 it simple to extract into ready-to-compile form. The reader can 294 apply the following sed script to this document to produce a machine- 295 readable XDR description of the extension. 297 299 sed -n -e 's:^ */// ::p' -e 's:^ *///$::p' 301 303 That is, if this document is in a file called "ima-extension.txt" 304 then the reader can do the following to extract an XDR description 305 file: 307 309 sed -n -e 's:^ */// ::p' -e 's:^ *///$::p' 310 < ima-extension.txt > ima.x 312 314 Once that extraction is done, these added lines need to be inserted 315 into an appropriate base XDR of the generated XDR from [RFC7863] 316 together with XDR from any additional extensions to be recognized by 317 the implementation. This will result in a ready-to-compile XDR file. 319 4. Managing IMA Metadata on NFS Files 321 4.1. XDR Definition 323 This section defines a new data type to encapsulate and a new 324 OPTIONAL attribute to access and update IMA metadata associated with 325 a particular file. 327 To enable a single IMA metadata payload to be retrieved or updated 328 via a single RPC, and to constrain the transport resources required 329 for the operations defined in this section, the length of IMA 330 metadata MUST NOT exceed 4096 bytes in length. 332 When an NFS version 4.2 server does not recognize, or does recognize 333 but does not support, this new attribute, the server responds in 334 accordance with the requirements specified in Section 4.3 of 335 [RFC8178]. 337 339 /// /* 340 /// * Copyright (c) 2019 IETF Trust and the person identified 341 /// * as author of the code. All rights reserved. 342 /// * 343 /// * The author of the code is: C. Lever 344 /// */ 345 /// 346 /// %/* 347 /// % * New For Integrity Measurement support 348 /// % */ 349 /// opaque ima_data4<4096>; 350 /// 351 /// const FATTR4_IMA = XXX; /* to be assigned */ 352 /// 353 /// %/* 354 /// % *New value added to enum nfsstat4 355 /// % */ 356 /// const NFS4ERR_INTEGRITY = YYYYY; /* to be assigned */ 358 360 4.1.1. NFS4ERR_INTEGRITY (Error Code YYYYY) 362 The server rejected this request because a data or metadata integrity 363 check failed during its execution. 365 4.2. Detecting support for IMA Metadata 367 An NFS version 4.2 client discovers support for IMA metadata on an 368 NFS version 4.2 server by sending an NFS GETATTR operation that 369 specifies the FATTR4_SUPPORTED_ATTRS attribute and the FATTR4_IMA 370 attribute. When a server supports IMA metadata, it sets the 371 FATTR4_IMA attribute bit in the NFS GETATTR bitmask returned in the 372 reply. Otherwise that bit is clear. 374 An NFS version 4.2 server MUST NOT return NFS4ERR_INTEGRITY to a 375 client unless that client has queried the server for IMA metadata 376 support using the above mechanism. The server identifies clients 377 using their client_id4 for this purpose. 379 4.2.1. Reporting Server-Side IMA Appraisal Failures 381 An NFS server that has rigorous integrity checking must somehow 382 report integrity-related failures to clients. Until now, a server 383 implementer chose amongst status codes that were available in the 384 base NFS version 4.2 protocol, typically NFS4ERR_IO or 385 NFS4ERR_ACCESS, even though these code points have generic meanings 386 that do not necessarily imply an integrity-related failure. 388 Once the above FATTR4_SUPPORTED_ATTRS handshake is done, the server 389 has determined that a client can properly recognize the 390 NFS4ERR_INTEGRITY status code. In instances where an NFS request 391 fails due to an integrity-related issue, and the server has 392 determined that the client recognizes the NFS4ERR_INTEGRITY status 393 code, the server MAY return NFS4ERR_INTEGRITY for the following 394 operations: ACCESS, COMMIT, CREATE, GETATTR, GETDEVICELIST, LINK, 395 LOOKUP, LOOKUPP, NVERIFY, OPEN, OPENATTR, READ, READDIR, READLINK, 396 REMOVE, RENAME, SETATTR, VERIFY, WRITE. The server MUST NOT return 397 NFS4ERR_INTEGRITY for any other operation. 399 The NFS4ERR_INTEGRITY status code is useful to inform the client (or 400 the end user, depending on the client implementation) that access to 401 the file's content was not blocked because of a permissions setting 402 but rather because an integrity check failed. This distinction can 403 guide the user or client towards a recovery action that is 404 appropriate. 406 4.3. Storing IMA Metadata 408 An NFS version 4.2 client stores IMA metadata by sending an NFS 409 SETATTR operation that specifies the FATTR4_IMA attribute and targets 410 the file system object associated with the metadata to be stored. 411 This attribute completely replaces any previous FATTR4_IMA attribute 412 associated with that object. Modifying an object in any other way 413 MUST NOT alter or remove FATTR4_IMA attributes. 415 To remove IMA metadata from an object, the client sends a FATTR4_IMA 416 attribute whose length is zero. 418 When an NFS SETATTR is presented to an NFS version 4.2 server with a 419 credential that is not authorized to replace a FATTR4_IMA attribute, 420 the server MUST respond with NFS4ERR_ACCESS. 422 When an NFS SETATTR is presented to an NFS version 4.2 server with an 423 ima_data4 field whose length is larger than 4096 bytes, the server 424 MUST respond with NFS4ERR_INVAL. 426 When an NFS SETATTR is presented to an NFS version 4.2 server and the 427 target object resides in a file system which supports FATTR4_IMA but 428 the object itself does not support the FATTR4_IMA attribute, the 429 server MUST respond with NFS4ERR_WRONGTYPE. For example, if the 430 server's file system supports associating IMA metadata with regular 431 files but not with sockets or FIFOs, then the result of an attempt to 432 associate IMA metadata with a FIFO will be NFS4ERR_WRONGTYPE. 434 When an NFS SETATTR is presented to an NFS version 4.2 server but the 435 target object resides in a file system which does not support the 436 FATTR4_IMA attribute, the server MUST respond with 437 NFS4ERR_ATTRNOTSUPP. 439 When a client presents an NFS SETATTR that modifies FATTR4_IMA along 440 with other attributes and the server responds with an error, the 441 client can retry setting each attribute separately to sort out which 442 attribute is causing the server to reject the NFS SETATTR operation. 444 A detailed description of the NFS SETATTR operation can be found in 445 Section 18.30 of [RFC5661]. 447 4.3.1. Sending IMA Metadata When Creating a New Object 449 An alternate way to set an attribute is to provide the attribute 450 during an NFS OPEN(CREATE) operation. Upon creation, an object has 451 no content to protect. If a client presents an FATTR4_IMA attribute 452 to an NFS version 4.2 server during NFS OPEN(CREATE), the server MUST 453 respond with NFS4ERR_INVAL. 455 4.3.2. Authorizing Updates to IMA Metadata 457 An NFS server permits a user to replace a file's IMA metadata 458 whenever that user is permitted to modify that file's byte content. 459 This is consistent with similar mechanisms already used throughout 460 the NFS version 4 protocol; for instance, setting an ACL. If an NFS 461 server determines that a user requesting a SETATTR with the 462 FATTR4_IMA attribute is not authorized to update the IMA metadata, 463 the SETATTR operation MUST return NFS4ERR_ACCESS. 465 If an NFS server implementation does not support modification of IMA 466 metadata via NFS, the server MUST return NFS4ERR_INVAL to a SETATTR 467 request with the FATTR4_IMA attribute, as required by Section 5.5 of 468 [RFC5661]. 470 4.4. Retrieving IMA Metadata 472 An NFS version 4.2 client retrieves IMA metadata by retrieving the 473 FATTR4_IMA attribute via an NFS GETATTR operation, specifying the 474 file handle of the object associated with the metadata to be 475 retrieved. 477 The IMA subsystem typically manages its own cache of this metadata to 478 maintain reasonable performance. The NFS client implementation MUST 479 always pass retrieval requests for this metadata to the server. This 480 metadata MUST NOT be cached by the NFS client. 482 When an NFS GETATTR is presented to an NFS version 4.2 server and the 483 target object resides in a file system which supports the FATTR4_IMA 484 attribute but the object does not support the FATTR4_IMA attribute, 485 the server MUST respond with NFS4ERR_WRONGTYPE. For example, if the 486 server's file system supports associating IMA metadata with regular 487 files but not named attributes, then the result of an attempt to 488 retrieve IMA metadata on a named attribute will be NFS4ERR_WRONGTYPE. 490 When an NFS GETATTR is presented to an NFS version 4.2 server but the 491 target object resides in a file system which does not support 492 FATTR4_IMA, this does not result in an error and the FATTR4_IMA 493 attribute bit is cleared in the server's response. 495 Otherwise, if the target object supports FATTR4_IMA and there is no 496 IMA metadata is available for the target object, the server returns a 497 FATTR4_IMA attribute whose length is zero. 499 When a client presents an NFS GETATTR that retrieves FATTR4_IMA along 500 with other attributes and the server responds with an error, the 501 client can retry by retrieving each attribute separately to sort out 502 which attribute is causing the server to reject the NFS GETATTR 503 operation. 505 A detailed description of the NFS GETATTR operation can be found in 506 Section 18.7 of [RFC5661]. 508 4.5. Using NFS Attribute Fencing (VERIFY/NVERIFY) 510 The NFS VERIFY and NVERIFY operations, described in Sections 18.31 511 and 18.15 of [RFC5661] respectively, permit a client to add a fence 512 in an NFS COMPOUND where, if a provided FATTR4 attribute does or does 513 not match, the server can force processing of that COMPOUND to stop. 514 The FATTR4_IMA attribute is a valid choice for these operations. 516 The server MUST use a simple byte comparison to evaluate whether the 517 client-provided FATTR4_IMA matches the FATTR4_IMA attribute 518 associated with the target object. If the server has a local IMA 519 implementation, it MAY prevent the use of the local FATTR4_IMA 520 attribute value for the purpose of this comparison (via EVM 521 protection). If the client has indicated support for IMA metadata, 522 the server MUST respond with NFS4ERR_INTEGRITY. Otherwise it MUST 523 respond with NFS4ERR_ACCESS. 525 5. Deployment Examples 527 5.1. Terminology 529 Because the protocol extension described in this document is 530 OPTIONAL, clients and servers that support it will necessarily 531 interact with clients and servers that do not support it. To aid the 532 discussion in this section, we define the following terms: 534 Appraiser: A security module separate from the storage system that 535 appraises file content based on a policy and IMA measurement 536 results. 538 Participating Client: An NFS version 4.2 client that employs an 539 appraiser, supports the OPTIONAL extension described in this 540 document, and indicates this support to NFS servers using the 541 handshake described in Section 4.2. 543 Legacy Client: Any NFS client that does not support the OPTIONAL 544 extension described in this document. 546 Participating Server: An NFS version 4.2 server that supports the 547 OPTIONAL extension described in this document, indicates this 548 support to clients using the handshake described in Section 4.2, 549 and its shared file systems can store IMA metadata. A 550 participating server is not required to implement an appraiser. 552 Legacy Server: Any NFS server that does not support the OPTIONAL 553 extension described in this document. 555 In addition, there are intermediate modes of operation on 556 participating peers: 558 Full-function Client: A participating client that can modify IMA 559 metadata via NFS. 561 Fetch-only Client: A participating client that does not support 562 modifying IMA metadata on a participating server. 564 Full-function Server: A participating server that has a local user 565 execution environment and supports updating IMA metadata that 566 resides on shared local file systems. 568 Store-only Server: A participating server where there is only remote 569 access to file content and IMA metadata. 571 Lastly, we provide the following possible simple appraisal policies 572 that might be applied by an appraiser: 574 Strict: Access is prevented to a file's content if the file has no 575 IMA metadata or if the extant IMA metadata fails to verify the 576 file content. Otherwise access to the file's content is not 577 prevented. 579 Audit: Access to a file's content is never prevented. Warnings are 580 reported when a file has no IMA metadata or when extant IMA 581 metadata fails to verify the file's content. 583 Disabled: IMA metadata is ignored and access to file content is 584 never prevented. 586 5.2. Instantiating IMA Metadata 588 Once a file is written and closed, a specialized tool generates and 589 signs the IMA metadata and then writes it to the file system. The 590 tool can be used on a full-function client to sign files on a 591 participating server. Or, the tool can be used on a full-function 592 server to sign local files. The IMA metadata is then visible to 593 participating clients and local users on the server (if there are 594 any). Or, an enhanced version of cpio or rsync might copy the 595 metadata into place as part of an installation procedure. 597 Typically, once IMA metadata is associated with a file, the file's 598 content is essentially immutable, even if the file's permissions 599 settings permit writing to it. This is because changing the content 600 without updating the associated IMA metadata will make the file's 601 content inaccessible, depending on the appraisal policy in effect. 603 Updating file content requires access to a signing key in order to 604 generate fresh IMA metadata to prevent subsequent IMA appraisal 605 failures. Typically a key like this will be well-protected, and thus 606 not available on NFS clients. 608 5.3. Interaction With Legacy Implementations 610 Given the example policies and definitions we provided earlier, the 611 following statements are true: 613 o A participating client that uses the Disabled policy is equivalent 614 to a legacy client, except that a participating server is allowed 615 to respond with NFS4ERR_INTEGRITY to a participating client. 617 o A legacy client never prevents access to file content on a 618 participating server, but a participating server that has a local 619 appraiser may prevent access of a corrupted file to a legacy 620 client. 622 o A participating client using the Strict policy never allows access 623 to files stored on a legacy server. 625 An appraiser on a participating NFS version 4.2 peer needs to be 626 prepared to deal gracefully with IMA metadata it does not recognize 627 or cannot parse. Its policy may treat this case as an appraisal 628 failure. 630 It is not required for an NFS version 4.2 server to implement an 631 appraiser. However, some servers, such as the Linux NFS server, do 632 just that, applying local IMA policy to both local and remote file 633 accesses. 635 If an appraisal failure occurs during a remote access, a 636 participating server responds to a legacy client with NFS4ERR_ACCESS. 637 The server's local policy decides exactly what a participating client 638 sees: Possibilities include an NFS4ERR_INTEGRITY response (and access 639 to the file is denied), or access to the file content and IMA 640 metadata may be permitted so that the client's own IMA policies can 641 be applied. 643 6. Implementation Status 645 This section records the status of known implementations of the 646 protocol defined by this specification at the time of posting of this 647 Internet-Draft, and is based on a proposal described in [RFC7942]. 648 The description of implementations in this section is intended to 649 assist the IETF in its decision processes in progressing drafts to 650 RFCs. 652 Please note that the listing of any individual implementation here 653 does not imply endorsement by the IETF. Furthermore, no effort has 654 been spent to verify the information presented here that was supplied 655 by IETF contributors. This is not intended as, and must not be 656 construed to be, a catalog of available implementations or their 657 features. Readers are advised to note that other implementations may 658 exist. 660 6.1. Linux NFS server and client 662 Organization: The Linux Foundation 664 URL: https://www.kernel.org 666 Maturity: Prototype software based on early versions of this 667 document. 669 Coverage: The bulk of this specification is implemented. 671 Licensing: GPLv2 673 Implementation experience: No comments from implementors. 675 7. Security Considerations 677 The design of the NFS extension described in this document assumes 678 that all IMA metadata is cryptographically signed to prevent unwanted 679 alteration at rest or in transit. 681 When IMA metadata for a file exists and the end host has an active 682 appraiser, the content of a file is protected from creation to use. 683 Receivers can reliably detect unintentional or malicious alteration 684 of file content by verifying its content using the file's IMA 685 metadata. Additional protection of file content while at rest or in 686 transit on an untrusted network is unnecessary. 688 Likewise, receivers can also reliably detect unintentional or 689 malicious alteration of IMA metadata that is cryptographically 690 signed, simply by verifying its signature. Additional protection of 691 signed metadata while at rest or in transit on an untrusted network 692 is unnecessary. 694 Like other mechanisms that protect data integrity during transit, a 695 malicious agent or a network malfunction can create a denial-of- 696 service condition by repeatedly triggering integrity verification 697 failures on NFS version 4.2 clients. 699 To prevent a malicious denial-of-service attempt by altering IMA 700 metadata at rest, an NFS version 4.2 server can enforce a suitable 701 level of privilege before authorizing a local or remote agent to 702 alter this information. See Section 4.3.2 for more detail. 704 8. IANA Considerations 706 This document has no IANA actions. 708 9. References 710 9.1. Normative References 712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels", BCP 14, RFC 2119, 714 DOI 10.17487/RFC2119, March 1997, 715 . 717 [RFC4506] Eisler, M., Ed., "XDR: External Data Representation 718 Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 719 2006, . 721 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 722 "Network File System (NFS) Version 4 Minor Version 1 723 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 724 . 726 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 727 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 728 November 2016, . 730 [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor 731 Version 2 External Data Representation Standard (XDR) 732 Description", RFC 7863, DOI 10.17487/RFC7863, November 733 2016, . 735 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 736 Code: The Implementation Status Section", BCP 205, 737 RFC 7942, DOI 10.17487/RFC7942, July 2016, 738 . 740 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 741 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 742 May 2017, . 744 [RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor 745 Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, 746 . 748 9.2. Informative References 750 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 751 Hashing for Message Authentication", RFC 2104, 752 DOI 10.17487/RFC2104, February 1997, 753 . 755 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 756 Nicholas, "Internet X.509 Public Key Infrastructure: 757 Certification Path Building", RFC 4158, 758 DOI 10.17487/RFC4158, September 2005, 759 . 761 [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 762 "Network File System (NFS) Version 4 Minor Version 1 763 External Data Representation Standard (XDR) Description", 764 RFC 5662, DOI 10.17487/RFC5662, January 2010, 765 . 767 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 768 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 769 November 2016, . 771 [SAILER] Sailer, R., Zhang, X., Jaeger, T., and L. van Doorn, 772 "Design and Implementation of a TCG-based Integrity 773 Measurement Architecture", Proceedings of the 13th USENIX 774 Security Symposium, August 2004. 776 9.3. URIs 778 [1] https://trustedcomputinggroup.org/wp-content/uploads/Trusted- 779 Platform-Module-Summary_04292008.pdf 781 Acknowledgments 783 The author wishes to thank Mimi Zohar and James Morris for their 784 early review of the concepts in this document, Wim Coekaerts for his 785 encouragement of this work, and Dave Noveck for his work on NFS 786 version 4 extensibility. 788 The author wishes to acknowledge review comments from Dave Noveck, 789 Craig Everhart, and Bruce Fields which helped to make this a better 790 document. 792 The XDR extraction conventions were first described by the authors of 793 the NFS version 4.1 XDR specification [RFC5662]. Herbert van den 794 Bergh suggested the replacement sed script used in this document. 796 Special thanks go to Transport Area Director Magnus Westerlund, NFSV4 797 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 798 Working Group Secretary Thomas Haynes for their support. 800 Author's Address 802 Charles Lever 803 Oracle Corporation 804 United States of America 806 Email: chuck.lever@oracle.com