[38431] in Kerberos
Re: Kerberos n00b question.
daemon@ATHENA.MIT.EDU (Robbie Harwood)
Tue Jan 8 20:02:51 2019
From: Robbie Harwood <rharwood@redhat.com>
To: Grant Taylor <gtaylor@tnetconsulting.net>, <kerberos@mit.edu>
In-Reply-To: <eb5f2ecd-67f9-b04b-9b2d-2cf91c302aa6@spamtrap.tnetconsulting.net>
Date: Tue, 8 Jan 2019 20:02:32 -0500
Message-ID: <jlgy37uy76f.fsf@redhat.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3483021007510929367=="
Errors-To: kerberos-bounces@mit.edu
--===============3483021007510929367==
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512;
protocol="application/pgp-signature"
--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 01/07/2019 12:21 PM, Robbie Harwood wrote:
>
>> The biggest concern in a new Kerberos deployment is secrets being=20
>> based on passwords. To varying degrees, this reduces the strength of=20
>> 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,=20
>> it's possible to observe an exchange and mount an offline=20
>> dictionary attack against it. More information on=20
>> mitigating that (which isn't too hard) can be found here:=20
>> https://web.mit.edu/kerberos/krb5-devel/doc/admin/dictionary.html#dictio=
nary
>
> That's an interesting read.
>
> I wonder if I should recreate my user principals (the few that exist in=20
> 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=20
> Kerberos between a LAN client (with a local KDC) and a web server across=
=20
> 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=20
> communications between KDC <-> client <-> server is sensitive and what=20
> is okay to send across the Internet. I /think/ that client <-> server=20
> is okay as part of SSH. - I'm trying to understand if the client <->=20
> server is okay on it's own, or if it's also relying on security offered=20
> by SSH. Mainly so that I can judge how safe it is to use for other=20
> 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=
=20
> in a secure manner. I would expect that something like scp / sftp would=
=20
> 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=20
>> entire identity management systems (i.e., including Kerberos) now.=20
>> For instance, we develop FreeIPA ( https://www.freeipa.org/ ), which=20
>> will mitigate these threats by default.
>
> I was vaguely aware of FreeIPA. (I think) I now know more about=20
> FreeIPA. FreeIPA seems to be a purpose built Linux distribution that=20
> incorporates the technologies listed under Main features section of the=20
> 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,
=2D-Robbie
--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlw1SCgACgkQJTL5F2qV
pEJEeQ/+OOxlsHImDFSfYmbKkcbCM01BgJHnWY+qHJ71g2Nd8LhCVtCRRjXd45Xu
b4a7plyDgivlpjkBOIzxgRhRb3smw9IvAsyyvmHglVCxwkyQFKy9/RChUiVY5uMz
aeLadUB6w2URsguJ/lOQPImKsmTxzThvFIt3aQitiZpcOyjer4FSPqsO8gARnIRG
GA4eGT6IRoVbr1Loo/Ot0B5Gzc8qCySeH8gn9dAkBqpDjtoL+q+ineALQsgqpvaS
FeU8yB64n7h4Ap+P0YeLKl7vKATJNKwCb+r1Ybfex1dh6DsSV188zkQFo9eCOznO
AQOlMsjCa4lnCaaX3uRmy5ij4hWZsuzBdSAmmFZmdAO/UqkkNt1z2PUD2tKEW3fV
f+hrlDoZJYC4nJw0g8aL4bDXZwkjU66VWQPzXnOE+SN5g3jpjd53UWCbrLG3Ivld
cZttvoZu+c7lWEotywgyF7oo2PpaLb86k5oxpSozAJ8H2YmrhfHdDh5rqgZOlb7d
+srScir/mdLpk128Z8Y5yo04o/tb44RhiBI8ySo+ft4mLorGK/o+c1fOXN1KmT4i
/XaFjPRnxoKcP3XxN4jjVJnXcDOYvs+7jQeJyWXjlf/fLGzVhDnBOd1ZkImw85HU
u6LSwuyJ5plqGQyvapQdTlmZFcK9KH4oETtPE/rMgt6usl+I5hg=
=R4ti
-----END PGP SIGNATURE-----
--=-=-=--
--===============3483021007510929367==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============3483021007510929367==--
