On 9.8.2013 15:12, Rob Crittenden wrote:
How do we select the 'super-master' for CA certificates? I would re-use the
same logic (for now).
Simo Sorce wrote:
On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:
On 23.7.2013 10:55, Petr Spacek wrote:
On 19.7.2013 19:55, Simo Sorce wrote:
I will reply to the rest of the message later if necessary, still
digesting some of your answers, but I wanted to address the following
On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote:
The most important question at the moment is "What can we postpone?
fragile it can be for shipping it as part of Fedora 20?" Could we
DNSSEC support as "technology preview"/"don't use it for anything
Until we figur out proper management in LDAP we will be a bit stuck, esp
if we want to consider usin the 'somthing' that stores keys instead of
toring them stright in LDAP.
So maybe we can start with allowing just one server to do DNSSEC and
source keys from files for now ?
The problem is that DNSSEC deployment *on single domain* is 'all or nothing':
All DNS servers have to support DNSSEC otherwise the validation on client
can fail randomly.
Note that *parent* zone indicates that the particular child zone is secured
with DNSSEC by sending DS (delegation signer) record to the client.
will fail if client receives DS record from the parent but no signatures are
present in data from 'child' zone itself.
This prevents downgrade (DNSSEC => plain DNS) attacks.
As a result, we have only two options: One DNS server with DNSSEC enabled or
arbitrary number DNS servers without DNSSEC, which is very unfortunate.
as soon as we have that workign we should also have clearer plans about
how we manage keys in LDAP (or elsewhere).
Dmitri, Martin and me discussed this proposal in person and the new plan is:
- Elect one super-master which will handle key generation (as we do with
special CA certificates)
I guess we can start this way, but how do you determine which one is
In DNSSEC it could be a problem. Each signature contains validity interval and
validation will fail when it expires. It practically means that DNS will stop
working if the keys are not rotated in time. (More keys can co-exists, so the
roll-over process can be started e.g. a month before the current key really
I do not really like to have all this 'super roles', it's brittle and
admins will be confused which means one day their whole infrastructure
will be down because the keys are expired and all the clients will
refuse to communicate with anything.
AFAIU keys don't expire, rather there is a rollover process. The problem would
be if the server that controlled the rollover went away the keys would never
roll, leaving you potentially exposed.
I definitely agree. IMHO the basic problem is the same or very similar for
DNSSEC key generation & CA certificates, so we should solve both problems at
once - one day.
I think it is ok as a first implementation, but I think this *must not*
be the final state. We can and must do better than this.
I mean - we need to coordinate key & cert maintenance between multiple masters
somehow - and this will be the common problem for CA & DNSSEC.
Interesting. The master key is stored in the krbMKey attribute in
cn=REALM,cn=kerberos,dc=your,dc=domain , I didn't know that.
- Store generated DNSSEC keys in LDAP
- Encrypt stored keys with 'DNSSEC master key' shared by all servers
- Derive 'DNSSEC master key' from 'Kerberos master key' during server
install/upgrade and store it somewhere on the filesystem (as the Kerberos
master key, on each IPA server)
The Kerberos master key is not stored on disk, furthermore it could
change, so if you derive it at install time and install a replica after
it was changed everything will break. I think we need to store the key
in LDAP, encrypted, and dump it to disk when a new one is generated.
That was the original intention - generate a new 'DNSSEC master key'/'DNSSEC
wrapping key' and let named+certmonger/oddjob to play with it.
Aside, DNSSEC uses pub/private key crypto so this would be a special
'master key' used exclusively to encrypt keys in LDAP ?
I mean: How hard would it be to extend certmonger/oddjob to take care of
DNSSEC key maintenance?
- Consider certmonger or oddjob as key generation triggers
I do not understand this comment.
It definitely requires some changes in certmonger, I'm just exploring various
He is trying to automate the key rollover. I don't think certmonger will work
as it is designed for X.509 certs. Are you proposing an additional attribute
to schedule the rollover? I thought that it was a good idea to have some
flexibility here to prevent timed DoS attacks for rollover time.
It is correct as long as you don't need to change the 'derived' key without a
change in the 'source' key. Did I miss something? We don't need to dive into
details because (as Simo pointed out) the K/M can change.
I think that we should add one new thing - a 'salt' - used for Kerberos master
key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC
master key as necessary without a change in the Kerberos master key.
Salts are not necessary, HKDF from a cryptographically random key does
not require it.
Does it make sense? Does anybody have any ideas/recommendations which
libraries we should use for key derivation and key material en/decryption?
openssl/nss I already have all the basic code we need for that.
I prefer the procedure just outlined in
just calls dnssec-keygen rather than trying to roll your own. I don't know
what derivation really buys you.
I think that there is slight misunderstanding. We need to decide how the keys
generated by dnssec-keygen will be wrapped with 'the DNSSEC master key'. I
totally agree with using dnssec-keygen for the 'key generation' part! :-)
Simo proposed to use separate keys for each IPA DNS server. It could work in
theory, but I can see some problems:
How the keys are split:
- The (trusted) parent zone 'com.' contains hashes of public parts of KSKs
(key signing keys) used by child zone 'example.com.'
- The child zone 'example.com.' contains the whole public parts of KSKs and ZSKs
- KSKs signs ZSKs (zone signing key, the keys used for signing of real data)
top ] hash of the KSKs in parent zone 'com.'
middle] KSKs in the zone 'example.com.'
bottom] ZSKs - 'zone subkeys' used for real data signing
How the client validates DNSSEC signatures (client operates with public keys):
1) Read hashes of KSKs from (trusted) parent domain 'com.'
2) Get KSKs from the child domain 'example.com.'
3) Compare hashes received from parent domain with hashes computed from KSKs.
4) Trust ZSKs published in the zone 'example.com.' if they are signed by valid
KSK (valid = hash from parent and the zone itself match).
5) Get data requested by user along with signatures.
6) Validate that the data are signed by one of valid ZSKs.
The point is that *parent* zone has to contain all KSKs used by all IPA
servers. As a result, different keys on each IPA server will create very
interesting game with KSKs (on each KSK re-generation, i.e. approximately once
The another problem is that each key & signature contains key-id, which has to
be unique for each key. The client use this key-id to chose the right public
key for signature validation.
Key-id is 16 bits long unsigned integer, so there is not much space for
distributed number assignment.
Fortunately, you can re-use key-id if the key was removed from the zone and
records with this key-id disappeared from all caches. A secure interval for
key-id reuse can be determined from key TTL.
And the third problem: Many keys in parent zone will result in much bigger
responses to clients from the parent. It could cause some problems if we
exceed some 'local limit'. Some crazy firewalls could drop large UDP DNS
packets and TCP is not very nice solution alternative.
Freeipa-devel mailing list