Subject: regarding registry of acceptable SASL types

From: Jack De Winter <[email-masked]>
Date: Tue, 15 Sep 1998 11:08:04 -0400

I just checked the online sources for registered SASL types for
a type called "login" that is broadcasted as being accepted by
the exchange 5.0 server.  however, I cannot seem to find any
indication of what this "login" may be, nor specs as to how to
code for it...

any ideas?

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

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 15 Sep 1998 16:52:00 -0600

> indication of what this "login" may be, nor specs as to how to

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

---

From: Chris Newman <[email-masked]>
Date: Tue, 15 Sep 1998 16:49:00 -0700 (PDT)

> (LOGIN's pretty trivial to figure out if you decode the base64 string the 

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.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 15 Sep 1998 16:52:00 -0600

---

From: Chris Newman <[email-masked]>
Date: Tue, 15 Sep 1998 16:49:00 -0700 (PDT)

C'est la vie.

		- Chris

Date: Tue, 15 Sep 1998 16:49:00 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: LOGIN & PLAIN (was Re: regarding registry of acceptable SASL types)
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Lyndon Nerenberg <[email-masked]>
Cc: Jack De Winter <[email-masked]>, [email-masked]
Sender: [email-masked]

C'est la vie.

		- Chris

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 15 Sep 1998 16:52:00 -0600
To: Jack De Winter <[email-masked]>
Subject: Re: regarding registry of acceptable SASL types
Cc: [email-masked]
Sender: [email-masked]

Date: Tue, 15 Sep 1998 11:08:04 -0400
To: [email-masked]
From: Jack De Winter <[email-masked]>
Subject: regarding registry of acceptable SASL types
Sender: [email-masked]

any ideas?

regards,
Jack

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: Re: SMTP AUTH design-team meeting addendum
Date: Mon, 14 Sep 1998 16:01:00 -0700
Organization: Netscape Communications Corporation
Lines: 18
NNTP-Posting-Host: 208.12.60.63
Sender: [email-masked]

Chris Newman wrote:
> I agree.  But this wording is a bit subtle.  Here's another try:

The wording was subtle for several reasons:

1) This document is avoiding the political morass of specifying anything
that pertains only to message submission.  The suggested replacement
wording explicitly pertains to client UIs.  The only clients with UIs
are submission clients.  If there is wording which is specific for the
use of authentication in mail submission, it should go into the
submission document.

2) I do not want to recommend specific site policies or require
implementations to support specific site policies, unless such
recommendations or requirements are necessary for interoperability or
security.  The most the document should say is "if you want to have
such-and-such policy, the best technical way to implement it is to do
such-and-so."

Date: Tue, 08 Sep 1998 13:41:10 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: SMTP AUTH design-team meeting addendum
To: Chris Newman <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> I wish we could include a non-normative appendix with the three primary
> usage scenairos for SMTP AUTH in combination with port 25.  But I think
> this is better deferred for an applicability statement produced after SMTP
> Submit and the revised SMTP specs are published:

I agree. I also think that waiting for some experience in the field would be
wise. Based on numerous conversations with customers over the years I *think* I
know how people are going to use SMTP AUTH, but experience has shown that
deployment of a facility can lead to uses its designers and/or implementors
never thought of. And given the rapid uptake we're seeing on SMTP AUTH already
I suspect we'll be surprised at the things people come up with.

> An SMTP server on port 25 allows delivery to local users without
> authentication, but requires SMTP AUTH to relay mail to non-local users.

> An SMTP server on port 25 allows delivery to local users without
> authentication, but requires either SMTP AUTH or access from a trusted
> subnet to relay mail to non-local users.

> An SMTP server on port 25 is used only for delivery to local users, does
> not advertise SMTP AUTH and does not relay mail to non-local users.  A
> separate SMTP server on a different port or different machine is used to
> "submit" mail and requires the use of SMTP AUTH.

I'd put your #2 before your #1, but otherwise this seems like the right
set of initial applications for SMTP AUTH. But as I say, we may be surprised
at how this plays out.

				Ned

Date: Tue, 8 Sep 1998 12:35:47 -0700
To: Chris Newman <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: SMTP AUTH design-team meeting addendum
Sender: [email-masked]

At 11:31 AM -0700 9/8/98, Chris Newman wrote:

