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

[Tom Haynes <[e-mail]>]

> On Jan 23, 2016, at 7:10 AM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hi Tom,
> 
> On 23/01/16 00:13, Tom Haynes wrote:
>> 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
> 
> That's better (for me) yes, or just refer to rfc1832 maybe
> as Chuck suggested.
> 
>> 
>> 
>> 
>>> - 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.
> 
> Really? I'd be surprised. That probably means I didn't ask
> the question well though:-)
> 
> Does NFS have any support for an encrypted file system such
> that the long term keys protecting those files can be stored
> e.g. on a usb dongle that the user keeps?


No


> 
> If so, then I doubt server-server copy can work in such cases
> and that probably would need to be documented. If not, then...
> not:-)
> 
>>> - 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.
> 
> Sure, but that's not the issue.
> 
>> 
>> 
>>> 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.
> 
> That's fine.
> 
>> 
>> In a Full Mode implementation, a policy might exist that
>> allowed the server to let the client make such decisions.
> 
> I'm not sure what decision you mean. The issue I wanted to
> ask about relates to information leakage, not a client
> decision. Let me try as another way.
> 
> Say if a directory has N files labelled secret and one
> file labelled top-secret and a user is cleared to secret.
> Can the user use NFS to check the size of the directory
> and thus deduce the size of the top-secret file? If so,
> then I think you ought note that as a security consideration.
> If not, it'd maybe be worth saying a few words about that
> so that implementers don't get it wrong.


Do the requirements in section 3.6 of RFC 7204 address your concern?


> 
> Cheers,
> S.
> 
>>> 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.