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

Ts7 Coe tm3y at hotmail.com
Wed Oct 16 05:32:17 EDT 2019


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

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

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/


More information about the krbdev mailing list