Multiple-Mechanism Sample Code?

[Dave Cridland]

On Wed Jan  3 02:09:31 2007, Henry B. Hotz wrote:
> 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.)
> 
> 
I can answer some of that. sasl_client_init() does one-time 
initialization, whereas sasl_client_new() does per-connection 
initialization.


> 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.
> 
> 
ACAP is merely an example of a protocol that got the SASL profile 
right, not a replacement for SASL. It does the full range of 
signalling required, so you know what to do on failure, and it also 
handles both initial responses and data on success, to drop the 
round-trip count.


> 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.
> 
> 
No, sasl_client_new() is once per connection. sasl_client_start() is 
once per authentication attempt. <sasl/sasl.h> has some useful 
documentation, look for "Basic client model".

> 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.
> 
> 
Right, so for the protocol, look at how ACAP does it.

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