RPC: Remote Procedure Call Protocol Specification Version 2
draft-ietf-nfsv4-rfc1831bis-13

[Ballot discuss]
The security portions of this protocol are not implementable from this specification or anything it normatively references. I would be looking for the draft to normative reference, or include in it, enough specification that I could implement all the options in an interoperable way. Then I would want all the normal rules for moving to Draft Standard to be considered for the added material. I have no problem with one of the Security ADs taking over this discuss if that would help reduce the of people involved with resolving the discuss.

[Ballot comment]
Christian Vogt's review:

Document..........:  draft-ietf-nfsv4-rfc1831bis-10
Reviewer..........:  Christian Vogt
Review date.......:  December 11, 2008
IESG Telechat date:  December 11, 2008


Summary: This draft is basically ready for publication, but has nits
        that should be fixed before publication.


Document draft-ietf-nfsv4-rfc1831bis-10 is an update of the "Remote
Procedure Call Protocol Specification Version 2", RFC 1831.  It seeks to
promote the RPC protocol to draft standard.  The document is overall in
good quality.

However, one aspect where I found the document to be insufficient is in
the specification of security methods.  The documents does list possible
security methods, but it neither specifies them, nor does it state a
mandatory-to-support method other than null-authentication.  I am aware
that the predecessor document, RFC 1831 also did not attend to security
methods any more carefully.  But the security-related requirements for
IETF documents have become stricter since the publication of the
predecessor document in 1995, which implies that this document would
need to pay more attention to security-related aspects.

Suggestion:  Could the list of possible security methods (alias
"security flavors") be limited to those for which there are clear
protocol specifications?  E.g., one of the possible methods, AUTH_DH,
currently refers to an academic publication rather than a protocol
specification.  That's insufficient.  And could one of the non-null
security methods be made mandatory?

[Ballot comment]
Editorial nits:
- Section 8.3, the chart isn't actually "in groups of hexadecimal
  20000000" any more (it was in 1831).
- Section 8.4.2: there's an extra blank link in middle of the 1st
  paragraph.
- The names of RPCSEC_GSS related errors don't match RFC 2203.
- Section 16 has old email address for IANA.

From Shawn Emery's SecDir review:
- s/in future/in the future/ (twice)
- s/to used on/to be used on/

[Ballot discuss]
The document should give the initial contents for the authentication
flavor registry (and this should include AUTH_KERB and all other
old/obsolete mechanisms, too). This table should probably mention that
flavors 0..3 have been also called with different names earlier
(AUTH_NULL/UNIX/SHORT/DES), and give pointers to the RFCs that
define these mechanisms.

Should the document say how new values for "auth_stat" enum are
allocated?

[Ballot discuss]
This does not seem to comply with BCP 61 (RFC 3365), which requires a
mandatory to implement authentication mechanism.  The RPCSEC_GSS
mechanism would suffice as a MITM if it were a normative reference.

[Ballot discuss]
I support Russ's and Cullen's DISCUSSes.

As noted in the warning on the front of RFC 2695,
AUTH_DH is also vulnerable to the small subgroup
attack.  AUTH_DH should probably get the same caveats
as AUTH_SYS in the security considerations section.

This document also needs to have positive rather than
negative requirements for authentication mechanisms.
Something like:

  Standards-track RPC services MUST mandate support for
  RPCSEC_GSS, and MUST mandate support for an
  authentication pseudo-flavor with appropriate levels
  of security, such as .

RPCSEC_GSS and the listed pseudo flavors need to move
from informative to normative, as well.

[Ballot discuss]
The implementation report, which can be found at
  http://www.ietf.org/IESG/Implementations/report-rfc1831.txt, raises
  a question about AUTH_DH.  It appears that only one implementation
  supports AUTH_DH.  The amount of documentation is pretty sparce,
  which may be one reason that it is not supported more widely.
  Should AUTH_DH be removed from the Draft Standard specification?

IANA Last Call comments:

IANA has questions:

