Re: [nfsv4] Adoption call for draft-dnoveck-nfsv4-security

[Rick Macklem <[e-mail]>]

I am going to stay out of the adoption debate. However, I thought I should comment
on one statement.
David Noveck <[e-mail]> wrote:

>As above, there are implementations that require use rpc-with-tls when  AUTH_SYS is used.

The current FreeBSD server implementation allows a requirement for rpc-with-tls to
be used, but it can be applied to RPCSEC_GSS and not just AUTH_SYS.
For example, the combination of:
   -tls -sec=krb5
would specify that clients must use rpc-with-tls and also use Kerberos.
(rpc-with-tls provides the on-the-wire encryption and may be preferable to -sec=krb5p,
 since offload hardware is available for TLS and in encrypts the entire RPC message.)

One case I am planning on doing implementation of soon is..
- Allow the machine credential to be established via the client presenting a verifiable
  X.509 certificate during handshake, so that a Kerberos mount does not have to have
  a valid Kerberos credential at mount time.
  --> This avoids the bother of having a Kerberos host principal in a keytab on the client.

The idea is to allow compounds that consist only of operations like ExchangeID,
CreateSession, Sequence by itself, DestroySession, DestroyClientID to be performed
using AUTH_SYS and the same uid as the initial ExchangeID (since the machine credential
for this is established by the client via their X.509 certificate) even when Kerberos is
required for other compounds.

Other compounds would be required to provide a valid Kerberos credential, but these
compounds would only be done by users after the mount is established, using their
user principal kint'd credential.

I do suspect there will be some "tricks" needed, such as setting a default lease_time
until a successful Getattr acquires the server's lease_time and things like finding
the root directory for the mount will need to be (re)attempted by each user access
attempt until a successful one acquires the file handle for the client.

I do think that one of the reasons Kerberos has not been widely adopted is the
hassle/misuse of "service principals" to establish "machine credentials".

rick