Thanks for the answer it's a little better....
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!
----- Original Message ----
From: "cyrus-sasl-request@xxxxxxxxxxxxxxxxxxxx" <cyrus-sasl-request@xxxxxxxxxxxxxxxxxxxx>
To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Sent: Wednesday, January 3, 2007 7:00:15 PM
Subject: Cyrus-sasl Digest, Vol 18, Issue 2
From: "cyrus-sasl-request@xxxxxxxxxxxxxxxxxxxx" <cyrus-sasl-request@xxxxxxxxxxxxxxxxxxxx>
To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Sent: Wednesday, January 3, 2007 7:00:15 PM
Subject: Cyrus-sasl Digest, Vol 18, Issue 2
Send Cyrus-sasl mailing list submissions to
cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
cyrus-sasl-owner@xxxxxxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cyrus-sasl digest..."
Today's Topics:
1. Re: Multiple-Mechanism Sample Code? (Henry B. Hotz)
2. Re: Multiple-Mechanism Sample Code? (Henry B. Hotz)
3. Re: Multiple-Mechanism Sample Code? (Ken Hornstein)
4. (no subject) (Tiron Adrian)
5. Re: (no subject) (Patrick Ben Koetter)
----------------------------------------------------------------------
Message: 1
Date: Tue, 2 Jan 2007 18:09:31 -0800
From: "Henry B. Hotz" <hotz@xxxxxxxxxxxx>
Subject: Re: Multiple-Mechanism Sample Code?
To: Dave Cridland <dave@xxxxxxxxxxxx>
Cc: Discussion list for the Cyrus SASL library
<cyrus-sasl@xxxxxxxxxxxxxxxxxxxx>, Alexey Melnikov
<alexey.melnikov@xxxxxxxxx>
Message-ID: <AF580985-CC64-45B5-B859-34492B71F95D@xxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
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
------------------------------
Message: 2
Date: Tue, 2 Jan 2007 18:50:49 -0800
From: "Henry B. Hotz" <hotz@xxxxxxxxxxxx>
Subject: Re: Multiple-Mechanism Sample Code?
To: Ken Hornstein <kenh@xxxxxxxxxxxxxxxx>
Cc: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Message-ID: <0754C074-7229-4DBD-9E74-6B9651C6C8A8@xxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On Dec 31, 2006, at 9:41 PM, Ken Hornstein wrote:
> Now, my suggestions? I think a SASL client should do the following:
>
> - Allow (and perhaps even enforce) the selection of a specific SASL
> mechanism.
Do you disagree with Simon's recommendation that a client should try
all mutually supported mechanisms before giving up?
> - If a mechanism is not specifically selected, pick the "best" one
> (I'm sure we could get into massive arguments about what the "best"
> mechanism is). You could use some intelligence here; if you don't
> have a Kerberos credential cache, for example, don't try GSSAPI.
Around here all users are in the central repository, but the
administrative accounts for services are local to the service. I was
envisioning "GSSAPI CRAM-MD5" as a back-door way of supporting two
different repositories.
> - If authentication fails with the chosen mechanism, error out and
> return the error text to the user.
Absolutely necessary. Of course the error you want is for the
mechanism that was supposed to work, and not for the ones that were
supposed to fail. ;-)
------
My own prejudices:
I think Cyrus SASL should take care of trying all the mutually
supported mechanisms. The client app programmer should never have to
tell the server what mechanism it's trying; that ought to be in the
"clientout" data returned by sasl_client_{start,step}(). The client
app programmer should never have to call sasl_client_start() a second
time to make the library try all of the mechanisms. SASL_INTERACT
should only be returned by sasl_client_start(), and never by
sasl_client_step(). The client app should not require any mechanism
selection configuration at all (except to exclude insecure mechanisms).
What I see in practice is that most (everything except MacOS X
ldapsearch?) applications make you select the specific, actual
mechanism on the client side. Nobody actually uses the mechanism
negotiation that the protocol provides. I think we're both touching
on reasons why: the library doesn't properly support it. Maybe the
protocol is inadequate to make it work reliably, but I would think
that trying all the possibilities SHOULD make it more reliable rather
than less.
------------------------------------------------------------------------
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
------------------------------
Message: 3
Date: Wed, 03 Jan 2007 00:44:27 -0500
From: Ken Hornstein <kenh@xxxxxxxxxxxxxxxx>
Subject: Re: Multiple-Mechanism Sample Code?
To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Message-ID: <200701030544.l035iSUX026092@xxxxxxxxxxxxxxxxxxxxxxx>
>> Now, my suggestions? I think a SASL client should do the following:
>>
>> - Allow (and perhaps even enforce) the selection of a specific SASL
>> mechanism.
>
>Do you disagree with Simon's recommendation that a client should try
>all mutually supported mechanisms before giving up?
In a perfect world ... no. In this world ... yes, I disagree.
#1 - You need mechanism-specific knowledge to do this right.
Otherwise you end up with things like prompting for a new password
when you get a GSSAPI failure. I'll give you a related example: I
had cases where the MacOS X-suppled ssh would "hang" for a long
time when someone would kinit and then ssh to a system that didn't
support GSSAPI. I wasn't able to debug it completely because the
user ended up being a flaming asshole, but my theory was that when
a credential cache appeared, the MacOS X ssh would always try GSSAPI
... and that was behaving badly in domains that didn't have Kerberos
support. Now, people are going to point out that ssh doesn't use
SASL, and that's certainly true ... I only bring it up to illustrate
that I can easily envision cases where you shouldn't attempt to use
GSSAPI, even if the server supports it.
#2 - If you try all of the mechanisms and they all fail ... what kind
of error message should you return to the user?
>Absolutely necessary. Of course the error you want is for the
>mechanism that was supposed to work, and not for the ones that were
>supposed to fail. ;-)
Right, and if you figure out how to determine _that_, let me know :-)
>What I see in practice is that most (everything except MacOS X
>ldapsearch?) applications make you select the specific, actual
>mechanism on the client side. Nobody actually uses the mechanism
>negotiation that the protocol provides.
Actually, in the code I've written I let mechanism negotiation happen by
default, but I let the user configure a specific mechanism if they want.
This seems to work reasonably well. But there's only one shot at
authentication.
>I think we're both touching
>on reasons why: the library doesn't properly support it. Maybe the
>protocol is inadequate to make it work reliably, but I would think
>that trying all the possibilities SHOULD make it more reliable rather
>than less.
The problem I see is that this would require the library to be able
to say, "Okay, now restart authentication with this mechanism". Perhaps
that wouldn't be hard. But ... and I hate harp on it, but it's very
important to me ... error reporting would be a real bitch if you
did that.
--Ken
------------------------------
Message: 4
Date: Wed, 3 Jan 2007 02:55:40 -0800 (PST)
From: Tiron Adrian <tiron_adrian@xxxxxxxxx>
Subject: (no subject)
To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Message-ID: <20070103105540.92237.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
Hello,
First of all i hope i've sent this mail where it should be. I have had some problems understanding the website.
Anyway i have installed postfix 2.3.5 compiled with cyrus-sasl 2.1.21 and i want to it to perform authentication with the unix database of users, however it tries using the /etc/sasldb2 file and i don't know why.
I'm running Fedora Core 4 and this is how my /usr/local/lib/sasl2/smtpd.conf looks like.
cat /usr/local/lib/sasl2/smtpd.conf
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
Any ideas?
Sorry for my english,i'm not a native speaker.
Thanks,
Adrian
__________________________________________________
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/20070103/33522f4c/attachment-0001.html
------------------------------
Message: 5
Date: Wed, 3 Jan 2007 13:13:54 +0100
From: Patrick Ben Koetter <p@xxxxxxxxxxxxxxxx>
Subject: Re: (no subject)
To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Message-ID: <20070103121354.GD15381@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8
* Tiron Adrian <tiron_adrian@xxxxxxxxx>:
> Hello,
> First of all i hope i've sent this mail where it should be. I have had some problems understanding the website.
>
> Anyway i have installed postfix 2.3.5 compiled with cyrus-sasl 2.1.21 and i
> want to it to perform authentication with the unix database of users,
> however it tries using the /etc/sasldb2 file and i don't know why. I'm
> running Fedora Core 4 and this is how my /usr/local/lib/sasl2/smtpd.conf
> looks like.
>
> cat /usr/local/lib/sasl2/smtpd.conf
ln -s /usr/local/lib/sasl2 /usr/lib/sasl2
--
The Book of Postfix
<http://www.postfix-book.com>
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
------------------------------
_______________________________________________
Cyrus-sasl mailing list
Cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
https://lists.andrew.cmu.edu/mailman/listinfo/cyrus-sasl
End of Cyrus-sasl Digest, Vol 18, Issue 2
*****************************************
cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
cyrus-sasl-owner@xxxxxxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cyrus-sasl digest..."
Today's Topics:
1. Re: Multiple-Mechanism Sample Code? (Henry B. Hotz)
2. Re: Multiple-Mechanism Sample Code? (Henry B. Hotz)
3. Re: Multiple-Mechanism Sample Code? (Ken Hornstein)
4. (no subject) (Tiron Adrian)
5. Re: (no subject) (Patrick Ben Koetter)
----------------------------------------------------------------------
Message: 1
Date: Tue, 2 Jan 2007 18:09:31 -0800
From: "Henry B. Hotz" <hotz@xxxxxxxxxxxx>
Subject: Re: Multiple-Mechanism Sample Code?
To: Dave Cridland <dave@xxxxxxxxxxxx>
Cc: Discussion list for the Cyrus SASL library
<cyrus-sasl@xxxxxxxxxxxxxxxxxxxx>, Alexey Melnikov
<alexey.melnikov@xxxxxxxxx>
Message-ID: <AF580985-CC64-45B5-B859-34492B71F95D@xxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
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
------------------------------
Message: 2
Date: Tue, 2 Jan 2007 18:50:49 -0800
From: "Henry B. Hotz" <hotz@xxxxxxxxxxxx>
Subject: Re: Multiple-Mechanism Sample Code?
To: Ken Hornstein <kenh@xxxxxxxxxxxxxxxx>
Cc: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Message-ID: <0754C074-7229-4DBD-9E74-6B9651C6C8A8@xxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On Dec 31, 2006, at 9:41 PM, Ken Hornstein wrote:
> Now, my suggestions? I think a SASL client should do the following:
>
> - Allow (and perhaps even enforce) the selection of a specific SASL
> mechanism.
Do you disagree with Simon's recommendation that a client should try
all mutually supported mechanisms before giving up?
> - If a mechanism is not specifically selected, pick the "best" one
> (I'm sure we could get into massive arguments about what the "best"
> mechanism is). You could use some intelligence here; if you don't
> have a Kerberos credential cache, for example, don't try GSSAPI.
Around here all users are in the central repository, but the
administrative accounts for services are local to the service. I was
envisioning "GSSAPI CRAM-MD5" as a back-door way of supporting two
different repositories.
> - If authentication fails with the chosen mechanism, error out and
> return the error text to the user.
Absolutely necessary. Of course the error you want is for the
mechanism that was supposed to work, and not for the ones that were
supposed to fail. ;-)
------
My own prejudices:
I think Cyrus SASL should take care of trying all the mutually
supported mechanisms. The client app programmer should never have to
tell the server what mechanism it's trying; that ought to be in the
"clientout" data returned by sasl_client_{start,step}(). The client
app programmer should never have to call sasl_client_start() a second
time to make the library try all of the mechanisms. SASL_INTERACT
should only be returned by sasl_client_start(), and never by
sasl_client_step(). The client app should not require any mechanism
selection configuration at all (except to exclude insecure mechanisms).
What I see in practice is that most (everything except MacOS X
ldapsearch?) applications make you select the specific, actual
mechanism on the client side. Nobody actually uses the mechanism
negotiation that the protocol provides. I think we're both touching
on reasons why: the library doesn't properly support it. Maybe the
protocol is inadequate to make it work reliably, but I would think
that trying all the possibilities SHOULD make it more reliable rather
than less.
------------------------------------------------------------------------
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
------------------------------
Message: 3
Date: Wed, 03 Jan 2007 00:44:27 -0500
From: Ken Hornstein <kenh@xxxxxxxxxxxxxxxx>
Subject: Re: Multiple-Mechanism Sample Code?
To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Message-ID: <200701030544.l035iSUX026092@xxxxxxxxxxxxxxxxxxxxxxx>
>> Now, my suggestions? I think a SASL client should do the following:
>>
>> - Allow (and perhaps even enforce) the selection of a specific SASL
>> mechanism.
>
>Do you disagree with Simon's recommendation that a client should try
>all mutually supported mechanisms before giving up?
In a perfect world ... no. In this world ... yes, I disagree.
#1 - You need mechanism-specific knowledge to do this right.
Otherwise you end up with things like prompting for a new password
when you get a GSSAPI failure. I'll give you a related example: I
had cases where the MacOS X-suppled ssh would "hang" for a long
time when someone would kinit and then ssh to a system that didn't
support GSSAPI. I wasn't able to debug it completely because the
user ended up being a flaming asshole, but my theory was that when
a credential cache appeared, the MacOS X ssh would always try GSSAPI
... and that was behaving badly in domains that didn't have Kerberos
support. Now, people are going to point out that ssh doesn't use
SASL, and that's certainly true ... I only bring it up to illustrate
that I can easily envision cases where you shouldn't attempt to use
GSSAPI, even if the server supports it.
#2 - If you try all of the mechanisms and they all fail ... what kind
of error message should you return to the user?
>Absolutely necessary. Of course the error you want is for the
>mechanism that was supposed to work, and not for the ones that were
>supposed to fail. ;-)
Right, and if you figure out how to determine _that_, let me know :-)
>What I see in practice is that most (everything except MacOS X
>ldapsearch?) applications make you select the specific, actual
>mechanism on the client side. Nobody actually uses the mechanism
>negotiation that the protocol provides.
Actually, in the code I've written I let mechanism negotiation happen by
default, but I let the user configure a specific mechanism if they want.
This seems to work reasonably well. But there's only one shot at
authentication.
>I think we're both touching
>on reasons why: the library doesn't properly support it. Maybe the
>protocol is inadequate to make it work reliably, but I would think
>that trying all the possibilities SHOULD make it more reliable rather
>than less.
The problem I see is that this would require the library to be able
to say, "Okay, now restart authentication with this mechanism". Perhaps
that wouldn't be hard. But ... and I hate harp on it, but it's very
important to me ... error reporting would be a real bitch if you
did that.
--Ken
------------------------------
Message: 4
Date: Wed, 3 Jan 2007 02:55:40 -0800 (PST)
From: Tiron Adrian <tiron_adrian@xxxxxxxxx>
Subject: (no subject)
To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Message-ID: <20070103105540.92237.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
Hello,
First of all i hope i've sent this mail where it should be. I have had some problems understanding the website.
Anyway i have installed postfix 2.3.5 compiled with cyrus-sasl 2.1.21 and i want to it to perform authentication with the unix database of users, however it tries using the /etc/sasldb2 file and i don't know why.
I'm running Fedora Core 4 and this is how my /usr/local/lib/sasl2/smtpd.conf looks like.
cat /usr/local/lib/sasl2/smtpd.conf
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
Any ideas?
Sorry for my english,i'm not a native speaker.
Thanks,
Adrian
__________________________________________________
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/20070103/33522f4c/attachment-0001.html
------------------------------
Message: 5
Date: Wed, 3 Jan 2007 13:13:54 +0100
From: Patrick Ben Koetter <p@xxxxxxxxxxxxxxxx>
Subject: Re: (no subject)
To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
Message-ID: <20070103121354.GD15381@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8
* Tiron Adrian <tiron_adrian@xxxxxxxxx>:
> Hello,
> First of all i hope i've sent this mail where it should be. I have had some problems understanding the website.
>
> Anyway i have installed postfix 2.3.5 compiled with cyrus-sasl 2.1.21 and i
> want to it to perform authentication with the unix database of users,
> however it tries using the /etc/sasldb2 file and i don't know why. I'm
> running Fedora Core 4 and this is how my /usr/local/lib/sasl2/smtpd.conf
> looks like.
>
> cat /usr/local/lib/sasl2/smtpd.conf
ln -s /usr/local/lib/sasl2 /usr/lib/sasl2
--
The Book of Postfix
<http://www.postfix-book.com>
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
------------------------------
_______________________________________________
Cyrus-sasl mailing list
Cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
https://lists.andrew.cmu.edu/mailman/listinfo/cyrus-sasl
End of Cyrus-sasl Digest, Vol 18, Issue 2
*****************************************
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
