Grant Taylor <gtay...@tnetconsulting.net> writes: > On 01/07/2019 12:21 PM, Robbie Harwood wrote: > >> The biggest concern in a new Kerberos deployment is secrets being >> based on passwords. To varying degrees, this reduces the strength of >> the system as a whole to the strength of the passwords. > > Yep. > > I suspect the -randkey option when adding a principal is significantly > better than a password. > > I wonder if there is any possibility of users using a random key that > is password protected. Thus using the password unlocking the random > key that is used to secure communications. - I suspect that would > make keys used for users as secure as -randkey for services, at least > as far as brute forcing things. Of course you would need to protect > the encrypted key. But that's a different issue.
It still reduces to the security of a password (the one locking the random key). But as Russ points out, you may be interested in PKINIT if users choosing strong passwords is a serious worry. Also! 2FA will mitigate this concern somewhat as well. krb5 is prepared to hand off to a RADIUS responder for OTP (freeIPA uses this, which I know you're not interested in but is meaningful as a PoC); you can then use something like freeOTP or a physical 2fa token for acquiring additional credentials. >> In the system proposed in the dialogue above, for instance, >> it's possible to observe an exchange and mount an offline >> dictionary attack against it. More information on >> mitigating that (which isn't too hard) can be found here: >> https://web.mit.edu/kerberos/krb5-devel/doc/admin/dictionary.html#dictionary > > That's an interesting read. > > I wonder if I should recreate my user principals (the few that exist in > my test REALM) using "+requires_preauth -allow_svr". You don't have to recreate them, but yes, it's a good idea to set +requires_preauth. Setting -allow_svr will I believe block the use of U2U and make kvno on user principals no longer work, but this may be acceptable to you. >> See above. > > Sorry, I can't translate that to what your opinion is about using > Kerberos between a LAN client (with a local KDC) and a web server across > the Internet. (Thus the client <-> KDC interaction is on the LAN.) Apologies. I consider Kerberos (with preauth and strong passwords) safe for internet use, as I imagine the rest of us on here do as well. > I'm trying to build a mental model / working understanding of what > communications between KDC <-> client <-> server is sensitive and what > is okay to send across the Internet. I /think/ that client <-> server > is okay as part of SSH. - I'm trying to understand if the client <-> > server is okay on it's own, or if it's also relying on security offered > by SSH. Mainly so that I can judge how safe it is to use for other > protocols between the client and server (with or without other encryption). Kerberos exchanges are not reliant on additional layers of encapsulation for security. Russ went into more detail on this I think for SSH. But it's all encrypted with pre-shared knowledge, be it passwords or keytabs or certs (or things derived from those) - except for things that don't need to be kept secret, like usernames. > I think the biggest issue is that I need to get the keytab to the server > in a secure manner. I would expect that something like scp / sftp would > suffice. Yes. Provisioning is always the hard part in any cryptosystem :) It's possible to, on the server, kinit and acquire the keytab that way. But if you're SSHing in already, there isn't really an advantage to that. >> It's worth mentioning that there are turnkey solutions for configuring >> entire identity management systems (i.e., including Kerberos) now. >> For instance, we develop FreeIPA ( https://www.freeipa.org/ ), which >> will mitigate these threats by default. > > I was vaguely aware of FreeIPA. (I think) I now know more about > FreeIPA. FreeIPA seems to be a purpose built Linux distribution that > incorporates the technologies listed under Main features section of the > link you provided. It's not a Linux distro - it's a tool that can be run on man distros - but yes. > I feel like FreeIPA is analogous to a Lego set that produces one > particular structure using the aforementioned technologies as some of > the Lego bricks. - I personally want to learn how to use the Lego > bricks within my existing structures. I've already got LDAP, > Kerberos, NTP, DNS, and SSSD working (to my satisfaction). So I'm > reluctant to throw those integrated things out and introduce a new > turn key appliance, namely a FreeIPA (V)M. Totally fine! I also appreciate the need to tinker - but I've also set up enough realms to be tired of trying to figure out what I did wrong with LDAP this time :) Thanks, --Robbie
signature.asc
Description: PGP signature
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos