openldap-devel

openldap-devel@openldap.org

1416 discussions

Re: Storing TLS credentials in the directory
by Howard Chu 10 Apr '17

10 Apr '17

Michael Ströder wrote: > Howard Chu wrote: >> Turbo Fredriksson wrote: >>> Everything I’ve seen about the subject is so darn _complex_! It shouldn’t HAVE >>> to be. >> >> Indeed, there's no reason for it. > > Hmm, every time in a customer encryption/PKI project the customer requested that it > should be secure *and* easy to use. This is kind of a contradiction to begin with. Bootstrapping is usually the hardest part. That's the part I've focused on making easier. > > Also this short discussion already oversimplifys all the possible use-cases and > considerations when talking about storing/using/protecting private keys. Personally I'd > never use such a autoca overlay running on the "normal" directory server. (Over)simplification is exactly what is needed, most of the time. > So every technical design should start with a decent description of the use-cases or will > blatantly fail. This will lead to reviewing which name spaces have to be put in which > naming extension for which usage and who is authorized to use the keys and issue certs. > Simply starting with schema for private key storage is putting the cart before the horse. You cannot write a decent design from scratch. It's important to have a baseline of functionality to get an idea of scope. The current overlay provides that baseline. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

Re: Storing TLS credentials in the directory
by Howard Chu 10 Apr '17

10 Apr '17

Turbo Fredriksson wrote: > On 9 Apr 2017, at 17:55, Howard Chu <hyc(a)symas.com> wrote: >>> 2) What if I want a new certificate for that RDN? >>> Such as the previous one is [about to] expire and it needs to be >>> refreshed (preferably (?) without destroying/removing the old one). >> >> Currently you would have to delete the old one first. > > Ok, thanx. Not that big a’ deal I guess. I've noted this in the manpage now. > >>> 3) Is the CAs _public_ key available as well? >>> Same reason as point 1. >> >> If the overlay generated it, then it is stored in cACertificate;binary in the suffix entry of the database. > > Awesome! Update the man page about this as well then :) Done. > >>> 4) If I already have a CA “on premises” and that have created an >>> intermediate CA I’d like to use for “autoca”, could this be done? >> >> You can replace cACertificate;binary and cAPrivateKey;binary of the suffix entry to force this. > > I see, that’s quite smart! So they’re writable, not just read-only then. > This should probably also be documented. > > Is that true for userCertificate and userPrivateKey as well? Yes. Also noted in the manpage. If you're running git master, you can look at test066-autoca and see how it works. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Storing TLS credentials in the directory
by Howard Chu 09 Apr '17

09 Apr '17

Turbo Fredriksson wrote: > On 9 Apr 2017, at 14:24, Howard Chu <hyc(a)symas.com> wrote: > >> Please read the slapo-autoca(5) manpage for more info. > > This is exactly how easy I’m envisioning this to be! Brilliant, thanx! > > So if I’m understanding this correctly, all you have to do to request > a certificate for a specific object, is to read the “userPrivateKey;binary” > of that RDN? You must request exactly two attributes, otherwise the overlay ignores it: userCertificate;binary userPrivateKey;binary > Now, I know it’s well to early for feature requests :D, but I have a few > questions (and a feature request :): > > 1) Why is both certificates (private AND public) in the same attribute? > I can see the reason to have the public … “public” (with a much > more relaxed ACL/ACI). They aren't, they are in two separate attributes. > 2) What if I want a new certificate for that RDN? > Such as the previous one is [about to] expire and it needs to be > refreshed (preferably (?) without destroying/removing the old one). Currently you would have to delete the old one first. > 3) Is the CAs _public_ key available as well? > Same reason as point 1. If the overlay generated it, then it is stored in cACertificate;binary in the suffix entry of the database. > > 4) If I already have a CA “on premises” and that have created an > intermediate CA I’d like to use for “autoca”, could this be done? You can replace cACertificate;binary and cAPrivateKey;binary of the suffix entry to force this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Storing TLS credentials in the directory
by Howard Chu 09 Apr '17

09 Apr '17

