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

[David Noveck <[e-mail]>]

I want to respond to Chris's email, although Gmail has somehow swallowed it.

At the risk of contributing to an ongoing case of multiple personality
disorder 😕,  Chris as wg member is alone on the To line,  while Chris, the
wg chair, is part of the cc list as a member of nfsv4-chairs.

I don't  have all that much to contribute to discussion of possible
authentication extensions but there are a few peripheral remarks below that
relate to Chris's email.


   - I believe Chris is right about the desirability of a discussion of
   this at a subsequent interim.  I think we need Chris wg-chair to schedule
   an interim meeting.  Not clear who would lead the discussion if Chris did
   not want to do it with his chair hat on but Chuck and Chris wg-member seem
   like likely candidates.
   - With regard to the suggestion that we might address this as part of
   the bis, I think this is not doable, given the need to bring this work to
   closure.  If the wg can quickly arrive at some likely future direction,
   there is some preparatory work that could be done as part of the bis. I'm
   thinking we might define the uid/gid string as beginning with a preparatory
   type:: and providing that future formats can be done as extensions in later
   extension documents.  The case in which there is no such type can be fixed
   as it is now: either a numeric value or name@domain.
   - It appears to me that Chris's remarks about the confused state if the
   uid/gid string might reflect an earlier  version of the security spec.  As
   a result of Chris's earlier remarks, I  took some steps to clarify this.
   If those are not adequate, we can discuss that issue at the next interim,
   assuming it can be scheduled without undue angst.





On Fri, Aug 16, 2024, 12:26 PM 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.
>
>
> > 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]
>