On 6/2/2015 1:10 AM, Martin Kosek wrote:
Hi Endi,

Quickly skimming through your patches raised couple questions on my side:

1) Will it be possible to also store plain text password via Vault? It
talks about taking in the binary data or the text file, but will it also
work with plain user secrets (passwords)? I am talking about use like this:

# ipa vault-archive <name> --user mkosek --data Secret123

For security the plain text password should be stored in a file first:

  # vi password.txt
  # ipa vault-archive <name> --user mkosek --in password.txt

It's also possible to specify the password as base-64 encoded data:

  # echo -n Secret123 | base64
  # ipa vault-archive <name> --user mkosek --data U2VjcmV0MTIz

But it's not recommended since the data will be stored in the command history and someone could see and decode it. I think passing a plain text password as command line argument would be even worse. The --data parameter is mainly used for unit testing.

Later we might be able to add an option to read from standard input:

  # cat password.txt | ipa vault-archive <name> --user mkosek --std-in

2) Didn't we discuss a dependency of IPA/Vault on python-cryptography in
the past? I rather see use of python-nss for cryptography...

Yes. I might have mentioned that it would be in the 2nd (current) vault patch. Actually it will be in the 3rd patch when we add the symmetric and asymmetric vaults. The symmetric and asymmetric encryption will be implemented using python-cryptography. You can also see this in an old patch (#358) but it's obsolete now.

The standard vault in the current patch uses python-nss for transport encryption because when the KRA interface was written python-cryptography wasn't available on Fedora, it didn't support certificates, and I'm not sure if it supports key wrapping.

The symmetric and asymmetric vaults add an additional layer of encryption on top of the standard transport encryption, so it will depend on both python-nss and python-cryptography.

In the future if the KRA can support python-cryptography without python-nss we may be able to drop the python-nss dependency from vaults.

3) You do a lot of actions in the forward() method (as planned in
https://www.freeipa.org/page/V4/Password_Vault#Archival). But how do you
envision that this is consumed by the Web UI? It does not have access to
the forward() method. Would it need to also include some crypto library?

If Web UI wants to access vault (not sure if everybody agrees with that), it would have to perform an encryption on the browser side. In that case we will need to use either WebCrypto or a browser-specific extension to implement something similar to vault_archive.forward(), assuming the required cryptographic functionalities are available. In the future PKI might be able to provide a JavaScript interface for KRA.

4) In the vault-archive forward method, you use "pki" module. However,
this module will be only available on FreeIPA PKI-powered servers and
not on FreeIPA clients - so this will not work unless freeipa-client
gets a dependency on pki-base - which is definitely not something we
want...

In my opinion it should be fine to require pki-base on the client because it contains just the client library, unless you have other concerns? Any objections to having pki-nss and pki-cryptography dependencies on the client?

Even if we can change the client code not to depend on "pki" module, since in this framework the client and server code are written in the same plugin, the "import pki" still cannot be removed since it's still needed by the server code, and I don't think conditional import is a good programming practice.

Thanks,
Martin

--
Endi S. Dewata

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to