> On Dec 22, 2015, at 6:33 AM, Elwyn Davies <[email protected]> wrote: > > Hi, Andy. > > Thanks for the response and the updated draft. > > I think we are done with the editorial nits. > > There is a comment about the RFC 7204 issue below - and there was a separate > email suggesting negotiation with minorversion2 authors. > > The reference to the original paper on MLS seems to have got confused > somewhere. After ferreting around on the net, I believe that the report was > Mitre Technical Report MT-2547. This was originally published in two > 'volumes'. > There is a scan of the original volume I from 1973 on the Defense Technical > Information Center website at > http://www.dtic.mil/dtic/tr/fulltext/u2/770768.pdf > together with citation of Volume II but apparently no scan of the original. > > Both volumes appear to have been 'electronically' reconstructed by Leonard > LaPadula in 1996. Volume II was subsequently published in the Journal of > Computer Security: > http://content.iospress.com/articles/journal-of-computer-security/jcs4-2-3-08
> > Cheers - and Merry Christmas > Elwyn > > I haven't got free on-line access to this journal and I haven't had time to > go examine the hardcopy in the Cambridge Computer Lab, but there seems to be > a reasonable guess that the text is essentially what can be found here: > http://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf > http://www.albany.edu/acc/courses/ia/classics/belllapadula2.pdf > (along with some other foundational papers, including McLean's negative > comments on the underlying maths!) > > Tom Haynes tells me that he had the original ref from Ran Atkinson. I will > ask him whether my inferences are correct. If so the ref needs updating, > probably to include the JCS doc. OK. I’ll speak with Tom. > > There are a couple of other points below. > > On 15/12/2015 20:13, Adamson, Andy wrote: >>> 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. > That certainly fixes the downref (phew)! As you will see from the other > email I sent to Tom and the minorversion2 authors, I was wondering what extra > info is actually needed from the requirements RFC beyond what is already in > minorversion3 - I couldn't see much extra - and whether it would be possible > to add a little text to minorversion2 to cover their needs and make it > possible to remove the RFC 7204 ref from both documents. This would make > things cleaner and avoid any questions of whether the requirements draft > represents 'as implemented’. OK. I’ll work with Tom Haynes. >> >>> 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. > To be in line with usual convention I think you need to rewrite s5 so that it > gives the (relevant) information documented in Appendix B of RFC 5531 with a > rather shorter description string and pointers back to the longer > descriptions in the body of the draft. The IANA request number is transient > and is not of any interest in the final RFC. Yep. I had not heard back from IANA when draft-14 was submitted. I’ll fix this up in draft-15. Thanks again. Merry Chirstmas! —>Andy >>> >>> 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
