Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-labreqs-02.txt

From: [email-masked]
Date: Fri, 11 May 2012 16:28:15 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF.

	Title           : Requirements for Labeled NFS
	Author(s)       : Thomas Haynes
	Filename        : draft-ietf-nfsv4-labreqs-02.txt
	Pages           : 19
	Date            : 2012-05-11

   This Internet-Draft outlines high-level requirements for the
   integration of flexible Mandatory Access Control (MAC) functionality
   into NFSv4.2.  It describes the level of protections that should be
   provided over protocol components and the basic structure of the
   proposed system.  It also gives a brief explanation of what kinds of
   protections MAC systems offer.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-labreqs-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-nfsv4-labreqs-02.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-labreqs/

---

From: "Haynes, Tom" <[email-masked]>
Date: Fri, 11 May 2012 23:46:39 +0000

On 5/11/12 6:28 PM, "[email-masked]" <[email-masked]>
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories. This draft is a work item of the Network File System Version
>4 Working Group of the IETF.
>

In this version, I applied Bryce's comments about RFC 2119 and David's
concerns about us really having a third mode.

I did highlight what a MAC-Functional client has to do when it receives a
foreign label from a server. I also added that both clients and servers
must be able to detect the level of MAC functionality in the other
component. I did not describe how this is to be done in this document. I
will however take the passage I quoted to Bryce from the NFSv4.2 draft and
expand it there.

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

---

From: <[email-masked]>
Date: Mon, 14 May 2012 19:51:23 -0400

Good start on Limited Server Mode, but ...

[1] There needs to be a 3.7.* subsection on Limited Server Mode.  I think
it's mostly the following paragraphs:

   The client MUST apply its own policy to remotely located objects,
   using security labels for the objects obtained from the server.  It
   MUST be possible to configure the maximum length of time a client may
   cache state regarding remote labels before re-validating that state
   with the server.

   The server MUST recall delegation of an object if the object's
   security label changes.

   Any local security state associated with cached or delegated objects
   MUST also be flushed back to the server when any other state of the
   objects is required to be flushed back.

Although the text in 3.5.2 implies that the "MUST" in the second paragraph ought
to be a "SHOULD" for Limited Server Mode.

[2] There needs to be a Security Considerations subsection on Limited Server
Mode to warn that other means must be used to prevent clients that are not
MAC-Functional from accessing a MAC-Aware server.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Haynes, Tom
> Sent: Friday, May 11, 2012 7:47 PM
> Cc: [email-masked]
> Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-labreqs-02.txt
> 
> 
>

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 15 May 2012 00:28:17 +0000

>it's mostly the following paragraphs:

I'd almost want to change the 3.7 chapter to talk about server and client
responsibilities and not the modes. A client has the same responsibilities
regardless of whether the server is MAC-Aware or MAC-Functional.

The MAC-Functional client has to do this:

The MAC-Aware server has to do this:

>to be a "SHOULD" for Limited Server Mode.

Actually, I'd change 3.5.2 to be MUST.

And then for this, I'd be okay relaxing it to a SHOULD in case there is a
situation where a server can determine it does not have to recall.

>MAC-Functional from accessing a MAC-Aware server.

I've struggled with this, I wanted to add it, but in my mind, this covers
the concern:

5.  Security Considerations

5.1.  Guest Modes

   When either the client or server is operating in guest mode it is
   important to realize that one side is not enforcing MAC protections.
   Alternate methods are being used to handle the lack of MAC support
   and care should be taken to identify and mitigate threats from
   possible tampering outside of these methods.

We could change the title of Section 5.1, but I think this covers it all.

---

From: <[email-masked]>
Date: Tue, 15 May 2012 09:01:29 -0400

Tom,

> Actually, I'd change 3.5.2 to be MUST.

I agree.

>    possible tampering outside of these methods.

