Re: [nfsv4] NFS over TLS for laptops

[Magnus Westerlund <[e-mail]>]

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:
> 
> 
> On Fri, Jan 1, 2021, 7:28 PM Rick Macklem <[e-mail]> wrote:
> > >From: Benjamin Kaduk <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4