[Freeipa-devel] DNSSEC design page: key wrapping

[Petr Spacek]

On 4.3.2014 17:43, Dmitri Pal wrote:
> On 03/04/2014 11:25 AM, Petr Spacek wrote:
>> 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 ...
>>
> Without Dogtag? Vault would be an independent component from CA I assume,
> though CA might be needed anyways to issue transport keys for the internal
> components.
> But I think that even if we use Vault as an internal password and key storage
> I do not see a reason why we can't require it for DNSSEC.
> Why over-complicate things if we already have components that can be used? If
> we see a requests to support DNSSEC without Vault component we will adjust but
> I do not think we should limit ourselves in the first implementation.

I'm personally fine with that.

Are we going to re-prioritize Password Vault from Backlog to 4.0?
https://fedorahosted.org/freeipa/ticket/3872

We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo 
that key wrapping is not necessary :-)

-- 
Petr^2 Spacek