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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]