Subject: saslauthd question

From: Gopal Tadeparti <[email-masked]>
Date: Mon, 25 Feb 2002 10:16:45 -0600

I'm new to SASL. I want to set up cyrus IMAP server and use SASLv2 for
authentication.

I compiled SASLv2 with saslauthd option and installed it on solaris 5.7.
When I try to start saslauthd with the following command
>/usr/local/sbin/saslauthd -a shadow
It gives the following error
"saslauthd: /var/state/saslauthd: Not a directory"

I don't know why saslauthd is looking in /var/state/ directory. I never set
this in configuration. Please help me.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 25 Feb 2002 11:52:26 -0800

Please note that the lists you have posted are discussing
IETF engineering work.  Please direct questions specific to
particular implementations of IETF protocols to forums
supporting those implementations.

The CMU Cyrus SASL implementation is support by the
<[email-masked]> mailing list.

Thanks, Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 25 Feb 2002 11:52:26 -0800

Thanks, Kurt

Date: Mon, 25 Feb 2002 11:52:26 -0800
To: Gopal Tadeparti <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: saslauthd question
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Thanks, Kurt

From: Gopal Tadeparti <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: saslauthd question
Date: Mon, 25 Feb 2002 10:16:45 -0600
Sender: [email-masked]

From: Gopal Tadeparti <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Not able to start saslauthd
Date: Mon, 25 Feb 2002 10:09:59 -0600
Sender: [email-masked]

I don't know why saslauthd is looking for another saslauthd binary in
/var/state/ directory. I never set this in configuration. Please help me.

From: "Bruce Pennypacker" <[email-masked]>
To: <[email-masked]>
Subject: Sendmail-8.12.1 & Cyrus-1.5.27 AUTH problem with MD5 AUTH
Date: Sun, 17 Feb 2002 13:07:51 -0500
Sender: [email-masked]

Hi all,

I've been running sendmail 8.12.1 on RedHat Linux 7.1 successfully for quite
some time now and decided to try to get SMTP AUTH working.  I installed
Cyrus 1.5.27, rebuilt, and configured sendmail as shown at
http://www.sendmail.org/~ca/email/auth.html and managed to get it working at
a limited extent, however when I issue an ehlo it only shows LOGIN and PLAIN
as the authentication methods (I built Cyrus with --enable-login for testing
purposes).  I'm unable to get it to list DIGEST-MD5, CRAM-MD5, etc. as
authentication methods.

Here's a rundown of what I did:

- build Cyrus with --enable-login and no other options (I verified that
digest & cram are enabled by default)

- Added the following to sendmail/devtools/Site/site.config.m4 & rebuilt
sendmail:

APPENDDEF(`confENVDEF', `-DSASL')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl')
APPENDDEF(`confLIBDIRS', `-L/usr/lib/sasl')
APPENDDEF(`confINCDIRS', `-I/usr/include')

- Added the following to my sendmail.mc & rebuilt sendmail.cf

define(`confDEF_AUTH_INFO', `/etc/mail/auth/default-auth-info')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5
CRAM-MD5')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`Port=587, Name=MSA, M=Ea')dnl
ESASL_PATH=/usr/lib/sasl

- Created a dummy /etc/mail/auth/default-auth-info and set it to be readable
by root only

- Created /etc/sasldb via saslpasswd and set it to be readable by root only.
sasldblistusers lists the accounts I've created with both CRAM-MD5 &
DIGEST-MD5:

user: test realm: localhost mech: PLAIN
user: test realm: localhost mech: CRAM-MD5
user: test realm: localhost mech: DIGEST-MD5

After doing all  the above & running sendmail I get the following response
to ehlo:

250-localhost Hello IDENT:[email-masked] [127.0.0.1], pleased to
meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-DELIVERBY
250 HELP

If I run sendmail with -O LogLevel=14 it doesn't show any bad permissions or
other errors/warnings in my log.    The only thing I found interesting in
the log when using a high log level is:

Feb 17 11:34:27 localhost sendmail[7555]: AUTH: available mech=PLAIN LOGIN
ANONYMOUS, allowed mech=LOGIN PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5

So what am I missing in getting sendmail to support authentication  methods
other than login & plain?  Any suggestions would be greatly appreciated!

Thanks!

-Bruce

Date: Sat, 02 Feb 2002 10:18:52 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SRP CP/IP/RD options
Cc: [email-masked]
Sender: [email-masked]

At 09:58 AM 2002-02-02, [email-masked] wrote:
>SRP authentication is done once. Encryption and integrity protection
>are done for every message. Our thinking is that deployers should
>have the option to avoid the extra hash in situations where it may be
>unnecessary eg. where there are message size or speed constraints.
>
>The option of having confidentiality without integrity is a policy decision,
>and we have already been reminded that we can't prescribe policy to
>deployers.
>
>However, we do agree that deployers should be encouraged to do
>the "right thing" in general. So, we plan to specify:
>
>   - the server MUST advertise at least one integrity protection algorithm

The implementations (client or server) MUST support the XXYYZ
integrity protection algorithm.

>This means that
>   - normally integrity protection will be active
>   - if you select confidentiality, you should also select integrity
>   - you CAN select confidentiality without integrity but it is not
>     recommended and you must understand the consequences

These consequences should be discussed in the I-D, likely
in the security considerations section.

Date: Sat,  2 Feb 2002 19:58:38 +0200
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Re: SRP CP/IP/RD options
Sender: [email-masked]

SRP authentication is done once. Encryption and integrity protection
are done for every message. Our thinking is that deployers should
have the option to avoid the extra hash in situations where it may be
unnecessary eg. where there are message size or speed constraints.

The option of having confidentiality without integrity is a policy decision,
and we have already been reminded that we can't prescribe policy to
deployers.

However, we do agree that deployers should be encouraged to do
the "right thing" in general. So, we plan to specify:

   - the server MUST advertise at least one integrity protection algorithm
   - the server SHOULD always send the "mandatory=integrity" option
   - the client SHOULD select integrity protection, even if the server
     doesn't make it mandatory to do so

where SHOULD is defined as per RFC 2119:

    SHOULD  This word, or the adjective "RECOMMENDED", mean
    that there may exist valid reasons in particular circumstances to
    ignore a particular item, but the full implications must be understood
    and carefully weighed before choosing a different course.

This means that
   - normally integrity protection will be active
   - if you select confidentiality, you should also select integrity
   - you CAN select confidentiality without integrity but it is not
     recommended and you must understand the consequences

 - Keith and Raif