[9fans] upas/smtpd password authentication

[9fans] upas/smtpd password authentication

[erik quanstrom]

i was working on getting an outlook user working with
smtp authentication.  outlook won't do cram-md5 but
will do login authentication.  this does work, but it uses
the normal plan 9 lpassword rather than the inferno/pop
secret.  this means that to use imap4 + smtp, one needs
to use the "secret" for imap4 and the password for smtp.

is this an oversite, or am i missing something?

i'd rather that plan 9 passwords not be sent clear
text over the internet.

- erik

Re: [9fans] upas/smtpd password authentication

[Steve Simon]

I am pretty sure outlook will do tls encrypted auth,
smtpd has to do this so I can send to the exchange server at work
so outlook must know how to do it too.

-Steve

Re: [9fans] upas/smtpd password authentication

[erik quanstrom]

> I am pretty sure outlook will do tls encrypted auth,
> smtpd has to do this so I can send to the exchange server at work
> so outlook must know how to do it too.
> 
> -Steve

sure.  but the point of this exercize is to allow remote users to
send email without having an open relay.  since relays are only
an issue for email that is redirected offsite as an internal user,
tls seems like overkill -- and one more thing to break.

even over tls, it seems inconvinent to use two different passwords
(really the password and secret) for sending and downloading email.

- erik

Re: [9fans] upas/smtpd password authentication

[Russ Cox]

> even over tls, it seems inconvinent to use two different passwords
> (really the password and secret) for sending and downloading email.

it's certainly a bug if imap or smtpd or anything else expects
a password that is not the inferno/pop secret.

however, sending that password in plain text is no more
secure than sending the plan 9 password in plain text.
either way you should be using tls and not accept *any*
passwords sent over an unencrypted connection.

russ

Re: [9fans] upas/smtpd password authentication

[erik quanstrom]

> > even over tls, it seems inconvinent to use two different passwords
> > (really the password and secret) for sending and downloading email.
> 
> it's certainly a bug if imap or smtpd or anything else expects
> a password that is not the inferno/pop secret.
> 
> however, sending that password in plain text is no more
> secure than sending the plan 9 password in plain text.
> either way you should be using tls and not accept *any*
> passwords sent over an unencrypted connection.

i agree ... in general.  but the problem we're trying to solve is
to stop spam relay and to make a reasonable effort to insure
it's difficult to mess with someone's mail via imap.
(email is not secret anyway, since it is almost always sent
offsite and often archived in unexpected places.)

tls seems like something extra to break.  i have several
dozen mac/windows users that need detailed instructions
for every change.

i'm not a security expert.  what case that i can't currently see
would tls solve for me that's worth the extra configuration.
what am i missing?

- erik

Re: [9fans] upas/smtpd password authentication

[Jonathan D. Proulx]

On Sun, Dec 16, 2007 at 06:16:06PM -0500, erik quanstrom wrote:

:i'm not a security expert.  what case that i can't currently see
:would tls solve for me that's worth the extra configuration.
:what am i missing?

It will prevent the username:password pair from being easily
snpooped.  Minimally this would compromise email, which as you say is
inherantly insecure, but howmany of your users have the same username
password pair for other things too (like the plan9 passowrd you wish
to protect).

It this seconday case that is more dangerous, you can blame the users
for overloading their credentials and mixing "secure" and "insecure"
usages, but they will blame you if their email password is also their
bank passowrd.

Atleast those are the things I worry about with my users...

-Jon

Re: [9fans] upas/smtpd password authentication

[erik quanstrom]

> It will prevent the username:password pair from being easily
> snpooped.  Minimally this would compromise email, which as you say is
> inherantly insecure, but howmany of your users have the same username
> password pair for other things too (like the plan9 passowrd you wish
> to protect).

where would this happen?

(the second case is not a concern here.  we use seperate secret and passwords.)

- erik

Re: [9fans] upas/smtpd password authentication

[Russ Cox]

> i'm not a security expert.  what case that i can't currently see
> would tls solve for me that's worth the extra configuration.
> what am i missing?

I believe you are missing the fact that the 
so-called "inferno/pop" password is no less
powerful from an authentication point of 
view than the "plan9" password.  If you give me
either one, I can convince a host owner factotum
that I am you, and thus change my user id to 
yours on the local machine.

It turns out that the general login access daemons
all require p9any authentication, which can't be
carried out with the inferno/pop password, but 
that's not fundamental.  As far as factotum and
the kernel are concerned, the inferno/pop password
identifies you as much as the plan9 password.
So what I've described is, right now, only a local
escalation, not a network one.  But there's no 
fundamental reason for that to continue.

