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

["Larry Osterman" <[e-mail]>]

What's the standards track status on IMAP-TLS?  Won't citing it as a
reference tie the base standard to a subsidiary standard?  Other than
that nit, I personally like the wording.


Larry Osterman 



-----Original Message-----
From: Mark Crispin [mailto:[e-mail]] 
Sent: Friday, September 20, 2002 1:18 PM
To: [e-mail]
Cc: IMAP Mailing List; IMAP Extensions WG; [e-mail];
[e-mail]; [e-mail]
Subject: re: Further IESG feedback on draft-crispin-imapv-17.txt



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.