Re: [nfsv4] RFC: Combining RPC-with-TLS and sec=krb5

[Chuck Lever III <[e-mail]>]

Happy new year, Rick.

> On Dec 31, 2022, at 6:46 PM, Rick Macklem <[e-mail]> wrote:
> 
> First, some background...
> 
> The NFSv4 RFCs require that the same principal be used for all state
> related operations as was used for the initial SetClientID or ExchangeID.
> For kerberized NFSv4 mounts, the client has typically handled this in one
> of two ways:
> 
> A - A host based principal of the form "host/FQDN-of-client" is created
>     on the KDC.  A keytab entry for this principal is then generated and
>     put in the client's default keytab file via some secure means.
>     This approach works, but does have some limitations:
>     - The client must have a well defined, fixed, DNS host name.
>       This implies that it does not work for any mobile device.

My impression is that there are similar DNS-related constraints on the
usage of x.509 certificates for peer authentication.


>     - The administrative overhead of doing this seems to have discouraged
>       some from doing Kerberized NFSv4 mounts and instead choosing to
>       use insecure AUTH_SYS.
> 
> B - The client's "root" user does a kinit for a Kerberos user principal
>     to acquire a valid TGT and then does a mount, using that TGT/principal.
>     This approach works, but also has limitations:
>     - When the user principal's TGT expires, the mount stops working.
>     - The mount can only be done manually, after doing a "kinit".
>     - The procedure for doing this is rather convoluted for the Linux
>       NFSv4 client.
> 
> The fact that this tends to be administratively "awkward" is not
> surprising, since Kerberos was designed for user authentication
> and not machine (or peer, if you prefer) authentication.
> We now have RPC-with-TLS.  This can provide machine authentication,
> but requiring the NFSv4 client to present a valid X.509 certificate
> during TLS handshake.  It also provides on-the-wire encryption,
> obviating any need for RPCSEC_GSS integrity or privacy.
> However, it does not provide user authentication and, as such, can
> result in mounts using insecure AUTH_SYS.
> 
> So, what I have test coded for FreeBSD combines the use of RPC-with-TLS
> for privacy and machine authentication with the use of RPCSEC_GSS/Kerberos
> for user authentication.  This did not require any on-the-wire protocol
> changes, but did require some implementation work on both client and server.

This is the basic convention that I had roughly envisioned when working
on RPC-with-TLS, as it plays to the strengths of both security mechanisms.
It does not address the issue of having to place identification material
on every participating client (ie, a keytab, PSK, or x.509 certificate),
but the other benefits are palpable.

The security policy details have to be worked out, of course. I suspect
a channel binding type will need to be specified, for example.


> For the NFSv4 server:
> 1 - Allow compound RPCs that consist entirely of state maintenance operations
>     (ExchangeID, CreateSession, ReclaimComplete, Sequence, DestroySession,
>      DestroyClient, SetClientID, SetClientIDConfirm, Renew, FreeStateID,
>      ReleaseLockOwner, BindConnectionToSession)
>     to be performed using AUTH_SYS credentials with the same uid (usually 0)
>     if the client is using RPC-with-TLS and has machine authenticated during
>     TLS handshake (via a X.509 certificate).
> 2 - Require all other compound RPCs (ones making use of a CFH) to be performed
>     with RPCSEC_GSS/Kerberos credentials.
> This turned out to be fairly simple for the FreeBSD NFSv4 server, since it
> already had a separate function to authenticate #1 vs #2 RPCs.
> 
> This allows a client to use Kerberos for user authentication, but does not
> require the client to do (A) or (B) above.
> Implementation of this in the FreeBSD NFSv4 client turned out to be somewhat
> more involved than the server changes.  The FreeBSD NFSv4 client does a
> compound RPC that looks like:
> - PutRootFH, { Lookup, Lookup,...Lookup }, GetFH
>   For example, if the mount is specified as nfsv4-server:/export/vol1,
>   the above would be:
>   PutRootFH, Lookup export, Lookup vol1, GetFH
> This RPC is normally done during mount.  To make this scheme work, the
> above RPC needed to be deferred if the server replied NFS4ERR_WRONGSEC
> when attempted using AUTH_SYS credentials.
> Then, the above RPC is attempted again whenever a user process attempts
> to access the mounted file system.  When one of these access attempts
> is done by a user with a valid TGT for their user principal, the attempt
> succeeds and the mount then knows the actual file handle for the
> mount point.
> 
> Deferring acquisition of the mount point file handle required that a "fake"
> one be created during the mount operation, which is then replaced when
> a retry of the above RPC succeeds.  This is obviously a FreeBSD specific
> implementation detail, but other clients might perform in a similar way.
> 
> In summary, this implementation allows the use of Kerberos for user
> authentication without the need to (mis)use Kerberos for machine authentication.
> Machine authentication is handled by RPC-with-TLS, along with on-the-wire
> encryption (which may be supported by offload hardware).
> It is hoped that this might simplify Kerberos deployment for NFSv4 mounts
> to the point that it would be more widely adopted.
> 
> So, does this sound like a good plan?
> 
> In particular, are the Linux folk interested in implementing this?

A better place to ask this last question is [e-mail],
Cc: the Linux NFS client architect/ maintainers (Trond and Anna). In
general, the Linux NFS server implementation will follow whatever the
Linux NFS client needs it to, so the client maintainers need to speak
up about what they find acceptable.


--
Chuck Lever