Re: Re-encrypt on change of master key

[Quanah Gibson-Mount]

Everything's in git.  You can fork your own repo and submit merge requests. 
That's what I do.


--Quanah

--On Thursday, March 16, 2017 1:47 PM -0700 "Henry B (Hank) Hotz, CISSP" 
 wrote:



Russ and I have submitted patches to the man pages in the past, much like
code patches. I assume similar submissions for the web pages would be
handled somehow? I would be more likely to do so if I had an account that
allowed editing.


On Mar 16, 2017, at 12:07 PM, Adam Lewenberg  wrote:


On 3/16/2017 12:03 PM, Henry B (Hank) Hotz, CISSP wrote:

+1


On Mar 15, 2017, at 5:51 AM, Jeffrey Altman
 wrote:

On 3/15/2017 5:17 AM, Lars-Johan Liman wrote:

Hi!

This whole thread contains a lot of really good information. Is this
all documented in a good way (preferrably with examples) somewhere?
If so, pointer please. If not, can it please be?



It is not.   Contributions are welcome.


If we want to help improve documentation, how can we go about it? Is
there a wiki somewhere that we can edit?

Adam Lewenberg









Personal email.  hbh...@oxy.edu







Personal email.  hbh...@oxy.edu







--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: Re-encrypt on change of master key

[Henry B (Hank) Hotz, CISSP]

Russ and I have submitted patches to the man pages in the past, much like code 
patches. I assume similar submissions for the web pages would be handled 
somehow? I would be more likely to do so if I had an account that allowed 
editing.

> On Mar 16, 2017, at 12:07 PM, Adam Lewenberg  wrote:
> 
> 
> On 3/16/2017 12:03 PM, Henry B (Hank) Hotz, CISSP wrote:
>> +1
>> 
>>> On Mar 15, 2017, at 5:51 AM, Jeffrey Altman  
>>> wrote:
>>> 
>>> On 3/15/2017 5:17 AM, Lars-Johan Liman wrote:
 Hi!
 
 This whole thread contains a lot of really good information. Is this all
 documented in a good way (preferrably with examples) somewhere? If so,
 pointer please. If not, can it please be?
 
>>> 
>>> It is not.   Contributions are welcome.
> 
> If we want to help improve documentation, how can we go about it? Is there a 
> wiki somewhere that we can edit?
> 
> Adam Lewenberg
> 
> 
> 
>>> 
>>> 
>>> 
>> 
>> Personal email.  hbh...@oxy.edu
>> 
>> 
>> 
> 

Personal email.  hbh...@oxy.edu

Re: Re-encrypt on change of master key

[Adam Lewenberg]

On 3/16/2017 12:03 PM, Henry B (Hank) Hotz, CISSP wrote:

+1


On Mar 15, 2017, at 5:51 AM, Jeffrey Altman  
wrote:

On 3/15/2017 5:17 AM, Lars-Johan Liman wrote:

Hi!

This whole thread contains a lot of really good information. Is this all
documented in a good way (preferrably with examples) somewhere? If so,
pointer please. If not, can it please be?



It is not.   Contributions are welcome.


If we want to help improve documentation, how can we go about it? Is 
there a wiki somewhere that we can edit?


Adam Lewenberg









Personal email.  hbh...@oxy.edu

Re: Re-encrypt on change of master key

[Henry B (Hank) Hotz, CISSP]

+1

> On Mar 15, 2017, at 5:51 AM, Jeffrey Altman  
> wrote:
> 
> On 3/15/2017 5:17 AM, Lars-Johan Liman wrote:
>> Hi!
>> 
>> This whole thread contains a lot of really good information. Is this all
>> documented in a good way (preferrably with examples) somewhere? If so,
>> pointer please. If not, can it please be?
>> 
> 
> It is not.   Contributions are welcome.
> 
> 
> 

Personal email.  hbh...@oxy.edu

Re: Re-encrypt on change of master key

[Jeffrey Altman]

On 3/15/2017 5:17 AM, Lars-Johan Liman wrote:
> Hi!
> 
> This whole thread contains a lot of really good information. Is this all
> documented in a good way (preferrably with examples) somewhere? If so,
> pointer please. If not, can it please be?
> 

It is not.   Contributions are welcome.





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Re-encrypt on change of master key

[Lars-Johan Liman]

Hi!

This whole thread contains a lot of really good information. Is this all
documented in a good way (preferrably with examples) somewhere? If so,
pointer please. If not, can it please be?

Cheers,
  /Liman
#--
# Lars-Johan Liman, M.Sc.   !  E-mail: li...@netnod.se
# Senior Systems Specialist !  Tel: +46 8 - 562 860 12
# Netnod Internet Exchange, Stockholm   !  http://www.netnod.se/
#--

ada...@stanford.edu:
> On 3/14/2017 3:57 PM, Nico Williams wrote:
>> 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

> I see.

> If I trust the backup operator (e.g., it's me), then it still might be
> useful as at the very least it makes it harder for anyone who runs
> across the database file to guess the passwords. On the other hand,
> encrypting the entire file before backup, as you suggest, accomplishes
> this _and_ removes the concern of getting back a compromised database.

> Thanks for the enlightenment.

> Adam Lewenberg

Re: Re-encrypt on change of master key

[Adam Lewenberg]

On 3/14/2017 3:57 PM, Nico Williams wrote:

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


I see.

If I trust the backup operator (e.g., it's me), then it still might be 
useful as at the very least it makes it harder for anyone who runs 
across the database file to guess the passwords. On the other hand, 
encrypting the entire file before backup, as you suggest, accomplishes 
this _and_ removes the concern of getting back a compromised database.


Thanks for the enlightenment.

Adam Lewenberg

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

[Nico Williams]

On Tue, Mar 14, 2017 at 06:41:06PM -0400, Jeffrey Hutzelman wrote:
> 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

Sure, you can propagate to a slave that doesn't have a master key.

> copy/paste attacks or do much of anything for a database at rest

Correct.

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

[Nico Williams]

On Tue, Mar 14, 2017 at 03:26:57PM -0700, Henry B (Hank) Hotz, CISSP wrote:
> > On Mar 14, 2017, at 12:54 PM, Nico Williams  wrote:
> > 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.
> 
> True. iprop will do a full download if the slave wants changes from a
> version older than the master has a record of.
> 
> ipropd-master is a daemon, so I stand by my original statement. ;-)

Restarting it is not sufficient.  You have to remove the iprop log too.

> > 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.
> 
> 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.

Nico
-- 

Re: Re-encrypt on change of master key

[Henry B (Hank) Hotz, CISSP]

> On Mar 14, 2017, at 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.

True. iprop will do a full download if the slave wants changes from a version 
older than the master has a record of.

ipropd-master is a daemon, so I stand by my original statement. ;-)
 
>> 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.

Probably, but encrypting the key material separately doesn’t seem like a bad 
thing.

> 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.

Off-topic, but I agree. A lot of people are deploying HSMs believing they will 
solve problems they won’t.

> 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
> -- 

Personal email.  hbh...@oxy.edu

Re: Re-encrypt on change of master key

[Nico Williams]

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.

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

[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&Kerb 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&Kerb best 
practices workshops, but I don’t remember the year.

Personal email.  hbh...@oxy.edu