Subject: [nfsv4] NFS over TLS for floating clients

From: Rick Macklem <[email-masked]>
Date: Fri, 6 Mar 2020 03:06:02 +0000

Hi,

As I am working through implementation of NFS over TLS, I have run into
a couple of things related to certificates.
Here's an example scenario:
- The client is a laptop that wants to mount a server from "anywhere" using
  TLS, so that data is encrypted on the wire.
  The server understandably wants to use "mutual authentication" to determine
  that the client is indeed one that is allowed to mount the server.

Ok, so now how do you get a certificate for the client that the server can
reasonably verify?
--> After a discussion over on a FreeBSD mailing list, it sounds like the easy
      (maybe only?) way to do this is for the NFS server admin. to run a site local
      CA and generate certificates against that.
      - Although I'm sure there are other ways, you can create a site local CA
         certificate with two openssl commands and sign a certificate for a client
         with two more openssl commands.
     Then the server can verify the certificate using the CAcert that was used to
     sign the client's certificate.

Now, when I read the sections around Page 6 of the draft...
   Mutual Host Authentication
      In this type of deployment, the client possesses a unique global
      identity (e.g., a certificate).  As part of the TLS handshake,
      both peers authenticate using the presented TLS identities.  If
      authentication of either peer fails, or if authorization based on
      those identities blocks access to the server, the client
      association MUST be rejected.
For the above, the client does not possess a unique global identity,
it might more correctly be called a "site local identity" that the server
can authenticate.
Is the "unique global identity" requirement necessary? It seems to me
that a site local CA issued certificate might be appropriate.
(RFC 5280 page 12, second (a) item seems to allow site local CA
 certificates).

Also, w.r.t. server certificates, the draft says:
   Each RPC server that supports RPC-over-TLS MUST possess a unique
   global identity (e.g., a certificate that is signed by a well-known
   trust anchor).  Such an RPC server MUST request a TLS peer identity...
I wonder if the above must be a MUST?
For example, I have an NFS server at home. It doe not have a well known
fixed DNS address (residential internet connection, where it sits behind
a NAT gateway where the address stays the same most of the time).
--> If I want to mount this server from anywhere, I do want to use TLS
      so that data is encrypted on the wire. Although it would be nice for
      the laptop to be able to verify the server's identity, I don't see how I
      can get a certificate for it from a well known trust anchor. I can live
      with it having a self-signed certificate.

Also, although an NFS server administrator can get a certificate from a
well known trust anchor, it might cost $$ or it might not be easy. (Lets
Encrypt expects to be able to use ACME on a web site or similar to issue
a certificate, if I understand their setup?)

Acquiring a certificate from a "well known trust anchor" might be a
significant effort that will discourage use of TLS. (Again, you can easily
create a self-signed certificate with a couple of openssl commands.)
--> Maybe this could be a recommendation instead of a MUST and
       the choice of accepting a self-signed certificate be left up to the
       client via configuration?

So, what do others think about this? rick

---

From: Chuck Lever <[email-masked]>
Date: Fri, 6 Mar 2020 11:59:17 -0500

Hi Rick-

Just a couple of observations below.

> On Mar 5, 2020, at 10:06 PM, Rick Macklem <[email-masked]> wrote:
> 
> Hi,
> 

"unique global identity" is probably overkill. It's text I made up.
I am willing to replace it with a term that encompasses site local
identities as well. We absolutely want this to work with self-signed
certs, although that's not going to provide an ultimate degree of
security.

>       client via configuration?

In a Proposed Standard, IMO we want to keep very strong security
recommendations. An implementer or administrator is of course free
to ignore these requirements, at some risk to them.

--
Chuck Lever

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Fri, 6 Mar 2020 18:08:41 +0100 (CET)

Well, you certificate contains your public key which is (in combination with
your private key) a global identity, other wise the whole PKI staff is dead.

Tigran.

----- Original Message -----
> From: "Chuck Lever" <[email-masked]>
> To: "Rick Macklem" <[email-masked]>
> Cc: "NFSv4" <[email-masked]>
> Sent: Friday, March 6, 2020 5:59:17 PM
> Subject: Re: [nfsv4] NFS over TLS for floating clients

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 6 Mar 2020 14:07:33 -0500

>      sign the client's certificate.

It really boils down to the question of who do you trust to assert
what information.

If you own a domain, you can usually buy SSL certificates for it that
assert a given name within that domain. As long as you trust the major
CA vendors not to sell such a certificate to someone who does not own
the rights to the domain, then you might have your server use that
chain of trust to verify that this is indeed a trusted laptop. You
might decide to compare the full name appearing in the certificate to
a trusted list, or maybe just verify that the domain or subdomain info
matches a list of trusted domains or subdomains. Yes, you can do this
more cheaply by creating your own site-local CA, but it is essentially
the same process of setting up a chain of trust for your source of
information and then of asserting that information in a certificate.

