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
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
