Subject: GSS-SPNEGO

From: Luke Howard <[email-masked]>
Date: Fri, 29 Nov 2002 14:52:39 +1100

According to draft-ietf-cat-sasl-gssapi-05.txt, all GSSAPI
mechanisms share the same SASL profile.

However, it appears that Microsoft's implementation of 
GSS-SPNEGO does not make the final exchange of the security
layer and optional authorization identity.

Does anyone have any comments on this? We modified Cyrus 
SASL to "conform" to Microsoft's implementation for GSS-SPNEGO
and NTLM, but our Sun ONE Directory Server GSS-API plugin still
behaves according to the draft specification.

-- Luke

--
Luke Howard | PADL Software Pty Ltd | www.padl.com

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 29 Nov 2002 04:31:51 -0700

> layer and optional authorization identity.

This was always part of GSSAPI document, so this means that Microsoft
implementation is non compliant.

> behaves according to the draft specification.

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

---

From: Luke Howard <[email-masked]>
Date: Sat, 30 Nov 2002 17:18:10 +1100

>implementation is non compliant.

Ah. Unfortunately, there's no way for our server to tell whether
it's dealing with a compliant client or not (without a priori
out-of-band knowledge). Oh well.

-- Luke

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 29 Nov 2002 04:31:51 -0700

Regards,
Alexey Melnikov

---

From: Luke Howard <[email-masked]>
Date: Sat, 30 Nov 2002 17:18:10 +1100

-- Luke

From: Luke Howard <[email-masked]>
Organization: PADL Software Pty Ltd
To: [email-masked]
Subject: Re: GSS-SPNEGO
Cc: [email-masked]
Reply-To: [email-masked]
Date: Sat, 30 Nov 2002 17:18:10 +1100
Versions: dmail (bsd44) 2.4c/makemail 2.9d
Sender: [email-masked]

-- Luke

Date: Fri, 29 Nov 2002 04:31:51 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
CC: [email-masked]
Subject: Re: GSS-SPNEGO
Sender: [email-masked]

Regards,
Alexey Melnikov

From: Luke Howard <[email-masked]>
Organization: PADL Software Pty Ltd
To: [email-masked]
Subject: GSS-SPNEGO
Reply-To: [email-masked]
Date: Fri, 29 Nov 2002 14:52:39 +1100
Versions: dmail (bsd44) 2.4c/makemail 2.9d
Sender: [email-masked]

-- Luke

From: "Joshua Gramlich" <[email-masked]>
To: <[email-masked]>
Subject: SASL y Kerberos y GSSAPI
Date: Fri, 22 Nov 2002 14:01:59 -0600
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00EE_01C2922F.B9A10150
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

I am part of a group that has been tasked to add grid-ley security =
mechanisms to an application we maintain at a large research =
organization.  Pardon my vagueness, I will hopefully be able to speak =
more later.  Suffice it to say we have a large pile of data that is =
accessed by many users around the world...on the order of 1000 or so, =
from many disparate locations.

The desire of our community is to maintain current security practices =
(Kerberos 5) but allow outsiders in using the GSSAPI.  Our community's =
security mavens have suggested we user SASL as a go-between the two =
mechanisms.

Unfortunately, I don't even know if I'm even asking the correct =
questions.  I'll try to explain a bit more.

The pieces of our application communicate via corba and http.  We would =
like to secure all of these connections, locally with Kerberos, remotely =
via GSSAPI.  Transmitting passwords, cleartext or through an SSL =
connection is not acceptible to the community.

I've been looking for a good abstract of how SASL works, and how it =
interacts with Kerberos and GSSAPI.

Any ideas any of you can pass along?

