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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf