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

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 2 Jun 2017 20:32:15 -0400

On Wed, May 31, 2017 at 9:23 AM, David Noveck <[email-masked]> 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.
​

---

From: Nico Williams <[email-masked]>
Date: Fri, 2 Jun 2017 20:06:02 -0500

> password auth, I would move to authenticating and encrypting using public

What are you on about??

GSS-API has a number of mechanisms, including:

 - Kerberos V5 [RFC4121]

 - PKU2U, which is PKIX based (no reference, as it's not yet
   standardized at the IETF)

 - SCRAM (password based)

and others.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Jun 2017 11:52:55 -0500

I find this much debate about a rather trivial extension that helps
NFSv4 meet the Unix security model... a bit surprising.  But onward, I
shall answer your questions.

As you'll see, the umask extension strictly *improves* security.

On Wed, May 31, 2017 at 08:59:30PM -0700, Watson Ladd wrote:
> On Wed, May 31, 2017 at 6:23 AM, David Noveck <[email-masked]> wrote:
> >> in haphazard fashion.
> >> There is clearly no coherent model of what NFS security should
> >> achieve, what the threats are, what controls are deployed to
> >> control them
> >
> How does this address the sorts of problems associated with the NFS
> permissions model? Furthermore, this candy bar network (crunchy shell
> with gooey inside) is a real liability. It would be nice if we could
> make it easier to move away from.

So... the idea is that:

 - the client establishes a "security context" that authenticates the
   user as some principal (using Kerberos, PKIX, SCRAM, whatever)

 - the server then establishes the client's UIDs/GIDs/SIDs/whatever is
   appropriate (if anything) on the server side -- let's call this the
   "authorization context"

 - subsequent RPCs for that user are made with that security context,
   thus identifying the user to the server

The server then authorizes calls as follows:

 - validates the request (see RPCSEC_GSS)

 - maps the security context ID to the authorization context for that
   security context

 - evaluates whatever ACLs or mode bits are associated with any files or
   directories (or other objects) the user wishes to access, and grants
   or denies access accordingly.

Now, mode bits and umask are a bit odd when used together with proper
access control lists.  However, there are ways to make them meaningful.

For example, if I chmod 0600 a file then all access bits will be removed
a) for all ACL entries (ACEs) that refer to non-owner users, b) for all
groups, c) for the "everyone" entry.  Increasing access, e.g., with
chmod 0664, is trickier, but still, there's a way to make it meaningful.

This is really important: it *is* possible to make mode bit changes
meaningful with ACLs.

A umask basically says "determine the ACL of new files/directories by
first adding the inheritable ACEs as usual, then applying the umask to
decrease or increase access as by a chmod, and do all of this
atomically".

The atomicity is the important part, because otherwise a client might
create a file that initially starts out as having a broad (inherited!)
ACL, and then decrease access via a second operation (possibly in the
same RPC, but RPCs are not atomic), thus creating a race condition when
trying to create files with more restrictive ACLs.

Clearly, the umask very much improves security.  It is rather shocking
that NFSv4 didn't have it to begin with.

We figured out the correct way to a) construct apparent mode bits from
ACLs, and b) apply mode bits changes to ACLs, years ago after many
dissatisfying attempts.  I don't think that is at all codified in any
RFC (but I don't follow NFSv4 that closely, so I may be wrong).  Perhaps
it should be, even though experimenting with various different
algorithms was made possible by... not specifying it in the first place
-- the state of the art here seems mature.

> > If it is appropriate to move the goal posts here, based on current needs, we
> > have to understand exactly what is being asked for, in order to see if
> > remediation is possible while maintaining continuity with the existing NFSv4
> > protocol and implementations.  Some possibilities:
> >
> > A clear security plan which defines the threats that NFSv4 addresses and is
> > clear about those it does not address (and so have to addressed by other
> > means).
> > A security plan plan defining the threats that NFSv4 should address, how
> > some of those are addressed by various NFSv4 minor versions, and others will
> > be by extensions to NFSv4.2 or later minor versions.
> 
> I prefer the second, but it might never happen. The first is at least
> useful (when combined with what NFSv4 could address as shown by other
> systems of similar kind)

I will admit to not knowing how comprehensively NFSv4's various base
RFCs cover the NFSv4 security model -- they are enormous RFCs.  Some
details are very much left to implementors, mainly how user/group IDs
are represented on disk, how the "authorization context" for any one
user is established, and how the implementation interfaces with other
protocols such as SMB or local POSIX access.  Leaving those details to
implementors is purposeful.

I've covered authentication and authorization (above).

I can also speak about the transport security model.  Spoilers: it's not
that good, and the first attempt to make it significantly better via
IPsec failed due to lack of implementation of RFC5660.  But it's not
exactly broken.

NFSv4's transport security protocol is woefully inefficient for
multi-user clients, but those have gone the way of the dodo.  It's
inefficient too in terms of ability to leave crypto to HW -- only IPsec
w/ RFC5660 can help here.  And even for single-user clients, it's
inefficient in that RPCSEC_GSS pre-dates AEAD functionality in GSS, so
it uses two GSS operations per-request (and two per-response) where one
should do -- i.e., it has higher overhead than it needs to.

The non-use of IPsec or TLS to protect the confidentiality (and
integrity) of all of the flows between an NFSv4 client and server means
that some traffic analysis can be done, identifying users identified to
eavesdroppers (depending on which GSS mechanism is used).  A more
complete analysis of RPCSEC_GSS should really not be done in the context
of this I-D.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Jun 2017 12:17:05 -0500

>                                                    [...].  A more

So here is that thread.

ONC RPC is... an RPC protocol.  Requests have a 32-bit (small) XID that
responses repeat.  The XID allows responses to be sent out of order, and
resembles what HTTP/2 calls channels (or whatever).

Each RPC request or response message has a header which carries said XID
and other metadata, including a field for security that RPCSEC_GSS uses
to a) identify a "security context" (explained earlier) and b) include a
MIC of metadata.  A "MIC" is a lot like a MAC, with some additional
metadata.

