Re: [nfsv4] NFS over TLS for laptops

On Fri, Jan 1, 2021, 7:28 PM Rick Macklem <rmacklem@uoguelph.ca> wrote:

> >From: Benjamin Kaduk <kaduk@mit.edu> 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.

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
> implementations that handle more than one username domain
> 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
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>