Last Call Review of draft-ietf-nfsv4-flex-files-15
review-ietf-nfsv4-flex-files-15-secdir-lc-weis-2018-01-12-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-nfsv4-flex-files-15-secdir-lc-weis-2018-01-12

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 just like any other last call comments.

This document defines the Parallel Network File System (pNFS), which allows a storage system to store the metadata for files onto a metadata server, and data of that file onto a separate storage device. The document focuses on the interaction between the two types of servers, and the requirements of clients using a pNFS system.

The document describes two models by which the metadata server and file storage server can communicate. One is a “tight coupling model”, in which the two types of servers directly communicate. In this model the metadata server can ensure that file access control state is synchronized between the two servers, and I believe that level of access control is equivalent to NFS v4.x today. From a security considerations perspective, this is perhaps best summarized in Section 2.2: 

  “With tightly coupled storage devices, the metadata server sets the
   user and group owners, mode bits, and ACL of the data file to be the
   same as the metadata file.  And the client must authenticate with the
   storage device and go through the same authorization process it would
   go through via the metadata server.”

The other model is a “loose coupling model”, in which the client is authenticated and authorized by the metadata server, and is given access to the file server through the use credentials. However, there is no direct communications between the metadata server and the file server. The metadata server does not seem to provide a fine grained access control to files on the file server, but instead relies upon the client to enforce a less granular level of access control. 

The Security Considerations section is well-written and helpful. I do have some suggestions for improving it,  and also some questions.

(1) Section 2.2: should the “recommended” in the Note be RECOMMENDED? Restricting access control to just superuser have access to the storage device seems like a valuable advice.

(2) Section 2.2: The NOTE probably should provide guidance regarding protecting the network connections between the metadata server and the file server. For example, something like: “Communications between the metadata server and file server need to secured. If there is not adequate physical security (i.e., the servers are not co-located in a physically secure area), their communications MUST be protected for confidentiality (e.g., using TLS or IPsec).”

(3) From the description of synthetic uids/gids in Section 2.2, I believe that the full range of file permissions (e.g., owner r/w/x)  is honored in the tightly coupled model, but are restricted in the loosely coupled model to “owner r/w”, “group r”. If that is correct, I think the security considerations should explicitly mention that the effect of access permissions is reduced on the file server files. 

(4) Section 2.2. In this phrase “it may be assigned some random synthetic uid/gid to deny access”, would a better word for “random” be “unused” or “unpredictable”? Also what is the security value intended by the use of a “random” value for synthetic uids/gids?

(5) In the “loose coupling model” file access actually enforced by the client, which presumably can be manipulated by an evil user. This is clearly stated n Section 2.2: “ The client is thus solely responsible for enforcing file permissions in a loosely coupled model.”  Also, Section 2.2.1 mentions “a SETATTR would be sent to the storage device to set the owner and group of the data file”, and since here is no control protocol between the metadata server and the file server so I assume it is sent by the client.  

Put another way, it seems as if any client that has credentials allowing it to access to the file server can access any file on the file system if it is chooses to do so (e.g.., if it is a malicious client). Is that correct?

Unless I’m mistaken, this is a serious reduction of actual security from NFS 4.x, and also from the tight coupling model. This should be clearly stated in the security considerations section, so that protocol adopters and users understand the additional risks of the loose coupling model. For this  reason, I've marked the review with "Has Issues" rather than "Has Nits".