- The document suggests that IANA start allocations at 0x00061a80, but
also states that previous assignments start at 0x000186a0. What about
0x00000001 - 0x0001869f? We've assumed those are reserved.

- The document suggests that a list of existing Authentication Flavors
and Pseudo-Flavors exists, but no such list is provided by value or
by reference in this document. Could you provide this list?

- In a similar vein, could you provide the allocation policy table
for the authentication flavor? How big is the number space?


Action 1:

Upon approval of this document, the IANA will create the
registry "RPC Program Numbers" at http://www.iana.org/assignments/TBD

0x00000000 Reserved
0x00000001 - 0x0001869f Reserved by previous assignments
0x000186a0 - 0x00061a7f Previous assignments
0x00061a80 - 0x1fffffff To be assigned by IANA
0x20000000 - 0x3fffffff Defined by local administrator
(some blocks assigned here)
0x40000000 - 0x5fffffff Transient
0x60000000 - 0x7effffff Reserved
0x7f000000 - 0x7fffffff Assignment outstanding
0x80000000 - 0xffffffff Reserved


Size of sub-block Assignment Method Authority
----------------- ----------------- ---------
Up to 100 numbers First Come First Served IANA
Up to 1000 numbers Specification Required IANA
More than 1000 numbers IESG Approval required IESG

Registration Procedures: Based on size of block
Initial contents of this registry will be:

< See contents of http://www.nfsv4-editor.org/rpc-numbers-1831bis.txt >


Action 2:

Upon approval of this document, the IANA will create the
registry "RPC Authentication Flavor Numbers" at
http://www.iana.org/assignments/TBD

Recent progress in RPC security has moved away from new auth flavors
as used by AUTH_DH [DH], and focused on using the existing RPCSEC_GSS
[RFC2203] flavor and inventing novel GSS-API mechanisms which can be
used with it. Even though RPCSEC_GSS is an assigned authentication
flavor, use of a new RPCSEC_GSS mechanism with NFS ([RFC1094]
[RFC1813] and [RFC3530]) will require the registration of 'pseudo-
flavors' which are used to negotiate security mechanisms in an
unambiguous way, as defined by [RFC2623]. Existing pseudo-flavors
have been granted in the decimal range 390000-390255. New pseudo-
flavor requests should be granted by IANA within this block on a
First Come First Served basis.

For non-pseudo-flavor requests, IANA should begin granting RPC
authentication flavor numbers at 400000 on a First Come First Served
basis to avoid conflicts with currently granted numbers.

For authentication flavors or RPCSEC_GSS mechanisms to be used on the
Internet, it is strongly advised that an informational or standards-
track RFC be published describing the authentication mechanism
behaviour and parameters.

Initial contents of this registry will be:

Auth Flavor Name Reference
------------ --------------------------- -----------------
0 AUTH_NONE [RFC-nfsv4-rfc1831bis-10]
1 AUTH_SYS [RFC-nfsv4-rfc1831bis-10]
2 AUTH_SHORT [RFC-nfsv4-rfc1831bis-10]
3 AUTH_DH [RFC-nfsv4-rfc1831bis-10]
6 RPCSEC_GSS [RFC-nfsv4-rfc1831bis-10]


We understand the above to be the only IANA Actions for this document.

IANA Last Call comments:

IANA has questions:

- The document suggests that IANA start allocations at 0x00061a80, but
also states that previous assignments start at 0x000186a0. What about
0x00000001 - 0x0001869f? We've assumed those are reserved.

- The document suggests that a list of existing Authentication Flavors
and Pseudo-Flavors exists, but no such list is provided by value or
by reference in this document. Could you provide this list?

- In a similar vein, could you provide the allocation policy table
for the authentication flavor? How big is the number space?


Action 1:

Upon approval of this document, the IANA will create the
registry "RPC Program Numbers" at http://www.iana.org/assignments/TBD

0x00000000 Reserved
0x00000001 - 0x0001869f Reserved by previous assignments
0x000186a0 - 0x00061a7f Previous assignments
0x00061a80 - 0x1fffffff To be assigned by IANA
0x20000000 - 0x3fffffff Defined by local administrator
(some blocks assigned here)
0x40000000 - 0x5fffffff Transient
0x60000000 - 0x7effffff Reserved
0x7f000000 - 0x7fffffff Assignment outstanding
0x80000000 - 0xffffffff Reserved


