On Wed, Jan 4, 2023 at 12:43 PM Trond Myklebust <trondmy@xxxxxxxxxx> wrote: > > On Wed, 2023-01-04 at 14:25 +0000, Chuck Lever III wrote: > > > > > > > On Jan 3, 2023, at 11:41 PM, Trond Myklebust <trondmy@xxxxxxxxxx> > > > wrote: > > > > > > I've been thinking about how to use a public key infrastructure to > > > provide stronger authentication of multiple individual users' RPC > > > calls > > > and multiplexing them across a shared TLS connection. > > > > > > Since the client trusts the server through the TLS connection > > > authentication mechanism, and you have privacy guaranteed by that > > > TLS > > > connection, then really all you want to do is for each RPC call > > > from > > > the client to be able to prove that the caller has a specific valid > > > identity in the PKI chain of trust. > > > > > > So how about just defining a simple credential (AUTH_X509 ?) > > > containing > > > a timestamp, and a distinguished name, and have it be signed using > > > the > > > (trusted) private key of the user? Use the timestamp as the basis > > > for a > > > TTL for the credential so that the client+server don't have to keep > > > signing a new cred for each and every RPC call for that user, and > > > allow > > > the client to reuse the cred for a while as a shared secret, once > > > the > > > signature has been verified by the server. > > > > A laptop typically has a single user. The flexibility of identity > > multiplexing isn't necessary in this particular scenario. > > > > Yeah, I don't particularly care about laptop use cases. Most > enterprises set up VPNs for dealing with them because users typically > need access to more services than just a NFS server. > > I am interested in the general problem of authenticating RPC users > using certificates, since that is becoming more common due to the rise > of S3 object storage and cloud services. While AD and krb5+LDAP can be > extended into those environments too, there are plenty who choose not > to, because PKI is generally sufficient, and can be more flexible. It sounds like you want some kind of TLS channel binding (rfc 9266). However I think in general it's frowned upon to share different authentication(s) over a secure channel. Or at least it sounds to me that in rfc 9266 they are not allowing sharing of different authentications over the same TLS session. But I could be wrong. > > -- > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust@xxxxxxxxxxxxxxx > >
