Subject: I-D ACTION:draft-hansen-sasl-pki-00.txt

From: [email-masked]
Date: Fri, 28 Feb 2003 07:25:47 -0500

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

	Title		: The PKI SASL Mechanism
	Author(s)	: T. Hansen
	Filename	: draft-hansen-sasl-pki-00.txt
	Pages		: 6
	Date		: 2003-2-27
	
This document defines a user/password Simple Authentication and
Security Layer(SASL) mechanism called the PKI mechanism.  The PKI
mechanism is intended to be used in situations where (1) passwords must
be encrypted, (2) the password must be recoverable, and (3) using TLS in
combination with a SASL mechanism such as PLAIN is inappropriate.
NOTE: This document is a straw proposal to see what interest there
is in having a SASL mechanism such as this.  See the first section below
for more information on why this mechanism is needed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hansen-sasl-pki-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-hansen-sasl-pki-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-hansen-sasl-pki-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.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 28 Feb 2003 10:06:54 -0800

Tony,

What's the advantage of this approach over using TLS+SASL/PLAIN
and then just closing TLS gracefully so that remainder of the
session is in the clear?

Kurt

At 04:25 AM 2/28/2003, [email-masked] wrote:
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-hansen-sasl-pki-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-hansen-sasl-pki-00.txt>

---

From: Ken Murchison <[email-masked]>
Date: Fri, 28 Feb 2003 14:03:23 -0500

> and then just closing TLS gracefully so that remainder of the

