Using a master key and principal name to derive password for principal

[Alexander Bokovoy]

On ke, 16 loka 2019, Ts7 Coe wrote:
>> do you actually need the principals to have keys that you can predict?
>
>I want to have the key to be predictable only on the KDC side, and the only purpose is
>to make KDC stateless(store nothing). The keys are used only internally in kerberos.
>keys are distributed automatically by kerberos, and no anther party has the need to know
>the keys, nor be able to predict the keys.
PKINIT doesn't rely on Kerberos principal keys at all. None of the
principal's keys are used for TGT key creation. So you don't need to
have those keys at place.

>
>> You will still want to have an entry in the Kerberos DB in most cases because it may
>contain ancilliary data such as the existence of the name
>
>A krb DB is essential, but I'm thinking a workaround for this: using a dummy DB plugin
>(by modifing the offical kdb_db2 plugin), which will return dynamically generated principal
>record when KDC querying a principal info. The db file on disk may only store admin principals.
>I've done some demo code on kdb_db2 plugin, which will read a template principal from db,
>then modify the princ/key_data field of the template entry, and return it to KDC. Not sure
>if this could work.
Try to not set entry.key_data and entry.n_key_data (where entry is
krb5_db_entry structure) fields. We do this in FreeIPA for principals
that have no key associated and it works for PKINIT. It works just fine.


>
>Regards,
>tm3y
>________________________________
>From: Roland C. Dowdeswell <elric at imrryr.org>
>Sent: Wednesday, October 16, 2019 16:04
>To: Coe Ts7 <tm3y at hotmail.com>
>Cc: krbdev at mit.edu <krbdev at mit.edu>
>Subject: Re: Using a master key and principal name to derive password for principal
>
>On Wed, Oct 16, 2019 at 02:45:19AM +0000, Coe Ts7 wrote:
>>
>
>>    > get the impression that you are interested in using PKI for clients
>>
>>    > who will use PKINIT to obtain a TGT.  In this case, is there any
>>    > reason that you need to know the client's key or password?  If you
>>    > never need to know a key or a password, then just randomise the
>>    > key and forget it on the creation of the client principal.
>>    Thanks for the reply.
>>    The reason why I need the keys to be predictable is that I don't want
>>    kerberos to store anything,
>
>I understand that.
>
>What I am asking is: do you actually need the principals to have
>keys that you can predict?  What are you going to use the keys for?
>If you are simply going to have PKINIT clients, then you do not
>need to _know_ the keys.  And if you do not need to know the keys,
>then it is sufficient to randomise them.  You will still want to
>have an entry in the Kerberos DB in most cases because it may contain
>ancilliary data such as the existence of the name.
>
>When I say, "What are you going to use the keys for?", the question
>really is made up of two parts:
>
>        1.  what AS_REQs do you expect to issue and serve for the
>            principal in question? and
>
>        2.  what TGS_REQs do you expect to issue and serve for the
>            principal in question?
>
>--
>    Roland C. Dowdeswell                   http://Imrryr.ORG/~elric/
>_______________________________________________
>krbdev mailing list             krbdev at mit.edu
>https://mailman.mit.edu/mailman/listinfo/krbdev

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland