Subject: [Gen-art] Gen-art LC review of draft-ietf-nfsv4-rpcsec-gssv3-13

From: Elwyn Davies <[email-masked]>
Date: Thu, 10 Dec 2015 19:48:33 +0000

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

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.

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.

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.]

---

From: "Adamson, Andy" <[email-masked]>
Date: Thu, 10 Dec 2015 21:50:31 +0000

Hi Elwyn

Thanks for the review. I submitted the IANA request (IANA #884160) today. I will address the rest of the issues asap.

—>Andy

> On Dec 10, 2015, at 2:48 PM, Elwyn Davies <[email-masked]> wrote:
> 
> 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
> 
> 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.
> 
> 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.
> 
> 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:
> 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 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.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)
> 
> 
>   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.
> 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.
> 
> 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 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:
> 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.]
> 
> 
>

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 15 Dec 2015 20:13:15 +0000

> 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 f…

Hi

I have addressed the review issues in draft-14 which I submitted. Please see inline for comments on three of the 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…

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.

> 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:/…

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

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 22 Dec 2015 11:33:21 +0000

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.

There are a couple of other points below.

> 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 documen…
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'.
>> 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-authenti…
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.

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 22 Dec 2015 16:23:12 +0000

> On Dec 22, 2015, at 6:33 AM, Elwyn Davies <[email-masked]> wrote:
> 
> Hi, Andy.
> 
> 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
> Both volumes appear to have been 'electronically' reconstructed by Leonard LaPadula in 1996.  Volume II was subsequently published in the Journal of Computer Security:

> 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:
> (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.

> 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.

> 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