Last Call Review of draft-ietf-nfsv4-rpcsec-gssv3-13

Request Review of draft-ietf-nfsv4-rpcsec-gssv3
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-01-05
Requested 2015-11-25
Authors Andy Adamson, Nicolás Williams
Draft last updated 2015-12-14
Completed reviews Genart Last Call review of -13 by Elwyn Davies (diff)
Genart Telechat review of -15 by Elwyn Davies (diff)
Secdir Telechat review of -14 by Radia Perlman (diff)
Opsdir Last Call review of -13 by Victor Kuarsingh (diff)
Assignment Reviewer Elwyn Davies 
State Completed
Review review-ietf-nfsv4-rpcsec-gssv3-13-genart-lc-davies-2015-12-14
Reviewed rev. 13 (document currently at 17)
Review result Almost Ready
Review completed: 2015-12-14


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


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:

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

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.


The inner context handle it SHOULD use a context handle to authenticate 

a user.


For the inner context handle with RPSEC_GSSv3 it MUST use a context 

handle to authenticate a user.


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:
Section  "Inter-Server Copy with RPCSEC_GSSv3" of [NFSv4.2]

Section "Inter-Server Copy via ONC RPC with RPCSEC_GSSv3" of 



s2.7.2, para 1 after code fragment: s/what assertions to be listed/what 

assertions are to be listed/


  Other assertion types are described

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

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


) which has 

some negative things to say about the Bell-LaPadula model.]