Re: [nfsv4] NFS over TLS for laptops

[Chuck Lever <[e-mail]>]

> On Dec 17, 2020, at 6:58 PM, Rick Macklem <[e-mail]> wrote:
> 
> 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.

Where the principal name is constructed is an artifact of
implementation. I'm not sure how it is relevant here other
than "hey, an apple and an orange both happen to be fruits."


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

Indeed, the Introduction of rpc-tls claims that hassle is one
of the primary reasons that administrators choose not to
deploy Kerberos. The stated purpose of RPC-over-TLS is to
provide stronger security than AUTH_SYS without the hassle of
GSS.

So we're 100% in alignment on that.


> 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?

The certificate has a unique identity other than the CN. I was
thinking that unique identity was going to be the key for the
squashing mapping.


> Well, maybe, but what if there were multiple
> OUs generating certificates?

Using the unique ID in the certificate solves that problem. These
are like UUIDs, so they should "never" collide, for some value of
never.

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

IMO you are ginning up a "hassle." All of this is easily hidden
behind a single tool or wrapper GUI. I don't see that the server
implementation is much simpler, and neither is the protocol on
the wire, with otherName compared with some other mechanism.


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

How does the server map that user@domain string to a UID?

The server has to be notified of new users. This step is
avoided by otherName only if [e-mail] is already
known to the server. But, that's a separate administrative
step, isn't it?


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

What prevents that person from generating the same CN for
multiple clients? This approach is Not Scalable for more
than a few client certificates, unless there is a directory
or database (or a flat file) to keep track of them.


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

I agree in principal that a low-hassle administrative experience
is critical. I remain unconvinced that we need to add a user
name to certificates to make that happen.


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

That does not make me more comfortable: it conflates hosts
and users. TLS is a transport layer mechanism. It does not
and should not know about users.

If we want to put an administrative instruction inside a
client certificate, rpc-tls-11 provides perhaps a more
suitable mechanism: an extended usage key value (see Section
5.2.1.1). But again I ask: why is that better than relying
on the server to handle squashing by itself?

An alternate approach would be TOFU. On the very first contact,
the server would validate an unfamiliar client's certificate
and then create a user mapping using the first user@domain
or UID that the client presents. After that, the server
squashes all RPC users from that client to that initial user.


>> 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.)

That analogy is exactly what the MUST NOT in rpc-tls is seeking
to avoid. TLS is a transport layer mechanism that knows only
about hosts. RPC user identity is never the concern of the TLS
layer.

I'm not arguing against the idea of TLS identity squashing.
The usage scenario is an obvious and common one.

What I'm struggling with is why the WG should sanction an
approach to addressing this scenario that is specifically _not_
compliant with the spec, particularly when there are other
ways to implement this behavior that are based on mechanisms
that many servers already have implemented.


>>>> - 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?

The client wouldn't present its certificate again. The text of
rpc-tls already states that the server-side TLS implementation
should make the client's TLS identity available to the RPC
consumer. The new state_protect_4a value might indicate "please
use the client's TLS identity to ensure that another client
cannot mess with the lease I am about to establish."


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

The point is that we don't want "any" certificate to purge or
alter this client's lease. We want only this client to be able
to alter its own lease.

Another client could send an EXCHANGE_ID using the same
nfs4_client_id string. Unless the first client's lease is
protected, the server might believe that the first client
has rebooted, and purge its lease.


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

This is not about injecting lease operations into a TLS
session. It's about protecting against rogue or misconfigured
clients misidentifying themselves on a separate connection
and thus causing the server to purge a legitimate client's
opens and locks. (Ie, CLID_INUSE).

"I'm Brian, and so's my wife!"


> --> 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

--
Chuck Lever