Size of sub-block Assignment Method Authority
----------------- ----------------- ---------
Up to 100 numbers First Come First Served IANA
Up to 1000 numbers Specification Required IANA
More than 1000 numbers IESG Approval required IESG

Registration Procedures: Based on size of block
Initial contents of this registry will be:

< See contents of http://www.nfsv4-editor.org/rpc-numbers-1831bis.txt >


Action 2:

Upon approval of this document, the IANA will create the
registry "RPC Authentication Flavor Numbers" at
http://www.iana.org/assignments/TBD

Recent progress in RPC security has moved away from new auth flavors
as used by AUTH_DH [DH], and focused on using the existing RPCSEC_GSS
[RFC2203] flavor and inventing novel GSS-API mechanisms which can be
used with it. Even though RPCSEC_GSS is an assigned authentication
flavor, use of a new RPCSEC_GSS mechanism with NFS ([RFC1094]
[RFC1813] and [RFC3530]) will require the registration of 'pseudo-
flavors' which are used to negotiate security mechanisms in an
unambiguous way, as defined by [RFC2623]. Existing pseudo-flavors
have been granted in the decimal range 390000-390255. New pseudo-
flavor requests should be granted by IANA within this block on a
First Come First Served basis.

For non-pseudo-flavor requests, IANA should begin granting RPC
authentication flavor numbers at 400000 on a First Come First Served
basis to avoid conflicts with currently granted numbers.

For authentication flavors or RPCSEC_GSS mechanisms to be used on the
Internet, it is strongly advised that an informational or standards-
track RFC be published describing the authentication mechanism
behaviour and parameters.

Initial contents of this registry will be:

Auth Flavor Name Reference
------------ --------------------------- -----------------
0 AUTH_NONE [RFC-nfsv4-rfc1831bis-10]
1 AUTH_SYS [RFC-nfsv4-rfc1831bis-10]
2 AUTH_SHORT [RFC-nfsv4-rfc1831bis-10]
3 AUTH_DH [RFC-nfsv4-rfc1831bis-10]
6 RPCSEC_GSS [RFC-nfsv4-rfc1831bis-10]

We understand the above to be the only IANA Actions for this
document.

(1.a) Who is the Document Shepherd For this document? Has the
Document Shepherd personally reviewed this version of the
document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

The document shepherd is Spencer Shepler. Spencer has reviewed
the documents and believes they are ready for publication.

(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

Yes. Reviews and last calls have been done at least twice with
this document. The shepherd does not have any issues with the
review; this is an update of an existing RFC and the scope of
the updates have been very limited.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

No concerns.

(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

Strong consensus is held.

(1.f) Has anyone threatened an appeal or otherwise indicated
extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met
all
formal review criteria it needs to, such as the MIB Doctor, media
type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are
not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the strategy for
their
completion? Are there normative references that are downward
references, as described in [RFC3967]? If so, list these
downward
references to support the Area Director in the Last Call
procedure
for them [RFC3967].

Yes.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document?

Yes.

If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries?

N/A

Are the IANA registries clearly identified?

Yes.

If the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations?

Yes.

Does it suggested a reasonable name for the new registry?

Yes.

If the document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

N/A

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

Yes.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document is intended to replace RFC 1831 as the
authoritative document describing RPC, without introducing
any over-the-wire protocol changes. The update includes
transition of the RPC program and authentication registries
to IANA along with appropriate rules for new entry requests.
It also provides additional discussion the the security
considerations section based on experience with strong
security flavors.

Working Group Summary

There is a long implementation history of this protocol and
the main intent of this document update is to move the RPC
RFC to Draft Standard. There has been strong support of this
within the RPC community and specifically within the working
group.

Document Quality

Given the review time, the numerous implementations in
existence and the updates that have been done, the quality of
this document is high.