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

From: David Noveck <[email-masked]>
Date: Tue, 23 Nov 2021 08:55:04 -0500

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.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Tue, Nov 23, 2021 at 8:45 AM
Subject: New Version Notification for draft-dnoveck-nfsv4-security-03.txt
To: David Noveck <[email-masked]>

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

---

From: Rick Macklem <[email-masked]>
Date: Tue, 23 Nov 2021 23:08:55 +0000

On page 122, I'm guessing that one of these statements
is meant to be for "client peer"?

   *  XPCH_SVRAUTH restricts connections allowed to those that provide,
      at connection time authentication of the server peer.

   *  XPCH_CLAUTH restricts connections allowed to those that provide,
      at connection time authentication of the server peer.

rick, who is slowly working through the draft...

________________________________________
From: nfsv4 <[email-masked]> on behalf of David Noveck <[email-masked]>
Sent: Tuesday, November 23, 2021 8:55 AM
To: NFSv4; nfsv4-chairs; [email-masked]
Subject: [nfsv4] Fwd: New Version Notification for draft-dnoveck-nfsv4-security-03.txt

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to [email-masked]

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.

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, Nov 23, 2021 at 8:45 AM
Subject: New Version Notification for draft-dnoveck-nfsv4-security-03.txt
To: David Noveck <[email-masked]<mailto:[email-masked]>>

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:

The IETF Secretariat

---

From: David Noveck <[email-masked]>
Date: Wed, 24 Nov 2021 10:23:26 -0500

>       at connection time authentication of the server peer.

It is the second.  Will fix in the next draft.

> rick, who is slowly working through the draft...

Thanks.

> CAUTION: This email originated from outside of the University of Guelph.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe. If in doubt, forward suspicious emails to
> [email-masked]
>
>

---

From: [email-masked] (J. Bruce Fields)
Date: Mon, 29 Nov 2021 11:25:27 -0500

> between -02 and -03 is useful to see where the changes/additions are, if

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, and an ACL like:

	deny read to INTERACTIVE
	allow everything to EVERYONE

would require the server to allow all NFS READs.

Presumably these special identifiers are mainly only there for the
multiprotocol case--the server can actually make use of them when
accessed by an SMB client, 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.

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 could imagine server administrators wanting
the option to configure this.

I'd rather leave this unspecified.  At least, unless we can get input
from a wide range of server implementors.

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.

--b.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: [email-masked] (J. Bruce Fields)
Date: Mon, 29 Nov 2021 12:01:28 -0500

Note an xref typo on p. 64.

I'm not up for the effort to pin down mode/ACL interactions:

	- We know that two implementations (Linux and Solaris) already
	  have at least one minor irreconcileable difference.

	- We know nothing about any other implementations.  No other
	  implementors have stepped up to describe their server's
	  behavior.  Nobody's stepped up to test other implementations.
	  I strongly suspect such efforts would find more (and larger)
	  differences.

	- We know of no application that actually depends on these
	  details of how ACLs and mode interacts.  I've seen no
	  compelling reason we need this level of detail other than a
	  blanket preference for stricter over looser specification.

	- Pinning this all down and getting concensus on it is a major
	  effort.  I know I've already spent more time on this than I
	  want to.

	- This is a long complicated piece of an already long
	  complicated spec.

I'm fine with minor editorial changes.  Otherwise, if we're going to be
making substantive changes, I'm only interested in removing language.

--b.

---

From: David Noveck <[email-masked]>
Date: Tue, 30 Nov 2021 05:58:11 -0500

> would require the server to fail all NFS READs,

Yes

> would require the server to allow all NFS READs.

Yes.

> 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.

> 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.

> 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.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 30 Nov 2021 10:03:25 -0500

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

As I understand it, they do--they correspond to special identities that
can be referenced in SMB DACLs using well known SID values.

	https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/special-identities

> them.   That works for me. Not sure who it wouldn't work for.

You consistently use "client" in an unusual way which seems to mean
"everything on the other side of the protocol from the server, all the
way to the end users".

I usually think of the word "client" as referring to a more specific
piece of software (usually an operating system filesystem driver) that
(in every case I'm aware of) is a passive conduit of ACLs, and wouldn't
be a part of any decision about whether to use these special identities
or not.

If a server makes use of these special identities, I'd expect it's
because it supports SMB as well, and hence Windows SIDs, and it'd map
these special NFSv4 identifiers to the corresponding well known Windows
SIDs.

I'd guess such a server needs some subsystem that maps NFS users to SIDs
and is responsible for deciding which SIDs might belong to which of
those special groups.  I don't know how it might make such a decision,
and I think we should stay out of it.

And it sounds like we agree on that point, so sorry for sounding
argumentative....

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 30 Nov 2021 10:59:07 -0500

> On Nov 30, 2021, at 10:03, J. Bruce Fields <[email-masked]> wrote:
> 

It’s not just limited to SMB, although those mixed mode setups are probably the most common use case.

> argumentative….

Authentication and construction of the authorisation token has always been out of scope for the NFSv4 protocol.

If you authenticate to my server, e.g. using kerberos to verify your identity, my server might decide to apply the AUTHENTICATED label to the authorisation token so that these ACLs can be interpreted within that context. If it recognises your account name as being a service account, it might apply SERVICE or BATCH as well.
On the other hand, it may decide to squash your identity, and apply ANONYMOUS instead.
Or it might not apply any of those labels.

None of the above actually depends on my server using SIDs, although if it does, I'd probably do want to keep the mapping into Windows identities consistent to avoid confusing users.

Trond