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

[David Noveck <[e-mail]>]

---------- Forwarded message ---------
From: David Noveck <[e-mail]>
Date: Fri, Sep 6, 2024 at 8:36 AM
Subject: Re: [nfsv4] Re: Feedback on user ID for any bis work
To: Mark Liam Brown <[e-mail]>




On Fri, Sep 6, 2024 at 7:15 AM Mark Liam Brown <[e-mail]>
wrote:

> On Fri, Aug 16, 2024 at 6: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


To have a conversation (super-brief or otherwise) at  "one of the interim
meetings", we actually have to have an interim meeting.

All jokes about Multiple Personality Disorder Aside, we need the chairs (of
which Chris is one, whatever hat he chooses to wear, if any, on any given
day) to actually schedule a meeting.   I'd like to know why these are not
happening.


> about how user identity is communicated across NFSv4, and there are 2
> options, UID/GID ‘integer's and then loosely defined ‘string’.


That's true.   The difference between rfc8881 and the current security
draft is that the numeric form is now a first-class citizen while
previously it was considered an unfortunate relic that needed to be tightly
controlled and interfere with the string which was considered the wave of
the future.

So I’ve been digging into this and I would say, most definitely, do NOT
> remove the string.


Nobody has suggested doing that and I have no intention of doing so.

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.


That's what the security draft now says.   rfc8881 suggested the string
should be used all the time but was really unclear about how the client and
server could agree on a secure mapping that they shared.


> As far as I can tell, the kerberos principal name should be the string in
> the field.


Perhaps some clarification should be added in the next draft.


> I certainly don’t yet have a full understanding about how everything is
> connected together.


What needs to be added to the spec?


> (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.)
>

I think Kerberos does that OK.  For auth_sys, it is not verified since the
server has to be trusted to a degree, and I don't see that changing in the
bis timeframe..

> > >
> > > 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".


Yes.


> So
> > I think the term "TLS" here is probably misplaced.
> >
>

Why?.  What term should we use?


> > 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.
>

If you want to do that, do that.  In any case, I don't think we will be
ready to tke on such a big
task as par of the bis.  As I said before, I am prepared to make a
provision to extend the string
in the bis and leave the actual extensions to later documents, once efforts
start in this
direction.

> >
> >
> > > 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.
>

I think we need some actions to go with these thoughts.  If not, we can
pick this
up later.  i.e. after the bis is close to submission.


> > >
> > > 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.
>
> But even auth_sys must support user@name on Windows, because Windows
> has no concept of uid/gid.


I don't understand.  If windows has no concept of uid/gid, how is it using
auth_sys?

authsys includes uids/gids in the header to identify the principal.


> The Windows NFS41 driver just sends the
> Windows domain\user converted to user@domain to the NFS server.
>

The NFS server, if it is using an fs that stores uid/gid in the inode, must
convert it to that form.  How are we assure that the client's and server's
mappings match and what does this mean for security?


>
> Mark
> --
> IT Infrastructure Consultant
> Windows, Linux
>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>