Re: [nfsv4] NFS over TLS for laptops

[Benjamin Kaduk <[e-mail]>]

Hi Rick,

On Thu, Dec 24, 2020 at 11:41:19PM +0000, Rick Macklem wrote:
> 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.

This is true :)

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

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

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

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.

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

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

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

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