An alternative to Cyrus SASL

Post by Petri Riihikallio
Hello again
I posted a few weeks ago a patch which adds SMTP AUTH to Postfix with
my alternative to Cyrus SASL. I got one follow-up, but no actual
feedback.
I can see from my httpd logs that the tarballs have been downloaded
quite a few times. I don't know who you are, but I do know you use
quite a variety of browsers: Mozilla, Safari, Konqeror et al. Nice to
see some variations on the otherwise quite boring stats: MSIE, MSIE...
Well, I am curious to hear from you: How did it go?
- Did the patch apply?
- Did the code compile?
- Did the program run?
- Did the authentication work?
I am working to make RSASL an independently compiled library. That is
going require libtool with friends. Then the patch required for
Postfix will be minimal. Meanwhile I am going to resubmit a patch
against Postfix 2.1 when it comes out.
If you missed my original post, the link to RSASL is
http://www.metis.fi/rsasl The published patch is still against
Postfix-2.0.16-20031231.

Would it help if after Postfix 2.1 there is a SASL plug-in protocol
interface? This would eliminate the need for patching Postfix.

Of course any reasonable protocol will do (I like the protocol as
described in in the SMTPD_POLICY_README file but am not married to
it). Anything that makes it easier to plug in SASL without poisoning
the rest of the code :-)

Wietse

Wietse

Petri Riihikallio

2004-02-07 01:02:54 UTC

--============_-1136006745==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Reposting this. Sorry, my MUA didn't notice the Reply-To for some reason.

Post by Wietse Venema
Would it help if after Postfix 2.1 there is a SASL plug-in protocol
interface? This would eliminate the need for patching Postfix.

Do you mean you are going to drop smtpd?_sasl_.* files altogether?
SASL would be an independent daemon that just checks the credentials!
That would definitely be a change from the current implementation.

That approach would have advantages: clear cut functional and
privilege separation. The SASL daemon could run outside a chroot jail
and have access to system passwords. Good!

There would be some difficulties:
- How would the server know what mechanisms to advertise in response to EHLO?
- Who would take care of base64 en/decoding?
- The protocol would end up being quite complicated. You would need
to pass back and forth binary protocol data to/from the client, and
out-of-band state and errors between Postfix and the SASL daemon.

Actually you would end up duplicating the Cyrus SASL API with a
remote procedure call equivalent. The Cyrus API for the server side
goes like:
1) initialize
2) get a list of mechanisms
3) start the mechanism that client selected
4) pass protocol data to/from client until success or error
5) clean up
With the different mechanisms there are variable number of rounds at #4.

I can't see any other viable protocol to achieve SMTP authentication.
Perhaps I am standing too close after studying Cyrus API for months
:o(

BTW: Would the SASL plug-in protocol interface handle the client side
(smtp$) as well?

Post by Wietse Venema
Of course any reasonable protocol will do (I like the protocol as
described in in the SMTPD_POLICY_README file but am not married to
it). Anything that makes it easier to plug in SASL without poisoning
the rest of the code :-)

<grumble>I took all the trouble to make my RSASL call compatible with
Cyrus SASL to ease interfacing with current Postfix. I am not
particularly fond of the Cyrus SASL API. It was no fun to write code
around it.</grumble>

My main design choices for RSASL were:
- run inside unprivileged smtpd, that is: there is no way to access
system passwords
- use Postfix maps to store the secrets, just to make the
configuration really simple

Building a separate SASL daemon would invalidate both :o(

I don't know how you feel about the smtpd?_sasl_.* code. If they are
going to stay around, my code would eventually need just a small
patch to smtpd_sasl_glue.c to provide one more callback to look up
the secret from a Postfix map. Oh, and the supporting patches to
mail_params.h and smtpd.c to define the map parameter. These patches
could be merged to base Postfix distribution, since they do not
interfere with Cyrus SASL or non-SASL operation.

The huge patch that changes just about everything was for the early
release only. It includes my whole SASL library, which is should be
turned into an independently compiled library. Then it would be just
linked in. The patch grew even more when I made up a new compile flag
(HAS_LIBCRYPTO) to keep my code out of lmtp and lmtpd. Then I had to
change most #ifdefs. The HAS_LIBCRYPTO will not be needed when done.

I attach a draft of the final modifications to Postfix sources. It is
a much less obtrusive patch :o) I hand edited it from the big patch,
so it may not actually apply. It is just to show what RSASL would
eventually require.
--
Cheers
Petri

GSM: +358 400 505 939
--============_-1136006745==_============
Content-Id: <a0602040bbc49e8e682ef@[192.168.0.2].0.0>
Content-Type: multipart/appledouble; boundary="============_-1136006745==_D============"

--============_-1136006745==_D============
Content-Transfer-Encoding: base64
Content-Type: application/applefile; name="%"
Content-Disposition: attachment; filename="%"
; modification-date="Sat, 7 Feb 2004 02:11:12 +0200"

AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAADAAAAPgAAABUAAAAJAAAAUwAAACAA
AAAIAAAAcwAAABBtaW5pLXJzYXNscGYuZGlmZi56aXAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAe3BcAHtwXAS20MAAe3Ecc=
--============_-1136006745==_D============
Content-Type: application/octet-stream; name="mini-rsaslpf.diff.zip"
Content-Disposition: attachment; filename="mini-rsaslpf.diff.zip"
Content-Transfer-Encoding: base64

UEsDBBQACAAIABMRRzAAAAAAAAAAAAAAAAARABAAbWluaS1yc2FzbHBmLmRpZmZVWAwA
hiwkQIYsJED1ARQAjVdtb9pIEP5MfsWIU1sgNmDzEiDqSYSQKg0BBPRa6XTybeyFuDG2
5bXT0Cj//WZ3bbCN6RVZxt6deXZ2Xp5ZW/Z6DaoJagDqA6hXoE6BBWbddChxGxvHeyBO
Y0tsx/BJQLas/sinCyfOarXa/+iWliSEa2qCfgFab9BsD/Q26M1m60xV1ZPApZvAhs/E
BdBB1wd4tbtcq81XTP+EBf1mX+lrbRADHFYO9ACf1TOAPyy6tl0K1+MbY3m/ml8by+Fy
Yoynw6vJuNRECfoS0sCFB89z4JkEBtuGvmUwwhyDuuTBoZcodHa+R/pruEgjzYfL5dfr
Ujml5hPGfniBZWyJz8op1ZwRiSoXia0wH0kAtZwZAs+6RKnUhnJmzOarZcYIRs0osMOd
4fmh7blox0lnSF3XI67n7rZeJGR/ZRBCsssz65fJJMTlvW6KYGdGcumTmSt9pZbIm5YG
Wn/QvMArmzdZ8WzCtPVBq3c6YTp6X+m0UgkjBzpJwthuCPx32PL3yH0yzK1lOPbWDnk2
iFzJyOTSRXgNTvjt/NR0EueT+gElzvYX8/TFpDLahktDTMEnlpde2w7G1XjxvQC3UuQg
vd2/UPROUz+4CId6fKidOKnEs284uR0ujfvhfKmIjEq/v+drEccmTBSBAk1+JZqT2Wg4
MRaj+SqlfjQoMBzPJLhx0w+LgHJJrBRldgyUC0MCdH4EJKvyCCoZzoPJoJ22azEeTu6P
0OLRPJgI8Gms8bfReL66nU2XxnS8+jpb3B1vuVAmv05BouRWvbmdrMYL49t8tljJNbIj
7/PJlOj/NitISzZORI/5IT13minSUqV7z4XPkQPYC3Rt0NQHnfZJzsgo8iYl2KMFWnfQ
0Qat/mn20Do9Reu2DqWhdTVFu9D2hSGQLWp6Fu22K7arIKE4FP+8KBS3LXlJ3vG/ylmZ
uug02WSgUeN3qMGcBmrEaACOt7HdRtJTEG7tBVvCg1eXog38YyGOmMALB2pH2clLJ24f
DfTlYRqxQQWeN3wZXGcDWG7OAzGfOC5wjRia82JWs/Ls2RbUIhfNtAzTc0PsGYoQ9APb
481HKXZiD33W66ac2Osrut5KnMh/AQ0jbD+yiu84i71JD+Xs2NAQOx1Kx9YkZvDClmRu
W/GLbGXcp5kBWXNyJOmciGeEaJ8vn6vwKuf5XWpxx3KXlvgSGEjxLN7XUNmyjfFMgweP
0apUBOBjPHaV8jAKH6mLPkW/upsBvGNlBbhZVREjlMcgrYIdhB5GxXuCyAfUgH0KiIiX
+Ct8BM6KWIiuVSkMu0TGyqzuLUT0qXdA22JVMSApo7CS1ngiiwIaL8X3xOVjP5Rwv7gy
CwN8kBMCvJT4CycrOVdW0VAHybzC7J/UW2enq3DOfRijVPZuV/+UKyX+LeGSrunvKmkR
i4REEdtRDiBvQB1GY3O563+QwM26Pt4lHjWwoPJRSFuBBky/TCYSl9/yuXkObzJwPHex
gEEUsKiqfTVhmtBgTUzK3RaZCEDrsHqkaCSXUbkQg0fyTMHF4GDxM8oYGhmjxXldP1FQ
yEr9FCvpekfRW1r+EDydGdhjJ1fD0Z0xmk1X428rcQQ+VLkIS2I0xi15ZH//g254FYQD
8Cq2ProyvizHC94YsR8U1aRStOKbEpf4HmUy+5QFQHL5XdXb5QoP89ey+3CKeDtxqmni
oUbLnGnQRd1u4iK8BIHgL2WI7dqhjceYn1TQC2frVxlqgD1Xy2gTFN0hpVDzqb4fbsRP
vIAKy1PQA89PH/XNSrlw7QGyoU9JiKnK41EWGZrAFh8i4eNHLPkEfI0l4iC4T017vQNy
KP6Qn1jh2SaCYf59xz7wTFvbmyiQJSK+yijmbllQJFJZ4XEpoa68W2Y+FrAgL8zoR4+F
+aWJy1taslMhKtuR/RCQYFeHL4we4BhyL3oBeQSLBcsWHUMsJFEFvkeIbeP3CsGKYt6W
epjvkY/kQJlAFcsdR6YwKgmtYg6jfuXo286KnVEqSbT8h0ByJry+Ha2Mm8nwEz/c3lUv
ZZ7BgSXEpm6z2493PsBdEks6w3eijYqbC/DQgHWMREdDs372H1BLBwigXyxeEwYAAM4P
AABQSwMECgAAAAAAZhFHMAAAAAAAAAAAAAAAAAkAEABfX01BQ09TWC9VWAwAIC0kQCAt
JED1AfUBUEsDBBQACAAIABMRRzAAAAAAAAAAAAAAAAAcABAAX19NQUNPU1gvLl9taW5p
LXJzYXNscGYuZGlmZlVYDACGLCRAhiwkQPUBFABjYBVjZ2BiwAQgMU4gNgJiBSg/CCQR
4hoREqSVnIFFDxgAAFBLBwgxaw3NIwAAAFIAAABQSwECFQMUAAgACAATEUcwoF8sXhMG
AADODwAAEQAMAAAAAAAAAABApIEAAAAAbWluaS1yc2FzbHBmLmRpZmZVWAgAhiwkQIYs
JEBQSwECFQMKAAAAAABmEUcwAAAAAAAAAAAAAAAACQAMAAAAAAAAAABA/UFiBgAAX19N
QUNPU1gvVVgIACAtJEAgLSRAUEsBAhUDFAAIAAgAExFHMDFrDc0jAAAAUgAAABwADAAA
AAAAAAAAQKSBmQYAAF9fTUFDT1NYLy5fbWluaS1yc2FzbHBmLmRpZmZVWAgAhiwkQIYs
JEBQSwUGAAAAAAMAAwDkAAAAFgcAAAAA
--============_-1136006745==_D============--
--============_-1136006745==_============--

Wietse Venema

2004-02-07 01:45:59 UTC

Post by Petri Riihikallio
Reposting this. Sorry, my MUA didn't notice the Reply-To for some reason.

Post by Wietse Venema
Would it help if after Postfix 2.1 there is a SASL plug-in protocol
interface? This would eliminate the need for patching Postfix.

Do you mean you are going to drop smtpd?_sasl_.* files altogether?
- How would the server know what mechanisms to advertise in response to EHLO?
- Who would take care of base64 en/decoding?
- The protocol would end up being quite complicated. You would need

There is no need for the MTA to understand anything at all about
SASL.

All that is needed is for the MTA to shuttle some strings between
the SMTP client and the SASL daemon. The MTA can be totally
ignorant of their meaning.

There's only one extra thing. Postfix needs to know the username
and auth method when authentication succeeds.

Post by Petri Riihikallio
Actually you would end up duplicating the Cyrus SASL API with a
remote procedure call equivalent.

Not quite. What I have in mind to change the Postfix SMTPD
into a transparent SASL proxy.

The idea comes from Plan 9. See http://cm.bell-labs.com/sys/doc/auth.html

Wietse

Tim B

2004-02-07 04:05:14 UTC

Post by Wietse Venema
Would it help if after Postfix 2.1 there is a SASL plug-in protocol
interface? This would eliminate the need for patching Postfix.

For me that would be a dream come true....

Petri Riihikallio

2004-02-07 15:21:24 UTC

Post by Petri Riihikallio
Actually you would end up duplicating the Cyrus SASL API with a
remote procedure call equivalent.

Not quite.

The Cyrus SASL API was designed to make SASL as protocol independent
as possible. GNU SASL has remarkably similar API for the very same
reason. I am unfamiliar with the Cryptix API, though. The idea behind
this decision was to provide a general library and let the protocol
specific server handle the protocol specific tasks.

Post by Wietse Venema
What I have in mind to change the Postfix SMTPD into a transparent SASL proxy.

That would require the SASL daemon to understand SMTP. The daemon
would need to generate the 250-AUTH line to the EHLO response and
prefix all intermediate responses with 334 for example. Not
impossible by any means, but a very different approach from the
current SASL interfaces.

As an example of problems to solve: How would the daemon know whether
to prefix the AUTH with 250 or 250- ? That's why the Cyrus API just
returns a list of mechanisms and lets the server formulate the
response. But that does not qualify as "transparently passing data".

Post by Wietse Venema
The idea comes from Plan 9. See http://cm.bell-labs.com/sys/doc/auth.html

An interesting paper indeed!

How closely do you plan to follow it? It would be possible to produce
a socket based equivalent of factotum.

If you include all the Plan 9 attributes, the daemon could be used as
a general purpose authentication service. All the different protocols
would need separate support modules, though. LDAP and ACAP need to
pass binary data as well.

The Plan 9 designers had the freedom to change everything else to
support the new design. Postfix needs to follow the SMTP AUTH specs
for compatibility.

On a vanilla Unix system we don't have the luxury of kernel level
protection of the secret data. Plan 9 designers invented "private"
and "noswap" flags to protect the secure store from debuggers and
other means of direct memory access. That's an example of the Plan 9
designers' freedom.

Post by Wietse Venema
There's only one extra thing. Postfix needs to know the username and
auth method when authentication succeeds.

The Plan 9 protocol "authinfo" command does just this.

All right. I'll stop my current work and wait for a draft of your
spec. I really look forward to see how you would design it. Meanwhile
I'll ponder on an RPC or socket equivalent of the current SASL APIs.
Postfix would still need the sasl_glue code, but the secrets would be
kept in a separate process.

This separate daemon thing does have one drawback. It makes it really
easy to build a daemon to authenticate against system passwords. The
system passwords are hashed, so the only possible mechanisms will be
PLAIN and LOGIN. That will mean a lot of cleartext system passwords
on the Internet in the future.

--
Cheers
Petri

GSM: +358 400 505 939

V***@morganstanley.com

2004-02-07 17:23:00 UTC

Post by Wietse Venema
What I have in mind to change the Postfix SMTPD into a transparent SASL
proxy.

Your intrepretation is too literal. The "smtpd" server can take care of
the SMTP response code rewriting. Chaging "250 " to "250-" is not too much
cost for getting SASL code out of the SMTP server.

--
Viktor.

Wietse Venema

2004-02-07 20:15:57 UTC

Post by Petri Riihikallio
Actually you would end up duplicating the Cyrus SASL API with a
remote procedure call equivalent.

Not quite.

The Cyrus SASL API was designed to make SASL as protocol independent
as possible.

There is no need to violate that.

Post by Wietse Venema
What I have in mind to change the Postfix SMTPD into a transparent SASL proxy.

That would require the SASL daemon to understand SMTP. The daemon

Do not take me too literally.

Postfix strips off the SMTP protocol, passes the payload to SASLD,
SASLD tells Postfix what to do next, Postfix encapsulates it in
SMTP protocol gunk and sends it to the client. So it is Postfix
that prepends 250- to the SASLD's method listing.

The SASL API is way too complicated for the trivial needs of Postfix.

Post by Wietse Venema
The idea comes from Plan 9. See http://cm.bell-labs.com/sys/doc/auth.html

An interesting paper indeed!
How closely do you plan to follow it? It would be possible to produce
a socket based equivalent of factotum.

As always, when I see an interesting idea then I change it for the
problem at hand. The factotem implementation goes a bit over the edge.

Wietse

Petri Riihikallio

2004-02-08 01:02:31 UTC

Post by Petri Riihikallio
That would require the SASL daemon to understand SMTP. The daemon

Do not take me too literally.

Sometimes you expect people to read your words _very_ literally :o)

I read the Plan 9 auth paper. In an example given a POP server wants
to start a conversation with the client. Factotum tells the server to
start with "+OK POP3 cxhxaxlxlxexnxgxe". The POP server would pass
that verbatim to the client and pass the client response back to
Factotum. I just combined your idea of transparent proxy with this
example.

Now I know better.

Post by Wietse Venema
The SASL API is way too complicated for the trivial needs of Postfix.

Whenever you have time to sit down and go through the whole process,
you will find that you are going to need the five steps I outlined

Post by Wietse Venema
1) initialize
2) get a list of mechanisms
3) start the mechanism that client selected
4) pass protocol data to/from client until success or error
5) clean up
With the different mechanisms there are variable number of rounds at #4.

That is the Cyrus|GNU SASL API. I don't think you can do it any simpler.

What you can do is simplify the argument lists a bit. The callbacks
are a real hassle, but there won't be any since the SASLD would be
responsible to look up the secrets in some datastore.

I am eager to see what you have in mind. I have given this matter a
lot of thought lately. Maybe I can give some constructive feedback. I
hope I am not too set in the current API frameset, though.

--
Cheers
Petri

GSM: +358 400 505 939

Wietse Venema

2004-02-08 03:03:58 UTC

Post by Wietse Venema
The SASL API is way too complicated for the trivial needs of Postfix.

Whenever you have time to sit down and go through the whole process,
you will find that you are going to need the five steps I outlined

Post by Wietse Venema
1) initialize
2) get a list of mechanisms

Hi there, SASLD, here are my service name and security policy
attributes. How would you like to authenticate today?

Post by Wietse Venema
3) start the mechanism that client selected
4) pass protocol data to/from client until success or error

Copy data from client to SASLD and back (stripping and adding SMTP
gunk) until either the client aborts or until the SASLD produces
a final answer.

Post by Wietse Venema
5) clean up

Hey, SASLD, have a nice day. Goodbye.

Post by Wietse Venema
With the different mechanisms there are variable number of rounds at #4.

That is the Cyrus|GNU SASL API. I don't think you can do it any simpler.

But it should not involve hundreds of lines of code.

Wietse

Post by Petri Riihikallio
What you can do is simplify the argument lists a bit. The callbacks
are a real hassle, but there won't be any since the SASLD would be
responsible to look up the secrets in some datastore.
I am eager to see what you have in mind. I have given this matter a
lot of thought lately. Maybe I can give some constructive feedback. I
hope I am not too set in the current API frameset, though.
--
Cheers
Petri
GSM: +358 400 505 939

Petri Riihikallio

2004-02-08 15:22:21 UTC

Post by Petri Riihikallio
1) initialize
2) get a list of mechanisms

Hi there, SASLD, here are my service name and security policy
attributes. How would you like to authenticate today?

sasl_server_init
sasl_server_new
sasl_listmech

Post by Petri Riihikallio
3) start the mechanism that client selected
4) pass protocol data to/from client until success or error

Copy data from client to SASLD and back (stripping and adding SMTP
gunk) until either the client aborts or until the SASLD produces
a final answer.

sasl_server_start(mech, &dataout)
while (SASL_CONTINUE) {
send(dataout)
recv(&datain)
sasl_server_step(datain, &dataout)
}

Post by Petri Riihikallio
5) clean up

Hey, SASLD, have a nice day. Goodbye.

sasl_dispose

This is the Cyrus API and therefore what smtpd_sasl_glue.c is all
about. Rest of the code is error checking and other housekeeping. The
few callbacks are quite short and simple. The ugliest parts are the
hacks to support Cyrus SASL API 1 and 2 in the same program.

I still feel you are going to duplicate the current SASL API with a
remote procedure call equivalent, as I wrote earlier. Funny that you
said "No" then.

Post by Petri Riihikallio
That is the Cyrus|GNU SASL API. I don't think you can do it any simpler.

But it should not involve hundreds of lines of code.

I wrote a test bed for the server side interface in 137 lines of code
including lots of error checking, comments, pretty formatting,
sockets interface and such.

I don't think the consumer side of the API is the problem. It is the
spaghetti that is hidden behind. Its configuration is error prone, as
noise on the list indicates.

Well, I never believed I would defend the Cyrus API! I have cursed it
for so many nights. I just try to avoid reinventing the wheel. GNU
folks ended up with basically the same API. Perhaps it is the most
natural one for the problem?

The idea of a separate process for authentication is still valid. It
is just a lot of work to get right. No such beast exists yet. It will
need access control, timeout control, resource limits, a
configuration system and all the different database back-ends. The
back-ends exist for Cyrus SASL, though. I am afraid we are talking
about hundreds of lines of code in any case. And we still need the
smtpd_sasl_glue.c equivalent to talk with SASLD.

Would SASLD be completely independent of Postfix, or should it be
controlled by master? Running inside Postfix would give SASLD a head
start: basic server functionality, configuration, controls and access
to Postfix tables.

--
Cheers
Petri

GSM: +358 400 505 939

Liviu Daia

2004-02-08 18:31:39 UTC

On 8 February 2004, Petri Riihikallio <***@metis.fi>
wrote:
[...]

Post by Petri Riihikallio
Well, I never believed I would defend the Cyrus API! I have cursed it
for so many nights. I just try to avoid reinventing the wheel. GNU
folks ended up with basically the same API. Perhaps it is the most
natural one for the problem?

[...]

Oh please. CMU people wrote Cyrus SASL, then they produced RFC
2222, essentially describing their own API. Then various other RFCs
(like 2251 LDAP v3, and 2554 SMTP AUTH) began referencing RFC 2222
as a standard for authentication. Then, some five years after RFC
2222, GNU SASL is started, implementing the same API. I'm sure that's
because GNU people recognized from the very beginning Cyrus SASL as
*the* masterpiece of the art of API design, the ultimate authentication
API humankind will ever need.

Regards,

Liviu Daia

--
Dr. Liviu Daia
Institute of Mathematics of the Romanian Academy

Wietse Venema

2004-02-08 19:19:07 UTC

Post by Petri Riihikallio
1) initialize
2) get a list of mechanisms

Hi there, SASLD, here are my service name and security policy
attributes. How would you like to authenticate today?

sasl_server_init
sasl_server_new
sasl_listmech

How about this:

Request:
request=mechanism_list
service_name=smtpd
security_policy=noplaintext noanonymous

Reply:
status=success
mechanism_list=CRAM-MD5 PLAIN

Notice how different this is from the SASL API.

Wietse

Petri Riihikallio

2004-02-08 20:41:01 UTC

Post by Liviu Daia
Oh please. CMU people wrote Cyrus SASL, then they produced RFC
2222, essentially describing their own API.

They are doing even better: they have produced
draft-newman-sasl-c-api-01, which chisels in stone every detail of
the current API.

--
Cheers
Petri

GSM: +358 400 505 939

Petri Riihikallio

2004-02-08 22:40:49 UTC

Post by Wietse Venema
request=mechanism_list
service_name=smtpd
security_policy=noplaintext noanonymous
status=success
mechanism_list=CRAM-MD5 PLAIN

Great! I am dying to see the rest of it!

My original goal was to make Postfix SMTP AUTH a no-brainer, like it
is in Exim, Courier-MTA, Exchange... I was trying to utilize the
existing pieces as much as possible. If you take it on your to-do
list, the result will be much better, no doubt about that.

I know 2.1 must be delivered first, so I'll try to hold my horses.

Post by Wietse Venema
Notice how different this is from the SASL API.

That is the protocol on the wire, not an API. When you get down to
rewrite smtpd_sasl_glue.c, you'll probably have a de-ja-vu experience
:o)

All right. SASLD will speak this new protocol. Then SASLD will most
probably convert the requests to Cyrus SASL calls. Cyrus SASL is
still the most widely used and tested library and already has all the
database back-ends. We better try to keep the conversion straight
forward.

--
Cheers
Petri

GSM: +358 400 505 939

Wietse Venema

2004-02-08 22:57:32 UTC

Postfix connects to SASLD.

Request:
request=mechanism_list
encoding=plain
service_name=smtpd
security_policy=noplaintext noanonymous

Reply:
status=success
encoding=plain
mechanism_list=CRAM-MD5 PLAIN

Post by Petri Riihikallio
Great! I am dying to see the rest of it!

Request:
request=start_authenticate
encoding=base64
response=response-base64stuff...

Reply:
status=failed
encoding=plain
reason=whatever

Reply:
status=continue
encoding=base64
challenge=challenge-base64stuff...

Request:
request=continue_authenticate
encoding=base64
response=response-base64stuff...

Reply:
status=success
encoding=plain
method=PLAIN
username=foobar

And after serving a number of clients Postfix disconnects from SASLD.

Post by Petri Riihikallio
My original goal was to make Postfix SMTP AUTH a no-brainer, like it
is in Exim, Courier-MTA, Exchange... I was trying to utilize the
existing pieces as much as possible. If you take it on your to-do
list, the result will be much better, no doubt about that.
I know 2.1 must be delivered first, so I'll try to hold my horses.

Post by Wietse Venema
Notice how different this is from the SASL API.

That is the protocol on the wire, not an API. When you get down to
rewrite smtpd_sasl_glue.c, you'll probably have a de-ja-vu experience
:o)

It's going to be an order to magnitude less code.

Post by Petri Riihikallio
All right. SASLD will speak this new protocol. Then SASLD will most
probably convert the requests to Cyrus SASL calls. Cyrus SASL is
still the most widely used and tested library and already has all the
database back-ends. We better try to keep the conversion straight
forward.

The above isn't cast into stone but should give an idea.

Wietse

V***@morganstanley.com

2004-02-08 23:42:34 UTC

Post by Wietse Venema
The above isn't cast into stone but should give an idea.

A key benefit is that SASL support is no longer an "smtpd" patch, but
rather a "sasld" replacement. The "sasld" daemon can be an optional
software package, with the main Postfix package free of any SASL library
dependencies. People can experiment with alternative SASL implementations
without rebuilding SMTPD.

Presumably "sasld" will also handle the client side protocol for smtp(8).

--
Viktor.

Greg A. Woods

2004-02-09 01:38:17 UTC

[ On Sunday, February 8, 2004 at 22:40:31 (+0200), Petri Riihikallio wrote: ]

Subject: Re: An alternative to Cyrus SASL

Post by Liviu Daia
Oh please. CMU people wrote Cyrus SASL, then they produced RFC
2222, essentially describing their own API.

They are doing even better: they have produced
draft-newman-sasl-c-api-01, which chisels in stone every detail of
the current API.

That is the only way to make an API really portable and thus usable.

--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>

Brian Blood

2004-02-11 01:47:28 UTC

Post by Wietse Venema
The above isn't cast into stone but should give an idea.

A key benefit is that SASL support is no longer an "smtpd" patch, but
rather a "sasld" replacement. The "sasld" daemon can be an optional
software package, with the main Postfix package free of any SASL library
dependencies. People can experiment with alternative SASL implementations
without rebuilding SMTPD.
Presumably "sasld" will also handle the client side protocol for smtp(8).

I just don't understand the desire to keep SMTP AUTH out of Postfix.

Postfix is an SMTP server.
A well defined feature of SMTP is Authentication.

Postifx already provides mechanisms for doing lookups.

The code for supporting Auth mechs (PLAIN/LOGIN/CRAM-MD5/DIGEST-MD5/NLTM) is
not that complicated.

Have that code simply call the configured lookup to verify the result of the
negotiated credentials.

Put it DIRECTLY into Postfix and be done with it already.

