> On Jan 1, 2016, at 7:33 PM, Elwyn Davies <[email protected]> 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 <[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
