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

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 21 Jan 2016 06:15:30 -0800

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

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

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

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

---

From: Tom Haynes <[email-masked]>
Date: Fri, 22 Jan 2016 16:13:18 -0800

Hi Stephen,

Thanks for the comment, responses inline

> On Jan 21, 2016, at 6:15 AM, Stephen Farrell <[email-masked]> wrote:
> 

No clue :-)

> consider re-phrasing if this isn't a common NFS term (if it

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

> copy but de-crypting before sending and then re-encrypting

Petty sure that Kerberos provides for this.

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

---

From: Chuck Lever <[email-masked]>
Date: Fri, 22 Jan 2016 16:18:08 -0800

> On Jan 22, 2016, at 4:13 PM, Tom Haynes <[email-masked]> wrote:
> 
> Hi Stephen,
> 

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

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 23 Jan 2016 15:10:03 +0000

Hi Tom,

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

> 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:-)

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

Sure, but that's not the issue.

> In a Limited Server, this is clearly not met.

That's fine.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 23 Jan 2016 13:08:40 -0500 (EST)

> and that probably would need to be documented. If not, then...

I don't know that there is much that has been said about a ~"client-side
encrypted network filesystem", i.e., it is not really clear that NFSv4
supports such a scheme at all.  In particular, the scheme would need to
specify whether the encryption key depends only on the client/user or also
on the remote server holding the encrypted data; in the latter case,
decryption/re-encryption would be needed, and I don't think the NFSv4
server-to-server copy scheme makes a provision for passing around such key
material.

In short, assuming that I am understanding the question correctly (an
encrypted filesystem built on top of NFSv4 where the data encryption is
done on the NFS client), I don't think Kerberos magically makes this work.

I don't know whether enough people are (interested in) doing this sort of
thing to make it worth adding a note that server-side copy is potentially
incompatible with it.

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 24 Jan 2016 11:13:51 +0000

Hi Ben,

> server-to-server copy scheme makes a provision for passing around such key

Right. If one were doing such an encrypted filesystem then I think
making the crypto in some way server dependent would be needed or
else the client might be vulnerable to being given /etc/passwd from
host A when it thinks it's getting it from host B.

> done on the NFS client), I don't think Kerberos magically makes this work.

Agreed.

> thing to make it worth adding a note that server-side copy is potentially

And that's also a fine answer if it's in fact the case. (Hence my
"possibly dumb question" opener:-)

S.

---

From: Tom Haynes <[email-masked]>
Date: Mon, 25 Jan 2016 15:46:49 -0800

> On Jan 23, 2016, at 7:10 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Tom,
> 

No

> so that implementers don't get it wrong.

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