[Freeipa-devel] [PATCH] Password vault

[Martin Kosek]

On 06/02/2015 02:07 PM, Endi Sukma Dewata wrote:
> 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

Ok. Well, base64 + file input look as good enough for now. I was mostly
concerned about usability of the solution for normal users as for a manual
secret, it is not convenient to always create an interim file.

We will see based on user experience, maybe Web UI or further CLI-only
additions will be the answer.

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

Ok.

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

Ok.

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

Ok, makes sense. I think we will want Web UI at some point, but the summary for
FreeIPA 4.2 seems - no Web UI for Vault (yet).

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

I have major concerns here. Look at the different between installing
"freeipa-client" and "freeipa-client + pki-base" on my F21:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ sudo yum install freeipa-client
...
Install  1 Package (+4 Dependent packages)

Total download size: 2.6 M
Installed size: 14 M
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ sudo yum install freeipa-client pki-base
...
Install  2 Packages (+288 Dependent packages)

Total download size: 160 M
Installed size: 235 M
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is obviously a no-go for client. The conditional import is smaller concern
that big dependency growth on the client. We do them in trust plugin for
example and it works fine (though I agree it is not ideal programming practice).

IMO, we should limit new freeipa-client dependencies only to
python-cryptography (or also python-nss in the worst case, in case
python-cryptography is not enough) - there should be no pki dependencies at
all, these should be only on the server side.

Thanks,
Martin