Subject: SASL questions: krb4, cleartext, code

From: Ken Raeburn <[email-masked]>
Date: Thu, 22 May 1997 01:58:50 -0400 (EDT)

Hi.  I've just joined the list.  Sorry if I'm rehashing anything that
hasn't made it to the mail-archive web site.

I've been looking over the SASL draft 10, with an eye towards using it
to negotiate authentication in CVS.  A few comments and questions have
come to mind.

Kerberos 4:

You require three round-trips to complete the authentication scheme.
But it seems to me that two round-trips should suffice, if client data
can be sent in the first message.  Is there some reason (other than
historical, relating to IMAP) that I'm missing?  I suppose it's too
late to change it....

Cleartext-password mechanisms:

I don't think there's any way I can get out of continuing to support
this in some form.  (I mean, really cleartext, not just passwords sent
over SSL-protected sessions.)  It's not secure, but the reality is
that it gets used.

Has someone confirmed, as Lyndon Nerenberg thought:
> Didn't Jeff Schiller state that the IETF was going to bounce any new
> security/authentication schemes incorporating cleartext passwords?

That would be unfortunate, since the schemes will exist anyways.  And
a mechanism for SASL would be more of an attempt to make such schemes
fit into a general authentication-negotiation protocol than an attempt
to promote insecure mechanisms.

Code:

Is there a publicly available implementation I can try out?  If not to
actually incorporate into CVS, at least to use for interoperability
testing?

Ken

---

From: [email-masked]
Date: Thu, 22 May 1997 19:12:09 +0200

FYI, the IESG just passed a protocol action (recycle at Draft
due to procedural issues; otherwise it would have been Full)
that included cleartext passwords: OSPF.

The relevant section of the document says:

        Simple password authentication guards against routers
        inadvertently joining the routing domain; each router must first
        be configured with its attached networks' passwords before it
        can participate in routing.  However, simple password
        authentication is vulnerable to passive attacks currently
        widespread in the Internet (see [Ref16]). Anyone with physical
        access to the network can learn the password and compromise the
        security of the OSPF routing domain.

It's not illegal to put out passwords, it's just illegal to say
that they provide security.
(But this had the advantage of being a deployed mechanism; it's
dangerous to assume that SASL gets the same liberty)

BTW: One reason for doing CRAM was the shudders people got when
they were thinking about passing cleartext passwords inside RC2/40bit
encrypted channels.

                   Harald A

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 22 May 1997 13:11:25 -0600

> that included cleartext passwords: OSPF.

I don't know if I would call that a "password." It's more like a
"co-operative routing domain identifier."

--lyndon

Lyndon Nerenberg
Sr. Software Developer
Server Products

---

From: Chris Newman <[email-masked]>
Date: Thu, 22 May 1997 15:24:35 -0700 (PDT)

> over SSL-protected sessions.)  It's not secure, but the reality is

I absolutely think we need such a mechanism.  I have no problems if the
definition states SHOULD NOT be used unless strong encryption (e.g.
greater than 56 bit key) is active on the channel.  I also wouldn't object
if it said "clients which implement this MUST also implement a stronger
mechanism such as CRAM-MD5."  I also think this mechanism shouldn't be in
the SASL base spec (so it can be depricated if we reach authentication
paradise).

I'm all for discouraging cleartext passwords, but it will be a long time
before we can get rid of them from a practical standpoint.  Forcing people
to implement the SASL framework in order to use cleartext passwords is
worth doing, IMHO.

---

From: [email-masked]
Date: Fri, 23 May 1997 10:09:17 +0200

> "co-operative routing domain identifier." 

That's what it is - same as the "community" string in SNMPv1.
But it's called a password, so it's possible to use the same argument
for something else also called a password.

Have fun!

            Harald A

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 23 May 1997 11:53:36 -0400

> That would be unfortunate, since the schemes will exist anyways.  

See http://www.iab.org/iab/secrets.html, which is the result of an IAB
workshop on security..

There was consensus among the attendees that plaintext passwords need
to be killed completely, and that one way to accomplish this is to
avoid "blessing" protocols which require/use them..

The verdict of the workshop:

> To be Killed: Plaintext Passwords
>
> Any protocol that relies on the transmission of unencrypted
> passwords is terminally broken. Any protocol that puts confidential
> information in public places (such as URLs) is similarly broken.

I see no reason to dispute this.

					- Bill

---

From: [email-masked]
Date: Thu, 22 May 1997 19:12:09 +0200

Harald A

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 22 May 1997 13:11:25 -0600

--lyndon

Lyndon Nerenberg
Sr. Software Developer
Server Products

---

From: Chris Newman <[email-masked]>
Date: Thu, 22 May 1997 15:24:35 -0700 (PDT)

---

From: [email-masked]
Date: Fri, 23 May 1997 10:09:17 +0200

Have fun!

            Harald A

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 23 May 1997 11:53:36 -0400

- Bill

To: Ken Raeburn <[email-masked]>
Cc: [email-masked]
Subject: Re: SASL questions: krb4, cleartext, code 
Date: Fri, 23 May 1997 11:53:36 -0400
From: Bill Sommerfeld <[email-masked]>
Sender: [email-masked]

					- Bill

From: [email-masked]
To: Lyndon Nerenberg <[email-masked]>
cc: Ken Raeburn <[email-masked]>, [email-masked]
Subject: Re: SASL questions: krb4, cleartext, code 
Date: Fri, 23 May 1997 10:09:17 +0200
Sender: [email-masked]

[email-masked] said:
> I don't know if I would call that a "password." It's more like a =

> "co-operative routing domain identifier." =

Have fun!

            Harald A

Date: Thu, 22 May 1997 15:24:35 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: SASL questions: krb4, cleartext, code
To: Ken Raeburn <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

To: [email-masked]
cc: Ken Raeburn <[email-masked]>, [email-masked]
Subject: Re: SASL questions: krb4, cleartext, code 
Date: Thu, 22 May 1997 13:11:25 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

--lyndon

Lyndon Nerenberg
Sr. Software Developer
Server Products

From: [email-masked]
To: Ken Raeburn <[email-masked]>
cc: [email-masked]
Subject: Re: SASL questions: krb4, cleartext, code 
Date: Thu, 22 May 1997 19:12:09 +0200
Sender: [email-masked]

                   Harald A

Date: Thu, 22 May 1997 01:58:50 -0400 (EDT)
From: Ken Raeburn <[email-masked]>
To: [email-masked]
Subject: SASL questions: krb4, cleartext, code
Sender: [email-masked]

Kerberos 4:

Code:

Ken

From: "Jeff Stephenson (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Response codes for SMTP servers requiring auth/security
Date: Wed, 14 May 1997 12:14:07 -0700
Sender: [email-masked]

There are many cases in which an SMTP server might wish to require that
all connections to it be secure, authenticated, or both.  In those cases
it would be nice if the server could reject SMTP commands with a more
informative response code than "554 Transaction failed" so that the
client software could know to authenticate or initiate security.

I think that such reply codes should be included in the SMTP-AUTH draft.
A provision has been added to the most recent SMTP-SSL draft
(draft-hoffman-smtp-ssl-02.txt) for this, though the reply code
specified there will probably change.  The SMTP-AUTH and SMTP-SSL drafts
should coordinate on this so that there is a generic "Secure channel
required" reply code.  I would suggest something along the lines of:

555  Secure channel required
556  Client authentication required

Another approach would be to go to the enhanced status codes of RFC 1893
- codes in the 5.7.x category would seem appropriate there.

-- jeff

Date: Thu, 08 May 1997 13:45:31 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: draft-myers-auth-sasl-10.txt
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

Comments on the new draft:

Section 3, second paragraph say "The command has a single argument."
Perhaps this should say "a single required argument" to be more precise.

Section 3, 7th paragraph mentions "null string".  Is this synonymous with
"empty string"?

Section 6.2 has some quoted strings which are wrapped poorly.  Using the
nroff "\%" prefix in front of those quoted strings might help.

Section 8, third paragraph.  Should "an SASL" be "a SASL"?  I'm also
unclear of exactly what restrictions this paragraph places on the
mechanism name.

In any discussion of listing available mechanisms and the security impact
thereof necessary?

Otherwise the spec looks great.

Date: Tue, 06 May 1997 15:30:28 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: TLS/SASL relationship
To: Dennis Glatting <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

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.

Date: Tue, 06 May 1997 15:03:17 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Clear text authentication in SASL?
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Mon, 5 May 1997, John Gardiner Myers wrote:
> 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.

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: Dennis Glatting <[email-masked]>
Date: Tue,  6 May 97 14:35:53 -0700
To: "Jack De Winter" <[email-masked]>
Subject: Re: TLS/SASL relationship
cc: John Gardiner Myers <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

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

> At 06:17 PM 5/5/97 -0700, Dennis Glatting wrote:
> >
> >What does application level security need, that
> >identifier/password provides, but isn't provided by
> >client-side certs?
>
> 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

