[nfsv4] Going forward on the security document

[David Noveck <[e-mail]>]

This message is my attempt to summarize the results of discussion of the v4
security document that occurred at the interim meeting this afternoon.

This email is  my attempt to summarize  the results of discussion of the
security document that occurred at the 2/13 Interim Wrorking Group
meeting.   This document is being done as part of the rfc5661bis effort .


Although I have tried to be accurate, it should be noted that I have made
no attempt to coordinate with others present and that others may have
different views as to what was discussed/decided.



I decided to try to simplify processing, as suggested by a number of
people, by splitting out the ACL-related material from the security
document proper .  I will then try to address the difficult issues created
when ACLs were added to NFSv4 without clear semantic requirements in a
separate document, devoted to ACLs



As a result, the next draft of the security document,
draft-dnoveck-nfsv4-security-08, will limit the discussion of acl-related
issues by treating acls as an EXPERIMENTAL feature to be described in a
separate document.



That document, initially draft-dnoveck-nfsv4-acls-00 will explain why the
experiment adopted initially in rfc3010 and propagated without major
changes to rfcs 3530, 5661, 7530, and 8881 was a failure which it does not
make sense to continue.  Instead, I will, as I proposed at the meeting,
change the focus of the focus ACL description on a simplified core
baased on the withdrawn draft POSIx ACLs with provisions for extensions of
that model that have actually.   I will be sending out in the week, a
description of ONTAP ACL support  which includes a number of such
extensions.


This approach is the reverse of the one adopted in rfc3010 and subsequent
rfcs in which ACLs including a massive set of extensions was presented as
canonical, but was supplemented by some dubious material which essentially
said "Oh by the way, if any of this inconvenient, feel free to ignore it. "


We will be needing information about actual implementations of some of the
ACL extensions discussed in existing documents and have to be prepared to
simply drop material that was never implemented.  In particular,  as far as
I know, the troublesome behavior, derived from windows acl implementation,
mentioned in the meeting in which deny ACL are scanned and effected after
all requested permissions was never described in NFSv4 and probably never
implemented.   As a result, it is likely that concern about its effect on
the specification of NFSv4 ACLs was misplaced.


There are also a number of related matters that were discussed without
resulting in any agreement.   The following uissues will need to be
addressed on the wg list and in subsequent meetings:


   - Chris I. raised what he described as a set of  problems with NFSv4's
   handling of "identity".   The ensuing discussion led me to conclude that he
   was referring to two different issues:
      - The lack of clarity about mapping between uid/gid values and the
      strings used to represent users and groups.   With regard to
this issue, I
      tend to agree with Brian P.'s point that these are properly treated as
      implementation matters.   I will try to make this clearer in forthcoming
      drafts.
      - At a later point in the discussion, it appeared that many of
      Chris's concerns were prompted by the disturbing ease with which a client
      might represent himself as a given named user.  While it is possible that
      such impersonation might be made more likely by flaws in the mappings
      between names and numeric ids, the fundamental issue here is
inherited from
      NFSv2 and NFSv3 implementations, in which AUTH_SYS is used, allowing
      unauthenticated requests to be executed, given the common use of AUTH_SYS
      and the lack of facilities for client peer authentication.

 The material in -08 will address this issue pretty much as was done in
-07, pointing out the security problem involved in use of AUTH_SYS, without
going so far forbidding its use or formally RECOMMENDING against it.
 While we may not have reached consensus on this, I don't see any obstacles
to it.

Although I feel that the shift from numeric ids to strings made between v3
and v4 was, like the inclusion of ACLs without a clear semantics model for
their use, a mistake, it is not possible for  us to undo that mistake.   I
think it will be possible to clarify the role of name mapping by not
requiring the mapping of ids to names when AUTH_SYS is used, although the
numeric ids need to (trivially) mapped to strings.  I will try to see what
can be done in that regard in -08, without crossing any red lines.


   - Tom H.  raised issues regarding potential XDR changes which he found
   troubling.   Chris agreed to post the diffs between RFC5662 and the most
   recent draft of rfc5662bis.  While Tom never wavered from his position that
   any such differences were inherently impermissible, I need to point out
   that these changes which reorganized the typedefs while keeping what is
   sent  OTW as formally opaque are analogous to the xdr changes made between
   rfc 3531 and 7531 and are not a problem.  The working group will have to
   discuss this issue further but I think consensus is achievable.
   - The repeated suggestions by Brian that the NFSv4 server could be
   defined  as an "interpreter" depending on the server fs's choice of
   semantics have never been addressed.  In my view, the working group needs
   to seriously consider this possibility and clearly reject it.  I don't
   think we can publish a purported *Proposed Standard* that leaves so much
   material unspecified, even if the IETF/IESG could somehow be convinced to
   accept it.