The thinking seems to be:
"Let's make another layer, JUST BECAUSE WE CAN!!!!"

SMTP AUTH is not that complicated. Why make it so? This alternative does
nothing to decrease the complexity of trying to use Cyrus SASL. It's just
taking another form.

If someone can explain the incredible overriding benefit of this extra layer
compared to the complexity and added layer of version
management/compilation/configuration, etc. I'd really like to hear it.

My $0.02.

Brian

Roger B.A. Klorese

2004-02-11 01:51:00 UTC

Post by Brian Blood
SMTP AUTH is not that complicated. Why make it so? This
alternative does
nothing to decrease the complexity of trying to use Cyrus
SASL. It's just
taking another form.

It keeps it out of the address space of, and keeps it from compromising,
core Postfix processes.

V***@morganstanley.com

2004-02-11 01:56:32 UTC

Post by Brian Blood
I just don't understand the desire to keep SMTP AUTH out of Postfix.

Not out of "Postfix", but rather out of the source code of the Postfix
SMTP server. Postfix a modular system. Authentication belongs in its
own module. End of thread please. The tone is much to provocative...

--
Viktor.

Brian Blood

2004-02-11 03:07:50 UTC

Post by Roger B.A. Klorese

Post by Brian Blood
SMTP AUTH is not that complicated. Why make it so? This
alternative does
nothing to decrease the complexity of trying to use Cyrus
SASL. It's just
taking another form.

It keeps it out of the address space of, and keeps it from compromising,
core Postfix processes.

Huh?

If Postfix is running the code that handles AUTH communication and then
merely does a lookup (using any of the currently well established lookup
methods), how does that expose it to any more possible compromising
situations than doing a lookup for recipient domains might?

Your statement doesn't make any sense.

The SMTP AUTH part of the SMTP protocol/conversation doesn't do anything
more complicated than RCPT TO might.

Brian

(Please reply back to the list only, thank you.)

Brian Blood

2004-02-11 03:21:23 UTC

Post by Brian Blood
I just don't understand the desire to keep SMTP AUTH out of Postfix.

Not out of "Postfix", but rather out of the source code of the Postfix
SMTP server. Postfix a modular system.

Postfix has modules, but as a whole is not "modular".

The source code for determining what domains the mail server should accept
mail for is not "outside" of the Postfix SMTP server and is handled by
another system with it's own API. It's handled by a lookup.

Post by V***@morganstanley.com
Authentication belongs in its
own module.

Why is Authentication any less of a part of SMTP than any other part and as
such should be "outside"?

You make this statement so matter-of-factly, but don't give any reason to
back it up.

Post by V***@morganstanley.com
End of thread please.
The tone is much to provocative...

It's meant to be.
Someone around here needs to question original precepts.

You all are spending this energy discussing using this or that API or
whatever, why not cut out all the complexity for such a small amount of code
and drop it right into the SMTP server. It IS a part of SMTP, after all.

Take the code that Petri Riihikallio did with RSASL and integrate it in and
be done with it.

If you really wanted to have some external process do the "lookup", then add
a lookup of type "exec" that could be called with the necessary
parameters/configuration.

I guess my point is that you guys have decided the line (between "modules")
should be "here" and I'm saying it should be farther down the road "there".

Brian

V***@morganstanley.com

2004-02-11 04:22:33 UTC

Post by Brian Blood
Postfix has modules, but as a whole is not "modular".
The source code for determining what domains the mail server should accept
mail for is not "outside" of the Postfix SMTP server and is handled by
another system with it's own API. It's handled by a lookup.

Stop picking pointless fights (trolling) or you will be unsubscribed. If
you want to be taken seriously, contribute something useful to Postfix
first, and then argue about the design.

--
Viktor.

Brian Blood

2004-02-11 06:27:09 UTC

Stop picking pointless fights (trolling) or you will be unsubscribed.

You think it's pointless because you've made up your mind and anybody with
other ideas be damned. Nice attitude.

I don't think it's pointless because I believe it'd make things a lot
simpler and a lot easier.

Prove me wrong with rational discussion instead of heavy handed BOFH-type
threats.

Post by V***@morganstanley.com
If
you want to be taken seriously, contribute something useful to Postfix
first, and then argue about the design.

Was that in the Mailing List intro somewhere that I missed?

So, opinions and ideas about how something might be designed/changed for the
better are NOT considered contributing something useful?

Victor, I respect your contributions to Postfix, but this holier-than-thou
attitude I see in many of your posts makes it difficult to respect your
opinions.

Back to the question at hand....

A good portion of the trouble in setting up and using Postfix (and hence the
noise on this list) would go away if Postfix supported SMTP AUTH directly
without involving some other process/library and merely utilized lookups.

Other SMTP Servers seem to handle doing it directly in their code base
without too much trouble/security risks.

Brian

Bill Boebel

2004-02-11 14:30:01 UTC

It makes total sense to keep SMTP AUTH as a separate module, because high
volume MX servers that just do content filtering want Postfix to be as light
weight as possible. Leaving out the SMTP AUTH code on those servers is
preferred.

However, it would be very nice if the SMTP AUTH module was available as a
compile-time option (without patching) when compiling Postfix.

Bill Boebel

-----Original Message-----
From: owner-postfix-***@postfix.org
[mailto:owner-postfix-***@postfix.org]On Behalf Of Brian Blood
Sent: Tuesday, February 10, 2004 10:21 PM
To: postfix-***@postfix.org
Subject: Re: An alternative to Cyrus SASL

Post by Brian Blood
I just don't understand the desire to keep SMTP AUTH out of Postfix.

Not out of "Postfix", but rather out of the source code of the Postfix
SMTP server. Postfix a modular system.

Post by V***@morganstanley.com
Authentication belongs in its
own module.

Why is Authentication any less of a part of SMTP than any other part and as
such should be "outside"?

You make this statement so matter-of-factly, but don't give any reason to
back it up.

