re: New version of TLS + IMAP/POP/ACAP draft

On Mon, 23 Nov 1998 14:25:13 -0800 (PST), Chris Newman wrote:
> Please suggest specific replacement
> text so we may debate the relative merits.

OK, fair enough.  My proposed changes are very simple and small.  I also
corrected some syntax nits:

Section 6:
     This defines the "PLAIN" SASL mechanism for use with ACAP and other
     protocols with no clear-text login command.  The PLAIN SASL mechanism
     MUST NOT be used unless strong TLS encryption or an equivalent strong
     encryption layer is also in use.

     If other words, if a strong encryption layer is not currently in use
     in the session, a server MUST NOT advertise the PLAIN SASL mechanism
     and MUST NOT accept an attempt to authenticate via the PLAIN SASL
     mechanism; and furthermore a client MUST NOT attempt to authenticate
     via the PLAIN SASL mechanism.

Section 9:
     Use of clear-text login mechanisms (e.g., the IMAP4 LOGIN command,
     POP3 PASS command or the PLAIN mechanism) without a suitable
     encryption layer, such as that provided by TLS, expose the user's
     password to a common network eavesdropping attack.  Therefore, the
     PLAIN mechanism MUST NOT be used unless a suitable encryption layer,
     such as that provided by TLS, is in use.

The significant change is a flat prohibition on the use of PLAIN outside of an
encryption layer.

> > You have admitted that a POP3 server which does not have PASS, or an IMAP
> > server which does not have LOGIN, will not function well in the
> > overwhelming majority of contemporary installations.
> I strongly disagree.  It won't be long before all IMAP clients under
> active development will support either CRAM-MD5 or TLS.

The key word is "contemporary".  Note, however, that "support CRAM-MD5" does
not necessarily mean that CRAM-MD5 is desirable, due to the requirement to
store (the equivalent of) plaintext passwords on the server.

To make matters worse, on NT a server that exports user accounts must have the
plaintext password available to it to do the LogonUser() call.

I have CRAM-MD5 support code available.  But there is no way that I can
guarantee that it will be on all installations of my server, because CRAM-MD5
can not export UNIX or NT passwords.  Unless the site creates a CRAM-MD5
database, imapd can not offer CRAM-MD5.

Why don't you tell me how to do CRAM-MD5 authentication if the only available
database is a UNIX password?  If you agree that CRAM-MD5 with a UNIX password
is impossible, then please acknowledge that the problem exists.

And no comments about "obsolete software" either.  There are a lot of sites
which install imapd as an afterthought or as a favor for a handful of users,
and not as a primary resource.  If imapd can't play ball with what's there,
and especially if it presents a new management burden, it won't get installed.

> At that point,
> this will be a very important option.  Futhermore, it is currently the
> correct option, IMHO, for connections from outside the local network and
> is the option I use for such connections when I travel.

If by "option" you mean "the ability to disable all plaintext authentication",
I already have that in my server.  It's a simple build option.

Nevertheless, this is best done in the client, not the server.  In a
development environment where plug-ins are increasingly replacing wired-in
code, a client should not be expected to have a list of all the "secure" and
"insecure" authentication mechanisms.

> > That is not an excuse for allowing PLAIN in a non-TLS session.  The
> > requirement already exists for doing a new CAPABILITY command after
> > STARTTLS.
> Why, then, do you feel compelled to allow PLAIN in a non-TLS session?

I don't.  PLAIN is part of the TLS plug-in, doesn't exist at all unless built
with the TLS plug-in, with declines to work unless TLS is in use.

The problem that I face is that it opens the door for you (or some other
vendor) to:
 1) badmouth my client for "using the insecure LOGIN command instead of SASL"
    only to have it turn out that the supposed "secure SASL" way is PLAIN
    outside of a TLS session.
 2) badmouth my server for "requiring the insecure LOGIN command and not
    having SASL" only to have it turn out that the reason why SASL isn't
    available is that there aren't any secure authenticators available for the
    server to use -- and that the proferred "solution" is to use PLAIN.

I resent being put into this position, and vehemently oppose the implication
that unencrypted PLAIN is a replacement for LOGIN.

Stated another way; LOGIN must remain the *sole* standard means of unencrypted
plaintext authentication, and no news ones should be added.

> Personally, I'd like to get rid of all unencrypted clear-text mechanisms
> (particuarly the undocumented ones).

That's fine.  Just don't to add a new one into standards-track.

> But when writing a spec my
> preference is to match the spec as closely to real-world deployed code as
> possible while making the security considerations clear.

In that case, why did you feel the need to write PLAIN, given that LOGIN has
been in real-world deployed code for 3 years?  PLAIN has only two reasons to
exist, both rather weak:
 1) It requires fewer RTTs than the LOGIN mechanism.  But the same can be said
    about the LOGIN command.  All existing IMAP software supports the LOGIN
    command.
 2) It allows a separate "authorization" and "authentication" user.  But that
    same function could have been provided via syntax in the user or password
    field with the LOGIN command or the LOGIN mechanism.  PLAIN makes it
    mandatory to specify both users, even on systems where the distinction is
    meaningless; and furthermore it adds the burden of having to implement the
    distinction to the point of giving an error when they are different.

The disadvantage of PLAIN is that, as a proposed standards-track extension, it
creates *two* standards-track insecure mechanisms which have to be secured.

> While we're on the subject, why does your code permit the undocumented
> LOGIN mechanism when TLS isn't active?

The LOGIN mechanism was written 3 years ago, and thus predates TLS IMAP.  Nor
is the LOGIN mechanism standards-track, nor was any attempt ever made to do
so, because I tried to follow the rules about not trying to standardize new
insecure login mechanism.  Because it is not standards-track, the LOGIN
mechanism can be deleted trivially.

PLAIN is an attempt to circumvent those rules.  Unless PLAIN forbids its usage
in an unencrypted session, it is a new insecure login mechanism and directly
violates IETF security policy.

All you have to do it make PLAIN follow the rules.

> Actually a programmer just has to read the third paragraph of
> section 6, glance at the first line of the formal syntax or read the
> example to get this right.

When one is reading through piles of stuff, "authentication" and
"authorization" tend to blur together, particularly when one is used to most
"thing and optional variant" having the optional part come after the thing
instead of before it.

It's an interoperability booby-trap in the PLAIN specification, particularly
since there are server implementations that will accept "user NUL NUL" as
equivalent to "NUL user NUL".  Yes, it's too late to change it now; but in the
future, I wish you will remember that well designed protocols make it easy to
do the right thing and hard to do the wrong thing.