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

Rick Macklem <rick.macklem@gmail.com> Sat, 31 December 2022 23:46 UTC

Return-Path: <rick.macklem@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AB753C14CE47 for <nfsv4@ietfa.amsl.com>; Sat, 31 Dec 2022 15:46:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id n0_OAr6m9B3K for <nfsv4@ietfa.amsl.com>; Sat, 31 Dec 2022 15:46:49 -0800 (PST)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1220AC14F720 for <nfsv4@ietf.org>; Sat, 31 Dec 2022 15:46:49 -0800 (PST)
Received: by mail-pg1-x52c.google.com with SMTP id f3so16328827pgc.2 for <nfsv4@ietf.org>; Sat, 31 Dec 2022 15:46:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=l2i8TfNTpqzsSF91F1AS0wsMnera3d4x9b67ptzPbec=; b=FXbRONIRmDmddoOrOBIvFlwmXdPoxxs7klA5nWmt2VIFPScVUj5phmHEe/AQtB0h6y u2fK+g3CthMFL0wzoYSOXAb2y6wD/tNAdUKpFgdKKs89EesD4DxfWqRL/nggt2EJrYSr nV9lOQGo0VucR3JwOZikwf0mxLz0WtJ3g+d4hhXKesgRYVadvJFJJhHrgE2G2J6z/z4t 2mKUkXwSbXlve9qgp6kZfnwgYHuEhTJBO1rGO5bcbF7kAbE4kMydI50y5dGSouIXmbz3 9HEoew3iPn56pkAWAdTn37sEO8sj+auQcLLdsNjPsZX/DtmOsmnUPWKHt+Xydlwj2v3s PFiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=l2i8TfNTpqzsSF91F1AS0wsMnera3d4x9b67ptzPbec=; b=iaTD6JFnMaL0Z6mkFQK2h/AWUR4GVfFGr3Neab5BPYkvbz3y5VAJRrOaV+yA16psZE Z+qlpc6qjknIXvMTgob33Dpg/TVd9q6RZRBkXA6FZhHW+rtYLAkO5aaZrfEatKMJIFwj a1poXpepOZPb2uD2bK2vDLIptHUI8PSsazY5V6INcUbNoLKTZdokD9hjXCEYypMuNGbt I7r2xvGBvj9L4vxMlIwI2fR/kqiLuTLc4bJs1nN2HKTBnZR8h7hmUTf76tUOxFiUg/9e iXWszEs2n++YLYPR57V+gUbS3ESm9f1X6uxH/U6s+pJnH5cvCm0ytRW+ISseDlhqw2q6 e8LQ==
X-Gm-Message-State: AFqh2ko6WT251AjL3TuEJC+p3ol1H7palV1o5RHbvNI933PUF7OgEnWU 1UeXooxz9nUe5oWPy+JccQ8yEdtaIJ1H8Vu87VykMrmJd+cF
X-Google-Smtp-Source: AMrXdXvpH0Q+hwSJ5Tav74GSDSNXlX7D1gm9alMq4nruSsdAmzHODOXtjMPI2ef+lJJcauSaYaIp2gNA3KBJqDj92S0=
X-Received: by 2002:a63:d018:0:b0:477:cce0:28f8 with SMTP id z24-20020a63d018000000b00477cce028f8mr2391412pgf.89.1672530408256; Sat, 31 Dec 2022 15:46:48 -0800 (PST)
MIME-Version: 1.0
From: Rick Macklem <rick.macklem@gmail.com>
Date: Sat, 31 Dec 2022 15:46:38 -0800
Message-ID: <CAM5tNy7A41ss3m_Q4+XSnUF3frbe9YO-4EzMUA1_k_wyz+e12Q@mail.gmail.com>
To: nfsv4@ietf.org
Content-Type: multipart/alternative; boundary="000000000000dc3b4905f12854b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/akSLDR2C-_V4m952todp0nvd2Ec>
X-Mailman-Approved-At: Sun, 01 Jan 2023 03:51:21 -0800
Subject: [nfsv4] RFC: Combining RPC-with-TLS and sec=krb5
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Dec 2022 23:47:41 -0000

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