Subject: [Gen-art] Late Last Call + Gen-ART review of draft-ietf-nfsv4-rfc1831bis-10

From: Christian Vogt <[email-masked]>
Date: Thu, 11 Dec 2008 15:15:30 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

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?

- Christian

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Robert Thurlow <[email-masked]>
Date: Fri, 12 Dec 2008 17:42:14 -0700

> need to pay more attention to security-related aspects.

So far, protocols building on top of RPC have specified themselves
that RPCSEC_GSS is mandatory to implement.  I have added the following
wording to the security considerations to address another comment:

Standards-track RPC services MUST mandate support for RPCSEC_GSS,
and MUST mandate support for an authentication pseudo-flavor with
appropriate levels of security, depending on the need for
simple authentication, integrity a.k.a. non-repudiation, or
data privacy.

Does this address your concern as worded?  If not, we will have
to address the circular normative references issue that I'm
grappling with.

> security methods be made mandatory?

I have mentioned that I believe these have historical value only,
and I think that only AUTH_NONE, AUTH_SYS and RPCSEC_GSS are
interesting enough to be used at all by IETF protocols.  I have
added the following wording to address another comment:

AUTH_DH as mentioned in sections 8.2 and 13.4.2 is considered
obsolete and insecure; see [RFC2695].  AUTH_SYS SHOULD NOT be
used for services which permit clients to modify data.  AUTH_DH
MUST NOT be specified as RECOMMENDED or REQUIRED for any
standards-track RPC service.

Does this address your concern as worded?  If there is consensus
that we should not mention anything for historical purposes, I
can delete references to AUTH_DH and probably AUTH_SHORT.  This
is easier if we get the current auth list publically available.

Rob T