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

[Rick Macklem <[e-mail]>]

On Sun, Jan 1, 2023 at 4:47 PM Rick Macklem <[e-mail]> wrote:

>
>
> On Sun, Jan 1, 2023 at 5:08 AM David Noveck <[e-mail]> wrote:
>
>>
>>
>> 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.
>>>
>> Sort of, yes.  My current implementation uses SP_NONE and, as such, works
> against an unmodified FreeBSD or Linux server. However, the servers are not
> enforcing the "requires RPC-with-TLS plus peer authentication" requirement.
>
> It appears to implement that requirement, a new value for
> state_protect_how4
> would need to be defined (SP4_PEER_AUTH ?).
> I think this could be added as a new case for both state_protect4_a and
> state_protect4_r with state_protect_ops in the union's case.
> Its semantics would be similar to SP4_MACH_CRED, but would allow AUTH_SYS
> to be used, so long as the compound was received on a RPC-with-TLS
> connection
> that has been peer authenticated during TLS handshake.
>

I think that a simpler way to do this which avoids defining a new value
for state_protect_how4 would be to have the server require use of
RPC-with-TLS including peer authentication for all connections from
a given client (checked via client IP host address) when doing non-NULL
RPCs.
I think? we have agreed that this is something reasonable for a server to
do, based on a server sysadmin's configuration.

Then, requiring RPC-with-TLS that peer authenticates successfully, combined
with SP4_NONE should achieve what I am trying to do.

This avoids the hassle of defining a new state_protect_how4 value and allows
it to be done for NFSv4.1 and 4.2.
For NFSv4.0, the equivalent to SP4_NONE could be implemented by the server
to achieve the same result.

rick

>
>
>>
>> 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?
>>
> Turns out that it does work (when modified to not use TLS, since the Linux
> server does not do that yet). The use of SP4_NONE against the Linux server
> allows the operations needed to establish the mount to work and the first
> user access to the mount (with a valid Kerberos TGT) fills in the
> additional
> mount information needed.
>
> The Linux client will not do a mount to the FreeBSD server when it does not
> have any Kerberos TGT nor host based keytab entry.
>
> rick
>
>>
>>
>>> 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
>>>
>>