Re: [nfsv4] NFS over TLS for floating clients

[Rick Macklem <[e-mail]>]

Mkrtchyan, Tigran wrote:
>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.
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.

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

> Hi Rick-
>
> Just a couple of observations below.
>
>> On Mar 5, 2020, at 10:06 PM, Rick Macklem <[e-mail]> wrote:
>>
>> 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).
>
> "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.
>
>
>> 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?
>
> 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.
>
>
>> So, what do others think about this? rick
>
> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4