That text is useful, as it effectively warns the client to be careful about trusting the server, which also applies to Guest Mode with MAC-Functional clients and an ordinary server.  The additional security consideration that I would like to see discussed for Limited Server Mode is what SHOULD be done to enable the clients to trust the labels on the server.  That tends to involve overall configuration of the environment, not just considerations about individual clients and servers.

Thanks,
--David

> From: Haynes, Tom [mailto:[email-masked]]
> Sent: Monday, May 14, 2012 8:28 PM
> To: Black, David
> Cc: [email-masked]

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 17 May 2012 18:44:10 -0700

> That text is useful, as it effectively warns the client to be careful about trusting the server, which also applies to Guest Mode with MAC-Functional clients and an ordinary server.  The additional…

Okay, you basically want the same thing as Bryce and Nico are suggestiing.
Stealing from Nico's reply, here is the new Section 5.1, with the old becoming
Section 5.2:

5.1.  Trust Needed for a Community

   Labeled NFS is a transport mechanism for labels, a storage
   requirement for labels, and a definition of how to interpret labels.
   It defines the responsibilities of the client and the server in the
   various permutations of being MAC-Functional.  It does not however
   dictate in any manner whether assumptions can be made about other
   entities in the relationship.  For example, it does not define
   whether a MAC-Functional client can demand that a MAC-Aware server
   only accept requests from other MAC-Functional clients.  That is a
   policy based in a MAC model and this document does not impose
   policies on systems.

   As the requirement is a policy, it can be met with the use of a MAC
   model.  Let L be a LFS which implements the Limited Server mode,
   i.e., a MAC-Aware server connected to MAC-Functional clients.  Then a
   new LFS L' can be created which has the additional policy that the
   MAC-Aware server MUST not accept any requests from a non-MAC-
   Functional client.

5.2.  Guest Modes

-- 
[email-masked], ex-cfb

---

From: <[email-masked]>
Date: Thu, 17 May 2012 21:58:12 -0400

This statement "SHOULD be done to enable the clients to trust the labels on the server"
Made me think that we need some error case when the label is corrupted or the server is supporting labels but it is malicious. Do we need such an error. Or at least some language about the trust assumptions?

/Sorin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Haynes, Tom
Sent: Thursday, May 17, 2012 9:44 PM
To: Black, David
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-labreqs-02.txt

5.2.  Guest Modes

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 May 2012 21:42:09 -0500

> Made me think that we need some error case when the label is corrupted or the server is supporting labels but it is malicious. Do we need such an error. Or at least some language about the trust as…

How can the client determine whether there's corruption on the server
side?  How can the client determine that the server is NOT malicious?
The client can only apply local policy.   Local policy might actually
be distributed, but the application is local.  The server has exactly
the same problems.  How can the server know that a client is properly
configured?  The server can't.  The server can only... apply policy.

I don't think we (this WG) should be in the business of defining
*that* policy mechanism (and policy distribution) that allows the
client and server to decide whether they can do business with each
other, not at this time.

Nico
--

---

From: "Haynes, Tom" <[email-masked]>
Date: Fri, 18 May 2012 05:55:13 +0000

On May 17, 2012, at 6:58 PM, "[email-masked]" <[email-masked]> wrote:

> Made me think that we need some error case when the label is corrupted

NFS4ERR_BADLABEL

> or the server is supporting labels but it is malicious. Do we need such an error.

If it is malicious, why would it return an error to alert the client it was tricking?

And such a decision is a policy and out of scope.

> Or at least some language about the trust assumptions?

The definition of MAC model policy decision making that I have quoted several times addresses this issue.

And again, it is up to the security models to decide whether or not there is a trust violation - I.e. this is policy and out of scope.

---

From: "Haynes, Tom" <[email-masked]>
Date: Fri, 18 May 2012 06:07:52 +0000

> client and server to decide whether they can do business with each

Well said, policy decisions belong to the security model. We can provide advice on how a LFS can be designed to apply that policy, but for me the main advantages of that are:

1) reinforce that this is a policy and out of scope

2) illustrate a security concern