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

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

If you make this change, you instantly render the vast majority of the
installed base of IMAP servers non compliant (read: ALL).

And I think that would be a bad thing.

The reason for the SHOULD NOT was that it allowed existing
implementations enough weasel room to say they were compliant as long as
they allowed a configuration option to disallow plaintext
authentication, but the implementation could leave the plaintext
mechanism in the server (either enabled or disabled by default, at the
vendors desire).

If you make it a MUST NOT, then this implies that the plaintext
mechanism must be REMOVED except under the cover of an alternative
encryption mechanism.  And that breaks interoperability with the
majority of servers and clients that exist in the wild, which is a less
than optimal solution.



Larry Osterman 



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, September 19, 2002 10:34 AM
To: IMAP Mailing Liste; IMAP Extensions WG
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Further IESG feedback on draft-crispin-imapv-17.txt



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