Multiple-Mechanism Sample Code?

[Henry B. Hotz]

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 at cridland.net - xmpp:dwd at jabber.org
>  - 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 at jpl.nasa.gov, or hbhotz at oxy.edu