Subject: Last Call for draft-ietf-sasl-plain-01

From: Sam Hartman <[email-masked]>
Date: Sat, 17 May 2003 15:12:42 -0400

This message initiates a SASL Working Group Last Call
on the document:

        Title           : The Plain SASL Mechanism
        Editor          : K. Zeilenga
        Filename        : draft-ietf-sasl-plain-01.txt

The purpose of this WG Last Call is to ensure that
the Working Group has achieved consensus that the
document is suitable for publication as a Proposed
Standard.

Please review the document for both technical and
editorial problems.  Technical issues should be
discussed on this list.  Editorial issues may be
sent to the document editor.

The Last Call period will end on Monday,
June 2, 2003.

Upon completion of the last call, the WG chair(s)
will take action based upon the consensus of the WG.
Possible actions include:

  1) recommending to the IETF Security Area Directors
     that the document, after possible editorial or
     other minor changes, be considered by the IESG
     for publication as a Standard Track RFC
     (which generally involves an IETF-wide Last Call); or

  2) requiring that outstanding issues be adequately
     addressed prior to further action (including,
     possibly, another WG Last Call).

Remember that it is our responsibility as Working
Group members to ensure the quality of our documents
and of the Internet Standards process.  So, please
read and comment!

 - Sam Hartman
   SASL co-chair

---

From: Chris Newman <[email-masked]>
Date: Fri, 30 May 2003 20:03:25 -0700

This is mostly editorial nits, but a few substantive issues are included.

-----
>  This document defines a simple clear-text user/password Simple
>  Authentication and Security Layer (SASL) mechanism called the PLAIN
>  mechanism.  The PLAIN mechanism intended to be used, in combination
                                  ^
                                  is
-----
I suggest adding a reference that would make sense to a broader audience:

>  This document defines the PLAIN Simple Authentication and Security
>  Layer ([SASL]) mechanism for use in protocols with no clear-text login
>  command (e.g., [ACAP]).
                       ^
                       or [SMTP-AUTH]

[SMTP-AUTH] J. Myers, "SMTP Service Extension for Authentication", RFC 2554,
            March 1999.
-----
>  The PLAIN SASL mechanism MUST NOT be advertised unless a strong
>  encryption layer, such as provided by Transport Layer Security
>  ([TLS]), is active.
                     ^
                     or backwards compatibility dictates otherwise.

I _STRONGLY_ object to this substantive change from RFC 2595 which was not
listed in the appendix.  There are deployed SMTP AUTH clients which use PLAIN
without TLS and I need to interoperate with them.  If you drop the backwards
compatibility phrase, I will refuse to comply with this version of the PLAIN
mechanism and encourage others to do the same (which would be a shame if we
want SASLprep to deploy).  If you can't tolerate the phrasing of the text from
RFC 2595, then I recommend using text similar to that in RFC 3501 sec 11.2:
  <http://www.apps.ietf.org/rfc/rfc3501.html#sec-11.2>
which is stronger but still realistic.

I'm all for improving the security of the Internet, but I have to draw the line
at requirements which fail to reflect reality.  IETF specifications only have
value if implementers can comply with them and still interoperate with the
majority of deployed software.
-----
>  character, followed by the clear-text password.   The client leaves
>  the authorization identity empty if wishes the server to derive the
                                      ^
                                      it
-----
> It is noted that the
> UTF-8 encoding of a Unicode character may be as long as 6 octets.

I believe this is incorrect.  Unicode characters range from U+0000 to U+10FFFF
(if I recall correctly).  The largest Unicode character consumes only 4 octets
in UTF-8.
-----
>  Upon receipt of the message, the server will verify presented
                                                      ^
                                                      the
>  authentication identity (authcid) and password (passwd) with the
>  system authentication database and that the authentication credentials
                                      ^^^^
                                      verify
>  permit the client to login as the (presented or derived) authorization
>  identity.  If both steps succeed, the user is authenticated.
-----
>  The presented authentication identity and password strings are not be
                                                                     ^
                                                                     to
