re: Further IESG feedback on draft-crispin-imapv-17.txt
Mark Crispin <MRC@cac.washington.edu> Fri, 20 September 2002 20:23 UTC
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8KKNRF05966 for ietf-imapext-bks; Fri, 20 Sep 2002 13:23:27 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (clane@panda.com [206.124.149.114]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8KKNPk05961 for <ietf-imapext@imc.org>; Fri, 20 Sep 2002 13:23:25 -0700 (PDT)
Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id NAA08318; Fri, 20 Sep 2002 13:23:16 -0700 (PDT)
Date: Fri, 20 Sep 2002 13:18:29 -0700
From: Mark Crispin <MRC@cac.washington.edu>
Subject: re: Further IESG feedback on draft-crispin-imapv-17.txt
To: ned.freed@mrochek.com
cc: IMAP Mailing List <imap@u.washington.edu>, IMAP Extensions WG <ietf-imapext@imc.org>, ned.freed@mrochek.com, paf@cisco.com, jis@mit.edu
In-Reply-To: <01KMOKNGXORY00628S@mauve.mrochek.com>
Message-ID: <MailManager.1032553109.220.mrc@Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
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>
OK, here is what I have for draft 18, based upon all the comments which I have read. Please try to give me feedback on whether or not this is will be acceptable to the IESG as soon as possible. I'd like to send draft 18 by the end of the day today and hopefully not need a draft 19. In AUTHENTICATE command, change: 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. to: Note: a server implementation MUST implement a configuration in which it does NOT permit any plaintext password mechanisms, unless either the STARTTLS command described in [IMAP-TLS] has been negotiated or some other mechanism that protects the session from password snooping has been provided. Server sites SHOULD NOT use any configuration which permits a plaintext password mechanism without such a protection mechanism against password snooping. 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. In LOGIN command, add: A server implementation MUST implement a configuration in which it advertises the LOGINDISABLED capability described in [IMAP-TLS] and does NOT permit the LOGIN command, unless either the STARTTLS command described in [IMAP-TLS] has been negotiated or some other mechanism that protects the session from password snooping has been provided. Server sites SHOULD NOT use any configuration which permits the LOGIN command without such a protection mechanism against password snooping. A client implementation MUST NOT send a LOGIN command if the LOGINDISABLED capability is advertised. In Security Considerations, add: A server implementation MUST implement a configuration in which, at the time of authentication, requires that: (1) The STARTTLS command command described in [IMAP-TLS] has been negotiated. OR (2) Some other mechanism that protects the session from password snooping has been provided. OR (3) The following measures are in place: (a) The LOGINDISABLED capability as described in [IMAP-TLS] is advertised, and [SASL] mechanisms (such as PLAIN) which use plaintext passwords are NOT advertised in the CAPABILITY list. AND (b) The LOGIN command returns an error even if the password is correct. AND (c) The AUTHENTICATE command returns an error with all [SASL] mechanisms which use plaintext passwords, even if the password is correct.
- re: Further IESG feedback on draft-crispin-imapv-… ned.freed
- RE: Further IESG feedback on draft-crispin-imapv-… Mark Crispin
- RE: Further IESG feedback on draft-crispin-imapv-… ned.freed
- RE: Further IESG feedback on draft-crispin-imapv-… Larry Osterman
- re: Further IESG feedback on draft-crispin-imapv-… Mark Crispin
- Re: Further IESG feedback on draft-crispin-imapv-… ned.freed
- Re: Further IESG feedback on draft-crispin-imapv-… Mark Crispin
- Re: Further IESG feedback on draft-crispin-imapv-… ned.freed
- Re: Further IESG feedback on draft-crispin-imapv-… Cyrus Daboo
- Re: Further IESG feedback on draft-crispin-imapv-… Jeffrey I. Schiller
- Re: Further IESG feedback on draft-crispin-imapv-… Jeffrey I. Schiller
- Re: Further IESG feedback on draft-crispin-imapv-… Mark Crispin
- Re: Further IESG feedback on draft-crispin-imapv-… Steve Hole
- Re: Further IESG feedback on draft-crispin-imapv-… Chris Newman
- RE: Further IESG feedback on draft-crispin-imapv-… Mark Crispin
- RE: Further IESG feedback on draft-crispin-imapv-… Larry Osterman
- Further IESG feedback on draft-crispin-imapv-17.t… ned.freed