Hmm.  I always thought that it was implied that TLS would be active
until the end of the session.  Can this be done gracefully so that both
client and server is happy (are there any existing implementations that
wouldn't freak)?  Who can/should initiate the shutdown?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 28 Feb 2003 14:02:51 -0500

Date: Fri, 28 Feb 2003 10:06:54 -0800
   From: "Kurt D. Zeilenga" <[email-masked]>

You don't close TLS; you can renegotiate to the NULL cipher.

Larry

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 28 Feb 2003 11:15:33 -0800

At 11:03 AM 2/28/2003, Ken Murchison wrote:
>until the end of the session.

Well, that's maybe how some application-layer protocols specify
how TLS is to be used, but TLS does support closure (and
subsequent restart).  For an example of how one application
layer protocol allows TLS closure (and restart), see Section 4.1
of RFC 2830 (LDAPv3 Start TLS).

>Can this be done gracefully so that both
>wouldn't freak)?

Yes.  But there application-layer issues (such as how to
handle outstanding operations, etc.) which need to be address
in the technical specification detailing use of TLS in that
application-layer protocol.

>Who can/should initiate the shutdown?

Either TLS peer can issue a closure alert.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 28 Feb 2003 11:22:25 -0800

>You don't close TLS; you can renegotiate to the NULL cipher.

Application-level protocols may permit use the stream after TLS
closure.  See RFC 2246, Section 7.2.1.  LDAPv3 is an example,
RFC 2830, of an application-level protocol which explicitly
permits such use.

Kurt

---

From: Tony Hansen <[email-masked]>
Date: Fri, 28 Feb 2003 14:45:53 -0500

All the application protocols have a way of saying "I want to turn TLS 
on", but none of the application protocols have a way to say "now I want 
to turn TLS off". I even think that the "start TLS" specs in most 
application protocols explicitly say that you CANNOT switch it back off.

Within the TLS layer, you can negotiate switching to a null cipher. But 
there is no way to mandate that up at the application protocol level. 
Plus I think there're still other overheads of TLS that don't go away.

	Tony Hansen
	[email-masked]

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 28 Feb 2003 12:39:49 -0800

At 11:45 AM 2/28/2003, Tony Hansen wrote:

>All the application protocols have a way of saying "I want to turn TLS on",
>but none of the application protocols have a way to say "now I want to turn TLS off".

TLS closure alert says "I want to turn TLS off".  Every application
protocol which profiles TLS should state what happens when this is
said.

>I even think that the "start TLS" specs in most application protocols explicitly say that you CANNOT switch it back off.

I suspect most application protocol specifications are mute on what
to do upon TLS closure.

Anyways, it seems what you are saying is, you need a new mechanism
because some application protocol profiles of TLS don't allow
messages to be exchanged post TLS closure.  I would add, and
where they do allow such, not all implementations support it.

I suggest briefly discuss in your draft why a TLS+SASL/PLAIN+closure
approach is not well suited to your needs.

>Within the TLS layer, you can negotiate switching to a null cipher. But there is no way to mandate that up at the application protocol level.

Most TLS implementations I know provide applications with adequate
control over which cipher suites may be used, as well as which
cipher suite is in use, so that they may ensure they can enforce
applicable security policies.

>Plus I think there're still other overheads of TLS that don't go away.

I would think that a good TLS implementation would have minimal
overhead when a null cipher suite was in use.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 28 Feb 2003 10:06:54 -0800

Tony,

Kurt

---

From: Ken Murchison <[email-masked]>
Date: Fri, 28 Feb 2003 14:03:23 -0500

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 28 Feb 2003 14:02:51 -0500

Larry

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 28 Feb 2003 11:15:33 -0800

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 28 Feb 2003 11:22:25 -0800

Kurt

---

From: Tony Hansen <[email-masked]>
Date: Fri, 28 Feb 2003 14:45:53 -0500

Tony Hansen
	[email-masked]

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 28 Feb 2003 12:39:49 -0800

Date: Fri, 28 Feb 2003 12:39:49 -0800
To: Tony Hansen <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt
Cc: [email-masked]
Sender: [email-masked]

Date: Fri, 28 Feb 2003 14:45:53 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt
Sender: [email-masked]

	Tony Hansen
	[email-masked]

> and then just closing TLS gracefully so that remainder of the

Date: Fri, 28 Feb 2003 11:22:25 -0800
To: Lawrence Greenfield <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Kurt

Date: Fri, 28 Feb 2003 11:15:33 -0800
To: Ken Murchison <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Kurt 

Date: Fri, 28 Feb 2003 14:02:51 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt
Sender: [email-masked]

Larry

Date: Fri, 28 Feb 2003 14:03:23 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: "Kurt D. Zeilenga" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt
Sender: [email-masked]

Date: Fri, 28 Feb 2003 10:06:54 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-hansen-sasl-pki-00.txt
Cc: [email-masked]
Sender: [email-masked]

Tony,

Kurt

><ftp://ftp.ietf.org/internet-drafts/draft-hansen-sasl-pki-00.txt>

Date: Fri, 28 Feb 2003 12:02:35 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
CC: SASL mailing list <[email-masked]>
Subject: draft-hansen-sasl-pki-00.txt
Sender: [email-masked]

Tony,

I assume that this is in response to discussions/complaints on
ietf-nntp?  Can you compare/contrast what you have in mind to Newman's
PASSDSS?

http://www.alternic.org/drafts/drafts-n-o/draft-newman-sasl-passdss-01.txt

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-hansen-sasl-pki-00.txt
Date: Fri, 28 Feb 2003 07:25:47 -0500
Sender: [email-masked]

--NextPart

	

Send a message to:
	[email-masked].
In the body type:

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

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

Content-Type: text/plain

ENCODING mime

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

Content-Type: text/plain

--OtherAccess--

--NextPart--

Date: Thu, 27 Feb 2003 11:02:39 -0800
To: Steve Hole <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-00.txt
Cc: [email-masked]
Sender: [email-masked]

At 07:57 AM 2/27/2003, Steve Hole wrote:

>On Thu, 27 Feb 2003 07:45:32 -0500 [email-masked] wrote:
>
>        
>> 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.
>
>It is entirely possible that I have missed some conversation that answers 
>this question ... if so I apologize.   Why is this necessary.   Those 
>mechanisms that are recommended for use (CRAM-MD5 is effectively 
>deprecated in favour of Digest) support use of UTF8 encoded strings.  Why 
>we would need to do anything else for exact comparison purposes?

To ensure that two different, but canonically equivalent, Unicode
strings are treated as being the same.

Kurt 

From: Steve Hole <[email-masked]>
Date: Thu, 27 Feb 2003 08:57:27 -0700
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-00.txt
Sender: [email-masked]

On Thu, 27 Feb 2003 07:45:32 -0500 [email-masked] wrote:

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

It is entirely possible that I have missed some conversation that answers 
this question ... if so I apologize.   Why is this necessary.   Those 
mechanisms that are recommended for use (CRAM-MD5 is effectively 
deprecated in favour of Digest) support use of UTF8 encoded strings.  Why 
we would need to do anything else for exact comparison purposes?

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-saslprep-00.txt
Date: Thu, 27 Feb 2003 07:45:32 -0500
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-00.txt
	Pages		: 5
	Date		: 2003-2-26
	
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-00.txt

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-00.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-saslprep-00.txt".

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

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

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

--OtherAccess--

--NextPart--

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Philip Guenther <[email-masked]>, [email-masked]
Subject: Re: realms
From: Sam Hartman <[email-masked]>
Date: Fri, 21 Feb 2003 22:24:30 -0500
Sender: [email-masked]

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> At 12:39 PM 2/20/2003, Alexey Melnikov wrote:
    >> Just to clarify: the solution can be as simple as saying that domain part
    >> of an "email" can be parsed by the server in order to figure out realm. 

    Kurt> I would rather clarify that the trace information has
    Kurt> no semantical value.

    Kurt> Kurt 

I tend to agree that if a clarification is made it should be in the
direction of no semantic value for the trace component.

This is just another rehash of the authorization name vs
authentication name problem all over again.  There is exactly one
anonymous authentication name in the universe.  It may have trace
information associated with it but anonymous logins are all the same.

The anonymous identity may be authorized for several different
authorization identities--these identities may even correspond to
different realms.

Our current mechanism does not provide a way to express this
authorization identity and expanding the mechanism now is probably a
bad idea and possible out of scope.

It may be appropriate for some future anonymous mechanism to support
authorization identity if that is useful.

Date: Fri, 21 Feb 2003 13:49:52 -0800
To: Philip Guenther <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) 
Cc: [email-masked]
Sender: [email-masked]

