> On Dec 10, 2015, at 2:48 PM, Elwyn Davies <[email protected]> wrote: > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-nfsv4-rpcsec-gssv3-13.txt > Reviewer: Elwyn Davies > Review Date: 2015-12-09 > IETF LC End Date: 2015-12-09 > IESG Telechat date: (if known) - > > Summary: Almost Ready. There are a couple of minor issues that just poke > above the editorial/nits level. The downref issue probably needs to be > solved by incorporating the relevant descriptions from the requirements doc > (RFC 7204) into the NFS v4.2 draft and using that as the reference - the > relevant information is indeed needed by implementers to understand what is > going on in this protocol and in NFSv4.2 and referring back to the > requirements RFC is probably not a good way to go as the requirements may be > neither complete nor fully implemented, making the reference potentially > unreliable. > > Major issues: > None >
Hi I have addressed the review issues in draft-14 which I submitted. Please see inline for comments on three of the issues. > Minor issues: > s1, para 5 and s6.2: idnits points out that RFC 2401 has been obsoleted by > RFC 4301. I suspect that RFC 4301 could be referenced instead. No - RFC2401 section 8 describes Multi-level security - RFC 4301 does not.. draft-14 uses 4301 along with Bell-LaPadula, but this needs to be changed. See last comment on the Bell-LaPadula technical report. > > s1.1, first bullet and last para: ... both refer to RFC 7204 which is given > as a normative reference. This is a downref to an informational document. I > observe that (probably) the same material is referred to in [NFSv4.2] > although there it is given as informational. My personal view is that it > would be better to extract the relevant info from RFC 7204 and add it into > [NFSv4.2] which is already referenced normatively in this draft. Requiring > implementers to plough through the requirements (no section pointers are > given) that may or may not have been executed in the standards seems > undesirable. As I look at the GSSv3 use of RFC 7204, it is all informational. I moved the RFC 7204 referrence from normative to informational and give section pointers when the referrence is used in the document. I hope this clears it up. > > s2.1 and s2.5: s2.5 states that 'RPCSEC_GSS_BIND_CHANNEL MUST NOT be used on > RPCSEC_GSS version 3 handles'. This is rather more constraining than the > term 'deprecated' used in s2.1. It would seem that: > - s2.1 ought to say that RPCSEC_GSS_BIND_CHANNEL is *not supported* when > version 3 is in use. > - s2.5 ought to specify how the target should respond if a client requests a > RPCSEC_GSS_BIND_CHANNEL operation on a v3 handle. > > s2.6/s5: New auth_stat values are managed by IANA (on a first come first > served basis) [Better get your request in now if you want these numbers!] > See > http://www.iana.org/assignments/rpc-authentication-numbers/rpc-authentication-numbers.xhtml#status > and RFC 5531. The request should be documented in s5. > > Nits/editorial comments: > Abstract: s/to server/to a server/ > > s1, para 3: s/A major motivation for RPCSEC_GSSv3/A major motivation for > version 3 of RPCSEC_GSS (RPCSEC_GSSv3)/ (This expansion is currently done > later on in s1.1). > > s1, para 3: s/i.e. /i.e., / > > s1, para 5: s/ Labeled NFS (see Section 8 of [NFSv4.2])/ Labeled NFS (see > Section 9 of [NFSv4.2]) (referring to -39) It might be worth noting > explicitly that 'full-mode' is defined in s9.6.1 of [NFSv4.2] > > s1, para 5: MAC needs to be expanded (at least on account of the multiple > possible expansions!) Presumably this should be 'Mandatory Access Control > (MAC) systems (as defined in [RFC4949])' (quoting RFC7204, section 1). > > s1, para 6: s/server-side copy (see Section 3.4.1 of [NFSv4.2])/server-side > copy (see Section 4 of [NFSv4.2])/ > > s1, para 7: It might be worth explicitly mentioning s9 of [AFS-RXGK] that > introduces cache poisoning issues. > > s1.1: According to s2.7.1.2, the channel binding feature is OPTIONAL to > implement for servers. It would be useful to note this in s1.1. Similarly > labeling is OPTIONAL according to s2.7.1.3. Presumably the other features > MUST be supported by a RPSEC_GSSv3 implementation - this could also be noted. > > s2, 2nd bullet: s/that uses the child handle./that use the child handle./ > > s2.3, para 1: Need to expand MIC on first occurrence (Message Integrity Code, > I assume) > > s2.3, code fragment: s/* This code was derived from [RFC2203]./* This code > was derived from RFC 2203, RFC 5403 and RFC-to-be./ (presumably) > > > s2.3, para 2: s/except for the mtype/except that the mtype/ > > s2.4: To be absolutely clear, it would be worth adding something like: > The following code fragment replaces the corresponding preliminary code > shown in Figure 1 of [RFC5403]. > The values in the code fragment in s2.6 are additions to the auth_stat > enumeration. > Subsequent code fragments are additions to the code for version 2 that > support the new procedures > defined in version 3. > --- inserted at the head of the section. > > s2.7, last para but two: s/SHOULD associate/need to associate/ - this isn't > something that is on the wire or can be verified by the protocol. > > s2.7.1.1, para after code fragment: s/e.g. /e.g., / > > s2.7.1.1, para 3 after the code fragment: > I think that the following change is needed, firstly to make the text > comprehensible and secondly, there is no current alternative allowed for the > SHOULD and the following text indicates that an updated protocol would be > needed for other alternatives. > OLD: > The inner context handle it SHOULD use a context handle to authenticate a > user. > NEW: > For the inner context handle with RPSEC_GSSv3 it MUST use a context handle to > authenticate a user. > END > > s2.7.1.1, para 5 after the code fragment: s/is placed in/and is placed in the/ > > s2.7.1.3, para 3 after the code fragment: s/Section 12.2.2 of > [NFSv4.2]./Section 12.2.4 of [NFSv4.2]./ > > s2.7.1.3, para 6 after the code fragment: s/to different subject label/to a > different subject label/ > > s2.7.1.3, last para: > OLD: > Section 3.4.1.2. "Inter-Server Copy with RPCSEC_GSSv3" of [NFSv4.2] > NEW: > Section 4.10.1.1 "Inter-Server Copy via ONC RPC with RPCSEC_GSSv3" of > [NFSv4.2] > END > > s2.7.2, para 1 after code fragment: s/what assertions to be listed/what > assertions are to be listed/ > > s2.8: >> Other assertion types are described >> elsewhere... > Where? An example or reference would help. > > s5: There are IANA considerations... see minor issues above. > > s6.1: RFC 7204 is a downref ... see minor issues above. > > s6.2: The Bell-LaPadula technical report is one of those much cited but > almost unobtainable papers. After some ferreting I found a 'reconstruction' > via Wikipedia's article on the report at > http://www.albany.edu/acc/courses/ia/classics/belllapadula2.pdf. [Aside: In > the process of tracking down this text I came across 'A Comment on the "Basic > Security Theorem" of Bell and LaPadula' by John McLean > (http://www.albany.edu/acc/courses/ia/classics/mclean5.pdf) which has some > negative things to say about the Bell-LaPadula model.] So the Bell-LaPadula technical report referrence is not good, and RFC 2401 is old, we need a reference to describe Multi-level security. I’m no sure what is acceptable. I found a SANS Institute InfoSec Reading room paper entitled “ Multilevel Security Networks: An Explanation of the Problem” https://www.sans.org/reading-room/whitepapers/standards/multilevel-security-networks-explanation-problem-546 Any ideas for a reference? NFSv4.2 has the same issue. —>Andy > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
