[nfsv4] Fwd: SecDir Review of draft-ietf-nfsv4-labreqs

[spencer shepler <[e-mail]>]

FYI

---------- Forwarded message ----------
From: Yoav Nir <[e-mail]>
Date: Sat, Nov 2, 2013 at 5:29 AM
Subject: SecDir Review of draft-ietf-nfsv4-labreqs
To: "<[e-mail]>" <[e-mail]>, The IESG <[e-mail]>, "
[e-mail]" <
[e-mail]>


I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments ust
like any other last call comments.

Short version: I think the draft is ready.

This draft is intended to be Informational. It does not specify any
standard. Instead, it describes the operating environment and assumptions
behind labeled NFS.

Labeled NFS associates labels with resources (usually files) and processes,
where the resources reside on a file server, while the resources run on a
client. Such labels (Multi-Level Security is but one example) are then used
as a basis for policy decisions. The draft is intended for people not
familiar with NFS, and does a good job of explaining the different
scenarios. For example, with a limited server, it is up to the client to
decide about authorization for accessing resources, and the server
functions solely as a store. This model is surprising to people familiar
with, for example, web servers, where the resources are considered to
belong to the server, and it is up to the server to make authorization
decisions. Other NFS servers, called "MAC-functional" have authorization
decisions on both client and server.

I found the draft to be well-written and informative.

I have a few comments, but I consider none of them show-stoppers:

- The introduction has this text: "DAC systems offer no real protection
against malicious or flawed software due to each program running with the
full permissions of the user executing it.". Put like that, this sentence
is inflammatory. Discretionary Access Control protects you against
unauthorized users running malicious software. It just doesn't protect
against "good" users being tricked into running bad software.

- Section 3.3 uses the term "opaque". This is a surprising term,
considering this sentence about the opaque component: "The LFS component
provides a mechanism for identifying the structure and semantics of the
opaque component." So it's not really opaque, is it?  The term "opaque" is
commonly used when the data is unparseable by the participants in the
protocol. Here, the client and a MAC-functional server can parse this data
just fine.

- I think the security considerations is missing some text on what
additional security is needed in the case of a limited server that only
stores the information. Something should protect the data so that client
A's data is not served to client B, even if client B is malicious.

Yoav