At 01:04 PM 2/21/2003, Philip Guenther wrote:
>How about the following sentence for addition to section 1, perhaps
>right after the 'no security layer' paragraph?
>
>"The ANONYMOUS mechanism is not applicable to servers that support
> multiple anonymous identities and that do not have enough information
> from before the SASL exchange (for example, from previous protocol
> exchanges or the connection addresses) to determine which identity to
> use."

A few comments.

I think "anonymous identity" is an oxymoron.  And, of course,
the ANONYMOUS mechanism is not intended to determine any identity.

One possible alternative wording, which would at avoid these issues,
would be:
        The ANONYMOUS mechanism is not applicable where
        application-level protocols and/or their implementations
        offer more than one kind/type/level of anonymous
        associations between the client and the server as the
        mechanism provides no facility to indicate the kind/type/level
        of associate desired.  No semantics should be associated
        with the trace information.

Kurt 

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) 
Date: Fri, 21 Feb 2003 13:04:07 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:
>At 12:25 PM 2/20/2003, Philip Guenther wrote:
>>>Are you asking for the WG to consider adding realm support
>>>to ANONYMOUS mechanism?  Or asking the WG to consider
>>>clarifications to the ANONYMOUS mechanism that it is not
>>>applicable in scenarios allowing different anonymous
>>>associations to be established?
>>
>>The latter, not the former.
>
>Okay.  I suggest you (or another proponent of the clarification)
>offer text for the WG to consider.

How about the following sentence for addition to section 1, perhaps
right after the 'no security layer' paragraph?

"The ANONYMOUS mechanism is not applicable to servers that support
 multiple anonymous identities and that do not have enough information
 from before the SASL exchange (for example, from previous protocol
 exchanges or the connection addresses) to determine which identity to
 use."

Philip Guenther

Date: Thu, 20 Feb 2003 12:52:24 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00)
Cc: Philip Guenther <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:39 PM 2/20/2003, Alexey Melnikov wrote:
>Just to clarify: the solution can be as simple as saying that domain part
>of an "email" can be parsed by the server in order to figure out realm. 

I would rather clarify that the trace information has
no semantical value.

Kurt 

Date: Thu, 20 Feb 2003 12:49:52 -0800
To: Philip Guenther <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) 
Cc: [email-masked]
Sender: [email-masked]

