Re: [nfsv4] Review of draft-ietf-nfsv4-integrity-measurment-01

[Chuck Lever <[e-mail]>]

> On Sep 28, 2018, at 8:58 PM, David Noveck <[e-mail]> wrote:
> 
> > > The things that we are waiting for are:
> > >       • A definition of the fornat of the provenance information.
> 
> > I don't expect the draft to ever provide a format for the provenance
> > information. 
> 
> I now understand that, but that doesn't mean that people are not waiting 
> for it.  Without  a definition of the format somwhere, implementations
> cannot be written and if implementations cannot be written, there is no 
> point in doing this.
> 
> > This information is _opaque_ to NFS, 
> 
> As I understand it, it is opaque to the server, but for there to a be client implementations
> there needs to be code written to create the provenance information and verify it and
> that ccode cannot be written without the format being known.

It is opaque to the NFS client implementation as well. There is
a security module on each system where FPI is used that reads
the FPI and determines whether to prevent access to the file's
content. It is entirely independent of the file system in which
the FPI and file content is stored.


> > and at least in IMA's case, 
> 
> As I understand things the chances of there being any other case is quite low, and I
> believe that that is your feeling as well.

> > there is no published normative specification that defines it.
> 
> Perhaps not, but one would hope that there is definition of the format somewhere.   If there isn't, how
> could implementations be developed and interoperate?
> 
> > There is no practical way to specify the format in this document.
> 
> What makes it impractical?

IMA has no specification. It has a web site and a white paper and
an implementation in Linux. I cite the web site as an Informative
reference and use IMA as an example. As far as I can tell, that's
the best that can be done.

The IMA web site and white paper state that IMA uses an HMAC.
HMAC is defined by RFC 2104, but that's an Informative document.
I cite that RFC as an Informative reference as well.

Thus I have no normative specification of the format that IMA
uses that I can use in a normative specification of an extension
to NFS.

But aside from that, the FPI format is application-specified, and
the file system does not care what that format looks like, as I
state in the new Introduction below. No file system cares what FPI
looks like.


> > I thought the point of this revision was to make that clear, but
> > reviewers have been confused on this point. 
> 
> Confused or disbelieving.
> 
> > What more can the draft do to make it clear? 
> 
> The normal function of a specfication like this is to explain how interoprating implementations can be developed.  If, as I understand to be the case, you feel that this document or some successor draft cannot do that, I think you need to clearly state that it will not do that and explain how you expect interoperating implementations to be developed.

I don't disagree with this, but I stated well before posting this
revision that I planned to remove discussion of IMA from this
document and state that the FPI format is defined elsewhere and is
self-describing. There was no objection at that time.

Now suddenly neither of those is adequate. But OK: I take the
review comments to mean I've removed too much context. I've
rewritten the Introduction to include the details about the
layering that were removed along with the IMA-specific language.
I hope this is a step toward addressing the stated concerns.


1.  Introduction

   The security of software distribution systems is complex and
   challenging, especially as software distribution has become
   increasingly decentralized.  An end administrator needs to trust that
   she is running executables just as they are supplied by a software
   vendor; in other words, that they have not been modified by malicious
   actors, contracted system administration services, or broken hardware
   or software.  Software vendors want a guarantee that customer-
   installed executables that fall under support contracts have
   similarly not been modified.

   There already exist mechanisms that protect file data during certain
   portions of a file's life cycle:

   o  Whole file system checksumming can verify so-called Golden Master
      installation media before it is used to install the software it
      contains.

   o  File or block integrity mechanisms can protect data at rest on
      storage servers.

   o  For a distributed file system such as NFS, transport layer
      security or a GSS integrity service (as described in [RFC7861])
      can protect data while it traverses a network between a storage
      server and a client.

   A more extensive mechanism is needed to guarantee that no
   modification of a particular file has occurred since it was created,
   even perhaps after several generations of copies have been made of
   the file's content.

   This guarantee can be accomplished by separately preserving a keyed
   hash, such as an HMAC [RFC2104], of a file's content.  The checksum
   and its signature are verified as the file's content is read into
   memory immediately before it is used.  If verification fails, access
   to the file's content is prevented.  The hash is updated and re-
   signed only when the file is legitimately modified.

1.1.  Architecture Basics

   A keyed hash authenticates the identity of the last modifier of a
   file's content and serves as a strong check of the content's
   integrity.  For the purposes of this document, we refer to this
   metadata using the generic term "file provenance information".

   File provenance information is generated and signed by a "provenance
   authority", and then placed in the file system using special tools.

   A security module separate from the file system stack specifies the
   format of the file provenance information and enforces a policy for
   utilizing it to determine when a protected file's content is safe to
   use on the local system.  For the purposes of this document, we refer
   to this module as a "provenance assessor", and the policy it uses as
   the "provenance assessment policy".

   NFS acts as a conduit by which file provenance information and file
   content move between storage on an NFS server and the provenance
   assessor where that content is to be accessed.  NFS peers accessing a
   set of shared files must all agree on the at-rest file provenance
   information format.  The format is specified by the provenance
   assessor and is therefore not described in this document.

   The protocol extension in this document enables the storage and use
   of file provenance information to protect files stored on an NFS
   server.  The Linux Integrity Measurement Architecture (IMA) is an
   example of a mechanism that provides a full provenance assessment
   service [IMA-WP].

   A Trusted Platform Module [TPM-SUM] can seal the key material used to
   sign and verify file content.  Distributing and protecting such key
   material is outside the scope of the OPTIONAL extension specified in
   this document.


--
Chuck Lever