What is the proper way to setup SASL and TLS with different security strength factors? I've setup SASL on my OpenLDAP server so that it can connect to my Kerberos server using GSSAPI. I also have TLS setup for simple auth. My database config is below:
root@baneling:~/ldif_files# slapcat -H "ldap:///olcDatabase={1}mdb,cn=config??base?" dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=harmonywave,dc=com olcAccess: {0}to attrs=userPassword,shadowLastChange,krbPrincipalKey by self write by anonymous auth by dn="cn=admin,dc=harmonywave,dc=com" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=harmonywave,dc=com olcRootPW:: e1NTSEF9dUhDcE1jUUJoWlpuc0twRHBNQkVCUGtmTFA5SC9EYUU= olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: sudoUser eq olcDbIndex: krbPrincipalName eq,pres,sub olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: caa04334-6857-1035-9fbb-dd6671002504 creatorsName: cn=admin,cn=config createTimestamp: 20160215174631Z olcSecurity: sasl=56 simple_bind=256 ssf=256 entryCSN: 20160218030327.503814Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20160218030327Z
When I set the security to "olcSecurity: sasl=56 simple_bind=256" then I can bind with SASL or simple auth. However if I set ssf=256 (or really anything higher then 56), like in the above configuration, I get an error when trying to bind with SASL:
root@baneling:~/ldif_files# ldapsearch -LLL -Y GSSAPI -H ldapi:/// -b dc=harmonywave,dc=com -s base SASL/GSSAPI authentication started SASL username: jschaeffer@HARMONYWAVE.COM SASL SSF: 56 SASL data security layer installed. Confidentiality required (13) Additional information: stronger confidentiality required
If I set tls instead of ssf to any number (tls=1 or greater) then I get a slightly different error message when trying to bind with SASL:
root@baneling:~/ldif_files# ldapsearch -LLL -Y GSSAPI -H ldapi:/// -b dc=harmonywave,dc=com -s base SASL/GSSAPI authentication started SASL username: jschaeffer@HARMONYWAVE.COM SASL SSF: 56 SASL data security layer installed. Confidentiality required (13) Additional information: TLS confidentiality required
It looks like slapd has its own preference when parsing through olcSecurity. I'm really just trying to understand the preferred method for setting this up. Perhaps this isn't a real-world situation or perhaps I already answered my own question by setting just sasl and simple_bind.
Thanks, Joshua
Am Wed, 17 Feb 2016 20:25:56 -0700 schrieb Joshua Schaeffer jschaeffer0922@gmail.com:
What is the proper way to setup SASL and TLS with different security strength factors? I've setup SASL on my OpenLDAP server so that it can connect to my Kerberos server using GSSAPI. I also have TLS setup for simple auth. My database config is below:
[...]
olcSecurity: sasl=56 simple_bind=256 ssf=256
ssf=x specifies the overall security, a value '1' enables security. This setting would meet your requirements: olcSecurity: ssf=1 sasl=56 tls=256
-Dieter
On 02/18/2016 03:19 AM, Dieter Klünter wrote:
Am Wed, 17 Feb 2016 20:25:56 -0700 schrieb Joshua Schaeffer jschaeffer0922@gmail.com:
What is the proper way to setup SASL and TLS with different security strength factors? I've setup SASL on my OpenLDAP server so that it can connect to my Kerberos server using GSSAPI. I also have TLS setup for simple auth. My database config is below:
[...]
olcSecurity: sasl=56 simple_bind=256 ssf=256
ssf=x specifies the overall security, a value '1' enables security. This setting would meet your requirements: olcSecurity: ssf=1 sasl=56 tls=256
-Dieter
I updated olcSecurity and now I get the following when using simple auth:
root@immortal:/var/log/kerberos# ldapsearch -LLL -x -D cn=admin,dc=harmonywave,dc=com -W -H ldap://baneling.harmonywave.com/????starttls -b dc=harmonywave,dc=com Enter LDAP Password: ldap_bind: Confidentiality required (13) additional info: SASL confidentiality required
I see this in the logs:
Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 ACCEPT from IP=10.1.10.12:55750 (IP=0.0.0.0:389) Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 STARTTLS Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 RESULT oid= err=0 text= Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 TLS established tls_ssf=256 ssf=256 Feb 18 22:19:08 baneling slapd[22171]: conn=1005 op=1 BIND dn="cn=admin,dc=harmonywave,dc=com" method=128 Feb 18 22:19:08 baneling slapd[22171]: conn=1005 op=1 RESULT tag=97 err=13 text=SASL confidentiality required Feb 18 22:19:08 baneling slapd[22171]: conn=1005 op=2 UNBIND Feb 18 22:19:08 baneling slapd[22171]: conn=1005 fd=15 closed
Am Thu, 18 Feb 2016 22:20:16 -0700 schrieb Joshua Schaeffer jschaeffer0922@gmail.com:
On 02/18/2016 03:19 AM, Dieter Klünter wrote:
Am Wed, 17 Feb 2016 20:25:56 -0700 schrieb Joshua Schaeffer jschaeffer0922@gmail.com:
What is the proper way to setup SASL and TLS with different security strength factors? I've setup SASL on my OpenLDAP server so that it can connect to my Kerberos server using GSSAPI. I also have TLS setup for simple auth. My database config is below:
[...]
olcSecurity: sasl=56 simple_bind=256 ssf=256
ssf=x specifies the overall security, a value '1' enables security. This setting would meet your requirements: olcSecurity: ssf=1 sasl=56 tls=256
-Dieter
I updated olcSecurity and now I get the following when using simple auth:
root@immortal:/var/log/kerberos# ldapsearch -LLL -x -D cn=admin,dc=harmonywave,dc=com -W -H ldap://baneling.harmonywave.com/????starttls -b dc=harmonywave,dc=com Enter LDAP Password: ldap_bind: Confidentiality required (13) additional info: SASL confidentiality required
I see this in the logs:
Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 ACCEPT from IP=10.1.10.12:55750 (IP=0.0.0.0:389) Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 STARTTLS Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 RESULT oid= err=0 text= Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 TLS established tls_ssf=256 ssf=256
[...]
You still have a overall security ssf=256 and it seems your TLS session used a key length lower than 256 bit, check your TLS configuration.
-Dieter
Dieter Klünter wrote:
Am Thu, 18 Feb 2016 22:20:16 -0700
Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 ACCEPT from IP=10.1.10.12:55750 (IP=0.0.0.0:389) Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 STARTTLS Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 RESULT oid= err=0 text= Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 TLS established tls_ssf=256 ssf=256
[...]
You still have a overall security ssf=256 and it seems your TLS session used a key length lower than 256 bit, check your TLS configuration.
Dieter, the log lines say: tls_ssf=256
=> TLS seems to be ok.
Ciao, Michael.
Am Fri, 19 Feb 2016 09:19:28 +0100 schrieb Michael Ströder michael@stroeder.com:
Dieter Klünter wrote:
Am Thu, 18 Feb 2016 22:20:16 -0700
Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 ACCEPT from IP=10.1.10.12:55750 (IP=0.0.0.0:389) Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 STARTTLS Feb 18 22:19:04 baneling slapd[22171]: conn=1005 op=0 RESULT oid= err=0 text= Feb 18 22:19:04 baneling slapd[22171]: conn=1005 fd=15 TLS established tls_ssf=256 ssf=256
[...]
You still have a overall security ssf=256 and it seems your TLS session used a key length lower than 256 bit, check your TLS configuration.
Dieter, the log lines say: tls_ssf=256
=> TLS seems to be ok.
might be, but I think that security strength factor is just a requirement for a given session, but doesn't say anything about configured and used ciphers.
-Dieter
Joshua Schaeffer wrote:
On 02/18/2016 03:19 AM, Dieter Klünter wrote:
ssf=x specifies the overall security, a value '1' enables security. This setting would meet your requirements: olcSecurity: ssf=1 sasl=56 tls=256
I updated olcSecurity
To the exact value Dieter mentioned above?
and now I get the following when using simple auth:
root@immortal:/var/log/kerberos# ldapsearch -LLL -x -D cn=admin,dc=harmonywave,dc=com -W -H ldap://baneling.harmonywave.com/????starttls -b dc=harmonywave,dc=com Enter LDAP Password: ldap_bind: Confidentiality required (13) additional info: SASL confidentiality required
You're not using a SASL bind mech at all. So no wonder why it fails due to sasl=56.
Do not guess. Read the man page for the exact meaning of all this.
Ciao, Michael.
On 02/19/2016 01:20 AM, Michael Ströder wrote:
Joshua Schaeffer wrote:
On 02/18/2016 03:19 AM, Dieter Klünter wrote:
ssf=x specifies the overall security, a value '1' enables security. This setting would meet your requirements: olcSecurity: ssf=1 sasl=56 tls=256
I updated olcSecurity
To the exact value Dieter mentioned above?
Yes, olcSecurity: ssf=1 sasl=56 tls=256
You're not using a SASL bind mech at all. So no wonder why it fails due to sasl=56.
Yes I surmised as much. But how do I tell slapd that when I do a simple auth use the tls settings and when I do an SASL auth to use sasl settings. Can you point me to the man pages that explains this.
--On Saturday, February 20, 2016 7:28 PM -0700 Joshua Schaeffer jschaeffer0922@gmail.com wrote:
Yes I surmised as much. But how do I tell slapd that when I do a simple auth use the tls settings and when I do an SASL auth to use sasl settings. Can you point me to the man pages that explains this.
Set this correctly: olcSaslSecProps: <properties> Used to specify Cyrus SASL security properties. The none flag (without any other properties) causes the flag properties default, "noanonymous,noplain", to be cleared. The noplain flag disables mechanisms susceptible to simple passive attacks. The noactive flag disables mechanisms susceptible to active attacks. The nodict flag disables mechanisms susceptible to passive dictionary attacks. The noanonymous flag disables mechanisms which support anonymous login. The forwardsec flag require forward secrecy between sessions. The passcred require mechanisms which pass client credentials (and allow mechanisms which can pass credentials to do so). The minssf=<factor> property specifies the minimum acceptable security strength factor as an integer approximate to effective key length used for encryption. 0 (zero) implies no protection, 1 implies integrity protection only, 56 allows DES or other weak ciphers, 112 allows triple DES and other strong ciphers, 128 allows RC4, Blowfish and other modern strong ciphers. The default is 0. The maxssf=<factor> property specifies the maximum acceptable security strength factor as an integer (see minssf description). The default is INT_MAX. The maxbufsize=<size> property specifies the maximum security layer receive buffer size allowed. 0 disables security layers. The default is 65536.
Then only set the tls SSF in olcSecurity (drop the SASL SSF). Make sure your SASL binds *also* use TLS. Then you're covered.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc
That did the trick. Thanks for pointing out that I also need to use SASL with TLS. I don't know why, but for some reason I was keeping the two separate in my mind.
On 02/20/2016 07:59 PM, Quanah Gibson-Mount wrote:
--On Saturday, February 20, 2016 7:28 PM -0700 Joshua Schaeffer jschaeffer0922@gmail.com wrote:
Yes I surmised as much. But how do I tell slapd that when I do a simple auth use the tls settings and when I do an SASL auth to use sasl settings. Can you point me to the man pages that explains this.
Set this correctly: olcSaslSecProps: <properties> Used to specify Cyrus SASL security properties. The none flag (without any other properties) causes the flag properties default, "noanonymous,noplain", to be cleared. The noplain flag disables mechanisms susceptible to simple passive attacks. The noactive flag disables mechanisms susceptible to active attacks. The nodict flag disables mechanisms susceptible to passive dictionary attacks. The noanonymous flag disables mechanisms which support anonymous login. The forwardsec flag require forward secrecy between sessions. The passcred require mechanisms which pass client credentials (and allow mechanisms which can pass credentials to do so). The minssf=<factor> property specifies the minimum acceptable security strength Set this correctly: olcSaslSecProps: <properties> Used to specify Cyrus SASL security properties. The none flag (without any other properties) causes the flag properties default, "noanonymous,noplain", to be cleared. The noplain flag disables mechanisms susceptible to simple passive attacks. The noactive flag disables mechanisms susceptible to active attacks. The nodict flag disables mechanisms susceptible to passive dictionary attacks. The noanonymous flag disables mechanisms which support anonymous login. The forwardsec flag require forward secrecy between sessions. The passcred require mechanisms which pass client credentials (and allow mechanisms which can pass credentials to do so). The minssf=<factor> property specifies the minimum acceptable security strength factor as an integer approximate to effective key length used for encryption. 0 (zero) implies no protection, 1 implies integrity protection only, 56 allows DES or other weak ciphers, 112 allows triple DES and other strong ciphers, 128 allows RC4, Blowfish and other modern strong ciphers. The default is 0. The maxssf=<factor> property specifies the maximum acceptable security strength factor as an integer (see minssf description). The default is INT_MAX. The maxbufsize=<size> property specifies the maximum security layer receive buffer size allowed. 0 disables security layers. The default is 65536.
Then only set the tls SSF in olcSecurity (drop the SASL SSF). Make sure your SASL binds *also* use TLS. Then you're covered.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc.
openldap-technical@openldap.org
-
Dieter Klünter -
Joshua Schaeffer -
Michael Ströder -
Quanah Gibson-Mount