[nfsv4] Re: Feedback on user ID for any bis work

[Rick Macklem <[e-mail]>]

On Fri, Aug 16, 2024 at 9:26 AM Chuck Lever III <chuck.lever=
[e-mail]> wrote:

>
>
> > On Aug 16, 2024, at 11:39 AM, Chris Inacio <[e-mail]> wrote:
> >
> > Dave, All,
> >
> > INDIVIDUAL CONTRIBUTOR HAT ON - NOT CHAIR
> >
> > We need this super brief conversation in one of the interim meetings
> about how user identity is communicated across NFSv4, and there are 2
> options, UID/GID ‘integer's and then loosely defined ‘string’.  So I’ve
> been digging into this and I would say, most definitely, do NOT remove the
> string.  So what I can see so far, is that UID/GID numbers are used when
> auth ‘sys’ is the selected mechanism, where current the string is used when
> auth is tied to GSS-API.  As far as I can tell, the kerberos principal name
> should be the string in the field.  I certainly don’t yet have a full
> understanding about how everything is connected together.  (Just sending
> the principal is nice and everything, but you want to be able to verify it,
> and HOLY RAT HOLE ROBIN is that confusing in practice.)
> >
> > So, the thing I’m trying to make sense of, how hard would it be to
> support TLS identities (X.509 certs really) instead of Kerberos.
>
> A perhaps subtle distinction here:
>
> The current RPC-with-TLS protocol uses x.509 explicitly only for
> authenticating
> network peers (ie, hosts). RFC 9289 even says "not for user
> authentication". So
> I think the term "TLS" here is probably misplaced.
>
> You instead want to invent a new RPC security flavor or flavors that
> authenticates
> users (or, dare I say it, to extend GSSAPI to handle this for us) via an
> x.509
> certificate, or OAuth, or such like. Nothing to do with transport layer
> security,
> which doesn't know from users.
>
There is the specific case Chuck named "TLS identity squashing", where
the client's X.509 cert. identifies a single user for all RPCs done
via the TLS session.

This works ok for cases where the client is just a single user, such
as a mobile device.

As for making the Windows world work, I do not have any experience,
but a site in Sweden does it by using Windows AD as the Kerberos KDC.
(Not saying it is easy, but they do seem to make it work. I can give
you his email, if you are interested in finding out more.)

rick


>
> > That also opens a fairly different control domain.  Kerberos is well
> suited to local enterprise control.  You can do that with X.509, but
> really, my anecdotal experience says, X.509 certs for enterprise are too
> heavy a lift, but they’re the answer when you want a more global identity.
> That raises the question of target users of NFS protocol.  And if we’re (or
> maybe that’s just me doing it?) opening a wound there – then maybe we want
> to be able to support authentication and authorization that is more cloud
> compatible, which is potentially more than X.509.
> >
> > These are just thoughts and feedback on some discussions.
> >
> > Chris
> >
> >
> > P.S.
> >
> > The complexity of auth is BONKERS!!!  So to kind of dig into this I have
> a freenas server running with ZFS as the backing store.  It’s the FreeBSD
> variant 13.0 stream.  I then deployed an LDAP and Kerberos solution
> (freeipa on Fedora) to have that running on an RPi4.  (This is all in my
> house, by the way.) For clients, I have a _real_ menagerie of machines: Mac
> OS 14.6, RPi Raspbian, FreeBSD, and Win 11.  For fun, that means NFS
> versions running are:  Mac OS 14.0 - NFSv4.0, Raspbian/Linux NFSv4.2,
> FreeBSD 13.x - NFSv4.1, Win 11 - NFSv3.  I can get most of the unixen to at
> least get a Kerberos user principal TGT.  Machine-to-machine, host
> principals are still a bit of a challenge.  The Windows machine seemingly
> would rather piss in my Cheerios than do what I want.  (What engineer where
> convinced their UI people to be able to give error messages as ‘1450
> resource unavailable’ and then you need to type `net helpmsg 1450` to get
> an actual error message, which is completely useless anyway?  That person
> is either my hero or the devil.) And while Windows doesn’t want to
> cooperate at all, the unixen management of authentication identities is its
> own entire disjoint universe!  ‘SSSD' on Linux, ‘nfsuserd' on FreeBSD, and
> I haven’t even tried to cross that bridge on Mac.  So I’m still trying to
> get this collection of stuff to attempt to do full kerberos/gss-api
> negotiation on a mount.
> >
> >
> > Maybe this is why people run with auth sys!
>
> No "maybe" about it, this /is/ why people stick with auth_sys.
>
>
> --
> Chuck Lever
>
>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>