Subject: cyrus libsasl 1.4.1

From: Rob Earhart <[email-masked]>
Date: Tue, 30 Mar 1999 22:57:14 -0500 (EST)

Hey, I just wanted to mention that we've released another version of our
SASL library, implementing something like what we think the final C API
might look like; source code for the library, sample code using the
library, & plugins for the cram-md5, plain, anonymous, kerberos_v4,
digest-md5, and gssapi mechanisms are available at
<ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/>.

  The digest-md5 code is still a little unstable, and the gssapi code
hasn't been tested lately (I'm not sure it still works), but the others
are pretty happy.

  We're also kicking this release out as RPMs (available in the same
place), as a convenience for people who want to just install it and use it
on Redhat 5.2 systems without actually building the software.

  The old Java SASL implementation is missing; it looks like it'll be
changing quite a bit in the near future.  We're working with Sun and
Netscape on some ideas; it's going well, and we're hoping to get another
implementation of it out in a future release.

  As usual, questions/comments can be sent to myself, Tim Martin
<[email-masked]>, or the Cyrus SASL project list at
<[email-masked]>. 

  )Rob

Date: Tue, 30 Mar 1999 22:57:14 -0500 (EST)
From: Rob Earhart <[email-masked]>
To: [email-masked]
Subject: cyrus libsasl 1.4.1
Sender: [email-masked]

  Hey, I just wanted to mention that we've released another version of our
SASL library, implementing something like what we think the final C API
might look like; source code for the library, sample code using the
library, & plugins for the cram-md5, plain, anonymous, kerberos_v4,
digest-md5, and gssapi mechanisms are available at
<ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/>.

  The digest-md5 code is still a little unstable, and the gssapi code
hasn't been tested lately (I'm not sure it still works), but the others
are pretty happy.

  We're also kicking this release out as RPMs (available in the same
place), as a convenience for people who want to just install it and use it
on Redhat 5.2 systems without actually building the software.

  The old Java SASL implementation is missing; it looks like it'll be
changing quite a bit in the near future.  We're working with Sun and
Netscape on some ideas; it's going well, and we're hoping to get another
implementation of it out in a future release.

  As usual, questions/comments can be sent to myself, Tim Martin
<[email-masked]>, or the Cyrus SASL project list at
<[email-masked]>. 

  )Rob

To: IETF-Announce: ;
Cc: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-cat-sasl-gssapi-00.txt
Date: Thu, 25 Mar 1999 17:11:53 -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 Common Authentication Technology 
Working Group of the IETF.

	Title		: SASL GSSAPI mechanisms
	Author(s)	: J. Myers
	Filename	: draft-ietf-cat-sasl-gssapi-00.txt
	Pages		: 7
	Date		: 24-Mar-99
	
   The Simple Authentication and Security Layer [SASL] is a method for
   adding authentication support to connection-based protocols.  This
   document describes the method for using the Generic Security Service
   Application Program Interface [GSSAPI] in the Simple Authentication
   and Security Layer [SASL].
 
   This document amends section 7.2 of RFC 2222 [SASL], the definition
   of the 'GSSAPI' SASL mechanism.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-cat-sasl-gssapi-00.txt

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

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

--OtherAccess--

--NextPart--

Date: Sun, 14 Mar 1999 11:44:59 -0800
From: [email-masked] (Rob Weltman)
Organization: Netscape Communications Corp.
To: [email-masked]
Subject: Discuss Java SASL API in Minneapolis
Sender: [email-masked]

  If you're in Minneapolis for the IETF meeting next week, consider joining Rob Earhart, Tim Martin, and myself to discuss unifying the different Java SASL API's that have been proposed (the Cyrus one and the one I proposed in an Internet Draft).

  We'll meet at the registration desk on Wednesday at 1:00.

Thanks,
Rob

Date: Tue, 09 Mar 1999 18:02:27 -0700
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: DIGEST-MD5 interop testing and comments
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi folks,
> At last weeks MailConnect 6 event hosted by the IMC in San Jose, we did
> some DIGEST-MD5 interop testing with some client and server
> implementations. Some question wrt to the current draft arose from this
> and I'll list those below.
>
> If anyone else is interested in interop testing of DIGEST-MD5 please
> post to this list so that we can all do this. We (Cyrusoft
> International) have a DIGEST-MD5 plugin for Mulberry (IMAP email
> client) available now and want to test with whatever server
> implementations are currently available.
>
> Comments:
>
> 1) Section 2.1.2.1
> The definition for A2 includes the 'digest-uri-value'. Does this have
> to be present or can it be NULL?

It seems that it might be NULL

> I'm assuming that if the client does
> not send a 'digest-uri' as part of the digest-response (Section 2.1.2)
> then the value in A2 should be NULL.

It might be not NULL, but "AUTHENTICATE:".

> This needs more explanation.

This have to be explicitly defined, because at least two persons (Cyrus
and I) understand it differently.

> 2) Section 2.1.3
> The purpose of Step 3 seems to be missing. Why is it present?
> Presumably so that the client can validate the server response.

Exactly.

> It should be stated explicitly that the client should abort the
> authentication if the wrong values are returned, i.e. the client must
> calculate and compare the response-auth sent by the server.

I agree.

> 3) Section 4: Example
> The example does not include Step 3 or does it? Its also not clear to
> me what happens after Step 3 - does the server immediately respond with
> a tagged OK response or does it wait for something from the client,
> since the client may reject step three? If the example does include
> Step 3 then it would be the line immediately preceeding the a OK line,
> in which case the example is not at all clear. Perhaps using the 'C:'
> and 'S:' prefixes for each response would make things clearer.

Example is broken.
As I understand:

Step 3: Server sends "rspauth=...". Clients verifies it. If it is
successful, it sends to server zero-length response. Then server sends
back success indication flag (this is true for SMTP, POP3, IMAP4 because
they don't have the ability to send additional data with success
indicator)

> --Cyrus Daboo

For all interested parties I propose to arrange "DIGEST dinner" during
IETF 44. Any propositions about date? (I'll be in Minneapolis from Sunday
up to Wednesday)

--
Regards,
Alexey Melnikov

Date: Mon, 08 Mar 1999 11:01:19 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: DIGEST-MD5 interop testing and comments
Originator-Info: login-id=daboo; server=imap.cyrusoft.com
Sender: [email-masked]

Hi folks,
At last weeks MailConnect 6 event hosted by the IMC in San Jose, we did
some DIGEST-MD5 interop testing with some client and server
implementations. Some question wrt to the current draft arose from this
and I'll list those below.

If anyone else is interested in interop testing of DIGEST-MD5 please
post to this list so that we can all do this. We (Cyrusoft
International) have a DIGEST-MD5 plugin for Mulberry (IMAP email
client) available now and want to test with whatever server
implementations are currently available.

Comments:

1) Section 2.1.2.1
The definition for A2 includes the 'digest-uri-value'. Does this have
to be present or can it be NULL? I'm assuming that if the client does
not send a 'digest-uri' as part of the digest-response (Section 2.1.2)
then the value in A2 should be NULL. This needs more explanation.

2) Section 2.1.3
The purpose of Step 3 seems to be missing. Why is it present?
Presumably so that the client can validate the server response. It
should be stated explicitly that the client should abort the
authentication if the wrong values are returned, i.e. the client must
calculate and compare the response-auth sent by the server.

3) Section 4: Example
The example does not include Step 3 or does it? Its also not clear to
me what happens after Step 3 - does the server immediately respond with
a tagged OK response or does it wait for something from the client,
since the client may reject step three? If the example does include
Step 3 then it would be the line immediately preceeding the a OK line,
in which case the example is not at all clear. Perhaps using the 'C:'
and 'S:' prefixes for each response would make things clearer.

--Cyrus Daboo

Date: Fri, 05 Mar 1999 21:28:53 -0700
From: Alexey Melnikov <[email-masked]>
To: Paul Leach <[email-masked]>
CC: "'RL Bob Morgan'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: comments on draft-leach-digest-sasl-01.txt
Sender: [email-masked]

Paul Leach wrote:

> Unfortunately, your comments arrived on the Monday that updates to I-Ds were
> due, and I was at a conference from Monday to Thursday. I incorporated as
> many of your comments and those of others as I could into an update that I
> submitted to the I-D editor, but since it was with just 5 minutes to spare
> before the deadline, I wasn't sure that the mail would get there in time.
> However, it did, and draft-leach-digest-sasl-02.txt is now available in the
> I-D directories.

Paul, please, send to the list the final version that you have.
I am compiling the list of bugs/unresolved questions that I would like to ask
you during IETF. I would rather not to ask again about already fixed problems.

--
Regards,
Alexey Melnikov

From: Paul Leach <[email-masked]>
To: "'RL Bob Morgan'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: comments on draft-leach-digest-sasl-01.txt
Date: Fri, 5 Mar 1999 19:23:21 -0800 
Sender: [email-masked]

Unfortunately, your comments arrived on the Monday that updates to I-Ds were
due, and I was at a conference from Monday to Thursday. I incorporated as
many of your comments and those of others as I could into an update that I
submitted to the I-D editor, but since it was with just 5 minutes to spare
before the deadline, I wasn't sure that the mail would get there in time.
However, it did, and draft-leach-digest-sasl-02.txt is now available in the
I-D directories.

> -----Original Message-----
> From: RL Bob Morgan [mailto:[email-masked]]
> Sent: Monday, February 22, 1999 12:18 AM
> To: [email-masked]
> Cc: Paul Leach; [email-masked]; [email-masked]
> Subject: comments on draft-leach-digest-sasl-01.txt
> 
> 
> 
> I apologize for submitting these comments long after the 
> closing date in
> the Last Call announcement on this document.  I hope that 
> there is still
> an opportunity to consider the issues I raise here, since in 
> my opinion
> this specification in its current state is not ready for 
> Proposed Standard
> status.  The digest security mechanism is intended to have wide use in
> many application protocols, so it's important to get it right.
> 
> Thanks,
> 
>  - RL "Bob" Morgan
>    Stanford
>

Date: Tue, 02 Mar 1999 22:44:48 -0800
From: [email-masked] (Rob Weltman)
Organization: Netscape Communications Corp.
To: Rob Earhart <[email-masked]>
CC: [email-masked]
Subject: Re: cyrus-sasl-1.3b1
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------4148810D01BE4837B299EBC6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

  I'm attaching a zip file with javadocs, and also a sample driver file. I was meaning to write some code to figure out what an LDAP implementation and an IMAP implementation would look like using the cyrus API, to make it easier to compare, but haven't had time.

Rob

Rob Earhart wrote:

> On Sun, 28 Feb 1999, Rob Weltman wrote:
> >   I've worked up a revised proposal with SUN, mostly changing the
> > factory interface to be more like the URL one. It looks like I'll have
> > to be at the IETF meeting at least on Wednesday (March 17), the LDAP
> > day. Will you guys be around then? Or maybe Thursday? This might be a
> > good opportunity to make some progress on unifying the proposals.
>
>   Sounds great.  I'm not entirely sure yet what my schedule will look
> like, but I'll be around both days.
>
>   )Rob

--------------4148810D01BE4837B299EBC6
Content-Type: application/x-zip-compressed;
 name="docs.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="docs.zip"

--------------4148810D01BE4837B299EBC6--

Date: Mon, 1 Mar 1999 07:41:23 -0500 (EST)
From: Rob Earhart <[email-masked]>
To: Rob Weltman <[email-masked]>
cc: [email-masked]
Subject: Re: cyrus-sasl-1.3b1
Sender: [email-masked]

On Sun, 28 Feb 1999, Rob Weltman wrote:
>   I've worked up a revised proposal with SUN, mostly changing the
> factory interface to be more like the URL one. It looks like I'll have
> to be at the IETF meeting at least on Wednesday (March 17), the LDAP
> day. Will you guys be around then? Or maybe Thursday? This might be a
> good opportunity to make some progress on unifying the proposals. 

  Sounds great.  I'm not entirely sure yet what my schedule will look
like, but I'll be around both days.

  )Rob