Re: [nfsv4] NFS over TLS for floating clients

Chuck Lever <chuck.lever@oracle.com> Mon, 30 March 2020 16:27 UTC

Return-Path: <chuck.lever@oracle.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 5B9AB3A188F for <nfsv4@ietfa.amsl.com>; Mon, 30 Mar 2020 09:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBJi2v8swXgs for <nfsv4@ietfa.amsl.com>; Mon, 30 Mar 2020 09:27:19 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E7C3A186A for <nfsv4@ietf.org>; Mon, 30 Mar 2020 09:27:18 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 02UGNoEo041538; Mon, 30 Mar 2020 16:27:18 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2020-01-29; bh=EvcTAtG+flOjjt9CXmPOxANy4uYc9mP0bn9yBQm1nmI=; b=Rtso8C2uKnHOoFeDM8Fk45xBtraL0xBHyXOaZ59wxo5kDmntAn9riwg6eByrJfylfckG dE+xOyybAtYP/hu2loXrN1zs4QWkOnaYvc9t5Cr0KRJYsQjftjiDioMGIQ6SiShRSJNT /dJEkdpppsVDJ2DjPVtACrrjwh9OSqB7B6LEu84N4z2+BrWKscpiDWsATgQJlQs+c7+l KmMVRK/mypEfPTCDOVL3ZBNCQStyIOxgzBnoouO6/2e11hpo7QkYPEjfiBlrHjbZS/GR wqf6Z0GTH2lcH2YmSwD4vr3zE/vzw9MZ9kK04wSvGpQsO+Q5fklNBC5A6068WTYfuX44 BA==
Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 303ceutsnw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 30 Mar 2020 16:27:18 +0000
Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 02UGMKPZ125099; Mon, 30 Mar 2020 16:27:17 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 302g4pysm0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 30 Mar 2020 16:27:17 +0000
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 02UGRG1E000455; Mon, 30 Mar 2020 16:27:16 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Mar 2020 09:27:16 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <QB1PR01MB36490F5BFC5CC7ACCF41D230DDCB0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>
Date: Mon, 30 Mar 2020 12:27:14 -0400
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CB92024-0157-4896-B97D-68CF4B72358D@oracle.com>
References: <YTBPR01MB337482A9420C1AEF05466D3FDDE30@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> <CAABAsM7mSfULv974gPQmCSt+Nt2zdH1wMvemwPXw365SeEGTQg@mail.gmail.com> <CAMhwm99ZUf5fshkkOtRyf2u8DjeRLdVk=Q05H8YF4A+ycZi8fA@mail.gmail.com> <YTBPR01MB337418573DE1D692BC029012DDE30@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> <20200329015025.GK50174@kduck.mit.edu> <QB1PR01MB36490F5BFC5CC7ACCF41D230DDCB0@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>
To: Rick Macklem <rmacklem@uoguelph.ca>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9576 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 suspectscore=0 mlxscore=0 spamscore=0 malwarescore=0 mlxlogscore=418 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003300151
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9576 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 adultscore=0 clxscore=1015 phishscore=0 lowpriorityscore=0 spamscore=0 malwarescore=0 suspectscore=0 mlxscore=0 impostorscore=0 mlxlogscore=479 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003300151
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/LybkE2niPoaDybCFAR5vM1O7vyY>
Subject: Re: [nfsv4] NFS over TLS for floating clients
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 30 Mar 2020 16:27:22 -0000

Hi Rick-

> On Mar 29, 2020, at 10:16 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote:
> 
> A case I've coded up that may or may not be allowed by the current draft is:
> - Optionally, if the client presents a certificate to the server that verifies and
>   where the CN is of the form "user@dns_domain", then this "user" is translated
>   to a set of credentials used for all RPCs on the TCP connection instead of
>   what is   provided in the RPC request header. I put "user" in quotes because
>   I think you can argue that this is the identity of the client host and the server
>   chooses to assign credentials to that client identity.
>   (Basically, I'd argue that, for laptops, the line between "user" and "host" is fuzzy
>    and normally one and the same.)
> 
> As for the current draft, it says:
> (end of sec. 4.2)
> In either of these modes, RPC user authentication is not affected by
>   the use of transport layer security.  When a client presents a TLS
>   peer identity to an RPC server, the protocol extension described in
>   the current document provides no way for the server to know whether
>   that identity represents one RPC user on that client, or is shared
>   amongst many RPC users.
> 
> True, although there is the case where there is only one user on the client
> and that is known by the server administrator.
> 
> Therefore, a server implementation must not
>   utilize the remote TLS peer identity for RPC user authentication.
> 
> I would argue that this is a server implementation choice and does not
> affect the protocol.

I don't fully understand this statement, but the protocol described in
draft-ietf-nfsv4-rpc-tls forces this choice to be "does not utilize
the TLS peer identity for RPC user authentication." IMO we cannot
relax this requirement in this protocol, though it can be revisited if
RPC is made to handle user authentication with certificates: I will
be discussing that possibility during our interim meetings in April.

A connection/TLS session uses exactly one pair of certificates for its
entire lifetime: a server cert and a client cert (let's set aside the
"no client cert" case for a moment).

After the TLS session has been established, in general a client is free
to send multiple RPC user identities on that connection. Users have no
association with the certificate the client used to establish that
session.

The certificates here are used to establish secure communication between
two hosts. They are not intended to be used for authenticating RPC user
identities, period.

We do not want to alter RPC user authentication at this time. If using
a certificate to identify an RPC user is something we _do_ want to do,
and we most likely do want to allow it eventually, then that will
require a different set of changes to the RPC protocol, and not just at
the transport layer.


> (in sec. 7.3)
> In light of the above, it is RECOMMENDED that when AUTH_SYS is used,
>   every RPC client should present host authentication material to RPC
>   servers to prove that the client is a known one.  The server can then
>   determine whether the UIDs and GIDs in AUTH_SYS requests from that
>   client can be accepted.
> 
> I would argue this is what the above case does.
> 
> The use of TLS does not enable RPC clients to detect compromise that
>   leads to the impersonation of RPC users.  Also, there continues to be
>   a requirement that the mapping of 32-bit user and group ID values to
>   user identities is the same on both the RPC client and server.
> 
> Doing the above solves/avoids this problem.
> 
> I do feel the above case can be useful (optionally, not always) and I would
> appreciate comments w.r.t. it.
> If others think it is a reasonable approach, it would be nice if the draft allowed
> it, but I can leave it in the FreeBSD code, noting it is "non-RFC conformant".

IMO you should wait until the RPC protocol has a purpose-built mechanism
for user authentication via certificates, then implement a client that
presents the same certificate to establish a TLS session as it does to
identify its only user.

However, you can probably make your current proposed implementation a
little more future proof:

An NFS client should use AUTH_NONE for your use case, since the NFS
server ignores the client-provided RPC user identities. Maybe the server
should enforce the use of AUTH_NONE. That would possibly navigate around
the restriction stated in rpc-tls that the server cannot use the client's
TLS identity to make RPC user-specific authentication and authorization
decisions.

Add the following per-export controls on your NFS server implementation:

- A control requiring a TLS connection to access the shared filesystem.

- A control requiring the client to present a certificate to establish
a TLS session (ie, the server should prevent TLS with anonymous clients).

- A control that enables mapping between the client's TLS identity to a
particular user identity that already exists on your server. The mapping
should happen via NFSv4 id-mapping. Then the server can map both user-
specific or client certificates to particular local user identities.

It's significantly more secure if the server is pre-configured with
known user/client identities. Then, if the server does not recognize a
client's certificate, it rejects the attempt to establish a TLS
session.


--
Chuck Lever