<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> On 08/02/2011 05:51 PM, Ian Stokes-Rees wrote: <blockquote cite="mid:4E387170.5010804@hkl.hms.harvard.edu" type="cite"> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> On 8/2/11 4:27 PM, Dmitri Pal wrote: <blockquote class=" cite" id="mid_4E385D9B_8010207_redhat_com" cite="mid:4E385D9B.8010207@redhat.com" type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> On 08/02/2011 02:15 PM, Ian Stokes-Rees wrote: <blockquote class=" cite" id="mid_4E383ED7_1030506_hkl_hms_harvard_edu" cite="mid:4E383ED7.1030506@hkl.hms.harvard.edu" type="cite"> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> 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. </blockquote> Not now however: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/754">https://fedorahosted.org/freeipa/ticket/754</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/237">https://fedorahosted.org/freeipa/ticket/237</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/521">https://fedorahosted.org/freeipa/ticket/521</a> 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.</blockquote> 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 <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://kedpm.sourceforge.net/">http://kedpm.sourceforge.net/</a>. 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 </blockquote> 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 <a class="moz-txt-link-freetext" href="http://www.oasis-open.org/committees/kmip/">http://www.oasis-open.org/committees/kmip/</a> 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. <pre class="moz-signature" cols="72">-- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? <a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a> </pre> </body> </html>