need project review

[Tim Alsop]

In addition - if you store old master keys in a keytab they are
potentially open to attack, so better to store as key material in the db
as possible, and protect with the latest master key. You only need the
stash file so that when daemons are started they can use this to get
access to the db to read the principal records and decrypt latest and
older keys.

Our product also works with no stash file, in which case you start the
daemons and get prompted for a password, and this password is used
instead of reading the latest master key from the stash file.

I hope this input helps ?

Thanks,
Tim

-----Original Message-----
From: krbdev-bounces at MIT.EDU [mailto:krbdev-bounces at MIT.EDU] On Behalf
Of Tim Alsop
Sent: 07 April 2008 20:17
To: Ken Raeburn; Jeffrey Hutzelman
Cc: MIT Kerberos Dev List
Subject: RE: need project review

Hi,

Why don't you store all master key versions in the database and encrypt
them all with the latest master key ? That's what we do with our
TrustBRoker product and we already include a master key change utility,
and it works very well, even with incremental propagation. We didn't
have to change our stash file to a keytab file, or change the contents
of it.

Cheers,
Tim

-----Original Message-----
From: krbdev-bounces at MIT.EDU [mailto:krbdev-bounces at MIT.EDU] On Behalf
Of Ken Raeburn
Sent: 07 April 2008 20:11
To: Jeffrey Hutzelman
Cc: MIT Kerberos Dev List
Subject: Re: need project review

On Apr 7, 2008, at 15:03, Jeffrey Hutzelman wrote:
> It doesn't happen currently, but I gather that one of the purposes of
> moving to keytabs as a storage mechanism is to allow more than one  
> master
> key version to be stored, so that database entries do not all have  
> to be
> reencrypted at once (possibly resulting in a service outage while the
> update occurs).

Yes.  Of course, once this is done, and password changes start  
happening, the old master key is no longer enough to retrieve all of  
the database contents, so downgrading is a non-trivial process.

Ken
_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev