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

[Roland C. Dowdeswell]

On Wed, Oct 16, 2019 at 09:32:17AM +0000, 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.

Then you don't actually need keys at all.  If no one is going to
make an AS_REQ or TGS_REQ with the principal as a target, then you
do not need keys.

That said, what you want is possible in Heimdal out of the box:

https://github.com/heimdal/heimdal/wiki/Setting-up-PK-INIT-and-Certificates

You will still need to maintain service principals and their keys,
though.

>    > 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                   [1]http://Imrryr.ORG/~elric/
> 
> References
> 
>    1. http://Imrryr.ORG/~elric/


--
    Roland C. Dowdeswell                   http://Imrryr.ORG/~elric/