Subject: PCS CELL PHONE & 2000 GATEWAY 333 MHZ COMPUTERS!!! ALL FOR THE ASKING !!

From: [email-masked]
Date: Mon, 26 Oct 98 21:54:14 EST

<HTML><PRE>WANT TO ELIMINATE ONE OF YOUR LARGEST UTILITY BILLS AND GET A COMPLETELY PAID-FOR COMPUTER???

ABSOLUTELY EVERYONE QUALIFIES.......
NO CREDIT CHECKS, NO ONE TURNED DOWN.

Would you like to receive a PCS Digital Phone (which is not only a phone but an answering machine and pager as well) and completely eliminate your long distance bills??? And, want a completely paid for 2000 Gateway 333 MHZ computer delivered rignt to your door.. and, as if that isn't enough, how about earning considerable long-term income in the process??? You can earn from $650.00 to $1950.00 a day possible. 

THEN DO YOURSELF A FAVOR AND TAKE 30 SECONDS TO CONTINUE READING THIS!!!
Be prepared to be shocked and Amazed at the information you are about to discover!! You can actually receive all the above. The company is at a pre pre-launch and people are getting involved in the hundreds because of this incredible opportunity. No folks, this is not a joke. It is as real as it can be!!! What you will read is actual and people are earning Cell phones and computers!!! No contract to sign, No finance papers to sign and no roaming fees to pay!!!  

 Pre-launch Announcement - Take Advantage Of  It !!

Get a Cellular Phone Free and Never pay Long Distance Again!!
Receive a 2000 Gateway 333 MHZ Computer (see below for specs)

<U>Computer Specs:</U>
Processor 333 MHz w/128k Cache
32MB RAM
3.2 Gigabyte Hard Drive
1.44 MB Floppy Drive
32x CD-ROM
Sound Blaster 64V w/Speakers
4MB 3-D AGP Video Card
US Robotics 56K Flex Modem
Mid-tower Case w/Mouse & Keyboard
15" SVGA Monitor
Windows98 & Home Essentials 98
Gateway Gold Service

IN ADDITION TO THAT YOU HAVE THE POTENTIAL TO EARN THE FOLLOWING:

Earn up To $1950.00 Per Day
And up to $300.00 of FREE AIR TIME On Your Cell Phone Per Day!!!
                                 PLUS
40% Matching Bonus On Everyone You Personally Sponsor.
                 ($650.00 per day-per center-Plus Bonuses)

CALCULATED DAILY , PAID WEEKLY!

Plus....Self-Replicating Websites, Genealogies Online, Leg Counts Online....Monthly Residual Earnings on High Tech Life Changing Products.
Low Entry - High Return. 
  
This is an explosive program with the most sought after products and one of the best compensation plans EVER!!!

Easy Duplication - Just think. If I was to ask you a simple question like this: If I can show you a way to eliminate your long distance phone bill by using a cell phone that will earn pre-paid free air  time and have the ability to be a pager and answering machine, would that interest you? If I can show you how to earn a FREE 2000 Gateway 333 MHZ Computer without signing your life away on any dotted line for any type of financing and it was given to YOU absolutely FREE. Would that interest you? And do you think you know 2 people that would also say yes to the above question??? You got it!!  The answer is very simple. 

OF COURSE YOU WOULD !!! Who wouldn't. In addition to that we will show you how you can earn from $650.00 a day to $1950.

If you are truly tired of building and waiting to get paid.....YOU must act on this opportunity and need to talk to me. Positioning is the KEY and the OPPORTUNITY IS PHENOMINAL!!! I am a leader in the Network Marketing Industry and have been extremely successful and NOW I have been given this opportunity. The sky is the limit. We estimate to have over 5,000 new members by the end of November. Where will you be? At the top I hope. So Join our TEAM  if you truly are serious about wanting to make a change in your life financially. 

This plan is totally unheard of !! And people are getting PAID!!!! I joined a couple of weeks ago and I have all ready earned two checks and my very own cell phone!!!. This company pays weekly!!! I earned my very first paycheck on the first week and the second one on the second week!! You bet I am excited!!! And YES I truly received my checks !!!   

<FONT COLOR="#000000" SIZE=5><B>FOR FURTHER INFORMATION CALL:
       <FONT COLOR="#000000" SIZE=6>800-600-0343  EXT. 2158
</P><P ALIGN=CENTER><FONT COLOR="#000000" SIZE=1> DUE TO THE OVERWHELMING SUCCESS, IF YOU EXPERIENCE A BUSY SIGNAL, 
PLEASE TRY AGAIN.  
</P><P ALIGN=LEFT><FONT COLOR="#000000" SIZE=3></B>

</PRE></HTML>

From: [email-masked]
Date: Mon, 26 Oct 98 21:54:14 EST
To: [email-masked]
Subject: PCS CELL PHONE & 2000 GATEWAY 333 MHZ COMPUTERS!!! ALL FOR THE ASKING !!
Sender: [email-masked]

<HTML><PRE>WANT TO ELIMINATE ONE OF YOUR LARGEST UTILITY BILLS AND GET A COMPLETELY PAID-FOR COMPUTER???

