1 |
NM* |
#1a in S
|
Outline of new approach to authetication/identification,
replacing confusion about the matter in previous
specifications.
|
2 |
NM* |
#2a in S
|
Introduction to and outline of changes needed in
negotiation framework to support provision of security by
RPC on a per-connection basis.
|
3 |
BE |
#3a in S
|
Conversion of mask bit descriptions from being about
"permissions" to being about the action permitted,
denied, or specified as being audited or generating
alarms.
|
4 |
CI |
#4a in S
|
Elimination of uses of SHOULD believed
inappropriate in .
|
5 |
BE |
#5a in S
|
Explicit inclusion of ACCESS as an operation affected in the
mask bit definitions.
|
6 |
CI |
#6a in S
#6b in S
#6c in S
|
New/revised description of the role of the "sticky bit" for
directories, both with respect to ACL handling and mode
handling.
|
7 |
BE |
#7a in S
|
Clarification of relationship between READ_DATA and EXECUTE.
|
8 |
CI |
#8a in S
|
Revised discussion of relationship between WRITE_DATA and
APPEND_DATA.
|
9 |
BC |
#9a in S
|
Clarification of how ADD_DIRECTORY relates to RENAME.
|
10 |
BC |
#10a in S
#10b in S
|
Revisions in handling of the masks WRITE_RETENTION and
WRITE_RETENTION_HOLD.
|
11 |
CI |
#11a in S
#11b in S
#11c in S
|
Explicit recommendation and requirements for mask
granularity, replacing the previous treatment which gave
the server license to ignore most of the previous section,
placing clients in an unfortunate situation.
|
12 |
BC |
#12a in S
#12b in S
|
Revised treatment of directory entry deletion.
|
13 |
BC |
#13a in
|
Attempt to put some reasonable limits on possible non-support
(or variations in the support provided) for the ACE flags.
This is to replace a situation in which the client has no real
way to deal with the freedom granted to server implementations.
|
14 |
BC |
#14a in S
|
Explicit discussion of the case in which aclsupport is
not supported.
|
15 |
BC |
#15a in S
#15b in S
#15c in S
|
Handling of the proper relationship between support for
ALLOW and DENY ACEs.
|
16 |
NM |
#16a in S
|
Discussion of coherence of acl, sacl, and dacl
attributes.
|
17 |
BC |
#17a in S
#17b in S
|
Relationship of support for ALLOW and DENY ACEs
|
18 |
BC |
#18a in S
#18b in S
|
Need for support of owner, owner_group.
|
19 |
CI |
#19a in S
|
Revised discussion of coordination of mode and the ACL-related
attributes.
|
20 |
WI |
#20 in S
|
More closely align ACL_based and mode-based semantics with
regard to SVTX.
|
21 |
BC |
#21a in S
#21b in S
#21c in S
|
Introduce the concept of reverse-slope modes and deal
properly with them. The decision as to the proper
handling is addressed as Consensus Item #28.
|
22 |
BC |
#22a in S
|
Revise treatment of divergences between AC/mode authorization
and server behavior, dividing the treatment between cases
in which something authorized is still not allowed (OK),
and those in which something not authorized is allowed
(highly problematic from a security point of view).
|
23 |
BC |
#23a in S
|
Revise discussion of client access to of ACLs.
|
24 |
BE |
#24a in S
|
Delete bogus reference.
|
25 |
CI |
#25a in S
#25b in S
#25d in S
#25e in S
#25f in S
#25g in S
|
Revised description of co-ordination of acl and mode
attributes to apply to NFSv4 as a whole. While this includes
many aspects of the shift
to be more specific about the co-ordination
requirements including addressing apparently
unmotivated uses of the terms
"SHOULD" and "SHOULD NOT",
it excludes some arguably related
matters dealt with as Consensus Items #26 and #27.
|
26 |
CI |
#26a in S
#26 in S
|
Decide how ACEs with who values other than OWNER@,
Group, or EVERYONE@ are be dealt with when setting mode.
|
27 |
CI |
#27a in S
#27b in S
#27c in S
|
Concerns the possibility of establishing one way of computing a
mode from an acl that clients can depend on, rather than two or
an unbounded number.
|
28 |
WI |
#28a in S
#28 in S
|
Decide how to address flaws in mapping to/from reverse-
slope modes.
|
29 |
BC |
#29 in S
|
Address the coordination of mode and ACL-based attributes
in unified way for all minor versions.
|
30 |
CI |
#30a in S
#30b in S
#30c in S
|
New proposed treatment of setting mode incorporating
some consequences of anticipated decisions regarding
other consensus items (#26, #28, #29)
|
31 |
WI |
#31a in S
|
Need to deal with mask bits ACE4_READ_ATTRIBUTES,
ACE4_WRITE_RETENTION, ACE4_WRITE_RETENTION_HOLD,
ACE4_READ_ACL to reflect the semantics of the mode
attribute.
|
32 |
BC |
#32a in S
#32b in S
#32c in S
#32d in S
#32e in S
|
Expanded negotiation framework to accomodate multiple
transport types and security services provided on a
per-connection basis, i.e. encryption and peer authentication.
|
33 |
BE |
#33a in S
#33b in S
#33c in S
#33d in S
#33e in S
#33f in S
#33g in S
#33h in S
|
Reorganization of description of SECINFO op to apply
to all minor versions. Assumes basics of proposal for
Item #32.
|
34 |
BC |
#34a in S
|
Revision to NFSv4.0 SECINFO implementation section to
be compatible with expanded approach to negotiation.
Assumes basics of proposals for Items #32 and #33.
|
35 |
NE |
#35a in S
|
Now has preliminary work on future security needs.
|
36 |
CI |
#36a in S
|
Threat analysis only dealing with RECOMMENDED behavior
regarding use of per-connection security facilities and
handling of AUTH_SYS.
|
37 |
CI |
#37a in S
|
Threat analysis only dealing with RECOMMENDED behavior
with regard to acl support including ACL/mode coordination.
|
38 |
CI |
#38a in S
|
Address the need to temporarily allow unsafe behavior
mistakenly allowed by previous specifications
|
39 |
CI |
#39a in S
|
Define new approach to AUTH_SYS.
|
40 |
CI |
#40a in S
#40a in S
|
Discussion of scope for security considerations and the
corresponding threat analysis.
|
41 |
CI |
#41a in S
#41b in S
#41c in S
#41d in S
|
Discuss major new security recommendations regarding
protection of data in flight and client peer authentication.
Also, covers the circumstances under which such recommendations
can be bypassed.
|
42 |
RT |
#42a in S
|
Former placeholders for threat analysis subsections have now
been superseded by new proposed subsections.
|
43 |
RT |
#43a in S
|
44 |
RT |
#44a in S
|
45 |
RT |
#45a in S
|
46 |
RT |
#46a in S
|
47 |
CI |
#47a in S
|
Dubious paragraph which should be deleted if there
are no compatibility issues that make that impossible.
|
48 |
RT |
Merged with #49.
|
Missing pieces of secinfo processing algorithm that
didn't get done in -02.
|
49 |
NE |
#49a in S
#49b in S
#49c in S
|
Secinfo processing algorithm that needs to
finished in -04.
|
50 |
BC |
#50a in S
|
Revise handling of "special" who values, making it clear
for which ones "special" is a euphemism for
"semantics-challenged".
|
51 |
BC |
#51a in S
|
Clarify the handling of the group bit for the special who
values.
|
52 |
BC |
#52a in S
#52b in S
|
Eliminate superuser semantics as it had been, as valid by
implication. Also, deal with the security consequences
of its inclusion appropriately.
|
53 |
EV |
#53a in S
|
Discussion of possible adaptation of RPCSEC_GSS/Kerberos to
multi-factor authentication.
|
54 |
EV |
#54a in S
|
Discussion of prevention of code on a compromised client
from hijacking the client machine's peer authentication.
|
55 |
EV |
#55a in S
|
Discussion of issues with potential use of Kerberos in cloud
environments
|