IESG review: Add pseudo-flavor requirement to ADMIN Security Considerations

Sean Turner says:
> Chuck Lever says:
> > Sean Turner says:
> > > Just trying to follow the bread crumbs … The following is in RFC 5531:
> > >
> > > 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.
> >
> > I take "MUST mandate support" to mean that any new standards track protocol
> > MUST allow the use of RPCSEC_GSS (or a particular pseudo-flavor).  It does
> > not require any implementation or administrator to actually use the flavor.
> >
> > RFC 5661 appears to interpret RFC 5531 this way:
> >
> > "NFSv4.1 clients and servers MUST implement RPCSEC_GSS.  (This requirement
> > to implement is not a requirement to use.)  Other flavors, such as
> > AUTH_NONE and AUTH_SYS, MAY be implemented as well."
> >
> > And:
> >
> > "Note that being REQUIRED to implement does not mean REQUIRED to use;
> > AUTH_SYS can be used by NFSv4.1 clients and servers.  However, AUTH_SYS is
> > merely an OPTIONAL security flavor in NFSv4.1, and so interoperability via
> > AUTH_SYS is not assured."
> >
> > > In this draft: Use of RPCSEC_GSS is a MUST - so check mark in that box.
> >
> > Section 6 of the ADMIN draft says "MUST support RPCSEC_GSS" -- not "MUST
> > use RPCSEC_GSS".  But that seems to meet the RFC 5531 requirement.
> >
> > > Where's the MUST for the authentication psuedo-flavor?
> >
> > I don't see an equivalent MUST in, say, RFC 5661, though I haven't read it
> > closely.  Can you suggest some appropriate text you would like to see?
>
> I think we might be on the same page here and maybe this is just a
> specificity thing.  I agree RPCSEC_GSS is the mandatory to implement (MTI)
> and not mandatory to use (MTU) and your draft is very clear about that.
> The thing I don't see is the value for the second value required by RFC
> 5331 of a new RPC service, which is the 'pseudo' flavor.  Do you think
> rpc_gss_svc_integrity = RPCSEC_GSS data integrity?  I'm really hoping
> that's a yes and then all you'd need to do is add one sentence that says
> "The rpc_gss_svc_integrity RPCSEC_GSS service [RFC5661] MUST be supported"
> before "When RPCSEC_GSS is employed, RPCSEC_GSS data integrity SHOULD be
> used."
IESG review: Negate the use of obsolete security flavors for ADMIN protocol

Sean Turner says:
> Chuck Lever says:
> > Sean Turner says:
> > > Also any thought to MUST NOTing AUTH_SYS and AUTH_DH?
> >
> > It seems to me that RFC 5531 already covers these flavors by saying in
> > Section 14 that:
> >
> >
> > "AUTH_SYS as described in Appendix A is known to be insecure due to the
> > lack of a verifier to permit the credential to be validated.  AUTH_SYS
> > SHOULD NOT be used for services that permit clients to modify data.
> > AUTH_SYS MUST NOT be specified as RECOMMENDED or REQUIRED for any Standards
> > Track RPC service.
> >
> > AUTH_DH as mentioned in Sections 8.2 and 13.4.2 is considered obsolete and
> > insecure; see [RFC2695].  AUTH_DH SHOULD NOT be used for services that
> > permit clients to modify data.  AUTH_DH MUST NOT be specified as
> > RECOMMENDED or REQUIRED for any Standards Track RPC service."
> >
> >
> > Do we need to repeat that here?
>
> No if you add something like "the security considerations of [RFC5331]
> apply to the protocol described in this document" ;)
IESG comment: FedFS OID registry should be closed on creation

Kurt Zeilenga says:
> Chuck Lever says:
> > Barry Leiba says:
> > > -- Section 7.2 --
> > > Future allocations from the 1.3.6.1.4.1.31103.1.x range are to be
> > > assigned by IANA using the "RFC Required" policy defined in
> > > [RFC5226].
> > >
> > > First, I'd like to know what the justification is for RFC Required.
> > > There's no shortage of code points.  What harm would there be in
> > > allowing more registrations?
> >
> > I don't know why "RFC Required" is specified.  RFC 4520, for example,
> > seems to prefer "Expert Review with Specification Required" for this
> > type of registration.  I'm open to suggestions.
>
> I would prefer this registry actually be closed on creation.  Because the
> OID 1.3.6.1.4.1.31103.1 is effectively delegated to the purposes of this
> RFC-to-be.  As there is no shortage of OIDs, there's no need for some
> future specification to use OIDs from 1.3.6.1.4.1.31103.1, they can get
> some other OID for that different propose.  This is consistent with how
> LDAP OIDs are assigned presently (one OID per spec, which is delegated as
> needed within that spec, and not otherwise used).
Clean up Acknowledgements section

Chuck Lever was made editor recently, so thanking him for editing
the document is redundant credit.

Combine and simplify the credits, and recognize the contributions of
the IESG.