Joshua Gramlich
------=_NextPart_000_00EE_01C2922F.B9A10150
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I am part of a group that has been =
tasked to add=20
grid-ley security mechanisms to an application we maintain at a large =
research=20
organization.&nbsp; Pardon my vagueness, I will hopefully be able to =
speak more=20
later.&nbsp; Suffice it to say we have a large pile of data that is =
accessed by=20
many users around the world...on the order of 1000 or so, from many =
disparate=20
locations.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The desire of our community is to =
maintain current=20
security practices (Kerberos 5) but allow outsiders in using the =
GSSAPI.&nbsp;=20
Our community's security mavens have suggested we user SASL as a =
go-between the=20
two mechanisms.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Unfortunately, I don't even know if I'm =
even asking=20
the correct questions.&nbsp; I'll try to explain a bit =
more.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The pieces of our application =
communicate via corba=20
and http.&nbsp; We would like to secure all of these connections, =
locally with=20
Kerberos, remotely via GSSAPI.&nbsp; Transmitting passwords, cleartext =
or=20
through an SSL connection is not acceptible to the =
community.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I've been looking for a good abstract =
of how SASL=20
works, and how it interacts with Kerberos and GSSAPI.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Any ideas any of you can pass =
along?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Joshua =
Gramlich</FONT></DIV></BODY></HTML>

------=_NextPart_000_00EE_01C2922F.B9A10150--

Date: Thu, 21 Nov 2002 17:42:53 -0300 (ART)
Subject: Question
From: <[email-masked]>
To: <[email-masked]>
Importance: High
Sender: [email-masked]

Hello,
Im newbie in sasl and I have the following problem:
Im trying to use Cyrus IMAP with multiple domains so
I have several lmtp sockets listen in the server. Its working
fine but for saslauthd I would need also several "mux" sockets
listening since Im validating user aginst LDAP. But I dont know how to
configure the saslauthd.conf for that
and if I start the daemon with command "-m /path_to_mux/mux" I do an
netstat -an and I see the socket listening where I want, but when Im
trying to login into the cyrus I got the following error in the log:

Nov 21 13:24:21 server01 pop3d[5193]: cannot connect to saslauthd server:
Connection refused

Anyine could help me?
Thanks!
Lucas,

Content-class: urn:content-classes:message
Subject: RE: text about CBC Oracle attack
Date: Tue, 19 Nov 2002 16:38:23 -0800
From: "Paul Leach" <[email-masked]>
To: "Sam Hartman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_009F_01C28FEA.0B821970
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Question: if it's a birthday paradox issue, does that mean that ciphers
with a block size of 128 bits such as AES are immune from a practical
standpoint (say, 2**32 times harder to get a birthday coincidence)?

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Tuesday, November 19, 2002 2:42 PM
To: [email-masked]
Subject: text about CBC Oracle attack

At the meeting today we noted that we need to include some text in the
digest-md5 spec regarding CBC Oracle attacks.

Here's the text from section 11 (security considerations) of
draft-ietf-secsh-transport-14:

   Nearly all ciphers specified in this document are used in cipher
   block chaining (CBC) mode.  It's been known for some time that CBC
   modes will reveal information about the plaintext if two ciphertext
   blocks encrypted under the same key are equal; this is one of the
   reasons this document strongly recommends rekeying at least once per
   gigabyte of data, to reduce the chance that a "birthday paradox"
   collision will appear.

------=_NextPart_000_009F_01C28FEA.0B821970
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_009F_01C28FEA.0B821970--

Date: Tue, 19 Nov 2002 17:41:31 -0500 (EST)
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: text about CBC Oracle attack
Sender: [email-masked]

At the meeting today we noted that we need to include some text in the
digest-md5 spec regarding CBC Oracle attacks.

