[Freeipa-devel] Password Vault Implementation

Endi Sukma Dewata edewata at redhat.com
Fri Aug 1 19:42:27 UTC 2014


On 8/1/2014 12:21 PM, Simo Sorce wrote:
>> OK, understood. This means in the service use case the service vault
>> password will have to be provisioned to service instances using separate
>> vaults that use asymmetric encryption key. This type of vaults will
>> become a "drop box" and will not support escrow.
>
> I do not understand why escrow would not be supported, can you
> elaborate ?

See http://www.freeipa.org/page/V4/Password_Vault#Escrow_Workflows.

With a normal vault (symmetric key) the secrets will be encrypted with a 
symmetric secret key, then the secret key itself will be encrypted with 
the escrow officer's public key and stored on the server. On recovery 
the escrow officer will decrypt the encrypted secret key with the 
private key, and use it to decrypt the secrets.

I suppose with a drop box (asymmetric key) the secrets themselves will 
be encrypted with the public key of the owner (i.e. the service 
instance), not the escrow officer. The secrets can only be 
retrieved/recovered using the owner's private key. There's no secret key 
to escrow, unless we want to escrow the owner's private key?

>> OK. Any preference how the service vaults should be structured?
>> * /services/<service name>@<server name> -> repetitive server name?
>> * /services/<server name>/<service name> -> more organized
>
> The latter seem to make more sense to me.
>
>> Is this going to be the service drop box (to provision the service vault
>> password) or the service vault (that the instance is going to access
>> using the service vault password)? Or will the instances access a shared
>> service vault?
>
> Good questions, I am not sure.

Unless there's an objection I'll use it as a drop box. I think each 
service instance should have a mechanism to configure the vaults it's 
going to use anyway, so we don't have to decide this now.

-- 
Endi S. Dewata




More information about the Freeipa-devel mailing list