Re: Late Last Call + Gen-ART review of draft-ietf-nfsv4-rfc1831bis-10

Christian Vogt wrote:

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

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.

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

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
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf