Authentication with saslauthd
Tiron Adrian
tiron_adrian at yahoo.com
Thu Jan 4 05:49:16 EST 2007
I tried to start saslauth with the option -s smtp, but the option -s is for cache size or something so it accepts an integer not a name for a service.... I looked at the man page and i didn't find any options to specify another name service....
Here is the output of saslfinfer -s
saslfinger - postfix Cyrus sasl configuration Thu Jan 4 12:43:04 EET 2007
version: 1.0
mode: server-side SMTP AUTH
-- basics --
Postfix: 2.3.5
System: Fedora Core release 4 (Stentz)
-- smtpd is linked to --
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x43f44000)
-- active SMTP AUTH and TLS parameters for smtpd --
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain =
smtpd_sasl_path = /usr/lib/sasl2/smtpd.conf #numele fisierului in care caut din /usr/lib/sasl2/
smtpd_sasl_security_options = noanonymous
smtpd_tls_CAfile = /var/ssl/cacert.pem
smtpd_tls_cert_file = /etc/postfix/cert.pem
smtpd_tls_key_file = /etc/postfix/key.pem
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:/var/run/smtpd_tls_session_cache
smtpd_use_tls = yes
-- listing of /usr/lib/sasl2 --
total 1884
drwxr-xr-x 2 root root 4096 Jan 3 21:15 .
drwxr-xr-x 11 root root 4096 Dec 28 14:23 ..
-rwxr-xr-x 1 root root 695 Dec 28 14:23 libanonymous.la
-rwxr-xr-x 1 root root 53966 Dec 28 14:23 libanonymous.so
-rwxr-xr-x 1 root root 53966 Dec 28 14:23 libanonymous.so.2
-rwxr-xr-x 1 root root 53966 Dec 28 14:23 libanonymous.so.2.0.21
-rwxr-xr-x 1 root root 683 Dec 28 14:23 libcrammd5.la
-rwxr-xr-x 1 root root 60638 Dec 28 14:23 libcrammd5.so
-rwxr-xr-x 1 root root 60638 Dec 28 14:23 libcrammd5.so.2
-rwxr-xr-x 1 root root 60638 Dec 28 14:23 libcrammd5.so.2.0.21
-rwxr-xr-x 1 root root 713 Dec 28 14:23 libdigestmd5.la
-rwxr-xr-x 1 root root 122213 Dec 28 14:23 libdigestmd5.so
-rwxr-xr-x 1 root root 122213 Dec 28 14:23 libdigestmd5.so.2
-rwxr-xr-x 1 root root 122213 Dec 28 14:23 libdigestmd5.so.2.0.21
-rwxr-xr-x 1 root root 749 Dec 28 14:23 libgssapiv2.la
-rwxr-xr-x 1 root root 78021 Dec 28 14:23 libgssapiv2.so
-rwxr-xr-x 1 root root 78021 Dec 28 14:23 libgssapiv2.so.2
-rwxr-xr-x 1 root root 78021 Dec 28 14:23 libgssapiv2.so.2.0.21
-rwxr-xr-x 1 root root 668 Dec 28 14:23 libotp.la
-rwxr-xr-x 1 root root 118265 Dec 28 14:23 libotp.so
-rwxr-xr-x 1 root root 118265 Dec 28 14:23 libotp.so.2
-rwxr-xr-x 1 root root 118265 Dec 28 14:23 libotp.so.2.0.21
-rwxr-xr-x 1 root root 679 Dec 28 14:23 libplain.la
-rwxr-xr-x 1 root root 55296 Dec 28 14:23 libplain.so
-rwxr-xr-x 1 root root 55296 Dec 28 14:23 libplain.so.2
-rwxr-xr-x 1 root root 55296 Dec 28 14:23 libplain.so.2.0.21
-rwxr-xr-x 1 root root 704 Dec 28 14:23 libsasldb.la
-rwxr-xr-x 1 root root 96624 Dec 28 14:23 libsasldb.so
-rwxr-xr-x 1 root root 96624 Dec 28 14:23 libsasldb.so.2
-rwxr-xr-x 1 root root 96624 Dec 28 14:23 libsasldb.so.2.0.21
drwxr-xr-x 2 root root 4096 Jan 3 21:15 sasl2
-rw-r--r-- 1 root postfix 49 Dec 28 14:29 smtpd.conf
-rw-r--r-- 1 root root 0 Dec 28 14:28 smtpd.conf~
-- listing of /usr/local/lib/sasl2 --
total 1884
drwxr-xr-x 2 root root 4096 Jan 3 21:15 .
drwxr-xr-x 11 root root 4096 Dec 28 14:23 ..
-rwxr-xr-x 1 root root 695 Dec 28 14:23 libanonymous.la
-rwxr-xr-x 1 root root 53966 Dec 28 14:23 libanonymous.so
-rwxr-xr-x 1 root root 53966 Dec 28 14:23 libanonymous.so.2
-rwxr-xr-x 1 root root 53966 Dec 28 14:23 libanonymous.so.2.0.21
-rwxr-xr-x 1 root root 683 Dec 28 14:23 libcrammd5.la
-rwxr-xr-x 1 root root 60638 Dec 28 14:23 libcrammd5.so
-rwxr-xr-x 1 root root 60638 Dec 28 14:23 libcrammd5.so.2
-rwxr-xr-x 1 root root 60638 Dec 28 14:23 libcrammd5.so.2.0.21
-rwxr-xr-x 1 root root 713 Dec 28 14:23 libdigestmd5.la
-rwxr-xr-x 1 root root 122213 Dec 28 14:23 libdigestmd5.so
-rwxr-xr-x 1 root root 122213 Dec 28 14:23 libdigestmd5.so.2
-rwxr-xr-x 1 root root 122213 Dec 28 14:23 libdigestmd5.so.2.0.21
-rwxr-xr-x 1 root root 749 Dec 28 14:23 libgssapiv2.la
-rwxr-xr-x 1 root root 78021 Dec 28 14:23 libgssapiv2.so
-rwxr-xr-x 1 root root 78021 Dec 28 14:23 libgssapiv2.so.2
-rwxr-xr-x 1 root root 78021 Dec 28 14:23 libgssapiv2.so.2.0.21
-rwxr-xr-x 1 root root 668 Dec 28 14:23 libotp.la
-rwxr-xr-x 1 root root 118265 Dec 28 14:23 libotp.so
-rwxr-xr-x 1 root root 118265 Dec 28 14:23 libotp.so.2
-rwxr-xr-x 1 root root 118265 Dec 28 14:23 libotp.so.2.0.21
-rwxr-xr-x 1 root root 679 Dec 28 14:23 libplain.la
-rwxr-xr-x 1 root root 55296 Dec 28 14:23 libplain.so
-rwxr-xr-x 1 root root 55296 Dec 28 14:23 libplain.so.2
-rwxr-xr-x 1 root root 55296 Dec 28 14:23 libplain.so.2.0.21
-rwxr-xr-x 1 root root 704 Dec 28 14:23 libsasldb.la
-rwxr-xr-x 1 root root 96624 Dec 28 14:23 libsasldb.so
-rwxr-xr-x 1 root root 96624 Dec 28 14:23 libsasldb.so.2
-rwxr-xr-x 1 root root 96624 Dec 28 14:23 libsasldb.so.2.0.21
drwxr-xr-x 2 root root 4096 Jan 3 21:15 sasl2
-rw-r--r-- 1 root postfix 49 Dec 28 14:29 smtpd.conf
-rw-r--r-- 1 root root 0 Dec 28 14:28 smtpd.conf~
-- content of /usr/lib/sasl2/smtpd.conf --
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
-- content of /usr/local/lib/sasl2/smtpd.conf --
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
-- active services in /etc/postfix/master.cf --
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
smtp inet n - n - - smtpd -v
pickup fifo n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
-o fallback_relay=
-o smtp_generic_maps=
showq unix n - n - - showq
error unix - - n - - error
discard unix - - n - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache
maildrop unix - n n - - pipe
flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
old-cyrus unix - n n - - pipe
flags=R user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -m ${extension} ${user}
cyrus unix - n n - - pipe
user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -r ${sender} -m ${extension} ${user}
uucp unix - n n - - pipe
flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail unix - n n - - pipe
flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix - n n - - pipe
flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient
smtp-amavis unix - - y - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20
127.0.0.1:10025 inet n - y - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks_style=host
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
-- mechanisms on localhost --
250-AUTH GSSAPI DIGEST-MD5 PLAIN OTP CRAM-MD5
250-AUTH=GSSAPI DIGEST-MD5 PLAIN OTP CRAM-MD5
-- end of saslfinger output --
----- Original Message ----
From: "cyrus-sasl-request at lists.andrew.cmu.edu" <cyrus-sasl-request at lists.andrew.cmu.edu>
To: cyrus-sasl at lists.andrew.cmu.edu
Sent: Thursday, January 4, 2007 1:04:44 AM
Subject: Cyrus-sasl Digest, Vol 18, Issue 4
Send Cyrus-sasl mailing list submissions to
cyrus-sasl at lists.andrew.cmu.edu
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.andrew.cmu.edu/mailman/listinfo/cyrus-sasl
or, via email, send a message with subject or body 'help' to
cyrus-sasl-request at lists.andrew.cmu.edu
You can reach the person managing the list at
cyrus-sasl-owner at lists.andrew.cmu.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cyrus-sasl digest..."
Today's Topics:
1. Re: Authentication with saslauthd (Andreas Winkelmann)
2. Re: Multiple-Mechanism Sample Code? (Andreas Winkelmann)
3. Re: Multiple-Mechanism Sample Code? (Dave Cridland)
4. Re: Multiple-Mechanism Sample Code? (Andreas Winkelmann)
5. Re: Multiple-Mechanism Sample Code? (Dave Cridland)
6. Re: Multiple-Mechanism Sample Code? (Dave Cridland)
----------------------------------------------------------------------
Message: 1
Date: Wed, 3 Jan 2007 20:42:54 +0100
From: Andreas Winkelmann <ml at awinkelmann.de>
Subject: Re: Authentication with saslauthd
To: cyrus-sasl at lists.andrew.cmu.edu
Message-ID: <200701032042.54410.ml at awinkelmann.de>
Content-Type: text/plain; charset="utf-8"
On Wednesday 03 January 2007 20:22, Tiron Adrian wrote:
> Now i get the following in /var/log/maillog
>
> Jan 3 21:17:34 localhost postfix/smtpd[3435]: warning: SASL authentication
> failure: Password verification failed Jan 3 21:17:34 localhost
> postfix/smtpd[3435]: warning: localhost.localdomain[127.0.0.1]: SASL PLAIN
> authentication fa iled: authentication failure Jan 3 21:17:34 localhost
> postfix/smtpd[3435]: > localhost.localdomain[127.0.0.1]: 535 5.7.0 Error:
> authentication fai led: authentication failure
>
> I'm sure the user and pass is correct. It works when i use it with
> testsaslauthd. What else do you think it could be? Thanks!
Stop saslauthd and start it again with an additional -d in a Shell.
# saslauthd -d -a .... ....
Try to Authenticate with testsaslauthd and with your Mailclient. Compare the
Output.
--
Andreas
------------------------------
Message: 2
Date: Wed, 3 Jan 2007 21:04:56 +0100
From: Andreas Winkelmann <ml at awinkelmann.de>
Subject: Re: Multiple-Mechanism Sample Code?
To: cyrus-sasl at lists.andrew.cmu.edu
Message-ID: <200701032104.56308.ml at awinkelmann.de>
Content-Type: text/plain; charset="iso-8859-1"
On Monday 18 December 2006 23:12, Alexey Melnikov 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.
This is ok and already implemented.
> 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.
No, I would say this is a Security Risk and of course useless.
If the Server offers DIGEST-MD5 and PLAIN. And the User/Client trys wrong
Credentials, the Second try will pass in Cleartext the Internet. I would not
like to see that if I just make a Typo in the Password, you?
Oh and useless, because why should there be a difference between one of the
Offered Mechanisms? If DIGEST-MD5 with one set of Credentials fails, why
should it succeed with PLAIN? This is only the case with misconfigured
Servers (Offering *-MD5 Mechanisms with saslauthd for example).
> 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.
--
Andreas
------------------------------
Message: 3
Date: Wed, 03 Jan 2007 20:23:41 +0000
From: Dave Cridland <dave at cridland.net>
Subject: Re: Multiple-Mechanism Sample Code?
To: Andreas Winkelmann <ml at awinkelmann.de>
Cc: Discussion list for the Cyrus SASL library
<cyrus-sasl at lists.andrew.cmu.edu>
Message-ID: <6991.1167855822.092862 at peirce.dave.cridland.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
On Wed Jan 3 20:04:56 2007, Andreas Winkelmann wrote:
> On Monday 18 December 2006 23:12, Alexey Melnikov wrote:
> > 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.
>
> No, I would say this is a Security Risk and of course useless.
>
>
Almost...
> If the Server offers DIGEST-MD5 and PLAIN. And the User/Client trys
> wrong Credentials, the Second try will pass in Cleartext the
> Internet. I would not like to see that if I just make a Typo in the
> Password, you?
>
>
Well, the client really ought to be warning about this, and checking
with the user. Of course, this might need a new API/callback for
Cyrus SASL, I can't recall. (All my Cyrus SASL usage is on the
server, my client usage uses its own library, which does do warnings).
> Oh and useless, because why should there be a difference between
> one of the Offered Mechanisms? If DIGEST-MD5 with one set of
> Credentials fails, why should it succeed with PLAIN? This is only
> the case with misconfigured Servers (Offering *-MD5 Mechanisms with
> saslauthd for example).
>
Ah... No, there's the transition case. For ACAP, for example, the
attempt to authenticate with DIGEST-MD5 might yield a
TRANSITION-NEEDED, but (all?) other protocols won't communicate that
back to the client, so it's reasonable to try PLAIN.
PLAIN might work because SASL can pass the credentials onto the
operating system's authentication method, whereas DIGEST-MD5 needs
either a copy of the plaintext, or the intemediate hash, in which
case that's per-user, not per-site. The simplest way of getting the
data needed is to get the user to authenticate once using PLAIN,
after which DIGEST-MD5 works.
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
------------------------------
Message: 4
Date: Wed, 3 Jan 2007 22:18:35 +0100
From: Andreas Winkelmann <ml at awinkelmann.de>
Subject: Re: Multiple-Mechanism Sample Code?
To: cyrus-sasl at lists.andrew.cmu.edu
Message-ID: <200701032218.35134.ml at awinkelmann.de>
Content-Type: text/plain; charset="iso-8859-1"
On Wednesday 03 January 2007 21:23, Dave Cridland wrote:
> > If the Server offers DIGEST-MD5 and PLAIN. And the User/Client trys
> > wrong Credentials, the Second try will pass in Cleartext the
> > Internet. I would not like to see that if I just make a Typo in the
> > Password, you?
>
> Well, the client really ought to be warning about this, and checking
> with the user. Of course, this might need a new API/callback for
> Cyrus SASL, I can't recall. (All my Cyrus SASL usage is on the
> server, my client usage uses its own library, which does do warnings).
Hmm, ok, you have a Server, which does only allow Plaintext-Passwords with
SSL/TLS and Shared-Secret Mechanisms without SSL/TLS. The Client connects
without TLS and trys DIGEST-MD5, it fails. What shall happen? Cyrus-SASL
cannot switch to PLAIN without a heavy Interaction with the
Server-Application. At least it has to establish a SSL/TLS-Layer to enable
Plaintext-Passwords in the Authentification-Phase. I don't think this
hypothetical Situation is a rare exception.
> > Oh and useless, because why should there be a difference between
> > one of the Offered Mechanisms? If DIGEST-MD5 with one set of
> > Credentials fails, why should it succeed with PLAIN? This is only
> > the case with misconfigured Servers (Offering *-MD5 Mechanisms with
> > saslauthd for example).
>
> Ah... No, there's the transition case. For ACAP, for example, the
> attempt to authenticate with DIGEST-MD5 might yield a
> TRANSITION-NEEDED, but (all?) other protocols won't communicate that
> back to the client, so it's reasonable to try PLAIN.
>
> PLAIN might work because SASL can pass the credentials onto the
> operating system's authentication method, whereas DIGEST-MD5 needs
> either a copy of the plaintext, or the intemediate hash, in which
> case that's per-user, not per-site. The simplest way of getting the
> data needed is to get the user to authenticate once using PLAIN,
> after which DIGEST-MD5 works.
I don't know ACAP so good to see this relation, but this sounds like the
Cyrus-SASL auto_transition Feature. To "convert" a Crypted Password Storage
(shadow/passwd/...) to an UnEncrypted (auxprop) you enable auto_transition
and waits until all Accounts/Passwords are created in auxprop. In this Phase
you run with Plaintext-Passwords only (mech_list: plain login) though it
would be possible to use *-MD5 Mechanisms for the already created Accounts.
BTW, a failed Authentification with right Credentials has always a bad taste.
Looks like a Trojan Horse at the first sight.
--
Andreas
------------------------------
Message: 5
Date: Wed, 03 Jan 2007 23:03:25 +0000
From: Dave Cridland <dave at cridland.net>
Subject: Re: Multiple-Mechanism Sample Code?
To: Andreas Winkelmann <ml at awinkelmann.de>
Cc: Discussion list for the Cyrus SASL library
<cyrus-sasl at lists.andrew.cmu.edu>
Message-ID: <6991.1167865406.828686 at peirce.dave.cridland.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
On Wed Jan 3 21:18:35 2007, Andreas Winkelmann wrote:
> On Wednesday 03 January 2007 21:23, Dave Cridland wrote:
>
> > > If the Server offers DIGEST-MD5 and PLAIN. And the User/Client
> trys
> > > wrong Credentials, the Second try will pass in Cleartext the
> > > Internet. I would not like to see that if I just make a Typo in
> the
> > > Password, you?
> >
> > Well, the client really ought to be warning about this, and
> checking
> > with the user. Of course, this might need a new API/callback for
> > Cyrus SASL, I can't recall. (All my Cyrus SASL usage is on the
> > server, my client usage uses its own library, which does do
> warnings).
>
> Hmm, ok, you have a Server, which does only allow
> Plaintext-Passwords with SSL/TLS and Shared-Secret Mechanisms
> without SSL/TLS. The Client connects without TLS and trys
> DIGEST-MD5, it fails. What shall happen? Cyrus-SASL cannot switch
> to PLAIN without a heavy Interaction with the Server-Application.
> At least it has to establish a SSL/TLS-Layer to enable
> Plaintext-Passwords in the Authentification-Phase. I don't think
> this hypothetical Situation is a rare exception.
>
>
No, and it's not very hard, either. The client application then
receives the transition request, and assuming the user accepts,
negotiates TLS, and reauthenticates with PLAIN.
> > > Oh and useless, because why should there be a difference between
> > > one of the Offered Mechanisms? If DIGEST-MD5 with one set of
> > > Credentials fails, why should it succeed with PLAIN? This is
> only
> > > the case with misconfigured Servers (Offering *-MD5 Mechanisms
> with
> > > saslauthd for example).
> >
> > Ah... No, there's the transition case. For ACAP, for example, the
> > attempt to authenticate with DIGEST-MD5 might yield a
> > TRANSITION-NEEDED, but (all?) other protocols won't communicate
> that
> > back to the client, so it's reasonable to try PLAIN.
> >
> > PLAIN might work because SASL can pass the credentials onto the
> > operating system's authentication method, whereas DIGEST-MD5 needs
> > either a copy of the plaintext, or the intemediate hash, in which
> > case that's per-user, not per-site. The simplest way of getting
> the
> > data needed is to get the user to authenticate once using PLAIN,
> > after which DIGEST-MD5 works.
>
> I don't know ACAP so good to see this relation, but this sounds
> like the Cyrus-SASL auto_transition Feature. To "convert" a Crypted
> Password Storage (shadow/passwd/...) to an UnEncrypted (auxprop)
> you enable auto_transition and waits until all Accounts/Passwords
> are created in auxprop. In this Phase you run with
> Plaintext-Passwords only (mech_list: plain login) though it would
> be possible to use *-MD5 Mechanisms for the already created
> Accounts.
>
>
Exactly - Cyrus SASL tells the server, and the server can tell the
client via the application level protocol. ACAP happens to be an
example of a protocol which allows this, whereas IMAP does not.
> BTW, a failed Authentification with right Credentials has always a
> bad taste. Looks like a Trojan Horse at the first sight.
No, it's not a matter of the right or wrong credentials, it's a
matter of the credentials not being validatable.
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
------------------------------
Message: 6
Date: Wed, 03 Jan 2007 23:03:27 +0000
From: Dave Cridland <dave at cridland.net>
Subject: Re: Multiple-Mechanism Sample Code?
To: "Henry B\. Hotz" <hotz at jpl.nasa.gov>
Cc: Discussion list for the Cyrus SASL library
<cyrus-sasl at lists.andrew.cmu.edu>, Alexey Melnikov
<alexey.melnikov at isode.com>
Message-ID: <6991.1167865407.620288 at peirce.dave.cridland.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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
------------------------------
_______________________________________________
Cyrus-sasl mailing list
Cyrus-sasl at lists.andrew.cmu.edu
https://lists.andrew.cmu.edu/mailman/listinfo/cyrus-sasl
End of Cyrus-sasl Digest, Vol 18, Issue 4
*****************************************
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.andrew.cmu.edu/mailman/private/cyrus-sasl/attachments/20070104/63c1b6d3/attachment-0001.html
More information about the Cyrus-sasl
mailing list