Subject: Re: [nfsv4] NFS over TLS for laptops

From: Rick Macklem <[email-masked]>
Date: Sat, 2 Jan 2021 00:27:59 +0000

>From: Benjamin Kaduk <[email-masked]> wrote:
>On Thu, Dec 31, 2020 at 04:53:04PM +0000, Rick Macklem wrote:
>> Chuck Lever wrote:
>> > Ben Kaduk wrote:
>> >>
>> >> I suspect that we can find a compromise position, yes.
>> >> The certificate still authenticates the client (not the user), and the
>> >> client uses AUTH_SYS to claim what user is performing operations.  But the
>> >> server uses the client's authenticated identity to restrict, by policy,
>> >> what user identities the client is allowed to claim via AUTH_SYS.  In the
>> >> degenerate case there is an otherName in the certificate that corresponds
>> >> to a single user and the client can only claim that one user, which looks
>> >> very similar to just authenticating the user, but we can say that the
>> >> relevant policy logic is located in the server as part of its internal
>> >> implementation choices.
>> >
>> >An NFS client might send legitimate operations as UID 0 too
>> >(e.g., lease management). Those cannot be rejected. Perhaps
>> >we need to specify that the client has to perform _all_
>> >operations as the squashed user.
>> Yes. I agree with this.
>> My current implementation simply ignores the AUTH_SYS RPC
>> credential when TLS squashing is enabled.
>
>Hmm, that may not be as robust as you want, since a certificate is allowed
>to have more than one SAN of any given type.  I think that if we do write
>up something like this we should be sure to define behavior when multiple
>names are present in the certificate.
Good point. I assumed there would only be one "user@domain" entry.
I can see a couple of alternatives for this:
1 - Only allow one and reply AUTH_ERR if there is more than one.
2 - Allow more than one, but require that they all have different
  "domain" fields. The server would use the one for the "domain"
  that the server supports. The NFS server would reply AUTH_ERR
  if none of the domain names match one the server supports.
  If the server supports more than one of the domains in the set
  of names, it could be required that the server reply AUTH_ERR
  or leave it up to the server implementor?
  This would allow the certificate to work for multiple NFS servers
  with different username domains.
Personally, I prefer #2.

As an aside, I think that an NFSv4 server can support multiple
username domains. However I am not aware of any NFSv4 server
implementations that handle more than one username domain
in Owner and Owner_Group names at this time.
Are there any?

rick

-Ben

---

From: David Noveck <[email-masked]>
Date: Sat, 2 Jan 2021 05:57:03 -0500

On Fri, Jan 1, 2021, 7:28 PM Rick Macklem <[email-masked]> wrote:

> username domains.

It's certainly allowed by the spec.  If it were not, there would be no
point in including "@domain" in each user and group name.

Howeverrr I am not aware of any NFSv4 server
> in Owner and Owner_Group names at this time.

This topic is discussed in some detail in RFC 8000. The motivation was
FedFs deployments.

Are there any?

I don't know of any.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Jan 2021 17:14:55 +0000

Hi,

I intended in the Interim to ask for a clarificaiton if any in this thread
affects the approved draft? In other words, do we need to run through a process
of getting consensus any changes to 
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/ ?

Cheers

Magnus

On Sat, 2021-01-02 at 05:57 -0500, David Noveck wrote:
> It's certainly allowed by the spec.  If it were not, there would be no point
> in including "@domain" in each user and group name.
> 
> This topic is discussed in some detail in RFC 8000. The motivation was FedFs
> deployments.
> 
> > Are there any?
> 
> I don't know of any.
> 
> > rick
> > 
> > -Ben
> > 
> >

---

From: Chuck Lever <[email-masked]>
Date: Tue, 26 Jan 2021 17:16:52 +0000

Hi Magnus-

> On Jan 26, 2021, at 12:14 PM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 

My understanding is that we will relegate the discussion of specific
NFS server policy implementations to the NFS-on-TLS specification,
in whatever subsequent document it lands in. rpc-tls will not be
affected.

--
Chuck Lever