Here's the text from section 11 (security considerations) of draft-ietf-secsh-transport-14:

   Nearly all ciphers specified in this document are used in cipher
   block chaining (CBC) mode.  It's been known for some time that CBC
   modes will reveal information about the plaintext if two ciphertext
   blocks encrypted under the same key are equal; this is one of the
   reasons this document strongly recommends rekeying at least once per
   gigabyte of data, to reduce the chance that a "birthday paradox"
   collision will appear.

   Recent research has uncovered a new attack on CBC mode which, under
   certain conditions, allows a chosen plaintext attacker aware of the
   IV for a forthcoming message to have some chance to artificially
   induce a system into generating ciphertext collisions, allowing the
   attacker's guesses at likely prior plaintexts to be confirmed.

   Any protocol which uses CBC in a way which allows advance knowledge
   of a message's IV (e.g., by using the last block of the preceding
   message as the IV) might be vulnerable to this attack.

   Preliminary analysis of this attack as applied to the SSH protocol
   suggests that the protocol as implemented today is actually fairly
   resistant to this attack.  While estimates vary, on average, an
   attacker would need tens or hundreds of millions of opportunities to
   inject chosen plaintexts to be encrypted with a known IV to confirm
   guesses on the value of a few unknown plaintexts.

   While this attack involves less work than a brute-force attack on the
   underlying cipher (and is thus a matter of some concern), it is also
   likely to be significantly more difficult than attacks on other parts
   of a system using the SSH protocol, and so is unlikely to be an
   immediate risk to real-world systems.  Due to this document's
   recommendation that rekeying occur once an hour, an attacker also has
   a limited amount of time to complete any particular attack.

   Nevertheless, work is underway to specify, in a separate document or

Ylonen, et. al.        Expires September 18, 2002              [Page 24]

Internet-Draft        SSH Transport Layer Protocol            March 2002

   documents, additional cipher modes for the SSH protocol to address
   this vulnerability.  Implementors should be prepared to add new
   algorithms to their implementations as this work progresses.

Date: Tue, 19 Nov 2002 15:07:56 -0500
To: Alexey Melnikov <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: SASL (informal) meeting in Atlanta
Cc: Tony Hansen <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

I've arranged for a meeting room...  "State" (by the terminal room).

Kurt

At 12:25 PM 2002-11-17, Alexey Melnikov wrote:

>Tony Hansen wrote:
>
>> I vote for 15:45-16:45 slot.
>
>Ok, lets meet near the Notice Board.
>And if we run out of time, we can arrange for additional meetings.
>
>> [skip]
>
>> > Either 15:45-16:45 slot or after 18:00 is fine with me (both on Tuesday).
>> >
>> > Also, I suggest we have two separate meetings: one regarding SASL status
>> > (base document + mechanisms) and a separate for SASL C API discussion
>> > (draft-newman-sasl-c-api-00.txt).
>
>People who are already in Atlanta on Sunday and are interested in
>draft-newman-sasl-c-api-00.txt can join a discussion at 14:00.
>
>Cheers,
>Alexey Melnikov

Date: Mon, 18 Nov 2002 15:58:15 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>
Subject: Re: [Fwd: text conferencing at the 55th IETF meeting in Atlanta]
Sender: [email-masked]

I tried to do a running commentary of the C API discussion today, its at:

http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/sasl/2002-11-18.html

-Rob

On Mon, 18 Nov 2002, Alexey Melnikov wrote:

> [For numerous SASL meetings this week the name of the group is "sasl".]
>
> -------- Original Message --------
> Subject: text conferencing at the 55th IETF meeting in Atlanta
> Date: Tue, 22 Oct 2002 17:02:15 -0700
> From: Marshall Rose <[email-masked]>
> Organization: Dover Beach Consulting, Inc.
> To: [email-masked], [email-masked], [email-masked]
>
> hi. attached you will find a file describing how to do text conferencing
> at the 55th IETF meeting in Atlanta.
>
> comments welcome.
>
> i suggest that this email get sent to the ietf-announce mailing list
> after the agenda is finalized.
>
> Enjoy,
>
> /mtr

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Mon, 18 Nov 2002 13:53:31 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: [Fwd: text conferencing at the 55th IETF meeting in Atlanta]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------DB9665E743FE34BF4876927F
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit

[For numerous SASL meetings this week the name of the group is "sasl".]

-------- Original Message --------
Subject: text conferencing at the 55th IETF meeting in Atlanta
Date: Tue, 22 Oct 2002 17:02:15 -0700
From: Marshall Rose <[email-masked]>
Organization: Dover Beach Consulting, Inc.
To: [email-masked], [email-masked], [email-masked]

