Subject: [nfsv4] NFS over TLS for laptops

From: Rick Macklem <[email-masked]>
Date: Sun, 13 Dec 2020 00:02:02 +0000

Hi,

David Noveck emailed me w.r.t talking about this at a future meeting.
This sounds rather scary to me, so I figured I'd post here and then, if
others want me to, I can try to attend a "virtual meeting".
First off, the disclaimer that I am neither a security guy nor TLS guy.

The case I was trying to address was mobile device (aka laptop)
mounts to an NFS server using TLS. These devices are assumed to
have two properties:
- Used by a single user.
- Connecting to the Internet from anywhere (ie. no fixed IP nor
   DNS name).

Typical filtering at the NFS server via client IP address obviously cannot work, so
what can be done?

1 - The NFS server admin. creates an x509v3 certificate via a site
      local CA for the laptop, which is stored on the laptop.

      --> When the laptop mounts the server via TLS, the NFS server
             verifies this certificate acquired during the TLS handshake
             from the laptop.

Ok, so at least the server knows that the laptop has a certificate created
by the server admin. How can this be compromised?
--> The trivial case would be the laptop being stolen or similar.
       If the CA admin. creates the private key for the laptop's certificate
       with a passphrase (something like the "-aes256" option on the
        openssl command used to create it), then the user will need to
       enter the correct passphrase before the client side daemon that
       does the TLS handshake can run.
       No daemon-->no handshake-->no TLS.
--> An attacker could still install something like a "trojan horse", that
      would pretend to be the daemon and capture the passphrase
      when the laptop user types it in.

Now, for the part that might be considered a violation of the "soon
to be an RFC" draft.
2 - When the site local CA admin creates the certificate for the laptop,
     put an otherName component in  subjectAltName that looks like:
      1.3.6.1.4.1.2238.1.1;UTF8:[email-masked]

      Now. if the daemon that does the TLS handshake on the NFS server
      is started with the "--certuser" option, it will take the
      [email-masked] from the client's certificate and translate
      that to a POSIX <uid, gidlist> credential on the serve in a manner
      analogous to what the mapper daemon (think rpc.imapd) and gssd
      does for a Kerberos user principal.
      --> Strip off @uoguelph.ca as the local domain and then get the
            POSIX credentials for "rmacklem" from the user/group databases.

Now, all RPCs done on this TLS/TCP connection use the above POSIX
credentials instead of the contents of any AUTH_SYS credential in the
RPC request header.
--> FreeBSD has for a long time had a "-mapall" export option which
       is similar to root squash, but happens for all uids. However this
       doesn't work for this case, since exports are based on client IP
       address.

       This is similar to that, but using the information in the client's
        machine certificate to decide what to squash the AUTH_SYS
        credentials to.

This limits the damage done if a laptop is compromised to that
which can be done by that user (aka rmacklem) against the NFS server.

Now, how does this compare with "sec=krb5" for this laptop case?
--> Well, if the device is compromised such that a "trojan horse" can capture
       the latop key's passphrase can the same be done on it for login/kinit
       to capture the Kerberos password for the user principal the laptop's
       user uses?
       I think so.
       --> If the user principal's password is compromised, then access to the
              server as that user is acquired.

        Also, this would require the KDC be accessible from "the world", which
        sounds pretty scary to me.

This seems comparable to the mobile device's certificate being compromised,
which allows NFS server access as the user in the otherName component of
subjectAltName.
Seems like the level of risk is about the same?

For Kerberos, the user's password can be changed to stop the compromised
access. For the certificate being compromised, the site local CA admin. can
put the certificate in the CRL for the site to stop the compromised access.

Anyhow, I am about as far from a security guy as you can get, so I may be way
off w,r.t the above.

Also, the NFS over TLS code in FreeBSD is still considered "test" (it uses
OpenSSL3, which is alpha test at this time), so I can easily change things
if others have a better idea.

I will document this as "non-RFC conformant" if that appears to be the case.

rick

---

From: David Noveck <[email-masked]>
Date: Sun, 13 Dec 2020 07:08:40 -0500

On Sat, Dec 12, 2020, 7:02 PM Rick Macklem <[email-masked]> wrote:

> This sounds rather scary to me,

 Not sure why we you think we are so scary.

