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

> On Jan 22, 2016, at 4:13 PM, Tom Haynes <thomas.haynes@primarydata.com> wrote:
> 
> Hi Stephen,
> 
> Thanks for the comment, responses inline
> 
>> On Jan 21, 2016, at 6:15 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> 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.

"Arm" is an XDR term defined in RFC 1832, section 3.15.

> 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.
>> 
>> 
> 
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever