[Freeipa-devel] DNSSEC design page: key wrapping

[Dmitri Pal]

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.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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