Skip to main content

Last Call Review of draft-ietf-nfsv4-labreqs-04
review-ietf-nfsv4-labreqs-04-secdir-lc-nir-2013-11-05-00

Request Review of draft-ietf-nfsv4-labreqs
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-11-01
Requested 2013-10-24
Authors Thomas Haynes
I-D last updated 2013-11-05
Completed reviews Genart Last Call review of -04 by Roni Even (diff)
Genart Last Call review of -04 by Roni Even (diff)
Secdir Last Call review of -04 by Yoav Nir (diff)
Opsdir Telechat review of -04 by Mehmet Ersue (diff)
Assignment Reviewer Yoav Nir
State Completed
Request Last Call review on draft-ietf-nfsv4-labreqs by Security Area Directorate Assigned
Reviewed revision 04 (document currently at 05)
Result Has nits
Completed 2013-11-05
review-ietf-nfsv4-labreqs-04-secdir-lc-nir-2013-11-05-00
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