Kerberos n00b question.

[Robbie Harwood]

Grant Taylor <gtaylor at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20190108/7d487e05/attachment-0001.bin