ABSOLUTELY EVERYONE QUALIFIES.......
NO CREDIT CHECKS, NO ONE TURNED DOWN.

Would you like to receive a PCS Digital Phone (which is not only a phone but an answering machine and pager as well) and completely eliminate your long distance bills??? And, want a completely paid for 2000 Gateway 333 MHZ computer delivered rignt to your door.. and, as if that isn't enough, how about earning considerable long-term income in the process??? You can earn from $650.00 to $1950.00 a day possible. 

THEN DO YOURSELF A FAVOR AND TAKE 30 SECONDS TO CONTINUE READING THIS!!!
Be prepared to be shocked and Amazed at the information you are about to discover!! You can actually receive all the above. The company is at a pre pre-launch and people are getting involved in the hundreds because of this incredible opportunity. No folks, this is not a joke. It is as real as it can be!!! What you will read is actual and people are earning Cell phones and computers!!! No contract to sign, No finance papers to sign and no roaming fees to pay!!!  

 Pre-launch Announcement - Take Advantage Of  It !!

Get a Cellular Phone Free and Never pay Long Distance Again!!
Receive a 2000 Gateway 333 MHZ Computer (see below for specs)

<U>Computer Specs:</U>
Processor 333 MHz w/128k Cache
32MB RAM
3.2 Gigabyte Hard Drive
1.44 MB Floppy Drive
32x CD-ROM
Sound Blaster 64V w/Speakers
4MB 3-D AGP Video Card
US Robotics 56K Flex Modem
Mid-tower Case w/Mouse & Keyboard
15" SVGA Monitor
Windows98 & Home Essentials 98
Gateway Gold Service

IN ADDITION TO THAT YOU HAVE THE POTENTIAL TO EARN THE FOLLOWING:

Earn up To $1950.00 Per Day
And up to $300.00 of FREE AIR TIME On Your Cell Phone Per Day!!!
                                 PLUS
40% Matching Bonus On Everyone You Personally Sponsor.
                 ($650.00 per day-per center-Plus Bonuses)

CALCULATED DAILY , PAID WEEKLY!

Plus....Self-Replicating Websites, Genealogies Online, Leg Counts Online....Monthly Residual Earnings on High Tech Life Changing Products.
Low Entry - High Return. 
  
This is an explosive program with the most sought after products and one of the best compensation plans EVER!!!

Easy Duplication - Just think. If I was to ask you a simple question like this: If I can show you a way to eliminate your long distance phone bill by using a cell phone that will earn pre-paid free air  time and have the ability to be a pager and answering machine, would that interest you? If I can show you how to earn a FREE 2000 Gateway 333 MHZ Computer without signing your life away on any dotted line for any type of financing and it was given to YOU absolutely FREE. Would that interest you? And do you think you know 2 people that would also say yes to the above question??? You got it!!  The answer is very simple. 

OF COURSE YOU WOULD !!! Who wouldn't. In addition to that we will show you how you can earn from $650.00 a day to $1950.

If you are truly tired of building and waiting to get paid.....YOU must act on this opportunity and need to talk to me. Positioning is the KEY and the OPPORTUNITY IS PHENOMINAL!!! I am a leader in the Network Marketing Industry and have been extremely successful and NOW I have been given this opportunity. The sky is the limit. We estimate to have over 5,000 new members by the end of November. Where will you be? At the top I hope. So Join our TEAM  if you truly are serious about wanting to make a change in your life financially. 

This plan is totally unheard of !! And people are getting PAID!!!! I joined a couple of weeks ago and I have all ready earned two checks and my very own cell phone!!!. This company pays weekly!!! I earned my very first paycheck on the first week and the second one on the second week!! You bet I am excited!!! And YES I truly received my checks !!!   

<FONT COLOR="#000000" SIZE=5><B>FOR FURTHER INFORMATION CALL:
       <FONT COLOR="#000000" SIZE=6>800-600-0343  EXT. 2158
</P><P ALIGN=CENTER><FONT COLOR="#000000" SIZE=1> DUE TO THE OVERWHELMING SUCCESS, IF YOU EXPERIENCE A BUSY SIGNAL, 
PLEASE TRY AGAIN.  
</P><P ALIGN=LEFT><FONT COLOR="#000000" SIZE=3></B>

</PRE></HTML>

Date: Tue, 13 Oct 1998 10:19:54 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: RE: SASL security layers
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Paul Leach <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

On Mon, 12 Oct 1998, Paul Leach wrote:
> Does the "buffer" include the security mechanism's trailer, or not?

A SASL security layer is a stream of blocks, each with a four-byte length.
The concept of a "trailer" isn't part of SASL, so it would be part of the
buffer.

The basic idea is that the blocking & buffering code is completely
independent of the mechanism used.

		- Chris

From: Paul Leach <[email-masked]>
To: "'Chris Newman'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: SASL security layers
Date: Mon, 12 Oct 1998 21:36:54 -0700
Sender: [email-masked]

Does the "buffer" include the security mechanism's trailer, or not?

> -----Original Message-----
> From: Chris Newman [mailto:[email-masked]]
> Sent: Monday, October 12, 1998 11:35 AM
> To: Paul Leach
> Cc: [email-masked]'
> Subject: Re: SASL security layers
> 
> 
> On Fri, 9 Oct 1998, Paul Leach wrote:
> > When applied to GSS mechanisms, the following issue arises. 
> My data stream
> > looks like this:
> > 
> > 	4 byte count
> > 	App protocol data unit (APDU)
> > 	padding to cipher block size
> > 	GSS mechanism trailer
> 
> SASL only specifies that the cipher text buffers begin with a 4-octet
> count (covering the remainder of the buffer).  The structure 
> of the cipher
> text buffers is otherwise entirely defined by the mechanism.
> 
> If you're using the GSSAPI SASL mechanism, the buffer consists of the 
> entire output of a GSS_Wrap operation, with a SASL 
> security-layer buffer
> length prepended.
> 
> 		- Chris
> 
> 

Date: Mon, 12 Oct 1998 11:35:08 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: SASL security layers
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Paul Leach <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

On Fri, 9 Oct 1998, Paul Leach wrote:
> When applied to GSS mechanisms, the following issue arises. My data stream
> looks like this:
> 
> 	4 byte count
> 	App protocol data unit (APDU)
> 	padding to cipher block size
> 	GSS mechanism trailer

SASL only specifies that the cipher text buffers begin with a 4-octet
count (covering the remainder of the buffer).  The structure of the cipher
text buffers is otherwise entirely defined by the mechanism.

If you're using the GSSAPI SASL mechanism, the buffer consists of the 
entire output of a GSS_Wrap operation, with a SASL security-layer buffer
length prepended.

		- Chris

From: Paul Leach <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: SASL security layers
Date: Fri, 9 Oct 1998 16:27:04 -0700 
Sender: [email-masked]

I'm trying to add a confidentiality layer to Digest SASL mechanism. In the
process, some questions arose.

RFC 2222 says:

"If use of a security layer is negotiated, it is applied to all
   subsequent data sent over the connection.  The security layer takes
   effect immediately following the last response of the authentication
   exchange for data sent by the client and the completion indication
   for data sent by the server.  Once the security layer is in effect,
   the protocol stream is processed by the security layer into buffers
   of cipher-text.  Each buffer is transferred over the connection as a
   stream of octets prepended with a four octet field in network byte
   order that represents the length of the following buffer.  The length
   of the cipher-text buffer must be no larger than the maximum size
   that was defined or negotiated by the other side."

When applied to GSS mechanisms, the following issue arises. My data stream
looks like this:

	4 byte count
	App protocol data unit (APDU)
	padding to cipher block size
	GSS mechanism trailer

All three of those are variable length. (There is a slight constraint on the
padding -- the sum of the length of the APDU and the padding is 0 mod the
cipher blocksize.) How does one locate:
1. The start of the padding
2. The start of the trailer
3. The start of the next buffer

Can any one tell me how this is supposed to work?

Paul

PS: It would be much more convenient if the data stream looked like:

	4 byte count
	App protocol data unit (APDU)
	padding to cipher block size
      4 byte trailer size
	GSS mechanism trailer

Date: Sat, 10 Oct 1998 01:04:32 +0400
From: Alexey Melnikov <[email-masked]>
Reply-To: [email-masked]
Organization: Epsylon Technologies
To: Chris Newman <[email-masked]>, IETF SASL List <[email-masked]>
Subject: Re: SMTP AUTH design-team meeting addendum
Sender: [email-masked]

Chris Newman wrote:

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

>From other side, IMHO, new clients MAY (or even SHOULD) remember passwords.
However clients SHOULD be configured not to do this.

Cheers,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team
"ACAP Explorer" client

Epsylon Technologies, Russia
 http://www.demo.ru

Imap Development Kit (my own product)
http://www.demo.ru/homerus/mail/idk/index.htm
------------------------------------------

From: [email-masked]
Date: Fri, 09 Oct 98 01:21:06 EST
To: [email-masked]
Subject: FREE CELL PHONES AND NO BILLS!
Sender: [email-masked]

Positioning Key Leaders Now - Pre-launch Announcement - Take Advantage Of  It
!!
Get a Cellular Phone Free and Never pay Long Distance Again!!
Now You Have the Potential To Earn up To $1950.00 Per Day
And up to $300.00 of FREE AIR TIME On Your Cell Phone.
                                 PLUS
40% Matching Bonus On Everyone You Personally Sponsor.
                 ($650.00 per day-per center-Plus Bonuses)

CALCULATED DAILY , PAID WEEKLY!

No credit check, No turn downs, No roaming Fee and no contracts.
 
Plus....Self-Replicating Websites, Genealogies Online, Leg Counts
Online....Monthly Residual Earnings

We have been overwhelmed with incoming calls and have alot of leads to share
with you if you join our team today. So let's work together and build a strong
business for you and your team. No co-op fees to pay or seach for any leads to
call. We have plenty of leads to share with you if you are willing to work
with us. We build leaders every single day!! We generate leads to  help you
build your business.  This is an explosive program with the most sought after
products and one of the best compensation plans EVER!!!

Easy Duplication - Just think. If I was to ask you a simple question like
this: If I can show you a way to eliminate your long distance phone bill by
using a cell phone that will earn pre-paid free time and have the ability to
be a pager and answering machine, would that interest you? And do you think
you know 2 people that would also like to eliminate their phone bill? You got
it!!  The answer is very simple. 
OF COURSE YOU WOULD !!! Who wouldn't. In addition to that we will show you how
you can earn from $650.00 a day to $1950 a day by sharing this with just two
people.

If you are a leader and would like to share this plan with more than 2 people,
don't forget you will earn 40% matching bonuses on all personally sponsored.

We have just started promoting this opportunity a couple of weeks ago and have
brought in quite a few leaders. If you are truly tired of building and waiting
to get paid.....YOU must act on this opportunity and need to talk to me.
Positioning is the KEY and the OPPORTUNITY IS PHENOMINAL!!! I am a leader in
the Network Marketing Industry and have been extremely successful and NOW I
have been given this opportunity to help launch this company. The sky is the
limit. We estimate to have over 5,000 new members by the end of October. Where
will you be? At the top I hope. So Join our TEAM  and climb it with us. And if
you would like to be a leader, I welcome your phone call so we can talk. We do
not discriminate and we consider everyone a LEADER that wants to help build
with us. Within 2 weeks we have all ready brought aboard major proffesional
network marketers who have recognized this opportunity, so we hope you take
the time to check the following numbers below. Upon completing the below
instructions, please give me a call so we can discuss it further.

1- 2 minute sizzle - 918-222-7233 - key in option number 1
2- Pull up the fax on demand - 918-222-7233 - option 5  
                     or
Go to our website at www.atinetwork.com
( This is just a temporary splash page. Take a look and see why so many people
are so excited about this program. Actual website is under construction,
website will be up and running is 1 week)

***You will notice on the fax on demand that it has specific details on the
entire compensation plan. We have also brought aboard some high tech
nutritionals that will build our residuals month in and month out. This plan
is totally unheard of !!
After you have retrieved the information, give us a call so we can explain it
to you. We guarantee you will not sleep after you understand what we have put
in place to make it possible for everyone to WIN WIN WIN.
To leave your name and number, please call:  800-600-0343  ext. 2158

(Due to the overwhelming success, if you experience a busy signal. Please try
again)

***If you do not have a fax machine , give me a call and leave your message
and I will make arrangements to send you the paperwork.*****       

Date: Thu, 8 Oct 1998 15:16:38 -0700
To: Dave Crocker <[email-masked]>, Randall Gellens <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: SMTP AUTH design-team meeting addendum
Cc: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

I agree this change makes the text easier to read.

Date: Thu, 08 Oct 1998 16:59:42 +0300
From: Alexey Melnikov <[email-masked]>
To: Marc Horowitz <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: SASL profile for FTP?
Sender: [email-masked]

Marc Horowitz wrote:

> Chris Newman <[email-masked]> writes:
>
> >> When the FTP security stuff was being debated, John Myers proposed a 5
> >> page SASL-based alternative to the 27 page RFC 2228.  Incidentally, the
> >> CAT WG (a security area WG) ignored John's proposal.  I suppose one could
> >> draw some conclusions from this and the subsequent deployment patterns of
> >> RFC 2228.
>
> There's eight implementations of rfc 2228.
>
> SASL is simpler, I admit.  But there were implementations of ftpsec
> shipping before SASL was generalized.  Shooting the existing
> implementors is poor practice.
>
> Do a SASL profile, and let the market decide.

May be I am wrong, but after my reading of document, SASL profile can be derived
from RFC 2228.

Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team
"ACAP Explorer" client
Imap Development Kit (my own product)

Epsylon Technologies, Russia
 http://www.demo.ru
------------------------------------------

From: Paul Leach <[email-masked]>
To: "'Hallvard B Furuseth'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Compromise Authentication Proposal
Date: Wed, 7 Oct 1998 12:22:49 -0700 
Sender: [email-masked]

The LDAP server can do one of several things for usernames that aren't DNs.

1. It can lookup the username in an authentication database that is NOT the
directory itself. This is not the most natural thing for a directory service
to do, but for lots of other services they don't have an obvious database --
mail protocols for example.

2. It can do a search for some attribute of the user's entry whose value is
the username. The "uid" attribute (e-mail address, IIRC) is one such choice,
and would integrate quite well with all of the mail protocols (at least).

3. It can hand control of the whole authentication exhange to the
authentication system on the machine it is running on. Part of the
philosophy of the SASL approach is that one can use implementations of SASL
mechanisms across many application protocols.

> -----Original Message-----
> From: Hallvard B Furuseth [mailto:[email-masked]]
> Sent: Wednesday, October 07, 1998 11:48 AM
> To: Paul Leach
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: Compromise Authentication Proposal
> 
> 
> I've missed something: What can the LDAP server *do* with the 
> usernames
> we bind as?  It's simple enough if the username is a DN, of course.
> But if I bind as "hbf", may the server translate that to a DN - e.g.
> with a local subtree search for (&(uid=hbf)(objectclass=person))?
> May it bind as user user "hbf" which does not correspond to a DN, in a
> private user file?
> 
> -- 
> Hallvard
> 

From: Paul Leach <[email-masked]>
To: "'Hallvard B Furuseth'" <[email-masked]>, [email-masked]
Subject: RE: draft-leach-digest-sasl-00.txt typo
Date: Wed, 7 Oct 1998 12:07:28 -0700 
Sender: [email-masked]

Will be fixed in the next draft; already in my editing copy. Thanks.

> -----Original Message-----
> From: Hallvard B Furuseth [mailto:[email-masked]]
> Sent: Wednesday, October 07, 1998 11:59 AM
> To: [email-masked]
> Subject: draft-leach-digest-sasl-00.txt typo
> 
> 
> 2.1.2.1   Response-value
> 
> >      A2       = { "AUTHENTICATE:", digest-uri-value,
> >               ":00000000000000000000000000000000" }
> > 
> >   i.e., a string of two colons followed by 32 zeros.
> 
> The displayed string has only one colon.
> 
> -- 
> Hallvard
> 

Date: Wed, 7 Oct 1998 20:58:46 +0200 (MET DST)
From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: draft-leach-digest-sasl-00.txt typo
Sender: [email-masked]

2.1.2.1   Response-value

>      A2       = { "AUTHENTICATE:", digest-uri-value,
>               ":00000000000000000000000000000000" }
> 
>   i.e., a string of two colons followed by 32 zeros.

The displayed string has only one colon.

-- 
Hallvard

Date: Wed, 7 Oct 1998 20:48:16 +0200 (MET DST)
From: Hallvard B Furuseth <[email-masked]>
To: Paul Leach <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Compromise Authentication Proposal
Sender: [email-masked]

I've missed something: What can the LDAP server *do* with the usernames
we bind as?  It's simple enough if the username is a DN, of course.
But if I bind as "hbf", may the server translate that to a DN - e.g.
with a local subtree search for (&(uid=hbf)(objectclass=person))?
May it bind as user user "hbf" which does not correspond to a DN, in a
private user file?

-- 
Hallvard

To: Chris Newman <[email-masked]>
Cc: [email-masked]
Subject: Re: SASL profile for FTP?
From: Marc Horowitz <[email-masked]>
Date: 07 Oct 1998 02:21:49 -0400
Lines: 15
Sender: [email-masked]

Chris Newman <[email-masked]> writes:

>> > There's eight implementations of rfc 2228.
>> 
>> Better than I would have expected.  Any for MacOS and OpenVMS?

There's an implementation for MacOS which is mostly done, but isn't
released yet.  That's actually not one of the eight I was thinking of.
Don't ask me any more, because I regrettably can't talk much about it.
However, when it is announced, I'll certainly put it on
http://www.mit.edu/people/marc/ftpsec/implementations.html.

I don't know of any for OpenVMS.

		Marc

Date: Tue, 06 Oct 1998 22:42:27 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Compromise Authentication Proposal
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Mark C Smith <[email-masked]>
Cc: Paul Leach <[email-masked]>, IETF LDAP Extensions WG <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, 6 Oct 1998, Mark C Smith wrote:
> 4) Section 2.1.2 (Step Two): somewhere we need to define the serv-type
> for all the protocols we care about.  It would be nice to refer to
> something like the IANA list of protocol names or URI prefixes or
> something, but I see "www" is used for HTTP.  LDAP should use "ldap" of
> course.

SASL explicitly references the GSSAPI service type registry.  It's at:

<http://www.isi.edu/in-notes/iana/assignments/gssapi-service-names>

I think the Digest spec should reference this as well.  This leverages the
service names used by Kerberos, and has an authentication focus.  It would
be bad if Kerberos and Digest used different service name registries, as
the higher level API would then have to pass down two parameters rather
than one.

There are actually two other service registries -- the one for WKS records
in DNS, and the one for domain name naming conventions.  The WKS record
registry is full of junk, so I wouldn't want to use that.  The domain name
naming convention has a different purpose (user friendly names), rather
than the purpose of dividing services into separately manageable groups.

		- Chris

Date: Tue, 06 Oct 1998 22:34:40 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: SASL profile for FTP?
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Marc Horowitz <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Tue, 6 Oct 1998, Marc Horowitz wrote:
> There's eight implementations of rfc 2228.

Better than I would have expected.  Any for MacOS and OpenVMS?

> SASL is simpler, I admit.  But there were implementations of ftpsec
> shipping before SASL was generalized.  Shooting the existing
> implementors is poor practice.
> 
> Do a SASL profile, and let the market decide.

Fair enough.

		- Chris

From: Paul Leach <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: IETF LDAP Extensions WG <[email-masked]>, [email-masked]
Subject: RE: Compromise Authentication Proposal
Date: Tue, 6 Oct 1998 19:46:53 -0700 
Sender: [email-masked]

> -----Original Message-----
> 
> *** Start of detailed comments on draft-leach-digest-sasl-00.txt:
> 
> 4) Section 2.1.2 (Step Two): somewhere we need to define the serv-type
> for all the protocols we care about.  It would be nice to refer to
> something like the IANA list of protocol names or URI prefixes or
> something, but I see "www" is used for HTTP.  LDAP should use 
> "ldap" of
> course.

The list is in RFC 2219. Here it is:

        ----------------------------------------------------------
        Alias     Service
        -----------------------------------------------------------
        archie    archie [ARCHIE]
        finger    Finger [RFC-1288]
        ftp       File Transfer Protocol [RFC-959]
        gopher    Internet Gopher Protocol [RFC-1436]
        ldap      Lightweight Directory Access Protocol [RFC-1777]
        mail      SMTP mail [RFC-821]
        news      Usenet News via NNTP [RFC-977]
        ntp       Network Time Protocol [RFC-1305]
        ph        CCSO nameserver [PH]
        pop       Post Office Protocol [RFC-1939]
        rwhois    Referral WHOIS [RFC-1714]
        wais      Wide Area Information Server [RFC-1625]
        whois     NICNAME/WHOIS [RFC-954]
        www       World-Wide Web HTTP [RFC-1945]

Paul

From: Paul Leach <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: IETF LDAP Extensions WG <[email-masked]>, [email-masked]
Subject: RE: Compromise Authentication Proposal
Date: Tue, 6 Oct 1998 19:42:17 -0700 
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 06, 1998 6:47 PM

Thanks for the comments. Responses interleaved below.

> Subject: Re: Compromise Authentication Proposal
> 
> *** Start of detailed comments on draft-leach-digest-sasl-00.txt:
> 
> 1) Section 1 and section 3.1 seem to be in conflict with respect to
> support for confidentiality.  I don't see anything in the 
> document that
> provides confidentiality of messages other than those for the password
> exchange itself, so I think section 1 is in error.

I had a section on confidentiality. It was real simple. The way to make it
simple is to hard-wire the cipher. Chris and the TLS experience convinced me
one needs to be able to negotiate the cipher. That got to be less simple. I
didn't want working out the kinks to hold up what was already overdue, and
which was not supported by CRAM-MD5 anyway.

> 
> 2) Section 2.1.1 (Step One) indicates that the server begins the SASL
> exchange, but in LDAP (and IMAP for that matter I think) the client
> actually needs to begin the exchange.  Is this issue covered 
> in the SASL
> RFC? 

Yes. It says that the client sends an empty "initial response".

 Either way, I'd like to see a note added to this document or to
> the LDAP auth. methods draft to make it clear how LDAP client/server
> pairs will begin a DIGEST-MD5 exchange.

This is the correct approach, IMO -- it belongs in the SASL profile for
LDAP, which is essentially what the ldap-auth-methods draft is: the place
that interactions between the authentication protocol and the application
protocol are defined.

> 
> 3) Are there any serious restrictions on what a username can 
> look like?

No.
 
> Could it be an LDAP DN?

Yes.

>  Of course for compatibility with other
> protocols such as IMAP a DN might be a bad choice.

Indeed.

> It would be helpful if this document were clearer about how usernames are
to be used.

I'm not sure how.

This is a layering issue, and a system issue. One of the ideas behind Digest
(and CRAM-MD5 before it) was that Digest could be used as a common mechanism
for many application protocols. Obviously, each application protocol can not
dictate what the form of user names is independently of the authentication
protocol. First, because the application protocols could conflict. Second,
because all the app servers may want to use a common authentication service,
which won't be able to map lots of different user names for the same person
onto one account. Third because users won't like have to have lots of
different user names. Finally, because the authentication protocol may
impose requirements.

That all said, the Digest protocol imposes no restriction on what's in a
user name. It's just text. It'll take whatever you give it and throw it into
the MD5 hash. As long as all clients and server use exactly the same form
for the user name, it'll all work fine.

However, some implementation may have lots of problems with being told what
the form of a user name is. To take an old example that is no longer
commercially significant, Multics wanted user names to be of the form
"user.project". That's what the system access control mechanism demanded.

Bottom line: if Digest is being used to authenticate to a single application
server with a single application protocol, then the form of user names can
be completely up to the application protocol. However, if the server is
participating in a system of many servers running different application
protocols and they try and make the user's life simpler by sharing a common
authentication service, then the authentication service has to be able to
pick the form of user names. I think we should allow both approaches.

> 
> 4) Section 2.1.2 (Step Two): somewhere we need to define the serv-type
> for all the protocols we care about.  It would be nice to refer to
> something like the IANA list of protocol names or URI prefixes or
> something, but I see "www" is used for HTTP.  LDAP should use 
> "ldap" of
> course.

There is an RFC with all of these. 2052, I think. I'll find it and put in a
reference.

> 
> 5) Section 3.6 (Man in the Middle): An algorithm called "md5-neg" is
> mentioned but not defined in the document.

Bug. But that section needs to be fixed.

