Hello,
openldap 2.5.12 cyrus-sasl 2.1.28 + sasl channel binding patch[1] + gss-spnego maxssf=0 patch[2] openldap linked with gnutls libsasl2-modules-gssapi-mit
I'm currently testing the patches[1][2] for sasl channel binding over GSSAPI + ssl/tls connection, and was wondering if I could get openldap to reject ldaps connections without sasl channel binding. Currently it seems to always accept it, but I can't be sure CB was even checked by the server by looking at logs (even with -d -1). I got windows 2016 AD to reject ldaps connections without CB over gssapi and gss-spnego, so the client part of openldap (ldapwhoami specifically) seems ok.
I looked at test 077[3] and it runs the server with this configuration: dn: cn=config changetype: modify replace: olcSaslCBinding olcSaslCBinding: ${acb}
Where `${acb}` loops over the 3 valid values of "none" "tls-unique" "tls-endpoint".
Then a simple connection with ldapwhoami is attempted, also looping -o SASL_CBINDING=$icb over those values.
I have seen the comment in that test script that it looks like tls-unique is broken when used with gnutls[4], and also a comment about MIT failing in another case[5].
When trying it manually, though, I could never get the client connection to be refused by the server. Before digging in deeper, let me just ask if my understanding is correct:
- server configured with: dn: cn=config changetype: modify replace: olcSaslCBinding olcSaslCBinding: tls-endpoint
- client connecting to that server over ldaps://, with GSSAPI, and with -o SASL_CBINDING=none
Should that client be rejected?
Sample run:
$ sudo ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcSaslCBinding=*)' olcSaslCBinding SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=config olcSaslCBinding: tls-endpoint
$ ldapwhoami -Y GSSAPI -H ldaps://k-slapd.lxd -o SASL_CBINDING=none SASL/GSSAPI authentication started SASL username: ubuntu@VMS SASL SSF: 256 SASL data security layer installed. dn:uid=ubuntu,cn=gssapi,cn=auth
And the server logs (olcLogLevel: stats): Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 fd=14 ACCEPT from IP=10.0.100.36:33800 (IP=0.0.0.0:636) Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 fd=14 TLS established tls_ssf=256 ssf=256 tls_proto=TLS1.3 tls_cipher=AES-256-GCM Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=0 BIND dn="" method=163 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=0 RESULT tag=97 err=14 qtime=0.000011 etime=0.002447 text=SASL(0): successful result: Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=1 BIND dn="" method=163 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=1 RESULT tag=97 err=14 qtime=0.000012 etime=0.000069 text=SASL(0): successful result: Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 BIND dn="" method=163 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 BIND authcid="ubuntu" authzid="ubuntu" Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 BIND dn="uid=ubuntu,cn=gssapi,cn=auth" mech=GSSAPI bind_ssf=256 ssf=256 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 RESULT tag=97 err=0 qtime=0.000012 etime=0.000109 text= Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=3 EXT oid=1.3.6.1.4.1.4203.1.11.3 Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=3 WHOAMI Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=3 RESULT oid= err=0 qtime=0.000016 etime=0.000087 text= Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=4 UNBIND Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 fd=14 closed
1. https://github.com/cyrusimap/cyrus-sasl/commit/975edbb69070eba6b035f08776de7... 2. https://github.com/cyrusimap/cyrus-sasl/pull/603/commits 3. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/tests... 4. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/tests... 5. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/tests...
Hi Andreas,
On Mon, Jul 25, 2022 at 6:00 PM Andreas Hasenack andreas@canonical.com wrote:
Hello,
openldap 2.5.12 cyrus-sasl 2.1.28 + sasl channel binding patch[1] + gss-spnego maxssf=0 patch[2] openldap linked with gnutls libsasl2-modules-gssapi-mit
I'm currently testing the patches[1][2] for sasl channel binding over GSSAPI + ssl/tls connection, and was wondering if I could get openldap to reject ldaps connections without sasl channel binding. Currently it seems to always accept it, but I can't be sure CB was even checked by the server by looking at logs (even with -d -1). I got windows 2016 AD to reject ldaps connections without CB over gssapi and gss-spnego, so the client part of openldap (ldapwhoami specifically) seems ok.
I looked at test 077[3] and it runs the server with this configuration: dn: cn=config changetype: modify replace: olcSaslCBinding olcSaslCBinding: ${acb}
Where `${acb}` loops over the 3 valid values of "none" "tls-unique" "tls-endpoint".
Then a simple connection with ldapwhoami is attempted, also looping -o SASL_CBINDING=$icb over those values.
I have seen the comment in that test script that it looks like tls-unique is broken when used with gnutls[4], and also a comment about MIT failing in another case[5].
When trying it manually, though, I could never get the client connection to be refused by the server. Before digging in deeper, let me just ask if my understanding is correct:
- server configured with:
dn: cn=config changetype: modify replace: olcSaslCBinding olcSaslCBinding: tls-endpoint
- client connecting to that server over ldaps://, with GSSAPI, and
with -o SASL_CBINDING=none
Should that client be rejected?
That's exactly case[5] you refer to above, the answer is as in the comment; it will be rejected with old MIT libs but not with newer ones nor it will be rejected with heimdal. To get the client rejected you need that both client and server set bindings and that those bindings don't match. Otherwise, to properly handle this case where the server sets binding and not the client, the returned flags could be checked for GSS_C_CHANNEL_BOUND_FLAG which was added in recent Heimdal/MIT libs, see links below. I guess new server option could be added to require CBT, implemented by checking this flag.
MIT and Heimdal related changes: https://github.com/krb5/krb5/pull/1047 https://github.com/heimdal/heimdal/pull/712
Hi Isaac, thanks for the reply
On Tue, Jul 26, 2022 at 11:06 AM Isaac Boukris iboukris@gmail.com wrote:
Hi Andreas,
On Mon, Jul 25, 2022 at 6:00 PM Andreas Hasenack andreas@canonical.com wrote:
Hello,
That's exactly case[5] you refer to above, the answer is as in the comment; it will be rejected with old MIT libs but not with newer ones nor it will be rejected with heimdal. To get the client rejected you
I was using MIT krb 1.19, I thought it was new enough :)
need that both client and server set bindings and that those bindings don't match. Otherwise, to properly handle this case where the server sets binding and not the client, the returned flags could be checked for GSS_C_CHANNEL_BOUND_FLAG which was added in recent Heimdal/MIT libs, see links below. I guess new server option could be added to require CBT, implemented by checking this flag.
Thanks for the explanation.
MIT and Heimdal related changes: https://github.com/krb5/krb5/pull/1047
This was merged in 2020, but doesn't seem to be in any release yet, just in the master branch. This seems to be a trend with sasl gssapi channel binding patches ;)
Merged in 2021, but also not in any release yet
Hi,
On Tue, Jul 26, 2022 at 11:53 AM Andreas Hasenack andreas@canonical.com wrote:
Hi Isaac, thanks for the reply
On Tue, Jul 26, 2022 at 11:06 AM Isaac Boukris iboukris@gmail.com wrote:
Hi Andreas,
On Mon, Jul 25, 2022 at 6:00 PM Andreas Hasenack andreas@canonical.com wrote:
Hello,
MIT and Heimdal related changes: https://github.com/krb5/krb5/pull/1047
This was merged in 2020, but doesn't seem to be in any release yet, just in the master branch. This seems to be a trend with sasl gssapi channel binding patches ;)
Oops, I was relying too much on git tag/branch --contains, it is in 1.19 at least.
openldap-technical@openldap.org
-
Andreas Hasenack -
Isaac Boukris