sooooo I figured I'd post here and then, if
> others want me to, I can try to attend a "virtual meeting".

I'd like to have your proposal discussed, but, if you don't want to
actually present, it is ok.
I just need you to decide in the next week so I can put together an agenda.

That's not a problem. A security guy would just tell us we suck.  A TLS guy
is going to be attending tls meetings, but will be needed to review your
proposal if the working group decides to pursue it.

> - Connecting to the Internet from anywhere (ie. no fixed IP nor

Secure use on the internet was an official goal of RFC 3530 published
4/2003.  Sigh!

> Typical filtering at the NFS server via client IP address obviously cannot

The old answer was RPCSECGSS but we seem to be stuck with AUTH_SYS which is
one reason security people tell us we suck.

The working group has to decide how to retain AUTH_SYS, with acceptable
security. As I see it your proposal has a possible role in that

> Now, for the part that might be considered a violation of the "soon

Unless you are quoting someone else, you are misquoting me.  I never said
"soon". Rpc-tls is in rfc-editor state and so is an rfc-to-be.

Whether your proposal is in conflict with rpc-tls should be first addressed
with its editor

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

---

From: Rick Macklem <[email-masked]>
Date: Sun, 13 Dec 2020 17:30:27 +0000

David Noveck wrote:
>On Sat, Dec 12, 2020, 7:02 PM Rick Macklem  wrote:
>>Hi,
>>
Heh, heh. It's not you guys that are scary, it's the technology that's scary.
In January, I'll probably be living in a room with flakey wifi.
I don't currently have a microphone (just earphones). Buying such a thing
may be somewhat challenging, given my location and the pandemic.
The last order I did with Amazon took a month and the nearest Walmart
is 200km away, but I can get that done, if I need to.
I've also never used any of these systems like Zoom.
(I really do still use "ed" as my main text editor and I hate using my phone.;-)
I'm worse at tech stuff than any teenager...

So, I'll wait a week and see what others might say about this.

I'll also note I didn't exactly intend this as a proposal, but I suppose there
is a thin line between what I am testing and proposing it for others.

rick

I'd like to have your proposal discussed, but, if you don't want to actually present, it is ok.
I just need you to decide in the next week so I can put together an agenda.

That's not a problem. A security guy would just tell us we suck.  A TLS guy is going to be attending tls meetings, but will be needed to review your proposal if the working group decides to pursue it.

Secure use on the internet was an official goal of RFC 3530 published 4/2003.  Sigh!

The old answer was RPCSECGSS but we seem to be stuck with AUTH_SYS which is one reason security people tell us we suck.

The working group has to decide how to retain AUTH_SYS, with acceptable security. As I see it your proposal has a possible role in that

Unless you are quoting someone else, you are misquoting me.  I never said "soon". Rpc-tls is in rfc-editor state and so is an rfc-to-be.

Whether your proposal is in conflict with rpc-tls should be first addressed with its editor

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

---

From: Chuck Lever <[email-masked]>
Date: Mon, 14 Dec 2020 11:30:26 -0500

Hi Rick!

> On Dec 12, 2020, at 7:02 PM, Rick Macklem <[email-masked]> wrote:
> 
> Hi,
> 

Disclaimer: I'm also not really much of either. The goal of
this exercise would to get help from real experts to understand:

- Your use case and threat model
- Is your proposed solution secure?
- If it adds sufficient value, can it be made interoperable?

Pursuing this discussion further on the list before the meeting
seems prudent.

> - Connecting to the Internet from anywhere (ie. no fixed IP nor

I agree that this is an interesting and common use case, though
it might need another bullet or two to characterize fully. More
below.

> Typical filtering at the NFS server via client IP address obviously cannot work, so

Our vision is that a TLS-enabled NFS service would be unlikely
to filter based on IP address. Such an NFS server either
allows the cert presented by a client, or the server tells
that client to pound sand. That's part of the TLS handshake.

IIRC a client cert don't have to contain a domain name or IP
address that matches the network endpoint that presents that
cert. Unlike RPC-over-TLS server certs.

> credentials instead of the contents of any AUTH_SYS credential in the

Here you want to introduce an additional constraint so that the
holder of a client certificate may act only as a single user
identity on the NFS server. The server itself would force that
constraint. For convenience of narrative, I'll refer to this as
"TLS identity squashing".

- Kerberos already provides this kind of constriction, but
  RPC-over-TLS with AUTH_SYS by itself does not. Have we
  documented this AUTH_SYS limitation somewhere? Would it be
  non-repudiation or something else?

- Since that client certificate is already unique, otherName isn't
  a requirement for this constraint to work. The client's identity
  is supposed to be exposed to the NFS server, which can be
  configured to constrain that client's activity to a single user.
  otherName seems to be an administrative convenience (and I think
  you alluded to that somewhere else).

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

In addition:

Is TLS identity squashing going to cause interoperability problems
or loss of security in environments that don't support it?

What is our thinking about how certificates might be used to handle
RPC user authentication? Will TLS identity squashing conflict with
that future?

> I will document this as "non-RFC conformant" if that appears to be the case.

I'm having trouble remembering exactly why we decided on MUST NOT
there. 2020 has been a long year.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Tue, 15 Dec 2020 02:46:07 +0000

>Hi Rick!
Hi Chuck
>- Is your proposed solution secure?
Is anything secure?;-)
It is definitely more secure than AUTH_SYS or a TLS session where
the client does not present a verifiable certificate.

As noted, with "TLS squashing" I think it is about the same as RPCSEC_GSS
with Kerberos mechanism. Without "TLS squashing" a malicious client using a
stolen certificate/key would be able to use AUTH_SYS to authenticate as any user
and that will not happen when a client uses a "stolen" Kerberos TGT, making it
less secure than Kerberos.

Another area that can make it less secure would be the creation of client
certificates with long validity durations. A Kerberos TGT is typically valid
for 24hrs, whereas a X.509 certificate is typically 30days or more.
Of course, the validity duration can be set to any duration for both cases.

>- If it adds sufficient value, can it be made interoperable?
For the client, I do not think there is going to be interoperability issues.
The FreeBSD client side TLS handshake daemon (I call it rpc.tlsclntd) and
I suspect most others simply handles the client certificate as an opaque blob
that it presents to the server during TLS handshake.

If there are standardized ways for the server to handle the  client certificate's
information (subjectAltName->otherName for my use case), then the same
client certificate could be used against multiple server implementations,

>that client to pound sand. That's part of the TLS handshake.
Btw, it's a little off topic, but I do think there is a use case for TLS,
where the NFS client does not have a certificate.
--> Server trusts the client's identity via it's IP host address, but
      encryption on the wire is desired.
-->The harder we make deployment of NFS-over-TLS, the less likely
     it will be adopted.

>cert. Unlike RPC-over-TLS server certs.
I agree. For FreeBSD's current implementation, this is optional and
obviously cannot be done for mobile devices.

>  RPC-over-TLS with AUTH_SYS by itself does not.
Yes, as Inoted above.

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

>  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 as far as I am aware, FreeBSD does allow the
NFSv4 client 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 for this case as well.

> This is an area that might be tackled by
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?

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

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

--> For a small number of different users (I would be concerned with
      scaling this to a large number 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.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Tue, 15 Dec 2020 15:54:26 +0000

Oops. Here's a slightly updated reply with some typos/missing words added.

________________________________________
From: nfsv4 <[email-masked]> on behalf of Rick Macklem <[email-masked]>
Sent: Monday, December 14, 2020 9:46 PM
To: Chuck Lever
Cc: [email-masked]
Subject: Re: [nfsv4] NFS over TLS for laptops

Hi Chuck
Is anything secure?;-)

Btw, it's a little off topic, but I do think there is a use case for TLS,
where the NFS client does not have a certificate.
--> Server trusts the client's identity via it's IP host address, but
      encryption on the wire is desired. For this case, creating
      certificates for all the clients would seem to be unnecessary
      overhead, unless "TLS squashing" is desired.
-->The harder we make deployment of NFS-over-TLS, the less likely
     it will be adopted.
Client TLS mounts without certificates is optionally allowed by
the current FreeBSD implementation.

>  RPC-over-TLS with AUTH_SYS by itself does not.
Yes, as I noted above.

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.

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.

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

      scaling this to a large numbesr of users), they can simply use

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

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Tue, 15 Dec 2020 12:17:50 -0500

> On Dec 15, 2020, at 10:54 AM, Rick Macklem <[email-masked]> wrote:
> 

That's the interoperability bit I'm concerned about: What goes
in the certs and how clients and servers are expected to
interpret those blobs.

> the current FreeBSD implementation.

Agreed, this is absolutely a use case we have in mind. There is
text throughout the document that discusses it.

And in this case, such clients would not be able to present an
otherName. If the server is security-sensitive, it will need
to be responsible for constraining the user identity of requests
from unauthenticated clients. It might map them all to nobody, for
example. 

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

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!

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

Server implementations have had user identity mapping and
squashing capabilities for a very long time, so the latter
approach feels more natural to me.

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.
Otherwise the server has to squash an unknown identity to
something anonymous like nobody.

Is there another benefit to an otherName vs. a server-side
mapping approach that I'm missing?

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

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

More discussion is needed here.

> also weaker that if the client uses RPCSEC_GSS/Kerberos.

Agreed.

>             as using Kerberos, I think.

Agreed, IIRC that was the consensus a year ago.

>     look at https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt

Thank you Rick, I'll take a look.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Thu, 17 Dec 2020 23:58:42 +0000

Chuck Lever wrote:
>Rick Macklem wrote:
>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 = [email-masked]
        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 = [email-masked]
        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::[email-masked]

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=[email-masked]

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=[email-masked]
/C=CA/ST=Alberta/O=MMM/OU=XXX/CN=nfsv4new3.home.rick/emailAddress=[email-masked]

