mailing list archives

Hi,

Can anyone tell me if there is a way of NOT asking for a password for 
various usernames?

The situation is as follows :

1) we're using a server that has many users
2) some use SSL, some don't
3) some users want to only be able to use SSL

This is set up and works fine.

However, if a users who wants to only be able to use SSL tries to use a 
regular port without SSL, then their username and password are 
transmitted in plain text.

I want to configure the server to not even ask for a password for those 
users who have to use SSL.

Max.

Your question is difficult to answer, because it makes an incorrect 
premise.  That premise is that the server "asks" for a password.

The server does not "ask" for a password in IMAP; rather, the client 
chooses to provide one.

The server MAY announce that it refuses passwords on a global basis via 
the LOGINDISABLED capability.  Any client which sends a password to a 
server which has announced LOGINDISABLED is non-compliant with the IMAP 
specification and should not be used.

The standard configuration of UW imapd, in accordance with the IMAP 
specification (RFC 3501), makes such an announcement on non-SSL/TLS 
sessions; and in that state will reject any password even if the password 
is correct.  In that state, UW imapd allows other means of authentication 
that do not involve passwords.  If the session negotiates TLS encryption, 
the UW imapd will retract the LOGINDISABLED announcement and allow 
password authentication.

For other servers, you will need to read the vendor's documentation.

When announced, LOGINDISABLED is a global restriction.  It is not possible 
to allow passwords for some users and disallow passwords for other users. 
This is because the user name and password are sent together.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Thanks for the prompt response and clear explanation.

It seems that the options are :

1) propose a new RFC to split the username/password, which can then be 
implemented
2) use a separate servers for secure and insecure users (I suppose a 
second NIC would suffice?)

Is that correct?

Max.

Mark Crispin wrote:
> Your question is difficult to answer, because it makes an incorrect 
> premise.  That premise is that the server "asks" for a password.
> 
> The server does not "ask" for a password in IMAP; rather, the client 
> chooses to provide one.
> 
> The server MAY announce that it refuses passwords on a global basis via 
> the LOGINDISABLED capability.  Any client which sends a password to a 
> server which has announced LOGINDISABLED is non-compliant with the IMAP 
> specification and should not be used.
> 
> The standard configuration of UW imapd, in accordance with the IMAP 
> specification (RFC 3501), makes such an announcement on non-SSL/TLS 
> sessions; and in that state will reject any password even if the 
> password is correct.  In that state, UW imapd allows other means of 
> authentication that do not involve passwords.  If the session negotiates 
> TLS encryption, the UW imapd will retract the LOGINDISABLED announcement 
> and allow password authentication.
> 
> For other servers, you will need to read the vendor's documentation.
> 
> When announced, LOGINDISABLED is a global restriction.  It is not 
> possible to allow passwords for some users and disallow passwords for 
> other users. This is because the user name and password are sent together.
> 
> -- Mark --
> 
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.

On Thu, 3 Nov 2005, Max Waterman wrote:
> 1) propose a new RFC to split the username/password, which can then be 
> implemented

The chances of such a document being accepted for publication as an RFC, 
much less being implemented, are about as close to nil as you can get 
without being completely impossible.

> 2) use a separate servers for secure and insecure users (I suppose a second 
> NIC would suffice?)

That is more likely.  You could use a different port number instead of a 
separate IP address.

I question the need to use a client which does not negotiate SSL or TLS. 
All modern IMAP clients support SSL and/or TLS, and have done so for 
years.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Max Waterman <davidmaxwaterman@fastmail.co.uk> writes:
>It seems that the options are :
>
>1) propose a new RFC to split the username/password, which can then be 
>implemented

Given the rabid desire of many client implementors to minimize the
number of round-trips required by IMAP, my guess is that such a
proposal would be a virtual non-starter, especially given that
support for STARTTLS is now mandatory.  That is, there already is
a standardized method of eliminating the problem: require use of
STARTTLS or an authentication mechanism that's safe from passive
attacks, so why come up with a workaround for this problem when it
would just delay support for the mandated methods?

I will note that no direct protocol change is required for what you
want: clients would merely need to use a (synchronizing) literal
for the password argument to the LOGIN command, while server
implementors would need to trigger any "is this user permitted to
use cleartext logins" check immediately after the username is
received and condition whether to send a tagged NO or a continuation
response on that check.  For some servers, moving the check there
may be trivial, and perhaps should be encouraged, but the ease
depends on the design of the server.  A security analysis of the
effects of moving the check there would be in order as well.


>2) use a separate servers for secure and insecure users (I suppose a 
>second NIC would suffice?)

