Subject: mailing list last call: pop and smtp sasl

From: John Gardiner Myers <[email-masked]>
Date: Fri, 21 Nov 1997 15:42:01 -0800

I will shortly be asking the pop3 and smtp SASL drafts to go to IETF
Last Call.  Please send any last-minute comments.

---

From: Chris Newman <[email-masked]>
Date: Mon, 24 Nov 1997 10:55:22 -0800 (PST)

> Last Call.  Please send any last-minute comments.

When I was writing the TLS extension to POP3 draft, I realized it
introduced an ugly mess in combination with the SASL AUTH command.
A client has to probe both for the "AUTH" command and for the "STLS"
command, then decide what security to do.  I think the right way to
address this is to have a proper extension mechanism for POP3.  I wrote a
first cut: draft-newman-pop3ext-00.txt

		- Chris

---

From: [email-masked] (John Myers)
Date: Mon, 24 Nov 1997 11:15:20 -0800

Chris Newman wrote:
> I think the right way to

There is existing widely deployed code using the mechanism described in
the draft.

---

From: Chris Newman <[email-masked]>
Date: Mon, 24 Nov 1997 11:47:58 -0800 (PST)

> There is existing widely deployed code using the mechanism described in

I still think that the extension mechanism is a better solution long term.
Would you object to having the extension announcement mechanism in
addition to what's in the POP3 AUTH spec?

		- Chris

---

From: Randall Gellens <[email-masked]>
Date: Mon, 24 Nov 1997 15:13:20 -0800

>addition to what's in the POP3 AUTH spec?

I'd go further; I think the standard should be a general extension
announcement mechanism.  The empty AUTH probe should be a MAY, and
discouraged for new code.

--
Randall Gellens       ||    Opinions are personal; facts are suspect;
[email-masked]    ||    I speak for myself alone

f u cn rd ths, itn tyg h myxbl cd.

---

From: Rob Earhart <[email-masked]>
Date: Wed, 26 Nov 1997 22:14:22 -0500 (EST)

(Is there any reason why this is being discussed on the ietf-acap
mailing list, instead of ietf-sasl, where it started?)

  Personally, I'm with John; POP3's useful if you need to interact
with legacy systems, but it seems a bit silly to take the time and
effort to work on POP3 to the point of defining a generic extension
mechanism that'll be good in the long run, since in the long run,
everything ought to transition to IMAP anyway.

  Encouraging the use of POP3 seems harmful at this point; I'd rather
see it just go away.

  )Rob

---

From: Chris Newman <[email-masked]>
Date: Mon, 24 Nov 1997 10:55:22 -0800 (PST)

- Chris

---

From: [email-masked] (John Myers)
Date: Mon, 24 Nov 1997 11:15:20 -0800

---

From: Chris Newman <[email-masked]>
Date: Mon, 24 Nov 1997 11:47:58 -0800 (PST)

- Chris

---

From: Randall Gellens <[email-masked]>
Date: Mon, 24 Nov 1997 15:13:20 -0800

---

From: Rob Earhart <[email-masked]>
Date: Wed, 26 Nov 1997 22:14:22 -0500 (EST)

)Rob

Date: Wed, 26 Nov 1997 22:14:22 -0500 (EST)
From: Rob Earhart <[email-masked]>
To: IETF ACAP Mailing List <[email-masked]>, [email-masked]
Subject: Re: mailing list last call: pop and smtp sasl
CC: John Gardiner Myers <[email-masked]>
Beak: Is
Organization: cmu
Sender: [email-masked]

  )Rob

Date: Mon, 24 Nov 1997 15:13:20 -0800
To: Chris Newman <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: mailing list last call: pop and smtp sasl
Cc: John Myers <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Date: Mon, 24 Nov 1997 11:47:58 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: mailing list last call: pop and smtp sasl
To: John Myers <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

		- Chris

Date: Mon, 24 Nov 1997 11:15:20 -0800
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: mailing list last call: pop and smtp sasl
Sender: [email-masked]

Date: Mon, 24 Nov 1997 10:55:22 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: mailing list last call: pop and smtp sasl
To: John Gardiner Myers <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

		- Chris