>On Fri, 4 Sep 1998, John Gardiner Myers wrote:
>> The SMTP AUTH spec should mention the principle that servers SHOULD NOT
>> advertise the existence of mechanisms whose use provide no benefit to
>> either client or server.  For example, consider a server which
>> implements CRAM-MD5 authentication, and has the policy that clients
>> connecting from certain networks have authorization which is not
>> affected by authentication.  Since CRAM-MD5 does not implement a
>> security layer, it does not itself provide a benefit to the client.  If
>> the policy for a given client is such that CRAM-MD5 authentication does
>> not affect the client's authorization, then the server should not
>> advertise the CRAM-MD5 mechanism to that particular client.
>
>I agree.  But this wording is a bit subtle.  Here's another try:
>
>If an existing SMTP server is reconfigured or upgraded to advertise
>authentication mechanisms, this is likely to cause new SMTP client UIs to
>begin prompting users for their passwords.  As such a behavior change may
>be undesirable at some sites, servers SHOULD NOT advertise client-only
>authentication mechanisms, such as CRAM-MD5, unless they grant the client
>additional delivery rights or services.

I think that might be too strong, since some sites might want all users
to authenticate (for tracking or policy).  How about:

If an existing SMTP server is reconfigured or upgraded to advertise
authentication mechanisms, this is likely to cause local upgraded SMTP
clients to prompt users for their passwords when sending mail.  This
behavior change may be undesirable at some sites, while other sites may
desire it.  Therefore, servers SHOULD be configurable to not advertise
authentication mechanisms which do not authenticate the server to the
client or include a privacy layer, such as CRAM-MD5, unless the client
is granted additional delivery rights or services by such
authentication.

In other words, the advertisement of authentication mechanisms by the
server (in the EHLO response) is likely to cause upgraded clients to
prompt users for passwords.  Some authentication mechanisms mutually
authenticate and/or include a security layer, while others do neither,
and thus may not provide any benefit to local clients.  Some sites may
want local users (within the trusted subnet) to always authenticate (as
a matter of policy), while other sites may want only non-local users to
authenticate.  Therefore, the server SHOULD be configurable to
advertise or not various supported authentication mechanisms which do
not provide direct client benefit.

>---
>
>I wish we could include a non-normative appendix with the three primary
>usage scenairos for SMTP AUTH in combination with port 25.  But I think
>this is better deferred for an applicability statement produced after SMTP
>Submit and the revised SMTP specs are published:
>
>An SMTP server on port 25 allows delivery to local users without
>authentication, but requires SMTP AUTH to relay mail to non-local users.
>
>An SMTP server on port 25 allows delivery to local users without
>authentication, but requires either SMTP AUTH or access from a trusted
>subnet to relay mail to non-local users.
>
>An SMTP server on port 25 is used only for delivery to local users, does
>not advertise SMTP AUTH and does not relay mail to non-local users.  A
>separate SMTP server on a different port or different machine is used to
>"submit" mail and requires the use of SMTP AUTH.

I'd perhaps add one more scenario, that of a trusted relay which is not
used for submission, and does advertise SMTP AUTH.

Date: Tue, 08 Sep 1998 11:31:50 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: SMTP AUTH design-team meeting addendum
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: [email-masked]
Sender: [email-masked]

On Fri, 4 Sep 1998, John Gardiner Myers wrote:
> The SMTP AUTH spec should mention the principle that servers SHOULD NOT
> advertise the existence of mechanisms whose use provide no benefit to
> either client or server.  For example, consider a server which
> implements CRAM-MD5 authentication, and has the policy that clients
> connecting from certain networks have authorization which is not
> affected by authentication.  Since CRAM-MD5 does not implement a
> security layer, it does not itself provide a benefit to the client.  If
> the policy for a given client is such that CRAM-MD5 authentication does
> not affect the client's authorization, then the server should not
> advertise the CRAM-MD5 mechanism to that particular client.

I agree.  But this wording is a bit subtle.  Here's another try:

If an existing SMTP server is reconfigured or upgraded to advertise
authentication mechanisms, this is likely to cause new SMTP client UIs to
begin prompting users for their passwords.  As such a behavior change may
be undesirable at some sites, servers SHOULD NOT advertise client-only
authentication mechanisms, such as CRAM-MD5, unless they grant the client
additional delivery rights or services.
---

