Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
DRM is the way to go. However it does not support symmetric keys now. This is the pert that we need for volume keys. May be it is the vault to store all sorts of keys. This is something that needs to be designed and looked at as a broader perspective. Adam likes to repeat a phase about dreaming big so I do. I want IPA to be a vault for all sorts of keys and passwords and what else. If DRM is the answer - great. I can start listing the use cases that such a key store should satisfy and we can design something that would altimately fit the build but build gradually knocking use cases one by one. I will take an action idem to come with the use cases. Give me couple weeks as I am under water now... Specifically: the phrase is Dream big, implement small. There are four things here, I'd guess, that should play into the design. 1. User certificates in IPA. Discussed already, and probably the first thing to implement on the IPA side. 2. DRM/KRA talking to an external CA. Not sure if this makes sense, has been discussed etc. 3. DRM/KRA Integration into IPA. Regardless of 2, we should talk through the use cases for integration 4. DRM/KRA Support for symmetric keys etc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On 08/04/2011 02:05 PM, Ian Stokes-Rees wrote: On 8/3/11 6:13 PM, Dmitri Pal wrote: On 08/03/2011 10:10 AM, Ian Stokes-Rees wrote: If there were some way to securely embed an arbitrary string in the user profile, that would go a long way to solving this problem. At least 4KB to cover a 2048 X.509 public key, but ideally 10 KB or more. To remove the ACL complexity, just having it accessible only by the user (token or password based fetch) would be suitable. Do not quite understand how that would work or what you mean. I've just realized that I think the functionality I'm looking for is already available. I want the same system that is used for storing passwords. Consider the following trace: $ ldapsearch -h freeipa -b uid=tester,cn=users,cn=portal,dc=nebiogrid,dc=org -Y GSSAPI -LLL -d 0 -T ~/.ldapresults/ SASL/GSSAPI authentication started SASL username: ijsto...@nebiogrid.org SASL SSF: 56 SASL data security layer installed. dn: uid=tester,cn=users,cn=portal,dc=nebiogrid,dc=org objectClass: person objectClass: posixAccount objectClass: account objectClass: inetOrgPerson objectClass: top objectClass: organizationalPerson givenName: test sn: test cn: test test mail: meg...@hkl.hms.harvard.edu uidNumber: 1031 gidNumber: 1031 homeDirectory: /p/home//tester uid: tester userPassword:: e2NyeXB0fXNCb2drN3p4c2lha1E= [aside: I'd love a tip on how to get rid of the non-LDIF SASL headers] The userpassword (hash) is stored in base-64 format and is only accessible by me because I have permissions to access this. Some other user doing the same query would not get the userPassword attribute. Even better, I can use the -tt option to write the base64-decoded content to a file. The parts of the puzzle that I'd have to work out are: 1. are there objectClass schemas that have fields that would be suitable for a set of common private keys (rsa1, rsa2, dsa, gpg, pgp, and x509)? x509 schema are included with 389 (05rfc4523.ldif et. al.) I think there is a schema for storage of ssh keys 2. if not, instructions on how to set up such a schema (basically with exactly the set of attributes above), with the fields being base64 (binary?) Take a look at the existing schema. For most fields that hold opaque blob data, you will probably want to use OctetString syntax. 3. what do I have to do to get the behavior that only certain parties can read a particular attribute? Read up on Access Control (acis): http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Managing_Access_Control 4. any way to get ldapsearch to write out particular attributes to particular files? Not really - all you have is -T and -tt But any non-trivial application is not going to use ldapsearch as the main interface for getting these values. I suggest using python with python-ldap. Thanks, Ian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On 08/04/2011 04:12 PM, Rich Megginson wrote: On 08/04/2011 02:05 PM, Ian Stokes-Rees wrote: On 8/3/11 6:13 PM, Dmitri Pal wrote: On 08/03/2011 10:10 AM, Ian Stokes-Rees wrote: If there were some way to securely embed an arbitrary string in the user profile, that would go a long way to solving this problem. At least 4KB to cover a 2048 X.509 public key, but ideally 10 KB or more. To remove the ACL complexity, just having it accessible only by the user (token or password based fetch) would be suitable. Do not quite understand how that would work or what you mean. I've just realized that I think the functionality I'm looking for is already available. I want the same system that is used for storing passwords. Consider the following trace: $ ldapsearch -h freeipa -b uid=tester,cn=users,cn=portal,dc=nebiogrid,dc=org -Y GSSAPI -LLL -d 0 -T ~/.ldapresults/ SASL/GSSAPI authentication started SASL username: ijsto...@nebiogrid.org SASL SSF: 56 SASL data security layer installed. dn: uid=tester,cn=users,cn=portal,dc=nebiogrid,dc=org objectClass: person objectClass: posixAccount objectClass: account objectClass: inetOrgPerson objectClass: top objectClass: organizationalPerson givenName: test sn: test cn: test test mail: meg...@hkl.hms.harvard.edu uidNumber: 1031 gidNumber: 1031 homeDirectory: /p/home//tester uid: tester userPassword:: e2NyeXB0fXNCb2drN3p4c2lha1E= [aside: I'd love a tip on how to get rid of the non-LDIF SASL headers] The userpassword (hash) is stored in base-64 format and is only accessible by me because I have permissions to access this. Some other user doing the same query would not get the userPassword attribute. Even better, I can use the -tt option to write the base64-decoded content to a file. The parts of the puzzle that I'd have to work out are: 1. are there objectClass schemas that have fields that would be suitable for a set of common private keys (rsa1, rsa2, dsa, gpg, pgp, and x509)? x509 schema are included with 389 (05rfc4523.ldif et. al.) I think there is a schema for storage of ssh keys Take a look at this: https://fedorahosted.org/freeipa/ticket/754 http://code.google.com/p/openssh-lpk/ Patches are welcome ;-) 2. if not, instructions on how to set up such a schema (basically with exactly the set of attributes above), with the fields being base64 (binary?) Take a look at the existing schema. For most fields that hold opaque blob data, you will probably want to use OctetString syntax. 3. what do I have to do to get the behavior that only certain parties can read a particular attribute? Read up on Access Control (acis): http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Managing_Access_Control 4. any way to get ldapsearch to write out particular attributes to particular files? Not really - all you have is -T and -tt But any non-trivial application is not going to use ldapsearch as the main interface for getting these values. I suggest using python with python-ldap. Thanks, Ian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
Maybe stupid question, but I have to ask: Why would anyone want to store user RSA keys in LDAP? Once you have IPA server with KDC installed, you can use Kerberos for authentication as well. And you get single sign on as a special bonus :-) Ondrej The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communicati...@s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
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. OK, the transport from client to FreeIPA would, of course, be secure, but the key/token that is returned from the client is available in cleartext (perhaps just in memory, such as ssh-agent). And specifying a passphrase on the command line would be discouraged but possible -- prompting for it, if Kerberos tokens were not sufficient, would be preferable. 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. If there were some way to securely embed an arbitrary string in the user profile, that would go a long way to solving this problem. At least 4KB to cover a 2048 X.509 public key, but ideally 10 KB or more. To remove the ACL complexity, just having it accessible only by the user (token or password based fetch) would be suitable. Ian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On 8/3/11 4:47 AM, Ondrej Valousek wrote: Maybe stupid question, but I have to ask: Why would anyone want to store user RSA keys in LDAP? Once you have IPA server with KDC installed, you can use Kerberos for authentication as well. And you get single sign on as a special bonus :-) If you only work in a single administrative domain, this is fine. I am constantly accessing systems all over the US, and internationally, and the use of ssh-key-based authentication allows me to do this without continuous password prompts. In fact, on many of the systems I can *only* access them by ssh-key. Being able to hold those keys in central keystore like FreeIPA with a single passphrase, and the ability for an administrator to reset that passphrase, is very desirable for me and for the other users of the systems I'm a part of. Resetting key-based access control if the private key passphrase is lost is always a nuisance. Ian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On Wed, 2011-08-03 at 10:14 -0400, Ian Stokes-Rees wrote: On 8/3/11 4:47 AM, Ondrej Valousek wrote: Maybe stupid question, but I have to ask: Why would anyone want to store user RSA keys in LDAP? Once you have IPA server with KDC installed, you can use Kerberos for authentication as well. And you get single sign on as a special bonus :-) If you only work in a single administrative domain, this is fine. I am constantly accessing systems all over the US, and internationally, and the use of ssh-key-based authentication allows me to do this without continuous password prompts. In fact, on many of the systems I can *only* access them by ssh-key. Being able to hold those keys in central keystore like FreeIPA with a single passphrase, and the ability for an administrator to reset that passphrase, is very desirable for me and for the other users of the systems I'm a part of. Resetting key-based access control if the private key passphrase is lost is always a nuisance. As a general rule, I would think that having your private key stored somewhere that an admin other than yourself can reset the password and have access to would be really dangerous. Most especially if this private key was being used to access sites in other administrative domains. That really sounds like an accident waiting to happen... signature.asc Description: This is a digitally signed message part ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On Wed Aug 3 10:37:45 2011, Stephen Gallagher wrote: As a general rule, I would think that having your private key stored somewhere that an admin other than yourself can reset the password and have access to would be really dangerous. Most especially if this private key was being used to access sites in other administrative domains. That really sounds like an accident waiting to happen... If you are concerned about that, then don't make use of a centralized keystore. You may be a security expert and have a deeper understanding of this than I do, but from my limited experience and knowledge of security audits and risk assessment, if you don't trust your system administrators then you have a whole heap of other issues you need to contend with. Consider that the FreeIPA server is probably *more* secure than the user-accessible systems and file servers. If someone with administrative (root) privs for the part of the system where I store my passphrase encrypted private key would be the kind of person who would take the private key from a central keystore, if it existed, then do you not think they could get my passphrase and/or cleartext private key from the system *without* a central keystore? This is not to say there aren't arguments against it: a policy mix up or a bug in the central keystore could lead to *all* users having their private keys compromised, and an admin who can dip in and grab private keys without any evidence would also be bad, but hopefully the Audit part of IPA means that any access to private keys will be securely logged, and flagged if they are by users other than the owner of the private key. This is a topic that is very important to me, so I'm quite interested to hear how my reasoning may be flawed, or to hear opinions from others. Regards, Ian attachment: ijstokes.vcf___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On 08/03/2011 12:21 PM, Ian Stokes-Rees wrote: On Wed Aug 3 10:37:45 2011, Stephen Gallagher wrote: As a general rule, I would think that having your private key stored somewhere that an admin other than yourself can reset the password and have access to would be really dangerous. Most especially if this private key was being used to access sites in other administrative domains. That really sounds like an accident waiting to happen... If you are concerned about that, then don't make use of a centralized keystore. You may be a security expert and have a deeper understanding of this than I do, but from my limited experience and knowledge of security audits and risk assessment, if you don't trust your system administrators then you have a whole heap of other issues you need to contend with. Consider that the FreeIPA server is probably *more* secure than the user-accessible systems and file servers. If someone with administrative (root) privs for the part of the system where I store my passphrase encrypted private key would be the kind of person who would take the private key from a central keystore, if it existed, then do you not think they could get my passphrase and/or cleartext private key from the system *without* a central keystore? I think that it is a case of Just becasue I am paranoid doesn't mean they are not out to get me. Its not that we don't trust sys admins, it is that we don't trust anyone. Typically, instead of trusting anyone, sysadmin or no, with long term access to keys, you might provide a window in which they know the shared secret in order to reset the key, but not to make that a permanent relationship. I think what you are interested in is the Data Recovery Manager (DRM...hey, we had the acronym first, but we also call it Key Recovery ) aspect of Certificate Server. Here's the redhat docs on it http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/7.1/html/Administrators_Guide/kra.html#22604 And from the RPM That is not integrated into FreeIPA, but the packages are in Fedora as pki-kra The Data Recovery Manager (DRM) is an optional PKI subsystem that can act as a Key Recovery Authority (KRA). When configured in conjunction with the Certificate Authority (CA), the DRM stores private encryption keys as part of the certificate enrollment process. The key archival mechanism is triggered when a user enrolls in the PKI and creates the certificate request. Using the Certificate Request Message Format (CRMF) request format, a request is generated for the user's private encryption key. This key is then stored in the DRM which is configured to store keys in an encrypted format that can only be decrypted by several agents requesting the key at one time, providing for protection of the public encryption keys for the users in the PKI deployment. This is not to say there aren't arguments against it: a policy mix up or a bug in the central keystore could lead to *all* users having their private keys compromised, and an admin who can dip in and grab private keys without any evidence would also be bad, but hopefully the Audit part of IPA means that any access to private keys will be securely logged, and flagged if they are by users other than the owner of the private key. This is a topic that is very important to me, so I'm quite interested to hear how my reasoning may be flawed, or to hear opinions from others. Regards, Ian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On Wed, 2011-08-03 at 12:21 -0400, Ian Stokes-Rees wrote: On Wed Aug 3 10:37:45 2011, Stephen Gallagher wrote: As a general rule, I would think that having your private key stored somewhere that an admin other than yourself can reset the password and have access to would be really dangerous. Most especially if this private key was being used to access sites in other administrative domains. That really sounds like an accident waiting to happen... If you are concerned about that, then don't make use of a centralized keystore. You may be a security expert and have a deeper understanding of this than I do, but from my limited experience and knowledge of security audits and risk assessment, if you don't trust your system administrators then you have a whole heap of other issues you need to contend with. Consider that the FreeIPA server is probably *more* secure than the user-accessible systems and file servers. If someone with administrative (root) privs for the part of the system where I store my passphrase encrypted private key would be the kind of person who would take the private key from a central keystore, if it existed, then do you not think they could get my passphrase and/or cleartext private key from the system *without* a central keystore? This is not to say there aren't arguments against it: a policy mix up or a bug in the central keystore could lead to *all* users having their private keys compromised, and an admin who can dip in and grab private keys without any evidence would also be bad, but hopefully the Audit part of IPA means that any access to private keys will be securely logged, and flagged if they are by users other than the owner of the private key. This is a topic that is very important to me, so I'm quite interested to hear how my reasoning may be flawed, or to hear opinions from others. As Adam pointed out, the default assumption is that no one is trusted. But my main concern is not that the admins have access to your private keys, but that they have access to your private keys *for an unrelated domain*. Even if both domains exist in your organization (e.g. CORP and ENG), you are implicitly granting the admin of the CORP domain permission to impersonate you on the ENG domain. You're also significantly increasing the damage surface of a successful attack against this domain. It's analogous to using the same password at many major sites: compromise one and you have the keys to all of the others. So I guess what I'm saying is not Don't use centrally managed key storage, but rather If you use the key anywhere but in this administrative domain, do not put it in centrally-managed storage that anyone but you can ever gain access to it. signature.asc Description: This is a digitally signed message part ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On 8/3/11 12:38 PM, Adam Young wrote: I think what you are interested in is the Data Recovery Manager (DRM...hey, we had the acronym first, but we also call it Key Recovery ) aspect of Certificate Server. That is awesome. That is exactly what I want. Do you have experience with this? If so, does it work if the certificate requests are being handled by an external entity? We use a Department of Energy CA located in California, but the users in our community are from across the US (and international), and we're looking to improve the process of them acquiring a usable identity in a federated environment. We're using FreeIPA internally, but if we can link it in to the cert request process and cert mgmt process (from the user end, not the CA end) that would be great. Ian attachment: ijstokes.vcf___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On 8/3/11 1:02 PM, Stephen Gallagher wrote: So I guess what I'm saying is not Don't use centrally managed key storage, but rather If you use the key anywhere but in this administrative domain, do not put it in centrally-managed storage that anyone but you can ever gain access to it. Yes, I appreciate the distinction you raise. Regarding your last comment quoted above, to the best of my knowledge that is impossible. I regularly have discussions with people saying an administrator could always do X,Y and Z to access your supposedly private data -- if there are ways in which I could be wrong about that, I'd love to know them. Otherwise I believe that the key risks from a centralized keystore are: * ease of compromise by an unscrupulous administrator * extent of compromise if attacker gains administrative privs to central keystore (although it sounds like the RH DRM system could significantly reduce that) * risk of compromise due to security vulnerabilities in central keystore software I think the general consensus is that you are always exposed to some degree of risk, and it is necessary to evaluate the risks versus the benefits. There are some lovely lakes in northern Maine where you can probably use your laptop without too much risk of compromised privacy, or closer to home, I'm sure most of us can remember a day when we got lots of useful work done on a computer with no network connection and were excited when we got one new piece of software every few months. In my risk/benefit world, a centralized keystore would be really useful. And for the record, if any one of the computers I use is compromised with a keyboard scanner or theft of my private ssh or X.509 keys, then I'm in a whole world of pain, and not a small amount of inconvenience (and risk of malicious attacks) to the various systems I regularly access. Best I can tell, that isn't too different from most people in my situation, and short of that nice cabin in Maine, is simply the reality (risk) of the kind of work I do, and the people I do it for. Ian attachment: ijstokes.vcf___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On Wed, 2011-08-03 at 13:46 -0400, Stephen Gallagher wrote: On Wed, 2011-08-03 at 13:41 -0400, Ian Stokes-Rees wrote: On 8/3/11 1:02 PM, Stephen Gallagher wrote: So I guess what I'm saying is not Don't use centrally managed key storage, but rather If you use the key anywhere but in this administrative domain, do not put it in centrally-managed storage that anyone but you can ever gain access to it. Yes, I appreciate the distinction you raise. Regarding your last comment quoted above, to the best of my knowledge that is impossible. I regularly have discussions with people saying an administrator could always do X,Y and Z to access your supposedly private data -- if there are ways in which I could be wrong about that, I'd love to know them. Otherwise I believe that the key risks from a centralized keystore are: * ease of compromise by an unscrupulous administrator * extent of compromise if attacker gains administrative privs to central keystore (although it sounds like the RH DRM system could significantly reduce that) * risk of compromise due to security vulnerabilities in central keystore software I think the general consensus is that you are always exposed to some degree of risk, and it is necessary to evaluate the risks versus the benefits. There are some lovely lakes in northern Maine where you can probably use your laptop without too much risk of compromised privacy, or closer to home, I'm sure most of us can remember a day when we got lots of useful work done on a computer with no network connection and were excited when we got one new piece of software every few months. In my risk/benefit world, a centralized keystore would be really useful. And for the record, if any one of the computers I use is compromised with a keyboard scanner or theft of my private ssh or X.509 keys, then I'm in a whole world of pain, and not a small amount of inconvenience (and risk of malicious attacks) to the various systems I regularly access. Best I can tell, that isn't too different from most people in my situation, and short of that nice cabin in Maine, is simply the reality (risk) of the kind of work I do, and the people I do it for. Well, there exist central storage approaches that don't allow even the local admin access to the data. The trade-off of course is that they can't reinstate your access if you forget the password. In other words, you can set a password that is used as a symmetric key for encrypting your data in the central store. It's still central and can be retrieved from anywhere, but only you know how to read it. In these situations to allow recovery you can have all data encrypted a second time with a central store public key. But the corresponding private key is not stored in a place accessible online and gaining access to the means to recover keys is subject to logging on a specialized system which audits everything you do and notifies all interested parties automatically when you access anyone's keys. That can be done but it is expensive, something we can plan for a the future, but not something we can do in the short term. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On Wed, 2011-08-03 at 14:02 -0400, Ian Stokes-Rees wrote: On 8/3/11 1:46 PM, Stephen Gallagher wrote: Well, there exist central storage approaches that don't allow even the local admin access to the data. The trade-off of course is that they can't reinstate your access if you forget the password. In other words, you can set a password that is used as a symmetric key for encrypting your data in the central store. It's still central and can be retrieved from anywhere, but only you know how to read it. You still seem to be missing the relevance of unscrupulous administrators and compromised systems to man in the middle any interactions you have with this system. Unless you never access the data yourself once the unscrupulous admin or attacker has gained access, then such a person can pretty easily intercept your password and get at your data. Ian No, the way that such a system would work is that the password would never be passed to the central server. Only the encrypted data would be sent and received. All decryption would happen locally. The most a man-in-the-middle attack could accomplish would be damaging the file so it couldn't be decrypted anymore. That could accomplish a denial-of-service, but not grant the attacker privileges to use your keys. signature.asc Description: This is a digitally signed message part ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On Wed Aug 3 14:05:51 2011, Stephen Gallagher wrote: No, the way that such a system would work is that the password would never be passed to the central server. Only the encrypted data would be sent and received. All decryption would happen locally. The most a man-in-the-middle attack could accomplish would be damaging the file so it couldn't be decrypted anymore. That could accomplish a denial-of-service, but not grant the attacker privileges to use your keys. Yes, of course. I work so much on machines hosted in racks in some server room that I forget a lot of people do most of their work on a single physical machine that could have strong privilege separation so even administrators can't normally access the machine. I guess I'm imagining an environment where if there is *any* interest in a central keystore, then there are administrators who have full access to all systems that would access that central keystore, but your scenario is certainly possible. As you've pointed out, with that degree of autonomy over your own system surely it follows that you could choose not to use a central keystore if one were provided. Ian attachment: ijstokes.vcf___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On 08/03/2011 01:16 PM, Ian Stokes-Rees wrote: On 8/3/11 12:38 PM, Adam Young wrote: I think what you are interested in is the Data Recovery Manager (DRM...hey, we had the acronym first, but we also call it Key Recovery ) aspect of Certificate Server. That is awesome. That is exactly what I want. Do you have experience with this? If so, does it work if the certificate requests are being handled by an external entity? We use a Department of Energy CA located in California, but the users in our community are from across the US (and international), and we're looking to improve the process of them acquiring a usable identity in a federated environment. We're using FreeIPA internally, but if we can link it in to the cert request process and cert mgmt process (from the user end, not the CA end) that would be great. Ian Experience? I've been on the Dogtag project for over a week now. I'm learning about it as we speak. The place to ask about Dogtag and the pki products is pki-us...@redhat.com http://www.redhat.com/mailman/listinfo/pki-users and the IRC Channel on freednode is *#dogtag-pki. *Integrating KRA into IPA is on the map, although I am not sure the timeframe. However, I suspect that our approach would be assuming you wanted your own CA. Not sure if you can do KRA with**an external CA.* * ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On 08/03/2011 10:10 AM, Ian Stokes-Rees wrote: If there were some way to securely embed an arbitrary string in the user profile, that would go a long way to solving this problem. At least 4KB to cover a 2048 X.509 public key, but ideally 10 KB or more. To remove the ACL complexity, just having it accessible only by the user (token or password based fetch) would be suitable. Do not quite understand how that would work or what you mean. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On 08/03/2011 01:56 PM, Simo Sorce wrote: On Wed, 2011-08-03 at 13:46 -0400, Stephen Gallagher wrote: On Wed, 2011-08-03 at 13:41 -0400, Ian Stokes-Rees wrote: On 8/3/11 1:02 PM, Stephen Gallagher wrote: So I guess what I'm saying is not Don't use centrally managed key storage, but rather If you use the key anywhere but in this administrative domain, do not put it in centrally-managed storage that anyone but you can ever gain access to it. Yes, I appreciate the distinction you raise. Regarding your last comment quoted above, to the best of my knowledge that is impossible. I regularly have discussions with people saying an administrator could always do X,Y and Z to access your supposedly private data -- if there are ways in which I could be wrong about that, I'd love to know them. Otherwise I believe that the key risks from a centralized keystore are: * ease of compromise by an unscrupulous administrator * extent of compromise if attacker gains administrative privs to central keystore (although it sounds like the RH DRM system could significantly reduce that) * risk of compromise due to security vulnerabilities in central keystore software I think the general consensus is that you are always exposed to some degree of risk, and it is necessary to evaluate the risks versus the benefits. There are some lovely lakes in northern Maine where you can probably use your laptop without too much risk of compromised privacy, or closer to home, I'm sure most of us can remember a day when we got lots of useful work done on a computer with no network connection and were excited when we got one new piece of software every few months. In my risk/benefit world, a centralized keystore would be really useful. And for the record, if any one of the computers I use is compromised with a keyboard scanner or theft of my private ssh or X.509 keys, then I'm in a whole world of pain, and not a small amount of inconvenience (and risk of malicious attacks) to the various systems I regularly access. Best I can tell, that isn't too different from most people in my situation, and short of that nice cabin in Maine, is simply the reality (risk) of the kind of work I do, and the people I do it for. Well, there exist central storage approaches that don't allow even the local admin access to the data. The trade-off of course is that they can't reinstate your access if you forget the password. In other words, you can set a password that is used as a symmetric key for encrypting your data in the central store. It's still central and can be retrieved from anywhere, but only you know how to read it. In these situations to allow recovery you can have all data encrypted a second time with a central store public key. But the corresponding private key is not stored in a place accessible online and gaining access to the means to recover keys is subject to logging on a specialized system which audits everything you do and notifies all interested parties automatically when you access anyone's keys. That can be done but it is expensive, something we can plan for a the future, but not something we can do in the short term. Simo. Simo and Stephen, I do not think we would be able to design this right here an right now. It is a complex problem. I think we should design the solution when time comes (this fall) to be secure but allow people to loosen the security if the environment they work in allows it. For example we never know anything about the physical security of the deployment thus we always assume worst. But it does not mean that the environment does not have other means to secure access and that IPA has to be the lonely soldier. IMO it is up to the deployment to avoid our tight security recommendations and implement less secure approaches. It is all a trade off that should be evaluated in a specific environment by people in charge. We should educate about best practices but not enforce as there are reasons not to follow them. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
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. Thanks, Ian attachment: ijstokes.vcf___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
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. Thanks, Ian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
On Tue, 2011-08-02 at 16:27 -0400, 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 Replaced the last one with: https://fedorahosted.org/freeipa/ticket/1560 Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
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 attachment: ijstokes.vcf___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys
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/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