> 
> 6) Section 3.9 (Storing Passwords): I don't really like the idea of
> servers storing a hashed version of username:realm:passwd since
> usernames and realms may change at times when passwords 
> ideally don't. 
> Storing such a hash means I can't use the same password store in
> different realms or change user names without changing my  password as
> well.

First, as you point out below, they don't have to store the hash. 

Also, there's a HUGE advantage to the way it works -- I can use the same
password in different realms without having to trust all those realms to not
act as a client authenticate as me to any of them. One of the biggest
problems with password systems with many untrusting realms is that you would
have to choose a different password for each of them, making it very hard to
remember all of them. For an internet protocol in today's world of a huge
number of password protected sites, I think this it is intolerable to have
to pick a different password for each site to be secure.

A couple of things can be done to ameliorate the problem of storing the
hash. First, realms: the realm can be associated with the password store,
rather than the server.

Secoind, one may choose a form of user name _used to authenticate with_ that
does not have to change when the name of the user's entry in the directory
changes. This form can be a searchable attribute on the user's entry. This
means that moving the user's entry in the directory doesn't change the hash.

 It also makes it impossible for a servers in different 
> realms to
> share the same password store directly.  However, I understand the
> advantages (from a security standpoint) of storing the hash instead of
> a cleartext password, and believe that the choice of whether 
> to store the
> hash or a cleartext password is a policy decision that is best left up
> to implementors and deployers.

That choice is always available.

> 
> 7) Section 4 (Example): the last paragraph contains some non-ASCII
> characters (probably "smart quotes" or something similar).

I tired to catch all of them. Sorry.

Paul

Date: Wed, 07 Oct 1998 10:28:39 +0800
To: Randall Gellens <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: SMTP AUTH design-team meeting addendum
Cc: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

Small suggested change to put make the language state the positive:

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

...desire it.  Therefore servers SHOULD be configurable to advertise
authentication mechanisms only to clients which must use those
authentication mechanisms to obtain additional delivery rights or services.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                         Tel: +1(408)246 8253
<mailto:[email-masked]>                        675 Spruce Drive
                                                  Sunnyvale, CA 94086 USA
Brandenburg Consulting
<http://www.brandenburg.com>                         Tel: +60(19)3299 445
                                              Post Office Box 296, U.P.M.
Fax: +1(408)246 8253                     Serdang, Selangor 43400 MALAYSIA

Date: Tue, 06 Oct 1998 18:46:30 -0700
From: [email-masked] (Mark C Smith)
Organization: Netscape Communications
To: Paul Leach <[email-masked]>, [email-masked]
CC: IETF LDAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: Compromise Authentication Proposal
Sender: [email-masked]

Paul Leach wrote:
> 
> At Chicago, there was conditional concensus about using Digest as the MTI.
> It was conditional upon a digest/SASL spec being delivered "in a couple of
> weeks". It took a little longer than that, but I believe the precondition
> has now been met, and still seems to be relevant.
> 
> After a private conversation with Tim Howes, he suggested I "call the
> question". So here goes:
> 
> Are there any objections to making Digest/SASL the Mandatory-to-Implement
> non-plaintext password mechanism? If so, what are they?

No, although I have a bunch of relatively minor comments on the current
draft (see below).

> Are there any objections to making Digest/SASL the only
> Mandatory-to-Implement mechanism? If so, what are they?

If by this you mean "we plan to replace all occurrences of CRAM-MD5 with
DIGEST-MD5" in the LDAP Authentication Methods draft
(draft-ietf-ldapext-authmeth-02.txt), then I have no objections.  I
would like to see LDAP simple bind over TLS remain as a SHOULD for LDAP
though.

*** Start of detailed comments on draft-leach-digest-sasl-00.txt:

1) Section 1 and section 3.1 seem to be in conflict with respect to
support for confidentiality.  I don't see anything in the document that
provides confidentiality of messages other than those for the password
exchange itself, so I think section 1 is in error.

2) Section 2.1.1 (Step One) indicates that the server begins the SASL
exchange, but in LDAP (and IMAP for that matter I think) the client
actually needs to begin the exchange.  Is this issue covered in the SASL
RFC?  Either way, I'd like to see a note added to this document or to
the LDAP auth. methods draft to make it clear how LDAP client/server
pairs will begin a DIGEST-MD5 exchange.

3) Are there any serious restrictions on what a username can look like? 
Could it be an LDAP DN?  Of course for compatibility with other
protocols such as IMAP a DN might be a bad choice.  It would be helpful
if this document were clearer about how usernames are to be used.

4) Section 2.1.2 (Step Two): somewhere we need to define the serv-type
for all the protocols we care about.  It would be nice to refer to
something like the IANA list of protocol names or URI prefixes or
something, but I see "www" is used for HTTP.  LDAP should use "ldap" of
course.

5) Section 3.6 (Man in the Middle): An algorithm called "md5-neg" is
mentioned but not defined in the document.

