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:

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

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


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:

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:

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?

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


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

Freeipa-devel mailing list

Reply via email to