Re: [nfsv4] NFS over TLS for laptops

[Rick Macklem <[e-mail]>]

Chuck Lever wrote:
>Rick Macklem wrote:
>> Yes. My understanding is that the tuple <issuerName, subjectName>
>> should be uniquely assigned to a certificate.
>> As such, an NFS server admin. could maintain a database keyed on that
>> tuple, which could be used to constrain access in a manner analogous
>> to an exports file, but for TLS clients that present certificates during TLS
>> handshake.
>> --> I think this would be more effort to implement and, more importantly,
>>       more effort for a NFS server admin. to maintain.
>>       --> What I implemented simply uses the user database that
>>              will normally already exist and the same technique as the gssd
>>              already uses for Kerberos user principals.
>
>At least for the server implementations I'm familiar with,
>I don't see much difference between the current GSS cases and
>needing to add server-side per-user information to deal with
>TLS identity squashing.
Note that, for Kerberos, that the principal name is in the Kerberos
ticket, which is in the token generated by gss_init_sec_context() and
passed to the server.

Also, as an aside, we know that many sites do not use Kerberos.
We probably do not know why, but I suspect that "Administrative
Hassle" is a significant factor.

Here's a certificate I use for testing. (Note that rick.home is not a real
DNS domain, but just what I use for my systems sitting behind a NAT
gateway.)
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = CA, ST = Alberta, L = Jasper, O = MMM, OU = XXX, CN = democa.home.rick, emailAddress = [e-mail]
        Validity
            Not Before: Dec 17 05:08:33 2020 GMT
            Not After : Dec 17 05:08:33 2021 GMT
        Subject: C = CA, ST = Alberta, O = MMM, OU = XXX, CN = nfsv4new3.home.rick, emailAddress = [e-mail]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:b4...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                25:80:CA:0F:CD:13:23:4B:5D:57:3D:7E:AF:8C:AE:E9:78:36:4C:84
            X509v3 Authority Key Identifier: 
                38:92:2D:6C:DC:83:1B:37:6F:C0:9C:8C:FE:D8:54:76:91:F6:BC:70
            X509v3 Subject Alternative Name: 
                othername: 1.3.6.1.4.1.2238.1.1.1::[e-mail]

Now, could you get away with using only the CN field as a key for your
TLS squashing database? Well, maybe, but what if there were multiple
OUs generating certificates?
--> I think it is safer to use the whole subjectName. We can use the
    "oneline" format that OpenSSL can use.
/C=CA/ST=Alberta/O=MMM/OU=XXX/CN=nfsv4-new3.home.rick/emailAddress=[e-mail]

there should also be an issuerName in the key, so it end up looking
something like:
/C=CA/ST=Alberta/O=MMM/OU=XXX/CN=democa.home.rick/emailAddress=[e-mail]
/C=CA/ST=Alberta/O=MMM/OU=XXX/CN=nfsv4new3.home.rick/emailAddress=[e-mail]

and the above key refers to [e-mail]

So, all think all of the above needs tp be entered  in the database for each
certificate where TLS squashing is done, if there is no otherName field.

Seems like "Administrative Hassle" to me, especially if the NFS server
admin is not also the person generating the CSRs for certificates.

But, if the otherName field is done as it is for the above certificate,
the information (ie [e-mail]) is right in the certificate.
--> No database needed.

> The tooling might be a little different,
>but in both cases we are adding a user mapping mechanism, and
>that means updating a database or directory somewhere.
When the information is in the cert., no database nor directory
is needed. Only the person generating the CSR for certificates
needs to know about the mapping info.
--> Press the Easy Button.

>So I think we agree that AUTH_SYS with TLS has a significant
>weakness that leaves NFS-served data content vulnerable if a
>client cert is stolen. Thank you for pointing that out!
Yes.

>We likely disagree on whether the client cert should present
>the squashed user identity, or whether the server should be
>responsible for mapping operations for that user based on a
>trusted user mapping database (eg, KDC or LDAP).
Well, as I tried to show above, putting "[e-mail]" in
the certificate avoids a lot of "Administrative Hassle" and I
think that is important to encourage adoption.

As for what the server chooses to do with "[e-mail]"?
That is up to the server implementation, just as it currently is
for Kerberos principal names.

>Server implementations have had user identity mapping and
>squashing capabilities for a very long time, so the latter
>approach feels more natural to me.
Done based upon client IP address/DNS name traditionally.

If it makes you more comfortable, you can consider
"[e-mail]" as the client machine's name,
because it has no fixed IP address/DNS name and
then the server chooses to do squashing based on that.

>Further, the server already has to know a priori how to map
>user@domain to a UID whether or not it supports RPC-over-TLS.
Exactly. Again "Hit the Easy Button".
--> The NFS server could choose some entirely different mapping
      for the client's name of [e-mail], but the above
      mapping is the easy/obvious one.

>Otherwise the server has to squash an unknown identity to
>something anonymous like nobody.
Refusing to allow access would be preferable to "nobody"
access when there is no good TLS squashing mapping for
[e-mail] I think.

