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

[Rick Macklem <[e-mail]>]

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.

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.

rick


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