hi. attached you will find a file describing how to do text conferencing
at the 55th IETF meeting in Atlanta.
    
comments welcome.
    
i suggest that this email get sent to the ietf-announce mailing list
after the agenda is finalized.
    
Enjoy,
    
/mtr
--------------DB9665E743FE34BF4876927F
Content-Type: text/plain; charset=koi8-r;
 name="text-conferencing.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="text-conferencing.txt"

	     Remote Access for the 55th IETF meeting in Atlanta:
			     Text Conferencing

At each IETF meeting, two of the working group meeting rooms are equipped
for video multicast and remote participation.  That is, for every IETF
meeting slot, two of the working groups can see and hear the
meeting. For the 55th IETF, in *addition* to the usual network A/V, text
conferencing will be provided for every working group that meets.

All of the conference rooms will be hosted on

    conference.ietf.jabber.com

and each is named using the official IETF abbreviation found in the
agenda (e.g., "apparea",  "dhc", "forces", and so on -- for all the
examples that follow, we'll use "foobar" as the abbreviation).

Each conference room also has a 'bot which records everything that gets
sent. So, the minute taker can review this information right after the
meeting.

1. Before the meeting:

1.1. If you want to participate
    
If you don't already have one, get yourself a Jabber client, here are some
suggestions:

    platform	suggestion
    --------	----------
    win32	http://exodus.jabberstudio.org
    'nix	http://gabber.sf.net
    macos	http://jabberfox.sf.net

When you start the client for the first time, it will eventually ask if
you want to register on a public server. Go ahead and do
that. 
    
If you want to find out more, instead of choosing these defaults, here
are pointers to some additional information:
    
    list of clients:    http://www.jabber.org/user/clientlist.php
              howto:    http://www.jabber.org/user/userguide/
        server list:    http://www.jabber.org/user/publicservers.php

To make sure everything is running ok, do a "Join Group Chat" with your
Jabber client:
    
    Group/Room: testing
    Server:     conference.ietf.jabber.com

This conference room is up and running right now (although probably no
one will be in it when you connect).
    
1.2. What the Chair does
    
If you want to make text conferencing available, you'll need to have a
volunteer scribe in the meeting room. The scribe will be typing in a
running commentary as to what's going on in the room (who's presenting,
what question is being asked, etc.)
    
So, why not send an email out on the mailing list now, before the
meeting, to ask for volunteers?

2. At the meeting

2.1. What the Chair does

When a session starts, the chair asks if someone in the room is willing
to act as "scribe". If no one volunteers, read no further, we're done!

Otherwise, the scribe should do a "Join Group Chat" with their Jabber
client, e.g.,

    Group/Room: foobar
    Server:     conference.ietf.jabber.com

2.2. What the Scribe does

The scribe types in a running commentary as to what's going on in the
room. For example, if a speaker makes a presentation, the scribe types
in the URL for the presentation (more on this in a bit).

Simlarly, during question time, a remote participant can type a question
into the room and the scribe can pass it on to the speaker.

2.3. What each Presenter does

Each presenter should put a copy of their presentation on a web server
somewhere, so remote participants can follow along. 
    
If you don't have a server available, email your presentation to
    
    To: [email-masked]
    Subject: foobar
    
and the Secretariat will put the presentation in a server so it can be
accessed under:
    
    http://atlanta.ietf.org/presentations/foobar/
    
Don't wait until the last minute to send the email.

2.4. Where to find the conference log
    
    http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/
    
(Note: these URLs won't be active until just before the meeting starts!)

2.5. Finally
    
This is an experiment. Let's see how well it works and discuss it after
the meeting.
    
				  #######

--------------DB9665E743FE34BF4876927F--

Date: Mon, 18 Nov 2002 15:26:19 -0500
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Proposed Charter for the SASL WG
Sender: [email-masked]

It appears that the IESG is ready to consider our previous
request for a WG.  Below is an updated proposed WG charter
for your review and comment.  This will be discussed tomorrow
at the SASL Bar BOF during 15:45 (meet at message board).

Kurt & Alexey

Simple Authentication and Security Layer (SASL)

Chair(s):
  Kurt Zeilenga <[email-masked]>
  Alexey Melnikov <[email-masked]>

Security Area Advisor: <[email-masked]>
Applications Area Advisor: <[email-masked]>

Mailing Lists:
  General Discussions: <[email-masked]>
  To Subscribe: <[email-masked]>
  In Body: subscribe
  Archive: http://www.imc.org/ietf-sasl/mail-archive/

Description of Working Group

  The Simple Authentication and Security Layer [RFC2222] provides
  key security services to a number of application protocols
  including BEEP, IMAP, LDAP, POP, and SMTP.  The purpose of
  this working group is to shepherd SASL, including select SASL
  mechanisms, through the Internet Standards process.

  This group will deliver a revised SASL Technical Specification
  suitable for consideration as a Draft Standard.  This work
  will be based upon RFC 2222 and draft-myers-saslrev.

  This group will deliver revised Technical Specifications
  suitable for consideration as Draft Standards for the following
  SASL mechanisms: ANONYMOUS, PLAIN, CRAM-MD5, DIGEST-MD5, and
  EXTERNAL.  This work will be based upon RFC 2195, RFC 2222, RFC
  2831, draft-zeilenga-sasl-anon, draft-zeilenga-sasl-plain,
  draft-nerenberg-sasl-crammd5 and draft-melnikov-rfc2831bis,
  and draft-myers-saslrev-xx.txt.

  This group will deliver a revised Technical Specification
  suitable for publication as Proposed Standard for the GSSAPI
  family of SASL mechanisms.  This work will be based upon
  RFC 2222 and draft-ietf-cat-sasl-gssapi.

  This group will deliver a Technical Specification
  suitable for publication as Proposed Standard describing
  a family of SASL mechanisms using the Secure Remote
  Password [RFC2945] protocol.  This work will be based
  upon draft-burdis-cat-srp-sasl.

  The following areas are not within the scope of work of this WG:
    - new features,
    - SASL Mechanisms not specifically mentioned above, and
    - SASL "profiles".

  However, the SASL WG is an acceptable forum for review of
  SASL-related submissions produced by others as long as such
  review does not impede progress on the WG objectives listed
  above.

Goals and Milestones
  Dec 02  Submit revised SASL (+ EXTERNAL) I-D
  Dec 02  Submit revised SASL ANONYMOUS I-D
  Dec 02  Submit revised SASL PLAIN I-D
  Dec 02  Submit revised SASL CRAM-MD5 I-D
  Dec 02  Submit revised SASL DIGEST-MD5 I-D
  Dec 02  Submit revised SASL GSSAPI I-D
  Dec 02  Submit SASL SRP I-D
  Jun 03  Submit Implementation Report
  Jul 03  Submit revised SASL, CRAM-MD5, DIGEST-MD5 I-Ds with
          Implementation Report to IESG for consideration as
          a Draft Standard
  Jul 03  Submit revised SASL GSSAPI I-D to IESG for consideration
          as a Proposed Standard
  Jul 03  Submit SASL SRP I-D to IESG for consideration as a
          Proposed Standard
  Aug 03  Revise charter or conclude     

Date: Sun, 17 Nov 2002 15:27:52 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: SASL C API meeting in Atlanta
Sender: [email-masked]

For people interested in SASL C API, we will meet at 1pm on Monday near
the Message Board.

Regards,
Alexey

Date: Sun, 17 Nov 2002 10:25:20 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Tony Hansen <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: SASL (informal) meeting in Atlanta
Sender: [email-masked]

Tony Hansen wrote:

> I vote for 15:45-16:45 slot.

Ok, lets meet near the Notice Board.
And if we run out of time, we can arrange for additional meetings.

> [skip]

> > Either 15:45-16:45 slot or after 18:00 is fine with me (both on Tuesday).
> >
> > Also, I suggest we have two separate meetings: one regarding SASL status
> > (base document + mechanisms) and a separate for SASL C API discussion
> > (draft-newman-sasl-c-api-00.txt).

People who are already in Atlanta on Sunday and are interested in
draft-newman-sasl-c-api-00.txt can join a discussion at 14:00.

Cheers,
Alexey Melnikov

Date: Sat, 16 Nov 2002 22:53:02 -0500
From: Tony Hansen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: SASL (informal) meeting in Atlanta
Sender: [email-masked]

I vote for 15:45-16:45 slot.

	Tony Hansen
	[email-masked]

Alexey Melnikov wrote:

> Rob Siemborski wrote:
>
>
> >On Mon, 14 Oct 2002, Alexey Melnikov wrote:
> >
> >
> >>I currently see no interest in official BOF (correct me if I am wrong).
> >>So I suggest we hold an informal meeting to progress various documents
> >>(SASL spec, CRAM-MD5, DIGEST-MD5, GSSAPI, SRP, SM2, etc). Currently
> >>there is an almost empty slot on Tuesday, November 19 from 14:15 till
> >>15:15.
> >
> >Did we ever decide on a time for this?  A dinner discussion on Tuesday
> >sounds fine.
>
>
> Either 15:45-16:45 slot or after 18:00 is fine with me (both on Tuesday).
>
> Also, I suggest we have two separate meetings: one regarding SASL status
> (base document + mechanisms) and a separate for SASL C API discussion
> (draft-newman-sasl-c-api-00.txt).
>
> Regards,
> Alexey Melnikov

Date: Sun, 17 Nov 2002 00:50:25 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>
Subject: Re: SASL (informal) meeting in Atlanta
Sender: [email-masked]

On Sat, 16 Nov 2002, Alexey Melnikov wrote:

> Either 15:45-16:45 slot or after 18:00 is fine with me (both on Tuesday).

These work for me as well.

> Also, I suggest we have two separate meetings: one regarding SASL status
> (base document + mechanisms) and a separate for SASL C API discussion
> (draft-newman-sasl-c-api-00.txt).

Agreed.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

Date: Sat, 16 Nov 2002 21:13:05 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Rob Siemborski <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: SASL (informal) meeting in Atlanta
Sender: [email-masked]

Alexey Melnikov wrote:

> > Did we ever decide on a time for this?  A dinner discussion on Tuesday
> > sounds fine.
>
> Either 15:45-16:45 slot or after 18:00 is fine with me (both on Tuesday).
>
> Also, I suggest we have two separate meetings: one regarding SASL status
> (base document + mechanisms)

We have to decide who is going to edit the base spec and GSSAPI.
If I remember correctly John agreed to pass this on to somebody who has more
time.

> and a separate for SASL C API discussion
> (draft-newman-sasl-c-api-00.txt).

Alexey Melnikov

Date: Sat, 16 Nov 2002 20:27:16 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Rob Siemborski <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: SASL (informal) meeting in Atlanta
Sender: [email-masked]

Rob Siemborski wrote:

> On Mon, 14 Oct 2002, Alexey Melnikov wrote:
>
> > I currently see no interest in official BOF (correct me if I am wrong).
> > So I suggest we hold an informal meeting to progress various documents
> > (SASL spec, CRAM-MD5, DIGEST-MD5, GSSAPI, SRP, SM2, etc). Currently
> > there is an almost empty slot on Tuesday, November 19 from 14:15 till
> > 15:15.
>
> Did we ever decide on a time for this?  A dinner discussion on Tuesday
> sounds fine.

Either 15:45-16:45 slot or after 18:00 is fine with me (both on Tuesday).

Also, I suggest we have two separate meetings: one regarding SASL status
(base document + mechanisms) and a separate for SASL C API discussion
(draft-newman-sasl-c-api-00.txt).

Regards,
Alexey Melnikov

Date: Sat, 16 Nov 2002 15:50:22 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>
Subject: Re: SASL (informal) meeting in Atlanta
Sender: [email-masked]

On Mon, 14 Oct 2002, Alexey Melnikov wrote:

> I currently see no interest in official BOF (correct me if I am wrong).
> So I suggest we hold an informal meeting to progress various documents
> (SASL spec, CRAM-MD5, DIGEST-MD5, GSSAPI, SRP, SM2, etc). Currently
> there is an almost empty slot on Tuesday, November 19 from 14:15 till
> 15:15.

Did we ever decide on a time for this?  A dinner discussion on Tuesday
sounds fine.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nerenberg-sasl-crammd5-03.txt
Date: Thu, 07 Nov 2002 06:24:14 -0500
Sender: [email-masked]

--NextPart

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

	Title		: The CRAM-MD5 SASL Mechanism
	Author(s)	: L. Nerenberg
	Filename	: draft-nerenberg-sasl-crammd5-03.txt
	Pages		: 7
	Date		: 2002-11-6
	
This document defines a simple challenge-response [SASL] authenti-
cation mechanism, using a [KEYED-MD5] digest.

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-zeilenga-sasl-plain-01.txt
Date: Thu, 07 Nov 2002 06:23:38 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Plain SASL Mechanism
	Author(s)	: K. Zeilenga
	Filename	: draft-zeilenga-sasl-plain-01.txt
	Pages		: 7
	Date		: 2002-11-6
	
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-zeilenga-sasl-plain-01.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-zeilenga-sasl-plain-01.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-zeilenga-sasl-plain-01.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-nerenberg-imap-binary-07.txt
Date: Thu, 07 Nov 2002 06:22:37 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 Binary Content Extension
	Author(s)	: L. Nerenberg
	Filename	: draft-nerenberg-imap-binary-07.txt
	Pages		: 7
	Date		: 2002-11-6
	
This memo defines the BINARY extension to the Internet Message
Access Protocol [IMAP4rev1].  It provides a mechanism for IMAP4
clients and servers to exchange message body data without using a
MIME content-transfer-encoding.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nerenberg-imap-binary-07.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-nerenberg-imap-binary-07.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-nerenberg-imap-binary-07.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-nerenberg-imap-binary-07.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-zeilenga-sasl-anon-01.txt
Date: Thu, 07 Nov 2002 06:21:29 -0500
Sender: [email-masked]

--NextPart

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

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

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-zeilenga-sasl-anon-01.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-zeilenga-sasl-anon-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 04 Nov 2002 09:24:05 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
CC: [email-masked]
Subject: Re: How can I receive letters without authentication
Sender: [email-masked]

[email-masked] wrote:
> 
> hi,I have install sasl and sendmail successfully,and I can
> use the anthentication function when I send mail,but now
> when I receive mail,it also require authentication,so I can
> receive any letter from outside.How do I configure so that only when I send a letter using my SMTP server requere authentication but when I recieve a letter from other SMTP
> server don't require authentication.
> my sasl version is cyrus-sasl-1.5.28,sendmail version is Sendmail-8.12.3
> who can help me?thanks very much.

This is a Sendmail specific question and should be asked on
comp.mail.sendmail

However, your basic problem is that you shouldn't be requiring AUTH or
STARTTLS on the public SMTP port (25).  IMO, if you want authentication
for submission, you should be using the submission port (587) for your
clients.

Ken
-- 
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: [email-masked]
Date: Mon, 4 Nov 2002 17:26:59 +0800 (HKT)
To: [email-masked]
Subject: How can I receive letters without authentication  
Sender: [email-masked]

hi,I have install sasl and sendmail successfully,and I can 
use the anthentication function when I send mail,but now 
when I receive mail,it also require authentication,so I can
receive any letter from outside.How do I configure so that only when I send a letter using my SMTP server requere authentication but when I recieve a letter from other SMTP
server don't require authentication.
my sasl version is cyrus-sasl-1.5.28,sendmail version is Sendmail-8.12.3
who can help me?thanks very much.