[Freeipa-devel] LDAP schema for DNSSEC keys

Thu Jun 12 14:23:49 UTC 2014

On 30.4.2014 18:19, Petr Spacek wrote:
> following text summarizes schema & DIT layout for DNSSEC key storage in LDAP.

I have added object classes and default values for attributes I consider 
important. This is final proposal for implementation. Please review it ASAP.

> 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?
>
> 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

dn: ipk11Label=zone1_keyid123_public, cn=keys, cn=sec, cn=dns, dc=example
objectClass: ipk11Object
objectClass: ipk11PublicKey
objectClass: ipaPublicKeyObject
ipk11UniqueId: <UUID>
ipk11Label: zone1_keyid123_public
ipk11Wrap: FALSE
ipk11Verify: TRUE
ipaPublicKey: <public key>

dn: ipk11Label=zone1_keyid123_private, cn=keys, cn=sec, cn=dns, dc=example
objectClass: ipk11Object
objectClass: ipk11PrivateKey
objectClass: ipaPrivateKeyObject
objectClass: ipaWrappedKey
ipaWrappingKey:ipk11Label=dnssec_m1,cn=master,cn=keys,cn=sec,cn=dns,dc=example
ipk11Sign: TRUE
ipk11Decrypt: FALSE
ipk11Unwrap: FALSE
ipaPrivateKey: <blob encrypted with DNSSEC master key>

>   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.)
This will be sorted out in separate thread.

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

- Please note that private part of this key is stored on disk.

dn: ipk11Label=wrapkey_replica1,cn=DNS,cn=<replica 
FQDN>,cn=masters,cn=ipa,cn=etc,dc=example
objectClass: ipk11Object
objectClass: ipk11PublicKey
objectClass: ipaPublicKeyObject
ipk11UniqueId: <UUID>
ipk11Label: wrapkey_replica1
ipk11Wrap: TRUE
ipk11Encrypt: FALSE
ipk11Verify: FALSE
ipaPublicKey: <public key>

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

dn: ipk11Label=dnssec_m1, cn=master, cn=keys, cn=sec, cn=dns, dc=example
objectClass: ipk11Object
objectClass: ipk11SecretKey
objectClass: ipaWrappedKey
objectClass: ipaSecretKeyObject
ipk11UniqueId: <UUID>
ipk11Label: dnssec_m1
ipk11Wrap: TRUE
ipk11UnWrap: TRUE
ipk11Encrypt: FALSE
ipk11Decrypt: FALSE
ipk11Sign: FALSE
ipk11Verify: FALSE
ipaWrappingAlgo: <algorithm used for key wrapping>
ipaSecretKeyWrappedData: <encrypted blob for replica-1>
ipaSecretKeyWrappedData: <encrypted blob for replica-2>
ipaWrappingKey: <DN of replica-1 public key>
ipaWrappingKey: <DN of replica-2 public key>

Petr^2 Spacek

> 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