SASL Docs

[David H. Lynch Jr.]

	Sorry, I was not meaning to imply that you were responsible for
the  documentation. 

	I believe many months ago Ken produced an ASCII chart that
graphically represented much of this.
	I did not understand it at the time, and I am not sure I fully
grasp it yet, but I am an architect 
	and I tend to think visually.

	Is the distinction between "auxprop" methods that use auxprop
and those that do not,
	the requirement for a database (outside of any that Kerberos,
etc might maintain on its own) ?

	LDAP has been uses for authentication - much the same was as
rimap, 
	But I do understand that it is really a directory database, not
an authentication protocol.
	All I was trying to say regarding LDAP, MySQL, ... is that some
methods require an independent database,
	and there are a variety of choices for that database.
	
	I believe I grasp the difference between saslauthd, auxprop and
other SASL native methods.

	If I do not want to have to maintain an independent database of
users and secrets of some kind, 
	my choices are GSSAPI, LOGIN, PLAIN, krb4, ANONYMOUS, and
saslauthd.

			krb4 and ANONYMOUS are not relevant to what I
need.
	
	While I have not yet succeeded with GSSAPI, there appears to be
sufficient documentation, 
	and my problems are most likely with the idiosyncrasies of
integrating with M$'s Kerberos.
	God forbid M$ should actually follow a standard.
		
	Unless LOGIN or PLAIN trigger PAM, they do not help either.

	saslauthd is inherently less secure, but that is not a huge
problem as for the moment the clients I have to 
	deal with are going to be providing plain text passwords anyway.

	saslauthd provides another set of choices, the most potentially
useful to me are kerberos5 and pam.
	
	What little information I can find on saslauthd/kerberos5 seems
to indicate that it does not require 
	as much to be configured correctly as SASL/GSSAPI, but I can not
find any documentation, 
	It does not appear to take information from the local kerberos
configuration, 
	when I tried it, 
		the auth.log messages indicated a blank realm  (nor I
suspect where the kdc was to validate against)
		regardless of the realm information in imapd.conf or
whatever was appended to the user ID.

	Which leaves me stuck with PAM primarily because I can get there
and there is significantly more information
	regarding configuring it.

	

		 

	

-----Original Message-----
From: Rob Siemborski [mailto:rjs3 at andrew.cmu.edu] 
Sent: Thursday, November 07, 2002 9:24 AM
To: David H. Lynch Jr.
Cc: info-cyrus at lists.andrew.cmu.edu
Subject: RE: SASL Docs


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