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

[David Noveck <[e-mail]>]

On Sun, Jan 1, 2023, 6:51 AM 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.
>

That was not my impression.  Where exactly does it say this.?

Also, how does this relate to the discussion of state protection in rfc8881?

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

Yes.

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

That is explicitly discussed in *draft-ietf-nfsv4-security*, which hasn't
yet emerged from an adoption call that started in October.  We need to get
this completed soon.  I'll follow up with the other wg chairs.

However, it does not provide user authentication and, as such, can
> result in mounts using insecure AUTH_SYS.
>

The current assumption, in the pending rfc5661bis-related documents, is
that the security of using AUTH_SYS is substantially enhanced when it is
used with peer authentication since you have some basis for determining
that the client is trustworthy in sending uid values.  That's better but it
still leaves AUTH_SYS somewhat insecure.


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

I get the impression that it might require some limited set of
specification changes.

but did require some implementation work on both client and server.
>

So, if this prototype requires implementation work on both the FreeBSD
client and server, what is the interoperability story when your client
accesses a Linux 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 credential.
>

An alternative would be to allow LOOKUP of export points to be done with
AUTH_SYS.  More work for the server but less for the client.

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

It might but the experience is such that we can't depend on that happening.


> So, does this sound like a good plan?
>

It sounds like a worthwhile approach.


> In particular, are the Linux folk interested in implementing this?
>

I don't know.

In any case, we should discuss the spec implications at the IETF116 meeting
and see if this needs changes to go into *draft-ietf-nfsv4-security-01*.
That requires that we get the -00 out within the next few weeks


> Thanks for any comments, rick
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>