Each RPC request or response message also contains a payload.  The
payload is either MIC'ed (to provide only integrity protection) or
"wrapped" (to also provide integrity protection.

"MIC" and "wrap" are GSS [RFC2743] terminology.  GSS is an API and a
small amount of protocol for authenticating peers to each other.

GSS has an "initiator" (the client in the NFS case) and an "acceptor"
(the server in the NFS case).  At first the initiator and acceptor
engage in an exchange of "security context tokens" (messages) until
"security context" establishment succeeds or fail.

An established security context basically has session keys that can be
used to make/verify MICs (again, MAC-like messages), or wrap/unwrap
"wrap tokens".  Wrapping can provide either integrity protection, or
both integrity and confidentiality protection.

MIC and wrap tokens can carry things like timestamps or sequence numbers
in them that can be used to deal with out of sequence delivery and
detect replays.

All of the metadata in RPC headers goes in the clear unless the TCP
connection is further protected by IPsec or TLS or SSHv2 or whatever.
People have run NFSv4 over all of those, but there is no standard for
doing so over TLS or SSHv2 -- there is no "upgrade to TLS" feature in
NFSv4 (unless it's been added recently and I missed it).

The binding between header and payload is done, IIRC, by including the
payload MIC or wrap token in the input to the header MIC token input,
but I may be misremembering.  You can go check RFC2205 to double-check.

Wrap tokens nowadays can do "AEAD" style "encrypt some plaintext and
authenticate it and additional data", which would benefit RPCSEC_GSS.
But even so, the most efficient thing we can do is implement RFC5660 and
run NFSv4 with channel binding to IPsec.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Jun 2017 12:30:19 -0500

The biggest security problem with RPCSEC_GSS in general, and NFSv4 in
particular, is that RPC protocols like NFSv4 are generally three-party
protocols, not two-party protocols, but RPCSEC_GSS uses a two-party
security protocol (GSS) and does not compose use of it to construct a
three-party protocol.

The parties are: the client, the users on the client, and the server.

The client / user distinction is usually important and real: the client
is the OS, which does not necessarily (and usually does NOT) trust the
user.

This leads to some interesting attacks!

RPCSEC_GSSv3 adds the missing composition of GSS into a three-party
model.

Nico
--

---

From: David Noveck <[email-masked]>
Date: Tue, 6 Jun 2017 11:21:13 -0400

> A more complete analysis of RPCSEC_GSS should really not be
> done in the context of this I-D.

I agree that it should not, but it is not clear exactly what is being asked
for to
get this document into the RFC editing process.  Unlike xattrs, this
document
actually has been approved.  The state is listed as "Approved-announcement
to
be sent::Point Raised - writeup needed" so we know it has been approved but
are unclear about why this has not been announced, what exactly the point
raised
might be and how the issue/point is to be resolved.

I think the authors are entitled to a clearer treatment of these matters.

---

From: David Noveck <[email-masked]>
Date: Tue, 6 Jun 2017 11:22:20 -0400

---

From: Nico Williams <[email-masked]>
Date: Tue, 6 Jun 2017 11:00:33 -0500

On Tue, Jun 06, 2017 at 11:21:13AM -0400, David Noveck wrote:
> I agree that it should not, but it is not clear exactly what is being
> asked for to get this document into the RFC editing process.  Unlike

It's a secdir review.  It plays no official part in the publication
process.  It is merely a review meant to aid the IESG.

> xattrs, this document actually has been approved.  The state is listed
> as "Approved-announcement to be sent::Point Raised - writeup needed"
> so we know it has been approved but are unclear about why this has not
> been announced, what exactly the point raised might be and how the
> issue/point is to be resolved.

The secdir review may simply have been too late.  But it's still worth
responding to, which I have.

I took up this sub-thread because I'm familiar enough with the subject
so I can, and because I think Phillip and Watson deserve getting answers
on this even if there's no procedural need to provide them.

> I think the authors are entitled to a clearer treatment of these matters.

So are non-NFSv4 WG participants in this thread.  It's not every day you
get a free analysis of your protocol by folks like Watson.  Rejoice.

Nico
--

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 7 Jun 2017 02:08:46 -0500

Hi, David,

Speaking as the responsible AD ...

> get a free analysis of your protocol by folks like Watson.  Rejoice.

 The document is approved. We now approve documents with no Discuss ballot
positions, but can still make changes to resolve comments that arise during
IESG Evaluation, if that's appropriate.

I read Phillip's SECDIR review with interest. It does not seem to apply to
this draft, any more than to the rest of NFSv4, so I wouldn't hold up this
draft to pursue the issues Phillip raised.

Those issues do seem to be a useful input to NFSv4, as the working group
considers a charter update (after finishing quite a lot of work, and thanks
to you all for that).

Does that help?

Spencer (D)

---

From: David Noveck <[email-masked]>
Date: Wed, 7 Jun 2017 06:44:08 -0400

> Does that help?

Yes it does.  As NIco points out, implementations of this document will
help improve NFSv4 security, although the issues addressed seem to be
disjoint from the ones raised in the SECDIR review.  In any case, since
prototypes exist, I hope we will see iincreasing interoperability testing
of umask implementations,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Jun 2017 22:57:52 -0400

> considers a charter update (after finishing quite a lot of work, and thanks

That was the sense in which it was written. Its like when you take the
car in to get the tires changed and they mention it has no brakes.
Different things, yes. But something I am going to point out.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 14 Jun 2017 12:40:01 -0500

Hi, Phillip,

On Tue, Jun 13, 2017 at 9:57 PM, Phillip Hallam-Baker <[email-masked]

> car in to get the tires changed and they mention it has no brakes.

For your amusement, I was trying to install Lubuntu on an older desktop
system, and fell down the hall of mirrors of

   - "oh, it's too old to boot from USB",
   - "oh, the current 'CD images' won't fit on a 700-MB CD so you need to
   find an older release",
   - "oh, it can't create a bootable CD because XP Home didn't support
   that",
   - "oh, it has disk errors when installing from CD"

... and in the middle of all that, Mozilla popped up and said "your Mozilla
release is no longer supported on your operating system, and the oldest
release that would run on your operating system isn't supported either, so
you should upgrade your operating system".

So, I can relate to your analogy better today than I would have a week ago.

> Different things, yes. But something I am going to point out.

And thank you for that.

The NFSv4 working group has a recharter discussion on their agenda for
Prague, so your timing is perfect for them to consider their security
situation.

Spencer