[Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance

[Petr Spacek]

On 27.8.2013 23:08, Dmitri Pal wrote:
> On 08/27/2013 03:05 PM, Rob Crittenden wrote:
>> Dmitri Pal wrote:
>>> On 08/09/2013 08:30 AM, Petr Spacek wrote:
>>>> Hello,
>>>>
>>>> I would like to get opinions about key maintenance for DNSSEC.
>>>>
>>>> Problem summary:
>>>> - FreeIPA will support DNSSEC
>>>> - DNSSEC deployment requires <2,n> cryptographic keys for each DNS
>>>> zone (i.e. objects in LDAP)
>>>> - The same keys are shared by all FreeIPA servers
>>>> - Keys have limited lifetime and have to be re-generated on monthly
>>>> basics (in very first approximation, it will be configurable and the
>>>> interval will differ for different key types)
>>>> - The plan is to store keys in LDAP and let 'something' (i.e.
>>>> certmonger or oddjob?) to generate and store the new keys back into
>>>> LDAP
>>>> - There are command line tools for key-generation (dnssec-keygen from
>>>> the package bind-utils)
>>>> - We plan to select one super-master which will handle regular
>>>> key-regeneration (i.e. do the same as we do for special CA
>>>> certificates)
>>>> - Keys stored in LDAP will be encrypted somehow, most probably by some
>>>> symmetric key shared among all IPA DNS servers
>>>>
>>>> Could certmonger or oddjob do key maintenance for us? I can imagine
>>>> something like this:
>>>> - watch some attributes in LDAP and wait until some key expires
>>>> - run dnssec-keygen utility
>>>> - read resulting keys and encrypt them with given 'master key'
>>>> - store resulting blobs in LDAP
>>>> - wait until another key reaches expiration timestamp
>>>>
>>>> It is simplified, because there will be multiple keys with different
>>>> lifetimes, but the idea is the same. All the gory details are in the
>>>> thread '[Freeipa-devel] DNSSEC support design considerations: key
>>>> material handling':
>>>> https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html
>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html
>>>>
>>>> Nalin and others, what do you think? Is certmonger or oddjob the right
>>>> place to do something like this?
>>>>
>>>> Thank you for your time!
>>>>
>>> Was there any discussion of this mail?
>>>
>>
>> I think at least some of this was covered in another thread, "DNSSEC
>> support design considerations: key material handling" at
>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html
>>
>> rob
>>
>>
> Yes, I have found that thread though I have not found it to come to some
> conclusion and a firm plan.
> I will leave to Petr to summarize outstanding issues and repost them.

All questions stated in the first e-mail in this thread are still open:
https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html

There was no reply to these questions during my vacation, so I don't have much 
to add at the moment.

Nalin, please, could you provide your opinion?
How modular/extendible the certmonger is?
Does it make sense to add DNSSEC key-management to certmonger?
What about CA rotation problem? Can we share some algorithms (e.g. for 
super-master election) between CA rotation and DNSSEC key rotation mechanisms?

> BTW I like the idea of masters being responsible for generating a subset
> of the keys as Loris suggested.
E-mail from Loris in archives:
https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html

The idea seems really nice and simple, but I'm afraid that there could be 
some serious race conditions.

- How will it work when topology changes?
- What if number of masters is > number of days in month? (=> Auto-tune 
interval from month to smaller time period => Again, what should we do after a 
topology change?)
- What we should do if topology was changed when a master was disconnected 
from the rest of the network? (I.e. Link over WAN was down at the moment of 
change.) What will happen after re-connection to the topology?

Example:
Time 0: Masters A, B; topology:  A---B
Time 1: Master A have lost connection to master B
Time 2: Master C was added; topology:  A § B---C
Time 3 (Day 3): A + C did rotation at the same time
Time 4: Connection was restored;  topology: A---B---C

Now what?


I have a feeling that we need something like quorum protocol for writes (only 
for sensitive operations like CA cert and DNSSEC key rotations).

http://en.wikipedia.org/wiki/Quorum_(distributed_computing)


The other question is how should we handle catastrophic situations where more 
than half of masters were lost? (Two of three data centres were blown by a 
tornado etc.)

-- 
Petr^2 Spacek