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

["Mkrtchyan, Tigran" <[e-mail]>]

One option that we are currently exploring is adding OIDC tokens support to RPC.
This will play nicely with RPC-over-TLS. It should allow to pass identity tokens
to server to map with ldap or a local configuration. I am trying to define
the problem statement as an personal draft, but not that active as I wish. So, 
if general interest is there, then I will try to allocate more time to it.

— Tigran

> On 16. Aug 2024, at 23:07, Chris Inacio <[e-mail]> wrote:
> 
> 
> 
> > On Aug 16, 2024, at 4:42 PM, Chuck Lever III <[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 Aug 16, 2024, at 3:51 PM, Chris Inacio <[e-mail]> wrote:
> >>
> >>
> >>
> >>> 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?
> >
> > Rick implemented this for FreeBSD, and I have a plan to implement
> > this in Linux NFSD in a way that is hopefully compatible with his
> > implementation. It is merely a convention of adding a user identity
> > to the client certificate's SAN field; the receiving server then
> > squashes all RPC traffic from peers using that certificate to that
> > user ID.
> >
> > But I didn't mention it before because I assumed you were interested
> > in the more general multi-user case.
> >
> 
> [ci] You’re right in that I’m primarily interested in the more general use case. And I get some of the possible limitations / hiccups of the version you’re describing. (Mount at boot before user auth, etc.) If you add a field to the certificate, who and when is the signer?
> 
> [ci] It might be more interesting about the “squashes all RPC traffic” part. It seems a bit like a protocol hack, at first blush, to me. But then I don’t understand NFS that deeply, so I could be /really/ off base on that point. But even if it is, does that provide an avenue to think about how new/different auth might be achieved.
> 
> [ci] Although back to your first point, to my current understanding of NFSv4, the "right way”* is most likely API extensions in GSS. My thinking (at the moment) is that I would want to enable where auth is at today, especially if I think enterprise and things like hybrid clouds. I guess that means things like OAUTH, SCIM(?), and still kerberos (and I guess add JWT/CWT). What would make a seamless transition to accessing storage in the enterprise, being able to share to possibly local cloud compute, push up the cloud provider, extend to multi-cloud, and move back down allowing a client end point to have strong authentication and authorization across that. And for bonus points, it would be /really/ nice to be able to smoothly grow up from 3 people in a “garage” to 1000 as an enterprise, and beyond.
> 
> [ci] Free dinner on me if you and Rick have a prototype doing AA for that.
> 
> [ci] I don’t know of any pain free strong AA solutions that I would want to run in my house. I wish I could say that would be in scope - but I doubt my house compute / network is reasonable in 99% of the world's opinion.
> 
> 
> [ci] * - for some definition of right.
> 
> >
> > --
> > Chuck Lever
> 
> 
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]