draft-ietf-nfsv4-integrity-measurement-07.txt   draft-ietf-nfsv4-integrity-measurement-08.txt 
Network File System Version 4 C. Lever Network File System Version 4 C. Lever
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track September 30, 2019 Intended status: Standards Track April 3, 2020
Expires: April 2, 2020 Expires: October 5, 2020
Integrity Measurement for Network File System version 4 Integrity Measurement for Network File System version 4
draft-ietf-nfsv4-integrity-measurement-07 draft-ietf-nfsv4-integrity-measurement-08
Abstract Abstract
This document specifies an OPTIONAL extension to NFS version 4 minor This document specifies an OPTIONAL extension to NFS version 4 minor
version 2 that enables Linux Integrity Measurement Architecture version 2 that enables Linux Integrity Measurement Architecture
metadata (IMA) to be conveyed between NFS version 4.2 servers and metadata (IMA) to be conveyed between NFS version 4.2 servers and
clients. Integrity measurement authenticates the creator of a file's clients. Integrity measurement authenticates the creator of a file's
content and helps guarantee the content's integrity end-to-end from content and helps guarantee the content's integrity end-to-end from
creation to use. creation to use.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 2, 2020. This Internet-Draft will expire on October 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 8, line 33 skipping to change at page 8, line 33
/// ///
/// const FATTR4_IMA = XXX; /* to be assigned */ /// const FATTR4_IMA = XXX; /* to be assigned */
/// ///
/// %/* /// %/*
/// % *New value added to enum nfsstat4 /// % *New value added to enum nfsstat4
/// % */ /// % */
/// const NFS4ERR_INTEGRITY = YYYYY; /* to be assigned */ /// const NFS4ERR_INTEGRITY = YYYYY; /* to be assigned */
<CODE ENDS> <CODE ENDS>
RFC Editor: In this document, please replace XXX with the FATTR4
number assigned by the NFSV4 WG, and replace YYYYY with the NFS4ERR
code point assigned by the NFSV4 WG.
4.1.1. NFS4ERR_INTEGRITY (Error Code YYYYY) 4.1.1. NFS4ERR_INTEGRITY (Error Code YYYYY)
The server rejected this request because a data or metadata integrity The server rejected this request because a data or metadata integrity
check failed during its execution. check failed during its execution.
4.2. Detecting support for IMA Metadata 4.2. Detecting support for IMA Metadata
An NFS version 4.2 client discovers support for IMA metadata on an An NFS version 4.2 client discovers support for IMA metadata on an
NFS version 4.2 server by sending an NFS GETATTR operation that NFS version 4.2 server by sending an NFS GETATTR operation that
specifies the FATTR4_SUPPORTED_ATTRS attribute and the FATTR4_IMA specifies the FATTR4_SUPPORTED_ATTRS attribute and the FATTR4_IMA
skipping to change at page 14, line 42 skipping to change at page 14, line 42
If an appraisal failure occurs during a remote access, a If an appraisal failure occurs during a remote access, a
participating server responds to a legacy client with NFS4ERR_ACCESS. participating server responds to a legacy client with NFS4ERR_ACCESS.
The server's local policy decides exactly what a participating client The server's local policy decides exactly what a participating client
sees: Possibilities include an NFS4ERR_INTEGRITY response (and access sees: Possibilities include an NFS4ERR_INTEGRITY response (and access
to the file is denied), or access to the file content and IMA to the file is denied), or access to the file content and IMA
metadata may be permitted so that the client's own IMA policies can metadata may be permitted so that the client's own IMA policies can
be applied. be applied.
6. Implementation Status 6. Implementation Status
RFC Editor: Please remove this section and the reference to RFC 7942
before this document is published.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. RFCs.
Please note that the listing of any individual implementation here Please note that the listing of any individual implementation here
does not imply endorsement by the IETF. Furthermore, no effort has does not imply endorsement by the IETF. Furthermore, no effort has
been spent to verify the information presented here that was supplied been spent to verify the information presented here that was supplied
skipping to change at page 15, line 26 skipping to change at page 15, line 31
Coverage: The bulk of this specification is implemented. Coverage: The bulk of this specification is implemented.
Licensing: GPLv2 Licensing: GPLv2
Implementation experience: No comments from implementors. Implementation experience: No comments from implementors.
7. Security Considerations 7. Security Considerations
The design of the NFS extension described in this document assumes The design of the NFS extension described in this document assumes
that all IMA metadata is cryptographically signed to prevent unwanted that IMA metadata in transit and at rest is cryptographically signed
alteration at rest or in transit. to prevent unwanted alteration.
When IMA metadata for a file exists and the end host has an active When IMA metadata for a file exists and the end host has an active
appraiser, the content of a file is protected from creation to use. appraiser, the content of a file is protected from creation to use.
Receivers can reliably detect unintentional or malicious alteration Receivers can reliably detect unintentional or malicious alteration
of file content by verifying its content using the file's IMA of file content by verifying its content using the file's IMA
metadata. Additional protection of file content while at rest or in metadata. Additional protection of file content while at rest or in
transit on an untrusted network is unnecessary. transit on an untrusted network is unnecessary.
Likewise, receivers can also reliably detect unintentional or Likewise, receivers can also reliably detect unintentional or
malicious alteration of IMA metadata that is cryptographically malicious alteration of IMA metadata that is cryptographically
skipping to change at page 18, line 6 skipping to change at page 18, line 6
The author wishes to acknowledge review comments from Dave Noveck, The author wishes to acknowledge review comments from Dave Noveck,
Craig Everhart, and Bruce Fields which helped to make this a better Craig Everhart, and Bruce Fields which helped to make this a better
document. document.
The XDR extraction conventions were first described by the authors of The XDR extraction conventions were first described by the authors of
the NFS version 4.1 XDR specification [RFC5662]. Herbert van den the NFS version 4.1 XDR specification [RFC5662]. Herbert van den
Bergh suggested the replacement sed script used in this document. Bergh suggested the replacement sed script used in this document.
Special thanks go to Transport Area Director Magnus Westerlund, NFSV4 Special thanks go to Transport Area Director Magnus Westerlund, NFSV4
Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 Working Group Chairs Dave Noveck and Brian Pawlowski, and NFSV4
Working Group Secretary Thomas Haynes for their support. Working Group Secretary Thomas Haynes for their support.
Author's Address Author's Address
Charles Lever Charles Lever
Oracle Corporation Oracle Corporation
United States of America United States of America
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
 End of changes. 8 change blocks. 
8 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/