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

[Chris Inacio <[e-mail]>]

> On Aug 17, 2024, at 3:05 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 2:07 PM 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.
> Once upon a time (over 20years ago) I recall asking "what does the domain in owner
> mean?". I think the response was something like "we are considering a new DNS record
> type for it".
> 
> Maybe this is worth visiting?
> If there was a DNS record type (similar to MX for email) that provided IP host address(es)
> for a "user domain", then clients might be able to configure themselves more easily?
> For example, suppose the IP host address in the reply had a KDC and LDAP server on it.
> --> The client could configure Kerberos and LDAP to covert between names<->numbers
>     from that.
>     --> Kerberos would still be needed, but the only work would be on the server end.
> 
[ci] We can ask the DNS folks how painful such an extension would be.  It could always be added in a TXT record more informally.

[ci] should have read this earlier, because (while it still doesn’t work); I fixed the LDAP config on my Mac and I’m getting very different behavior on the wire.  Which is good.  By the auto mounter attempting all manner of look ups in LDAP and then failing is just yet another config item, somewhere…. So I didn’t realized how critical in the process having LDAP is; I would have thought getting the Kerberos TGT would be sufficient, but I guess that doesn’t really tell you UID/GID, etc. (after I think about it.)

> Then there is the hassle of creating a Kerberos principal to be a machine credential
> for a client and creating/moving a keytab entry into the client.
> --> For this one, I think that rfc5661bis might be able to fix the problem.
>     Right now, RFC8881 specifies that SP4_MACH_CRED requires krb5i or krb5p.
>     (Understandable, since that was all there was.)
>     Now, RPC-over-TLS where the client provides a X.509 cert. during handshake (mtls)
>     should be sufficient to satisfy the requirements for SP4_MACH_CRED, I think?
>     (Then the machine principal could just be uid 0 over AUTH_SYS, since the X.509
>      cert. is the machine credential and TLS provides the on-the-wire security.)
> If you get rid of the need for a client to have a Kerberos keytab, all a client
> needs is a krb5.conf and a X.509 cert. If the krb5.conf can be created from a DNS
> "user domain" record, there is even less work.
> 
> Although I support ideas for alternatives to Kerberos for user authentication, I
> doubt they will be a lot simpler to setup/implement.
> 

[ci] that appears to be true.  Although we might be able to take advantage of DANCE (https://datatracker.ietf.org/wg/DANCE) to more TLS lifting for us at least for machine ID.

> rick
> 

> > 
> > --
> > Chuck Lever
> 
>