and the above key refers to [email-masked]

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 [email-masked]) is right in the certificate.
--> No database needed.

> The tooling might be a little different,
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.

>client cert is stolen. Thank you for pointing that out!
Yes.

>trusted user mapping database (eg, KDC or LDAP).
Well, as I tried to show above, putting "[email-masked]" 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 "[email-masked]"?
That is up to the server implementation, just as it currently is
for Kerberos principal names.

>approach feels more natural to me.
Done based upon client IP address/DNS name traditionally.

If it makes you more comfortable, you can consider
"[email-masked]" 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.

>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 [email-masked], but the above
      mapping is the easy/obvious one.

>something anonymous like nobody.
Refusing to allow access would be preferable to "nobody"
access when there is no good TLS squashing mapping for
[email-masked] I think.

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

>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 [email-masked] 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

Agreed.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Sat, 19 Dec 2020 14:57:41 -0500

> On Dec 17, 2020, at 6:58 PM, Rick Macklem <[email-masked]> wrote:
> 
> Chuck Lever wrote:
>> Rick Macklem wrote:

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

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

> 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

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

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

> the information (ie [email-masked]) is right in the certificate.

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 [email-masked] is already
known to the server. But, that's a separate administrative
step, isn't it?

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

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

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

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

> Why would the client need to present the certificate again, after TLS

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

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

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

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Sun, 20 Dec 2020 00:01:21 +0000

Chuck Level wrote:
[stuff snipped]
>thinking that unique identity was going to be the key for the
Not sure what field(s) of a certificate you are referring to?
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 = [email-masked]
        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 = [email-masked]
        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

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

>the wire, with otherName compared with some other mechanism.
We are probably just going to agree to disagree on this.

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

>known to the server. But, that's a separate administrative
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]
>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]
>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]

>about hosts. RPC user identity is never the concern of the TLS
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?

>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

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Sun, 20 Dec 2020 22:48:41 +0000

>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 = [email-masked]
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

For FreeBSD, it is:

rick

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 20 Dec 2020 23:34:56 -0800

Hi Rick,

Consolidating a few messages into a single note (inline)...

On Sun, Dec 13, 2020 at 12:02:02AM +0000, Rick Macklem wrote:
[...]
> which can be done by that user (aka rmacklem) against the NFS server.

(I agree with Chuck that we should be careful about conflating host and
user authentication, and that some sort of "squash", or rather,
constraining the allowed users from a given host/certificate, will be
useful.)

>         sounds pretty scary to me.

It shouldn't -- the protocol is designed for it, the software is designed
for it, and lots of sites do it.

> put the certificate in the CRL for the site to stop the compromised access.

(The point raised downthread about the disparity in credential lifetimes is
also relevant, though can be managed in several ways, including via CRL as
you note.)