> (RFC 5280 page 12, second (a) item seems to allow site local CA

It might be better to word in terms of the language of chains of
trust. "...the client possesses an identity (e.g. a certificate) that
is backed by a trusted entity."

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 6 Mar 2020 15:07:21 -0500

On Fri, 6 Mar 2020 at 14:37, Craig Everhart <[email-masked]> wrote:
>
> I think the problem statement contains the issue here:
> What attribute is the server looking for that will "allow" the server to be mounted?
> And can it be done anonymously, which this "anywhere" laptop really wants to be?
>
> Note that on-the-wire encryption will be done even if there is no client certificate--as long as the server has a certificate (or if the client/server are using a pre-shared key, which is a little further afield).
>
> If the client owns a domain, somehow, then the PKI machinery is available to it; a certificate will allow it to prove that it is able to speak for that domain name.  Is that what's being checked as this stuff about "allowing" the mount?
>
> I think that there's a problem with the NFS server wanting to know much about the client, unless it's limited to a DNS name.

The main purpose I can see for wanting to authenticate the client to
the server is to decide whether or not to allow user authentication
through weak mechanisms that rely on trust of the client itself (i.e.
AUTH_SYS). However there are also several mechanisms today that rely
on IP and port number tracking to identify clients (e.g. the duplicate
reply cache and side band protocols such as lockd, statd, mounts) and
that could benefit from stronger client identification. Ditto the
NFSv4.0 callback mechanism, and the NFSv4 lease mechanism.

We already agreed that describing how to modify NFSv4 etc,  is out of
scope for this document, but these are all motivations for ensuring
that this document should describe how we might go about identifying
clients.

> Craig
>
> On Fri, Mar 6, 2020 at 2:08 PM Trond Myklebust <[email-masked]> wrote:
>>

---

From: Rick Macklem <[email-masked]>
Date: Fri, 6 Mar 2020 22:47:29 +0000

Craig Everhart wrote:
>Note that on-the-wire encryption will be done even if there is no client certificate--as long as >the server has a certificate (or if the client/server are using a pre-shared key, which is a little >further afield).
Yes, but I wouldn't be comfortable with "any" client mounting from anywhere.

>If the client owns a domain, somehow, then the PKI machinery is available to it; a certificate >will allow it to prove that it is able to speak for that domain name.  Is that what's being >checked as this stuff about "allowing" the mount?
Well, I didn't envision the laptop owning a domain, but I suppose that might work.
(Since the laptop's IP address/DNS host name wouldn't match this domain, it sounds
 a bit sketchy, but so is the use of a certificate signed by the NFS admin using a site
 local CA, see below.)

>I think that there's a problem with the NFS server wanting to know much about the client, >unless it's limited to a DNS name.
Well, my thinking is that, if the NFS admin. is running a site local CA and the client has
a certificate signed by that site local CA, then the certificate must have been issued by
the NFS admin. I don't think the contents of the certificate is of much use in this case,
just the fact it was signed by the NFS admin. using the site local CA.
Creating the site local CA just seems easier and cheaper than trying to register a
domain name for a laptop and getting a certificate signed by a trusted CA.
After all, some of the motivation for doing NFS over TLS is that NFS admins. don't
seem willing to run KDCs, etc and use sec=krb5p. To get it widely adopted, I think
it needs to be relatively simple to set up and use.

Obviously, if the laptop is compromised and the certificate signed by the site local CA
is copied to a different system, then that system could mount the server.
(I think exactly the same risk exists for a certificate for a domain owned by the laptop
 and signed by a trusted CA. ie. Copy the certificate to a different system and it
 would allow that system to mount the server.)
Whether or not that is an acceptable risk is up to the NFS admin, I think?

rick
Craig

On Fri, Mar 6, 2020 at 2:08 PM Trond Myklebust <[email-masked]<mailto:[email-masked]>> wrote:

> [email-masked]<mailto:[email-masked]>

_______________________________________________
nfsv4 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Rick Macklem <[email-masked]>
Date: Fri, 6 Mar 2020 22:53:04 +0000

>your private key) a global identity, other wise the whole PKI staff is dead.
Yes, I suppose this is true. I'll admit when I read "unique global identity" I
thought DNS domain name, since that is what the trusted CAs are signing
off on, if I understand it correctly. (Which I might not, since I'm new to this
stuff and definitely not a security guy.)

rick

Tigran.

---

From: Rick Macklem <[email-masked]>
Date: Fri, 6 Mar 2020 23:02:32 +0000

>Just a couple of observations below.
[good stuff snipped]
>I wrote:
Sure, I can live with this.

My only concern is, that if it sound difficult to do, the NFS admins. won't
bother, similar to not bothering to set up KDCs.

Thanks for the comments everyone, rick

--
Chuck Lever

---

