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

[Stephen Farrell <[e-mail]>]

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?

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.

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.
>>
>>
> 
> 
> 
>