Re: [nfsv4] NFS over TLS for laptops

[Rick Macklem <[e-mail]>]

Benjamin Kaduk wrote:
[stuff snipped]
>(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.)
 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]
>>
>>         Also, this would require the KDC be accessible from "the world", which
>>         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.
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]

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