> Subject: Re: [nfsv4] NFS over TLS for laptops
[...]
> where the NFS client does not have a certificate.

TLS does not allow you to have the client authenticate with a certificate
when the server does not.

> obviously cannot be done for mobile devices.

Subject names for X.509 certificates are quite flexible, yes; the
subjectAltName is in essence arbitrarily exztensible.

[...]
> should be uniquely assigned to a certificate.

No.  It's perfectly normal to have multiple concurrently valid certificates
for the same issuerName/subjectName -- that is how certificate renewal
works.

A certificate is uniquely identified by its serialNumber/issuer pair; the
issuer, in turn, can be identified either by its own subject and issuer, or
by keyIdentifier.

[...]
>        would need to be implemented. The client would need to have

It already has been, actually -- the Globus Grid Security Infrastructure
(GSI) mechanism uses X.509 certificates as credentials for a GSSAPI
mechanism (that's essentially just running a TLS handshake) and there are
patched ssh clients around if you search for them.  (Paper at
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=BF00DE253BA4E15725A19A87974D62D5?doi=10.1.1.109.6988&rep=rep1&type=pdf
.)  Not that I am advocating using it in this context!  I don't think we
should put much effort into supporting multiple certificates per
connection.

>              as using Kerberos, I think.

"Much effort" seems likely; "less secure" is not so clear -- I think it
would have somewhat different security properties but which one is better
or worse would depend on the deployment conditions.

> I think that the issuerName will be needed in the database key,

Yes, serialNumber + issuer is the common practice (as mentioned above).
RFC 5280 is a bit dense but if you know the terms to search for these
points can be found.

> referring uniquely to one certificate.

There's no guarantee that any endpoint will correclty implement the
protocol, but a CA that reuses a serial number is seriously misbehaving and
shouldn't be trusted for anything.

-Ben

---

From: Chuck Lever <[email-masked]>
Date: Mon, 21 Dec 2020 11:54:24 -0500

Hi Rick -

> On Dec 20, 2020, at 5:48 PM, Rick Macklem <[email-masked]> wrote:
> 
> Rick Macklem wrote:
>> Chuck Level wrote:
>> [stuff snipped]

Section 5.2.1 used to start this way:

5.2.1.  X.509 Certificates Using PKIX trust

   Implementations are REQUIRED to support this mechanism.  In this
   mode, the tuple (serial number of the presented certificate; Issuer)
   uniquely identifies the RPC peer.

This is quoted from rpc-tls-05. This is the tuple that I meant
as a unique ID for a certificate.

It's also common for cert-based security implementations to use
a certificate's fingerprint for indexing databases or mappings.
Take the SHA-256 hash of the whole cert, and use that, or a
portion of it if a small index is needed.

A pre-shared key (Section 5.2.2 of the current revision), I
believe, cannot carry an otherName payload. For PSK, the only
way to implement identity squashing is for each server to enforce
a mapping of unique IDs (keys) to a set of one or more allowed
users.

And, as mentioned before, when a client does not present any TLS
identity, the server is the only party that can perform identity
squashing.

> I think that the issuerName will be needed in the database key,

Correct. As I quoted above, both are part of that unique
tuple.

> Still seems to be an Administrative Hassle to me, rick

In a small deployment, client certificates could be generated
on the NFS server itself. A tool specifically for this purpose
could generate the certificate and update the squashing
configuration at the same time. This can also work for PSK
deployments.

When you have more than one server, some mechanism for sharing
the squashing information is needed. You have proposed adding
that information to the certificates, but that would work only
in the case when each client actually has a certificate.

I expect larger deployments (eg, client fleets in the tens of
thousands and user populations in the hundreds of thousands,
with dozens of servers) to have infrastructure that would make
certificate creation as easy. An administrative host would be
able to create certificates and update an LDAP directory that
is consulted by servers. (Think of Red Hat's "IPA" which
already combines certificate management, Kerberos, and LDAP)

So I still believe that TLS administrative scalability is:

a. better than a Kerberos deployment

b. able to be improved by clever infrastructure and tool chains

---

You said you are not asking the WG to codify the otherName
convention. So, right now, you do not care whether other
implementations interoperate with FreeBSD in this regard. Fair
enough.

And, we agree that securing single-user clients is an important
and common usage scenario.

I expect other implementers will find the same thing. When they
deal with this issue, they might see your implementation and
and copy it. Or they might copy it and add some variations,
since there is no published specification.

And then I can see one or more of them approaching the WG and
asking us to either update rpc-tls or provide a specification
to enable proper interoperation.

Or, possibly, at some point in the future, the WG will be tasked
with updating rpc-tls to reflect implementation practice, part
of which might be otherName.

At that point, we have a real problem. Or maybe just me, as an
author of rpc-tls and possibly its descendants, has that problem.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Thu, 24 Dec 2020 00:03:58 +0000

Chuck Lever wrote:
[lots of stuff snipped]
>b. able to be improved by clever infrastructure and tool chains

If this is going to work for NFS servers from different vendors
(using vendors loosely to include open source projects)
you may have to think about defining a standard format
for the database information and a standard secure way
to distribute the data.
Otherwise, how is a Redhat tool going to manage a Netapp
filer, for example?
--> This could be a lot of work to define and implement
       for all vendors?

Wearing my old sysadmin hat, I'll admit that I was careful to
deploy NFS servers that were not dependent on other services
such as LDAP, DNS.
Why?
Well, after something like a major power failure I did not the
NFS servers stuck waiting for other services to come online.
--> As such, personally, I'd rather not depend on a service
      like LDAPS (note the 'S') to be running for the NFS server to be running.
      But, that's just me.

>implementations interoperate with FreeBSD in this regard. Fair
I suspect (although I cannot be 100% sure) that non-FreeBSD
clients will simply handle the X.509 certificate as a blob.
As such, it will work against a FreeBSD server.

For non-FreeBSD servers, they will probably ignore the otherName.
So, for those, the TLS squashing will need to be done with whatever that
server vendor provides.

Dealing with this will probably not be a lot different than dealing with
every server vendor choosing their own data format and distribution
mechanism.

>use case. (paraphrase. My stupid email system cut the text line out.)
>
Yes. As above w.r.t a TLS squashing data and distribution mechanism,
I agree.

>of which might be otherName.
And you can simply restate that you do not consider use of the
otherName field this way as acceptable, due to conflagration
of user and machine credentials in the certificate.
(I suppose there is the question of whether or not the "collective"
 working group agrees with the above, but since no one else has
 commented except Ben Kaduk, we do not know the answer to
 that?)

Anyone other implementation who might choose the otherName
approach can easily do so from the FreeBSD doc. and sources.
(Or by simply asking me.)

>author of rpc-tls and possibly its descendants, has that problem.
I do not really see the problem. No is a simple answer.

I will make one more generic comment...
There is a cousin to Administrative Hassle called Implementation
Effort.
--> It has been almost 11years since RFC5661 was published and
       I think you can count the number of different NFSv4.1 client
       and server implementations on one hand. Different vendors
       for client vs server, but both about 5 or less?

rick

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Thu, 24 Dec 2020 23:41:19 +0000

Benjamin Kaduk wrote:
[stuff snipped]
>constraining the allowed users from a given host/certificate, will be
 Ok. I'd agree. Of course, "careful" can mean just about anything.

Here's a simple analogy:
- I have a mobile phone#.
- I have a mobile device called a smartphone in my backpack.
Does the phone# refer to me, as the user, or the device/host in
my backpack?
I'd say "both".
-->So, yes, I'd say that you need to be careful, when multiple users
     share a host/device.
     When a single user uses a device, I do not see any need for a
     distinction between "user" and "host".
This is the last time I will try and argue this.;-)

