|
|
|
|
|
|
| Author |
Message |
Alexander Leidinger
*nix forums addict
Joined: 16 Jun 2002
Posts: 59
|
 Posted: Sun Jul 14, 2002 11:23 am Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
On 13 Jul, Leo Bicknell wrote:
| Quote: | Tomorrow I'll write up a better summary with this new info. At
the end of the day it looks like if we add cyrus-sasl, which is
BSD licensed then the default behavior will be unchanged, but it
will be possible through a combination of rc.conf options, running
saslpasswd, and/or running ssl key generation tools to do auth on
a non-encrypted session using challenge response (against sasl
passwords), or do auth against the password file (or any PAM method)
over an ssl session. Thus we could make it as simple as
'sendmail_auth="unix"' (or pam, or whatever) for an admin to allow
end clients to starttls, auth, and securely send e-mail all with
their existing credential.
|
It would be nice if it would work like the ssh key stuff. If there's no
credential at boot time: create one.
Bye,
Alexander.
--
If Bill Gates had a dime for every time a Windows box crashed...
...Oh, wait a minute, he already does.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Sun Jul 14, 2002 8:36 am Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
FWIW:
I've taken the response to this off list, as it's drifting pretty
far from FreeBSD, unlike "Should we include Cyrus SASL in the
base system" or "How might FreeBSD implement SSL in an ideal
future" or "If Cyrus SASL is included in the base system, should
the senmail included in the base system be linked against it",
etc..
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Bernd Walter
*nix forums beginner
Joined: 28 Mar 2002
Posts: 19
|
| Posted: Sun Jul 14, 2002 8:01 am Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
On Sun, Jul 14, 2002 at 01:17:46AM -0700, Terry Lambert wrote:
| Quote: | Bernd Walter wrote:
IMO, this is broken. Here's why: Implementation of SSL in the
kernel is a foregone conclusion. It is a matter of "when", not
"if", due to work like that of Sam Leffler's recent porting of
the OpenBSD crypto hardware interface framework to FreeBSD.
Basically, asking for conversion of a socket from one type to
another is not something that will necessarily be supportable.
With SSL you still do a normal socket connect anyway and than
call SSL_connect/accept on the already existing connection.
What's the matter with exchanging packets before doing that?
Does that mean that the SSL API changes?
Yes; it becomes something like:
s = socket( PF_INET, SOCK_SSL, 0);
bzero(&sa, sizeof(struct sockaddr_ssl));
sa.sin_family = PF_INET;
sa.sin_port = htons( 465); /* SMTPS */
sa.sin_cert = &cert; /* Local Cert. */
connect( s, (struct sockaddr *)&sa, sizeof(struct sockaddr_ssl));
|
Now I understand what you mean with "socket type conversion".
Mmm - That way I can't have a different SSLcontext on incoming connects?
Currently I do it after accept, but before I only have the listen
descriptor and if accept already does the SSL handshake...
Not that it's an important thing to me - I just wonder.
| Quote: | I'm not a cryptographic expert, but I wouldn't prefer a packet
encryption over a stream encryption.
The bloat in the IPSEC case is because of the KAME integration;
the IPSEC in IPv4 eats a context structure, even if it's not
used. The IPv6 code is better. I took it to be a political
statement on IPv4 by the KAME people.  .
The support being in the kernel instead of user space doesn't
make it other than a stream encryption, though.
|
Maybe I should spend more time into IPSEC.
| Quote: | With STARTTLS you can probe for SSL in MTA - MTA comunications.
MTAs connect foreign SMTP servers and want to prefer SSL.
It's unpractical to try a connect to smpts port first with all those
blackhole firewalls out there.
Meaning that it won't reject the initial packet, you will have
to time out the connection, and then retry on port 25?
Actually, you can use non-blocking I/O, simultaneously connect,
and then drop whiever one doesn't pan out, or you could cache
the result, or you etc.. could make it a mailer flag (e.g.
"mailer smtps has flag 'Q' and uses port 465"), and control it
on a peer basis.
|
OK - that's both possible.
| Quote: | It's not really for trusted host communications anyway, since
the only reason we're eating the encruption overhead is to
secure a plaintext password; the that rest of the session is
also encrypted is actually annoying overhead, in most cases.
|
But it's a nice to have feature.
It brings encryption of the whole session together with certificates.
Certificates are great to deliver safly to dynamic IPs.
Together with ETRN this was the first real option to replace rmail
only UUCP nodes with SMTP - asuming that IP is available.
| Quote: | The only downside with STARTTLS is that it makes it allmost impossible
to use external SSL boxes.
That's a very big downside. OpenSSL does maybe 200 if you have
a fas box, and you eat the whole thing doing crypto. Not worth
doing onboard the box itself, if you can possibly avoid it.
|
I never saw this as a big point as it was forseeable that one day you
can just plug in a crypto card directly in each border mailhost :)
--
B.Walter COSMO-Project http://www.cosmo-project.de
ticso@cicely.de Usergroup info@cosmo-project.de
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Sun Jul 14, 2002 6:17 am Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
Bernd Walter wrote:
| Quote: | IMO, this is broken. Here's why: Implementation of SSL in the
kernel is a foregone conclusion. It is a matter of "when", not
"if", due to work like that of Sam Leffler's recent porting of
the OpenBSD crypto hardware interface framework to FreeBSD.
Basically, asking for conversion of a socket from one type to
another is not something that will necessarily be supportable.
With SSL you still do a normal socket connect anyway and than
call SSL_connect/accept on the already existing connection.
What's the matter with exchanging packets before doing that?
Does that mean that the SSL API changes?
|
Yes; it becomes something like:
s = socket( PF_INET, SOCK_SSL, 0);
bzero(&sa, sizeof(struct sockaddr_ssl));
sa.sin_family = PF_INET;
sa.sin_port = htons( 465); /* SMTPS */
sa.sin_cert = &cert; /* Local Cert. */
connect( s, (struct sockaddr *)&sa, sizeof(struct sockaddr_ssl));
| Quote: | I'm not a cryptographic expert, but I wouldn't prefer a packet
encryption over a stream encryption.
|
The bloat in the IPSEC case is because of the KAME integration;
the IPSEC in IPv4 eats a context structure, even if it's not
used. The IPv6 code is better. I took it to be a political
statement on IPv4 by the KAME people. .
The support being in the kernel instead of user space doesn't
make it other than a stream encryption, though.
| Quote: | With STARTTLS you can probe for SSL in MTA - MTA comunications.
MTAs connect foreign SMTP servers and want to prefer SSL.
It's unpractical to try a connect to smpts port first with all those
blackhole firewalls out there.
|
Meaning that it won't reject the initial packet, you will have
to time out the connection, and then retry on port 25?
Actually, you can use non-blocking I/O, simultaneously connect,
and then drop whiever one doesn't pan out, or you could cache
the result, or you etc.. could make it a mailer flag (e.g.
"mailer smtps has flag 'Q' and uses port 465"), and control it
on a peer basis.
It's not really for trusted host communications anyway, since
the only reason we're eating the encruption overhead is to
secure a plaintext password; the that rest of the session is
also encrypted is actually annoying overhead, in most cases.
| Quote: | The only downside with STARTTLS is that it makes it allmost impossible
to use external SSL boxes.
|
That's a very big downside. OpenSSL does maybe 200 if you have
a fas box, and you eat the whole thing doing crypto. Not worth
doing onboard the box itself, if you can possibly avoid it.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Bernd Walter
*nix forums beginner
Joined: 28 Mar 2002
Posts: 19
|
| Posted: Sun Jul 14, 2002 5:36 am Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
On Sat, Jul 13, 2002 at 05:24:59PM -0700, Terry Lambert wrote:
| Quote: | You can (and should) use STARTTLS with SMTP AUTH PLAIN/LOGIN and do not
(and should not) use SMTP over SSL as it is non-standard.
IMO, this is broken. Here's why: Implementation of SSL in the
kernel is a foregone conclusion. It is a matter of "when", not
"if", due to work like that of Sam Leffler's recent porting of
the OpenBSD crypto hardware interface framework to FreeBSD.
Basically, asking for conversion of a socket from one type to
another is not something that will necessarily be supportable.
|
With SSL you still do a normal socket connect anyway and than
call SSL_connect/accept on the already existing connection.
What's the matter with exchanging packets before doing that?
Does that mean that the SSL API changes?
| Quote: | The whole "STARTTLS" thing was introduced to kludge around the
lack of IPSEC support in IPv4. Even if you argue that it's an
issue for IPv4 because IPSEC bloats the hell out of IPv4 even
when it's not being used, IPv6 requires implementation of IPSEC
for it to be called an IPv6 implementation.
This means that the days of transport crypto decisions like
this one, and the code to implement it, living in user space
are numbered, no matter what.
|
I'm not a cryptographic expert, but I wouldn't prefer a packet
encryption over a stream encryption.
| Quote: | I know the sendmail folks don't like SMTP over SSL, but...
there is an IANA assigned number in /etc/services for it,
which makes it about as standard as it can be; I don't think
SSL RFC policy requires a per protocol SSL usage RFC for SSL
to be used (that wouldn't make sense, in terms of promoting
the adoption of SSL).
|
With STARTTLS you can probe for SSL in MTA - MTA comunications.
MTAs connect foreign SMTP servers and want to prefer SSL.
It's unpractical to try a connect to smpts port first with all those
blackhole firewalls out there.
The only downside with STARTTLS is that it makes it allmost impossible
to use external SSL boxes.
--
B.Walter COSMO-Project http://www.cosmo-project.de
ticso@cicely.de Usergroup info@cosmo-project.de
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Leo Bicknell
*nix forums beginner
Joined: 13 Jul 2002
Posts: 4
|
| Posted: Sat Jul 13, 2002 11:46 pm Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
In a message written on Sat, Jul 13, 2002 at 10:55:28AM -0700, Claus Assmann wrote:
| Quote: | AuthOptions
...
Example:
O AuthOptions=p,y
would disallow ANONYMOUS as AUTH mechanism
and would allow PLAIN only if a security
layer (e.g., provided by STARTTLS) is
already active. ....
|
Thanks. I found a document on the authoptions earlier, but it
confused me more than it enlightened me. This, plus Greg's mail
makes a lot more things clear.
Tomorrow I'll write up a better summary with this new info. At
the end of the day it looks like if we add cyrus-sasl, which is
BSD licensed then the default behavior will be unchanged, but it
will be possible through a combination of rc.conf options, running
saslpasswd, and/or running ssl key generation tools to do auth on
a non-encrypted session using challenge response (against sasl
passwords), or do auth against the password file (or any PAM method)
over an ssl session. Thus we could make it as simple as
'sendmail_auth="unix"' (or pam, or whatever) for an admin to allow
end clients to starttls, auth, and securely send e-mail all with
their existing credential.
That is exactly what I want to promote. Hopefully people will
agree, and we can get to the code details (which actually seem
really simple).
--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Sat Jul 13, 2002 10:24 pm Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
Gregory Neil Shapiro wrote:
| Quote: | You need to go back and read the RFC's/documentation.
First, you can limit the AUTH mechanisms offered based on whether STARTTLS
was used or not. Second, after a successful STARTTLS negotiation, a new
EHLO is done and a new set of AUTH mechanisms is given.
|
I see it now. My bad. I was looking at 2246 and 2595, when I
should have been looking at 3207. As you say, the race is
addresses by the state reset requirement.
| Quote: | You can (and should) use STARTTLS with SMTP AUTH PLAIN/LOGIN and do not
(and should not) use SMTP over SSL as it is non-standard.
|
IMO, this is broken. Here's why: Implementation of SSL in the
kernel is a foregone conclusion. It is a matter of "when", not
"if", due to work like that of Sam Leffler's recent porting of
the OpenBSD crypto hardware interface framework to FreeBSD.
Basically, asking for conversion of a socket from one type to
another is not something that will necessarily be supportable.
The whole "STARTTLS" thing was introduced to kludge around the
lack of IPSEC support in IPv4. Even if you argue that it's an
issue for IPv4 because IPSEC bloats the hell out of IPv4 even
when it's not being used, IPv6 requires implementation of IPSEC
for it to be called an IPv6 implementation.
This means that the days of transport crypto decisions like
this one, and the code to implement it, living in user space
are numbered, no matter what.
I know the sendmail folks don't like SMTP over SSL, but...
there is an IANA assigned number in /etc/services for it,
which makes it about as standard as it can be; I don't think
SSL RFC policy requires a per protocol SSL usage RFC for SSL
to be used (that wouldn't make sense, in terms of promoting
the adoption of SSL).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Gregory Neil Shapiro
*nix forums beginner
Joined: 19 Jun 2002
Posts: 5
|
| Posted: Sat Jul 13, 2002 9:42 pm Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
tlambert2> You need to submit your patches for this to the sendmail people.
tlambert2> Without modification, sendmail does not enforce use of SSL for
tlambert2> permitting advertisement of SMTP AUTH, and therefore addition of
tlambert2> a pseudo-RFC-2595 "PLAIN" or "EXTERNAL X-UNIX" mechansim can not
tlambert2> reasonably be added to FreeBSD so that it's operational by default.
tlambert2> The STARTTLS SMTP command doesn't work, because it is issued
tlambert2> after the EHLO, which solicits the capabilities list that exposes
tlambert2> the SMTP AUTH. The only method that works, therefore, is to use
tlambert2> an SSL connection -- SMTPS... port 465, instead of port 25). You
tlambert2> can see the order of operation problem, I hope?
You need to go back and read the RFC's/documentation.
First, you can limit the AUTH mechanisms offered based on whether STARTTLS
was used or not. Second, after a successful STARTTLS negotiation, a new
EHLO is done and a new set of AUTH mechanisms is given.
You can (and should) use STARTTLS with SMTP AUTH PLAIN/LOGIN and do not
(and should not) use SMTP over SSL as it is non-standard.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Claus Assmann
*nix forums beginner
Joined: 13 Jul 2002
Posts: 17
|
| Posted: Sat Jul 13, 2002 3:55 pm Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
On Sat, Jul 13, 2002, Leo Bicknell wrote:
| Quote: | I was more thinking SMTPS; that is the SMTPS server would allow
SMTP AUTH, and the SMTP (25) server would not. I understand you
can't configure sendmail to do this today. That could be
patched though, and an interim hack would to just run two copies
of sendmail with slightly different configs. No?
|
AuthOptions
....
Example:
O AuthOptions=p,y
would disallow ANONYMOUS as AUTH mechanism
and would allow PLAIN only if a security
layer (e.g., provided by STARTTLS) is
already active. ....
PS: you may want to check out _FFR_SMTP_SSL
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Leo Bicknell
*nix forums beginner
Joined: 13 Jul 2002
Posts: 4
|
| Posted: Sat Jul 13, 2002 11:26 am Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
In a message written on Sat, Jul 13, 2002 at 04:32:36AM -0700, Terry Lambert wrote:
| Quote: | This isn't really a FreeBSD issue, except for the inclusion of
the SASL library in the base system, which is not currently the
case.
|
Correct.
| Quote: | The STARTTLS SMTP command doesn't work, because it is issued
after the EHLO, which solicits the capabilities list that exposes
the SMTP AUTH. The only method that works, therefore, is to use
an SSL connection -- SMTPS... port 465, instead of port 25). You
can see the order of operation problem, I hope?
|
I was more thinking SMTPS; that is the SMTPS server would allow
SMTP AUTH, and the SMTP (25) server would not. I understand you
can't configure sendmail to do this today. That could be
patched though, and an interim hack would to just run two copies
of sendmail with slightly different configs. No?
--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Sat Jul 13, 2002 9:32 am Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
Leo Bicknell wrote:
| Quote: | Terry Lambert wrote:
You are almost better off simply using SMTP over SSL, and
permitting connections only to certificated clients, at which
point you can just sign the client certificates and be done
with it, without using the "SMTP AUTH" approach at all.
I want to address this specifically.
I have personally been involved with a half dozen situations where
SMTP AUTH against the password file was desired.
|
This isn't really a FreeBSD issue, except for the inclusion of
the SASL library in the base system, which is not currently the
case.
The license on Cyrus SASL is right (BSD license) for it to be
included int he base system (one of the things you are asking)
and for sendmail to be configured to use it, and linked with it
by default (the other thing you are asking).
I personally approve of including it, but it *is* "bloat".
But integration into the UNIX password mechanism is not really
possible at this time.
People can want it, but they aren't going to get it, because
UNIX passwords are not stored as plaintext, as they are when
you use the "saslpasswd" program, and sendmail only advertises
SMTP AUTH KERBEROS and CRAM-MD5 mechanisms (per RFC-2222), and
not "PLAIN" if saslpasswd( has been run, and the saslpasswd
file exists. Note that RFC-2595 does not apply to SMTP, and
it doesn't apply to what it does apply to, without TLS (SSL).
| Quote: | using protocols supported today by the majority of e-mail
clients. SMTP AUTH, requiring SSL as I outlined before, is the only
solution I have ever found.
|
You need to submit your patches for this to the sendmail people.
Without modification, sendmail does not enforce use of SSL for
permitting advertisement of SMTP AUTH, and therefore addition of
a pseudo-RFC-2595 "PLAIN" or "EXTERNAL X-UNIX" mechansim can not
reasonably be added to FreeBSD so that it's operational by default.
You might as well argue for rsh or telnet being reenabled by
default.
The STARTTLS SMTP command doesn't work, because it is issued
after the EHLO, which solicits the capabilities list that exposes
the SMTP AUTH. The only method that works, therefore, is to use
an SSL connection -- SMTPS... port 465, instead of port 25). You
can see the order of operation problem, I hope?
The normal commercial practice (assuming you aren't also using
SASL for IMAP4 server authentication, in which case, the password
database is shared, but seperate from the UNIX password database)
is to trap UNIX password authentication to the POP3 server, and,
on successful authentication, create a corresponding SASL password
file entry using the pop3 daemon's knowledge of the unencrypted
shared secret (either from it's own database, if APOP is used, or
the over the wire value, if USER/PASS is used).
In other words, it's something you do with the plaintext in hand,
no matter how you look at it.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Leo Bicknell
*nix forums beginner
Joined: 13 Jul 2002
Posts: 4
|
| Posted: Sat Jul 13, 2002 2:57 am Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
In a message written on Fri, Jul 12, 2002 at 09:42:26PM -0700, Terry Lambert wrote:
| Quote: | You are almost better off simply using SMTP over SSL, and
permitting connections only to certificated clients, at which
point you can just sign the client certificates and be done
with it, without using the "SMTP AUTH" approach at all.
|
I want to address this specifically.
I have personally been involved with a half dozen situations where
SMTP AUTH against the password file was desired. In most, certificates
were also investigated. They were rejected for one or more of the
following reasons:
1) There was no certificate management system already in place,
and creating one just for e-mail was "too expensive".
2) Management wanted centrally revokable credentials, which generally
means kerberos (although there are other methods for login
access). While hooking that to certificates is possible, it is
not the default in anything, so it's additional work on top of
1.
3) Configuring trusted credentials in the client software was non-trival
for "regular" end users.
4) Users are used to authenticating with a "password", and preserving
that model is a good thing.
I don't suggest that any or all of them are good ideas, but simply
that from my point of view everyone insists on passwords as the
(only) mechanism.
Today, most people I know are using ssh to port foward 25 +
110/143/220. ssh uses passwords, "localhost" can be trusted. This
works. I want to make this go away, in the default install if at
all possible. imap/ssl solves the mail download issue, so the only
issue I see is how to you securely send mail, without compromising
passwords, using protocols supported today by the majority of e-mail
clients. SMTP AUTH, requiring SSL as I outlined before, is the only
solution I have ever found.
--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Sat Jul 13, 2002 2:42 am Post subject:
Re: Mail subsystem defaults, adding authentication.
|
|
|
Leo Bicknell wrote:
| Quote: | So, I would like comments on the following issues:
1) Is it desirable to provide a default install for which SMTP AUTH
against the password file works?
|
Yes. But it's not possible without destorying the ablity of
the default install to run over port 25. The contents of the
crypt-encrypted password are one-way hashed with an externally
unrecoverable salt. The net effect of this is that you can not
use crypt-based passwords unless they are encrypted for
comparison on the server -- which means passing them over the
wire as plaintext. You *force* the use of SSL, if this is
enabled.
| Quote: | 2) If yes to #1, is including the cyrus-sasl port in the base
distribution the best way to get a SASL library? [Included
in this is license issues, code quality issues, etc.] If it
is not the best, is there a better choice?
|
You would have to use SMTP over SSL, *NOT* "STARTTLS", and then
enforce its use if "SMTP AUTH" is to be used, to make sending
passwords in the clear acceptable due to the secure link.
You are almost better off simply using SMTP over SSL, and
permitting connections only to certificated clients, at which
point you can just sign the client certificates and be done
with it, without using the "SMTP AUTH" approach at all.
An alternate approach would be to use the crypted passwords,
with the salt being passed as apart of the SASL dialog, so the
crypted password could be passed. This would be less painful,
overall, for the server (clients outnumber servers by a large
margin), but... it would require client modification, and the
definition of an "x-crypt" authentication type (and/or a full
RFC process to define it without the "-x").
The OpenLDAP list archives are quire extensive on this subject,
as are the Cyrus list archives, and the Sendmail list archives,
where there has been a similar desire to use the standard UNIX
authentication mechanism with SASL.
PAM has the same problem, if it's any consolation.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Leo Bicknell
*nix forums beginner
Joined: 13 Jul 2002
Posts: 4
|
| Posted: Sat Jul 13, 2002 1:47 am Post subject:
Mail subsystem defaults, adding authentication.
|
|
|
[Those CC:ed, you send me mail in a freebsd-hackers discussion late
last year.]
[I am not on freebsd-arch, please keep me in CC's.]
Short form:
I believe it is important for FreeBSD's default install to either
make it easy, or default to a setup that allows SMTP AUTH against
the password file. To do this we need to include a SASL library.
As such, I would like a SASL library in the base distribution.
Long form:
FreeBSD already supports STMP over SSL in the default install
(if the user creates keys). There is a port for imap-ssl that
works quite well, plus there is no imap in the default install.
To provide secure, e-mail (sending and receiving) you need a
download protocol that is encrypted (imap-ssl), and a sending
protocol (SMTP AUTH) that prevents relaying. Since SMTP AUTH
does not require non-cleartext passwords, doing SMTP AUTH over
SSL is a good idea.
SMTP AUTH checks a userid and password. To my knowledge, sendmail
only supports using SASL to perform this function. We have SASL
libraries in a port. If they are installed, a few flags can be
changed so "make world" builds a sendmail that has SASL support.
If the SASL port were installed as part of the base system, these
flags could be the default.
Since all major e-mail clients support IMAP/SSL and SMTP AUTH
(usually over SSL, if IMAP/SSL is supported) this seems the right
combination for a fully secure, non-open relay configuration.
So, I would like comments on the following issues:
1) Is it desirable to provide a default install for which SMTP AUTH
against the password file works?
2) If yes to #1, is including the cyrus-sasl port in the base
distribution the best way to get a SASL library? [Included
in this is license issues, code quality issues, etc.] If it
is not the best, is there a better choice?
At the end of the day, I think we are close to the right thing,
which means imap-ssl is easy to install from a port (and easy to
keep separate from the base system). SMTP over SSL seems to already
be in the base system. The only thing preventing a user from
running a "secure" SMTP/IMAP server from a base install, is the
lack of SMTP AUTH. AFAIK, SASL is the only way to get that working,
and cyrus-sasl is the best (technically) library available.
At this time, I don't want to nit-pick on details, that can be done
off list. What I'm really after is if there is support for making
SMTP AUTH work in the base install, and if my _general_ outline is
the right way to go about it. There are more appropriate places
for the details.
--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 6:13 am | All times are GMT
|
|
CitiBank Credit Cards | Remortgages | Loans | Brazilian Property | Mortgage
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