>Is there another benefit to an otherName vs. a server-side
>mapping approach that I'm missing?
Both are server-side mappings.
All the otherName case I've done does is simplify the mapping
mechanism. (It basically puts the "principal" name in the certificate,
analogous to the "principal" name that is in the Kerberos ticket.)

>>> - For NFSv4, there's a separate authentication for SETCLIENTID /
>>> EXCHANGE_ID, which must present consistent authentication material
>>> across client reboots. Usually that's the client's root user,
>>> though that could also be rmacklem in this case. Which is your
>>>implementation doing?
>> rmacklem. The FreeBSD server implementation will optionally not allow
>> non-NULL RPCs to be done from a client without TLS being enabled on
>> the TCP connection and that option would always be used for this case.
>> --> All compounds, including the EXCHANGE_ID etc will be done as the
>>      squashed user.
>> Btw, although not widely adopted as far as I am aware, FreeBSD does allow the
>> NFSv4 client mount to be done using Kerberos, but where all RPCs including
>> EXCHANGE_ID etc use the Kerberos user principal's TGT, avoiding the
>> need for a host based credential in a keytab on the client.
>> --> rmacklem would do EXCHANGE_ID etc for this case as well.
>
>Sure, just as long as the same "principal" is presented to the
>server when the client needs to recover its lease state, that
>should work fine.
>
>>> This is an area that might be tackled by
>>> an NFSv4-on-TLS document that can in fact require that an NFS
>>> server map the client's identity to a particular lease.
>> Not sure what you mean here?
>> My understanding of the NFSv4 RFCs is that the same user that does
>> the EXCHANGE_ID/SET_CLIENT_ID must be used for the others like
>> DESTROY_CLIENTID/RENEW.
>>
>> --> For 4.0 there is Renew, but for 4.1/4.2 anyone doing Sequence is
>>       sufficient. Were you thinking of Renew for 4.0?
>
>So I was thinking of enabling a server to use the client cert instead
>of the GSS or AUTH_SYS RPC credentials for authenticating all of
>these operations.
>
>Dave Noveck suggested we might add this to the EXCHANGE_ID operation
>as a new state_protect_4a value, or simply some additional language
>in RFC 5661bis explaining how to use the client certificate with an
>existing state_protect_4a value.
Why would the client need to present the certificate again, after TLS
handshake?
If the NFS server applies the following rule for the client:
- All non-Null RPCs must be done within a TLS session.
Then any certificate that verifies and was presented during the TLS
handshake for that session can be used to authenticate these operations.
(ie I do not see a need for the client to resend the certificate.)
--> Again, I think that a name like [e-mail] from the otherName
      would be easier to manage than the entire issuerName/subjectName,
      but either would work, I think?

To be honest, it should be very hard for a malicious
client (or malicious user on a legitimate client) to generate/inject 
a bogus RPC into an established TLS session/TCP stream.
--> If the client is required to present a certificate that verifies during
       TLS handshake, the malicious case will need access to that
      certificate.
      --> If the malicious client has a certificate, it can send it to the
             server whenever it likes, so sending it again during
             EXCHANGE_ID is not going to help, I think?

>More discussion is needed here.
Yes, as above.

Hopefully others will chime in w.r.t all this stuff, rick


>> In addition:
>>
>> Is TLS identity squashing going to cause interoperability problems
>> or loss of security in environments that don't support it?
> I suppose there might be confusion caused by one server doing
> all RPCs as "rmacklem" and another doing the RPC as whatever
> uid is in the AUTH_SYS RPC authenticator.
> -->This would be no more so than different servers having different
>      squashing rules in their exports file.
>
> If an NFS server chooses to trust the client's identity due to its
> presentation of a verifiable certificate but not its IP address/DNS name
> then, without TLS squashing, a stolen client certificate could provide
> cart blanche access to the server (assuming AUTH_SYS).
> This would result in weaker security than with "TLS squashing" and
> also weaker that if the client uses RPCSEC_GSS/Kerberos.

Agreed.


>> What is our thinking about how certificates might be used to handle
>> RPC user authentication?
> --> I posted about this once before and, in my opinion, using more than
>      one certificate per TLS session/TCP connection is not practical.
>      To do so, something like RPCSEC_GSS with X509 mechanism
>       would need to be implemented. The client would need to have
>       a database of certificates for different users. A compromised
>       client system would compromise all those users, etc and so on.
>       --> For this we have Kerberos and it works. Doing RPCSEC_GSS
>             with X509 mechanism would require a lot of implementation work
>             and the result would be less secure and as much effort to manage
>             as using Kerberos, I think.

Agreed, IIRC that was the consensus a year ago.


> --> For a small number of different users (I would be concerned with
>      scaling this to a large numbesr of users), they can simply use
>      separate TLS sessions/TCP connections. Each of these could
>      present a different client certificate during TLS handshake and
>      then "TLS squashing" can be applied to each of them, squashed
>      to the appropriate user.
>
>> Will TLS identity squashing conflict with that future?
> As above, I think "TLS squashing" would be an appropriate
> mechanism for this.
>
> rick
> ps: If anyone is interested in the various options I have implemented, you can
>     look at https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt

Thank you Rick, I'll take a look.

--
Chuck Lever