One of the things that has been a long-standing obstacle to the automatic CA code is the fact that there's no LDAP syntax/matchingrule/attributes for storing private keys in the directory. There's schema for storing userCertificate and cAcertificate, but not the corresponding keys. This is also a stumbling block for being able to configure TLS directly in cn=config, instead of using separate files. Currently the autoca overlay defines a syntax and matching rule for use with private keys but this needs to move into the core code so that back-config can also use it. At this point I need to pick an OID arc for it, which prompted me to troll thru all the existing OID assignments. It's clear that nobody in the standards organizations considers storing private keys in the directory to be a safe thing to do. IMO this is just a matter of password security and good ACLs, and the standards should not preclude the option. It is no worse than storing userPassword. Comments? openldap-commit2devel(a)OpenLDAP.org wrote: > A ref change was pushed to the OpenLDAP (openldap.git) repository. > It will be available in the public mirror shortly. > > The branch, master has been updated > via 79284a06d3bea085ed92f17f2a2b5a15746f83a0 (commit) > via 2012795d3b1a29913e9f3a5b3a35d40fd8f5f903 (commit) > via b402a2805f8b96d2751a7315ea5e70e5082965ed (commit) > from 2b920ecaecc2e4858a33d0c8151bcf3b3d71cadd (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log ----------------------------------------------------------------- > commit 79284a06d3bea085ed92f17f2a2b5a15746f83a0 > Author: Howard Chu <hyc(a)openldap.org> > Date: Sun Apr 9 03:55:01 2017 +0100 > > Catalog of assigned OID arcs > > With some specific elements as well, but not exhaustively listed. > Patches welcome. > > commit 2012795d3b1a29913e9f3a5b3a35d40fd8f5f903 > Author: Howard Chu <hyc(a)openldap.org> > Date: Sun Apr 9 02:21:06 2017 +0100 > > Add config support for binary values > > Use base64 for .conf files, straight binary for back-config > > commit b402a2805f8b96d2751a7315ea5e70e5082965ed > Author: Howard Chu <hyc(a)openldap.org> > Date: Sun Apr 9 00:13:42 2017 +0100 > > Add options to use DER format cert+keys directly > > Instead of loading from files. > > ----------------------------------------------------------------------- > > Summary of changes: > doc/devel/OIDs | 69 ++++++++++++++++++++++++++++++++++++++++++ > include/ldap.h | 3 ++ > libraries/libldap/ldap-int.h | 6 ++++ > libraries/libldap/tls2.c | 34 ++++++++++++++++++++- > libraries/libldap/tls_o.c | 56 +++++++++++++++++++++++++++++++--- > servers/slapd/bconfig.c | 13 +++++++- > servers/slapd/config.c | 34 +++++++++++++++++++-- > servers/slapd/config.h | 2 ++ > 8 files changed, 208 insertions(+), 9 deletions(-) > create mode 100644 doc/devel/OIDs > > > --- > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Storing TLS credentials in the directory
by Howard Chu 09 Apr '17

09 Apr '17

Turbo Fredriksson wrote: > On 9 Apr 2017, at 11:29, Howard Chu <hyc(a)symas.com> wrote: > >> Turbo Fredriksson wrote: >>> On 9 Apr 2017, at 04:06, Howard Chu <hyc(a)symas.com> wrote: >>> >>> Only difference might be that the local FS isn’t available _outside_ the host, a directory >>> is. >> >> As soon as a host offers something like ssh, then that distinction is gone too. > > True. > >> Moreover, a secure mechanism for distributing private keys to users is required but nobody >> ever specifies how to do that. Certainly LDAP/TLS is more manageable than sneakernet and >> this is more bootstrappable. > > Yeah, I’ve been struggling like crazy about this the last couple of months. > > There’s many scripts and some products that can be/handle a CA, but > no one seems to have thought about the actual distribution of the result(s). > > Or how to restrict queries, distribution and what type of cert is/can be requested. > > And every link I’ve ever seen about certs, “then copy it securely to the > destination”. But no wording on HOW to do that or how to script it (in a > more .. “automated” fashion). > > Everything I’ve seen about the subject is so darn _complex_! It shouldn’t HAVE > to be. Indeed, there's no reason for it. > So if you can do something like this, and leave the ACL/policies etc to the admin, > using existing functionality (ACL/ACI/ppolicy or whatever), I’d be a very happy man! :) This is coming along now... > > Are you actually talking about OpenLDAP being a “CA” as well? As in, being able > to create certificates by requests, or are you talking about OpenLDAP “only” > being the … “backend-storage” for such a tool? The autoca overlay turns slapd into a CA. It can generate certificates for any users (and servers) in the directory. Please read the slapo-autoca(5) manpage for more info. For bootstrapping purposes I'm now extending back-config to be able to use certificates/keys stored directly in cn=config. The autoca overlay will be extended to store its generated CA cert in cn=config, so that a slapd can immediately support TLS as soon as the overlay is used (without requiring restarts). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 4

Re: Storing TLS credentials in the directory
by Howard Chu 09 Apr '17

09 Apr '17