[more stuff snipped]
>for it, and lots of sites do it.
My concern would be that it can facilitate a brute force attack on
passwords.

Correct me if I am wrong, but, with a KDC open to the world, I thought
that all an attacker would need to get an encrypted TGT was a valid
principal name.
--> Then they can brute force attack the password that maps to the
      principal's private key for that TGT at their leisure.
You could, correctly I believe, argue that this is really a concern w.r.t.
crappy passwords and not Kerberos.

If there is something in Kerberos to prevent the above brute force
password attack, please let me know.
[yet more snipped]

>or worse would depend on the deployment conditions.
My comment w.r.t. "less secure" came from the fact that the private keys
for the certificates would need to be known to the clients.
For Kerberos, the private keys remain locally on the KDC.
It just seems that distributing the private keys would introduce some
fundamental element of "risk" to the design?

rick

---

From: Chuck Lever <[email-masked]>
Date: Tue, 29 Dec 2020 11:41:04 -0500

> On Dec 23, 2020, at 7:03 PM, Rick Macklem <[email-masked]> wrote:
> 

> commented except Ben Kaduk, we do not know the answer to

I think we know the answer. We have a consensus that was
arrived at by the usual process. It is documented in
rpc-tls.

> Any other implementation who might choose the otherName

My concern is that we have a spec (one that supposedly
represents a community consensus) that tells us not to mix
client and user authentication material, and yet implementers
are choosing to do this anyway.

