[Freeipa-devel] LDAP schema for DNSSEC keys

Tue Jul 29 09:49:06 UTC 2014

Dne 29.7.2014 v 08:56 Simo Sorce napsal(a):
> On Tue, 2014-07-29 at 08:46 +0200, Jan Cholasta wrote:
>> Dne 28.7.2014 v 11:04 Simo Sorce napsal(a):
>>> On Fri, 2014-07-25 at 19:26 +0200, Petr Spacek wrote:
>>>>
>>>> I have updated design page and diagrams:
>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#LDAPschema
>>>
>>> Excellent page, I took a full read and it all seem reasonable.
>>>
>>> However I would like a page like this with the detailed summary of key
>>> material handling.
>>>
>>> This is important to get right and have documented anyway so if someone
>>> could summarize in detail all the key handling I would be happy to do a
>>> detailed review and think carefully about the security stance of the
>>> final solution we agreed on. If we can do this early it would be better
>>> to avoid costly rewrites should we have forgotten/underestimated some
>>> implementation detail that requires changes.
>>>
>>> Simo.
>>>
>>
>> Do you need more detail than
>> <https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#Keydistribution>?
>
> It's almost there but the wraping/unwrapping steps are a bit handwavy.
>
> I would like more details on algorithms we are going to use and exactly
> what parts do the wrapping and unwrapping. For example we say all these
> operations happen in SoftHSM at the start, but then the steps that
> describe how these keys are inserted into or extracted from SoftHSM are
> vague enough they can be interpreted as these operations are being
> performed outside of SoftHSM. It should be made much clearer exactly
> what component on the system will perform each and any of the key
> (un)wrapping operations and with which keys and algorithms.
>
> Simo.
>

I don't think I'm authorized to edit bind-dyndb-ldap wiki, so I'm going 
to comment the steps from the link above here:

> First server installation (replica1)
>
> This operation needs to be detected and guarded so only one replica will become DNSSEC master. It can be done by writing who is DNSSEC master to cn=masters.
>
>  1. Generate symmetric "master key" for DNSSEC

The master key is generated on the token by C_GenerateKey call using the 
CKM_AES_KEY_GEN mechanism, it is 128b AES, it can be used for wrapping 
and unwrapping keys, it can be extracted from the token by wrapping, but 
not in plaintext.

>
>  2. Generate replica key pair:

The replica key pair is generated on the token by C_GenerateKeyPair call 
using the CKM_RSA_PKCS_KEY_PAIR_GEN mechanism, it is 2048b RSA, the 
public part can be used for wrapping keys and can be extracted from the 
token in plaintext, the private part can be used for unwrapping keys and 
can't be extracted from the token.

>
>       * Store public key to LDAP: cn=DNS,cn=<replica FQDN>,cn=masters,cn=ipa,cn=etc,dc=example sub-tree in LDAP.
>
>       * Store private key to SoftHSM (on disk).

This is already achieved above by generating the replica key pair on the 
token.

>
>  3. Wrap master key with replica key:

The master key is wrapped on the token by C_WrapKey using the 
CKM_RSA_PKCS mechanism and the replica public key as the wrapping key.

>
>       * Store resulting blob in cn=master, cn=keys, cn=sec, cn=dns, dc=example sub-tree in LDAP.
>
>
> Replica installation (replica2)
>
> This is done by ipa-replica-install:
>
>  1. Generate replica key pair:

The replica key pair is generated in the same manner as in first server 
installation.

>
>  2. Store public key to LDAP: cn=DNS,cn=<replica FQDN>,cn=masters,cn=ipa,cn=etc,dc=example sub-tree in LDAP.
>
>  3. Store private key in SoftHSM (on disk).

This is already achieved above by generating the replica key pair on the 
token.

>
> This is done by little daemon running on replica 1:
>
>  1. DNSSEC master-replica will detect (SyncRepl) a new public key in cn=masters sub-tree and will use own private key (replica1's) to re-encrypt master key using public key of the new replica (replica2)

The master key is wrapped in the same manner as in first server 
installation.

>
>  2. Store resulting master-key-blob to cn=master, cn=keys, cn=sec, cn=dns, dc=example sub-tree in LDAP.
>
> This is done by little daemon running on replica 2:
>
>  1. Download blob with master key from LDAP.

The master key is rotated when a replica is deleted, so there may be 
more than one master keys in LDAP, but there will be only one which is 
allowed to wrap keys. This particular master key is downloaded in this step.

>
>  2. Unwrap blob with replica2's private key.

The master key is unwrapped on the token by C_UnwrapKey call using 
CKM_RSA_PKCS mechanism with the replica private key as the unwrapping 
key, it can be used for wrapping and unwrapping keys, it can be 
extracted from the token by wrapping, but not in plaintext.

>
>  3. Store raw master key to local SoftHSM.

This is already achieved above by unwrapping the master key on the token.

>
>
> Replica uninstallation (replica2)
>
> NOTE: replica1 cannot be uninstalled at the moment. Support for this scenario requires more work.
>
> NOTE: Old master keys remain in LDAP and old DNSSEC keys are not touched at all. After all, all keys used before replica removal are on replica2's disk anyway.
>
> This step is done by ipa-replica-manage:
>
>  1. Delete replica entry in cn=masters.
>
> All operations with keys are done by little daemon running on replica1:
>
>  1. Detect that replica2's public key was deleted and initiate master key rotation.
>
>  2. Generate a new master key.

The master key is generated in the same manner as in first server 
installation. After the new master key is generated, wrapping keys using 
the old master key is disabled.

>
>  3. Wrap new master key with all currently published replica-public keys (from cn=masters) and store it to LDAP

The master key is wrapped in the same manner as in first server 
installation.

>
>
> DNSSEC key generation (replica1)
>
> Key wrapping is done only by replica1 which is running OpenDNSSEC Enforcer daemon.
>
>  1. Let OpenDNSSEC Enforcer to generate a key according to time schedule. (OpenDNSSEC Enforcer calls OpenDNSSEC Signer daemon which is replaced by our script.)

OpenDNSSEC generates a key pair on the token by C_GenerateKeyPair call, 
the details are OpenDNSSEC-specific, the private part can be extracted 
from the token by wrapping, but not in plaintext.

>
>  2. Wrap DNSSEC key with newest master key (stored in local SoftHSM) and store resulting blob to cn=keys, cn=sec, cn=dns.

The private key is wrapped on the token by C_WrapKey call using the 
CKM_AES_KEY_WRAP_PAD mechanism and the current master key as the 
wrapping key.

>
>  3. Store key metadata to cn=keys, idnsname=example.net, cn=dns
>
>
> DNSSEC key unwrapping (replica2)
>
> This is done by little daemons running on all replicas with DNS.
>
>  1. Detect a new key in LDAP (SyncRepl).
>
>  2. Download blob from LDAP.
>
>  3. Unwrap blob with master key described by ipaWrappingKey attribute.

The private key is unwrapped on the token by C_UnwrapKey call using the 
CKM_AES_KEY_WRAP_PAD mechanism and the master key specified by 
ipaWrappingKey as the unwrapping key, the private part can be extracted 
from the token by wrapping, but not in plaintext.

>
>  4. Store raw DNSSEC key in local SoftHSM.

This is already achieved above by unwrapping the private key on the token.

-- 
Jan Cholasta