Subject: cyrus-sasl-1.3b1

From: Rob Earhart <[email-masked]>
Date: Tue, 19 Jan 1999 11:38:22 -0500 (EST)

We're pleased to announce the 1.3b1 release of the Cyrus SASL
implementation available as
<ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/cyrus-sasl-1.3b1.tar.gz>. 

  This is a freely available library implementing something close to what
the final standard C SASL API should look like, a Java SASL API (which
still needs to be reconciled against Rob Weltman's proposed Java SASL API; 
maybe we should just open up that discussion on the list?), and includes
plugins for the Kerberos V4, GSSAPI, ANONYMOUS, PLAIN, CRAM-MD5, and
SCRAM-MD5 SASL mechanisms. 

  This hasn't been rigorously tested (which is why it still has the beta
tag), but we've been using it in a number of applications and gotten a few
contributions from outside sources; it seems to be holding up well, and it
definitely seems useful for people doing SASL development. 

  )Rob

Date: Tue, 19 Jan 1999 11:38:22 -0500 (EST)
From: Rob Earhart <[email-masked]>
To: [email-masked]
Subject: cyrus-sasl-1.3b1
Sender: [email-masked]

  We're pleased to announce the 1.3b1 release of the Cyrus SASL
implementation available as
<ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/cyrus-sasl-1.3b1.tar.gz>. 

  This is a freely available library implementing something close to what
the final standard C SASL API should look like, a Java SASL API (which
still needs to be reconciled against Rob Weltman's proposed Java SASL API; 
maybe we should just open up that discussion on the list?), and includes
plugins for the Kerberos V4, GSSAPI, ANONYMOUS, PLAIN, CRAM-MD5, and
SCRAM-MD5 SASL mechanisms. 

  This hasn't been rigorously tested (which is why it still has the beta
tag), but we've been using it in a number of applications and gotten a few
contributions from outside sources; it seems to be holding up well, and it
definitely seems useful for people doing SASL development. 

  )Rob

Date: Sun, 17 Jan 1999 03:05:46 +0300
From: Alexey Melnikov <[email-masked]>
Organization: Epsylon Technologies
To: Paul Leach <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-leach-digest-sasl-01.txt
Sender: [email-masked]

After playing with DIGEST client and server implementations I have few
questions:

IMAP4 example given in the document doesn't include "Step Three". This step is
optional, isn't it? I would like to make this clear in the spec.

Paul Leach wrote:

> > qop
> >   Indicates what "quality of protection" the client accepted. If
> >   present, its value MUST be one of the alternatives the server
> >   indicated it supports in digest-challenge. If not present, it
> >   defaults to "auth". These values affect the computation of the
> >   response. Note that this is a single token, not a quoted list of
> >   alternatives.
> > *
> > * It's unclear whether this option is required to be present
> > or not, because
> > * it's unclear whether qop-options is required in the challenge.
> > * Needs to be resolved.
> > *

So client may omit qop and in this case it is defaulted to "auth" in all
calculations, am I right?

>
> > digest-uri
> >   Indicates the principal name of the service with which the client
> >   wishes to connect, formed from the serv-type, host, and serv-name.
> >   For example, the FTP service on "ftp.xyz.com" would have a "digest-
> >   uri" value of "ftp/ftp.xyz.com"; the SMTP server from the example
> >   above would have a "digest-uri" value of
> > "smtp/mail3.xyz.com/xyz.com"
> > *
> > * what does it mean if the client omits this option?
> > *
>
> I'll have to think about it.

So, what do you think Paul?

I believe that digest-uri is required. If not present, authentication should
fail. (My opinion conflicts with example)

Another one question : should a server verify digest-uri?

--
Best Regards,
Alexey Melnikov
+----------------------------------------------------+
|SMTP/POP3/IMAP4/ACAP  | Epsylon Technologies, Russia|
|servers creation team |     http://www.taxxi.com    |
|----------------------------------------------------|
|Imap Development Kit (my own product)               |
|http://194.87.43.111/homerus/mail/idk/index.htm     |
|----------------------------------------------------|
|Fax (in San Diego, California): 1 (619) 8393837     |
+----------------------------------------------------+

Date: Fri, 15 Jan 1999 08:44:14 -0800 (PST)
From: List Manager of ietf-sasl <[email-masked]>
To: [email-masked]
Subject: How to be removed from this list
Sender: [email-masked]

Greetings again. Occasionally, people will sign up for a mailing list and
forget how to be removed. This message is a reminder for those folks.

First off, when you subscribe to a mailing list, you almost always get a
first message from the list owner telling you about the mailing list, and
explaining how to unsubscribe. It is always a good idea to keep those
messages, since you never know when you will need to unsubscribe. This is
particularly useful when you change email addresses, because it is difficult
to unsubscribe from a list after you have a different mailing address.

In the case of this list, the method to unsubscribe is to send a message
to:
     [email-masked]
with the single word:
     unsubscribe
in the body of the message. This is the same as it always has been.

To make this easier for you, I have crafted this message so that you should
be able to simply reply to this message, and the reply address should be
[email-masked] (although some mail clients screw this up...).
Remove everything from the body of the reply, and put in the single word:
     unsubscribe

If you have tried this method, and the mailing list software won't let you
unsubscribe, it is probably because your address has changed. In that case,
please send a message to [email-masked] stating which list (or lists) you
want to unsubscribe from, and what you think your previous address was.
There is a human (that's me!) who will then try to take care of your
request, often within a few days.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 15 Jan 1999 17:33:10 +0100 (MET)
From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-nystrom-securid-sasl-00.txt (fwd)
Sender: [email-masked]

FYI. Comments and feedback is welcome and solicited.

/Magnus
------------------------------------------------------------
Magnus Nyström            Email: [email-masked]
RSA Laboratories          Phone: (781) 687-7000

---------- Forwarded message ----------
Date: Thu, 14 Jan 1999 15:54:58 GMT
From: [email-masked]
Newsgroups: local.ietf-announce-list
Subject: I-D ACTION:draft-nystrom-securid-sasl-00.txt

--NextPart

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

	Title		: The SecurID(r) SASL Mechanism
	Author(s)	: M. Nystrom, J. Brainard
	Filename	: draft-nystrom-securid-sasl-00.txt
	Pages		: 10
	Date		: 13-Jan-99
	
   This document defines a SASL [SASL] authentication mechanism based on
   Security Dynamics' SecurID authentication protocol, providing client
   authentication. This mechanism is only for authentication, and has no
   effect on the protocol encoding and is not designed to provide
   integrity or confidentiality services.
 
   This memo assumes the reader has basic familiarity with the SecurID
   authentication protocol and SASL.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nystrom-securid-sasl-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-nystrom-securid-sasl-00.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-nystrom-securid-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.

--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-nystrom-securid-sasl-00.txt

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

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

--OtherAccess--

--NextPart--