Implement SASL

[mildred]

glauth is not able to receive bind requests using SASL as per RFC 4513 section 5.2.

[Fusion]

This is definitely a major enhancement request. It is likely that we will look into it over an extended period of time.

We would need to support the bind mechanism (may have to modify the LDAP library to support the additional attributes) then settle on some algorithms and finally get to work; that is, implement support for these algorithms.

Kerberos5 would likely be the first implemented algorithm.

[terefang]

i think you should not torture yourself with kerberos as the entry into SASL.

my suggestion would be to start with: ANONYMOUS, PLAIN/LOGIN, and EXTERNAL, exactly in that order

• ANONYMOUS -- always success
• PLAIN/LOGIN -- do password match as with simple bind
• EXTERNAL -- success if the subject-dn contained in the tls client certificate can be mapped to a user.

[hexdrome]

SASL is required for any service authenticated by Active Directory or FreeIPA. Because GLAuth supports a external LDAP backend so it must (not should) support GSSAPI too. For Cross-LDAP auth it also requires S4U2Proxy extension support. ANONIMOUS is not used in secured infrastructure. PLAIN is unsecured due to password file. EXTERNAL is associated with CA - too many nuances.

[terefang]

ANONYMOUS

could be enabled/disable with a config option, with default off.

PLAIN/LOGIN

there are many good password hashing algorithms and libraries out there

https://snyk.io/blog/secure-password-hashing-in-go/

EXTERNAL

if you do LDAPS (SSL/TLS) connections already the ssl-library will basically do this for free if configured.

you just need to retrieve the client-cert dn and start mapping:

• try to map the complete dn to a user in the directory
• extract known or configured attributes from dn (cn or uid are common) and map that to a known user.
• compare the dn to a list of known valid ones
• compare the certificate public key has to a list of known valid ones (called "certificate pinning")

people the will use SASL-EXTERNAL are usually well versed in managing CA topics.

all glauth needs to do is loading the list of known allowed CAs for the ssl-library via config. the simplest way is to read all .pem/.crt files from a directory.

[Fusion]

Thanks, nice summary. As a reminder, this is where we are today: https://glauth.github.io/docs/security.html

I understand that bcrypt is not the ultimate solution, for various reasons including allowing the admin to use too few rounds, or mistake a pepper for a salt.

So, yes, I have been very interested in alternate hashings (of course Argon is a top contender), or even zero knowledge auth.

Regarding EXTERNAL, it looks like you are advocating what would be otherwise known as "mutual auth" -- I like the idea, especially if we can use an enterprise signing chain for both ends. This doesn't seem to be a very popular approach, though, as from what I've been reading, only SASL-EXTERNAL is usually offered?

[Fusion]

BTW @hexdrome sometimes the best approach is the swiss cheese model. That is why OTP and Yubikey are also supported.

[terefang]

Thanks, nice summary. As a reminder, this is where we are today: https://glauth.github.io/docs/security.html

I understand that bcrypt is not the ultimate solution, for various reasons including allowing the admin to use too few rounds, or mistake a pepper for a salt.

So, yes, I have been very interested in alternate hashings (of course Argon is a top contender), or even zero knowledge auth.

while bcrypt is ok-ish, a simple sha256 is becoming increasingly insecure by todays standards.

ldap standard defines how password are stored by schemas https://datatracker.ietf.org/doc/html/rfc3112#section-3 as examplified here https://passlib.readthedocs.io/en/stable/lib/passlib.hash.ldap_std.html

and defines compatiblity with unix libcrypt/xcrypt here https://passlib.readthedocs.io/en/stable/lib/passlib.hash.ldap_crypt.html

once documentation catches up, both argon and yes-crypt will be part of that.