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

[Rick Macklem <[e-mail]>]

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.
    - 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.

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?

Thanks for any comments, rick