[Freeipa-devel] DNSSEC design page: key wrapping

[Petr Spacek]

On 4.3.2014 21:25, Petr Spacek wrote:
> On 4.3.2014 20:48, Simo Sorce wrote:
>> On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote:
>>> On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote:
>>>> 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 :-)
>>>
>>> For 4.0 we could document that you have to copy the keys around
>>> manually. And add Vault support in 4.1 ?
> It could work ... Can we modify ipa-replica-prepare in 4.0 to add the wrapping
> key to replica file to make it easier?

Where are we going to store private keys for DNS services (for vault)?

> Can the vault approach work for Kerberos master key? If not, shouldn't we
> design something universal instead of deferring it again and again?
>
> Another problem is that the PKCS#11 LDAP schema was designed as
> application-independent but now we are adding very specific key-wrapping
> mechanism (it is hard to believe that somebody else will implement it).
>
> Maybe we can add something like attribute 'pkcs11keyWrapMech':
> - key is not wrapped if it is not present
> - key is wrapped if it is present - value determines used mechanism (mandatory
> mechanism to implement is only 'none')
>
>> Actually an idea came to mind that might work well enough.
>>
>> We could store the symmetric key wrapped itself.
> ???
>
>> The wrapping would be done using a public key per DNS server.
>> Public keys for DNS servers would be generated via certmonger in the
>> usual way.
> I don't understand, maybe it is too late for me :-)
>
> Where will the private key be stored?
>
>> The only unknown here is who adds a new wrapper wen a new server is up
>> and it publishes the public key in LDAP. For existing servers they can
>> re-wrap themselves.
>>
>> It's a few layers but should not be too hard.
> I don't fully understand to your proposal but I'm afraid that it will not work
> for ordinary IPA users. Don't forget that we want to have universal PKCS#11
> storage usable even for private SSH keys and other stuff.
>
> Please correct me if I'm wrong.
I guess that you mean something like
http://www.freeipa.org/page/V4/Password_Vault#Service_Workflows , right?

-- 
Petr^2 Spacek