idnits 2.17.1 draft-ietf-nfsv4-integrity-measurement-04.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 (March 27, 2019) is 1851 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 542 -- Looks like a reference, but probably isn't: '2' on line 545 ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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 March 27, 2019 5 Expires: September 28, 2019 7 Integrity Measurement for Network File System version 4 8 draft-ietf-nfsv4-integrity-measurement-04 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 September 28, 2019. 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 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 3. Protocol Extension Considerations . . . . . . . . . . . . . . 4 57 3.1. XDR Extraction . . . . . . . . . . . . . . . . . . . . . 4 58 4. Managing IMA Metadata on NFS Files . . . . . . . . . . . . . 5 59 4.1. XDR Definition . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Storing IMA Metadata . . . . . . . . . . . . . . . . . . 6 61 4.3. Retrieving IMA Metadata . . . . . . . . . . . . . . . . . 6 62 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.2. Instantiating IMA Metadata . . . . . . . . . . . . . . . 8 65 5.2.1. Authorizing Updates to IMA Metadata . . . . . . . . . 8 66 5.3. Interaction With Non-Participating Implementations . . . 8 67 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 68 6.1. Linux NFS server and client . . . . . . . . . . . . . . . 10 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 9.2. Informative References . . . . . . . . . . . . . . . . . 12 74 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 The security of software distribution systems is complex and 81 challenging, especially as software distribution has become 82 increasingly decentralized. An end administrator needs to trust that 83 she is running executables just as they are supplied by a software 84 vendor; in other words, that they have not been modified by malicious 85 actors, contracted system administration services, or broken hardware 86 or software. Software vendors want a guarantee that customer- 87 installed executables that fall under support contracts have 88 similarly not been modified. 90 There already exist mechanisms that protect file data during certain 91 portions of a file's life cycle: 93 o Whole file system checksumming can verify so-called Golden Master 94 installation media before it is used to install the software it 95 contains. 97 o File or block integrity mechanisms can protect data at rest on 98 storage servers. 100 o For a distributed file system such as NFS, transport layer 101 security or a GSS integrity service (as described in [RFC7861]) 102 can protect data while it traverses a network between a storage 103 server and a client. 105 A more extensive mechanism is needed to guarantee that no 106 modification of a particular file has occurred since it was created, 107 perhaps even after several generations of copies have been made of 108 the file's content. 110 1.1. The Linux Integrity Measurement Architecture 112 The Linux Integrity Measurement Architecture (IMA) [1] provides 113 assurance that the content of files is unaltered and authentic to 114 what was originally written to those files. The primary goal is to 115 detect when a remote attacker, a local attacker, or unintentional 116 platform behavior has modified the content of a file either in 117 transit or at rest. 119 A keyed hash (e.g., an HMAC [RFC2104]) authenticates the identity of 120 the last modifier of a file's content and serves as a strong check of 121 the content's integrity. For the purposes of this document, we refer 122 to this hash as "IMA metadata". Such metadata is generated and 123 signed by a trusted authority and then associated with each file 124 using special tools. 126 Each hash and its signature are verified as the file's content is 127 read into memory immediately before it is used. If verification 128 fails, access to the file's content is prevented. A security module 129 separate from the file system specifies the format of the metadata, 130 measures file content, and enforces a policy for determining when 131 file content is safe to use on the local system. For the purposes of 132 this document, we refer to this module as the "integrity assessor" 133 and the policy it uses as the "appraisal policy". 135 Appraisal is typically performed at the point of content use. The 136 file and storage system play no part in measurement or appraisal. 137 The file system acts only as a conduit by which IMA metadata and file 138 content move between storage on an NFS server and the integrity 139 assessor module on the host where that content is to be used. 141 NFS peers accessing a set of shared files must all agree on the IMA 142 metadata format. The format is specified by the integrity assessor 143 module and is therefore not described in this document. The protocol 144 extension in this document enables the storage and use of IMA 145 metadata so that measurement and appraisal can occur at point-of-use 146 on NFS clients. The extension does not provide a full assessment 147 mechanism. 149 A Trusted Platform Module [2] can seal key material used to sign and 150 verify file content. Distributing and protecting such key material 151 is outside the scope of the extension specified in this document. 153 2. Requirements Language 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 3. Protocol Extension Considerations 163 This document specifies an OPTIONAL extension to NFS version 4 minor 164 version 2 [RFC7862], hereafter referred to as NFS version 4.2. NFS 165 version 4.2 servers and clients implemented without knowledge of this 166 extension will continue to interoperate with NFS version 4.2 clients 167 and servers that are aware of the extension, whether or not they 168 support it. 170 Because [RFC7862] does not define NFS version 4.2 as non-extensible, 171 [RFC8178] treats it as an extensible minor version. Therefore this 172 Standards Track RFC extends NFS version 4.2 but does not update 173 [RFC7862] or [RFC7863]. 175 3.1. XDR Extraction 177 Section 4.1 contains a description of an extension to the NFS version 178 4.2 protocol, expressed in the External Data Representation (XDR) 179 language [RFC4506]. This description is provided in a way that makes 180 it simple to extract into ready-to-compile form. The reader can 181 apply the following sed script to this document to produce a machine- 182 readable XDR description of the extension. 184 186 sed -n -e 's:^ */// ::p' -e 's:^ *///$::p' 188 190 That is, if this document is in a file called "ima-extension.txt" 191 then the reader can do the following to extract an XDR description 192 file: 194 196 sed -n -e 's:^ */// ::p' -e 's:^ *///$::p' 197 < ima-extension.txt > ima.x 199 201 Once that extraction is done, these added lines need to be inserted 202 into an appropriate base XDR of the generated XDR from [RFC7863] 203 together with XDR from any additional extensions to be recognized by 204 the implementation. This will result in a ready-to-compile XDR file. 206 4. Managing IMA Metadata on NFS Files 208 4.1. XDR Definition 210 This section defines a new data type to encapsulate and a new 211 OPTIONAL attribute to access and update IMA metadata associated with 212 a particular file. 214 To enable a single IMA metadata payload to be retrieved or updated 215 via a single RPC, and to constrain the transport resources required 216 for the operations defined in this section, the length of IMA 217 metadata MUST NOT exceed 4096 bytes in length. 219 When an NFS version 4.2 server does not recognize, or does recognize 220 but does not support, this new attribute, the server responds in 221 accordance with the requirements specified in Section 4.3 of 222 [RFC8178]. 224 226 /// /* 227 /// * Copyright (c) 2019 IETF Trust and the person identified 228 /// * as author of the code. All rights reserved. 229 /// * 230 /// * The author of the code is: C. Lever 231 /// */ 232 /// 233 /// %/* 234 /// % * New For Linux IMA support 235 /// % */ 236 /// opaque ima_data<4096>; 237 /// 238 /// const FATTR4_LINUX_IMA = XXX; /* to be assigned */ 240 242 4.2. Storing IMA Metadata 244 An NFS version 4.2 client stores IMA metadata by sending a SETATTR 245 operation that specifies the FATTR4_LINUX_IMA attribute, targeting 246 the file object associated with the metadata to be stored. This 247 attribute completely replaces any previous one. 249 To remove IMA metadata from a file, the client sends a 250 FATTR4_LINUX_IMA attribute whose length is zero. Modifying the file 251 in any other way MUST NOT alter or remove FATTR4_LINUX_IMA 252 attributes. 254 When a SETATTR is presented to an NFS version 4.2 server with a 255 credential that is not authorized to replace a FATTR4_LINUX_IMA 256 attribute, the server MUST respond with NFS4ERR_ACCESS. 258 When a SETATTR is presented to an NFS version 4.2 server with a 259 fattr4_linux_ima field whose length is larger than 4096 bytes, the 260 server MUST respond with NFS4ERR_INVAL. 262 When a SETATTR is presented to an NFS version 4.2 server and the 263 target object resides in a file system which supports 264 FATTR4_LINUX_IMA but the object itself does not support the 265 FATTR4_LINUX_IMA attribute, the server MUST respond with 266 NFS4ERR_WRONGTYPE. 268 When a SETATTR is presented to an NFS version 4.2 server but the 269 target object resides in a file system which does not support the 270 FATTR4_LINUX_IMA attribute, the server MUST respond with 271 NFS4ERR_ATTRNOTSUPP. 273 A detailed description of the SETATTR operation can be found in 274 Section 18.30 of [RFC5661]. 276 4.3. Retrieving IMA Metadata 278 An NFS version 4.2 client retrieves IMA metadata by retrieving the 279 FATTR4_LINUX_IMA attribute via a GETATTR operation, specifying the 280 file handle of the file object associated with the metadata to be 281 retrieved. This information may have been computed and signed 282 previously on this client or by some other agent. 284 When a GETATTR is presented to an NFS version 4.2 server and the 285 target object resides in a file system which supports the 286 FATTR4_LINUX_IMA attribute but the object does not support the 287 FATTR4_LINUX_IMA attribute, the server MUST respond with 288 NFS4ERR_WRONGTYPE. 290 When a GETATTR is presented to an NFS version 4.2 server but the 291 target object resides in a file system which does not support 292 FATTR4_LINUX_IMA, this does not result in an error and the 293 FATTR4_FILE_PROVENANCE attribute bit is cleared in the server's 294 response. 296 Otherwise, if the target object supports FATTR4_LINUX_IMA and there 297 is no IMA metadata is available for the target object, the server 298 returns a FATTR4_LINUX_IMA attribute whose length is zero. 300 Integrity assessment occurs after file content has been delivered but 301 immediately before that content is to be used. To enable integrity 302 assessment on NFS clients to verify IMA metadata, NFS version 4.2 303 servers should not prevent access to file content if they have a 304 local appraisal policy and it indicates that integrity verification 305 has failed. 307 A detailed description of the GETATTR operation can be found in 308 Section 18.7 of [RFC5661]. 310 5. Operation 312 5.1. Terminology 314 To aid the discussion in this section, we define a few handy terms: 316 o A "participating client" is an NFS version 4.2 client that 317 supports the OPTIONAL extension described in this document and 318 employs a integrity assessor module. 320 o A "non-participating client" is an NFS version 4.2 client that 321 does not support the OPTIONAL extension described in this document 322 or does not employ a integrity assessor module. 324 o A "participating server" is an NFS version 4.2 server that 325 supports the OPTIONAL extension described in this document and its 326 shared filesystems can store IMA metadata. A participating server 327 is not required to implement an integrity assessor module. 329 o A "non-participating server" is an NFS version 4.2 server that 330 does not support the OPTIONAL extension described in this document 331 or its shared filesystems are not capable of storing IMA metadata. 333 In addition, there are intermediate modes of operation on 334 participating peers: 336 o A "full-function client" is a participating client that supports 337 updating remote IMA metadata. 339 o A "fetch-only client" is a participating client that does not 340 support modifying IMA metadata on a participating server. 342 o A "full-function server" is a participating server that supports 343 updating IMA metadata that resides on local shared file systems. 345 o A "store-only server" is a participating server where there is 346 only remote access to IMA metadata. 348 5.2. Instantiating IMA Metadata 350 Once a file is written, IMA metadata is generated and signed by an 351 appropriate trust authority. Using the OPTIONAL extension specified 352 in this document, the information can be associated with a file on 353 either a full-function server or client using a tool with appropriate 354 privileges that writes IMA metadata to the shared file system. When 355 using a store-only server, only a full-function client can place IMA 356 metadata in the shared file system. 358 Typically, once IMA metadata is associated with a file, the file's 359 content is essentially immutable, even if the file has write 360 permissions. This is because changing the content without updating 361 the associated IMA metadata will make the content inaccessible, 362 depending on the appraisal policy in effect. Thus updating the file 363 content usually requires generating fresh IMA metadata. 365 5.2.1. Authorizing Updates to IMA Metadata 367 A participating server should ensure that modifications to IMA 368 metadata are done only by appropriately authorized agents. Such 369 agents usually include only agents with super-user privileges. The 370 NFS server MAY confirm that the new IMA metadata actually verifies 371 the file content correctly before storing it. 373 5.3. Interaction With Non-Participating Implementations 375 Because the protocol extension described herein is OPTIONAL, clients 376 and servers that support it must necessarily interact with clients 377 and servers that do not support it. To set the stage for a 378 discussion of interactions that might occur, consider the following 379 possible simple appraisal policies that might be adopted by an 380 integrity assessment module: 382 Strict: Access is prevented to a file's content if the file has no 383 IMA metadata or if the extant IMA metadata fails to verify the 384 file content. Otherwise access to the file's content is not 385 prevented. 387 Audit: Access to a file's content is never prevented. Warnings are 388 reported when a file has no IMA metadata or when extant IMA 389 metadata fails to verify the file's content. 391 Disabled: Access to file content is never prevented and IMA metadata 392 is ignored. 394 Given the above example policies and the definitions we provided 395 earlier for participating and non-participating implementations, the 396 following statements are true: 398 o A participating client that uses the Disabled policy is equivalent 399 to a non-participating client. 401 o A non-participating client never prevents access to file content 402 on a participating server. 404 o A participating client using the Strict policy never allows access 405 to files stored on a non-participating server. 407 A integrity assessor module on an NFS version 4.2 peer needs to be 408 prepared to deal with IMA metadata it does not recognize or cannot 409 parse. Its policy may treat this case as a appraisal failure. 411 Note that an NFS version 4.2 server may use a integrity assessor 412 module to prevent access by local users to protected files. To 413 enable NFS version 4.2 clients to do their own assessment, an NFS 414 version 4.2 server should not prevent remote access to participating 415 clients if local integrity assessment fails. 417 6. Implementation Status 419 This section records the status of known implementations of the 420 protocol defined by this specification at the time of posting of this 421 Internet-Draft, and is based on a proposal described in [RFC7942]. 422 The description of implementations in this section is intended to 423 assist the IETF in its decision processes in progressing drafts to 424 RFCs. 426 Please note that the listing of any individual implementation here 427 does not imply endorsement by the IETF. Furthermore, no effort has 428 been spent to verify the information presented here that was supplied 429 by IETF contributors. This is not intended as, and must not be 430 construed to be, a catalog of available implementations or their 431 features. Readers are advised to note that other implementations may 432 exist. 434 6.1. Linux NFS server and client 436 Organization: The Linux Foundation 438 URL: https://www.kernel.org 440 Maturity: Prototype software based on early versions of this 441 document. 443 Coverage: The bulk of this specification is implemented. 445 Licensing: GPLv2 447 Implementation experience: No comments from implementors. 449 7. Security Considerations 451 The design of the OPTIONAL extension described in this document 452 assumes that all IMA metadata is keyed or otherwise cryptographically 453 signed by a trust authority to prevent unwanted alteration at rest or 454 in transit. 456 When IMA metadata for a file exists and the end host has adopted an 457 IMA policy, the content of a file is protected from creation to use. 458 Receivers can reliably detect unintentional or malicious alteration 459 of file content by verifying its content using the file's IMA 460 metadata. Additional protection of file content while at rest or in 461 transit on an untrusted network is unnecessary. 463 Likewise, receivers can also reliably detect unintentional or 464 malicious alteration of IMA metadata that is cryptographically 465 signed, simply by verifying its signature. Additional protection of 466 signed metadata while at rest or in transit on an untrusted network 467 is unnecessary. 469 Like other mechanisms that protect data integrity during transit, A 470 malicious agent or a network malfunction can create a denial-of- 471 service condition by repeatedly triggering integrity verification 472 failures on NFS version 4.2 clients. 474 To prevent a malicious denial-of-service attempt by altering IMA 475 metadata at rest, an NFS version 4.2 server can enforce a suitable 476 level of privilege before authorizing a local or remote agent to 477 alter this information. See Section 5.2.1 for more detail. 479 8. IANA Considerations 481 This document requests no action from IANA. 483 9. References 485 9.1. Normative References 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, 489 DOI 10.17487/RFC2119, March 1997, 490 . 492 [RFC4506] Eisler, M., Ed., "XDR: External Data Representation 493 Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 494 2006, . 496 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 497 "Network File System (NFS) Version 4 Minor Version 1 498 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 499 . 501 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 502 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 503 November 2016, . 505 [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor 506 Version 2 External Data Representation Standard (XDR) 507 Description", RFC 7863, DOI 10.17487/RFC7863, November 508 2016, . 510 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 511 Code: The Implementation Status Section", BCP 205, 512 RFC 7942, DOI 10.17487/RFC7942, July 2016, 513 . 515 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 516 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 517 May 2017, . 519 [RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor 520 Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, 521 . 523 9.2. Informative References 525 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 526 Hashing for Message Authentication", RFC 2104, 527 DOI 10.17487/RFC2104, February 1997, 528 . 530 [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 531 "Network File System (NFS) Version 4 Minor Version 1 532 External Data Representation Standard (XDR) Description", 533 RFC 5662, DOI 10.17487/RFC5662, January 2010, 534 . 536 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 537 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 538 November 2016, . 540 9.3. URIs 542 [1] http://downloads.sf.net/project/linux-ima/linux-ima/ 543 Integrity_overview.pdf 545 [2] https://trustedcomputinggroup.org/wp-content/uploads/Trusted- 546 Platform-Module-Summary_04292008.pdf 548 Acknowledgments 550 The author wishes to thank Mimi Zohar and James Morris for their 551 early review of the concepts in this document, Wim Coekaerts for his 552 encouragement of this work, and Dave Noveck for his work on NFS 553 version 4 extensibility. 555 The author wishes to acknowledge review comments from Dave Noveck, 556 Craig Everhart, and Bruce Fields which helped to make this a better 557 document. 559 The XDR extraction conventions were first described by the authors of 560 the NFS version 4.1 XDR specification [RFC5662]. Herbert van den 561 Bergh suggested the replacement sed script used in this document. 563 Special thanks go to Transport Area Director Magnus Westerlund, NFSV4 564 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 565 Working Group Secretary Thomas Haynes for their support. 567 Author's Address 569 Charles Lever 570 Oracle Corporation 571 United States of America 573 Email: chuck.lever@oracle.com