I have recently implemented a NFSv4.1/4.2 client mount
on FreeBSD that uses AUTH_SYS for ExchangeID, CreateSession
(and the other state maintenance operations)
using SP4_NONE and then it defers an RPC that does:
PutRootFH { Lookup, Lookup,... Lookup } GetFH
until a user process/thread attempts to use the mount.
Once an attempt succeeds, the file handle for the mount
point is filled in and the mount works normally.
This works for both a FreeBSD NFSv4 server and a Linux
5.15 one.
Why do this?
It allows a sec=krb5 mount to work without any
machine credential on the client. (Both installing
a keytab entry for a host/nfs-client.domain in the
client or doing the mount based on a user principal's
TGT are bothersome.) The first user with a valid TGT
that attempts to access the mount completes the mount's
setup.
I envision that this will be used along with RPC-with-TLS
(which can provide both on-the-wire encryption and
peer authentication). The seems to be a reasonable
alternative to a machine credential and a requirement
for RPCSEC_GSS integrity or privacy.
Why am I posting here?
I am wondering if the Linux client implementors are
interested in doing the same thing?
I think it is possible to extend NFSv4.2 with a new
enum state_protect_how4 value (SP4_PEER_AUTH?) that
would allow the client to specify what operations must
use RPC-with-TLS including peer authentication and which
must be allowed for this case (similar to SP4_MECH_CRED).
However, if the server forces the client to use RPC-with-TLS
plus peer authentication, that may be sufficient and does
not require any protocol extensions.
Comments?
rick
On Tue, 2023-01-03 at 17:28 -0800, Rick Macklem wrote:
> I have recently implemented a NFSv4.1/4.2 client mount
> on FreeBSD that uses AUTH_SYS for ExchangeID, CreateSession
> (and the other state maintenance operations)
> using SP4_NONE and then it defers an RPC that does:
> PutRootFH { Lookup, Lookup,... Lookup } GetFH
> until a user process/thread attempts to use the mount.
> Once an attempt succeeds, the file handle for the mount
> point is filled in and the mount works normally.
> This works for both a FreeBSD NFSv4 server and a Linux
> 5.15 one.
>
> Why do this?
>
> It allows a sec=krb5 mount to work without any
> machine credential on the client. (Both installing
> a keytab entry for a host/nfs-client.domain in the
> client or doing the mount based on a user principal's
> TGT are bothersome.) The first user with a valid TGT
> that attempts to access the mount completes the mount's
> setup.
>
> I envision that this will be used along with RPC-with-TLS
> (which can provide both on-the-wire encryption and
> peer authentication). The seems to be a reasonable
> alternative to a machine credential and a requirement
> for RPCSEC_GSS integrity or privacy.
>
> Why am I posting here?
>
> I am wondering if the Linux client implementors are
> interested in doing the same thing?
>
> I think it is possible to extend NFSv4.2 with a new
> enum state_protect_how4 value (SP4_PEER_AUTH?) that
> would allow the client to specify what operations must
> use RPC-with-TLS including peer authentication and which
> must be allowed for this case (similar to SP4_MECH_CRED).
> However, if the server forces the client to use RPC-with-TLS
> plus peer authentication, that may be sufficient and does
> not require any protocol extensions.
>
> Comments?
>
Are there really that many use cases for this? If you are using krb5
authentication, then you pretty much have to support identity mapping.
Unless you are talking about a hobby setup, then that usually means
backing your Kerberos server with either LDAP or Active Directory to
serve up account mappings, and it usually means protecting those
databases with some form of strong authentication as well.
IOW: for most setups, I would expect the machine credential requirement
to be a non-negotiable part of the total AD/Krb5+LDAP security package
that is implemented in userspace. Am I wrong?
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email protected]
On Tue, Jan 3, 2023 at 6:12 PM Trond Myklebust <[email protected]> wrote:
>
> On Tue, 2023-01-03 at 17:28 -0800, Rick Macklem wrote:
> > I have recently implemented a NFSv4.1/4.2 client mount
> > on FreeBSD that uses AUTH_SYS for ExchangeID, CreateSession
> > (and the other state maintenance operations)
> > using SP4_NONE and then it defers an RPC that does:
> > PutRootFH { Lookup, Lookup,... Lookup } GetFH
> > until a user process/thread attempts to use the mount.
> > Once an attempt succeeds, the file handle for the mount
> > point is filled in and the mount works normally.
> > This works for both a FreeBSD NFSv4 server and a Linux
> > 5.15 one.
> >
> > Why do this?
> >
> > It allows a sec=krb5 mount to work without any
> > machine credential on the client. (Both installing
> > a keytab entry for a host/nfs-client.domain in the
> > client or doing the mount based on a user principal's
> > TGT are bothersome.) The first user with a valid TGT
> > that attempts to access the mount completes the mount's
> > setup.
> >
> > I envision that this will be used along with RPC-with-TLS
> > (which can provide both on-the-wire encryption and
> > peer authentication). The seems to be a reasonable
> > alternative to a machine credential and a requirement
> > for RPCSEC_GSS integrity or privacy.
> >
> > Why am I posting here?
> >
> > I am wondering if the Linux client implementors are
> > interested in doing the same thing?
> >
> > I think it is possible to extend NFSv4.2 with a new
> > enum state_protect_how4 value (SP4_PEER_AUTH?) that
> > would allow the client to specify what operations must
> > use RPC-with-TLS including peer authentication and which
> > must be allowed for this case (similar to SP4_MECH_CRED).
> > However, if the server forces the client to use RPC-with-TLS
> > plus peer authentication, that may be sufficient and does
> > not require any protocol extensions.
> >
> > Comments?
> >
>
> Are there really that many use cases for this? If you are using krb5
> authentication, then you pretty much have to support identity mapping.
> Unless you are talking about a hobby setup, then that usually means
> backing your Kerberos server with either LDAP or Active Directory to
> serve up account mappings, and it usually means protecting those
> databases with some form of strong authentication as well.
>
> IOW: for most setups, I would expect the machine credential requirement
> to be a non-negotiable part of the total AD/Krb5+LDAP security package
> that is implemented in userspace. Am I wrong?
>
For systems in machine rooms, you are probably correct, although I
think many of these environments would just use AUTH_SYS, since they
trust the clients.
What about mounts from mobile devices that do not have a fixed
client IP host address?
(I suspect that, currently, they seldom if ever use NFS, but I think
trying to support them could be useful. A mobile client can use
a X.509 certificate to do a reasonable job of verifying its identity
if signed by a site local CA, although it cannot have a "wired-down"
DNS name in the certificate.)
rick
> --
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> [email protected]
>
>
On Tue, 2023-01-03 at 19:16 -0800, Rick Macklem wrote:
> On Tue, Jan 3, 2023 at 6:12 PM Trond Myklebust <[email protected]>
> wrote:
> >
> > On Tue, 2023-01-03 at 17:28 -0800, Rick Macklem wrote:
> > > I have recently implemented a NFSv4.1/4.2 client mount
> > > on FreeBSD that uses AUTH_SYS for ExchangeID, CreateSession
> > > (and the other state maintenance operations)
> > > using SP4_NONE and then it defers an RPC that does:
> > > PutRootFH { Lookup, Lookup,... Lookup } GetFH
> > > until a user process/thread attempts to use the mount.
> > > Once an attempt succeeds, the file handle for the mount
> > > point is filled in and the mount works normally.
> > > This works for both a FreeBSD NFSv4 server and a Linux
> > > 5.15 one.
> > >
> > > Why do this?
> > >
> > > It allows a sec=krb5 mount to work without any
> > > machine credential on the client. (Both installing
> > > a keytab entry for a host/nfs-client.domain in the
> > > client or doing the mount based on a user principal's
> > > TGT are bothersome.) The first user with a valid TGT
> > > that attempts to access the mount completes the mount's
> > > setup.
> > >
> > > I envision that this will be used along with RPC-with-TLS
> > > (which can provide both on-the-wire encryption and
> > > peer authentication). The seems to be a reasonable
> > > alternative to a machine credential and a requirement
> > > for RPCSEC_GSS integrity or privacy.
> > >
> > > Why am I posting here?
> > >
> > > I am wondering if the Linux client implementors are
> > > interested in doing the same thing?
> > >
> > > I think it is possible to extend NFSv4.2 with a new
> > > enum state_protect_how4 value (SP4_PEER_AUTH?) that
> > > would allow the client to specify what operations must
> > > use RPC-with-TLS including peer authentication and which
> > > must be allowed for this case (similar to SP4_MECH_CRED).
> > > However, if the server forces the client to use RPC-with-TLS
> > > plus peer authentication, that may be sufficient and does
> > > not require any protocol extensions.
> > >
> > > Comments?
> > >
> >
> > Are there really that many use cases for this? If you are using
> > krb5
> > authentication, then you pretty much have to support identity
> > mapping.
> > Unless you are talking about a hobby setup, then that usually means
> > backing your Kerberos server with either LDAP or Active Directory
> > to
> > serve up account mappings, and it usually means protecting those
> > databases with some form of strong authentication as well.
> >
> > IOW: for most setups, I would expect the machine credential
> > requirement
> > to be a non-negotiable part of the total AD/Krb5+LDAP security
> > package
> > that is implemented in userspace. Am I wrong?
> >
> For systems in machine rooms, you are probably correct, although I
> think many of these environments would just use AUTH_SYS, since they
> trust the clients.
>
> What about mounts from mobile devices that do not have a fixed
> client IP host address?
> (I suspect that, currently, they seldom if ever use NFS, but I think
> trying to support them could be useful. A mobile client can use
> a X.509 certificate to do a reasonable job of verifying its identity
> if signed by a site local CA, although it cannot have a "wired-down"
> DNS name in the certificate.)
Those aren't really likely to use krb5, though.
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.
Such a mechanism would presumably allow you to continue to define
separate identities for the machine and the user, and multiplex them
over the same TLS connection.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email protected]
> On Jan 3, 2023, at 11:41 PM, Trond Myklebust <[email protected]> wrote:
>
> On Tue, 2023-01-03 at 19:16 -0800, Rick Macklem wrote:
>> On Tue, Jan 3, 2023 at 6:12 PM Trond Myklebust <[email protected]>
>> wrote:
>>>
>>> On Tue, 2023-01-03 at 17:28 -0800, Rick Macklem wrote:
>>>> I have recently implemented a NFSv4.1/4.2 client mount
>>>> on FreeBSD that uses AUTH_SYS for ExchangeID, CreateSession
>>>> (and the other state maintenance operations)
>>>> using SP4_NONE and then it defers an RPC that does:
>>>> PutRootFH { Lookup, Lookup,... Lookup } GetFH
>>>> until a user process/thread attempts to use the mount.
>>>> Once an attempt succeeds, the file handle for the mount
>>>> point is filled in and the mount works normally.
>>>> This works for both a FreeBSD NFSv4 server and a Linux
>>>> 5.15 one.
>>>>
>>>> Why do this?
>>>>
>>>> It allows a sec=krb5 mount to work without any
>>>> machine credential on the client. (Both installing
>>>> a keytab entry for a host/nfs-client.domain in the
>>>> client or doing the mount based on a user principal's
>>>> TGT are bothersome.) The first user with a valid TGT
>>>> that attempts to access the mount completes the mount's
>>>> setup.
>>>>
>>>> I envision that this will be used along with RPC-with-TLS
>>>> (which can provide both on-the-wire encryption and
>>>> peer authentication). The seems to be a reasonable
>>>> alternative to a machine credential and a requirement
>>>> for RPCSEC_GSS integrity or privacy.
>>>>
>>>> Why am I posting here?
>>>>
>>>> I am wondering if the Linux client implementors are
>>>> interested in doing the same thing?
>>>>
>>>> I think it is possible to extend NFSv4.2 with a new
>>>> enum state_protect_how4 value (SP4_PEER_AUTH?) that
>>>> would allow the client to specify what operations must
>>>> use RPC-with-TLS including peer authentication and which
>>>> must be allowed for this case (similar to SP4_MECH_CRED).
>>>> However, if the server forces the client to use RPC-with-TLS
>>>> plus peer authentication, that may be sufficient and does
>>>> not require any protocol extensions.
>>>>
>>>> Comments?
>>>>
>>>
>>> Are there really that many use cases for this? If you are using
>>> krb5
>>> authentication, then you pretty much have to support identity
>>> mapping.
>>> Unless you are talking about a hobby setup, then that usually means
>>> backing your Kerberos server with either LDAP or Active Directory
>>> to
>>> serve up account mappings, and it usually means protecting those
>>> databases with some form of strong authentication as well.
>>>
>>> IOW: for most setups, I would expect the machine credential
>>> requirement
>>> to be a non-negotiable part of the total AD/Krb5+LDAP security
>>> package
>>> that is implemented in userspace. Am I wrong?
>>>
>> For systems in machine rooms, you are probably correct, although I
>> think many of these environments would just use AUTH_SYS, since they
>> trust the clients.
>>
>> What about mounts from mobile devices that do not have a fixed
>> client IP host address?
>> (I suspect that, currently, they seldom if ever use NFS, but I think
>> trying to support them could be useful. A mobile client can use
>> a X.509 certificate to do a reasonable job of verifying its identity
>> if signed by a site local CA, although it cannot have a "wired-down"
>> DNS name in the certificate.)
>
> Those aren't really likely to use krb5, though.
My intuition is Rick's usage scenario would be common if we made
it possible. It's similar to how Windows/SMB works on laptops,
and is a common deployment scenario in campus environments.
> 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.
--
Chuck Lever
On Wed, Jan 4, 2023 at 6:25 AM Chuck Lever III <[email protected]> wrote:
>
>
>
> > On Jan 3, 2023, at 11:41 PM, Trond Myklebust <[email protected]> wrote:
> >
> > On Tue, 2023-01-03 at 19:16 -0800, Rick Macklem wrote:
> >> On Tue, Jan 3, 2023 at 6:12 PM Trond Myklebust <[email protected]>
> >> wrote:
> >>>
> >>> On Tue, 2023-01-03 at 17:28 -0800, Rick Macklem wrote:
> >>>> I have recently implemented a NFSv4.1/4.2 client mount
> >>>> on FreeBSD that uses AUTH_SYS for ExchangeID, CreateSession
> >>>> (and the other state maintenance operations)
> >>>> using SP4_NONE and then it defers an RPC that does:
> >>>> PutRootFH { Lookup, Lookup,... Lookup } GetFH
> >>>> until a user process/thread attempts to use the mount.
> >>>> Once an attempt succeeds, the file handle for the mount
> >>>> point is filled in and the mount works normally.
> >>>> This works for both a FreeBSD NFSv4 server and a Linux
> >>>> 5.15 one.
> >>>>
> >>>> Why do this?
> >>>>
> >>>> It allows a sec=krb5 mount to work without any
> >>>> machine credential on the client. (Both installing
> >>>> a keytab entry for a host/nfs-client.domain in the
> >>>> client or doing the mount based on a user principal's
> >>>> TGT are bothersome.) The first user with a valid TGT
> >>>> that attempts to access the mount completes the mount's
> >>>> setup.
> >>>>
> >>>> I envision that this will be used along with RPC-with-TLS
> >>>> (which can provide both on-the-wire encryption and
> >>>> peer authentication). The seems to be a reasonable
> >>>> alternative to a machine credential and a requirement
> >>>> for RPCSEC_GSS integrity or privacy.
> >>>>
> >>>> Why am I posting here?
> >>>>
> >>>> I am wondering if the Linux client implementors are
> >>>> interested in doing the same thing?
> >>>>
> >>>> I think it is possible to extend NFSv4.2 with a new
> >>>> enum state_protect_how4 value (SP4_PEER_AUTH?) that
> >>>> would allow the client to specify what operations must
> >>>> use RPC-with-TLS including peer authentication and which
> >>>> must be allowed for this case (similar to SP4_MECH_CRED).
> >>>> However, if the server forces the client to use RPC-with-TLS
> >>>> plus peer authentication, that may be sufficient and does
> >>>> not require any protocol extensions.
> >>>>
> >>>> Comments?
> >>>>
> >>>
> >>> Are there really that many use cases for this? If you are using
> >>> krb5
> >>> authentication, then you pretty much have to support identity
> >>> mapping.
> >>> Unless you are talking about a hobby setup, then that usually means
> >>> backing your Kerberos server with either LDAP or Active Directory
> >>> to
> >>> serve up account mappings, and it usually means protecting those
> >>> databases with some form of strong authentication as well.
> >>>
> >>> IOW: for most setups, I would expect the machine credential
> >>> requirement
> >>> to be a non-negotiable part of the total AD/Krb5+LDAP security
> >>> package
> >>> that is implemented in userspace. Am I wrong?
> >>>
> >> For systems in machine rooms, you are probably correct, although I
> >> think many of these environments would just use AUTH_SYS, since they
> >> trust the clients.
> >>
> >> What about mounts from mobile devices that do not have a fixed
> >> client IP host address?
> >> (I suspect that, currently, they seldom if ever use NFS, but I think
> >> trying to support them could be useful. A mobile client can use
> >> a X.509 certificate to do a reasonable job of verifying its identity
> >> if signed by a site local CA, although it cannot have a "wired-down"
> >> DNS name in the certificate.)
> >
> > Those aren't really likely to use krb5, though.
>
> My intuition is Rick's usage scenario would be common if we made
> it possible. It's similar to how Windows/SMB works on laptops,
> and is a common deployment scenario in campus environments.
>
Although I won't claim to have any idea how widely used this might
be, I suppose a "shared desktop or laptop" such as you might find
in a college campus is a better example.
Another possible case, which I hesitate to even mention because
I have no understanding of it, is use in container like environments.
In FreeBSD, there is something called a vnet prison. Each of these
has their own password database, etc. I had never thought that
running an nfsd inside one of these made sense, but others indicated
that this was desirable, so I have generated patches to do it.
(An nfsd running in one of these vnet prisons is what I actually used
to test the NFSv4 client mount changes, although it certainly is not
specific to this case.)
Similar to what Chuck notes below, when a mobile device is only used by one
user, Kerberos is not needed. (See below.)
>
> > 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.
All certainly doable, but to me it just sounds like you are re-inventing
Kerberos, but using X.509 certificates instead of Kerberos tickets.
(Isn't the main purpose of a KDC handling trusted private keys for users?)
Having said the above "Maybe such a system would catch on where
Kerberos has not?)
To me, part of the problem with Kerberized NNFSv4 is that it (mis)uses
Kerberos to create the machine credentials.
>
> A laptop typically has a single user. The flexibility of identity
> multiplexing isn't necessary in this particular scenario.
>
Yes, Chuck, I (and others) had a discussion on [email protected] some
time ago w.r.t. using the X.509 certificate presented during TLS handshake
to identify a specific user and then use credentials for that user for all
compound RPCs, ignoring the credentials in the RPC header.
Chuck labelled this "TLS Identity squashing" (he's much better at
naming things than I am).
I think we agreed that the concept is useful. We disagreed on what
would be the most appropriate way to implement it.
- The FreeBSD server currently expects the "user" to be identified
right in the X.509 certificate, using the otherName component of
the SubjectAltName field.
- Chuck preferred a database on the server keyed on <issuer, serial#>
of the certificate.
However, these are implementation details and a NFSv4 server could
easily support either or both of these techniques.
rick
> --
> Chuck Lever
>
>
>
On Wed, 2023-01-04 at 14:25 +0000, Chuck Lever III wrote:
>
>
> > On Jan 3, 2023, at 11:41 PM, Trond Myklebust <[email protected]>
> > 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.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email protected]
> On Jan 4, 2023, at 12:25 PM, Trond Myklebust <[email protected]> wrote:
>
> On Wed, 2023-01-04 at 14:25 +0000, Chuck Lever III wrote:
>>
>>
>>> On Jan 3, 2023, at 11:41 PM, Trond Myklebust <[email protected]>
>>> 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.
The trend I've seen is that enterprises are moving their important
services out of from behind VPNs and into the cloud. Each such
service is responsible for providing appropriate levels of
authentication and confidentiality via a single-sign on service
and an in-transit encryption capability.
> 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.
We had SPKM. Would that not work?
--
Chuck Lever
On Wed, Jan 4, 2023 at 12:43 PM Trond Myklebust <[email protected]> wrote:
>
> On Wed, 2023-01-04 at 14:25 +0000, Chuck Lever III wrote:
> >
> >
> > > On Jan 3, 2023, at 11:41 PM, Trond Myklebust <[email protected]>
> > > 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
> [email protected]
>
>
On Wed, 2023-01-04 at 18:06 +0000, Chuck Lever III wrote:
>
>
> > On Jan 4, 2023, at 12:25 PM, Trond Myklebust <[email protected]>
> > wrote:
> >
> > On Wed, 2023-01-04 at 14:25 +0000, Chuck Lever III wrote:
> > >
> > >
> > > > On Jan 3, 2023, at 11:41 PM, Trond Myklebust
> > > > <[email protected]>
> > > > 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.
>
> The trend I've seen is that enterprises are moving their important
> services out of from behind VPNs and into the cloud. Each such
> service is responsible for providing appropriate levels of
> authentication and confidentiality via a single-sign on service
> and an in-transit encryption capability.
>
>
> > 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.
>
> We had SPKM. Would that not work?
The SPKM spec was withdrawn following review by the IETF security
working groups. Reviving it and pushing it again would require
addressing those comments.
Furthermore, SPKM was always intended as a full blown RPCSEC_GSS
mechanism, which seems like overkill for this use case.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email protected]
On Wed, 2023-01-04 at 13:34 -0500, Olga Kornievskaia wrote:
> On Wed, Jan 4, 2023 at 12:43 PM Trond Myklebust <[email protected]>
> wrote:
> >
> > On Wed, 2023-01-04 at 14:25 +0000, Chuck Lever III wrote:
> > >
> > >
> > > > On Jan 3, 2023, at 11:41 PM, Trond Myklebust
> > > > <[email protected]>
> > > > 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.
Channel bindings require mutual TLS authentication between the server
and the client because the idea is that the client can then be trusted
by the server to authenticate the users.
I'm looking for something that only requires the server to authenticate
to the client, and that then allows the applications running RPC calls
to authenticate their users to the server at the per-RPC level. That
requires stronger authentication at the RPC level, but doesn't need the
full-blown RPCSEC_GSS treatment because we already have privacy
guaranteed at the transport level.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email protected]