Re: [nfsv4] Stephen Farrell's No Objection on draft-ietf-nfsv4-minorversion2-40: (with COMMENT)

[Tom Haynes <[e-mail]>]

Hi Stephen,

Thanks for the comment, responses inline

> On Jan 21, 2016, at 6:15 AM, Stephen Farrell <[e-mail]> wrote:
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-nfsv4-minorversion2-40: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> 
> - 1.3.2: I'm just curious, feel free to ignore. Does anyone
> maintain those posix specs these days? (e.g.
> [posix_fadvise]).

No clue :-)


> 
> - 1.4: "a new arm" isn't clear to this reader, maybe
> consider re-phrasing if this isn't a common NFS term (if it
> is, that's fine)
> 


No, not a NFS term.

How about this:

   NFSv4.2, it is possible to add a new arm (i.e., a new entry in the
   union and a corresponding new field in the structure) in a subsequent
   minor version.  And it is also possible to move such an operation



> - 4.10: thanks for providing all that!
> 
> - 4.10: possibly dumb question: does this (or NFSv4) support
> what a user would perceive as an encrypting file system
> where the keys are held-by/derived from something on the
> user's machine? If so, and if the two servers involved use
> keys known at the user's machine and not by the NFS
> infrastructure then I'm not sure how this can work. IOW, if
> there's a decryption and then a re-encryption required in a
> server-server copy and if that needs any keying material
> from the client then could that ever work? Note that I'm not
> talking about securing the file during the server-server
> copy but de-crypting before sending and then re-encrypting
> before storing.

Petty sure that Kerberos provides for this.


> 
> - 9.6: Is it considered a requirement that e.g. a user
> cleared to secret cannot tell if there is anything stored
> that is of higher classification?


In Section 9.2, it states:

   o  MUST NOT expose an object to either the client or server name
      space before its security information has been bound to it.

And the definition of “bound” belongs to
the security implementation being defined.

I.e., I mean seLinux, Trusted Solaris, etc.


> If so, did anyone go
> through all NFS interfaces to check if e.g. disk or
> directory usage information could give away the fact that
> there is stuff stored that's not visible to this user?


In a Limited Server, this is clearly not met.

In a Full Mode implementation, a policy might exist that
allowed the server to let the client make such decisions.

>  I'm
> not arguing that this definitely needs to be done
> exhaustively, but maybe consider adding a caveat emptor
> sentence somewhere saying that even with MAC, it could be
> that NFS allows for some minor meta-data leakage such as the
> above.
> 
>