Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: users

GNU SASL gsasl integration into Exim

 

 

exim users RSS feed   Index | Next | Previous | View Threaded


pdp at exim

Feb 13, 2012, 6:52 PM

Post #1 of 6 (602 views)
Permalink
GNU SASL gsasl integration into Exim

Folks,

A first cut at GNU SASL (gsasl) integration has been written for Exim.

At this time, it's server-only. I'm not sure whether or not to
integrate this for release as part of the next Exim. Feedback may make
the difference, but something more informative than "+1"/"me too"
please.

This authentication driver can be built into Exim at the same time as
Cyrus SASL. It provides the mechanism work, but does not provide
authentication sources (an inherent difference between the two
libraries). You'll need to use server_condition or server_password for
that, depending upon the mechanism used.


The code is on the gsasl branch of git:
http://git.exim.org/exim.git/shortlog/refs/heads/gsasl
and includes full documentation.

I've built the PDF and made it available at:
http://www.exim.org/~pdp/spec-gsasl-dev.pdf
Note that this claims to be for 4.77. The major changes are to chapter
33 and the insertion of a new chapter 38.


There are a number of open issues:

(1) Versioning of available features and library interfaces is not
ideal. I wrote and tested against gsasl 1.6.1.

(2) Some aspects of the API do not let Exim generically support future
mechanisms; instead, knowledge of each mechanism needs to be
embedded into Exim. This is why the versioning is not ideal. It's
not immediately obvious which versions of gsasl introduced which
mechanism identifiers. Code archaeology would answer that, but I'm
currently adopting the approach of "report compile problems you
encounter, I'll then see what needs to be done".

I'm a reluctant to commit the Exim Maintainers to ongoing
integration work which will either tie particular releases of Exim
to particular releases of gsasl, or require an increasing amount of
spaghetti inside Exim to sometimes use some new symbols and some
logic for when to set $auth1, to which gsasl property, and with
what prior dependencies.

I'd be happier if I'd received a response to my mail to the gsasl
mailing-list, to discuss the issues and if I saw gsasl moving in a
direction which would make it easier for us in the future. But it
might just be that the goals and aims of the two projects are not
mutually compatible and we'll just not integrate this work for
release as part of Exim.

(nb: it's only been a little over a week since I mailed them, so
this may be the same issue Exim sometimes has, as a result of
relying solely upon volunteers for doing the work).

(3) Released versions of OpenSSL do not, that I have seen, provide an
API for cleanly extracting channel binding information, so that
code can only be used with GnuTLS. I do not use GnuTLS, so that
code is currently untested. (See the docs for information on
channel binding).

(4) I haven't used the SCRAM mechanisms and suspect that we might want
to make $auth1 available at time of expanding the scram options, or
make the results of those two options available as variables while
expanding server_password. Informed feedback welcome.

(5) Exim currently can not use a string with embedded NULs, supplied in
configuration, for DB lookups, so you can *not* just use the gsasl
driver to talk directly to sasldb2 and cut over. It would be
informative to see expressions of serious interest by users who
want this, so that we can judge the importance of this work.

(6) I've no idea how to augment GSASL to integrate with Kerberos for
GSSAPI right now. The version of Heimdal I'm running disables
using KRB5_KTNAME from the environment for setuid binaries; there's
no way exported via gsasl to set the keytab. This affects Cyrus
too.

Heimdal doesn't let the keytab be set in appdefaults, only
libdefaults. *sigh* For folks using older releases of Heimdal,
gsasl might "just work" for you. Please let me know if it does.

(7) Nothing has been written for the test suite yet, so we have no
regression tests. I'm not willing to do this until we decide
whether to integrate for release.

Regards,
-Phil
--
https://twitter.com/syscomet


pdp at exim

Mar 2, 2012, 2:25 AM

Post #2 of 6 (558 views)
Permalink
Re: GNU SASL gsasl integration into Exim [In reply to]

On 2012-02-13 at 21:52 -0500, Phil Pennock wrote:
> (5) Exim currently can not use a string with embedded NULs, supplied in
> configuration, for DB lookups, so you can *not* just use the gsasl
> driver to talk directly to sasldb2 and cut over. It would be
> informative to see expressions of serious interest by users who
> want this, so that we can judge the importance of this work.

There is now a "dbmjz" branch in Exim's git repository which adds the
"dbmjz" lookup type. This new type is very similar to dbmnz, except
that the key is interpreted as an Exim list, the items of which are
joined together with ASCII NUL characters.

I can successfully authenticate to Exim using:

