Last Call Review of draft-ietf-nfsv4-rpcsec-gssv3-13
review-ietf-nfsv4-rpcsec-gssv3-13-opsdir-lc-kuarsingh-2016-01-11-00

Dear Authors,



I have reviewed this document as part of the Operational directorate's 


ongoing effort to review all IETF documents being processed by the 


IESG.  These comments were written with the intent of improving the 


operational aspects of the IETF drafts. Comments that are not addressed 


in last call may be included in AD reviews during the IESG review.  


Document editors and WG chairs should treat these comments just like any 


other last call comments.




Document Reviewed - Remote Procedure Call (RPC) Security Version 3


Link to Document - 


https://tools.ietf.org/html/draft-ietf-nfsv4-rpcsec-gssv3-14






Summary:



This document specifies version 3 of the RPC Security protocol 


(RPCSEC_GSS).  The updated specification provides support for new 


functionality beyond RPCSEC_GSS Version 2 and 1.  This specification is 


a superset of the previous specifications.






Key additions which are included in RPCSEC_GSSv3 include: 


multi-principal authentication (client host to user principals on 


server), security label assertions for multi-level enforcement, 


structure privilege assertions and updated channel binding function.





General Comments and Feedback:



The document is well matured within the WG and had gone through a number 


of revisions.  Document progress over the last year has been minimal 


(minor changes based on review of previous versions and WG list 


discussion) and appears to be mature.






In reviewing operational considerations, there was a small Operational 


Recommendations for Deployment section, but much of the discussion 


around operational components to the updated spec is captured within the 


text (e.g. interactions with previous versions of RPCSEC_GSS) and covers 


aspects of how this updated specification would operate/inter-operate 


within existing implementations.






There are currently only minor feedback points (covered below in Textual 


Review) with a couple of comments and a question to the authors.  There 


are not apparent issues from this review which would prevent it from 


review by the IESG.  The updates appear clear, well documented and the 


update is inline with how previous updates (RPCSEC_GSSv2) were documented.





Textual Review, questions and feedback:

Section 1: Introduction and Motivation

No Updates / Items of Note

Section 1.1: Added Functionality



<< Minor NIT >>.  NO changed is absolutely needed here, it’s just being 


noted for document consistency.  The list order for how the target 


responds to unsupported items (e.g. multi-principal, auth, channel 


bindings, label assertions and structure privileges) is in a different 


order then the list higher up when highlighting the added functionality.






For consistently, perhaps the second list can be re-ordered to match the 


order of the first list (which was listed as - Security Labels, 


Structured Privileges, Multi-Principal Authentication and Channel Binding.




Section 1.2: XDR Code Extraction

No Updates / Items of Note

Section 2: The PRCSEC_GSSv3 Protocol



** Should authors noted that an implementer needs to read/understand 


RPCSEC_GSSv2 in addition to RPCSEC_GSSv3 - this is implied by text in 


this section, but perhaps it can be specifically noted ***




Section 2.1: Compatibility with RPCSEC_GSSv2

No Updates / Items of Note

Section 2.2: Version Negotiation

No Updates / Items of Note

Section 2.3: Net REPLAY Verifier



No Updates / Items of Note.  Appears previous WG feedback taken care of 


with pre-version 10 of draft.




Section 2.4: XDR Code Preliminaries

No Updates / Quick review of code fragment appears consistent / good

Section 2.5: RPCSEC_GSS_BIND_CHANNEL Operation

No Updates / Items of Note.

Section 2.6: New auth_stat Values

No Updates / Items of Note.

Section 2.7: New Control Procedures

<< Small Text Error>>


<old text> “As in RPCSEC_GSS version 1 and version 2, the RPCSEC_GSSv 


version 3”



<Suggestion> remove extra “v” after GSS

Section 2.7.1: New Control Procedure - RPCSEC_GSS_CREATE

<<Second Paragraph>>


<old text> “… and are REQUIRED be enumerated in the same order as they 


appeared in the ..”


<new text> “.. and are REQUIRED to be enumerated in the same order as 


they appeared in the .. “




Section 2.7.1.1 Multi-principal Authentication

No Updates / Items of Note.

Section 2.7.1.2: Channel Binding

No Updates / Items of Note.

Section 2.7.1.3: Label Assertions



<< Update reference >> for NFSv4.2 to Draft version 39 (sept/15) vs. 29 


(dec/14)




Section 2.7.1.4: Structured Privilege Assertions

<<Text nit>> Paragraph 3.


<old text> “If a server receives a structured privilege assertion that 


it does not recognize the assertion is..”


<new text>” If a server receives a structured privilege assertion that 


it does not recognize, the assertion is…” (add comma)




Section 2.7.2: New Control Procedure - PRCSEC_GSS_LIST

No Updates / Items of Note.

Section 2.8: Extensibility

No Updates / Items of Note.

Section 3: Operational Recommendations for Deployment

<< Question >>


- the paragraph states that RPCSEC_GSSv3 can be used “where RPCSEC_GSSv1 


or RPCSEC_GSSv2 is used”.  Would a more accurate statement not be that 


GSSv3 can be used in which GSSv2 is used, or where GSSv1 is used and 


channel bindings functionality is not needed/required?




Section 4: Security Considerations

Well written and informative.  No additional comments.