To: [email-masked]
Path: not-for-mail
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-sasl
Subject: mailing list last call: pop and smtp sasl
Date: Fri, 21 Nov 1997 15:42:01 -0800
Organization: Netscape Communications Corporation
Lines: 2
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Date: Fri, 14 Nov 1997 17:18:52 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: I-D ACTION:draft-newman-sasl-plaintrans-04.txt (fwd)
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

---559023410-1903590565-879556732=:16241
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email-masked]>

I'm planning to ask that this become an Informational RFC.

It defines the "PLAIN" SASL mechanism for plaintext login.

Please review this if you get a chance.

		Thanks,
		- Chris

---------- Forwarded message ----------
Date: Fri, 14 Nov 1997 11:57:14 -0500
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-newman-sasl-plaintrans-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Plaintext Password SASL Mechanism for Transitioning
	Author(s)	: C. Newman
	Filename	: draft-newman-sasl-plaintrans-04.txt
	Pages		: 9
	Date		: 13-Nov-97
	
     Unencrypted plaintext passwords are the biggest single risk to
     Internet application protocol security.  Unfortunately, they are
     widely deployed, often tightly integrated into operating system
     services and very difficult to replace in an interoperable fashion.
 
     This specification discusses some methods which can be used to
     eliminate unencrypted plaintext passwords.  It also defines a SASL
     mechanism [SASL] which may be used by newer protocols such as ACAP
     [ACAP] to transition away from a legacy authentication database.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-newman-sasl-plaintrans-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-newman-sasl-plaintrans-04.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

---559023410-1903590565-879556732=:16241--

To: [email-masked]
From: [email-masked]
cc: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-myers-smtp-auth-09.txt
Date: Thu, 13 Nov 1997 09:50:01 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SMTP Service Extension for Authentication
	Author(s)	: J. Myers
	Filename	: draft-myers-smtp-auth-09.txt
	Pages		: 8
	Date		: 12-Nov-97
	
   This document defines an SMTP service extension [ESMTP] whereby an
   SMTP client may indicate an authentication mechanism to the server,
   perform an authentication protocol exchange, and optionally negotiate
   a security layer for subsequent protocol interactions.  This
   extension is a profile of the Simple Authentication and Security
   Layer [SASL].

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-myers-smtp-auth-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-smtp-auth-09.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-myers-smtp-auth-09.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-myers-smtp-auth-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-myers-smtp-auth-09.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 13 Nov 1997 00:25:04 -0500 (EST)
From: John C Klensin <[email-masked]>
Subject: Re: Feedback on RFC 2195: CRAM-MD5
To: Chris Newman <[email-masked]>
Cc: [email-masked], Paul Krumviede <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, 12 Nov 1997 11:10:08 -0800 (PST) Chris Newman 
<[email-masked]> wrote:

> There was a discussion of the CRAM-MD5 mechanism on the LDAPEXT mailing
> list.  Since LDAP uses spaces in user names, it's important that CRAM-MD5
> implementations do a right-to-left parse to support that.
>...
> A formal grammar and some sample code (which I'd be willing to supply, if
> you wish) would also be useful.

If you supply it, we will enthusiastically review it and 
paste it in.

   john

Date: Wed, 12 Nov 1997 11:10:08 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Feedback on RFC 2195: CRAM-MD5
To: John C Klensin <[email-masked]>, Paul Krumviede <[email-masked]>, [email-masked]
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

There was a discussion of the CRAM-MD5 mechanism on the LDAPEXT mailing
list.  Since LDAP uses spaces in user names, it's important that CRAM-MD5
implementations do a right-to-left parse to support that.

I think this needs to be documented in the next revision to the spec
(presumably a draft standard revision next March).

A formal grammar and some sample code (which I'd be willing to supply, if
you wish) would also be useful.

		- Chris

To: [email-masked]
From: John Gardiner Myers <[email-masked]>
Subject: SMTP SASL document
Date: Mon, 03 Nov 1997 18:50:26 -0800
Organization: Netscape Communications Corporation
Lines: 3
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Sorry folks, I neglected to deal with some comments I had received on
the previous SMTP draft.  Please ignore draft-myers-smtp-auth-08.txt and
I'll issue a new document RSN.