Turbo Fredriksson wrote: > On 9 Apr 2017, at 04:06, Howard Chu <hyc(a)symas.com> wrote: > >> It's clear that nobody in the standards organizations considers storing private keys in the directory to be a safe thing to do. IMO this is just a matter of password security and good ACLs, and the standards should not preclude the option. It is no worse than storing userPassword. > > I agree (fwiw). > > > It needs to be stored SOMEWHERE. Usually it’s in/on the filesystem. And the only two (?) > things that protect it there is: > > 1) The access permissions on the file. I.e., “ACLs". > 2) No/limited users allowed on the system. I.e., "password security" (?) > > So using “ACLs" and "password security" on the filesystem or in the directory, shouldn’t be > that different. > > Only difference might be that the local FS isn’t available _outside_ the host, a directory > is. As soon as a host offers something like ssh, then that distinction is gone too. Moreover, a secure mechanism for distributing private keys to users is required but nobody ever specifies how to do that. Certainly LDAP/TLS is more manageable than sneakernet and this is more bootstrappable. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Storing TLS credentials in the directory
by Turbo Fredriksson 09 Apr '17

09 Apr '17

On 9 Apr 2017, at 04:06, Howard Chu <hyc(a)symas.com> wrote: > It's clear that nobody in the standards organizations considers storing private keys in the directory to be a safe thing to do. IMO this is just a matter of password security and good ACLs, and the standards should not preclude the option. It is no worse than storing userPassword. I agree (fwiw). It needs to be stored SOMEWHERE. Usually it’s in/on the filesystem. And the only two (?) things that protect it there is: 1) The access permissions on the file. I.e., “ACLs". 2) No/limited users allowed on the system. I.e., "password security" (?) So using “ACLs" and "password security" on the filesystem or in the directory, shouldn’t be that different. Only difference might be that the local FS isn’t available _outside_ the host, a directory is.

1 0

Re: openldap.git branch master updated. e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d
by Howard Chu 15 Mar '17

15 Mar '17

Hallvard Breien Furuseth wrote: > On 15. mars 2017 12:15, openldap-commit2devel(a)OpenLDAP.org wrote: >> commit e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d >> Author: Howard Chu <hyc(a)openldap.org> >> Date: Wed Mar 15 11:13:09 2017 +0000 >> >> Fixes for multiple threadpool queues >> >> Remove poolq_hash, it wasn't distributing work evenly to the queues. > > Not surprising when it was hashing the address instead of contents > of a local variable. Whatever that intended to achieve, it looks > to me like rand_r() would have done the same but better. It was hashing the bytes of arg. In the common case of the slapd_daemon_task submitting jobs to the pool, arg was the socket descriptor of an active connection, so this was always distributing those evenly. But in other cases where arg was a context pointer, the result was heavily skewed. > (Also the > hash was pointlessly slow in that it walked a byte at a time, it > could have hashed better with fewer operations.) for a 4 or 8 byte arg this was hardly important. > I guess I should have looked closer at that code earlier:-) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: openldap.git branch master updated. e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d
by Hallvard Breien Furuseth 15 Mar '17

15 Mar '17

On 15. mars 2017 12:15, openldap-commit2devel(a)OpenLDAP.org wrote: > commit e12ca8b6fed6b8a2526c5c8ee820bf5aa942b59d > Author: Howard Chu <hyc(a)openldap.org> > Date: Wed Mar 15 11:13:09 2017 +0000 > > Fixes for multiple threadpool queues > > Remove poolq_hash, it wasn't distributing work evenly to the queues. Not surprising when it was hashing the address instead of contents of a local variable. Whatever that intended to achieve, it looks to me like rand_r() would have done the same but better. (Also the hash was pointlessly slow in that it walked a byte at a time, it could have hashed better with fewer operations.) I guess I should have looked closer at that code earlier:-) -- Hallvard

1 0

Re: ldif API
by Quanah Gibson-Mount 13 Mar '17

13 Mar '17

--On Monday, March 13, 2017 7:46 PM +0000 Brett Sheffield <brett(a)gladserv.com> wrote: Hi Brett, > Which leads me to ask three questions: > > 1) Am I correct in thinking this will make it into the 2.5 release? Yes, it's already in the RE25 development branch. > 2) Is there a rough release date planned for 2.5? Not at this time. We had been planning on doing an initial alpha for 2.5 to get the ball rolling on sunsetting 2.4. I'd still like to get to that point, but we need to get the current 2.4 release stable first (Things like ITS#8444, ITS#8609, ITS#8589, ITS#8559, ITS#8545, ITS#8436, ITS#8528, ITS#8125, etc). There are also a couple of items that need fixing in master/RE25 before we do a 2.5 alpha as well. > 3) I've submitted my first patch to openldap[2], adding a new function > ldif_open_mem() which is useful when working with ldif data in memory. I > read through the contribution guidelines and I think I've made all the > necessary copyright statements etc., but please let me know if I've > missed anything. It would be great if this made it into 2.5 as well (tis Great, thanks! I can't say when it will be responded to as it'll need a code review, most likely from Howard, and I know he's currently heavily involved in a customer project for Symas. The simple fact is, the project needs more active participants, particularly knowledgable C programmers, so that things do not continually back up waiting on Howard for a response to even get somewhere on them. :/ --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel