Re: [secdir] [nfsv4] SECDIR Review of draft-ietf-nfsv4-umask-03

[Phillip Hallam-Baker <[e-mail]>]

On Wed, May 31, 2017 at 9:23 AM, David Noveck <[e-mail]> wrote:

> Phillip Hallam-Baker wrote
> > They are not so much a security plan as a collection of random thoughts
> jotted down
> > in haphazard fashion.​
>
> This is fair criticism.  I've looked through the Security Considerations
> sections of RFCs 3530, 7530, and 5661 and the differences are minor.   None
> of these sections were written to provide a security plan, but tried to
> describe, somewhat inelegantly, the evolution of NFS from its origins in a
> LAN environment towards NFSv4 which attempted to provide some reasonable
> security features.  Any security needs were provided by RPCSECGSS, and not
> by the protocol itself.
>
> > There is clearly no coherent model of what NFS security should achieve,
> what the
> > threats are, what controls are deployed to control them
>
> An alternative would have been to define an entirely new protocol with a
> real security plan covering these matters, but that wasn't the goal then.
> If it had been, we would probably have a much more secure protocol that
> nobody would deploy.  What happened was that NFSv4 was defined requiring
> implementation, but not use, of RPCSECGSS.  Even today, many NFSv4
> deployments use AUTH_SYS and very few which use RPCSECGSS, use integrity or
> privacy, because of performance issues.  Security is provided by use of
> physically isolated networks or VPNs.   That was considered adequate when
> RFCs 3530, 5661, and 7530 were written and approved.
>

​When the decisions were made performance was likely an issue. No longer.
turning on encryption has negligible impact in the HTTP world. What would
be an issue is that TLS ain't exactly designed to be NFS friendly.

​
​Protocols do wear out over time. And often it is simpler to start from
scratch than to try and extend something beyond capacity.​ ​I don't see a
need to rewrite NFS though. As a file sharing protocol it is fine. What I
would look into changing is the transport layer.

When I look at a protocol, I ask, how much of this protocol needs to
interact with other 'stuff' because that is the stuff that is really
expensive to change. In NFS, that is the parts that interact with the file
system semantics operating system drivers and all that.


​Instead of layering over UDP/TCP I would look at QUIC. Sure, you are not
using that any time soon in a standard but it is probably in a decent
enough state now to start looking at the possibilities.

Instead of using GSS which is a framework for fifty shades of almost always
password auth, I would move to authenticating and encrypting using public
key based credentials.

​What you would need to make this work is a mechanism to make management of
the public key credentials​ really simple and that just happens to be what
I am working on right now. I am pretty sure that it would suit a file
system because I am using it to support an object storage system which is
not the same thing but it is close enough. The main difference I see
between the two is that a remote file system allows you to modify remote
files while in an object system the only modification supported is to
append additional data to an append only log.
​