[Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys

[Dmitri Pal]

On 08/02/2011 05:51 PM, Ian Stokes-Rees wrote:
>
>
> On 8/2/11 4:27 PM, Dmitri Pal wrote:
>> On 08/02/2011 02:15 PM, Ian Stokes-Rees wrote:
>>> Is there some mechanism to store private keys (e.g. ssh, pgp, gpg,
>>> X.509) in FreeIPA, tied to a user account, so only the user (via
>>> kerb token or with password prompt) can fetch the token?
>>>
>>> If FreeIPA doesn't make this possible, can anyone suggest a good
>>> mechanism to have, effectively, a user keystore that would sync
>>> passwords with FreeIPA nicely.  I am thinking, in particular, of the
>>> scenario where users forget their password -- we'd strongly prefer
>>> to just reset it for them (24 hours, one login) in a way that didn't
>>> mean also re-issuing all passphrase-secured identity tokens.
>>>
>>
>> Not now however:
>> https://fedorahosted.org/freeipa/ticket/754
>> https://fedorahosted.org/freeipa/ticket/237
>> https://fedorahosted.org/freeipa/ticket/521
>>
>> There are also some thoughts and ideas about IPA as a secure vault
>> for other credentials in other systems which is not logged as a ticket.
>>
>>
>> Would you mind sharing with us your ideas about this functionality
>> actually should work?
>> Use cases, examples and design ideas are very welcome.
>
> Is there any standard to keystores?  It would be great if Linux, Mac,
> Windows could all be pointed at an FreeIPA to fetch credentials,
> usernames, passwords.  Authentication could use kerberos tickets if
> available, otherwise prompt for username/password, or have
> configurable authentication policies.
>
> Users and administrators could set ACL policies on the keystores (I
> know very little about LDAP, but I believe LDAP already provides this
> kind of thing), and they could be hierarchical, with access policy
> inheritance.  It could act as a password safe like
> http://kedpm.sourceforge.net/.
>
> Imagine storing SSH private keys in IPA.  The user then wants to fetch
> these into ssh-agent, or to provide them for some other in-memory
> process that requires access to the unencrypted private-key.
>
> Another scenario is X.509 PKI where the private key is usually
> passphrase encrypted.  If the user forgets their passphrase, the PKI
> token needs to be revoked and a new one issued.  Much better (IMO) to
> hold it in a trusted authentication system and to provide the
> unencrypted key to applications on demand.  User-passphrase can then
> be linked to FreeIPA system.
>
> Here is a quick idea of a command line to fetch credentials from an
> IPA keystore:
>
> ipa-keystore-fetch [-k keystore] [-u username] [-p password] [-P]
>      [-o output_dir_or_file] \
>      [/path/to/token/]token_name[#attribute] \
>     [[/path/to/token/]token_name[#attribute]] [ ... ]
>
> Usual kind of thing: the user would have a default keystore, and their
> kerberos tokens (if available) would be used to authenticate for
> access to the keystore (based on username, I guess).  Users could just
> dump tokens in the "root" space, or arrange the tokens
> hierarchically.  Tokens could have attributes associated with them,
> with a "primary" or "default" token if none is specified.  Tokens
> could be dumped to screen, routed to an application (pipe, IPC,
> socket, PID), or written to file.  You could pretty easily imagine
> commands:
>
> chmod # acl changes
> add
> edit
> rm
> backup
> ls
>
> Ian
>

First, security specialist would probably rebel about providing the
password or keys in clear. The best practice says do not reveal the
keys/passwords but rather encrypt them with some other "transport"
secret that would be known to the user or destination host and would
protect the password/key while in transit.
Second, yes I was thinking about hierarchical storage too but then every
user would have to turn into a container. That would have some
implications that need to be researched. It might be easier to keep the
key(s) in user entry and have ACLs attached to the key(s). And then have
a separate vault storage in a form of a database for a quick and simple
lookup. Needs investigation.
Third there is a standard and protocol
http://www.oasis-open.org/committees/kmip/ but last time I looked there
were no open source implementations that we can take advantage of.
Starting a whole new kmip related project is something that we can't
afford...

So:
It can be solved and can be solved generically and more or less securely
but it will take a lot of time before we would get there.
I am sure we would though but not as soon as you might want.

Our current plan is to focus on the storage and make sure we can address
the use cases we need to address like keys for disk encryption, SSH etc.
Serving them out is whole different story and I doubt it will be done
soon. Design work in this area would hopefully start in the fall.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20110802/40bdf413/attachment.htm>