[Freeipa-devel] DNSSEC design page: key wrapping

[Dmitri Pal]

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?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/