>  compared directly with stored strings.  The server SHALL first prepare
>  authentication identity strings and password strings using the
                           XXXXXXX
>  [SASLPrep] profile of the [StringPrep] algorithm.  If preparation
-----
>  stronger SASL mechanisms such as the Kerberos-based GSSAPI mechanism

If you mention it, you need to include an informative reference.
-----
>  address this issue.  Clients are encouraged to have an operational
>  mode where all mechanisms which are likely to reveal the user's
>  password to the server are disabled.  It is RECOMMENDED that this mode
>  be the default.

I object to the addition of the last sentence (which was not in RFC 2595).
Such a default mode would mean the client would not interoperate with about 95%
of deployed servers on the Internet.  Please remove it as it is not realistic.
-----
>  "stringprep" and Unicode security considerations also apply.

Please include references.  If I'm trying to review all the security
considerations that apply I need to be able to find them.  The security
considerations for UTF-8 also apply.
-----
      Person & email address to contact for further information:
          Kurt Zeilenga <[email-masked]>
>          Chris Neuman <[email-masked]>

Please remove me from this registration.  You might want to put the address of
the ietf-sasl mailing list as the contact address for more information.
-----
>  This document is a revision of RFC 2595 by Chris Newman.  Portions of
>  the grammar defined in Section 2 were borrowed from [UTF-8] by
>  Francois Yergeau.

I wrote the grammar in Yergeau's revised document :-)
-----
  [UTF-8]      F. Yergeau, "UTF-8, a transformation format of ISO
               10646", RFC 2279, January 1998.

Please change this to reference the working draft, which has the revised
security considerations.

  [UTF-8]  F. Yergeau, "UTF-8, a transformation format of ISO 10646",
        draft-yergeau-rfc2279bis-04 (work in progress), February 2003.
-----

                - Chris

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 30 May 2003 21:42:46 -0700

Chris,

I concur with your comments.

>                     or backwards compatibility dictates otherwise.

An error on my part.  It should be same as the text in the
Security Considerations section.

Kurt

---

From: Chris Newman <[email-masked]>
Date: Fri, 30 May 2003 20:03:25 -0700

-----
                                  ^
                                  is
-----

                       ^
                       or [SMTP-AUTH]

                     ^

                                      ^
                                      it
-----

                                                      ^
                                                      the
                                      ^^^^
                                      verify
-----
                                                                     ^
                                                                     to
                           XXXXXXX
-----

                - Chris

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 30 May 2003 21:42:46 -0700

Chris,

Kurt 

Date: Fri, 30 May 2003 21:42:46 -0700
To: Chris Newman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last Call for draft-ietf-sasl-plain-01
Cc: Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

Chris,

Kurt 

Date: Fri, 30 May 2003 20:03:25 -0700
From: Chris Newman <[email-masked]>
Subject: Re: Last Call for draft-ietf-sasl-plain-01
To: Sam Hartman <[email-masked]>, [email-masked], Kurt Zeilenga <[email-masked]>
Sender: [email-masked]

-----
                                  ^
                                  is
-----

                       ^
                       or [SMTP-AUTH]

                     ^

                                      ^
                                      it
-----

                                                      ^
                                                      the
                                      ^^^^
                                      verify
-----
                                                                     ^
                                                                     to
                           XXXXXXX
-----

                - Chris

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-01.txt
Date: Fri, 30 May 2003 07:15:46 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: Using Digest Authentication as a SASL Mechanism
	Author(s)	: P. Leach, C. Newman, A. Melnikov
	Filename	: draft-ietf-sasl-rfc2831bis-01.txt
	Pages		: 37
	Date		: 2003-5-29
	
This specification defines how HTTP Digest Authentication [Digest]
can be used as a SASL [RFC 2222] mechanism for any protocol that has
a SASL profile. It is intended both as an improvement over CRAM-MD5
[RFC 2195] and as a convenient way to support a single authentication
mechanism for web, mail, LDAP, and other protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2831bis-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-ietf-sasl-rfc2831bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-01.txt".
	
