Kerberos n00b question.

[Robbie Harwood]

Grant Taylor <gtaylor at tnetconsulting.net> writes:

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

Kerberos uses PBKDF2, so probably not.  The thing it would help with is
reducing the availability the password encrypted blob - it becomes
similar to a certificate.

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



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

kvno is a number associated with each principal that keeps track of how
many times it's been rekeyed (password change and the like).  It's
useful for debugging to be able to access this information, but you can
also get it out of kadmin.

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

I don't believe it would be.

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

The kvno(1) tool works by acquiring a service ticket to the given
principal.  So for instance, asking `kvno rharwood at FEDORAPROJECT.ORG`
acquires for rharwood at FEDORAPROJECT.ORG and then inspects the kvno on
the result.

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

I don't believe so (but I haven't actually checked).

>> 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 would be with kadmin (or ktutil).  Sorry if that was unclear.

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/20190110/c615f555/attachment.bin