From: "Mkrtchyan, Tigran" <[email-masked]>
Date: Sat, 7 Mar 2020 16:55:55 +0100 (CET)

----- Original Message -----
> From: "Rick Macklem" <[email-masked]>
> To: "Chuck Lever" <[email-masked]>
> Sent: Saturday, March 7, 2020 12:02:32 AM

> bother, similar to not bothering to set up KDCs.

Running a local CA is much simpler than KDCs and there are plenty of tools, including
hard-core openssl or cfssl toolkit from cloudflare. The main different it that you never
need an additional central server, like in case of kerberos. Thus I can just create
a self-signed server and client certificates and have a secure NFS within minutes.

Regards,
   Tigran.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 28 Mar 2020 18:50:25 -0700

It looks like the quoting got a little jumbled, but I'll drop a few
thoughts inline.

> Yes, but I wouldn't be comfortable with "any" client mounting from anywhere.

The NFS server can decide which X.509 CAs it will trust to issue
certificates that it wants to use.  Whether this is a "well-known global
CA" or a local one is just a matter of configuration, and doesn't really
need to be nailed down at a protocol level.

>  a bit sketchy, but so is the use of a certificate signed by the NFS admin using a site

There's a little bit of a mismatch between what TLS client certificates say
and what TLS server certificate say, at least in the common class of usage.
If you read RFC 6125, you note that it *only* talks about naming TLS server
certificates, because the process for that is along the lines of "the
client figures out in some mechanism specified by the application protocol
a name that it's trying to contact, and the server has to present a
certificate that matches that desired name".  For client certificates, on
the other hand, the server may not have some preconceived notion of what
identity the client should be proving, and so the X.509 certificate serves
solely as an identifier, not a verification of identity.  In this sense,
depending on the server's authentication policy, there's not necessarily a
need for the client to have a well-known IP address or DNS name to validate
against.

> Whether or not that is an acceptable risk is up to the NFS admin, I think?

It's also possible to put the private key for the certificate in a
protected hardware module on the laptop, so that the key cannot be copied
elsewhere (and thus the copied certificate would not be useful).

> is backed by a trusted entity."

I think there's a few different ways to word this, and don't expect us to
be particularly sensitive to the details of the wording.  As Tigram(IIRC?)
noted upstream, the combination of issuer, key, and subject name really
will be globally unique, so the current wording doesn't seem technically
wrong, albeit an unusual way to phrase it.

-Ben

---

From: Rick Macklem <[email-masked]>
Date: Mon, 30 Mar 2020 02:16:46 +0000

>need for the client to have a well-known IP address or DNS name to validate
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.

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

>elsewhere (and thus the copied certificate would not be useful).
I'll admit I know nothing about protected hardware modules, but it is easy
to have the client's private key encrypted so that the user must enter a
passphrase when they start the daemon to unencrypt the key.
--> A bit of a bother, but not that bad for a laptop.
   (Of course, if the client laptop is compromised, the typed in passphrase could
    be captured, but this handles the simple case of the key, certificate being copied
    to a different laptop.)

Also, for my CN set to "user@dns_domain" case, the certificate only allows access
to the NFS server as "user" and is less useful if compromised.

Thanks for your comments, rick

-Ben

---

From: Chuck Lever <[email-masked]>
Date: Mon, 30 Mar 2020 12:27:14 -0400

Hi Rick-

> On Mar 29, 2020, at 10:16 PM, Rick Macklem <[email-masked]> wrote:
> 

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.

> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 30 Mar 2020 19:53:20 -0700

>    where the CN is of the form "user@dns_domain", then this "user" is translated

Oof, could I persuade you to go with a subjectAltName instead?  Putting
structure within (or really, using at all) the legacy subject CN is
generally disrecommended.

>     and normally one and the same.)

This is a unique-enough usage that I'd recommend a dedicated OID for the
"otherName" SAN type.

> I would argue that this is a server implementation choice and does not

I'm inclined to agree with Chuck -- this is passing information across
layers of the protocol stack in a way that is not well understood, and the
spec forbids it because of the potential for hazardous consequences.

> I would argue this is what the above case does.

I would frame it differently, in that the client is authenticating itself
and the server is (possibly implicitly) restricting that client to only
allow AUTH_SYS authentication to a specific subset of users (possibly only
one).  But it's the client that authenticates with host credentials and
asserting user identity, and the server trusting the client to faithfully
represent the user identity.

>     be captured, but this handles the simple case of the key, certificate being copied

"PKCS #11 hardware token" is probably the best search term to start with.
(There is at least one implementation that uses software to emulate this
interface as well, for testing.)

> to the NFS server as "user" and is less useful if compromised.

It's also possible to define a new certificate purpose via X.509 extension
for NFS use.  I'd have to reflect a bit more on whether that's the right
thing to do here (and possibly consult the LAMPS WG as well).

-Ben