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

Rick Macklem <rick.macklem@gmail.com> Sun, 01 January 2023 17:34 UTC

Return-Path: <rick.macklem@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15661C14F692 for <nfsv4@ietfa.amsl.com>; Sun, 1 Jan 2023 09:34:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CSP254QutIl for <nfsv4@ietfa.amsl.com>; Sun, 1 Jan 2023 09:34:53 -0800 (PST)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 91553C14F607 for <nfsv4@ietf.org>; Sun, 1 Jan 2023 09:34:53 -0800 (PST)
Received: by mail-pl1-x629.google.com with SMTP id 17so27200424pll.0 for <nfsv4@ietf.org>; Sun, 01 Jan 2023 09:34:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wbcY6Vdj8BSnDgyCGosd8vAQwFnimLzsbh1F79CDDyk=; b=KlX4MbNvFrf9CY/Kc5bacrLFIJsHqIKevVqik7A/InCTTWCk49EOIVhfw/6JY1it99 qeTuqjEGTG/Pi7wiLKGMlQVQbzHqH9YsAfImAHZiUAHsv061DmHn2SqI9F//JfshOl7x dKqreDGm1Uf4RKzr8ZjH2V2BbSJH5lq+8JQhF4ZN0YYDG9jGreEtMR2EpTYy8HjQK/PR RbJeoEod6U9FO560MqTACk6pYzU9k3RxwyN3h8Rcp4ERm4h7rllBVzcz34VsKtvyVWYw ViGRofvuOKVUDOQzb0Rvq3CE7+wOCNcvU85q/n6ZuFnwrOpI8TVTsvY2FIjf7Lzyq42k MDxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wbcY6Vdj8BSnDgyCGosd8vAQwFnimLzsbh1F79CDDyk=; b=HuZlwVbgBB5BERU2hD/ssFIxd8xoGwkymm55LMcZmN4lGt3tGcaDh4f4g4vDdlXo+0 IOROSL8bdp8aT8QBO4/aT2ZWQVcN8+ll+CpSw0uFdjk/AufKbuNhw81SQGN2oKM2sorU 5V6Bu3F1TQjxinWtu3luk/iJzTpdYUkoV5OtlJNSXgsJDX97gpx7Wv8qTwuI62V4oPpY mWGAoWtqxI5jHcJseqTrrS9cbBojf9tikGVGpMkYkphBblGsIO2rvGmdxCcrPx2Wz9L1 R5pCg4l9yYn20szFgezyIr/EC01mxpaL4yK1VeOszHxj6xq0QFIcWhX8W+XWpzoKrIHK 6AXQ==
X-Gm-Message-State: AFqh2kqP7b+2To2LJk87YwAPxsQfImZ3u0jXVWVA0yOcKDqQyK7s0i9R mzb8NSnMpLtlj754ix0w9UV9FcTq82+Q0ecwnUyXkkT3wsvI
X-Google-Smtp-Source: AMrXdXvXi16MnXBTrHtz8iycnCfh9xOLgPbc0y08I0yqT34JBDWoXVgLAeWJ2podBTkflWbSkVtDePZCp+LEGF685pw=
X-Received: by 2002:a17:902:e944:b0:191:8cb:fbe6 with SMTP id b4-20020a170902e94400b0019108cbfbe6mr2489707pll.60.1672594492941; Sun, 01 Jan 2023 09:34:52 -0800 (PST)
MIME-Version: 1.0
References: <CAM5tNy7A41ss3m_Q4+XSnUF3frbe9YO-4EzMUA1_k_wyz+e12Q@mail.gmail.com> <CADaq8jcDcbDsvS3WnJo1jXO4bBFwT+smT4Yr5GREcu4-TCinvg@mail.gmail.com>
In-Reply-To: <CADaq8jcDcbDsvS3WnJo1jXO4bBFwT+smT4Yr5GREcu4-TCinvg@mail.gmail.com>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Sun, 01 Jan 2023 09:34:41 -0800
Message-ID: <CAM5tNy5xGoS3puwYdi+1JQQwVSb4j4TNeiUip55x+bJfW434+w@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
Cc: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009aecaf05f13740fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/SbkxQGrKIa8UV8aUIEO_adLzb2g>
Subject: Re: [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: Sun, 01 Jan 2023 17:34:57 -0000

On Sun, Jan 1, 2023 at 5:08 AM David Noveck <davenoveck@gmail.com> wrote:

>
>
> On Sun, Jan 1, 2023, 6:51 AM Rick Macklem <rick.macklem@gmail.com> 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.?
>
Ouch, yes, you are correct.  I hadn't read the state protection section of
the RFC in a long time and mostly recalled the "rule" for NFSv4.0.
(Actually, even NFSv4.0 allows a Renew to be done with the principal that
 acquired a current Open as an alternative to the one used for SetClientID.)

I am still wading through it, but I did spot:
    o  SP4_NONE.  The client does not request the NFSv4.1 server to
      enforce state protection.  The NFSv4.1 server MUST NOT enforce
      state protection for the returned client ID.
I had missed the second sentence before.  It appears that, for SP4_NONE,
the server cannot enforce the requirement that RPC-with-TLS including a
successful peer authentication be needed.

As such, what I proposed does not conform to the RFC.
Apologies for the noise.

I'll look at the extension rules for NFSv4.2 to see if a new SP4_TLS
could be added, that would be similar to SP4_MACH_CRED, but would
allow AUTH_SYS, but would require a successful peer authentication
via TLS.


> Also, how does this relate to the discussion of state protection in
> rfc8881?
>
As above, I now see it is non-conformant. I thought this would be
allowed for SP4_NONE, but I was wrong.


>
> 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.
>
I do think a successful peer authentication is at least a good alternative
to checking the client's host IP address to verify client machine identity.
And then I suppose the server allowing use of AUTH_SYS recognizes that the
server trusts the client's uid/gid information.

However, in practice, I suspect many use AUTH_SYS because they do not want
to implement kerberized NFSv4 and choose to accept the risk that the client
will use appropriate uid/gids in the AUTH_SYS credential.


>
>
>> 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.
>
It appears more than that. It looks like this would require a new SP4_xxx
be defined. At this point, I am not sure if an extension of NFSv4.2 to do
this would be allowed under the extension rules. I need to look at that.


>
> 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?
>
Don't know. My Linux server does not have kerberos configured on it
at this time.  It would certainly be an interesting test.
If the Linux server does not do state protection checks for SP4_NONE,
then the client should be able to mount the server, but without the
server enforcing the RPC-with-TLS requirement.


>
>
>> 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.
>
If you allow Lookup, you would also need to allow PutRootFH. Once you
do that a client could "explore" the server's file name space without
having any RPCSEC_GSS credential.  That was not what I had intended.


>
> 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
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>