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

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to