From owner-freebsd-ports@freebsd.org Thu Jan 5 11:22:31 2017 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C1F9C9F853 for ; Thu, 5 Jan 2017 11:22:31 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 582601CD5 for ; Thu, 5 Jan 2017 11:22:31 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.local (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 529685DF3 for ; Thu, 5 Jan 2017 12:22:22 +0100 (CET) Subject: Re: openldap-client vs openldap-sasl-client To: freebsd-ports@freebsd.org References: <34b66662-a2d7-706d-3653-e0ffc9bf81b2@rlwinm.de> <20170105104326.GB2648@home.opsec.eu> From: Jan Bramkamp Message-ID: <5967fbad-7713-bdd8-4ca2-187bdfdcb965@rlwinm.de> Date: Thu, 5 Jan 2017 12:22:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 11:22:31 -0000 On 05/01/2017 12:04, Matthew Seaman wrote: > On 01/05/17 10:43, Kurt Jaeger wrote: >> Hi! >> >> [openldap-client vs openldap-sasl-client and libreoffice etc] >>> Yes and yes it sucks. The "solution" is to build your own repo and set >>> the right flags to always use the same LDAP client port. With binary >>> packages and the speed of modern x86_64 systems I for one no longer see >>> removing SASL support from OpenLDAP as useful enough to justify the >>> complexity. >> >> The other question is: What's the use of SASL anyway ? I've seen it >> for years in mailserver setups, etc, and it always caused trouble. >> > > SASL effectively gets you a number of new authentication mechanisms. > Most of these are ways of proving you know a secret without sending the > actual secret (ie. password) over the net in plain text, but I think it > also adds the ability to use client TLS certificates for authentication. > IIRC. > > I don't see much value in the extra mechanisms for secure login over > unencrypted links nowadays. Pretty much everything I'm using currently > already requires TLS for good security reasons, so there's no real > downside to using plain LOGIN over the encrypted channel. Plus the > 'proof of knowledge' authentication mechanisms have a big downside: they > need the secret stored in the LDAP database in plain text, or in some > locally reversible encryption. With LOGIN over TLS, I can use salted > password hashes in much the same way as Unix passwords. > > SASL would be worth it for TLS client certificate functionality, if > that's the only way to enable that. SASL external is required by OpenLDAP to extract authentication data from TLS client certificates and not all SASL mechs require plaintext passwords inside the database to avoid leaking the credentials over the wire e.g. SASL SCRAM (RFC 5802). You can also use SASL to authenticate against PAM.