Re: [nfsv4] NFS over TLS for laptops

[Rick Macklem <[e-mail]>]

Rick Macklem wrote:
>Chuck Level wrote:
>[stuff snipped]
>>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.
>Not sure what field(s) of a certificate you are referring to?
I took a look at a CRL and it appears to use SerialNumber to
refer to s revoked certificate, so I'm guessing that is what
you are referring to?

Since the serial number is per issuer and I would expect some
NFS servers will want to handle certificates from multiple issuers,
I think that the issuerName will be needed in the database key,
as well.

For the below certificate, the database key would be:
Issuer: C = CA, ST = Alberta, L = Jasper, O = MMM, OU = XXX, CN = democa.home.rick, emailAddress = [e-mail]
Serial Number: 2 (0x2)

Of course, as I think you noted, there is no guarantee that the
certificates will be correctly generated, to result in the above
referring uniquely to one certificate.

Still seems to be an Administrative Hassle to me, rick

Here is the entire certificate I created using the openssl command,
as displayed by "openssl x509 -in cert.pem -noout -text":
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 = nfsv4-new3.home.rick, emailAddress = [e-mail]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:b4:f4:44:35:ce:73:3d:76:59:ed:ec:37:51:2a:
                    37:db:3c:98:81:b9:9d:58:90:4e:86:06:14:14:58:
                    39:60:2b:c3:37:2f:fc:7d:a7:62:bf:2a:a4:dc:46:
                    16:43:c9:6e:93:7a:35:4f:31:e3:19:1b:52:c5:ea:
                    77:d5:b9:df:da:34:25:6f:b8:ce:84:a1:80:20:14:
                    d2:62:48:4d:a3:22:54:75:25:04:ab:47:09:86:83:
                    4a:b4:5d:f8:20:11:18:23:20:1a:50:10:c7:72:9c:
                    2c:9f:1c:cf:28:fe:52:84:b6:60:f3:30:d9:32:fd:
                    5b:00:85:49:7d:32:18:6c:d9:88:2e:48:e9:69:4a:
                    ea:6a:dd:a0:5a:2a:ae:b1:10:82:34:6d:37:df:3f:
                    f9:0d:5e:a5:df:b1:6c:47:c0:bc:92:9e:de:d0:c0:
                    2e:3a:85:e3:e7:7a:7e:2c:bd:b9:3f:49:3c:0e:5f:
                    a3:32:22:7b:2a:5a:45:07:49:f3:41:93:0d:bf:eb:
                    eb:bb:c4:ca:e5:cf:d3:2c:9e:f9:9e:65:09:f6:ff:
                    05:c6:10:31:b3:27:6b:a1:62:70:23:95:7c:24:72:
                    29:14:ec:38:7a:a7:6d:63:fa:38:52:45:3e:a6:8a:
                    76:13:3a:ad:db:27:75:d5:90:e3:c4:4d:e9:1f:45:
                    bb:e7
                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:
                keyid: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:<unsupported>
    Signature Algorithm: sha256WithRSAEncryption
         6c:85:34:12:32:6d:dc:54:64:51:e6:6c:7a:61:cf:19:8d:2e:
         7a:88:46:c4:d5:fd:85:53:54:a9:7d:ca:ef:81:06:99:a4:a9:
         ee:7c:c5:da:b6:63:3b:50:33:ac:7d:d5:d2:71:da:5f:6c:ec:
         d3:bf:2d:53:f3:49:03:34:3c:3e:1e:b8:7e:46:eb:8e:af:45:
         38:f8:88:86:95:43:45:34:07:bc:3d:b9:27:33:41:7c:cb:4e:
         1c:4a:8d:49:0c:22:5d:40:f0:70:15:d6:6a:1d:7a:34:44:de:
         54:62:ed:22:0c:78:9c:80:98:1d:0b:36:08:d8:2b:2e:ab:42:
         e3:bb:71:67:da:33:29:43:52:76:6a:5a:8e:02:93:f6:f3:bc:
         f1:dc:a8:40:90:3b:81:0e:f5:7b:d2:be:69:48:74:63:3f:0c:
         d7:bc:98:7a:68:bf:e3:22:d0:38:bb:fe:35:ca:bd:06:af:d0:
         ed:c3:3f:5f:5f:01:f1:aa:c5:7f:cc:de:7f:f9:32:85:87:e7:
         08:af:d0:c2:4c:78:a3:75:3d:0f:d6:36:ba:02:4c:a2:8a:bf:
         0d:15:ac:b3:92:35:09:f5:61:36:0b:f6:2f:5f:cb:f6:96:37:
         3b:98:6b:38:93:ef:82:2c:0d:21:ad:d9:4e:c7:4b:59:e5:ba:
         b0:45:d2:07


>Using the unique ID in the certificate solves that problem. These
>are like UUIDs, so they should "never" collide, for some value of
>never.
So, what in the above certificate are you referring to when
you say "unique ID"?

>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.
We are probably just going to agree to disagree on this.

>> 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?
For FreeBSD, it is:
- string compare @domain with the server's and strip it off
- call getpwnam() with "user" as argument
Yes, there is a passwd database (often in an LDAP service),
but that is already there. (Needed for the gssd daemon and
id mapper that translates the Owner and Owner_group
attributes daemon, among other things.)

>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?
New users get added to the passwd database. This is
inevitable and "ricktst" would normally already be in the database
by the time Rick has a laptop that wants to mount the
NFS server and access it. "ricktst" is just a user name in
the passwd database like any other.
(There is no administrative step beyond new user creation.)
[more stuff snipped]
>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.
To me, this is an argument for the otherName component.
A user name will be maintained as a unique name in a passwd database
and then there is no concern w.r.t uniqueness for the rest of
the certificate.

Obviously I like the otherName approach and have implemented
it for FreeBSD. I am not bothered by the fact that a "machine
certificate" also conveys a user to squash AUTH_SYS uids to
and I think that is a simpler approach than a database in the
server.
You obviously feel otherwise. Again, I believe we are at the
agree to disagree stage.

Only time will tell if other server implementors find this useful
as well.

It was fairly well received when discussed on a FreeBSD mailing
list some months ago.
[more stuff snipped]
>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.
Isn't this trusting the client to do the right thing on the first
RPC?
--> Sounds like an easy way for a malicious client to get squashing
      set to the user the client would prefer?
[more stuff snipped]

>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 do not care about overloading the X.509 certificate, if that is
convenient.
Are NFSv4.1 Sessions really an NFS specific tool or actually a
way to implement "exactly once" RPC semantics and manage
RPC transport?

>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.
Well, I posted because David Noveck asked about this.
I was not looking for this to be sanctioned.

Honestly, I am not sure the working group needs to be telling
NFS server implementors how to do TLS squashing.
--> Suggesting that TLS squashing is a useful tool for improving
      security when NFS is done via RPC over TLS may be as far
      as the working group should go.
--> There is also the suggestion of using a passphrase on the
       private key for a client's certificate to reduce the risk of
       the certificate being used after being stolen.

rick


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





_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4