Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAM5tNy6nfvuqM30DwUVjTFHfewL8tSEQcyEJsSBzyWMTvDkEQw@mail.gmail.com>
 <e9fea39e926486146505c385dca50c116deb22f9.camel@kernel.org>
 <CAM5tNy7GM-5m-O2GUBwXCY=psSN2LKiE4bPPFyK=ABhObMdFCg@mail.gmail.com>
 <6ed7866da1e57a46da0108e9581242cd7f1ef2ce.camel@kernel.org>
 <FBAF6EA3-D78E-4F62-ACDB-8582973B4A93@oracle.com> <52f00169bb54c082dbffbcbf999c8096cb16d25d.camel@kernel.org>
In-Reply-To: <52f00169bb54c082dbffbcbf999c8096cb16d25d.camel@kernel.org>
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Wed, 4 Jan 2023 13:34:02 -0500
Message-ID: <CAN-5tyGFpV3s+kodEJYCQBNgXis35JC3gWTPU-9jYXJwec7YBg@mail.gmail.com>
Subject: Re: RFC:Doing a NFSv4.1/4.2 Kerberized mount without a machine credential
To:     Trond Myklebust <trondmy@kernel.org>
Cc:     Chuck Lever III <chuck.lever@oracle.com>,
        Rick Macklem <rick.macklem@gmail.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Jan 4, 2023 at 12:43 PM Trond Myklebust <trondmy@kernel.org> 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@kernel.org>
> > > 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@hammerspace.com
>
>