Subject: Clear text authentication in SASL?

From: "Jeff Stephenson (Exchange)" <[email-masked]>
Date: Fri, 2 May 1997 15:19:33 -0700

Has anybody been working on or thinking about a clear-text
userid/password authentication mechanism for SASL?  Combined with an
already secured connection via, say, STARTTLS, it would provide a simple
way to obtain a decent level of authentication in a secure manner.  In
SMTP it might look like

   S: 220 mail.whitehouse.gov ready
   C: EHLO elvis.graceland.com
   S: 250-mail.whitehouse.gov
   S: 250-TLS
   S: 250 AUTH=CLEAR
   C: STARTTLS SSL3.0
   S: 220 Go ahead with SSL3.0
   <start TLS session - from here on we're secure>
   C: AUTH CLEAR userid password
   S: 235 Clear text authentication successful
   ...

---

From: Mike Macgirvin <[email-masked]>
Date: Fri, 2 May 1997 16:10:25 -0700 (PDT)

>    S: 235 Clear text authentication successful

	This is likely to raise some flak. There is a "de-facto" plaintext auth
method called "LOGIN" which is used already by several vendors (including us).

The protocol is:

C: AUTH LOGIN
S: 220 ok (or server profile defined response)
C: <base64 username>
S: 220 ok
C: <base64 password>
S: 235 you're in.

	...However, there are some purists who don't feel that plaintext logins
have any place in the modern world. I wholeheartedly agree; but counter that
they are the only thing we can easily deploy in an existing infrastructure
before raising the bar to other more secure methods; and which doesn't pass
_obvious_ plain text. The obfuscation is minor, but important; and this also
jibes with our SSL/TLS strategy. If the connection is secured, how the password
is presented is irrelevant. 

	AUTH LOGIN is used in (correct me if I get any of these wrong) Sun's
Solstice IMAP products, the UW IMAP server, NetManage's IMAP client, Sun's java
IMAP client, and Netscape's Messaging products. It was actually in common use
in the UW server long before "IMAP authentication" became "SASL" and started
requiring registration of methods; and it was never pulled into SASL because of
its politically incorrectness. I have absolutely no qualms supporting it; but
would like to see it standardized. Problem is I don't think we can pull off
registration of essentially a plaintext auth type in this day and age.

	With the exception of perhaps PKL, I haven't see any authenticators I
can really buy into. Customers won't touch CRAM once you let them know that the
stored secret is really no more secure than APOP. S/KEY doesn't scale well.
Kerberos and GSSAPI require additional heavy-duty security infrastructures
which aren't totally compatible with my company's products.

---

From: Dennis Glatting <[email-masked]>
Date: Fri, 2 May 97 20:48:22 -0700

From: "Jeff Stephenson (Exchange)" <[email-masked]>
Date: Fri, 2 May 1997 15:19:33 -0700

> userid/password authentication mechanism for SASL?
> Combined with an already secured connection via, say,
> STARTTLS, it would provide a simple way to obtain a decent level
> of authentication in a secure manner.  In SMTP it might look like
>

That could be done, but would we want to?

The question is how do you limit combinations?  For example, an
identifier/password scheme protected by TLS seems
reasonable (unless you have client-side certificates--in
which case it makes little sense), but do you want allow
identifier/password then TLS?  What if you had three
authentication schemes? That's fifteen combinations!
Managing this can quickly get out of hand and combinations
can weaken each other.

My answer is combinations are not always a good idea and
avoiding bad combinations can be difficult. In this case,
client-side certificates is a reasonable authorization
scheme as would an SPEKE extension.

-dpg

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 5 May 1997 13:56:04 -0400 (EDT)

The "LOGIN" mechanism is defective in two ways: it does not permit the
negotiation of an authorization ID separate from the authentictation
ID and it would seem to require an unnecessary network round trip.
It's also extremely poorly named.

-- 
_.John Gardiner Myers	Internet: [email-masked]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 05 May 1997 12:13:33 -0600

Didn't Jeff Schiller state that the IETF was going to bounce any new
security/authentication schemes incorporating cleartext passwords?

Personally, I don't see that problem with using an existing non-cleartext
authentication scheme inside of an encrypted pipe. Both ends have to 
(should)
support this for situations where an encrypted pipe is not available.

Just FYI, the next release of our IMAP and IMSP servers will default to
having all cleartext authentication schemes turned off -- the site admin
will have to take explicit steps to turn on non-secure "security." A
not-too-distant release of our IMAP4 client will also let you disable
cleartext authentication schemes.

I really don't see any reason at all to continue to introduce flawed
authentication schemes such as AUTH LOGIN.

--lyndon

---

From: Mike Macgirvin <[email-masked]>
Date: Mon, 5 May 1997 11:27:31 -0700 (PDT)

> It's also extremely poorly named.

Agreed. I think it should be fixed, and in so doing will likely need a new
name. My last message on the subject was mostly to provide some historical
context w/r/t plaintext mechanisms.

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 5 May 1997 14:59:06 -0400 (EDT)

> That could be done, but would we want to?

Yes.  TLS doesn't provide all of the functionality needed for
appliation-level security, so there needs to be a mechanism to get
what's not there.

> The question is how do you limit combinations? 

You have to keep an eye on your minimum security requirements and not
offer choices weaker than your security policy.

> For example, an
> identifier/password then TLS?

Allowing identifier/password than TLS is no weaker than allowing just
identifier/password alone.  It's also not much stronger.

If identifier/password alone is weaker than allowed by policy, but
identifier/password under TLS is allowed by policy, then don't allow
identifier/password until TLS has been negotiated on with the strength
required by policy.

---

From: Dennis Glatting <[email-masked]>
Date: Mon, 5 May 97 18:17:38 -0700

Date: Mon,  5 May 1997 14:59:06 -0400 (EDT)
From: John Gardiner Myers <[email-masked]>

> appliation-level security, so there needs to be a mechanism to
> get what's not there.
>

What does application level security need, that
identifier/password provides, but isn't provided by
client-side certs?

-dpg

---

From: "Jack De Winter" <[email-masked]>
Date: Tue, 06 May 1997 11:44:05 -0400

>identifier/password provides, but isn't provided by

Say you use TLS to negotiate certificates.  One of them may
be the accounts that you are authorized to access the system
on.  Say jack, webmaster, and mailmaster for arguments sake.
You still don't know which one of these roles you are going
to assume from the application's viewpoint.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)

---

From: Dennis Glatting <[email-masked]>
Date: Tue, 6 May 97 14:35:53 -0700

Date: Tue, 06 May 1997 11:44:05 -0400
Subject: Re: TLS/SASL relationship

> Say you use TLS to negotiate certificates.  One of them may be the
> accounts that you are authorized to access the system on.  Say
> jack, webmaster, and mailmaster for arguments sake. You still
> don't know which one of these roles you are going to assume from
> the application's viewpoint.
>

Okay, I accept that, but I'm having difficulty with the
concept of using one or more authentication technologies
(i.e., SASL) within a technology that supports good
authentication (TLS).

If SASL's role is authentication then why use TLS? The TLS
client cert has no value and, probably, the server's doesn't
either. What is provided by TLS, then, is merely an encrypted
tunnel, which is not using TLS to its potential and can be done
with less complexity and bulk.

If SASL's role is identification of role then you only need a
fraction of SASL, i.e., only an identifier. The remainder of
SASL's functionality--as far as I can tell--is useless, i.e.,
it doesn't make sense to use GSSAPI, Kerberos, CRAM, and other
technologies identifiable by SASL when the session is
encapsulated by TLS. So what else is there other than
identifier/password and, if the tunnel is mutually
authenticated, why have a password?

-dpg

---

From: Chris Newman <[email-masked]>
Date: Tue, 06 May 1997 15:03:17 -0700 (PDT)

> It's also extremely poorly named.

Another flaw is that it opens up the possiblity of failing after the user
name is sent but before the password is sent.  This can reveal
information about what users are on the system to an attacker.

---

From: Chris Newman <[email-masked]>
Date: Tue, 06 May 1997 15:30:28 -0700 (PDT)

The TLS/SASL relationship is as follows:

TLS needs at least the SASL EXTERNAL mechanism to work with an application
requiring client authentication (e.g. anything other than HTTP).

Simple SASL mechanisms (e.g. CRAM-MD5, potentally a cleartext password
mechanism) benefit from using TLS's encrypted tunnel features to hide
the actual content of the connection. This can be deployed without
changing the client authentication framework and thus is a useful
combination.

Complete SASL mechanisms (e.g. Kerberos) never need TLS.

>From an architectural standpoint, I'd prefer to always use a complete SASL
mechanism and never use TLS.  But that ignores the following realities:

(1) There are a number of legacy client authentication frameworks which
work, but can't be changed easily and don't support encryption.

(2) There is a deployed server SSL public-key framework which works for
encryption.

(3) SSL/TLS has lots of hype and is what customers request now, even if
SASL would better serve their needs.

Recognizing this reality means that SASL and TLS will co-exist with
largely overlapping functionality for quite a while.

---

From: Mike Macgirvin <[email-masked]>
Date: Fri, 2 May 1997 16:10:25 -0700 (PDT)

The protocol is:

C: AUTH LOGIN

---

From: Dennis Glatting <[email-masked]>
Date: Fri, 2 May 97 20:48:22 -0700

-dpg

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 5 May 1997 13:56:04 -0400 (EDT)

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 05 May 1997 12:13:33 -0600

--lyndon

---

From: Mike Macgirvin <[email-masked]>
Date: Mon, 5 May 1997 11:27:31 -0700 (PDT)

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 5 May 1997 14:59:06 -0400 (EDT)

---

From: Dennis Glatting <[email-masked]>
Date: Mon, 5 May 97 18:17:38 -0700

-dpg

---

From: "Jack De Winter" <[email-masked]>
Date: Tue, 06 May 1997 11:44:05 -0400

regards,
Jack

---

From: Dennis Glatting <[email-masked]>
Date: Tue, 6 May 97 14:35:53 -0700

-dpg

---

From: Chris Newman <[email-masked]>
Date: Tue, 06 May 1997 15:03:17 -0700 (PDT)

---

From: Chris Newman <[email-masked]>
Date: Tue, 06 May 1997 15:30:28 -0700 (PDT)