6) Section 3.9 (Storing Passwords): I don't really like the idea of
servers storing a hashed version of username:realm:passwd since
usernames and realms may change at times when passwords ideally don't. 
Storing such a hash means I can't use the same password store in
different realms or change user names without changing my  password as
well.  It also makes it impossible for a servers in different realms to
share the same password store directly.  However, I understand the
advantages (from a security standpoint) of storing the hash instead of
acleartext password, and believe that the choice of whether to store the
hash or a cleartext password is a policy decision that is best left up
to implementors and deployers.

7) Section 4 (Example): the last paragraph contains some non-ASCII
characters (probably "smart quotes" or something similar).

*** End of detailed comments on draft-leach-digest-sasl-00.txt.

-- 
Mark Smith
Directory Architect / Netscape Communications Corp.
My words are my own, not my employer's.  Got LDAP?

To: Chris Newman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: SASL profile for FTP?
From: Marc Horowitz <[email-masked]>
Date: 06 Oct 1998 21:22:17 -0400
Lines: 17
Sender: [email-masked]

Chris Newman <[email-masked]> writes:

>> When the FTP security stuff was being debated, John Myers proposed a 5
>> page SASL-based alternative to the 27 page RFC 2228.  Incidentally, the
>> CAT WG (a security area WG) ignored John's proposal.  I suppose one could
>> draw some conclusions from this and the subsequent deployment patterns of
>> RFC 2228.

There's eight implementations of rfc 2228.

SASL is simpler, I admit.  But there were implementations of ftpsec
shipping before SASL was generalized.  Shooting the existing
implementors is poor practice.

Do a SASL profile, and let the market decide.

		Marc

Date: Tue, 06 Oct 1998 18:21:12 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: I-D ACTION:draft-leach-digest-sasl-00.txt (fwd)
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: [email-masked]
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-959030623-907723272=:17962
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email-masked]>

I'd like to ask people on the list to take a careful look at this internet
draft.

One of the nastier problems the IETF has faced is the choice of
"mandatory-to-implement" authentication mechanism given that unencrypted
clear-text passwords are no longer permitted (for good reason).

I believe this is a better choice than CRAM-MD5.  The main reason is that
this brings HTTP into the set of protocols which can share the same
mandatory-to-implement mechanism.  There is also an attack against
CRAM-MD5 (the password can be easily recovered if the client is tricked
into connecting to a spoof server) which is a major concern for some
implementors.  It also adds integrity protection. 

This mechanism is crufty due to the desire to keep it backwards compatible
with the HTTP digest draft.  But I think the benefit outweighs the cruft
(and the source code necessary to work around the nastiest cruft is
included).

Please take the time to read this over carefully.  I consider it extremely
important.

If we get a sense of rough concensus for this mechanism, the following
things are likely to happen:
* LDAPv3 will adopt it as mandatory-to-implement
* I will lobby for a recycle of the ACAP spec at proposed standard to
  change from CRAM-MD5 to this mechanism.
* I will lobby for this as mandatory-to-implement in the NNTP AUTH draft.
* Other political stuff moving towards making this an across-the-board
  replacement for unencrypted clear-text.

		- Chris

---------- Forwarded message ----------
Date: Mon, 05 Oct 1998 10:10:50 -0400
From: [email-masked]
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-leach-digest-sasl-00.txt

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

	Title		: Using Digest Authentication as a SASL Mechanism
	Author(s)	: P. Leach, C. Newman
	Filename	: draft-leach-digest-sasl-00.txt
	Pages		: 20
	Date		: 02-Oct-98
	
       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 [RFC2195]
       and as a convenient way to support a single authentication mechanism for
       web, mail, LDAP, and other protocols.

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-leach-digest-sasl-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-leach-digest-sasl-00.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: ftp.ietf.org
	
	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-leach-digest-sasl-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.

---559023410-959030623-907723272=:17962--

Date: Tue, 06 Oct 1998 17:47:41 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: SASL profile for FTP?
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Tue, 6 Oct 1998, Alexey Melnikov wrote:
> Anybody in SASL list can confirm/disprove that currently there is no
> SASL profile for FTP?

There is no such profile.  I'd love it if someone wrote one.

> I found only RFC 2228 (FTP Security Extensions), it looks very similar
> to SASL profile, but it doesn't mention SASL.

When the FTP security stuff was being debated, John Myers proposed a 5
page SASL-based alternative to the 27 page RFC 2228.  Incidentally, the
CAT WG (a security area WG) ignored John's proposal.  I suppose one could
draw some conclusions from this and the subsequent deployment patterns of
RFC 2228.

		- Chris

Date: Tue, 06 Oct 1998 03:06:13 +0400
From: Alexey Melnikov <[email-masked]>
Organization: Epsylon Technologies
To: [email-masked]
Subject: SASL profile for FTP?
Sender: [email-masked]

Hi,

Anybody in SASL list can confirm/disprove that currently there is no
SASL profile for FTP?

I found only RFC 2228 (FTP Security Extensions), it looks very similar
to SASL profile, but it doesn't mention SASL.

Cheers,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team
"ACAP Explorer" client

Epsylon Technologies, Russia
 http://www.demo.ru

Imap Development Kit (my own product)
http://www.demo.ru/homerus/mail/idk/index.htm
------------------------------------------