Re: Further IESG feedback on draft-crispin-imapv-17.txt

Cyrus Daboo <daboo@cyrusoft.com> Fri, 20 September 2002 17:35 UTC

Received: by above.proper.com (8.11.6/8.11.3) id g8KHZ5E25803 for ietf-imapext-bks; Fri, 20 Sep 2002 10:35:05 -0700 (PDT)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KHZ3k25798 for <ietf-imapext@imc.org>; Fri, 20 Sep 2002 10:35:04 -0700 (PDT)
Received: from PLATO.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA05886; Fri, 20 Sep 2002 13:30:27 -0400 (EDT)
Date: Fri, 20 Sep 2002 13:33:29 -0400
From: Cyrus Daboo <daboo@cyrusoft.com>
To: Mark Crispin <MRC@cac.washington.edu>, Steve Hole <steve.hole@messagingdirect.com>
cc: ned.freed@mrochek.com, IMAP Mailing List <imap@u.washington.edu>, IMAP Extensions WG <ietf-imapext@imc.org>, paf@cisco.com, jis@mit.edu
Subject: Re: Further IESG feedback on draft-crispin-imapv-17.txt
Message-ID: <584114892.1032528809@PLATO.cyrusoft.com>
In-Reply-To: <MailManager.1032538938.220.mrc@Ikkoku-Kan.Panda.COM>
References: <MailManager.1032538938.220.mrc@Ikkoku-Kan.Panda.COM>
X-Mailer: Mulberry/3.0.0b3 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Mark,

--On Friday, September 20, 2002 9:22 AM -0700 Mark Crispin 
<MRC@cac.washington.edu> wrote:

|> I don't think there is
|> any practical way of forcing an IMAP server to turn off LOGIN in any kind
|> of open environment (University for example).
|
| Interestingly, it's easier for universities to turn off LOGIN (we have!)
| than it is for enterprises.  It just means that many clients don't work
| with our servers.  Of course, *our* preferred client works just fine...

Turning off LOGIN on the server won't stop clients that expect it to be 
present from sending the LOGIN command when SSL is not being used, thus 
exposing the plain text password. The bottom line is you cannot stop 
clients from sending LOGIN and exposing plain text passwords. The current 
draft does state clients SHOULD NOT use LOGIN except as a last restort and 
that is something that needs to be encouraged.

Also, the current (and proposed) wordings for the AUTHENTICATE command only 
suggest that the server should (must) not allow plain text passwords 
without SSL. I think the burden for that check should also lie with the 
client to prevent clients being tricked into sending plain text passwords 
over an insecure link, and I would like to see the wording changed to 
include clients doing this check.

-- 
Cyrus Daboo