Re-encrypt on change of master key

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re-encrypt on change of master key

Adam Lewenberg
How do I re-encrypt the entries of the Heimdal KDC database if I want to
change its master key?


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re-encrypt on change of master key

Henry B (Hank) Hotz, CISSP-2
How’s the contract coming?

> On Mar 14, 2017, at 9:43 AM, Adam Lewenberg <[hidden email]> 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.  [hidden email]



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re-encrypt on change of master key

Henry B (Hank) Hotz, CISSP-2
https://www.mail-archive.com/heimdal-discuss@.../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 <[hidden email]> wrote:
>
>> On Mar 14, 2017, at 9:43 AM, Adam Lewenberg <[hidden email]> 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.  [hidden email]

Personal email.  [hidden email]



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re-encrypt on change of master key

Russ Allbery-2
In reply to this post by Henry B (Hank) Hotz, CISSP-2
"Henry B (Hank) Hotz, CISSP" <[hidden email]> 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 ([hidden email])              <http://www.eyrie.org/~eagle/>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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" <[hidden email]> 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
--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re-encrypt on change of master key

Henry B (Hank) Hotz, CISSP-2

> On Mar 14, 2017, at 12:54 PM, Nico Williams <[hidden email]> wrote:
>
> On Tue, Mar 14, 2017 at 12:32:10PM -0700, Russ Allbery wrote:
>> "Henry B (Hank) Hotz, CISSP" <[hidden email]> 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.  [hidden email]



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> 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
--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re-encrypt on change of master key

Jeffrey Hutzelman
On March 14, 2017 6:32:13 PM EDT, Nico Williams <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re-encrypt on change of master key

Adam Lewenberg
In reply to this post by Nico Williams


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" <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
--
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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





>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re-encrypt on change of master key

Lars-Johan Liman-2
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: [hidden email]
# Senior Systems Specialist             !  Tel: +46 8 - 562 860 12
# Netnod Internet Exchange, Stockholm   !  http://www.netnod.se/
#----------------------------------------------------------------------

[hidden email]:

> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re-encrypt on change of master key

Jeffrey Altman-2
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 (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re-encrypt on change of master key

Henry B (Hank) Hotz, CISSP-2
+1

> On Mar 15, 2017, at 5:51 AM, Jeffrey Altman <[hidden email]> 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.  [hidden email]



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]> 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.  [hidden email]
>
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re-encrypt on change of master key

Henry B (Hank) Hotz, CISSP-2
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 <[hidden email]> 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 <[hidden email]> 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.  [hidden email]
>>
>>
>>
>

Personal email.  [hidden email]



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re-encrypt on change of master key

Quanah Gibson-Mount-2
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"
<[hidden email]> 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 <[hidden email]> 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
>>>> <[hidden email]> 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.  [hidden email]
>>>
>>>
>>>
>>
>
> Personal email.  [hidden email]
>
>
>



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

Loading...