Mark Crispin wrote: > OK, I'm trying to digest all of this. > > It seems clear to me that TLS+AUTH=PLAIN will be a solution, and will be > required of all IMAP server implementations. I have not seen any > objection to either "TLS+AUTH=PLAIN is a solution" or "TLS+AUTH=PLAIN is > required of all server implementations." > > What is under debate is whether or not TLS+AUTH=PLAIN is *the* solution. > > Is a client is required to implement TLS+AUTH=PLAIN? > > If the answer is "yes", we have the option of declaring the problem > solved, put it in the document, and submit to IESG. > > If the answer is "no", then we must select one or more AUTH=xxx methods > that are MANDATORY for server implementation. A client, on the other > hand, only needs to implement one of the server-mandatory methods. > > After careful consideration, I have concluded that if Kerberos (GSSAPI and > KERBEROS_V4) is not suitable, then CRAM-MD5 and DIGEST-MD5 are also > unsuitable. Like Kerberos, CRAM-MD5 and DIGEST-MD5 make demands upon the > server's authentication capabilities that some servers may be unable to > fufill. Kerberos requires the services of a KDB, and CRAM-MD5 and > DIGEST-MD5 require the server to have a plaintext equivalent of the > password.
> Modern operating systems store passwords in a one-way encrypted form. If > a server implementation is required to use the host operating system's > userids and passwords (particularly if a system call is needed to log in), > then CRAM-MD5 and DIGEST-MD5 are unimplementable. > > This, by itself, indicates to me that we should rule out making either > CRAM-MD5 or DIGEST-MD5 be mandatory to implement on a server. But this is not an excuse not to implement it on client side. > I therefore recommend to the group that we declare that: > . *the* solution is TLS+AUTH=PLAIN > . TLS+AUTH=PLAIN is mandatory to implement on both client and server > . the problem is solved > and abandon alternatives. I am afraid that this will discourage people from implementing SASL authentication and this is a very bad thing, IMHO. I agree with Lyndon (not because we work for the same company), most of the times a lightweight non-plaintext authentication mechanisms is sufficient. DIGEST-MD5 might be complex, but it is still easier to implement from scratch than TLS. I don't mind Chris proposal of not using CRAM-MD5 as mandatory to implement (or we the document can mention it as MAY). Having said that I would like to leave at least one non-plaintext SASL mechanism as mandatory to implement. So, what about Clients: MUST TLS+AUTH=PLAIN and DIGEST-MD5 Servers: MUST TLS+AUTH=PLAIN or DIGEST-MD5 What client implementors think? I don't feel that I have a moral ground to make a decision for client implementors, as I currently not writing one, although I used to a long time ago (and it had DIGEST-MD5 support ;-)). Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________
