idnits 2.17.1 draft-ietf-nfsv4-integrity-measurement-06.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 21, 2019) is 1679 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 798 ** 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 21, 2019 5 Expires: March 24, 2020 7 Integrity Measurement for Network File System version 4 8 draft-ietf-nfsv4-integrity-measurement-06 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 March 24, 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) . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . 15 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 version 4.2 server needs to ensure that modifications to IMA 458 metadata are done only by appropriately authorized agents. Although 459 access to file content is typically controlled by ACLs and permission 460 bits, these mechanisms do not apply to IMA metadata. 462 The question of "who is authorized to modify IMA metadata" is often 463 left to the server's local IMA security policy. In addition, the 464 issue of whether to allow a particular IMA metadata update has no 465 bearing on protocol interoperability, as long as the server sticks to 466 returning NFS4ERR_ACCESS or NFS4ERR_INTEGRITY, as appropriate. Thus, 467 to enable server implementation flexibility, the current document 468 treats the following recommendations as implementation guidance 469 rather than as normative protocol requirements. 471 Possible NFS server implementations include limiting IMA metadata 472 update authority in the following ways: 474 Particular users 475 A server might allow IMA metadata updates only by UID 0 or by a 476 client's machine principal. 478 Particular clients 479 A server might allow IMA metadata updates only from specific 480 client IP addresses. 482 File owners 483 A server might allow IMA metadata updates only by the file's owner 484 or group owner. 486 No remote updates 487 A server might always return NFS4ERR_ACCESS when an NFS client 488 sends a SETATTR request that updates IMA metadata. 490 4.4. Retrieving IMA Metadata 492 An NFS version 4.2 client retrieves IMA metadata by retrieving the 493 FATTR4_IMA attribute via an NFS GETATTR operation, specifying the 494 file handle of the object associated with the metadata to be 495 retrieved. 497 The IMA subsystem typically manages its own cache of this metadata to 498 maintain reasonable performance. The NFS client implementation MUST 499 always pass retrieval requests for this metadata to the server. This 500 metadata MUST NOT be cached by the NFS client. 502 When an NFS GETATTR is presented to an NFS version 4.2 server and the 503 target object resides in a file system which supports the FATTR4_IMA 504 attribute but the object does not support the FATTR4_IMA attribute, 505 the server MUST respond with NFS4ERR_WRONGTYPE. For example, if the 506 server's file system supports associating IMA metadata with regular 507 files but not named attributes, then the result of an attempt to 508 retrieve IMA metadata on a named attribute will be NFS4ERR_WRONGTYPE. 510 When an NFS GETATTR is presented to an NFS version 4.2 server but the 511 target object resides in a file system which does not support 512 FATTR4_IMA, this does not result in an error and the FATTR4_IMA 513 attribute bit is cleared in the server's response. 515 Otherwise, if the target object supports FATTR4_IMA and there is no 516 IMA metadata is available for the target object, the server returns a 517 FATTR4_IMA attribute whose length is zero. 519 When a client presents an NFS GETATTR that retrieves FATTR4_IMA along 520 with other attributes and the server responds with an error, the 521 client can retry by retrieving each attribute separately to sort out 522 which attribute is causing the server to reject the NFS GETATTR 523 operation. 525 A detailed description of the NFS GETATTR operation can be found in 526 Section 18.7 of [RFC5661]. 528 4.5. Using NFS Attribute Fencing (VERIFY/NVERIFY) 530 The NFS VERIFY and NVERIFY operations, described in Sections 18.31 531 and 18.15 of [RFC5661] respectively, permit a client to add a fence 532 in an NFS COMPOUND where, if a provided FATTR4 attribute does or does 533 not match, the server can force processing of that COMPOUND to stop. 534 The FATTR4_IMA attribute is a valid choice for these operations. 536 The server MUST use a simple byte comparison to evaluate whether the 537 client-provided FATTR4_IMA matches the FATTR4_IMA attribute 538 associated with the target object. If the server has a local IMA 539 implementation, it MAY prevent the use of the local FATTR4_IMA 540 attribute value for the purpose of this comparison (via EVM 541 protection). If the client has indicated support for IMA metadata, 542 the server MUST respond with NFS4ERR_INTEGRITY. Otherwise it MUST 543 respond with NFS4ERR_ACCESS. 545 5. Deployment Examples 547 5.1. Terminology 549 Because the protocol extension described in this document is 550 OPTIONAL, clients and servers that support it will necessarily 551 interact with clients and servers that do not support it. To aid the 552 discussion in this section, we define the following terms: 554 Appraiser: A security module separate from the storage system that 555 appraises file content based on a policy and IMA measurement 556 results. 558 Participating Client: An NFS version 4.2 client that employs an 559 appraiser, supports the OPTIONAL extension described in this 560 document, and indicates this support to NFS servers using the 561 handshake described in Section 4.2. 563 Legacy Client: Any NFS client that does not support the OPTIONAL 564 extension described in this document. 566 Participating Server: An NFS version 4.2 server that supports the 567 OPTIONAL extension described in this document, indicates this 568 support to clients using the handshake described in Section 4.2, 569 and its shared file systems can store IMA metadata. A 570 participating server is not required to implement an appraiser. 572 Legacy Server: Any NFS server that does not support the OPTIONAL 573 extension described in this document. 575 In addition, there are intermediate modes of operation on 576 participating peers: 578 Full-function Client: A participating client that can modify IMA 579 metadata via NFS. 581 Fetch-only Client: A participating client that does not support 582 modifying IMA metadata on a participating server. 584 Full-function Server: A participating server that has a local user 585 execution environment and supports updating IMA metadata that 586 resides on shared local file systems. 588 Store-only Server: A participating server where there is only remote 589 access to file content and IMA metadata. 591 Lastly, we provide the following possible simple appraisal policies 592 that might be applied by an appraiser: 594 Strict: Access is prevented to a file's content if the file has no 595 IMA metadata or if the extant IMA metadata fails to verify the 596 file content. Otherwise access to the file's content is not 597 prevented. 599 Audit: Access to a file's content is never prevented. Warnings are 600 reported when a file has no IMA metadata or when extant IMA 601 metadata fails to verify the file's content. 603 Disabled: IMA metadata is ignored and access to file content is 604 never prevented. 606 5.2. Instantiating IMA Metadata 608 Once a file is written and closed, a specialized tool generates and 609 signs the IMA metadata and then writes it to the file system. The 610 tool can be used on a full-function client to sign files on a 611 participating server. Or, the tool can be used on a full-function 612 server to sign local files. The IMA metadata is then visible to 613 participating clients and local users on the server (if there are 614 any). Or, an enhanced version of cpio or rsync might copy the 615 metadata into place as part of an installation procedure. 617 Typically, once IMA metadata is associated with a file, the file's 618 content is essentially immutable, even if the file's permissions 619 settings permit writing to it. This is because changing the content 620 without updating the associated IMA metadata will make the file's 621 content inaccessible, depending on the appraisal policy in effect. 623 Updating file content requires access to a signing key in order to 624 generate fresh IMA metadata to prevent subsequent IMA appraisal 625 failures. Typically a key like this will be well-protected, and thus 626 not available on NFS clients. 628 5.3. Interaction With Legacy Implementations 630 Given the example policies and definitions we provided earlier, the 631 following statements are true: 633 o A participating client that uses the Disabled policy is equivalent 634 to a legacy client, except that a participating server is allowed 635 to respond with NFS4ERR_INTEGRITY to a participating client. 637 o A legacy client never prevents access to file content on a 638 participating server, but a participating server that has a local 639 appraiser may prevent access of a corrupted file to a legacy 640 client. 642 o A participating client using the Strict policy never allows access 643 to files stored on a legacy server. 645 An appraiser on a participating NFS version 4.2 peer needs to be 646 prepared to deal gracefully with IMA metadata it does not recognize 647 or cannot parse. Its policy may treat this case as an appraisal 648 failure. 650 It is not required for an NFS version 4.2 server to implement an 651 appraiser. However, some servers, such as the Linux NFS server, do 652 just that, applying local IMA policy to both local and remote file 653 accesses. 655 If an appraisal failure occurs during a remote access, a 656 participating server responds to a legacy client with NFS4ERR_ACCESS. 657 The server's local policy decides exactly what a participating client 658 sees: Possibilities include an NFS4ERR_INTEGRITY response (and access 659 to the file is denied), or access to the file content and IMA 660 metadata may be permitted so that the client's own IMA policies can 661 be applied. 663 6. Implementation Status 665 This section records the status of known implementations of the 666 protocol defined by this specification at the time of posting of this 667 Internet-Draft, and is based on a proposal described in [RFC7942]. 668 The description of implementations in this section is intended to 669 assist the IETF in its decision processes in progressing drafts to 670 RFCs. 672 Please note that the listing of any individual implementation here 673 does not imply endorsement by the IETF. Furthermore, no effort has 674 been spent to verify the information presented here that was supplied 675 by IETF contributors. This is not intended as, and must not be 676 construed to be, a catalog of available implementations or their 677 features. Readers are advised to note that other implementations may 678 exist. 680 6.1. Linux NFS server and client 682 Organization: The Linux Foundation 684 URL: https://www.kernel.org 686 Maturity: Prototype software based on early versions of this 687 document. 689 Coverage: The bulk of this specification is implemented. 691 Licensing: GPLv2 693 Implementation experience: No comments from implementors. 695 7. Security Considerations 697 The design of the NFS extension described in this document assumes 698 that all IMA metadata is cryptographically signed to prevent unwanted 699 alteration at rest or in transit. 701 When IMA metadata for a file exists and the end host has an active 702 appraiser, the content of a file is protected from creation to use. 703 Receivers can reliably detect unintentional or malicious alteration 704 of file content by verifying its content using the file's IMA 705 metadata. Additional protection of file content while at rest or in 706 transit on an untrusted network is unnecessary. 708 Likewise, receivers can also reliably detect unintentional or 709 malicious alteration of IMA metadata that is cryptographically 710 signed, simply by verifying its signature. Additional protection of 711 signed metadata while at rest or in transit on an untrusted network 712 is unnecessary. 714 Like other mechanisms that protect data integrity during transit, a 715 malicious agent or a network malfunction can create a denial-of- 716 service condition by repeatedly triggering integrity verification 717 failures on NFS version 4.2 clients. 719 To prevent a malicious denial-of-service attempt by altering IMA 720 metadata at rest, an NFS version 4.2 server can enforce a suitable 721 level of privilege before authorizing a local or remote agent to 722 alter this information. See Section 4.3.2 for more detail. 724 8. IANA Considerations 726 This document has no IANA actions. 728 9. References 730 9.1. Normative References 732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", BCP 14, RFC 2119, 734 DOI 10.17487/RFC2119, March 1997, 735 . 737 [RFC4506] Eisler, M., Ed., "XDR: External Data Representation 738 Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 739 2006, . 741 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 742 "Network File System (NFS) Version 4 Minor Version 1 743 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 744 . 746 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 747 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 748 November 2016, . 750 [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor 751 Version 2 External Data Representation Standard (XDR) 752 Description", RFC 7863, DOI 10.17487/RFC7863, November 753 2016, . 755 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 756 Code: The Implementation Status Section", BCP 205, 757 RFC 7942, DOI 10.17487/RFC7942, July 2016, 758 . 760 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 761 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 762 May 2017, . 764 [RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor 765 Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, 766 . 768 9.2. Informative References 770 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 771 Hashing for Message Authentication", RFC 2104, 772 DOI 10.17487/RFC2104, February 1997, 773 . 775 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 776 Nicholas, "Internet X.509 Public Key Infrastructure: 777 Certification Path Building", RFC 4158, 778 DOI 10.17487/RFC4158, September 2005, 779 . 781 [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 782 "Network File System (NFS) Version 4 Minor Version 1 783 External Data Representation Standard (XDR) Description", 784 RFC 5662, DOI 10.17487/RFC5662, January 2010, 785 . 787 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 788 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 789 November 2016, . 791 [SAILER] Sailer, R., Zhang, X., Jaeger, T., and L. van Doorn, 792 "Design and Implementation of a TCG-based Integrity 793 Measurement Architecture", Proceedings of the 13th USENIX 794 Security Symposium, August 2004. 796 9.3. URIs 798 [1] https://trustedcomputinggroup.org/wp-content/uploads/Trusted- 799 Platform-Module-Summary_04292008.pdf 801 Acknowledgments 803 The author wishes to thank Mimi Zohar and James Morris for their 804 early review of the concepts in this document, Wim Coekaerts for his 805 encouragement of this work, and Dave Noveck for his work on NFS 806 version 4 extensibility. 808 The author wishes to acknowledge review comments from Dave Noveck, 809 Craig Everhart, and Bruce Fields which helped to make this a better 810 document. 812 The XDR extraction conventions were first described by the authors of 813 the NFS version 4.1 XDR specification [RFC5662]. Herbert van den 814 Bergh suggested the replacement sed script used in this document. 816 Special thanks go to Transport Area Director Magnus Westerlund, NFSV4 817 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 818 Working Group Secretary Thomas Haynes for their support. 820 Author's Address 822 Charles Lever 823 Oracle Corporation 824 United States of America 826 Email: chuck.lever@oracle.com