Re: [nfsv4] I-D Action: draft-ietf-nfsv4-integrity-measurement-02.txt

["Everhart, Craig" <[e-mail]>]

Let's go back to the document proper.  I think it contains the fundamental disagreement.

To me, the point is to achieve interoperation.  The question is--"interoperation of what"?

There's an attractive feature that you describe: a keyed hash that's a strong check on the integrity of file content.  Suppose that I want to play, but I'm not running Linux, and/or I cannot run Linux for one reason or another.  I might even have a TPM on a client or a server.  How do the parts interrelate?  If I come up with some scheme that encodes provenance as a tree, saying how the file content is a product of many different originators (let's just say an executable file built by linker X from objects Y and Z, where each of those objects are based on a signed source file and a given compiler), how do I relate to what you're calling "provenance"?

Thinking much more simply: if IMA does what the draft says that it does, then it would be straightforward to describe exactly what it does, saying just how an HMAC is to be calculated and validated, with some description of the source of the key used in the HMAC.

This would perhaps be a more honest draft if it didn't call the blob that NFS was to store FATTR4_FILE_PROVENANCE, but just one brand of provenance encoding.  FATTR4_FILE_IMA?  That would rankle much less.  It would still suffer from all the weaknesses of not being well-defined, but at least it wouldn't appear to describe many possible "provenance" descriptions but really mean only one.

		Craig