Better names would have been the "crappy DES"
("plan9") password and the "everything else" 
("inferno/pop") password.  The plan9 password
is not stored on the auth server -- its DES equivalent is.
The inferno/pop password *is* stored on the auth
server, making it possible to use in non-DES protocols.
If the plan9 password text had been stored originally,
the inferno/pop password wouldn't exist.

> tls seems like something extra to break.  i have several
> dozen mac/windows users that need detailed instructions
> for every change.

Around 1999, DHCP was a royal pain, because 
configuring it was difficult or undocumented,
the clients and all the servers spoke slightly different
dialects, and to a first approximation no one could
understand each other.  Now, you just check a box
and it works.  No one blinks at needing to set up DHCP.

IMAP and SMTP over TLS used to be difficult too,
but support for these has converged as they have
become more widespread.  Now you just check a box.

Russ

Re: [9fans] upas/smtpd password authentication

[Jonathan D. Proulx]

On Mon, Dec 17, 2007 at 12:26:16PM -0500, erik quanstrom wrote:

:where would this happen?

over an open wireless netowrk at some airport or coffee shop when the
user check/sends email is the mundane case.

Now is that really _your_ problem? I can't say...

-Jon

Re: [9fans] upas/smtpd password authentication

[Wes Kussmaul]

***off list***

Jonathan,

I've been bringing these issues up over the years with the Plan 9 crowd. 
I think the real response is that the Plan 9 culture is all about 
collegial groups and not about what I call Rocinha, the wider world 
where bad things happen if you don't guard against them.

Wes Kussmaul


Jonathan D. Proulx wrote:
> On Sun, Dec 16, 2007 at 06:16:06PM -0500, erik quanstrom wrote:
>
> :i'm not a security expert.  what case that i can't currently see
> :would tls solve for me that's worth the extra configuration.
> :what am i missing?
>
> It will prevent the username:password pair from being easily
> snpooped.  Minimally this would compromise email, which as you say is
> inherantly insecure, but howmany of your users have the same username
> password pair for other things too (like the plan9 passowrd you wish
> to protect).
>
> It this seconday case that is more dangerous, you can blame the users
> for overloading their credentials and mixing "secure" and "insecure"
> usages, but they will blame you if their email password is also their
> bank passowrd.
>
> Atleast those are the things I worry about with my users...
>
> -Jon
>
>   


-- 
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify attorney Mort Hapless at Vulner, Exposed & Wideopen LLP immediately at either (781) 647-7178, or at ohoh@vulex.com, and destroy all copies of this message and any attachments. No, really. Really. Listen, we mean it! Hey, if you don’t stop reading that confidential stuff about our client you’re in big trouble. OK, we’re the ones in trouble but we’ll find a way to go after you, or at least we think we may be able to. Look, we’re begging you. Just click the delete button and move on to a message that concerns you, OK? Please?? We'll buy you lunch...

Identity is the Foundation of Security™. Let Authentrus (authentrus.com) ensure that only intended recipients receive your confidential messages.

Re: [9fans] upas/smtpd password authentication

[Lyndon Nerenberg]

On 2007-Dec-16, at 15:16 , erik quanstrom wrote:

> tls seems like something extra to break.  i have several
> dozen mac/windows users that need detailed instructions
> for every change.
>
> i'm not a security expert.  what case that i can't currently see
> would tls solve for me that's worth the extra configuration.
> what am i missing?

Starting with RFC 3516 (latest IMAP4rev1), TLS support is mandatory.  
I'm not sure what problems you're running into with clients -- I've  
rolled out TLS-aware IMAP clients to hundreds of end-users, and it's  
no more difficult than any of the other IMAP4 configuration you have  
to deal with.  For most clients these days, enabling TLS involves  
ticking off a checkbox.

Re: [9fans] upas/smtpd password authentication

[Lyndon Nerenberg]

>> Starting with RFC 3516 (latest IMAP4rev1)

Sorry, I meant RFC 3501.

Re: [9fans] upas/smtpd password authentication

[erik quanstrom]

> Starting with RFC 3516 (latest IMAP4rev1), TLS support is mandatory.  
> I'm not sure what problems you're running into with clients -- I've  
> rolled out TLS-aware IMAP clients to hundreds of end-users, and it's  
> no more difficult than any of the other IMAP4 configuration you have  
> to deal with.  For most clients these days, enabling TLS involves  
> ticking off a checkbox.
> 

it might not be complicated, but there are many users for whom the box
must be checked.  these users are often twenty miles down the road.

- erik

Re: [9fans] upas/smtpd password authentication

[Lyndon Nerenberg]

On 2007-Dec-17, at 13:10 , erik quanstrom wrote:

> it might not be complicated, but there are many users for whom the box
> must be checked.  these users are often twenty miles down the road.

Ya, well, welcome to sysadmin :-(