[9fans] upas/smtpd password authentication - Plan9

This is a discussion on [9fans] upas/smtpd password authentication - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: [9fans] upas/smtpd password authentication

  1. [9fans] upas/smtpd password authentication

    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

  2. Re: [9fans] upas/smtpd password authentication

    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

  3. Re: [9fans] upas/smtpd password authentication

    > 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

  4. Re: [9fans] upas/smtpd password authentication

    > 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


  5. Re: [9fans] upas/smtpd password authentication

    > > 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

  6. Re: [9fans] upas/smtpd password authentication

    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 usernameassword 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

  7. Re: [9fans] upas/smtpd password authentication

    > It will prevent the usernameassword 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

  8. Re: [9fans] upas/smtpd password authentication

    > 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


  9. Re: [9fans] upas/smtpd password authentication

    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

  10. Re: [9fans] upas/smtpd password authentication

    ***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 usernameassword 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.


  11. Re: [9fans] upas/smtpd password authentication


    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.

  12. Re: [9fans] upas/smtpd password authentication

    >> Starting with RFC 3516 (latest IMAP4rev1)

    Sorry, I meant RFC 3501.

  13. Re: [9fans] upas/smtpd password authentication

    > 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

  14. Re: [9fans] upas/smtpd password authentication


    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 :-(

+ Reply to Thread