Dan Langille wrote:

> When I run imtest, I see two problems:
> 1 - I see only two AUTH= clauses: DIGEST-MD5 and CRAM-MD5.  Shouldn't 
> I see one for SASL?

No.  SASL is the library that provides the glue between various
authentication mechanisms, the authentication databases and the
applications.  There isn't a 'SASL' authentication mechanism as
such.  You're not seeing LOGIN or PLAIN here -- which suggests
you've got a non-zero security strength factor set, and it seems
you don't have any GSSAPI/Kerberos or SSL based authentication
available, which really leaves only CRAM-MD5 or DIGEST-MD5, and
CRAM-MD5 is really only there for historical reasons.

> 2 - I've been unable to get authorization to work.
> $ imtest -m login -a admin -u admin polo
> AUTH=CRAM-MD5 SASL-IR] polo.unixathome.org Cyrus IMAP4 v2.3.7 server 


> I've tried various sasl_pwcheck_method options.  The above is with 
> "saslauthd".  With "auxprop", it is similar, but:
> Please enter your password:
> C: L01 LOGIN admin {5}
> S: + go ahead
> C: <omitted>
> failure: prot layer failure

'saslauthd' handles only password style authentication.  You can set it
to use the standard system password stuff -- getpwent() or PAM things,
but ironically that will force you to use LOGIN or PLAIN auth mechanisms
with the password being sent over then 'net in plain.  If you use the
separate saslauthdb, or you tie SASL to RADIUS, LDAP or some other back-end
RDBMS, you'll get the more secure login mechanisms (ie. DIGEST-MD5) but
at the cost of having a DB containing the authentication tokens (read:
password) held in plain text inside it.

However, if you're going to have a non-password file auth database, then
forget using saslauthd -- setup Cyrus IMAPD to use auxprop directly.  You
can put configuration stuff for Cyrus in /usr/local/lib/sasl2/Cyrus.conf
or you can add the same directives to /usr/local/etc/imapd.conf prefixed
with 'sasl-' (in addition to the imapd configuration directives from the
imapd.conf(5) man page)  There's a list of the directives you can use
in one of the application Foo.conf files under /usr/local/lib/sasl2/


There's two advantages of doing things that way: (i) you aren't reliant
on saslauthd which can be a SPOF and (ii) you make the *non* password
authentication mechanisms available to your application -- so you can
use GSSAPI or even SSL certs to authenticate users.

Another good move is to provide SSL Certs etc for IMAP and either run
it over an encrypted link (IMAPS on port 993 usually) or permit it to
use STARTTLS to provide an encrypted channel for authentication.



Dr Matthew J Seaman MA, D.Phil.                       7 Priory Courtyard
                                                      Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey         Ramsgate
                                                      Kent, CT11 9PW

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to