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