At 12:25 PM 2/20/2003, Philip Guenther wrote:
>>Are you asking for the WG to consider adding realm support
>>to ANONYMOUS mechanism?  Or asking the WG to consider
>>clarifications to the ANONYMOUS mechanism that it is not
>>applicable in scenarios allowing different anonymous
>>associations to be established?
>
>The latter, not the former.

Okay.  I suggest you (or another proponent of the clarification)
offer text for the WG to consider.

Kurt 

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) 
Date: Thu, 20 Feb 2003 12:34:41 -0800
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:
>> At 11:54 PM 2/19/2003, Philip Guenther wrote:
>> >The ANONYMOUS mechanism does not provide a means for the client to
>> >supply an optional realm in which the anonymous authentication should
>> >take place.
...
>> Are you asking for the WG to consider adding realm support
>> to ANONYMOUS mechanism?
>
>Just to clarify: the solution can be as simple as saying that domain part
>of an "email" can be parsed by the server in order to figure out realm.

I don't think an rfc should suggest automated parsing of trace
information.  Such a practice would arguably make the non-address form a
second-class citizen and possibly lead to the use of placeholder
addressees when a general text string would have been more appropriate.

Philip Guenther

Date: Thu, 20 Feb 2003 13:39:15 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Philip Guenther <[email-masked]>, [email-masked]
Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00)
Sender: [email-masked]

"Kurt D. Zeilenga" wrote:

> At 11:54 PM 2/19/2003, Philip Guenther wrote:
> >The ANONYMOUS mechanism does not provide a means for the client to
> >supply an optional realm in which the anonymous authentication should
> >take place.
>
> Correct, it doesn't.  (The trace information has no semantical
> value.)
>
> >This makes the ANONYMOUS mechanism unusable by servers that
> >support multiple realms on a single communication end-point; it cannot
> >supplant the "anonymous@domain" login supported by, for example, some
> >IMAP servers.
>
> Maybe so.
>
> Are you asking for the WG to consider adding realm support
> to ANONYMOUS mechanism?

Just to clarify: the solution can be as simple as saying that domain part
of an "email" can be parsed by the server in order to figure out realm.

> Or asking the WG to consider
> clarifications to the ANONYMOUS mechanism that it is not
> applicable in scenarios allowing different anonymous
> associations to be established?

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: security considerations (was: comments on draft-ietf-sasl-anon-00) 
Date: Thu, 20 Feb 2003 12:26:41 -0800
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:
...
>I'm thinking the problem starts in paragraph 4 with the
>suggestion that servers should restrict the numbers of
>anonymous users.  How about replacing both paragraph 4 and
>5 with:
<elided>

Looks good to me.

Philip Guenther

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: realms (Was: comments on draft-ietf-sasl-anon-00) 
Date: Thu, 20 Feb 2003 12:25:16 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:
>At 11:54 PM 2/19/2003, Philip Guenther wrote:
...
>>This makes the ANONYMOUS mechanism unusable by servers that
>>support multiple realms on a single communication end-point; it cannot
>>supplant the "anonymous@domain" login supported by, for example, some
>>IMAP servers.
>
>Maybe so. 
>
>Are you asking for the WG to consider adding realm support
>to ANONYMOUS mechanism?  Or asking the WG to consider
>clarifications to the ANONYMOUS mechanism that it is not
>applicable in scenarios allowing different anonymous
>associations to be established?

The latter, not the former.

While a mechanism that supports multiple anonymous identities may have
its place in the SASL 'cookbook', I don't currently have a clear idea of
what would be generally useful in that direction to suggest changing the
current ANONYMOUS mechanism at this time.

Philip Guenther

Date: Thu, 20 Feb 2003 12:32:52 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Unicode/UTF-8 issues (was: commentsondraft-ietf-sasl-anon-00)
Cc: Philip Guenther <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:09 PM 2/20/2003, Alexey Melnikov wrote:

