Subject: Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)

From: Tom Haynes <[email-masked]>
Date: Mon, 2 Apr 2018 12:56:24 -0700

Hi Eric,

Kathleen has removed her “discuss” from this document (the new version was pushed,
which satisfied her need for the SecDir review.

Could you please revisit your position on this draft?

Thanks,
Tom

> On Jan 24, 2018, at 2:34 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Wed, Jan 24, 2018 at 2:32 PM, Tom Haynes <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On Jan 24, 2018, at 1:48 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-nfsv4-flex-files-15: Discuss
> >
> > 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 <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-flex-files/ <https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/>
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I concur with Kathleen's discuss. To put a finer point on it, I think the
> > security considerations section here needs to really clearly state what the
> > security properties of this design are and how they differ from existing NFS.
> > That's not true yes.
> 
> 
> Could you please clarify the last sentence?
> 
> That’s not true yet.
> 
> Or:
> 
> That’s not true, yes?
> 
> If yet, then hopefully pushing the next version will suffice.
> 
> Sorry. "yet"
>  
> 
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > - I'm a bit confused on whether the client can tell which model the server is using. I see:
> >
> >   An implementation can always be deployed as a loosely coupled model.
> >   There is however no way for a storage device to indicate over a NFS
> >   protocol that it can definitively participate in a tightly coupled
> >   model:
> >
> > But then there is a flag that you use to indicate you are tightly coupled. So I'm confused.
> >
> 
> Ah, the flag ffdv_tightly_coupled is used between the metadata server
> and the client. Not between the storage device and the metadata server.
> 
> OK. Thanks.
>  
> 
> 
> > - I note that some of your PDUs have /// in front and some do not. E.g., Section 5. Is that a bug.
> >
> 
> No, the ones with a /// are to be extracted and the other ones refer to existing fragments
> from other IDs. So for example, the one in Section 5 is referring to RFC5662.
> 
> Makes sense.
> 
> -Ekr
> 
> 
> 
> 
> > - S 2.2.
> > " Note: it is recommended to implement common access control methods at"
> >
> > Do you want RECOMMENDED.
> 
> Yes, this was pointed out by Brian Weis in the SecDir review.
> 
> 
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 10 Apr 2018 13:43:43 -0500

Hi, Eric,

> Could you please revisit your position on this draft?

I'm just following up on this one - could you take a look at whether -17
addresses your Discuss position?

Thanks,

Spencer

(diff from telechat version is
https://tools.ietf.org/rfcdiff?url1=draft-ietf-nfsv4-flex-files-15.txt&url2=draft-ietf-nfsv4-flex-files-17.txt
)

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 10 Apr 2018 16:25:47 -0700

Not entirely. I'm inferring from the following text that this draft is
supposed to have somewhat better security than typical NFS, but it's
not really clear.

   If the configuration of the storage device is such that clients can
   access the directory namespace, then the access control degrades to
   that of a typical NFS server with exports with a security flavor of
   AUTH_SYS.

On Tue, Apr 10, 2018 at 11:43 AM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> (diff from telechat version is https://tools.ietf.org/
> rfcdiff?url1=draft-ietf-nfsv4-flex-files-15.txt&url2=draft-
> ietf-nfsv4-flex-files-17.txt)
>

---

From: Tom Haynes <[email-masked]>
Date: Tue, 10 Apr 2018 17:02:07 -0700

No, it does not have better security than typical NFS, it has the same security.

The synthetic IDs control access to the files and the metadata server can
modify them to fence off a rogue client*, but in the end, the security of any
AUTH_SYS approach is limited.

* By rogue client I do not mean malicious, I mean one which had established
a connection with the metadata server, was handed a layout, and then when
the layout was recalled, took over 91s to return that layout. It is probable that
there is a network partition between the client and the metadata server and
it is unknown if there is one between the client and the storage device. The
fencing act causes the client to become aware that it needs to once again
reach out to the metadata server.

The security aspect of this version of the flex file layout type is to be as secure
as any other NFS in a data center environment.

The goal of the next version of the flex file layout type is to be as secure
as any other NFS in the WAN. I.e., kerberized connections.

> On Apr 10, 2018, at 4:25 PM, Eric Rescorla <[email-masked]> wrote:
> 
> On Tue, Apr 10, 2018 at 11:43 AM, Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Eric,
> 
> On Mon, Apr 2, 2018 at 2:56 PM, Tom Haynes <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Eric,
> 
> I'm just following up on this one - could you take a look at whether -17 addresses your Discuss position?
> 
> Thanks,
> 
> Spencer
> 
> (diff from telechat version is https://tools.ietf.org/rfcdiff?url1=draft-ietf-nfsv4-flex-files-15.txt&url2=draft-ietf-nfsv4-flex-files-17.txt <https://tools.ietf.org/rfcdiff?url1=draft-ietf-nfsv4-flex-files-15.txt&url2=draft-ietf-nfsv4-flex-files-17.txt>) 
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 10 Apr 2018 17:53:59 -0700

> No, it does not have better security than typical NFS, it has the same

OK, then I'm confused about "degrades to"  Can you help me with that?

>> (diff from telechat version is https://tools.ietf.org/rfcd
>> iff?url1=draft-ietf-nfsv4-flex-files-15.txt&url2=draft-ietf-
>> nfsv4-flex-files-17.txt)
>>
>
>
>

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 10 Apr 2018 21:20:32 -0700

Hi Eric,

You are asking good questions, they illustrate how the community is too close to
the problem.

In the fourth paragraph of Section 15, there is the recommended case:
  
   The combination of file handle, synthetic uid, and gid in the layout
   are the way that the metadata server enforces access control to the
   data server.  The directory namespace on the storage device SHOULD
   only be accessible to the metadata server and not the clients. 
….

In that context, the client has no access to the storage device’s namespace,
and as such, cannot easily do a READDIR or LOOKUP for traversing.
It can snoop the file handles going to the storage device, but unlike a
normal server, the credentials can change underneath the client. I.e.,
they are not controlled by an app, but by the metadata server.

If we allow access to the directory namespace, as suggested by paragraph 5:

   If the configuration of the storage device is such that clients can
   access the directory namespace, then the access control degrades to
   that of a typical NFS server with exports with a security flavor of
   AUTH_SYS.  Any client which is allowed access can forge credentials
   to access any data file.  The caveat is that the rogue client might
   have no knowledge of the data file's type or position in the metadata
   directory namespace.

then we “degrade” the security back to that faced by a normal server.

The point isn’t that flex file is more secure, but that by taking care of
how exports are managed on the storage devices, admins can do a bit
better than awful.

Hope this explains it.

Thanks,
Tom

> On Apr 10, 2018, at 5:53 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Apr 10, 2018 at 5:02 PM, Tom Haynes <[email-masked] <mailto:[email-masked]>> wrote:
>> On Apr 10, 2018, at 4:25 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 11 Apr 2018 09:14:55 -0500

Hi, Dear Authors,

> You are asking good questions, they illustrate how the community is too

That can happen with NFSv4, through no fault of that community!

> how exports are managed on the storage devices, admins can do a bit

When I see authors explaining something about existing text (in any
document), I usually think that it would be helpful to propose text that
would provide the same insights to future readers. At a minimum, that's
what Eric would be looking at, in considering his ballot position, rather
than email threads that other readers wouldn't have access to.

Do you folks know what such proposed text would look like?

And thanks to all involved, in moving this conversation forward.

Spencer (D)

---

From: Tom Haynes <[email-masked]>
Date: Wed, 11 Apr 2018 10:38:27 -0700

So actually, after thinking about, the discussion about securing the namespace on
the storage device is wrong.

The current text is:

   The combination of file handle, synthetic uid, and gid in the layout
   are the way that the metadata server enforces access control to the
   data server.  The directory namespace on the storage device SHOULD
   only be accessible to the metadata server and not the clients.  In
   that case, the client only has access to file handles of file objects
   and not directory objects.  Thus, given a file handle in a layout, it
   is not possible to guess the parent directory file handle.  Further,
   as the data file permissions only allow the given synthetic uid read/
   write permission and the given synthetic gid read permission, knowing
   the synthetic ids of one file does not necessarily allow access to
   any other data file on the storage device.

   The metadata server can also deny access at any time by fencing the
   data file, which means changing the synthetic ids.  In turn, that
   forces the client to return its current layout and get a new layout
   if it wants to continue IO to the data file.

My replacement would be:

   The combination of file handle, synthetic uid, and gid in the layout
   are the way that the metadata server enforces access control to the
   data server.  The client only has access to file handles of file
   objects and not directory objects.  Thus, given a file handle in a
   layout, it is not possible to guess the parent directory file handle.
   Further, as the data file permissions only allow the given synthetic
   uid read/write permission and the given synthetic gid read
   permission, knowing the synthetic ids of one file does not
   necessarily allow access to any other data file on the storage
   device.

   The metadata server can also deny access at any time by fencing the
   data file, which means changing the synthetic ids.  In turn, that
   forces the client to return its current layout and get a new layout
   if it wants to continue IO to the data file.

> On Apr 11, 2018, at 7:14 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Dear Authors,
> 
> On Tue, Apr 10, 2018 at 11:20 PM, Thomas Haynes <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Eric,
> 
> When I see authors explaining something about existing text (in any document), I usually think that it would be helpful to propose text that would provide the same insights to future readers. At a minimum, that's what Eric would be looking at, in considering his ballot position, rather than email threads that other readers wouldn't have access to.
> 
>> On Apr 10, 2018, at 5:53 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 11 Apr 2018 13:08:08 -0500

Hi, Tom,

>    if it wants to continue IO to the data file.

Thanks for proposing new text here.

Spencer (S) as shepherd and WG co-chair, does this look like something that
would come as a surprise to the working group?

Spencer (D) as AD

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Apr 2018 13:52:34 -0700

Hi Tom.

This text is clear, but I fear it doesn't answer the question I asked in my
discuss: how does the security here compare to ordinary NFS and why.

-Ekr

On Wed, Apr 11, 2018 at 11:08 AM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> Spencer (S) as shepherd and WG co-chair, does this look like something
> that would come as a surprise to the working group?
>
> Spencer (D) as AD
>

---

From: Tom Haynes <[email-masked]>
Date: Wed, 11 Apr 2018 14:25:38 -0700

Hi Eric,

It is the same. 

Section 2.2:

   It is RECOMMENDED to implement common access control methods at the
   storage device filesystem to allow only the metadata server root
   (super user) access to the storage device, and to set the owner of
   all directories holding data files to the root user.  This approach
   provides a practical model to enforce access control and fence off
   cooperative clients, but it can not protect against malicious
   clients; hence it provides a level of security equivalent to
   AUTH_SYS.  It is RECOMMENDED that the communication between the
   metadata server and storage device be secure from eavesdroppers and
   man-in-the-middle protocol tampering.  The security measure could be
   due to physical security (e.g., the servers are co-located in a
   physically secure area), from encrypted communications, or some other
   technique.

(By the way, this contradicts the original text in my first paragraph below
and is why we needed a change.)

And as for why, Section 15.1.1 discusses why RPCSEC_GSS is not
provided in this version of the Flex File Layout Type.

Thanks,
Tom

> On Apr 11, 2018, at 1:52 PM, Eric Rescorla <[email-masked]> wrote:
> 
> Hi Tom.
> 
> This text is clear, but I fear it doesn't answer the question I asked in my discuss: how does the security here compare to ordinary NFS and why.
> 
> -Ekr
> 
> 
> On Wed, Apr 11, 2018 at 11:08 AM, Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Tom,
> 
> On Wed, Apr 11, 2018 at 12:38 PM, Tom Haynes <[email-masked] <mailto:[email-masked]>> wrote:
> Spencer (S) as shepherd and WG co-chair, does this look like something that would come as a surprise to the working group?
> 
> Spencer (D) as AD
>

---

From: spencer shepler <[email-masked]>
Date: Wed, 11 Apr 2018 16:45:21 -0700

Spencer D. asked a question about working group surprise....

Given that the WG is cc'd here and IMO, Tom is addressing the questions
effectively, I think we can move forward with Tom's suggested text and ask
the WG to comment if there are any concerns.

So, WG, please express any concerns that may exist.

Thanks,
Spencer S.

On Wed, Apr 11, 2018 at 2:25 PM, Tom Haynes <[email-masked]> wrote:

> This text is clear, but I fear it doesn't answer the question I asked in
> my discuss: how does the security here compare to ordinary NFS and why.
>
> -Ekr
>
>