I wish we could include a non-normative appendix with the three primary 
usage scenairos for SMTP AUTH in combination with port 25.  But I think
this is better deferred for an applicability statement produced after SMTP
Submit and the revised SMTP specs are published:

An SMTP server on port 25 allows delivery to local users without
authentication, but requires SMTP AUTH to relay mail to non-local users.

An SMTP server on port 25 allows delivery to local users without
authentication, but requires either SMTP AUTH or access from a trusted
subnet to relay mail to non-local users. 

An SMTP server on port 25 is used only for delivery to local users, does
not advertise SMTP AUTH and does not relay mail to non-local users.  A
separate SMTP server on a different port or different machine is used to
"submit" mail and requires the use of SMTP AUTH. 

		- Chris

Date: Fri, 04 Sep 1998 17:41:39 -0700
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Subject: SMTP AUTH design-team meeting addendum
Sender: [email-masked]

One point brought up at the meeting that I neglected to mention:

The desire for reactive authentication appears to come from a site
policy that relay requires authentication for clients connecting from
external networks, but is allowed without authentication for clients
connecting from internal networks.

The SMTP AUTH spec should mention the principle that servers SHOULD NOT
advertise the existence of mechanisms whose use provide no benefit to
either client or server.  For example, consider a server which
implements CRAM-MD5 authentication, and has the policy that clients
connecting from certain networks have authorization which is not
affected by authentication.  Since CRAM-MD5 does not implement a
security layer, it does not itself provide a benefit to the client.  If
the policy for a given client is such that CRAM-MD5 authentication does
not affect the client's authorization, then the server should not
advertise the CRAM-MD5 mechanism to that particular client.

Date: Fri, 04 Sep 1998 12:22:24 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: authmeth-02 && (Digest | CRAM-MD5)?
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Some observations:

It is very desirable to use the same password backend and authentication
source code for mail/news, directory and web services due to the large
number of products which combine two or more of these services.  This is
easiest to achieve if there is a common mandatory-to-implement baseline
mechanism. It is my understanding that the web community is committed to
the new HTTP digest mechanism.  The mail/news and directory areas aren't
firmly committed to a specific solution yet although there has been
significant movement in the direction of CRAM-MD5 because it's there.

CRAM-MD5 (and APOP and CHAP and the RFC 2069 HTTP-DIGEST) all lack a
client nonce.  This means a rogue server can easily get the password (with
a known plaintext attack) if an incautious client tries to authenticate to
that server.  It's my understanding that the number of clients which will
fall in the "incautious" class may be high.  I don't consider this attack
damning, but it happens to be easy to create a demonstration and use that
to rake a vendor over the coals.

Most people don't see CRAM-MD5 as the best choice for a baseline mechanism
in the long term even though it's much better than clear text.  It's
missing too many useful operational security features.

Conclusions I got from various meetings:

Paul and I will try to come up with an HTTP-digest based SASL mechanism
that's "good enough" operationally to be a mandatory-to-implement baseline
authentication mechanism.  The meeting I had with Paul went well -- I
think the result will be good. 

The current drafts that are nearing last call and need a 
mandatory-to-implement mechanism are:

	LDAP authentication
	NNTP authentication
	On-demand SMTP

We've got informal agreements to hold these drafts for two weeks for the
HTTP-digest based alternative.  Assuming the HTTP-digest based alternative
is issued promptly and it's acceptable to the LDAPEXT WG, it will be last
called along with the LDAP authentication spec.  If the HTTP-digest based
alternative starts causing undue delay in the standards process, then
CRAM-MD5 is the fallback choice. 

		- Chris

Subject: authmeth-02 && (Digest | CRAM-MD5)?
To: [email-masked], [email-masked]
cc: [email-masked]
From: [email-masked]
Date: Fri, 04 Sep 1998 09:06:24 -0700
Sender: [email-masked]

[apologies for cross-post. which single list are we going to discuss (Digest | 
CRAM-MD5) on? Seems [email-masked] is probably the appropriate one.]

Ok, so my understanding is that the Apps-area mandatory-to-impl 
simple-vs-complex auth mechanism lunch occured during the Chicago IETF on Tue 
25-Aug-1998.