>> Okay, how about I replace the grammar and the paragraph before
>> it as follows:
>
>This mostly works, see below.
>
>>   A formal grammar for the client message using Augmented BNF [ABNF]
>>   is provide below as a tool for understanding this technical
>>   specification.
>>
>>   message     = [ email / token ]
>>                 ;; MUST be prepared in accordance with Section 2
>>
>>   UTF1        = %x00-3F / %x41-7F ;; less '@' (U+0040)
>>   UTF2        = %xC2-DF UTF0
>>   UTF3        = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
>>                 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
>>   UTF4        = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
>>                 %xF4 %x80-8F 2(UTF0)
>>   UTF0        = %x80-BF
>>
>>   TCHAR       = UTF1 / UTF2 / UTF3 / UTF3 / UTF4
>>               ;; any UTF-8 encoded Unicode character
>>               ;; except '@' (U+0040)
>
>Hmm, this suggests a typo in draft-yergeau-rfc2279bis-04.txt (UTF3 is
>shown twice).

Or an error on my part.  UTF3 should only be listed once here.

>Also note, that this doesn't have UTF5 & UTF6 that you currently have:
>
>      UTF5        = %xF8-FB 4(UTF0)
>      UTF6        = %xFC-FD 5(UTF0)
>
>(but they have to be cleaned up to prevent overlong sequences).

Yes.  There are a couple of 4 v 6 octet cleanups to be made as well. 

Date: Thu, 20 Feb 2003 12:23:36 -0800
To: Philip Guenther <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: security considerations (was: comments on draft-ietf-sasl-anon-00)
Cc: [email-masked]
Sender: [email-masked]

At 11:54 PM 2/19/2003, Philip Guenther wrote:
>Paragraph 5 of section 4 (security consideration), suggests the use of
>an idle timeout on servers that place a limit on the number of
>concurrent anonymous users in order to combat a denial-of-service
>attack.  As keeping a connection from being considered idle will
>generally require simply sending a request (possibly even a malformed
>request), it's unlikely that an idle timeout will actually prevent an
>intentional DOS attack from succeeding.  A hard timeout on connection
>duration, network access limitations, or (where appropriate) a limit on
>the number of requests permitted on an anonymous connection may be
>required to provide a minimal service guarantee in the face of malicious
>access.

I'm thinking the problem starts in paragraph 4 with the
suggestion that servers should restrict the numbers of
anonymous users.  How about replacing both paragraph 4 and
5 with:

  If the anonymous user can run many expensive operations (e.g., an
  IMAP SEARCH BODY command), this could enable a denial of service 
  attack. Servers are encouraged to reduce the priority of anonymous
  users or limit their resource usage.

  While servers may impose a limit on the number of anonymous
  users, it is noted that such a limit enables denial of service
  attacks and should be used with caution. 

Date: Thu, 20 Feb 2003 13:09:57 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Philip Guenther <[email-masked]>, [email-masked]
Subject: Re: Unicode/UTF-8 issues (was: commentsondraft-ietf-sasl-anon-00)
Sender: [email-masked]

"Kurt D. Zeilenga" wrote:

> Okay, how about I replace the grammar and the paragraph before
> it as follows:

This mostly works, see below.

>   A formal grammar for the client message using Augmented BNF [ABNF]
>   is provide below as a tool for understanding this technical
>   specification.
>
>   message     = [ email / token ]
>                 ;; MUST be prepared in accordance with Section 2
>
>   UTF1        = %x00-3F / %x41-7F ;; less '@' (U+0040)
>   UTF2        = %xC2-DF UTF0
>   UTF3        = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
>                 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
>   UTF4        = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
>                 %xF4 %x80-8F 2(UTF0)
>   UTF0        = %x80-BF
>
>   TCHAR       = UTF1 / UTF2 / UTF3 / UTF3 / UTF4
>               ;; any UTF-8 encoded Unicode character
>               ;; except '@' (U+0040)

Hmm, this suggests a typo in draft-yergeau-rfc2279bis-04.txt (UTF3 is
shown twice).

Also note, that this doesn't have UTF5 & UTF6 that you currently have:

      UTF5        = %xF8-FB 4(UTF0)
      UTF6        = %xFC-FD 5(UTF0)

(but they have to be cleaned up to prevent overlong sequences).