Date: Tue, 06 May 1997 11:44:05 -0400
To: [email-masked], John Gardiner Myers <[email-masked]>
From: "Jack De Winter" <[email-masked]>
Subject: Re: TLS/SASL relationship
Cc: [email-masked]
Sender: [email-masked]

At 06:17 PM 5/5/97 -0700, Dennis Glatting wrote:
>
>Date: Mon,  5 May 1997 14:59:06 -0400 (EDT)
>From: John Gardiner Myers <[email-masked]>
>
>> Dennis Glatting <[email-masked]> writes:
>> > 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.
>>
>
>What does application level security need, that
>identifier/password provides, but isn't provided by
>client-side certs?

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: Mon,  5 May 97 18:17:38 -0700
To: John Gardiner Myers <[email-masked]>
Subject: Re: TLS/SASL relationship
cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

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

> Dennis Glatting <[email-masked]> writes:
> > 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.
>

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

-dpg

Date: Mon,  5 May 1997 14:59:06 -0400 (EDT)
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Subject: TLS/SASL relationship
Sender: [email-masked]

Dennis Glatting <[email-masked]> writes:
> 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 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?

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.

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

Date: Mon, 5 May 1997 11:27:31 -0700 (PDT)
From: Mike Macgirvin <[email-masked]>
Reply-To: Mike Macgirvin <[email-masked]>
Subject: Re: Clear text authentication in SASL?
To: John Gardiner Myers <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

> 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.

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. 

To: John Gardiner Myers <[email-masked]>
cc: [email-masked]
Subject: Re: Clear text authentication in SASL? 
Date: Mon, 05 May 1997 12:13:33 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

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

Date: Mon,  5 May 1997 13:56:04 -0400 (EDT)
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Subject: Re: Clear text authentication in SASL?
Sender: [email-masked]

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

Date: Mon, 5 May 1997 09:16:10 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: New mailing list for discussing applications over TLS
Sender: [email-masked]

As I was revising my SMTP over TLS draft and looking at some of the issues
with creating IMAP over TLS and POP over TLS drafts, I realized that it
would be good to have a place where people could discuss the issues. After
the discussion of the first SMTP/TLS draft, I realize that the TLS mailing
list isn't the best place to have this discussion because there aren't many
apps people here.

This issue directly affects many SASL implementors, inasmuch as SASL
doesn't handle TLS directly. Thus, SASL folk might be interested in the
new list as well.

Thus, I've created a new mailing list for discussion of applications
running over TLS. This will keep the TLS folks from having to read the
debates between the apps folks about what is the best wording for the
"start TLS now" commands, and the apps folks from having to follow the
crypto stuff that goes on the TLS list.

The new list is called "[email-masked]", and you subscribe by
sending mail to:
     [email-masked]
with the single word:
     subscribe
in the body of the message. There is also a Web page for the list at
<http://www.imc.org/ietf-apps-tls> which will have links to the drafts
being discussed and so on.

I'll update the ietf-tls mailing list every so often about new things on
the other mailing list, and of course invite people to come over to the
list if they're interested in how the apps folks are doing with TLS.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Dennis Glatting <[email-masked]>
Date: Fri,  2 May 97 20:48:22 -0700
To: "Jeff Stephenson (Exchange)" <[email-masked]>
Subject: Re: Clear text authentication in SASL?
cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

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
>    ...
>

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

Date: Fri, 2 May 1997 16:10:25 -0700 (PDT)
From: Mike Macgirvin <[email-masked]>
Reply-To: Mike Macgirvin <[email-masked]>
Subject: Re: Clear text authentication in SASL?
To: "Jeff Stephenson (Exchange)" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

> 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
>    ...

	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. 

To: "Jeff Stephenson (Exchange)" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: "Jack De Winter" <[email-masked]>
Subject: Re: Clear text authentication in SASL?
Cc: "[email-masked]'" <[email-masked]>
Date: Fri, 2 May 1997 19:08:23 -0400
Sender: [email-masked]

At 03:19 PM 5/2/97 -0700, Jeff Stephenson (Exchange) wrote:
>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

I have to admit that John gave me this task and I am a touch behind.  I will
be sending in the draft on Monday as soon as I check something out with
John.

regards,
Jack

From: "Jeff Stephenson (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Clear text authentication in SASL?
Date: Fri, 2 May 1997 15:19:33 -0700
Sender: [email-masked]

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
   ...