If you must support insecure logins, then restricting them to a
separate IP or port may be the most easily deployed way to prevent
accidental leaking of passwords.  It's certainly something you can
do now without waiting for client and servers implementations to
change.


Philip Guenther

Mark Crispin wrote:
> On Thu, 3 Nov 2005, Max Waterman wrote:
>> 1) propose a new RFC to split the username/password, which can then be 
>> implemented
> 
> The chances of such a document being accepted for publication as an RFC, 
> much less being implemented, are about as close to nil as you can get 
> without being completely impossible.

Indeed. I wasn't suggesting it was a realistic option.

> 
>> 2) use a separate servers for secure and insecure users (I suppose a 
>> second NIC would suffice?)
> 
> That is more likely.  You could use a different port number instead of a 
> separate IP address.

Well, no. That is the problem really. Port numbers are just too easy to 
get wrong.

> 
> I question the need to use a client which does not negotiate SSL or TLS. 
> All modern IMAP clients support SSL and/or TLS, and have done so for years.

Indeed, but, again, this is the problem. It is just too easy to get wrong.

I am trying to *ensure* that my users *always* have a secure connection. 
This isn't so difficult, and, in fact, this is what we have. However, 
other users of the system (it's a 3rd party running it), don't want to 
use SSL/TLS, and so the standard ports are still open and will allow 
authentication attempts. Thus, my users, if, by mistake, configure their 
email clients to use the standard ports, will transmit their username 
and password in clear text and so anyone snooping could intercept it and 
use it to access the email server themselves.

It seems that the only solution is to have a completely separate server 
which only allows authentication after SSL/TLS has been set up.

Or, perhaps, all that is needed is separate server processes running on 
a separate NIC?

...or am I missing something.

Max.

> 
> -- Mark --
> 
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.

On Wed, 2 Nov 2005, Mark Crispin wrote:
> On Thu, 3 Nov 2005, Max Waterman wrote:

<clip>
> > 2) use a separate servers for secure and insecure users (I suppose a second
> > NIC would suffice?)
> 
> That is more likely.  You could use a different port number instead of a
> separate IP address.

What I have done is patching uw-imapd to support plain-text passwords 
taken from a file in the users homedirectory. This imapd runs on the 
standard imap4 port. I did this by modifying the cram-md5 code in 
uw-imapd.
 
The reason for this radical decision to decrease security is mobile 
phones. It's quite expensive to do SSL on a mobile phone (batterywise).

Then we have another imapd that speaks on the imaps port. 

This combination works fine for us. So far :)

> I question the need to use a client which does not negotiate SSL or TLS. All
> modern IMAP clients support SSL and/or TLS, and have done so for years.

Well, mobile devices, such as some mobile phones don't do SSL/TLS, it 
has to do with the required hardware and available batterypower. Although 
the phone speaks some kind of imap... 


> 
> -- Mark --
> 
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> https://mailman1.u.washington.edu/mailman/listinfo/imap-protocol
> 

-- 
A: Top Posters
Q: What is the most annoying thing on mailing lists? 

Harald H Hannelius | harald/a\arcada.fi      | GSM +358 50 594 1020

On Nov 2, 2005, at 9:11 PM, Max Waterman wrote:

> It seems that the only solution is to have a completely separate  
> server which only allows authentication after SSL/TLS has been set up.

If security is that critical to you then I don't think you have much  
choice other than to a) bring the service in house where you can  
control it, or b) find an outsourced provider who can meet your  
policy requirements.

Given the number of providers who insist on 'security by Microsoft',  
I think a) is your only realistic solution.

--lyndon

On Thu Nov  3 07:33:12 2005, Harald Hannelius wrote:
> The reason for this radical decision to decrease security is mobile 
> phones. It's quite expensive to do SSL on a mobile phone 
> (batterywise).

I keep hearing this rumour, but it's confusing on two counts:

1) The single biggest drain on the battery is the radio transmitter, 
not the CPU, which is generally reasonably efficient.
2) If crypto really was such a major drain on the battery, then given 
that battery life is so crucial to the market, why on earth haven't 
they got crypto processors (which have a markedly lower power usage 
for crypto work than a generic CPU).

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Dave Cridland writes:
> On Thu Nov  3 07:33:12 2005, Harald Hannelius wrote:
>> The reason for this radical decision to decrease security is mobile 
>> phones. It's quite expensive to do SSL on a mobile phone 
>> (batterywise).
>
> I keep hearing this rumour, but it's confusing on two counts:

It makes perfect sense if you think HTTP, not IMAP.

Think about short-lived HTTP-like connections and imperfect session 
caching. Lots of connections being opened, lots of number crunching and 
transmission for each connection establishment.

Arnt