Kerberos n00b question.

[Grant Taylor]

On 1/8/19 6:02 PM, Robbie Harwood wrote:
> It still reduces to the security of a password (the one locking the 
> random key).

I agree that the passwords are the weakest link.  But I thought (hoped) 
that it would bolster the strength of the (derived) key that Kerberos uses.

> But as Russ points out, you may be interested in PKINIT if users choosing 
> strong passwords is a serious worry.

I am interested and will be reading about PKINIT.

I read <~> skimmed RFC 6113 earlier today.  -  I feel like I'm trying to 
swim with cloths on.  High level concepts make some sense.  But I'm 
still getting enough bearings to be able to make more sense of things 
without getting too mired down in details.  -  I'm looking for a 
conceptual overview / understanding of what things do at the moment.

It seems as if FAST provides an extension framework that a number of 
things can use, including some options to provide encrypted 
pre-authentication connections.

I think that PKINIT is another method to derive some of the values that 
FAST can use.

> Also!  2FA will mitigate this concern somewhat as well.

I was wondering about 2nd factor authentication.  I have a YubiKey 
that's waiting for my attention.

Would I be correct in assuming that (from a Kerberos point of view) the 
1st and 2nd factors are used during the kinit process?  Meaning that all 
of the SSO functions still work unimpeded?

I think that it's more that I want to set Kerberos up using best 
practices as I start using it.  I don't want to start something new 
(like build a website) and then find out that I made a bone headed 
mistake (like not salting hashed passwords).

Everything I'm doing, Kerberos included, is functionally for me, myself, 
and I.  I'm still trying to decide which one has the worst security posture.

> krb5 is prepared to hand off to a RADIUS responder for OTP

I've been meaning to read about RADIUS as I know that it's an integral 
component of 802.1X which I want to set up when I find a few spare 
Round-Tuits.

> (freeIPA uses this, which I know you're not interested in but is 
> meaningful as a PoC);

There's nothing at all wrong with playing with the boxed Lego set to 
learn how things are done.  Once I've done that, I tear all the pieces 
apart and build my own thing, or add on to my other things.

> you can then use something like freeOTP or a physical 2fa token for 
> acquiring additional credentials.

*nod*

> 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

I need to do some more reading on what user-to-user and kvno are to know 
if I care about them.

The main thing that I care about that I'm not sure if it's impacted or 
not is .k5login / .k5users.  -  I don't think that would be impacted, 
but I don't know enough to confidently say one way or the other.

The little bit of reading that I just did on key version number (kvno) 
sounds unrelated to servers / services (what I think of with allow_svr). 
  I need to do more reading.

On the surface, I think I'd like to keep kvno functional.

Would -allow_svr have any impact on protocol translation?  (I think 
that's the term.)  I.e. when a non-Kerberos aware client logs into IMAPS 
with username & password and the daemon translates / gateways / bridges 
into Kerberos on the client's behalf?  (I saw something about that in 
one of the first three videos I mentioned in a previous message.)

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

:-)

Good.  I'm starting to get similar impression as I read more things.  I 
still think I want to keep client <-> KDC on the same LAN.  But I'm 
getting more and more comfortable with using Kerberos, via GSSAPI, with 
services across the Internet.

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

ACK

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

Agreed.

I do think that would expose the Kerberos client (the server in this 
context) to KDC exchange to the Internet.  Which it sounds like this is 
reasonably secure enough.

I was not aware that I could get the keytab via kinit.  I had used 
kadmin on clients (in the LAN) to get it.  -  This is why I ask questions.

> It's not a Linux distro - it's a tool that can be run on man distros - 
> but yes.

Thank you for the clarification.

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

LOL

Fair enough.

I'm not there (yet).  And I still want to graft the new Kerberos colored 
Lego bricks into my existing creations.  (For better or worse.)

> Thanks,

You're welcome.  But it is me that needs to say thank you.  You and Russ 
have given me a lot to read and think about.  I appreciate that.  :-)



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20190108/f20e9d7d/attachment-0001.bin