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

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to