auth_cram_own:
driver = cram_md5
public_name = CRAM-MD5
server_secret = ${lookup{$auth1:imap.spodhuis.org:userPassword}\
dbmjz{/usr/local/etc/sasldb2}{$value}fail}
server_set_id = $auth1

Note here that "imap.spodhuis.org" is the server realm as used by my
Cyrus install, whereas "userPassword" is a literal string.

You need to make sure that the Exim run-time user has read access to the
sasldb2 file.

This also works with the new gsasl authenticator, so that with gsasl and
dbmjz you should be able to migrate from Cyrus SASL to GNU SASL while
using the same password stores.

This is not a commentary on Cyrus SASL: Exim supports multiple TLS
providers, multiple authenticators, etc. It's just that now we have the
GPL'd gsasl driver and a way for administrators to switch to this in
practice, rather than creating a lot of migration work.

Regards,
-Phil


holborn-exim at real-life

Mar 3, 2012, 5:50 AM

Post #3 of 6 (549 views)
Permalink
Re: GNU SASL gsasl integration into Exim [In reply to]

Phil Pennock wrote:
> I can successfully authenticate to Exim using:
>
> auth_cram_own:
> driver = cram_md5
> public_name = CRAM-MD5
> server_secret = ${lookup{$auth1:imap.spodhuis.org:userPassword}\
> dbmjz{/usr/local/etc/sasldb2}{$value}fail}
> server_set_id = $auth1

I have been successful in compiling and using this on my companies exim
server. A handful of weekend users (including myself) have all successfully
authenticated. Monday morning will provide some better "stress testing"
but it works perfectly so far!

Regards

D.

> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


pdp at exim

Mar 4, 2012, 12:28 AM

Post #4 of 6 (543 views)
Permalink
Re: GNU SASL gsasl integration into Exim [In reply to]

On 2012-03-03 at 13:50 +0000, Drav Sloan wrote:
> Phil Pennock wrote:
> > I can successfully authenticate to Exim using:
> >
> > auth_cram_own:
> > driver = cram_md5
> > public_name = CRAM-MD5
> > server_secret = ${lookup{$auth1:imap.spodhuis.org:userPassword}\
> > dbmjz{/usr/local/etc/sasldb2}{$value}fail}
> > server_set_id = $auth1
>
> I have been successful in compiling and using this on my companies exim
> server. A handful of weekend users (including myself) have all successfully
> authenticated. Monday morning will provide some better "stress testing"
> but it works perfectly so far!

Good to know, thanks. :)

I'd be interested to know your views on the utility of this, versus just
proving that it can be done and having an alternative/competitor.

"One less moving part"? Problems with saslauthd? Or "doesn't really
matter to us"?

Ta muchly,
-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


holborn-exim at real-life

Mar 5, 2012, 5:36 AM

Post #5 of 6 (547 views)
Permalink
Re: GNU SASL gsasl integration into Exim [In reply to]

Phil Pennock wrote:
> > I have been successful in compiling and using this on my companies exim
> > server. A handful of weekend users (including myself) have all successfully
> > authenticated. Monday morning will provide some better "stress testing"
> > but it works perfectly so far!
>
> Good to know, thanks. :)

And FYI, today has seen no issues.

> I'd be interested to know your views on the utility of this, versus just
> proving that it can be done and having an alternative/competitor.
>
> "One less moving part"? Problems with saslauthd? Or "doesn't really
> matter to us"?

I remember having issues, some time ago, when setting up our Exim mail
server to play with sasl - It took a certain amount of faff to get it
to work. This looks like a more clear and straight forward way to do
similar authentication (it just worked when I put your example in place
with the appropriate tweaks for my server).

D.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


pdp at exim

Mar 21, 2012, 1:49 AM

Post #6 of 6 (505 views)
Permalink
Re: GNU SASL gsasl integration into Exim [In reply to]

On 2012-03-02 at 02:25 -0800, Phil Pennock wrote:
> On 2012-02-13 at 21:52 -0500, Phil Pennock wrote:
> > (5) Exim currently can not use a string with embedded NULs, supplied in
> > configuration, for DB lookups, so you can *not* just use the gsasl
> > driver to talk directly to sasldb2 and cut over. It would be
> > informative to see expressions of serious interest by users who
> > want this, so that we can judge the importance of this work.
>
> There is now a "dbmjz" branch in Exim's git repository which adds the
> "dbmjz" lookup type. This new type is very similar to dbmnz, except
> that the key is interpreted as an Exim list, the items of which are
> joined together with ASCII NUL characters.

Merged to master. We have feedback from Drav, it works in production
for him and is useful. That's enough for me. :)

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

exim users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.