My understanding from RLBob Morgan and Paul Hoffman is that at the (lunch) 
meeting, the discussion centered around CRAM vs Digest. The upshot was that 
Paul Leach and Chris Newman are to go off and tweak the Digest spec such that 
Chris' specific concerns are addressed (i.e. there was general consensus that 
Digest is better in specific areas and that we oughta utilize it rather than 
something we know has those problems and then have to change it in the 
near-to-intermediate term).

So, it seems we should be hearing from Paul & Chris about this, presummably on 
one or both of these lists ([email-masked]?).

Are there any first-hand accounts of the meeting someone who was actually 
there would like to publish (i.e. minutes?)?

thanks,

Jeff

Date: Thu, 03 Sep 1998 17:03:56 -0700
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Subject: SMTP AUTH design-team meeting notes
Sender: [email-masked]

Notes from the SMTP AUTH design-team meeting at the 42nd IETF In
Chicago.

. Both client and server must clear extension state and reissue EHLO
  after negotiating a security layer, to protect against
  man-in-the-middle attacks occuring before the authentication.

. The behavior for 0-length initial responses is slightly different with
SMTP
  AUTH due to the fact that some server implementations strip trailing
white
  space in their lexical analyzer. Instead of leaving it blank, you need
to
  specify an equals sign (=), e.g.
        AUTH EXTERNAL =

. Reactive authentication. There is a desire to be able to start a
  mail transaction and only obtain authentication if the server
  notifies the client that authentication is required.

  After some discussion, there was consensus that by allowing change
  of authentication state within a transaction complicates the
  security model.  For example, one may have to revoke delivery to
  previous RCPT TO: when the authentication state changes because the
  authenticated user may be explicitly denied the ability to send to
  given RCPT TO.  For another example, the application of moderator
  redirection for lists may depend on authentication state, so a change
  of authentication state could change the interpretation of a previous
  address.

  There was also some concerns with implementing this in current
  systems.

  As such, AUTH will only be allowed outside of a mail transaction. If
  AUTH is used within a mail transaction then an error will be
  returned by the server.

  A server could choose to implement reactive authentication in the case
  where the authentication does not enable a security layer, announcing
  this support using an additional ESMTP extension.  None of the server
  implementors present were interested in supporting such an extension,
  so there is no effort to define such an extension.

. Use of MAIL FROM: addr AUTH=. AUTH= is used by a relay to pass
  the authentication of a particular mail transaction from the
  client relay to the next trusted hop.

  Ideally, everyone would present AUTH= if the message is considered
  authentic and leave it blank if authentication is not asserted for
  the message.  However, the problem arises that a client may not know
  its own authentication and so the server needs to fill it in.

  The client can not just leave the field blank and assume the server
  will fill it in.  A relay may omit the AUTH= parameter when relaying
unauthentic
  mail even if it has established an authenticated connection.

  One proposal that was rejected was to have submit (but not relay) 
  servers fill in the submit client's authentication.  Doing so would
  be vulnerable to a man in the middle attack where the attacker could
  redirect a connection from the SMTP relay port to the submit port,
  causing the transaction to be incorrectly authenticated as the relay
client.

  Thus, a client is required to send MAIL FROM: addr AUTH=SOMETHING
  when it wants the server to assert that the value of the
  authentication for the current message (AUTH=) is to be set to the
  authentication identity of the connection.

  SOMETHING is currently undefined. Possible suggestions are currently
  "*@*" or "<>". John will check into this and propose a solution.

  Under both cases, if AUTH= is omitted from the MAIL FROM: line, then
  that message is considered unauthentic even if the session was
  authenticated.

. Reply codes: There was some discussion of the reply codes in SMTP
  AUTH, specifically the value of the middle field. It was decided
  that the current 505 field (which was used by SMTP TLS draft) should
  be changed to 530 to be more consistent with other documents where
  the middle digit of '3' represents an authentication related return
  code.

. XSENDER - Netscape has an extension to retrieve the value of AUTH=
  from the IMAP server, advertised by the XSENDER capability. This is
  by having an additional FETCH item.

  After some discussion, it appeared that most people were not
  interested in adopting this extension.  Some prefered to store this
  information as part of message annotations, but there was not
concensus
  on this point.  There was also a desire to have a way to be able to
  retrieve additonal SMTP envelope information.