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

ned.freed@mrochek.com Thu, 19 September 2002 17:49 UTC

Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8JHn9Q16984 for ietf-imapext-bks; Thu, 19 Sep 2002 10:49:09 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8JHn8k16980 for <ietf-imapext@imc.org>; Thu, 19 Sep 2002 10:49:08 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01KMOJL410O000628S@mauve.mrochek.com> for ietf-imapext@imc.org; Thu, 19 Sep 2002 10:49:08 -0700 (PDT)
Date: Thu, 19 Sep 2002 10:34:10 -0700
From: ned.freed@mrochek.com
Subject: Further IESG feedback on draft-crispin-imapv-17.txt
To: IMAP Mailing Liste <imap@u.washington.edu>, IMAP Extensions WG <ietf-imapext@imc.org>
Cc: ned.freed@mrochek.com, paf@cisco.com, jis@mit.edu
Message-id: <01KMOKNGXORY00628S@mauve.mrochek.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Content-transfer-encoding: 7bit
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>

The IESG had this on the agenda today. The various document nits seem to have
been satisfactorily addressed. The IESG is also happy with the general way the
big item in the previous feedback -- mandatory to implement security -- has
been dealt with.

One concern remains, however. The following note appears in 6.2.1:

Note: a server implementation SHOULD NOT permit any
      plaintext password mechanisms unless the STARTTLS
      command described in [IMAP-TLS] has been negotiated.
      Client and server implementations SHOULD implement
      additional SASL mechanisms which do not use plaintext
      passwords, such the GSSAPI mechanism described in [SASL]
      and/or the [DIGEST-MD5] mechanism.

The IESG would like to push back even harder on the use of plain text
passwords, and would like to see this changed to read:

Note: a server implementation MUST NOT permit any
      plaintext password mechanisms unless the STARTTLS
      command described in [IMAP-TLS] has been negotiated or some 
      other mechanism that protects the session from password
      snooping has been provided. Client and server implementations
      SHOULD implement additional SASL mechanisms which do not use
      plaintext passwords, such the GSSAPI mechanism described in
      [SASL] and/or the [DIGEST-MD5] mechanism.

The reason the IESG would like to see this change made  should be obvious, but
in case it is not: The IESG wants to mandate the use of mechanisms that insure
password snooping isn't possible but recognizes that there are many ways to do
this besides TLS: SSH, VPNs, physical network security, etc.

How do people feel about making this change?

				Ned