Re: [nfsv4] Fwd: New Version Notification for draft-dnoveck-nfsv4-security-03.txt

On Mon, Nov 29, 2021, 11:25 AM J. Bruce Fields <bfields@fieldses.org> wrote:

> On Tue, Nov 23, 2021 at 08:55:04AM -0500, David Noveck wrote:
> > This is considerably different from -02 (1400 lines).  Still, a diff
> > between -02 and -03 is useful to see where the changes/additions are, if
> > you read -02.
>
> 5.9: special identifiers: "when ACEs containing these who values are
> encountered, the server MUST treat all requesting users as not
> matching."
>
> So a two-ACE ACL like:
>
>         allow read to INTERACTIVE
>         deny everything to EVERYONE

> would require the server to fail all NFS READs,

Yes

and an ACL like:

>         deny read to INTERACTIVE
>         allow everything to EVERYONE
>
> would require the server to allow all NFS READs.
>

Yes.

> Presumably these special identifiers are mainly only there for the
> multiprotocol case--.

I don't know what they are there for

the server can actually make use of them when
> accessed by an SMB client,

I don't see how.  I'm not sure they exist in SMB ACLs.

but we still want NFS clients to be able to
> e.g. do ACL-preserving copies, so we want NFS clients to still see them.
>

I guess so.  We appear to be stuck with them.

> So I guess it's a sensible default to treat those special identifiers as
> describing groups of which no NFS user is a member.
>
> Seems more like "a sensible default", though, rather than something to
> be enshrined in a MUST.

I get your point.  I can see how this might cause people to think of is as
control freaks.

>
I could imagine server administrators wanting
> the option to configure this.
>

Perhaps, but I can't imagine anybody bothering to write the code to
configure this and the accompanying documentation.

>
> I'd rather leave this unspecified.

I think I will make that change in -04.

At least, unless we can get input
> from a wide range of server implementors.
>

Good luck with that.

> That goes double for ANONYMOUS and AUTHENTICATED.  I don't know all the
> ways that export permissions and idmapping (like squashing) are
> implemented on different servers and I'm not sure we can reasonably come
> up with rules that will work for everyone.
>

Leaving these unspecified will mean that no sane client would ever use
them.   That works for me. Not sure who it wouldn't work for.

>
> --b.
>
> >
> > ---------- Forwarded message ---------
> > From: <internet-drafts@ietf.org>
> > Date: Tue, Nov 23, 2021 at 8:45 AM
> > Subject: New Version Notification for draft-dnoveck-nfsv4-security-03.txt
> > To: David Noveck <davenoveck@gmail.com>
> >
> >
> >
> > A new version of I-D, draft-dnoveck-nfsv4-security-03.txt
> > has been successfully submitted by David Noveck and posted to the
> > IETF repository.
> >
> > Name:           draft-dnoveck-nfsv4-security
> > Revision:       03
> > Title:          Security for the NFSv4 Protocols
> > Document date:  2021-11-23
> > Group:          Individual Submission
> > Pages:          139
> > URL:
> > https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-03.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-security/
> > Html:
> > https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-03.html
> > Htmlized:
> > https://datatracker.ietf.org/doc/html/draft-dnoveck-nfsv4-security
> > Diff:
> > https://www.ietf.org/rfcdiff?url2=draft-dnoveck-nfsv4-security-03
> >
> > Abstract:
> >    This document describes the core security features of the NFSv4
> >    family of protocols, applying to all minor versions.  The discussion
> >    includes the use of security features provided by RPC on a per-
> >    connection basis.
> >
> >    This preliminary version of the document, is intended, in large part,
> >    to result in working group discussion regarding existing NFSv4
> >    security issues and to provide a framework for addressing these
> >    issues and obtaining working group consensus regarding necessary
> >    changes.
> >
> >    When a successor document is eventually published as an RFC, it will
> >    supersede the description of security appearing in existing minor
> >    version specification documents such as RFC 7530 and RFC 8881.
> >
> >
> >
> >
> > The IETF Secretariat
>
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www.ietf.org/mailman/listinfo/nfsv4
>
>