[Freeipa-devel] DNSSEC design page: key wrapping

Tue Mar 4 22:14:34 UTC 2014

On 4.3.2014 22:53, Simo Sorce wrote:
> On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote:
>> On 4.3.2014 22:15, Simo Sorce wrote:
>>> On Tue, 2014-03-04 at 21:25 +0100, 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:
>>>>>>>>>>>> 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?
>>>>
>>>> Can the vault approach work for Kerberos master key? If not, shouldn't we
>>>> design something universal instead of deferring it again and again?
>>>
>>> We can use the same method for the M/K, now that the CA is installed
>>> before the rest we do not have a chicken-egg issue anymore.
>>>
>>>> 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).
>>>
>>> It could be optional.
>>>
>>>> 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')
>>>
>>> What is 'none' ?
>> I mean 'attribute is not present'.
>>
>>>>> 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.
>>>
>>> Well ... TBH I am not really that hot about storing private keys in IPA
>>> like that, however for people that want to do it they can simply store
>>> them not encrypted as you proposed above.
>>>
>>>> Please correct me if I'm wrong.
>>>
>>> You are right, but I was caring for the DNS keys case, not the user's
>>> ssh key case, which is hairy IMHO.
>> There is no difference between DNSSEC keys and any other keys except the fact
>> that we need shared wrapping key for DNSSEC. Nothing else. Note that SSH
>> private key is just an example. You can use PKCS#11 as storage for user
>> certificates used for authentication in Firefox etc.
>>
>>> I think the private ssh key case is a clear job for the Vault the fact
>>> sssd might use a pkcs#11 interface to present it to ssh, or the user
>>> simply pulls it to the local file system is, in my view, an
>>> implementation detail.
>> I can see a huge difference. Properly implemented PKCS#11 provides you the
>> same separation as GSS-Proxy for keytabs. I.e. non-root process will not be
>> able to extract any private keys.
>>
>> Also, PKCS#11 is a standard so any application can use it. I don't like
>> IPA-specific hacks, let's use a standard.
>
> Standards are fine. That's not the point though.
>
>>> Although I realize I have not said it explicitly before I am not all
>>> that happy to have a generic pkcs#11 storage in IPA. Storing *arbitrary
>>> private* keys in my mind is clearly the job of DRM which has been built
>>> with that specific use case in mind and has all the appropriate
>>> protections. Putting unencrypted private keys in the IPA tree is IMHO a
>>> too high risk.
>> Oh wait, I think we misunderstood each other. I'm not proposing to store any
>> keys unencrypted (in IPA)! I only want to design the LDAP schema not to be
>> IPA-specific, nothing else.
>>
>> In case of IPA we can always encrypt all keys (when we have vault available).
>> I hope this clears the misunderstanding.
>
> Well if the Vault is the storage, then why do we care for an LDAP
> schema ?
We need PKCS#11 for CA certificates, BIND and OpenDNSSEC anyway so we need to 
design schema for *public* data. All private data can be stored in Vault if we 
agree on that.

In theory, we can use proposed schema for PKCS#11 key storage and just replace 
private key attributes with an reference to vault and we are done.

> I think Vault is the right storage for user custom data or application
> custom data.
>
> I am not sure we want to depend on the vault for DNS, because it needs
> high availability, however given we copy the keys on the local
> filesystem, once generated, perhaps the Vault is sufficient if it is a
> replicated system. I am not sure DRM is replicated, or will be
> replicated in the first incarnation, so that's why I am treating DNS
> differently.
>
>>> I am not against creating a generic schema if we think it may be useful
>>> for others, but the more I thin of it the less I think we should use it
>>> for anything but DNS keys and they should be definitely encrypted in
>>> LDAP and the DNS server machines should be the only ones able to decrypt
>>> them.
>> Even if all keys will be encrypted?
>
> ELOOP ? :)
>
>>> A casual search with directory manager should never yield private keys.
>> It makes sense. As I said above, all keys should be encrypted when the
>> proposed schema will be used as part of IPA.
>>
>>
>> Anyway, should we use vault for key storage from the beginning and do not
>> spend time on a throw-away schema design etc.?
>>
>> I can see the reasoning and we don't need two mechanisms for the same thing.
>
> Right.
>
> I guess my only reservation is about whether DRM storage is replicated
> or not. Although both the K/M and DNS cases do not require the Vault to
> be online at all times because the keys will be downloaded and stored
> locally and only needs to be accessed when they changed, there is the
> problem of having all keys in a SPOF, that should not happen.
According to http://www.freeipa.org/page/V4/Password_Vault#Replication the 
replication is available for DRM, we just need to use it.

IMHO a vault without replication is not useful anyway. Users are not happy 
when their passwords disappear ;-)

> The additional thing about the Vault is that we can use key escrow there
> as a mechanism to re-encrypt automatically system relevant keys when a
> new server is joined to the realm.
So we agree that Vault offers what we want so we should use it, right?

I think we should determine if we can use Vault for K/M. It would be another 
reason why we should use Vault instead of a custom solution.

-- 
Petr^2 Spacek