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@;andrew.cmu.edu] Sent: Thursday, November 07, 2002 9:24 AM To: David H. Lynch Jr. Cc: [EMAIL PROTECTED] 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