The SASL API is already pretty complex for what it does IMO. (Why
isn't there a call that does both sasl_client_init() and
sasl_client_new()? Why does every app need 10++ lines in front of
sasl_{client,server}_new() to do two getnameinfo()'s and two
snprintf's, instead of just handing over the sockaddr's? Why. . . ?
Obviously, I'm still getting familiar with things.)
Unless you can tell me that there is a properly-documented API for an
ACAP library that's deployed on as many platforms (including Java) as
SASL already is, *AND* that it's no harder to write/modify an
application to use ACAP than it is to use SASL, then I'm not
interested. Sorry. You're welcome to try to convince me, but it
sounds off-topic for this list.
In my current experiments Cyrus SASL doesn't appear to work when you
call sasl_client_start() with the second mechanism to try. There are
a lot of variables here, and a better-than-even chance the problem is
in my code, not the library. Once I have something properly working
I'll revisit this issue. I gather you're claiming that ACAP solves
this (and other) problems. See above.
Hopefully I can provide a better SASL example than the one currently
circulating. The one in the current distribution is really an option
test rig. The older example is better for someone figuring out how
to write a SASL-ized application.
On Dec 19, 2006, at 1:23 AM, Dave Cridland wrote:
On Mon Dec 18 22:12:03 2006, Alexey Melnikov wrote:
Henry B. Hotz wrote:
The published sample code seems to only try the first mechanism
and then quit. I'm told the "correct" way to do SASL is to try
all the mechanisms (or at least all the ones supported) and
don't quit until you've tried them all. Is there any example
code that illustrates this?
(I wanted to point you to Cyrus imtest, but it doesn't do that).
In general, I think a well written SASL client should behave as
follows:
It should sort SASL mechanisms that both client and server support
by their "strength" or features recognized by the client. For SASL
mechanisms with equal strength the order used by the server can be
used.
The client starts iterating through the ordered list, starting
from the strongest mechanism. It tries the mechanism. If
authentication succeeds - success. If not, the client may retry
the mechanism (e.g. if the server returned an indication that the
password is incorrect) several times, say 3 times. After that the
client should move on to the next strongest SASL mechanism and so on.
There are of course some complications. Some SASL mechanisms that
can potentially be stronger can end up being weaker, because of
the options that the server supports.
There are more complications than that - some protocols give you a
fairly wide set of protocol-level data about why a SASL exchange
failed, others don't. For example, IMAP will give you a pretty
simple "NO" for any failure at all, whereas ACAP will tell you
rather more, such as AUTH-TOO-WEAK, ENCRYPT-NEEDED, TRANSITION-
NEEDED, etc, which can be used by the client to figure out what the
next action should be.
Working examples? I'm modifying the PostgreSQL protocol as needed.
Adding SASL data to existing messages is easy. Adding an
AuthenticationContinue message isn't very hard either because they
have a protocol manual that's quite nice.
I'm concerned that the Cyrus API is so complex that the resulting
patches may be deemed too complex for acceptance. From a practical
standpoint what PostgreSQL stands to gain is 1) Kerberos support that
works on Windows and in Java, not just Unix/C, and 2) a bunch of
stuff that duplicates existing functionality. If it works well
enough 2) could be seen as an advantage in the long run since it
could allow the removal of their custom password database, custom
password verification algorithms, and PAM support. "Works well
enough" means "works, and takes no effort to link against on most
platforms".
Also, you need to add TLS into the mix, too - which is in itself
negotiated, of course, and will probably change the advertised
mechanisms.
As a for-example, a ACAP client might initially try DIGEST-MD5,
cancel it partway through because no encryption was supported, use
STARTTLS, try DIGEST-MD5, fail due to a TRANSITION-NEEDED code, and
use PLAIN.
An IMAP client in more or less tha same situation has longer to go,
because it doesn't get the TRANSITION-NEEDED code, and therefore
has no idea if it should retry DIGEST-MD5 a few times, or try a
different mechanism.
As if anyone needed *more* reasons to use ACAP. :-)
Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@xxxxxxxxxxxx, or hbhotz@xxxxxxx
