[Freeipa-devel] DNSSEC design page: key wrapping

[Dmitri Pal]

On 03/04/2014 05:14 PM, Petr Spacek wrote:
> 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.

Do we need it on the server and if so can it be exposed by the vault 
rather than via LDAP?

>
> 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.
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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