Re: [nfsv4] NFS over TLS for floating clients

Chuck Lever <> Wed, 01 April 2020 20:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EC323A08B5 for <>; Wed, 1 Apr 2020 13:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yRNYuA9B9ED5 for <>; Wed, 1 Apr 2020 13:50:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D40D13A08AA for <>; Wed, 1 Apr 2020 13:50:16 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 031KhW4J047560; Wed, 1 Apr 2020 20:50:16 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=3l7VKxEMsD4gBtR8OqbGdwd8+TZrlm8qm6yIRIytgeM=; b=F7V+JXVXGrVtxvPosKoQ9oNjnZYV8fgWDP3HbTUbN3WqAb9vjhYxtLTaKIlwnopW3s6+ Rq/BLbtEOaiBapcwngB1q+7aDC11Fg4Eo0AWoaVXGODHSAPH2ldv0p/mrvZFnWh+GdkO iEIv281NnGHj0vWmXSpTDCY2mtsxYgMWeTIhYfImnPgsYx6MCqcI4+hFvP0bEHbPKcwY 3zZyKjvsWLhlIBmDefWQYUe2BIr1VRureF5j76PEDcONcb9/Htf1bs/jQwy/FhvjWavd qdl9+J671yxltDtoyrWpnobDG8Mn0E95w25+s3t2WO5zrBvcjhSNjKDDPBYWBA9tWN0N gQ==
Received: from ( []) by with ESMTP id 303cev7uhs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 01 Apr 2020 20:50:15 +0000
Received: from pps.filterd ( []) by ( with SMTP id 031Kg8fp020090; Wed, 1 Apr 2020 20:48:15 GMT
Received: from ( []) by with ESMTP id 302ga1526b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 01 Apr 2020 20:48:14 +0000
Received: from ( []) by (8.14.4/8.13.8) with ESMTP id 031KmD70014842; Wed, 1 Apr 2020 20:48:14 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Apr 2020 13:48:13 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <>
In-Reply-To: <QB1PR01MB36495316F6F1973CC18BBB55DDC90@QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM>
Date: Wed, 1 Apr 2020 16:48:12 -0400
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
To: Rick Macklem <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9578 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 mlxscore=0 spamscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004010171
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9578 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=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004010171
Archived-At: <>
Subject: Re: [nfsv4] NFS over TLS for floating clients
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Apr 2020 20:50:19 -0000

> On Apr 1, 2020, at 4:36 PM, Rick Macklem <> wrote:
> Chuck Lever wrote:
>> On Mar 29, 2020, at 10:16 PM, Rick Macklem <> 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."
> Btw, when I said "does not affect the protocol" I was referring to what goes
> on the wire. The only thing that changes in the content of the client's certificate,
> which is not covered by this document (except for where the DNS name goes).
> --> Actually I am surprised that Ben and others accept putting the DNS name in
>      the CN field of subjectName and aren't insisting it be in the DNS field
>      of the subjectAltName. (I, personally, don't care.)
>> 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.
> As you'll see below, I am not talking about user authentication, I am
> referring to what credentials are being used for an RPC, which I believe
> is a server configuration issue.
> FreeBSD NFS server have had a "-mapall" option which says "use these
> credentials for all RPCs for a very long time (since the 1980s, I think?).
>> 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.
> Yes, I understand all of the above.
>> 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.
> Yes, I understand that you do not want to address user authentication, which
> the draft clearly defines as the credentials in the RPC request header.
> Another way to put what I am doing is:
> - The server derives "machine credentials" from the client's certificate.
>  The server then chooses via server configuration what RPCs are performed
>  using these machine credentials instead of the user credentials derived from
>  the RPC request header.
> I know that Sun RPC has never had the concept of machine credentials and
> that is one reason why it has not been a great fit for NFSv4, since NFSv4 does
> use machine credentials.
> - The workaround has been for the NFSv4 server to define the user credentials
>   used for the first ExchangeID (SetClientID) operation as the machine credentials
>   that must be used.
>   For AUTH_SYS, this is typically the infamous uid == 0.
>   For RPCSEC_GSS (Kerberos mechanism), it has typically required:
>   - host based principal being created on the KDC.
>   - keytab entry for this principal being created.
>   - this keytab entry being copied to the client via some secure method.
> (I won't bother to mention what credentials actually get used for callbacks.
> I'll admit I don't even understand how to do callback user credentials via
> RPCSEC_GSS. I think most just use AUTH_SYS with uid == 0 and clients mostly
> ignore the RPC request credentials for callbacks?)
> It might make sense to look at using client certificates to create machine credentials
> in the future?
> I am fine with this not being allowed by this spec. I will simply document that.
> However, you could state:
> Creation of machine credentials from peer certificates is out of the scope of
> this document.
>> 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.
> I have no idea what you are considering, but if it is along the lines of
> clients providing separate X509 certificates for each user,
> I think that would require:
> - generation of certificates for every user
> - copying these certificates into a database on each client in some secure
>  manner.
>  - You almost have to generate a separate certificate for each user for each
>     client (ie. #clients * #users).
> --> Too much administrative overhead, in my opinion.
> It is easier (and a better fit, imho) to just use Kerberos for this case and it
> is already implemented and works.
> However, I do think that a certificate is a good fit for machine credentials,
> which is not a good fit for Kerberos (the above exercise of host based principal...).
> Having a way for clients to do a Kerberos NFSv4 mount without the host based
> principal in a keytab on the client, would make Kerberized NFSv4 easier, I think?
>>> (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.
> As above, I'm not convinced this is practical.
>> 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.
> I don't believe extant NFSv4 clients can be configured to use AUTH_NONE
> for all RPCs.

Really? mount with sec=null/none does not work?

> What I am doing should work with an extant NFSv4 client once
> it has RPC-over-TLS support (I'm assuming client's will consider the X509
> certificate is an opaque blob that is only used for the TLS handshake).
>> Add the following per-export controls on your NFS server implementation:
>> - A control requiring a TLS connection to access the shared filesystem.
> Yes, this exists in my implementation as the export option "-tls".
>> - A control requiring the client to present a certificate to establish
>> a TLS session (ie, the server should prevent TLS with anonymous clients).
> Yes, this exists in my implementation as the export option "-tlscert".
>> - 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.
> As above, I do not think user specific certificates is practical.
> (Of course, feel free to prove me wrong;-)

For the moment, I'll just say that you might be misreading what I
wrote here: take out the "user-specific" and just make it "the server
maps the client-presented transport credential to a local user
identity on the server." That might be close to what you've already

I agree that the preference in multi-user environments is a certificate
for the machine and Kerberos principals for user identities, for exactly
the reasons you stated.

>> 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.
> I also have the "-h" option on the server side TLS handshake daemon,
> which states that the client's certificate must have a DNS name that
> matches the reverse DNS name for the client's IP address.
> --> This is on the daemon and not in exports, since for this case,
>      the IP address presented by the client is not trusted and, as such,
>      the exports file cannot be applied to it until it has passed this
>      requirement. (With "-h" it follows RFC 6125 style verification, but
>      for on the server for a client certificate and not the other way around.)
> rick
> --
> Chuck Lever

Chuck Lever