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

[Roland C. Dowdeswell]

On Tue, Oct 15, 2019 at 03:46:25AM +0000, Coe Ts7 wrote:
>

> I'm look for a simple but effective High Available solution for kerberos.
> In my deployment, I will use kerberos PKINIT. So there's a chance
> that the kerberos doesn't store principal list, just generate ticket
> according the name in PKI certificate.
> And I try to go further and make kerberos not to store principal
> password, so that the kerberos is completely stateless and fully
> trusts PKI.
> To achieve that,  I want to use some crypto & hashing mechanisms
> to make all kerberos instances could calculate the same password
> for each principal through a shared master key and principal name.

I've done something like this in Heimdal, although it is in the
early stages and I haven't finished writing up the documentation
for it.  But it's for a very different use case than that which
you are describing, namely it's for ultra-fast provisioning of
Kerberos services where the KDC doesn't even to know what service
principals are in use in advance.

You use case sounds quite different.  From what I read above, I
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.

The only reason to generate predictable keys for principals is if
you intend to use them without PKINIT and need to be able to generate
the key.  Is there are reason that you need the keys to be predictable?

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