Post by V***@morganstanley.com
End of thread please.
The tone is much to provocative...

Lydiard

2004-02-11 14:46:41 UTC

Post by Bill Boebel
It makes total sense to keep SMTP AUTH as a separate module, because high
volume MX servers that just do content filtering want Postfix to be as light
weight as possible. Leaving out the SMTP AUTH code on those servers is
preferred.
However, it would be very nice if the SMTP AUTH module was available as a
compile-time option (without patching) when compiling Postfix.

I agree with that. It's fine the way it is for the Boffs (BOHFs??) of this
world, but us clueless halfwits would like it as simple as possible. Same goes
for the other modules actually. My first install left out the mysql packages
because I didn't know they weren't included..

A yes/no list in the install would be a dream (although Wietse's nightmare
probably).. Imagine:

Instal MySQL module? (y/n):
Instal SMTP AUTH module? (y/n):
etc

Lyd

Brian Blood

2004-02-11 15:31:46 UTC

Post by Lydiard

I agree with that. It's fine the way it is for the Boffs (BOHFs??) of this
world, but us clueless halfwits would like it as simple as possible. Same
goes
for the other modules actually. My first install left out the mysql packages
because I didn't know they weren't included..
A yes/no list in the install would be a dream (although Wietse's nightmare
etc

This is what is known as Conservation of Complexity.

Yes it's hard for the programmers, but guess what, you do the hard work ONCE
and it pays off big time the thousands of times down the road for people
installing and running the software.

(This has been a theme highlighted tremendously in Macintosh programming
circles. Not exclusively, of course.)

Brian

V***@morganstanley.com

2004-02-11 18:06:45 UTC

Post by Lydiard
I agree with that. It's fine the way it is for the Boffs (BOHFs??) of this
world, but us clueless halfwits would like it as simple as possible. Same
goes
for the other modules actually. My first install left out the mysql packages
because I didn't know they weren't included..
A yes/no list in the install would be a dream (although Wietse's nightmare
etc

This is called system integration and is performed by *system* vendors.
When you get Postfix from NetBSD, FreeBSD, RedHat or Debian or SuSE, it is
nicely packaged and integrated with all the other modules on the system.
That's why people pay the system vendors money to deliver integrated
systems.

The base Postfix software runs on many platforms and supports many
different versions, locations, include paths, library paths, etc.
It is not practical for Postfix to automatically locate all the available
components on all possible platforms.

When you build Postfix from source, *you* are the system integrator. When
you get a Postfix package from a system vendor they've done the job for
you.

Building a complete system out of separate open source software components
takes time and effort. This is not the fault of the component authors,
their efforts are best spent on building better components and allowing
the distribution maintainers to port the component to a wide variety of
platforms.

--
Viktor.

Liviu Daia

2004-02-11 18:28:59 UTC

Post by Brian Blood

Post by Brian Blood
Postfix has modules, but as a whole is not "modular".
The source code for determining what domains the mail server should
accept mail for is not "outside" of the Postfix SMTP server and
is handled by another system with it's own API. It's handled by a
lookup.

Stop picking pointless fights (trolling) or you will be
unsubscribed.

You think it's pointless because you've made up your mind and anybody
with other ideas be damned. Nice attitude.
I don't think it's pointless because I believe it'd make things a lot
simpler and a lot easier.
Prove me wrong with rational discussion instead of heavy handed
BOFH-type threats.

[...]

Moving the authentication code to a separate daemon would allow,
among other things, proxying and caching credentials without breaking
the existing security model. Search the archives for a thread with the
subject "sender-specific AUTH or relayhost" to find out why that would
be useful.

That said, neither Victor nor Wietse have to prove anything. *You*
have to prove your claim that their design choice is flawed. As Victor
points out, your claim would stand more chances to become credible if
you came up with working code.

Regards,

Liviu Daia

--
Dr. Liviu Daia
Institute of Mathematics of the Romanian Academy

Roger B.A. Klorese

2004-02-11 18:43:58 UTC

If Postfix is running the code that handles AUTH=20
communication and then
merely does a lookup (using any of the currently well=20
established lookup
methods), how does that expose it to any more possible compromising
situations than doing a lookup for recipient domains might?
=20
Your statement doesn't make any sense.

The SASL code itself is a complex pile of suspect code. There's no =
reason
to have it share the address space of a privileged process like smtpd.

Now, if you're talking about writing the equivalent of Cyrus SASL inline
using trusted competent authors, that seems like a waste of effort.

Nothing is lost keeping it external to smtpd, and lots gained -- =
development
focus, using non-compromising interfaces, the ability to tie in a future
security implementaiton that hasn't even been created simply be writing =
a
new shim daemon.

Deives Michellis

2004-02-11 19:06:32 UTC

--S5HS5MvDw4DmbRmb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Having an external lib that auth users is quite a good idea, in my humble o=
pinion. You let that lib handle as many plugins as one might want, still ke=
eping the SMTPd code clean.

Besides, there are many services out there that are able to use the SASL li=
brary to auth as well. That might lead to standarization of auth plugins.

Personally, I like cyrus-sasl LDAP, rimap, and many other auth plugins, whi=
ch I assume would not be the first to be developed if the auth code were in=
the same (very much capable, I must say) hands of our Postfix developer :)=
. So, ppl coding the SASL plugins do develop them because it's "their busin=
ess", which would not be for a MTA developer

well, just my 2 cents, as ppl use to say :)

Deives

---

One day console shall take over the whole universe and killall -9 the evil =
X apps.
- The Ancient Fellowship of the Shell

=20
Nothing is lost keeping it external to smtpd, and lots gained -- developm=

ent

focus, using non-compromising interfaces, the ability to tie in a future
security implementaiton that hasn't even been created simply be writing a
new shim daemon.
=20

