[Freeipa-devel] Password Vault Implementation

[Endi Sukma Dewata]

On 7/31/2014 1:30 PM, Simo Sorce wrote:
>>>> http://www.freeipa.org/page/V4/Password_Vault_Implementation

> I was thinking whether we should use a single attribute for each vault,
> and format the data within the vault as a json blob, to organize the
> data within the blob.
>
> This would allow us to encrypt everything including names and
> descriptions of the single secrets. This way we also do not need to
> verify the password, as there is a single encrypted blob and not
> multiple ones.

> I am more concerned about an admin just seeing the secrets descriptions,
> or someone finding a backup etc...
> I was considering the vault as a unit to which either you have or not
> access based on encryption, not on access control done in LDAP. See
> above my proposal also that goes in this direction.

The "compartment" concept was actually proposed by Dmitri to help manage 
the secrets. I translated that into "vault" since a vault is essentially 
a compartment.

We can certainly change the design to use separate password for each 
secret. But suppose you have many secrets, you will be responsible to 
remember the password for each secret. Would that be a reasonable 
requirement for people in general? Encrypting the secret metadata is a 
separate issue, we can do that either way. See comments below.

Vault as a compartment will help reduce that burden by using the same 
password for multiple secrets. It also can help if you're sharing 
multiple secrets with the same group of people. You can also create 
separate vaults for each secret if necessary, or the server can be 
configured to limit the number of secrets in each vault.

>> Or we can make the access control more granular. Only owners can see the
>> list of secrets.
>
> I am not sure listing the secrets within the vault w/o decrypting the
> vault is necessarily valuable.

Any concern about the crypto operations being computationally expensive, 
or retrieving the whole blob just to see the metadata would waste bandwidth?

Even if we encrypt individual secrets with the metadata, the secret name 
itself will still be visible to the admin, and it might give out clues 
as to what is in the secret. You can use cryptic names for the secrets, 
but you'll have to maintain it on your own.

Let's see if the analogy with safe deposit box in a bank makes sense:

1. Use one box (vault) to store multiple items (secrets). You will have 
one key (vault password) and you will need it to see what's inside.

2. Like #1, but the bank keeps a list of items (metadata) in the box and 
only share it with authorized people (vault members). You can identify 
yourself as a member with an ID (Kerberos principal), but you still need 
a key (vault password) to get the items.

3. Use a separate box to store each item (separate password for each 
secret). You will have to manually keep track which key for which box/item.

>>> * Why services are in the /shared/ namespace ?
>>
>> Services don't seem to be something that you want to associate with a
>> specific user.
>
> Not with a user, with a service.
> /services/openvpn at foo.example.com/

We probably can add new commands (or repurpose the commands) to manage 
the namespace. So initially there will be /users and /shared, but you 
can add others such as /services.

>>   So in that case it's put under the /shared namespace.
>> Even so, the vault membership can still be limited to certain
>> users/service instances. Being in /shared doesn't mean it's open for public.
>
> Understood, but if you have the same "service" on multiple machines then
> it quickly becomes difficult to sort it out, I would prefer a logic
> similar that of the user, just with fully qualified service names under
> a /services/ namespace

The vault namespace is hierarchical, so you can organize it in any way 
you want:
* /services/<service name>@<server name>
* /shared/services/<server name>/<service name>

In the current wiki page the service admin can pick the vault name 
(/shared/services is just an example), but the secret names in it are 
generated from the service principal (to make sure the service admin and 
the service instance use the same secret name).

-- 
Endi S. Dewata