LOGIN & PLAIN (was Re: regarding registry of acceptable SASL types)

[Chris Newman <Chris.Newman@xxxxxxxxxxxx>]

On Tue, 15 Sep 1998, Lyndon Nerenberg wrote:
> It's a non-standard Netscape hack. Use PLAIN instead.
> 
> (LOGIN's pretty trivial to figure out if you decode the base64 string the 
> client sends.)

Both LOGIN and PLAIN are clear text password mechanisms.

Mark Crispin originated LOGIN in the c-client source code, and Netscape
and Microsoft copied it from there.  I was under the mistaken impression
that Mark did it as a prototype SASL mechanism for his c-client SASL model
and didn't intend to use it heavily.  Given that, I designed the PLAIN
mechanism (most recent version is in draft-newman-tls-imappop-04.txt) with
input from others to eliminate the extra round trip, support
internationalization, and include an authorization identity.

It retrospect, it sucks that we have both PLAIN and LOGIN and I would
never have developed PLAIN if I had known LOGIN was going to get widely
deployed.  But given we have both deployed, I prefer PLAIN for the three
reasons above and since there's a spec.  Our product ships with LOGIN SASL
support turned off on the grounds there is no spec for it so we can't be
sure we'll interoperate with someone else's idea of LOGIN.

Mark prefers LOGIN and doesn't seem interested in implementing PLAIN.  It
is my understanding that he prefers the extra round-trip on the grounds
that it separates the user name from the password in the network stream. 

C'est la vie.

		- Chris

P.S. draft-newman-tls-imappop requires use of a strong privacy layer in
combination with PLAIN.  This is a case where IESG rules cause the spec to
require correct security behavior even if the marketplace isn't ready yet.