Is the spec then wrong? If it is, the WG needs to address that.
The primary purpose of specifications is to codify the practices
where we agree, yet there is clearly a disagreement already.

If the spec is not wrong, the WG needs to consider ways to
address the need while complying with the normative
requirements in rpc-tls.

I was hoping that we could identify a compromise position, at
least, with the FreeBSD implementation. If it turns out we
cannot, then the WG needs to construct a proper response to
the single-user-per-client scenario.

In short, the WG must come to a fresh consensus that either
otherName is OK to do in this scenario, or it must provide an
acceptable alternative.

> I do not really see the problem. No is a simple answer.

Simple, but problematic. The possible result will be the
promulgation of implementations that do not comply with our
shiny new specification. I think the IETF would view that as
very much a quality-of-specification problem. The usual redress
is to publish an updated protocol specification.

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 Dec 2020 11:02:11 -0800

Hi Rick,

>  Ok. I'd agree. Of course, "careful" can mean just about anything.

This is true :)

> Does the phone# refer to me, as the user, or the device/host in

Sure, there are senses in which it refers to both.  OTOH, the device has
some credentials, perhaps in the SIM card, that to me clearly address the
device but not the user.  Though these credentials are used for
authentication/authorization decisions (not least, granting access to the
mobile network!), they can only be tied to you as the user with the
addition of a separate lookup database in the mobile operator.  (And, lest
we forget, mobile phone numbers are terrible credentials.)

> that all an attacker would need to get an encrypted TGT was a valid

Any kind of vaguely modern deployment should be setting the "requires
preauth" flag on password-based keys, so that you have to prove you know
the key (e.g., by sending an encrypted timestamp) before a ticket will be
issued that can be used as a brute-force target.  (IIRC this is the default
behavior for new installations.)  An observer on the network path would
still be able to obtain such a thing, of course, though there are many
additional options for avoiding that -- we recently implemented a
PAKE-based scheme that performs a zero-knowledge proof of the password as
part of the key-agreement process, which is very nice from a cryptographic
perspective, and you have had the option for years of using a FAST (RFC
6113) tunnel to protect the password-derived exchange, as well as the
option of using certificate-based PKINIT in lieu of passwords entirely.

> crappy passwords and not Kerberos.

Yes, I would also argue that :)
My passwords are created by `dd bs=1 count=18 if=/dev/random | openssl
base64`, and you would have a hard time brute-forcing them...

> fundamental element of "risk" to the design?

In order for a certificate to be usable on a client, the private key
associated with the public key in the certificate needs to be available to
the client (though could be wrapped in secure hardware such as a smart
card), yes.  But, you do not have to use the same private key on all
clients that will act on behalf of the same identity, and you can revoke
the certificate when it is compromised.  With a (possibly password-derived)
kerberos key, all users of the key have to know the same one, and you can't
revoke one copy without revoking all of them.  So, I stand by my assertion
that the security properties are different, and not straightforwardly
orderable into more or less secure.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 Dec 2020 11:07:07 -0800

> the single-user-per-client scenario.

I suspect that we can find a compromise position, yes.
The certificate still authenticates the client (not the user), and the
client uses AUTH_SYS to claim what user is performing operations.  But the
server uses the client's authenticated identity to restrict, by policy,
what user identities the client is allowed to claim via AUTH_SYS.  In the
degenerate case there is an otherName in the certificate that corresponds
to a single user and the client can only claim that one user, which looks
very similar to just authenticating the user, but we can say that the
relevant policy logic is located in the server as part of its internal
implementation choices.  (There might be some divergence from what Rick has
done for the FreeBSD implementation in terms of the behavior when a client
does try to send some other user information via AUTH_SYS, in terms of
getting "squashed" vs getting rejected, but I suspect that Rick is amenable
to changing that behavior if we come up with some reasoning for why it
makes sense.)

