On 18.6.2014 19:19, Petr Spacek wrote:
On 13.6.2014 18:43, Petr Spacek wrote:
On 12.6.2014 17:49, Petr Spacek wrote:
On 12.6.2014 17:19, Simo Sorce wrote:
On Thu, 2014-06-12 at 17:08 +0200, Petr Spacek wrote:
Hello list,
I have realized that we need to store certain DNSSEC metadata for every
(zone,key,replica) triplet. It is necessary to handle splits in replication
topology.
DNSSEC key can be in one of following states:
- key created
- published but not used for signing
- published and used for signing
- published and not used for signing but old signatures exist
- unpublished
Every state transition has to be postponed until relevant TTL expires,
and of
course, we need to consider TTL on all replicas.
Example of a problem
====================
DNS TTL=10 units
Key life time=100 units
Replica=1 Key=1 Time=0 Published
Replica=2 Key=1 Time=0 Published
Replica=1 Key=1 Time=10 Published, signing
Replica=2 Key=1 Time=10 Published, signing
Replica=1 Key=2 Time=90 Generated, published, not signing yet
Replica=2 Key=2 Time=90 <replication is broken: key=2 is not on replica=2>
Replica=1 Key=1 Time=100
^^^ From time=100, all new signatures should be created with key=2 but that
can break DNSSEC validation because key=2 is not available on replica=2.
Can you explain how this break validation ?
Aren't signatures regenerated on each replica ?
They are.
And so isn't each replica self-consistent ?
Ah, sorry, I didn't mention one important detail. Keys published in the zone
'example.com.' have to match keys published in parent zone. There has to be a
mechanism for synchronizing this.
Validation will break if (keys published by parent) are not subset of (keys on
replicas).
Next logical step in the example above is to remove key1 from replica 1 so you
will end replica1 having key2 and replica2 having only key1.
How can we guarantee that synchronization mechanism will not wipe key1 from
parent? Or the other way around? How can we guarantee that key2 was uploaded?
Also, things will break is number of keys in parent exceeds reasonable number
(because DNS replies will be to big etc.).
Proposal 1
==========
- Store state and timestamps for (zone,key,replica) triplet
- Do state transition only if all triplets (zone,key,?) indicate that all
replicas reached desired state so the transition is safe.
- This implicitly means that no transition will happen if one or more
replicas
is down. This is necessary otherwise DNSSEC validation can break
mysteriously
when keys got out of sync.
dn: cn=<some-replica-id>,ipk11Label=zone1_keyid123_private, cn=keys, cn=sec,
cn=dns, dc=example
idnssecKeyCreated: <timestamp>
idnssecKeyPublished: <timestamp>
idnssecKeyActivated: <timestamp>
idnssecKeyInactivated: <timestamp>
idnssecKeyDeleted: <timestamp>
Why do you care for all 5 states ?
In short, to follow RFC 6781 and all it's requirements.
Simo and I have discussed this off-line. The final decision is to rely on
replication. The assumption is that if replication is broken, everything will
break soon anyway, so the original proposal is overkill.
We have to store one set of timestamps somewhere to be able to follow RFC
6781, so we decided to store it in the key-metadata object.
I added other attributes to object class definition so it contains all
necessary metadata. The new object class idnsSecKey is now complete.
Please note that DN in the previous example was incorrect. It is necessary to
store the metadata separately for pairs (zone, key) to cover the case where
key is shared between zones. This also nicely splits metadata from actual key
material.
All attributes are single-valued.
MUST attributes are:
idnsSecKeyRef
idnsSecKeyCreated
idnsSecAlgorithm
dn: cn=<z/ksk+keytag>, cn=keys, idnsname=example.com, cn=dns, dc=example
objectClass: idnsSecKey
idnsSecKeyRef: <DN of the PKCS#11 key object under cn=keys, cn=sec, dn=dns>
idnsSecKeyCreated: <timestamp>
idnsSecKeyPublish: <timestamp>
idnsSecKeyActivate: <timestamp>
idnsSecKeyInactive: <timestamp>
idnsSecKeyDelete: <timestamp>
idnsSecKeyZone: <boolean> equivalent to bit 7 (ZONE) in [1]
idnsSecKeyRevoke: <boolean> equivalent to bit 8 (REVOKE) in [1]
idnsSecKeySep: <boolean> equivalent to bit 15 (SEP) in [1]
idnsSecAlgorithm: <string> used as mnemonic in [2]
I haven't heard any complains so I allocated OIDs and I'm going to implement it.
Relevant LDAP schema is:
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#DNSSECmetadata
Me and Honza have discussed off-line that reference from metadata to key
material should be in form of PKCS#11 URI so it will work even with real HSM.
The new definition is:
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#idnsSecKeyRef
--
Petr^2 Spacek
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
