[Freeipa-devel] Password Vault Implementation

[Simo Sorce]

On Thu, 2014-07-31 at 13:05 -0500, Endi Sukma Dewata wrote:
> On 7/31/2014 10:58 AM, Simo Sorce wrote:
> >> http://www.freeipa.org/page/V4/Password_Vault_Implementation
> 
> > I am reading this document and there are some things I need to ask
> > clarification for:
> >
> > * In "Vault password and secret key" you describe a mechanism where you
> > store a hash of the password used to generate the secret key, why ?
> > What's the purpose ?
> 
> The hash is for password verification. The encryption/secret key is for 
> encrypting the secrets. The hash will be different from the secret key 
> because they are generated with different salts. The hash is stored on 
> the server, but since it's different it cannot be used to decrypt the 
> secrets.
> 
> We need a password verification to make sure all secrets in the same 
> vault are encrypted with the same password. If we allow different 
> passwords for different secrets, the password change command wouldn't 
> make sense because it will only work on some secrets and corrupt the others.
> 
> I'm open to other ways for password verification without hash. Any 
> suggestions?

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.

> > * Why shared vaults need to be in a /shared/ namespace ?
> > Can't a user create a vault and then share it with other users ?
> > Ie should the fact a vault is shared just a property that can be changed
> > at any time ? If not, why not ?
> 
> We want to avoid conflicting names of private vaults created by 
> different people, so we put private vaults under the owner's namespace. 
> Yes, the owner can share the private vaults in their namespace, but the 
> ownership can change, or it can be owned by multiple people, or probably 
> the original owner will not be the owner anymore. So the /shared 
> namespace is provided for a global, non-user-specific vaults. The owner 
> can move a private vault into /shared, and vice versa, as long as it 
> doesn't conflict with an existing vault.

Ok

> The list of secrets are available to vault members/owners/escrow 
> officer/admin only, but they don't need to specify a password to view 
> the secret metadata. Non-members will not be able to see anything in the 
> vault including the list of secrets. If a member is not allowed to see 
> the list of secrets in a vault, the secrets probably should be split 
> into different vaults.

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.

> If we want to protect the secret metadata with password, does it mean we 
> need to encrypt it too?

Yes.

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

> > * In "Modifying a secret" you use "ipa vault-secret-del" but you mean
> > -mod I guess.
> 
> Yes, that's a copy & paste error. It has been fixed now.
> 
> > * 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/

>  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 paragraph "Changing service vault password" confuses me, is it
> > correct ?
> 
> I revised the wordings in this section, please take a look again:
> http://www.freeipa.org/page/V4/Password_Vault_Implementation#Service_Operations
> 
> Please also see the design page:
> http://www.freeipa.org/page/V4/Password_Vault#Service_Workflows

Thanks,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York