-Ben

---

From: Chuck Lever <[email-masked]>
Date: Wed, 30 Dec 2020 11:12:05 -0500

> On Dec 29, 2020, at 2:07 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> implementation choices.

An NFS client might send legitimate operations as UID 0 too
(e.g., lease management). Those cannot be rejected. Perhaps
we need to specify that the client has to perform _all_
operations as the squashed user.

As a process note, I'm thinking this explanation, a description
of the use of otherName, and a summary of the security discussion
in this thread ought to go in whichever document discusses how
NFS operates on RPC-over-TLS. It seems to be NFS-specific access
control behavior.

The alternative is publishing an update to rpc-tls...

> (There might be some divergence from what Rick has

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 30 Dec 2020 10:39:13 -0800

> The alternative is publishing an update to rpc-tls...

Agreed on both counts.

Thanks,

Ben

---

From: Rick Macklem <[email-masked]>
Date: Thu, 31 Dec 2020 16:53:04 +0000

Chuck Lever wrote:
> Ben Kaduk wrote:
Yes. I agree with this.
My current implementation simply ignores the AUTH_SYS RPC
credential when TLS squashing is enabled.

>NFS operates on RPC-over-TLS. It seems to be NFS-specific access
My implementation is done in the RPC layer.
However, since NFS is the main/only Sun RPC consumer and NFS
is what we do, an NFS specific document seems appropriate to me.

I do think that TLS squashing done via a database keyed on
issuer+serial could be a useful alternative (for larger deployments or ...).
I also think the database structure/access should be specified in detail,
so that all server implementations can use the same database deployment.
--> Possibly use secure LDAP?
       I do not know how to specify LDAP data, but there must
       be a way?
I could easily implement that as an optional alternative to otherName
in the FreeBSD daemon that does the TLS handshake.

>> to changing that behavior if we come up with some reasoning for why it
I think the "squash everything" will work best and that already appears to
be a concensus.

rick

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Thu, 31 Dec 2020 12:07:32 -0500

> On Dec 31, 2020, at 11:53 AM, Rick Macklem <[email-masked]> wrote:
> 

Fwiw, such an effort might be modeled after RFC 7532, which was produced
by the nfsv4 working group years ago. Note however that there currently
is no LDAP working group within the IETF, so we would have to scrounge
some LDAP expertise for expert review.

I also have some contacts on Red Hat's IPA team, who could give insight
about convenient ways to organize squashing information. Two cents.

--
Chuck Lever

---

From: Craig Everhart <[email-masked]>
Date: Thu, 31 Dec 2020 12:37:42 -0500

Am I the only clueless one who doesn’t understand what “TLS squashing” is or means?  If so I’ll go back to background and try to trawl old emails.  Otherwise, perhaps you could enlighten.

Happy New Year.

Craig

---

From: Chuck Lever <[email-masked]>
Date: Thu, 31 Dec 2020 13:05:52 -0500

> On Dec 31, 2020, at 12:37 PM, Craig Everhart <[email-masked]> wrote:
> 

The original term was "TLS identity squashing" which I coined earlier
in this thread. It has come to mean that the NFS server has a security
policy that squashes AUTH_SYS user identities to a single UID, based
on the client's TLS identity (x.509 certificate or pre-shared key).

--
Chuck Lever

---

From: Craig Everhart <[email-masked]>
Date: Thu, 31 Dec 2020 13:17:52 -0500

Thanks, Chuck.  So—an authentication policy to interpret AUTH_SYS, for any UID/GID as the connection-wide identity negotiated over TLS.

Thanks,
Craig

> On Dec 31, 2020, at 1:06 PM, Chuck Lever <[email-masked]> wrote:
> 
> 
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 31 Dec 2020 21:58:32 -0800

> credential when TLS squashing is enabled.

Hmm, that may not be as robust as you want, since a certificate is allowed
to have more than one SAN of any given type.  I think that if we do write
up something like this we should be sure to define behavior when multiple
names are present in the certificate.

-Ben