[Freeipa-devel] DNSSEC design page: key wrapping

[Petr Spacek]

On 4.3.2014 17:00, Dmitri Pal wrote:
> On 03/04/2014 10:26 AM, Simo Sorce wrote:
>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:
>>> On 26.2.2014 16:00, Simo Sorce wrote:
>>>>>>> need to be protected as carefully as the private key.
>>>>>>>> This is something I meant to discuss too, how do we protect them ?
>>>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt them with
>>>>>>>> keys not immediately or easily available via LDAP ?
>>>>>>>>
>>>>>>>> It's kind of catastrofic if they get inadvertently exposed like if
>>>>>>>> someone does a ldapsearch as "Directory Manager", which is one of the
>>>>>>>> reasons why we encrypt kerberos key material before storing it into the
>>>>>>>> db.
>>>>>> PKCS#8 allows encryption, I guess we can use that. There needs to be
>>>>>> some metadata on how to decrypt the blob though, so that the PKCS#11
>>>>>> module can actually decrypt it when necessary.
>>>> Yep, and we also need to decide what master key is used and where it is
>>>> placed, and who access it, and how:-)
>>> Let's move the discussion forward, we need to implement the schema for 4.0.
>>>
>>> Do I understand correctly that the whole purpose of
>>> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example
>>> is just to encrypt keys with some other key which is located at some other
>>> place? I.e. the goal is to lower the probability that a random ldapsearch will
>>> return encrypted blob and master key at once, right?
>> Yes, it would also be nice if we could finally offload this key from
>> LDAP for added security, but we are not there yet.
>>
>>> What algorithm/method should we use for key wrapping? As far as I remember
>>> from my studies key wrapping is very sensitive thing and we definitely need to
>>> use some existing standard&tool for doing it. Can we just call some NSS
>>> function with default/system-wide parameters and let it do it's job?
>> I think that would be what we want to do in some form.
>>
>>> That would mean that, after all, we just need to provide some blob as key
>>> wrapping key :-) (Generated with care it deserves etc.)
>> The key must be self describing somehow (for algorithm agility).
>>
>>
>>> We have had discussion with Honza and the first idea is to add attribute like
>>> 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key
>>> when necessary.
>>> - During decryption: Do a LDAP search with filter like (keyId=<wrappingKeyId>)
>>> to find appropriate wrapping key.
>>> - The harder part is how to pick a wrapping key for encryption. It can be
>>> tricky if the wrapped key is shared among more users (DNS servers) etc.
>>> - It is possible to easily use multiple wrapping keys at once so key rollover
>>> is easy. You can re-encrypt keys one by one.
>> This makes things complicated fast.
>> One thing I was thinking was to use a keytab and krb functions to do the
>> wrapping but that would be pretty IPA specific.
>>
>>> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11
>>> objects inside the same token will be encrypted with the same key.
>>> - Decryption is easy - the same as in previous case.
>>> - Encryption is basically the same as encryption.
>>> - Key rollover is hard. You would have to re-encrypt all keys and change
>>> wrappingKeyId associated with given token at once - but it is impossible
>>> because we don't have LDAP transactions. As a result, clients will be confused
>>> during rollover. (Consider problems with syncrepl when clients can see changes
>>> immediately.)
>> Yeah this is a problem we need to address.
>>
>>> The third approach is 'hybrid':
>>> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is
>>> used for encrypting new objects stored into PKCS#11 token. Each key stored in
>>> the token has own wrappingKeyId attribute and it is used for decryption.
>>> - Decryption is easy - the same as in previous case.
>>> - Encryption always use wrappingKeyId associated with given token.
>>> - Key roll over can start from wrappingKeyId associated with the token and
>>> then re-encrypt keys in the token one by one. All keys can be decrypted in any
>>> step (assuming that changes in one LDAP object are atomic).
>>>
>>>
>>> Where is a hole in this design? :-)
>> I do not like the idea of having to add a wrappingKeyId everywhere.
>>
>> My initial though was to have a central place where wrapping keys are
>> stored, and during a rollover period you try all the keys until one
>> works or decryption fails. At the end of rollover you delete the old key
>> so you avoid the additional load.
>>
>>> Where should we store wrapping keys for users/services and DNS servers? User
>>> object or cn=dns doesn't sound like a good idea because it would defeat the
>>> purpose.
>> Indeed. And this is the biggest problem. It would be nice to have a
>> mechanism to securely transfer the key to the DNS servers w/o having to
>> store it permanently in LDAP. If we had this mechanism we'd be able to
>> apply it to the Kerberos master key too. But it can't be confined to
>> installation time only, which is easy, it needs to be possible to update
>> it at a later time, which is where we have issues, as our replication
>> mechanism is LDAP.
>>
>> If we solve the DNA plugin issue with the ability to use groups for
>> authentication I guess we could build a control/extend operation that
>> would allow masters to transfer keys to each other w/o exposing them as
>> LDAP searches, do we want to try to go in that direction ?
>>
>> Simo.
>>
> Should we consider "vault" as a storage for these keys too?
> It already supports recovery of the symmetric and asymmetric keys so may be
> these keys should be stored there?

Maybe. The question is if we want to support DNSSEC without Dogtag ...

-- 
Petr^2 Spacek