Assuming that we set "TLS+AUTH=PLAIN" as the "mandatory to implement" answer for IESG, I have two questions:
1) Can a compliant server implementation be built without TLS support? In particular, UW's pre-built imapd binaries do *NOT* have TLS support because our lawyers' interpretation of US law is that we may *NOT* legally distribute crypto binaries. Similiarly, UNIX Pine binaries also do have have TLS support. PC Pine binaries do, but they use the SSPI features in the operating system and do not have crypto code themselves. Any IESG requirement which violates law is null and void. That's just common sense. 2) Can a compliant server implementation refuse AUTH=PLAIN for administrative reasons? Suppose a site decides that, by policy, Kerberos is the only permitted authentication mechanism and that passwords must NEVER be sent to any IMAP server. If the answer to both is "yes" (and I sure hope so!!!), then we need to have some recommendations as to what should be implemented in addition to the so-called "mandatory" ones. I would therefore recommend that clients and servers SHOULD implement as many additional authentication mechanisms as possible, with particular emphasis on: KERBEROS_V4, GSSAPI, CRAM-MD5, DIGEST-MD5. I would also note that failure to implement any of these mechanisms may result in loss of interoperability. What would really be nice is if there was some simple non-crypto algorithm that, given server knowledge of: . a UNIX-style encrypted password . a one-time "nonce" generated by the server and client knowledge of: . the actual password . the server's one-time "nonce" and eavesdropper knowledge of: . the algorithm (or algorithms if client and server uses different ones) . the UNIX-style encrypted password . the server's one-time "nonce" . the client's response that the client could respond to the server in a way that proves the client's knowledge of the password without disclosing the password to the eavesdropper. If I knew how to do this, I would be running to the patent office and preparing my retirement making merry "ka-CHING!" sounds... :-) -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
