[Freeipa-devel] Password Vault Implementation

[Endi Sukma Dewata]

On 8/1/2014 3:04 PM, Endi Sukma Dewata wrote:
> On 8/1/2014 2:45 PM, Simo Sorce wrote:
>> On Fri, 2014-08-01 at 14:42 -0500, Endi Sukma Dewata wrote:
>>> 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?
>>
>> The service can create a symmetric key and encrypt it with its public
>> key and the escrow public key.
>
> Not sure I understand. How does the admin provision the service vault 
> password to the instance? How does the instance retrieve the service 
> vault password? How does the escrow officer recover the service vault 
> password?

Hi,

Please take a look at the revised design:
http://www.freeipa.org/page/V4/Password_Vault_Implementation

The design now supports two types for vaults:
- regular vault with symmetric key derived from vault password,
- and drop box with asymmetric keys which may be new keys generated for 
vault, not necessarily the owner's personal keys.

Both types will support escrow now. On regular vault we escrow the vault 
encryption/secret key. On drop box we escrow the vault private key. It 
will also support multiple escrow officers. The escrow officers need to 
share the escrow private key (not the escrow officer's personal keys).

I removed the password hash used previously to verify the password. 
Assuming that retrieving secrets with a wrong password/key will not 
produce a usable result (invalid JSON structure), it's no longer 
necessary to verify password.

The Client API has been simplified as well by handling the secrets as a 
single collection. The CLI will still provide the interface to manage 
the secrets individually. There's no service-specific API, it will be 
handled by the CLI.

Please let me know if you have any comments/questions. See also the FAQ 
and To Do list at the bottom of the page. I'll be out of the office 
until Thursday, but I'll be back on Friday 22nd. Thanks!

-- 
Endi S. Dewata