>   email       = addr-spec
>               ;; as defined in [IMAIL], except with no free
>               ;; insertion of linear-white-space, and the
>               ;; local-part MUST either be entirely enclosed in
>               ;; quotes or entirely unquoted
>
>   token       = 1*255TCHAR
>
> and add an appropriate acknowledgement.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00) 
Date: Thu, 20 Feb 2003 11:56:34 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:
...
>I gather that you are saying that ABNF is not precise enough.
>(please correct me if I wrongly gathered).  While I can
>see that if you ignored all other text and the comments within
>the ABNF, one could presume that the message, in hex, 0C 30
>was valid.... if one actually ignored all the other text
>and the comments they could also presume that the invalid
>messages 00 (in hex), foo"bar"@x (in ASCII), and many others
>were valid.

No, the latter is not valid by the grammar.

My dislike for the current formulation is two-fold:

TCHAR, as defined, isn't actually "any UTF-8 encoded Unicode character
except '@' (U+0040)" as described in the comment.  The UTF5 and UTF6
definitions do not match any legal UTF-8 character and the UTF3 and UTF4
definitions match illegal UTF-8 characters.

I would prefer to find all the restrictions on what characters are legal
in a token in a single location.  The grammar could simply define TCHAR
as a UTF-8 encoded character (perhaps using the productions in the draft
Alexey mentioned) while the stringprep profile could handle all the
restrictions on content at the level of Unicode characters.  Yes, this
makes the grammar ambiguous, but even rfc2822, the first 'target' for
ABNF, has an amibiguous grammar that is only resolved by semantic
restrictions in the general text.

>Obviously, the grammar is not intended to be taken out of
>context.  It is provided as a tool for understanding the
>text of the specification.

As always, clarity and correctness are the goals.  IMHO, defining a
non-terminal that's neither a superset nor a subset of UTF-8, with
additional restrictions elsewhere, makes it more difficult to
understand.

Philip Guenther

Date: Thu, 20 Feb 2003 11:55:11 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Unicode/UTF-8 issues (was: comments ondraft-ietf-sasl-anon-00)
Cc: Philip Guenther <[email-masked]>, [email-masked]
Sender: [email-masked]

Okay, how about I replace the grammar and the paragraph before
it as follows:

  A formal grammar for the client message using Augmented BNF [ABNF]
  is provide below as a tool for understanding this technical
  specification.

  message     = [ email / token ]
                ;; MUST be prepared in accordance with Section 2

  UTF1        = %x00-3F / %x41-7F ;; less '@' (U+0040)
  UTF2        = %xC2-DF UTF0        
  UTF3        = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /               
                %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)               
  UTF4        = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /                 
                %xF4 %x80-8F 2(UTF0)          
  UTF0        = %x80-BF

  TCHAR       = UTF1 / UTF2 / UTF3 / UTF3 / UTF4                  
              ;; any UTF-8 encoded Unicode character
              ;; except '@' (U+0040)

  email       = addr-spec
              ;; as defined in [IMAIL], except with no free
              ;; insertion of linear-white-space, and the
              ;; local-part MUST either be entirely enclosed in
              ;; quotes or entirely unquoted

  token       = 1*255TCHAR

and add an appropriate acknowledgement.

Kurt

Date: Thu, 20 Feb 2003 11:30:21 -0800
To: Philip Guenther <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: realms (Was: comments on draft-ietf-sasl-anon-00)
Cc: [email-masked]
Sender: [email-masked]

At 11:54 PM 2/19/2003, Philip Guenther wrote:
>The ANONYMOUS mechanism does not provide a means for the client to
>supply an optional realm in which the anonymous authentication should
>take place.

Correct, it doesn't.  (The trace information has no semantical
value.)

>This makes the ANONYMOUS mechanism unusable by servers that
>support multiple realms on a single communication end-point; it cannot
>supplant the "anonymous@domain" login supported by, for example, some
>IMAP servers.

Maybe so. 

Are you asking for the WG to consider adding realm support
to ANONYMOUS mechanism?  Or asking the WG to consider
clarifications to the ANONYMOUS mechanism that it is not
applicable in scenarios allowing different anonymous
associations to be established?

Kurt

Date: Thu, 20 Feb 2003 12:18:34 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Philip Guenther <[email-masked]>, [email-masked]
Subject: Re: Unicode/UTF-8 issues (was: comments ondraft-ietf-sasl-anon-00)
Sender: [email-masked]

> >I believe Philip was referring to ABNF which allows for overlong UTF8
> >sequences.
>
> I gather that you are saying that ABNF is not precise enough.

Correct.

> (please correct me if I wrongly gathered).  While I can
> see that if you ignored all other text and the comments within
> the ABNF, one could presume that the message, in hex, 0C 30
> was valid.... if one actually ignored all the other text
> and the comments they could also presume that the invalid
> messages 00 (in hex), foo"bar"@x (in ASCII), and many others
> were valid.
>
> Obviously, the grammar is not intended to be taken out of
> context.  It is provided as a tool for understanding the
> text of the specification.

I've seen the version of the grammer that deals with overlong sequence.
Check draft-yergeau-rfc2279bis-04.txt section 4.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Thu, 20 Feb 2003 11:09:07 -0800
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00)
Cc: Philip Guenther <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:24 AM 2/20/2003, Alexey Melnikov wrote:
>> At 11:54 PM 2/19/2003, Philip Guenther wrote:
>> >The syntax for UTF-8 characters in the draft permits "non-shortest form"
>> >encodings
>>
>> I'm not exactly sure what you are referring to here.  The
>> draft says that the trace information is transferred as
>> string of UTF-8 encoded Unicode characters.  A non-shorted
>> form UTF-8 encoding of a Unicode character is invalid per
>> RFC 2247.  I believe draft-yergeau-rfc2279bis-04.txt is
>> more clear on this, so I'll change the reference.
>
>I believe Philip was referring to ABNF which allows for overlong UTF8
>sequences.

I gather that you are saying that ABNF is not precise enough.
(please correct me if I wrongly gathered).  While I can
see that if you ignored all other text and the comments within
the ABNF, one could presume that the message, in hex, 0C 30
was valid.... if one actually ignored all the other text
and the comments they could also presume that the invalid
messages 00 (in hex), foo"bar"@x (in ASCII), and many others
were valid.

Obviously, the grammar is not intended to be taken out of
context.  It is provided as a tool for understanding the
text of the specification.
  
Kurt 

Date: Thu, 20 Feb 2003 11:24:58 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Kurt D. Zeilenga" <[email-masked]>
CC: Philip Guenther <[email-masked]>, [email-masked]
Subject: Re: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00)
Sender: [email-masked]

"Kurt D. Zeilenga" wrote:

> At 11:54 PM 2/19/2003, Philip Guenther wrote:
> >The syntax for UTF-8 characters in the draft permits "non-shortest form"
> >encodings
>
> I'm not exactly sure what you are referring to here.  The
> draft says that the trace information is transferred as
> string of UTF-8 encoded Unicode characters.  A non-shorted
> form UTF-8 encoding of a Unicode character is invalid per
> RFC 2247.  I believe draft-yergeau-rfc2279bis-04.txt is
> more clear on this, so I'll change the reference.

I believe Philip was referring to ABNF which allows for overlong UTF8
sequences.

> If, however, you mean that the string of Unicode characters
> is not normalized using an algorithm which produces the
> minimum number of code points, yes.  This is as intended.

Regards,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Thu, 20 Feb 2003 10:04:34 -0800
To: Philip Guenther <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Unicode/UTF-8 issues (was: comments on draft-ietf-sasl-anon-00)
Cc: [email-masked]
Sender: [email-masked]

At 11:54 PM 2/19/2003, Philip Guenther wrote:
>The syntax for UTF-8 characters in the draft permits "non-shortest form"
>encodings

I'm not exactly sure what you are referring to here.  The
draft says that the trace information is transferred as
string of UTF-8 encoded Unicode characters.  A non-shorted
form UTF-8 encoding of a Unicode character is invalid per
RFC 2247.  I believe draft-yergeau-rfc2279bis-04.txt is
more clear on this, so I'll change the reference.

If, however, you mean that the string of Unicode characters
is not normalized using an algorithm which produces the
minimum number of code points, yes.  This is as intended.

>and encodings for characters outside the range of the Unicode
>character set.

Unassigned code points may be transferred.  I will clarify
that as I noted in another post.  However, I believe the
specification is clear that characters "outside the range",
e.g. not in the repertoire of characters, are invalid.

