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

[Chris Inacio <[e-mail]>]

> On Aug 16, 2024, at 3:17 PM, Rick Macklem <[e-mail]> wrote:
> 
> Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> 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.
>  

[ci] That’s really interesting.  I’ll have to look deeper at that.  First order is that the tighter binding of user to host that allows that to work more easily?

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

[ci] We accomplish this somewhat at “the office” (Carnegie Mellon) too.  But running an AD is not something I’m (personally) up for.  I did some reading on how this works with AD being the Kerberos for the Windows machines and then possibly using sub-domains and a Unix Kerberos for non-windows machines and building the trust relationship between the two KDCs.  (You might see where this is going…)

[ci] I’m not at liberty to discuss the more specific details of how we do it at CMU because it relates to how we build our overall security posture, but I roughly know how to pull it off.

[ci] And if you’re a major enterprise or research institution, it isn’t (relatively) that massive a lift compared to the savings across needing to manage many thousands of end points of all flavors.  If I’m not mistaken, Rick, you used to live in that world too; unlike a company, central IT is fairly week in saying what can come into the enterprise – especially weak when it comes to the computer a student beings when they come to campus.  (It’s different on some of the administrative parts of the overall system.)

[ci] But you still need an expert to do it.  And it kinda makes Box look useful; even though it’s crazy to think that might be an efficient way to share data.


> rick
> 
> 

chris



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