> On Jan 3, 2023, at 11:41 PM, Trond Myklebust <trondmy@xxxxxxxxxx> wrote:
>
> On Tue, 2023-01-03 at 19:16 -0800, Rick Macklem wrote:
>> On Tue, Jan 3, 2023 at 6:12 PM Trond Myklebust <trondmy@xxxxxxxxxx>
>> 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
