OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Andreas Piesk (a.pieskgmx.net)
Date: Wed Apr 24 2002 - 16:21:27 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Wednesday, April 24, 2002, 7:31:07 PM, David Wright wrote:

    i use your reply for my summary. of course i read ALL replies,
    but this one reflects my own thoughts most. and please excuse my bad
    English.

    > 1) SASL supports challenge-response authentication. Challenge-response
    > authentication methods work by having the server send some text across the
    > wire, which the client then hashes using his password as salt before
    > sending back. The server does the hash, too, and autheticates the user if
    > the hashed text is the same. Notice that the password itself never crosses
    > the wire in the scenario. While this is a cute idea, it's really
    > unnecessary if you use SSL or TLS to encrypt the connection anyway, and it
    > has the downside that the sever must store the password in cleartext (i.e.
    > no passwd or shadow). For me, using TLS and the cleartext storage has made
    > challenge-response uninteresting, but I'm sure there are people out there
    > who use it.

    the first time i used SASL i thought, CRAM-MD5 is a good thing. it is in
    fact, but i prefer plain authentication using pam with TLS too. the passwords
    aren't stored as cleartext and you transmit all data through an encrypted
    tunnel. the last COULD be an requirement in my case.

    > 2) SASL supports Kerberos ticket passing. I don't use Kerberos, so I'm
    > sort of shooting from the hip here, but I imagine this is a big plus for
    > SASL. It is persumably possible to get this functionality by using libkrb5
    > in addition to libpam, but I don't know how hard that is.

    ok, i don't use kerberos nor i plan to do so. but i know, pam has a
    kerberos module.

    > 3) PAM isn't cross-platform. PAM works on Linux and Solaris, but I believe
    > it's not a standard on the BSDs or HP-UX or AIX. So using PAM would limit
    > Postfix's portability.

    good point and a big minus to pam. i have to do some research on
    which platforms pam and sasl are available and compare the results.
    but i don't want replace sasl, i think about adding pam functionality,
    so that on platforms, where no pam support is available, you can use
    sasl. another nice guy said this could lead to code bloat and, because
    of the #ifdefs, the code would be more and more unreadable. in general
    i agree with him, but for now i don't know how big the impact on the
    existing code will be, so i cannot judge.

    > 4) SASL and PAM libraries are, in my experience, about equally easy to
    > program to, but SASL is much harder to administer. The first thing I do
    > when faced with an SASL program is make it use PAM and go from there.

    speaking of authorization only, programming pam is a lot easier IMHO.
    you describe exactly what is itching me: the use of sasl just as a wrapper
    for PAM.

    > 5) SASL has a nasty re-entancy problem which can cause problems when used
    > with PAM. For example, if you use pam_ldap and the OpenLDAP libraries, you
    > run into this problem because the SASL routines get called by your program
    > and again by the OpenLDAP libraries, resulting in a double-free bug. The
    > SASL2 solution to this problem is to always require you to use a password
    > daemon, but in my opinion the SASL people play way to fast a loose with
    > passwords on the server, and none of the password daemons out there
    > convince me they are really careful about security. You can also get
    > around the re-entrancy problem by hacking the code (which is what I have
    > done).

    i'm using saslauthd as authentication daemon. but i this setup

    postfix->sasl->saslauthd->pam->pwdfile

    is just too complicated IMHO. too many links in the chain.

    > If there were a PAM-only version of Postfix available I would use it, but
    > since I have managed to get SASL to use PAM in the way I want, I wouldn't
    > take the time to write one.

    darn, i hoped to convince someone to do the real work :)

    > If Witense wants to get away from SASL in the future, I would endorse
    > that move and recommend PAM, but I certainly see why some people would
    > object to such direction.

    his name is Wietse ;) as PAM is probably not available on all
    platforms which postfix supports, i wouldn't recommend to drop sasl.
    here i repeat myself :), i think about adding pam, not replacing sasl.

    thanks to all who replied, i really appreciate the opinions and
    thoughts. but feel free to post more :)

    david, can i contact you if i have problems/questions regarding pam
    programming? i promise not to bother too much :)

    ciao -ap

    -
    To unsubscribe, send mail to majordomopostfix.org with content
    (not subject): unsubscribe postfix-users