Re: Re-encrypt on change of master key

[Nico Williams]

On Tue, Mar 14, 2017 at 03:54:36PM -0700, Adam Lewenberg wrote:
> If you use a master key and you back up all your files _except_ the master
> key to some remote location, wouldn't that suffice to protect the database
> in that remote location?

No.  The problem is that the master key is not used to bind principal
keys to principal records.  This means that a backup operator could give
you back a dump where a user's keys are pasted into the krbtgt
principal(s), and if you load this dump that user will now be able to
mint tickets for any service as any user.  (You might notice this
attack, but probably not in time to stop it.)

Nico
-- 

Re: Re-encrypt on change of master key

[Adam Lewenberg]

On 3/14/2017 12:54 PM, Nico Williams wrote:

On Tue, Mar 14, 2017 at 12:32:10PM -0700, Russ Allbery wrote:

"Henry B (Hank) Hotz, CISSP"  writes:

Shut down all daemons on the master.



hprop --decrypt --stdout | hpropd --stdin



Restart all daemons.


You probably also want to shut down incremental propagation while you do
this.  I think this should force a full resync when the slaves reconnect,
but it would be a good idea to thoroughly test the replication behavior in
a test realm before doing this in a production realm.  I forget how it
deals with a complete database reload; I think it's supposed to do
something sane, but that would be the component that I would worry about.


Good point, but actually restarting the daemons does not force a full
resync.  You have to remove the iprop log file (on the master and/or the
slaves -- either works) to force a full resync.


Note that you will need to manually copy the new master key to the slaves
before they'll be able to replicate.  Also don't forget to keep the old
master key around for the length of your backup retention so that you
don't invalidate your backups.


If you're not storing the master key on a different disk anyways, and
maybe even if you are, I would recommend just not encrypting the HDB at
all.  As with MIT, only the principals' keys are encrypted, which leaves
you subject to cut-n-paste attacks by, e.g., your backups operator.

You should separately encrypt the backups/dumps.


If you use a master key and you back up all your files _except_ the 
master key to some remote location, wouldn't that suffice to protect the 
database in that remote location?


Adam Lewenberg




Even if we could put the master key in a hardware token, that would not
be sufficient to make the keys that much more secure.

The only case that KDB/HDB encryption gets you more security is where
it's easier to steal the disks than the whole system, and you either
store the master key on a disk that's inside the system or you type it
in when the daemons start.  With modern kit that's just not the case, so
you might as well not encrypt the KDB/HDB.  (MIT doesn't give you the
option; Heimdal does.)

Nico

Re: Re-encrypt on change of master key

[Jeffrey Hutzelman]

On March 14, 2017 6:32:13 PM EDT, Nico Williams  wrote:
>On Tue, Mar 14, 2017 at 03:26:57PM -0700, Henry B (Hank) Hotz, CISSP
>wrote:
>> Probably, but encrypting the key material separately doesn’t seem
>like a bad thing.
>
>It's a waste of CPU cycles.  It adds no real protection _by itself_
>unless you're keying in the master key on daemon startup.

it provides some additional protection against disclosure of the keys while in 
transit (i.e. during propagation). it doesn't protect against copy/paste 
attacks or do much of anything for a database at rest

Re: Re-encrypt on change of master key

[Russ Allbery]

"Henry B (Hank) Hotz, CISSP"  writes:

> Shut down all daemons on the master.

> hprop --decrypt --stdout | hpropd --stdin

> Restart all daemons.

You probably also want to shut down incremental propagation while you do
this.  I think this should force a full resync when the slaves reconnect,
but it would be a good idea to thoroughly test the replication behavior in
a test realm before doing this in a production realm.  I forget how it
deals with a complete database reload; I think it's supposed to do
something sane, but that would be the component that I would worry about.

Note that you will need to manually copy the new master key to the slaves
before they'll be able to replicate.  Also don't forget to keep the old
master key around for the length of your backup retention so that you
don't invalidate your backups.

-- 
Russ Allbery (ea...@eyrie.org)  

Re: Re-encrypt on change of master key

[Henry B (Hank) Hotz, CISSP]

https://www.mail-archive.com/heimdal-discuss@sics.se/msg00334.html

There’s also a long, historically-interesting, thread on migrating from MIT 
that includes an example.

> On Mar 14, 2017, at 11:51 AM, Henry B (Hank) Hotz, CISSP  
> wrote:
> 
>> On Mar 14, 2017, at 9:43 AM, Adam Lewenberg  wrote:
>> 
>> How do I re-encrypt the entries of the Heimdal KDC database if I want to 
>> change its master key?
> 
> Shut down all daemons on the master.
> 
> hprop --decrypt --stdout | hpropd --stdin
> 
> Restart all daemons.
> 
> That’s from memory. I think some other options may be needed, like keytab 
> files. I published this once in a presentation at one of the AFS best 
> practices workshops, but I don’t remember the year.
> 
> Personal email.  hbh...@oxy.edu

Personal email.  hbh...@oxy.edu

Re: Re-encrypt on change of master key

[Henry B (Hank) Hotz, CISSP]

How’s the contract coming?

> On Mar 14, 2017, at 9:43 AM, Adam Lewenberg  wrote:
> 
> How do I re-encrypt the entries of the Heimdal KDC database if I want to 
> change its master key?

Shut down all daemons on the master.

hprop --decrypt --stdout | hpropd --stdin

Restart all daemons.

That’s from memory. I think some other options may be needed, like keytab 
files. I published this once in a presentations at one of the AFS best 
practices workshops, but I don’t remember the year.

Personal email.  hbh...@oxy.edu