SASL Docs

[Rob Siemborski]

On Thu, 7 Nov 2002, David H. Lynch Jr. wrote:

> 	It does not help that virtually all the "HOWTO's" that are on
> the net, as well as the book,
> 	are all pretty much obsolete and this particular issue is the one
> they are most out of date about.

These resources aren't maintained by us, so there is very little we can do
about this.

> 	Most aspects of setting Cyrus IMAP up are not particularly
> difficult.
> 	But authorization/authentication is excruciatingly complex.

This is because it is a complicated issue.  Integrating cleanly with the
number of different authentication/authorization systems that are in
production throughout the world results in a large number of
possibilities.

> 	let me see if I understand correctly:
> 			no method except sasldb actually depends on
> sasldb.

sasldb isn't a method per se.  It's just an auxprop plugin.  Think of it
as a database access method.

> 			However some methods require some form of local
> user database, and sasldb can be used to supply that database for those
> methods.

Yes.

> 			The methods that do NOT require a local user
> database are:
> 					LOGIN, PLAIN, GSSAPI,
> Kerberos_V4, and ANONYMOUS.

These are the methods that don't require an auxprop plugin.

> 			(local above means specific to SASL, since LDAP
> or MYSQL could be remote)

I'm not sure what the distinction here is.  MySQL can supply the needed
information as it is distributed by SASL.  There's also an LDAP auxprop
plugin that is available from a third party, but we're not interested in
integrating for various reasons.

> 			I am assuming LDAP for SASL purposes is only a
> place to store under information
> 			NOT an authentication method ?

LDAP is only a directory access protocol, and therefor a place to
store information.  It's not an authentication method at all

> 	As best as I can tell the distinction between auxprqop methods
> and saslauthd methods,
> 	is that an auxprop method could involve exchanging
> authentication information between the client and SASL
> 	in a secure form and that with saslauthd the exchange between
> the client and SASL/imap is plain text.

That has nothing to do with the security of the mechanism.  Well, it does
indirectly, but you're really overloading the word "methods" I think.

saslauthd can only 'verify' passwords.  For example, you can only say "is
'foobar' the password for 'rjs3'?"

This implies that the server needs to have a plaintext copy of the
password from the client.

The auxprop interface allow you to turn the query around like "what is the
password for 'rjs3'?"

This allows you to rehash the password and do other intresting things, and
means that the client can send you a hash instead.

> 	The exchange between saslauthd and whatever authenticates the user
> could still be secure.

This is totally dependent on the saslauthd module that is being used.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper