[19984] in Kerberos_V5_Development
Re: Using a master key and principal name to derive password for
daemon@ATHENA.MIT.EDU (Roland C. Dowdeswell)
Wed Oct 16 06:12:41 2019
Date: Wed, 16 Oct 2019 11:12:08 +0100
From: "Roland C. Dowdeswell" <elric@imrryr.org>
To: Ts7 Coe <tm3y@hotmail.com>
Message-ID: <20191016101208.GA23133@xiombarg.imrryr.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <HK2PR06MB35396FB83B7692FBF8EE8C719C920@HK2PR06MB3539.apcprd06.prod.outlook.com>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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@imrryr.org>
> Sent: Wednesday, October 16, 2019 16:04
> To: Coe Ts7 <tm3y@hotmail.com>
> Cc: krbdev@mit.edu <krbdev@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/
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
