openldap-devel April 2017

openldap-devel@openldap.org

8 participants
25 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel April 2017