[Freeipa-devel] LDAP schema for DNSSEC keys
Rich Megginson
rmeggins at redhat.com
Thu May 1 14:10:41 UTC 2014
On 04/30/2014 10:19 AM, Petr Spacek wrote:
> Hello list,
>
> following text summarizes schema & DIT layout for DNSSEC key storage
> in LDAP.
>
> This is subset of full PKCS#11 schema [0]. It stores bare keys with
> few metadata attributes when necessary.
>
> The intention is to make transition to full PKCS#11-in-LDAP schema [0]
> as easy as possible. This transition should happen in next minor
> version of FreeIPA.
>
> In theory, the transition should be just adding few object classes to
> existing objects and populating few new metadata attributes. Related
> object classes are marked below with "(in long-term)".
>
> Please comment on it soon. We want to implement it ASAP :-)
>
>
> DNSSEC key
> ==========
> - Asymmetric
> - Private key is stored in LDAP as encrypted PKCS#8 blob
> - Public key is published in LDAP
> - Encrypted with symmetric "DNSSEC master key" (see below)
> - Private key - represented as LDAP object with object classes:
> ipaEPrivateKey [1] # encrypted data
> ipaWrappedKey [2] # pointer to master key, outside scope of pure
> PKCS#11
> ipk11PrivateKey [3] (in long-term) # PKCS#11 metadata
> - Public key - represented as LDAP object with object classes:
> ipaPublicKey [1] # public key data
> ipk11PublicKey [3] (in long-term) # PKCS#11 metadata
>
>
> Master key
> ==========
> - Symmetric
> - Stored in LDAP as encrypted blob
> - Encrypted with asymmetric "replica key" (see below)
> - 1 replica = 1 blob, n replicas = n blobs encrypted with different keys
> - A replica uses it's own key for master key en/decryption
> - Represented as LDAP object with object classes:
> ipaESecretKey [1]
> ipk11SecretKey [3] (in long-term)
>
> Replica key
> ===========
> - Asymmetric
> - Private key is stored on replica's disk only
> - Public key for all replicas is stored in LDAP
> - Represented as LDAP object with object classes:
> ipaPublicKey [1]
> ipk11PublicKey [3] (in long-term)
>
>
> DIT layout
> ==========
> DNSSEC key material
> -------------------
> - Container: cn=keys, cn=sec, cn=dns, dc=example
> - Private and public keys are stored as separate objects to
> accommodate all PKCS#11 metadata.
> - We need to decide about object naming:
> - One obvious option for RDN is to use uniqueID but I don't like it.
> It is hard to read for humans.
> - Other option is to use uniqueID+PKCS#11 label or other attributes
> to make it more readable. Can we use multi-valued RDN? If not, why?
> What are technical reasons behind it?
I would encourage you not to use multi-valued RDNs. There aren't any
technical reasons - multi-valued RDNs are part of the LDAP standards and
all conforming LDAP implementations must support them. However, they
are hard to deal with - you _must_ have some sort of DN class/api on the
client side to handle them, and not all clients do - many clients expect
to be able to just do dnstr.lower() == dnstr2.lower() or possibly do
simple escaping.
As far as being human readable - the whole goal is that humans _never_
have to look at a DN. If humans have to look at and understand a DN to
accomplish a task, then we have failed.
Has the DogTag team reviewed this proposal? Their data storage and
workflows are similar.
>
> It is question if we like:
> nsUniqID = 0b0b7e53-957d11e3-a51dc0e5-9a05ecda
> nsUniqID = 8ae4190d-957a11e3-a51dc0e5-9a05ecda
> more than:
> ipk11Label=meaningful_label+ipk11Private=TRUE
> ipk11Label=meaningful_label+ipk11Private=FALSE
>
> DNSSEC key metadata
> -------------------
> - Container (per-zone): cn=keys, idnsname=example.net, cn=dns
> - Key metadata can be linked to key material via DN or ipk11Id.
> - This allows key sharing between zones.
> (DNSSEC-metadata will be specified later. That is not important for
> key storage.)
>
> Replica public keys
> -------------------
> - Container: cn=DNS,cn=<replica
> FQDN>,cn=masters,cn=ipa,cn=etc,dc=example
> - or it's child object like cn=wrappingKey
>
> Master keys
> -----------
> - Container: cn=master, cn=keys, cn=sec, cn=dns, dc=example
> - Single key = single object.
> - We can use ipk11Label or ipk11Id for naming:
> ipk11Label=dnssecMaster1, ipk11Label=dnssecMaster2, etc.
>
>
> Work flows
> ==========
> Read DNSSEC private key
> -----------------------
> 1) read DNSSEC private key from LDAP
> 2) ipaWrappedKey objectClass is present - key is encrypted
> 3) read master key denoted by ipaWrappingKey attribute in DNSSEC key
> object
> 4) use local replica key to decrypt master key
> 5) use decrypted master key to decrypt DNSSEC private key
>
> Add DNSSEC private key
> ----------------------
> 1) use local replica key to decrypt master key
> 2) encrypt DNSSEC private key with master key
> 3) add ipaWrappingKey attribute pointing to master key
> 4) store encrypted blob in a new LDAP object
>
> Add a replica
> -------------
> ipa-replica-prepare:
> 1) generate a new replica-key pair for the new replica
> 2) store key pair to replica-file (don't scream yet :-)
> 4) add public key for the new replica to LDAP
> 3) fetch master key from LDAP
> 4) encrypt master key with new replica public key
> 5) store resulting master key blob to LDAP
> ipa-replica-install:
> 6) generate a new replica-key pair (!)
> 7) store new public key to LDAP
> 8) remove old public key (from replica-file) from LDAP
> 9) fetch master key
> 10) decrypt master key using old private key (from replica-file)
> 11) encrypt master key using new private key (generated locally)
> 12) replace old master key blob in LDAP with new blob (from step 11)
>
> Delete a replica
> ----------------
> This is the tricky part. New master key has to be generated on some
> other replica. What should we do if the ipa-replica-manage command was
> run on deleted replica?
>
> I propose to split replica master key roll-over to two phases:
> Any machine in IPA domain (including to-be deleted replica):
> 1) Delete public key associated with replica from LDAP
> 2) Flip a bit in master key metadata and say "this key needs to be
> re-generated"
> (Maybe we can disable ipk11Wrap boolean to indicate that this key
> should not be used for key wrapping.)
>
> Remaining replicas:
> 3) Periodically check that master key is obsolete
> 4) Wait for (random period of time) to limit probability of collision
> 5) Check that master key is really obsolete and new one is not present
> 6) Generate a new master key
> 7) Encrypt new master key with all replica-public-keys stored in LDAP
> 8) Store new master key blobs to a new LDAP object
> (Conflicts are not a problem up to now because we are not
> deleting old key. In worst case, we will have multiple new master keys.)
> *What should we do now?*
> 9) ??? Re-encrypt all DNSSEC keys with a new master key? (What if we
> have write conflict now?)
> ??? Let old keys there and wait until key rotation mechanism
> replaces all old DNSSEC keys with new DNSSEC keys encrypted with a new
> master key (~ one year)?
> 10) Old master key can be deleted when no other object is referencing
> to it.
>
>
> Congratulations to people who reached this line and didn't skip
> anything :-)
>
> [0] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema
> [1]
> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2
> [2]
> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#FreeIPA_specifics_-_key_wrapping
> [3] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Storage_objects
>
More information about the Freeipa-devel
mailing list