--S5HS5MvDw4DmbRmb
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAKn2nMA+T+3OrNFkRAkMAAJ9byRE3G0mvqWVnlKF5gAfeaIZjRgCfTUo4
0iY4S9LTrpZOgOLqalJPQjs=
=i+Bl
-----END PGP SIGNATURE-----

--S5HS5MvDw4DmbRmb--

Petri Riihikallio

2004-02-11 21:33:51 UTC

Post by Brian Blood
The code for supporting Auth mechs (PLAIN/LOGIN/CRAM-MD5/DIGEST-MD5/NLTM) is
not that complicated.

Actually, it is a mess. The mechs are hundreds of lines of code that
is error prone and hard to understand. If you count in the digest
code, you'll end up in big numbers. All this has to be linked with
the smtp processes, either statically or at run time from a library,
it doesn't matter.

Post by Brian Blood
This alternative does nothing to decrease the complexity of trying
to use Cyrus SASL. It's just taking another form.

I agree on this. It does have its advantages, though. The SASLD way
separates the security sensitive code from the code that has an
interface to the Internet.

I trust Wietse to come up with a good solution. He has a good history
for such. I'm going to stand in line to try out the new way - and
I'll report back :o)

I started my RSASL project when there was no improvement in sight.
The SASL glue code had stayed the same since the support for Cyrus
SASL 2 was added. If my work has made some wheels turn it has served
its purpose.

--
Cheers
Petri

GSM: +358 400 505 939

Lydiard

2004-02-11 23:48:37 UTC

Post by Lydiard

Post by Lydiard
I agree with that. It's fine the way it is for the Boffs (BOHFs??) of

this

Post by Lydiard
world, but us clueless halfwits would like it as simple as possible.

Same

Post by Lydiard
goes
for the other modules actually. My first install left out the mysql

packages

Post by Lydiard
because I didn't know they weren't included..
A yes/no list in the install would be a dream (although Wietse's

nightmare

Post by Lydiard
etc

This is called system integration and is performed by *system* vendors.
When you get Postfix from NetBSD, FreeBSD, RedHat or Debian or SuSE, it is
nicely packaged and integrated with all the other modules on the system.
That's why people pay the system vendors money to deliver integrated
systems.
The base Postfix software runs on many platforms and supports many
different versions, locations, include paths, library paths, etc.
It is not practical for Postfix to automatically locate all the available
components on all possible platforms.
When you build Postfix from source, *you* are the system integrator. When
you get a Postfix package from a system vendor they've done the job for
you.
Building a complete system out of separate open source software components
takes time and effort. This is not the fault of the component authors,
their efforts are best spent on building better components and allowing
the distribution maintainers to port the component to a wide variety of
platforms.

You're right - but in that case it would be nice to have "dumbed down" howtos.
Why is it most howtos explain what to do - but not WHY you're doing it? How's
a newbie supposed to learn??

Lyd

V***@morganstanley.com

2004-02-12 00:32:10 UTC

Post by Lydiard
You're right - but in that case it would be nice to have "dumbed down" howtos.
Why is it most howtos explain what to do - but not WHY you're doing it? How's
a newbie supposed to learn??

Actually HOWTO documents that explain "why" are for the sophisticated
newbies. The really dumb newbies won't understand the reasons which will
just confuse them. They need more detailed, less error-prone HOWTO
documents.

This said, I do think that good HOWTO documents for new users who are not
complete novices at everything should try to explain more of the why. Some
of this should be covered in books. We have one new book and soon
hopefully another...

--
Viktor.

Ejvind, Kristian

2004-02-12 11:39:23 UTC

Post by Bill Boebel
-----Original Message-----
Stop picking pointless fights (trolling) or you will be=20
unsubscribed. If
you want to be taken seriously, contribute something useful to Postfix
first, and then argue about the design.

Uh-oh... does this mean that anyone that expresses an opinion different
to the list maintainers will be cast out from here?

And, Victor, do you really mean that anyone who hasn't contributed
source code to Postfix can't have valuable experience and opinions?

Regards
Kristian=20

l***@kwsoft.de

2004-02-12 12:40:46 UTC

Post by Ejvind, Kristian
=20

Post by Bill Boebel
-----Original Message-----
Stop picking pointless fights (trolling) or you will be=20
unsubscribed. If
you want to be taken seriously, contribute something useful to Postfi=

Post by Ejvind, Kristian

Post by Bill Boebel
first, and then argue about the design.

=20
=20
Uh-oh... does this mean that anyone that expresses an opinion different
to the list maintainers will be cast out from here?
=20
And, Victor, do you really mean that anyone who hasn't contributed
source code to Postfix can't have valuable experience and opinions?

What would you say if someone rushes through the door say "you silly moro=
ns i
have found the only valid truth let's do it my way". Not the opinion is a
offense but the wording.

I found the reaction really polite compared to the statements lead to thi=
s.

Regards

Andreas

Greg A. Woods

2004-02-12 21:42:34 UTC

Subject: RE: An alternative to Cyrus SASL
What would you say if someone rushes through the door say "you silly morons i
have found the only valid truth let's do it my way". Not the opinion is a
offense but the wording.

Yes, but that's not even remotely what the guy did.

He raised some very valid and very important technical points!

--
Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <***@robohack.ca>
Planix, Inc. <***@planix.com> Secrets of the Weird <***@weird.com>

l***@kwsoft.de

2004-02-13 10:52:56 UTC

Post by Greg A. Woods
wrote: ]

Subject: RE: An alternative to Cyrus SASL
What would you say if someone rushes through the door say "you silly =

morons

Post by Greg A. Woods
i

have found the only valid truth let's do it my way". Not the opinion =

is a

Post by Greg A. Woods

offense but the wording.

=20
Yes, but that's not even remotely what the guy did.=20
=20
He raised some very valid and very important technical points!

He raised it in CAPS letter and a sarcastic tone....

If his opinion about that is valid or not is beyond my skills.

Regards

Andreas

Ron Wheeler

2004-02-14 07:09:21 UTC