>Neither may be interpreted by a program conforming to
>the Unicode 3.2 specification, which the draft references.

Which is exactly why the specification restricts the string
to a particular repertoire of characters.

Kurt 

Date: Thu, 20 Feb 2003 08:45:00 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last call for draft-ietf-sasl-anon-00
Cc: [email-masked]
Sender: [email-masked]

At 07:20 AM 2/20/2003, Simon Josefsson wrote:
>The stringprep profile in section 2 is silent on unassigned code point
>handling.  Perhaps clarify that the list of unassigned code points is
>empty, if that is indeed what is intended?

I intended:
        The list of unassigned code points for this profile is
        that provided in appendix A of [RFC 3454].  Unassigned
        code points are not prohibited.

Kurt 

To: [email-masked]
Subject: Re: Last call for draft-ietf-sasl-anon-00
From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Feb 2003 16:20:04 +0100
Sender: [email-masked]

The stringprep profile in section 2 is silent on unassigned code point
handling.  Perhaps clarify that the list of unassigned code points is
empty, if that is indeed what is intended?

,---- RFC 3454
|    The list of unassigned code points MUST be given in a profile, and
|    that list MUST be used by implementations of the profile.
`----

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-rfc2831bis-00.txt
Date: Thu, 20 Feb 2003 07:38:08 -0500
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-00.txt
	Pages		: 35
	Date		: 2003-2-19
	
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-00.txt

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-00.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-rfc2831bis-00.txt".

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

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

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

--OtherAccess--

--NextPart--

Date: Thu, 20 Feb 2003 05:33:31 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Philip Guenther <[email-masked]>
CC: [email-masked]
Subject: Re: comments on draft-ietf-sasl-anon-00
Sender: [email-masked]

Philip Guenther wrote:

> The ANONYMOUS mechanism does not provide a means for the client to
> supply an optional realm in which the anonymous authentication should
> take place.  This makes the ANONYMOUS mechanism unusable by servers that
> support multiple realms on a single communication end-point;

See below.

> it cannot supplant the "anonymous@domain"

Which conforms to the syntax for "email", isn't it?

> login supported by, for example, some IMAP servers.

Server is not supposed to verify "email", so anything that looks like
"email" just works fine.

Regards,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

To: [email-masked]
Subject: comments on draft-ietf-sasl-anon-00
Date: Wed, 19 Feb 2003 23:54:04 -0800
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

The syntax for UTF-8 characters in the draft permits "non-shortest form"
encodings and encodings for characters outside the range of the Unicode
character set.  Neither may be interpreted by a program conforming to
the Unicode 3.2 specification, which the draft references.

Paragraph 5 of section 4 (security consideration), suggests the use of
an idle timeout on servers that place a limit on the number of
concurrent anonymous users in order to combat a denial-of-service
attack.  As keeping a connection from being considered idle will
generally require simply sending a request (possibly even a malformed
request), it's unlikely that an idle timeout will actually prevent an
intentional DOS attack from succeeding.  A hard timeout on connection
duration, network access limitations, or (where appropriate) a limit on
the number of requests permitted on an anonymous connection may be
required to provide a minimal service guarantee in the face of malicious
access.

The ANONYMOUS mechanism does not provide a means for the client to
supply an optional realm in which the anonymous authentication should
take place.  This makes the ANONYMOUS mechanism unusable by servers that
support multiple realms on a single communication end-point; it cannot
supplant the "anonymous@domain" login supported by, for example, some
IMAP servers.

Philip Guenther

To: [email-masked]
Subject: Last call for draft-ietf-sasl-anon-00
From: Sam Hartman <[email-masked]>
Date: Wed, 19 Feb 2003 15:13:18 -0500
Sender: [email-masked]

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

        Title           : The Anonymous SASL Mechanism
        Editor          : K. Zeilenga
        Filename        : draft-ietf-sasl-anon-00.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 Wednesday,
March 5, 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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-plain-00.txt
Date: Tue, 11 Feb 2003 06:46:27 -0500
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 Plain SASL Mechanism
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-plain-00.txt
	Pages		: 8
	Date		: 2003-2-10
	
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-00.txt

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-00.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sasl-plain-00.txt".

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

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

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

--OtherAccess--

--NextPart--