NOTE:	The mail server at ietf.org 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-ietf-sasl-rfc2831bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-rfc2831bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: [email-masked]
Subject: less than One week left on plain last call
Date: Wed, 28 May 2003 17:42:37 -0400 (EDT)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

Just a reminder that the plain last call ends next Monday, June 2.

--Sam

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-saslprep-02.txt
Date: Wed, 28 May 2003 07:46:26 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: SASLprep: Stringprep profile for user names and 
                          passwords
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-saslprep-02.txt
	Pages		: 6
	Date		: 2003-5-27
	
This document describes how to prepare Unicode strings representing
user names and passwords for comparison.  The document defines the
'SASLprep' 'stringprep' profile to be used for both user names and
passwords.  This profile is intended to be used by Simple
Authentication and Security Layer (SASL) mechanisms (such as PLAIN,
CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user
names and/or passwords.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-ietf-sasl-saslprep-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-saslprep-02.txt".
	
NOTE:	The mail server at ietf.org 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-ietf-sasl-saslprep-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-saslprep-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Tue, 27 May 2003 11:30:15 +0200 (CEST)
From: =?ISO-8859-2?Q?Kov=E1cs_P=E9ter?= <[email-masked]>
Subject: mux.pid
To: [email-masked]
Sender: [email-masked]

Hello,

I have a system running FreeBSD 4.8.
After running the make world the following error come up in
the /var/log/messages file:

saslauthd[296]: FATAL: setting master lock on
/var/state/saslauthd/mux.pid: Resource temporarily unavailable

I recompiled the whole sasl2, but the error still exist.
And of course the file exsits as well. It has a number inside.

Thanks...

Date: Fri, 23 May 2003 18:57:22 -0700
To: Giorgi Lebanidze <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: problems with using CRAM-MD5
Cc: [email-masked]
Sender: [email-masked]

I note that the purpose of this list is to discuss the
standardization of SASL.  Specifically, this list is the
home of the IETF SASL WG.  Your post seems more appropriate
to a list supporting the particular implementation you
are using.  I suspect you are trying to use the Cyrus
SASL library from CMU.  If so, you should direct your
questions to the <[email-masked]> mailing
list.

Regards, Kurt (SASL WG co-chair)

At 10:51 AM 5/23/2003, Giorgi Lebanidze wrote:
>First of all I appologize if this is not teh way I was supposed to contact
>other subscribers of the list. I'm new to the group.

You just did contact everyone on the list.

>I'm trying to integrate SASL in the server I'm writing. I'm using CRAM-MD5
>mechanism and have /etc/cram-md5.pwd file. However, sasl_server_step call
>returns SASL_NOUSER -20  /* user not found */. Where does the SASL library
>look for the users and passwords while authenticating with  CRAM-MD5 ?
>thanks,
>Giorgi

Date: Fri, 23 May 2003 13:51:32 -0400 (EDT)
From: Giorgi Lebanidze <[email-masked]>
To: [email-masked]
Subject: problems with using CRAM-MD5
Sender: [email-masked]

First of all I appologize if this is not teh way I was supposed to contact
other subscribers of the list. I'm new to the group.
I'm trying to integrate SASL in the server I'm writing. I'm using CRAM-MD5
mechanism and have /etc/cram-md5.pwd file. However, sasl_server_step call
returns SASL_NOUSER -20  /* user not found */. Where does the SASL library
look for the users and passwords while authenticating with  CRAM-MD5 ?
thanks,
Giorgi

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2222bis-00.txt
Date: Wed, 21 May 2003 08:11:00 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: Simple Authentication and Security Layer (SASL)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sasl-rfc2222bis-00.txt
	Pages		: 18
	Date		: 2003-5-20
	
SASL provides a method for adding authentication support with an
optional security layer to connection-based protocols.  It also
describes a structure for authentication mechanisms.  The result is
an abstraction layer between protocols and authentication mechanisms
such that any SASL-compatible authentication mechanism can be used
with any SASL-compatible protocol.
This document describes how a SASL authentication mechanism is
structured, how a protocol adds support for SASL, defines the
protocol for carrying a security layer over a connection, and defines
the EXTERNAL SASL authentication mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-rfc2222bis-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-ietf-sasl-rfc2222bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-rfc2222bis-00.txt".
	
NOTE:	The mail server at ietf.org 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-ietf-sasl-rfc2222bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-rfc2222bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Sun, 18 May 2003 09:23:05 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-plain-01.txt
Cc: [email-masked]
Sender: [email-masked]

At 02:02 PM 5/17/2003, Simon Josefsson wrote:

>  The server MAY also use the password to initialize any new
>  authentication database, such as one suitable for [CRAM-MD5] or
>  [DIGEST-MD5].
>
>First, DIGEST-MD5 need authcid and authzid too,

Technically speaking, the DIGEST-MD5 A1 hash doesn't include
the authzid.  

>it isn't possible to
>initialize a hashed password database suitable for DIGEST-MD5 using
>the password only.

I'll s/password/credentials/ in the above.

>Secondly, how will this interact with the non-ASCII handling in
>CRAM-MD5 and DIGEST-MD5? 

I think that exactly how PLAIN credentials interact with credentials
of other mechanisms should be viewed as an implementation detail
as the syntax and semantics of those credentials is mechanism
specific.  But as Sam said, I think the WG intends to use SASLprep
for all username and password appearing in such mechanisms. 

>Should the PLAIN server SASLprep() the
>strings or not, before hashing them and storing them in the database,
>for later use with *-MD5?  The answer appears to depend on how
>*-MD5bis will handle non-ASCII, but there is no CRAM-MD5bis, and
>DIGEST-MD5bis does not currently mention SASLprep.
>
>Since 2195 is unclear on the username syntax (ASCII?  UTF-8?  Opaque
>data except SPC?), it would be prudent to mention in the security
>considerations that if someone currently uses non-ASCII usernames in
>PLAIN, the SASLprep() operation may cause changes to the username.
>This warning may be more appropriate in the saslprep document, but
>that document doesn't have a security consideration currently.  E.g.,
>if someone has a system with two users "foo<GERMAN SHARP S>" and
>"fooss", the SASLprep() operation translates the first string into the
>latter before database comparison, whereas the application does not
>necessarily perform the same translation.  The consequences appears to
>be that someone who knows the password for "fooss" may also be
>authenticated as "foo<GERMAN SHARP S>".

Well, saslprep should have a security consideration section.
I think it fine to elaborate that the profile as to why it is
not intended to be applied to identities which are not simple
user names and related issued.  Also, I think 2222bis should
be more clear that the form which authentication credentials
take and how they are used to authenticate the user is
mechanism specific.  Applications should be avoid overloading
syntax and semantics.

I don't see the PLAIN I-D needing any additional text here.

Kurt

To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-sasl-plain-01.txt
From: Sam Hartman <[email-masked]>
Date: Sat, 17 May 2003 17:26:53 -0400
Sender: [email-masked]

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Secondly, how will this interact with the non-ASCII
    Simon> handling in CRAM-MD5 and DIGEST-MD5?  Should the PLAIN
    Simon> server SASLprep() the strings or not, before hashing them
    Simon> and storing them in the database, for later use with *-MD5?
    Simon> The answer appears to depend on how *-MD5bis will handle
    Simon> non-ASCII, but there is no CRAM-MD5bis, and DIGEST-MD5bis
    Simon> does not currently mention SASLprep.

We agreed in San Francisco that digest-md5 would use saslprep.  I
believe we agreed the same for cram-md5.  Those updates are pending.

--Sam

To: [email-masked]
Subject: Comments on draft-ietf-sasl-plain-01.txt
From: Simon Josefsson <[email-masked]>
Date: Sat, 17 May 2003 23:02:18 +0200
Sender: [email-masked]

  The server MAY also use the password to initialize any new
  authentication database, such as one suitable for [CRAM-MD5] or
  [DIGEST-MD5].

First, DIGEST-MD5 need authcid and authzid too, it isn't possible to
initialize a hashed password database suitable for DIGEST-MD5 using
the password only.

Secondly, how will this interact with the non-ASCII handling in
CRAM-MD5 and DIGEST-MD5?  Should the PLAIN server SASLprep() the
strings or not, before hashing them and storing them in the database,
for later use with *-MD5?  The answer appears to depend on how
*-MD5bis will handle non-ASCII, but there is no CRAM-MD5bis, and
DIGEST-MD5bis does not currently mention SASLprep.

Since 2195 is unclear on the username syntax (ASCII?  UTF-8?  Opaque
data except SPC?), it would be prudent to mention in the security
considerations that if someone currently uses non-ASCII usernames in
PLAIN, the SASLprep() operation may cause changes to the username.
This warning may be more appropriate in the saslprep document, but
that document doesn't have a security consideration currently.  E.g.,
if someone has a system with two users "foo<GERMAN SHARP S>" and
"fooss", the SASLprep() operation translates the first string into the
latter before database comparison, whereas the application does not
necessarily perform the same translation.  The consequences appears to
be that someone who knows the password for "fooss" may also be
authenticated as "foo<GERMAN SHARP S>".

Thanks.

To: [email-masked]
Subject: Last Call for draft-ietf-sasl-plain-01
From: Sam Hartman <[email-masked]>
Date: Sat, 17 May 2003 15:12:42 -0400
Sender: [email-masked]

 - Sam Hartman
   SASL co-chair

Date: Tue, 06 May 2003 07:41:02 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: SASLprep
Sender: [email-masked]

I have updated draft-ietf-sasl-saslprep based upon list and
off-list comment.  Please review and comment.

Thanks, Kurt

Date: Tue, 06 May 2003 07:40:12 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: PLAIN
Sender: [email-masked]

I have updated draft-ietf-sasl-plain based upon list and
off-list comments.  Please review and comment.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-plain-01.txt
Date: Tue, 06 May 2003 07:43:18 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Author(s)	: K. Zeilenga
	Pages		: 8
	Date		: 2003-5-5
	
This document defines a simple clear-text user/password Simple
Authentication and Security Layer (SASL) mechanism called the PLAIN
mechanism.  The PLAIN mechanism intended to be used, in combination
with data confidentiality services provided by a lower layer, in
protocols which lack a simple password authentication command.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-plain-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-ietf-sasl-plain-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-plain-01.txt".
	
NOTE:	The mail server at ietf.org 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-ietf-sasl-plain-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-plain-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-anon-01.txt
Date: Tue, 06 May 2003 07:41:46 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: The Anonymous SASL Mechanism
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-anon-01.txt
	Pages		: 8
	Date		: 2003-5-5
	
It is common practice on the Internet to permit anonymous access to
various services.  Traditionally, this has been done with a plain text
password mechanism using 'anonymous' as the user name and optional
trace information, such as an email address, as the password.  As
plaintext login commands are not permitted in new IETF protocols, a
new way to provide anonymous login is needed within the context of the
Simple Authentication and Security Layer (SASL) framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-ietf-sasl-anon-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-anon-01.txt".
	
NOTE:	The mail server at ietf.org 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-ietf-sasl-anon-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-anon-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-saslprep-01.txt
Date: Tue, 06 May 2003 07:41:41 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.

	Title		: SASLprep: Stringprep profile for user names and 
                          passwords
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-saslprep-01.txt
	Pages		: 5
	Date		: 2003-5-5
	
This document describes how to prepare Unicode strings representing
user names and passwords for comparison.  The document defines the
'SASLprep' 'stringprep' profile to be used for both user names and
passwords.  This profile is intended to be used by Simple
Authentication and Security Layer (SASL) mechanisms (such as PLAIN,
CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging user
names and/or passwords.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-ietf-sasl-saslprep-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-saslprep-01.txt".
	
NOTE:	The mail server at ietf.org 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-ietf-sasl-saslprep-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sasl-saslprep-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--