> On Jan 5, 2016, at 11:50 AM, Elwyn Davies <elw...@dial.pipex.com> wrote: > > Apologies. I was looking at an old version, not -14.
Hi Elwyn OK. I’ll have a new version 15 out today with response to all review comments. —>Andy > > Please ignore this comment. > > Cheers, > Elwyn > > e.g., in s1 (before last para): >> [[Comment.1: RFC22203 >> states that when data integrity is used, the >> seq_num in the rpc_gss_data_t must be the same as in the credential. >> This means that using data integrity with GSS3 context's can not >> simply construct it using the parent context as the seq_num must be >> from the GSS3 context. --AA]] >> >> > > > On 04/01/2016 20:08, Adamson, Andy wrote: >>> On Jan 1, 2016, at 7:33 PM, Elwyn Davies <elw...@dial.pipex.com> >>> wrote: >>> >>> One point that I noticed when looking at the HTML version, is that there >>> are a number of comments still in the document that showed up in the HTML >>> version... Just checking that you are happy that these have been addressed >>> as theye appeared to be notes to yourself. >>> >> Hmmm. Built the html version. The only things that I see that could be seen >> as notes to myself are lines such as: >> >> • The new GSS version number [ss:vn]. >> >> where [ss:vn] is the html version of >> >> The new GSS <xref target='ss:vn'>version number</xref>. >> >> Is this what you mean? >> >> >>> I have sent some thoughts on the structured privileges in a separate email >>> copied to you and Tom. >>> >> Yep. Got it. >> >> —>Andy >> >>> Regards, >>> Elwyn >>> >>> >>> >>> On 22/12/2015 16:23, Adamson, Andy wrote: >>> >>>>> On Dec 22, 2015, at 6:33 AM, Elwyn Davies <elw...@dial.pipex.com> >>>>> 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 <elw...@dial.pipex.com> >>>>>>> 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 Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
