Subject: Re: Make imap work without "rsh"

From: Robert Moskowitz <[email-masked]>
Date: Mon, 31 Jul 1995 06:49:05 -0400

At 01:55 PM 7/28/95 -0700, Mark Crispin wrote:
>Sigh.  I shouldn't answer messages when I'm annoyed, but there has been some
>serious FUD and misinformation arising out of Paul Kramer's innocent question.
>
>On Fri, 28 Jul 1995 09:24:57 -0700 (PDT), Mike Macgirvin wrote:
>> >  This question would be better directed to comp.mail.pine (aka
>> >  [email-masked]) as I believe it is a Pine implementation
>> >  issue rather than an IMAP protocol issue.
>>
>> 	I won't presume that. It affects everybody.
>
>It affects everybody who uses c-client.
>

Gee am I that much of a newbie or am I missing something here...

I am running the latest cyrus code on a SPARC 20 SOLARIS 2.4.  I am using
the SIMEON DOS/Windows client.  Cyrus is currently set up for UNIX user
security (we are configuring a Kerberos 4 special for it, we already have a
DCE cell but that won't work :( ).  In my sniffer studies of trying to get
the ACLs right on Cyrus (long way to go there) I have not seen a single RSH
packet.  The USER ID and Password go directly to the server over port 143 in
an easy to sniff packet :[

Robert Moskowitz
Chrysler Corporation
(810) 758-8212

---

From: Mark Crispin <[email-masked]>
Date: Mon, 31 Jul 1995 10:24:27 -0700 (PDT)

> Gee am I that much of a newbie or am I missing something here...

Yes, you are.  ;-)

> packet.

The Cyrus IMAP server is not based upon c-client.  The issue of an option to
use rsh to a c-client based IMAP server is not relevant to you; you don't have
that option.

The only point that is relevant to you is that IMAP clients on Unix systems
may try to use this feature, and go to port 143 as a fall-back.  If your
server system is not set up to reject an rsh access in way that rsh will
recognize as a rejection (that is, by opening the connection, sending the
string "Permission denied", and closing the connection), the client may block
until timing out a minute or later.

Unfortunately, analysis of the source code for the rcmd() function called by
rsh shows that it treats a TCP-level "connection refused" and an IP level
"destination unreachable" as a "soft error, sleep and try again" condition.
On connect() calls these should be considered as hard errors.

The upshot of all of this is that users of Unix based clients *may* have an
annoying delay in opening their IMAP connections.  This delay can be cured at
either the server or the client end.

> The USER ID and Password go directly to the server over port 143 in

Yes.  That's what happens if you fall back to basic IMAP authentication.  This
is the same weakness that exists in FTP and most other Internet protocols.

The "security flaw" on the rsh feature in the c-client based IMAP server is
that it is vulnerable to IP address spoofing.  John's claim notwithstanding,
it is possible to secure your network from IP address spoofing; a good idea
even if you don't use IP addresses for authentication since IP address
spoofing can also be used to hijack connections.

If you don't use rsh, not only do you have user inconvenience but you also
become vulnerable to password sniffing.  It is quite debatable which is the
greater risk.  I believe that it is theoretically possible to make the rsh
mechanism somewhat more secure than transmitting passwords in the clear,
although doing so involves taking steps that are not obvious, such as using
static ARP for rsh-authenticated clients, keeping server-server communications
(e.g. NFS) isolated by firewall from clients as well as denying unapproved
access to servers by firewall (meaning also that servers are not on the same
subnet as clients), additional scan/validation of .rhosts files to prevent
illegitimate entries (e.g. "+ +"), etc.

Of course, Kerberos, S/Key, etc. cure these and many other ills.  But as you
have noticed, Kerberos is not plug'n'play.  Worse, Kerberos is a moving
target.  For better or worse, passwords in the clear and rsh are going to be
with us for some time to come, and I do not feel that it is appropriate to
bash software for using what are often the only mechanisms available.