idnits 2.17.1 draft-ietf-nfsv4-integrity-measurement-02.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 8, 2018) is 2027 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) ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 October 8, 2018 5 Expires: April 11, 2019 7 File Content Provenance for Network File System version 4 8 draft-ietf-nfsv4-integrity-measurement-02 10 Abstract 12 This document specifies an OPTIONAL extension to NFS version 4 minor 13 version 2 that enables file provenance information to be conveyed 14 between NFS version 4.2 servers and clients. File provenance 15 information authenticates the creator of a file's content and helps 16 guarantee the content's integrity from creation to use. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 11, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 3. Protocol Extension Considerations . . . . . . . . . . . . . . 4 55 4. Managing File Provenance Information on NFS Files . . . . . . 5 56 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 63 1. Introduction 65 The security of software distribution systems is complex and 66 challenging, especially as software distribution has become 67 increasingly decentralized. An end administrator needs to trust that 68 she is running executables just as they are supplied by a software 69 vendor; in other words, that they have not been modified by malicious 70 actors, contracted system administration services, or broken hardware 71 or software. Software vendors want a guarantee that customer- 72 installed executables that fall under support contracts have 73 similarly not been modified. 75 There already exist mechanisms that protect file data during certain 76 portions of a file's life cycle: 78 o Whole file system checksumming can verify so-called Golden Master 79 installation media before it is used to install the software it 80 contains. 82 o File or block integrity mechanisms can protect data at rest on 83 storage servers. 85 o For a distributed file system such as NFS, transport layer 86 security or a GSS integrity service (as described in [RFC7861]) 87 can protect data while it traverses a network between a storage 88 server and a client. 90 A more extensive mechanism is needed to guarantee that no 91 modification of a particular file has occurred since it was created, 92 perhaps even after several generations of copies have been made of 93 the file's content. 95 This guarantee can be accomplished by separately preserving a keyed 96 hash, such as an HMAC [RFC2104], of a file's content. The checksum 97 and its signature are verified as the file's content is read into 98 memory immediately before it is used. If verification fails, access 99 to the file's content is prevented. The hash is updated and re- 100 signed only when the file is legitimately modified. 102 1.1. Architecture Summary 104 A keyed hash authenticates the identity of the last modifier of a 105 file's content and serves as a strong check of the content's 106 integrity. For the purposes of this document, we refer to this 107 metadata using the generic term "file provenance information". 109 File provenance information is generated and signed by a "provenance 110 authority", and then placed in the file system using special tools. 112 A security module separate from the file system stack specifies the 113 format of the file provenance information and enforces a policy for 114 utilizing it to determine when a protected file's content is safe to 115 use on the local system. For the purposes of this document, we refer 116 to this module as a "provenance assessor", and the policy it uses as 117 the "provenance assessment policy". 119 NFS acts as a conduit by which file provenance information and file 120 content move between storage on an NFS server and the provenance 121 assessor where that content is to be accessed. NFS peers accessing a 122 set of shared files must all agree on the at-rest file provenance 123 information format. The format is specified by the provenance 124 assessor and is therefore not described in this document. 126 A Trusted Platform Module [TPM-SUM] can seal the key material used to 127 sign and verify file content. Distributing and protecting such key 128 material is outside the scope of the OPTIONAL extension specified in 129 this document. 131 The Linux Integrity Measurement Architecture (IMA) is an example of a 132 mechanism that provides a full provenance assessment service 133 [IMA-WP]. The protocol extension in this document enables the 134 storage and use of file provenance information to protect files 135 stored on an NFS server. 137 2. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in BCP 14 [RFC2119] 142 [RFC8174] when, and only when, they appear in all capitals, as shown 143 here. 145 3. Protocol Extension Considerations 147 This document specifies an OPTIONAL extension to NFS version 4 minor 148 version 2 [RFC7862], hereafter referred to as NFS version 4.2. NFS 149 version 4.2 servers and clients implemented without knowledge of this 150 extension will continue to interoperate with NFS version 4.2 clients 151 and servers that are aware of the extension, whether or not they 152 support it. 154 Because [RFC7862] does not define NFS version 4.2 as non-extensible, 155 [RFC8178] treats it as an extensible minor version. Therefore this 156 Standards Track RFC extends NFS version 4.2 but does not update 157 [RFC7862] or [RFC7863]. 159 3.1. XDR Extraction 161 Section 4.1 contains a description of an extension to the NFS version 162 4.2 protocol, expressed in the External Data Representation (XDR) 163 language [RFC4506]. This description is provided in a way that makes 164 it simple to extract into ready-to-compile form. The reader can 165 apply the following sed script to this document to produce a machine- 166 readable XDR description of the extension. 168 170 sed -n -e 's:^ */// ::p' -e 's:^ *///$::p' 172 174 That is, if this document is in a file called "provenance- 175 extension.txt" then the reader can do the following to extract an XDR 176 description file: 178 180 sed -n -e 's:^ */// ::p' -e 's:^ *///$::p' 181 < provenance-extension.txt > ima.x 183 185 Once that extraction is done, these added lines need to be inserted 186 into an appropriate base XDR of the generated XDR from [RFC7863] 187 together with XDR from any additional extensions to be recognized by 188 the implementation. This will result in a ready-to-compile XDR file. 190 4. Managing File Provenance Information on NFS Files 192 4.1. XDR Definition 194 This section defines a new data type to encapsulate and a new 195 OPTIONAL attribute to access and update file provenance information 196 associated with a particular file. 198 To enable a single file provenance information payload to be 199 retrieved or updated via a single RPC, and to constrain the transport 200 resources required for the operations defined in this section, the 201 length of file provenance information MUST NOT exceed 4096 bytes in 202 length. 204 When an NFS version 4.2 server does not recognize, or does recognize 205 but does not support, this new attribute, the server responds in 206 accordance with the requirements specified in Section 4.3 of 207 [RFC8178]. 209 211 /// /* 212 /// * Copyright (c) 2018 IETF Trust and the person identified 213 /// * as author of the code. All rights reserved. 214 /// * 215 /// * The author of the code is: C. Lever 216 /// */ 217 /// 218 /// const FILEPROV4_MAXSIZE = 4096; 219 /// typedef opaque file_prov4; 220 /// 221 /// %/* 222 /// % * New For File Provenance Information 223 /// % */ 224 /// const FATTR4_FILE_PROVENANCE = XXX; /* to be assigned */ 225 /// 226 /// typedef file_prov4 fattr4_file_provenance; 228 230 4.2. Storing File Provenance Information 232 An NFS version 4.2 client stores file provenance information by 233 sending a SETATTR operation that specifies the FATTR4_FILE_PROVENANCE 234 attribute, targeting the file object associated with the file 235 provenance information to be stored. This attribute completely 236 replaces any previous one. 238 To remove this attribute from a file, the client sends a 239 FATTR4_FILE_PROVENANCE attribute whose length is zero. [ cel: Does 240 writing to a file have any effect on IMA metadata? ] 242 When a SETATTR is presented to an NFS version 4.2 server with a 243 credential that is not authorized to replace the 244 FATTR4_FILE_PROVENANCE attribute, the server MUST respond with 245 NFS4ERR_ACCESS. 247 When a SETATTR is presented to an NFS version 4.2 server with a 248 fattr4_file_provenance field whose length is larger than 249 FILEPROV4_MAXSIZE, the server MUST respond with NFS4ERR_INVAL. 251 When a SETATTR is presented to an NFS version 4.2 server and the 252 target object resides in a file system which supports 253 FATTR4_FILE_PROVENANCE but the object does not support this 254 attribute, the server MUST respond with NFS4ERR_WRONGTYPE. 256 When a SETATTR is presented to an NFS version 4.2 server but the 257 target object resides in a file system which does not support 258 FATTR4_FILE_PROVENANCE, the server MUST respond with 259 NFS4ERR_ATTRNOTSUPP. 261 A detailed description of the SETATTR operation can be found in 262 Section 18.30 of [RFC5661]. 264 4.3. Retrieving File Provenance Information 266 An NFS version 4.2 client retrieves file provenance information by 267 retrieving the FATTR4_FILE_PROVENANCE attribute via a GETATTR 268 operation, specifying the file handle of the file object associated 269 with the information to be retrieved. This information may have been 270 computed and signed previously on this client or by some other agent. 272 When a GETATTR is presented to an NFS version 4.2 server and the 273 target object resides in a file system which supports 274 FATTR4_FILE_PROVENANCE but the object does not support this 275 attribute, the server MUST respond with NFS4ERR_WRONGTYPE. 277 When a GETATTR is presented to an NFS version 4.2 server but the 278 target object resides in a file system which does not support 279 FATTR4_FILE_PROVENANCE, this does not result in an error and the 280 FATTR4_FILE_PROVENANCE attribute bit is clear in the server's 281 response. 283 Otherwise, if the target object supports FATTR4_FILE_PROVENANCE and 284 there is no file provenance information is available for the target 285 object, the server returns a FATTR4_FILE_PROVENANCE attribute whose 286 length is zero. 288 Provenance assessors operate after file content has been delivered 289 but immediately before that content is to be used. To enable 290 provenance assessors on NFS clients to verify file provenance 291 information, NFS version 4.2 servers do not prevent access to file 292 content if they have a local provenance assessor and it indicates 293 that provenance verification has failed. 295 A detailed description of the GETATTR operation can be found in 296 Section 18.7 of [RFC5661]. 298 5. Operation 300 5.1. Terminology 302 To aid the discussion in this section, we define a few handy terms: 304 o A "participating client" is an NFS version 4.2 client that 305 supports the OPTIONAL extension described in this document and 306 employs a provenance assessor. 308 o A "non-participating client" is an NFS version 4.2 client that 309 does not support the OPTIONAL extension described in this document 310 or does not employ a provenance assessor. 312 o A "participating server" is an NFS version 4.2 server that 313 supports the OPTIONAL extension described in this document and its 314 shared filesystems can store file provenance information. 316 o A "non-participating server" is an NFS version 4.2 server that 317 does not support the OPTIONAL extension described in this document 318 or its shared filesystems are not capable of storing file 319 provenance information. 321 In addition, there are intermediate modes of operation on 322 participating peers: 324 o A "full-function client" is a participating client that supports 325 updating remote file provenance information. 327 o A "fetch-only client" is a participating client that does not 328 support modifying file provenance information on a participating 329 server. 331 o A "full-function server" is a participating server that supports 332 updating file provenance information that resides on local shared 333 file systems. 335 o A "store-only server" is a participating server where there is 336 only remote access to file provenance information. 338 5.2. Instantiating File Provenance Information 340 Once a file is written, file provenance information is generated and 341 signed by an appropriate provenance authority. Using the OPTIONAL 342 extension specified in this document, the information can be 343 associated with a file on either a full-function server or client 344 using a tool with appropriate privileges that writes the provenance 345 information to the shared file system. When using a store-only 346 server, only a full-function client can place file provenance 347 information in the shared file system. 349 Typically, once file provenance information is associated with a 350 file, the file's content is essentially immutable, even if the file 351 has write permissions. This is because changing the content without 352 updating the associated file provenance information will make the 353 content inaccessible, depending on the provenance assessment policy 354 in effect. Thus updating the file content usually requires 355 generating fresh file provenance information. 357 5.2.1. Authorizing Updates to File Provenance Information 359 A participating server should ensure that modifications to file 360 provenance information are done only by appropriately authorized 361 agents. 363 [ cel: TBD. Regular users are probably not able to modify a local 364 security.ima xattr. What kind of authority should be required to 365 modify FPI remotely? ] 367 5.3. Interaction With Non-Participating Implementations 369 Because the protocol extension described herein is OPTIONAL, clients 370 and servers that support it must necessarily interact with clients 371 and servers that do not support it. To set the stage for a 372 discussion of interactions that might occur, consider the following 373 possible simple provenance assessment policies that might be adopted 374 by a provenance assessor (actual polices are left to provenance 375 assessors): 377 Strict 378 Access is prevented to a file's content if the file has no 379 provenance information or if the provenance information fails to 380 verify the file content. Otherwise access to the file's content 381 is not prevented. 383 Audit 384 Access to a file's content is never prevented. Warnings are 385 reported when a file has no provenance information or when 386 existing provenance information fails to verify the file's 387 content. 389 Disabled 390 Access to file content is never prevented and provenance 391 information is ignored. 393 Given the above example policies and the definitions we provided 394 earlier for participating and non-participating implementations, the 395 following statements are true: 397 o A participating client that uses the Disabled policy is equivalent 398 to a non-participating client. 400 o A non-participating client never prevents access to file content 401 on a participating server. 403 o A participating client using the Strict policy never allows access 404 to files stored on a non-participating server. 406 A provenance assessor on an NFS version 4.2 peer needs to be prepared 407 to deal with file provenance information it does not recognize or 408 cannot parse. Typically its policy treats this case as a provenance 409 verification failure. 411 Note that an NFS version 4.2 server may use a provenance assessor to 412 prevent access by local users to protected files. To enable NFS 413 version 4.2 clients to do their own assessment, an NFS version 4.2 414 server should never prevent remote access to clients if local 415 provenance assessment fails. 417 5.4. Performance Cost of Using File Provenance Information 419 A provenance assessor typically checksums the entirety of a file's 420 content. When a file's content is first accessed, after it changes, 421 or if any portion of a file is evicted from an NFS version 4.2 422 client's cache, the client must retrieve any missing content before 423 its local provenance assessor can compute a fresh checksum to verify 424 the file's content. 426 Thus provenance assessment can incur a significant performance impact 427 for large files, files that change frequently, or files where only a 428 portion of the content is used on that client (e.g., software 429 libraries). A provenance assessor can employ mechanisms not 430 specified here to reduce this impact. 432 For example, instead of signing a hash of the file's byte stream, a 433 Merkle tree can be constructed that allows assessors to verify the 434 integrity of smaller portions of a large file [MERKLE]. The root 435 hash of that tree, being of sufficiently limited size, can be signed 436 and stored as file provenance information. The Merkle tree, which is 437 stored elsewhere, can be used to verify portions of the file's 438 content without the need to read the whole file. 440 6. Security Considerations 442 The design of the OPTIONAL extension described in this document 443 assumes that all file provenance information is keyed or otherwise 444 cryptographically signed by a provenance authority to prevent 445 unwanted alteration at rest or in transit. 447 When file provenance information for a file exists, the content of a 448 file is protected from creation to use. Receivers can reliably 449 detect unintentional or malicious alteration of file content by 450 verifying its content using file provenance information. Additional 451 protection of file content while at rest or in transit on an 452 untrusted network is unnecessary. 454 Likewise, receivers can also reliably detect unintentional or 455 malicious alteration of file provenance information that is 456 cryptographically signed, simply by verifying its signature. 457 Additional protection of signed file provenance information while at 458 rest or in transit on an untrusted network is unnecessary. 460 Like other mechanisms that protect data integrity during transit, A 461 malicious agent or a network malfunction can create a denial-of- 462 service condition by repeatedly triggering integrity verification 463 failures on NFS version 4.2 clients. 465 To prevent a malicious denial-of-service attempt by altering file 466 provenance information at rest, an NFS version 4.2 server should 467 enforce a suitable level of privilege before authorizing a local or 468 remote agent to alter this information. See Section 5.2.1 for more 469 detail. 471 7. IANA Considerations 473 This document does not require any actions by IANA. 475 8. References 477 8.1. Normative References 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, 481 DOI 10.17487/RFC2119, March 1997, 482 . 484 [RFC4506] Eisler, M., Ed., "XDR: External Data Representation 485 Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May 486 2006, . 488 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 489 "Network File System (NFS) Version 4 Minor Version 1 490 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 491 . 493 [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor 494 Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, 495 November 2016, . 497 [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor 498 Version 2 External Data Representation Standard (XDR) 499 Description", RFC 7863, DOI 10.17487/RFC7863, November 500 2016, . 502 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 503 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 504 May 2017, . 506 [RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor 507 Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017, 508 . 510 8.2. Informative References 512 [IMA-WP] Safford, D., "An Overview of The Linux Integrity 513 Subsystem", . 516 [MERKLE] Merkle, R., ""A Digital Signature Based on a Conventional 517 Encryption Function" Advances in Cryptology - CRYPTO '87", 518 DOI 10.1007/3-540-48184-2_32, 1988. 520 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 521 Hashing for Message Authentication", RFC 2104, 522 DOI 10.17487/RFC2104, February 1997, 523 . 525 [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 526 "Network File System (NFS) Version 4 Minor Version 1 527 External Data Representation Standard (XDR) Description", 528 RFC 5662, DOI 10.17487/RFC5662, January 2010, 529 . 531 [RFC7861] Adamson, A. and N. Williams, "Remote Procedure Call (RPC) 532 Security Version 3", RFC 7861, DOI 10.17487/RFC7861, 533 November 2016, . 535 [TPM-SUM] Trusted Computing Group, "Trusted Platform Module (TPM) 536 Summary", April 2008, . 540 Acknowledgments 542 The author wishes to thank Mimi Zohar and James Morris for their 543 early review of the concepts in this document, Wim Coekaerts for his 544 encouragement of this work, and Dave Noveck for his work on NFS 545 version 4 extensibility. 547 The author wishes to acknowledge review comments from Dave Noveck, 548 Craig Everhart, and Bruce Fields which helped to make this a better 549 document. 551 The XDR extraction conventions were first described by the authors of 552 the NFS version 4.1 XDR specification [RFC5662]. Herbert van den 553 Bergh suggested the replacement sed script used in this document. 555 Special thanks go to Transport Area Director Spencer Dawkins, NFSV4 556 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 557 Working Group Secretary Thomas Haynes for their support. 559 Author's Address 560 Charles Lever 561 Oracle Corporation 562 1015 Granger Avenue 563 Ann Arbor, MI 48104 564 United States of America 566 Phone: +1 248 816 6463 567 Email: chuck.lever@oracle.com