Subject: SMTP Authentication - is it mandatory if supported?

From: Paul Smith <[email-masked]>
Date: Fri, 31 Aug 2001 20:41:06 +0100

Am I right in thinking that just because a server supports SMTP 
authentication (ESMTP 'AUTH' keyword) it doesn't have to require it?

i.e. our server can be configured so that some IP addresses require 
authentication and others don't, or so that mail to local users doesn't 
require authentication, but mail to remote users does (to allow incoming 
SMTP mail)

However, we've found that once Microsoft Outlook sees that our server 
supports SMTP authentication it insists that the user enters login details, 
without even trying to send a message first. All other email clients we've 
tested are happy to send authentication information if it's supplied or to 
try without if it isn't supplied.

Which is correct?

Paul				VPOP3 - Internet Email Server/Gateway
[email-masked]			http://www.pscs.co.uk/

---

From: "David Lemson" <[email-masked]>
Date: Fri, 31 Aug 2001 19:51:55 -0700

I am still doing some investigation, but I have heard from some people
in Outlook that as far as they know, Outlook never tries outbound SMTP
auth unless it is configured to do so.  You configure it by checking the
box "My server requires authentication" within the accounts property
sheet.  I would suggest checking to make sure that box is not checked,
if you don't want it to prompt for credentials.

David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 31, 2001 5:11 PM
To: Paul Smith
Cc: [email-masked]
Subject: Re: SMTP Authentication - is it mandatory if supported?

> authentication (ESMTP 'AUTH' keyword) it doesn't have to require it?

Yes you are.

> authentication and others don't, or so that mail to local users 
> doesn't require authentication, but mail to remote users does (to 
> allow incoming SMTP mail)

This is a very common configuration.

> supports SMTP authentication it insists that the user enters login 
> details, without even trying to send a message first. All other email 
> clients we've tested are happy to send authentication information if 
> it's supplied or to try without if it isn't supplied.

Well, just because a server views SASL as optional doesn't mean the
client agrees. It is perfectly legitimate to have a client that requires
SMTP authentication.

What makes less sense is to have a client which implements "if SASL is
available its required, if it isn't it is not". This isn't nonstandard,
exactly, but it does lead to suboptimal behavior in quite a few cases.

				Ned

Content-Class: urn:content-classes:message
Subject: RE: SMTP Authentication - is it mandatory if supported?
Date: Fri, 31 Aug 2001 19:51:55 -0700
From: "David Lemson" <[email-masked]>
To: "Paul Smith" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I am still doing some investigation, but I have heard from some people
in Outlook that as far as they know, Outlook never tries outbound SMTP
auth unless it is configured to do so.  You configure it by checking the
box "My server requires authentication" within the accounts property
sheet.  I would suggest checking to make sure that box is not checked,
if you don't want it to prompt for credentials.

David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 31, 2001 5:11 PM
To: Paul Smith
Cc: [email-masked]
Subject: Re: SMTP Authentication - is it mandatory if supported?

> authentication (ESMTP 'AUTH' keyword) it doesn't have to require it?

Yes you are.

> authentication and others don't, or so that mail to local users 
> doesn't require authentication, but mail to remote users does (to 
> allow incoming SMTP mail)

This is a very common configuration.

> supports SMTP authentication it insists that the user enters login 
> details, without even trying to send a message first. All other email 
> clients we've tested are happy to send authentication information if 
> it's supplied or to try without if it isn't supplied.

Well, just because a server views SASL as optional doesn't mean the
client agrees. It is perfectly legitimate to have a client that requires
SMTP authentication.

What makes less sense is to have a client which implements "if SASL is
available its required, if it isn't it is not". This isn't nonstandard,
exactly, but it does lead to suboptimal behavior in quite a few cases.

				Ned

Date: Fri, 31 Aug 2001 17:11:07 -0700 (PDT)
From: [email-masked]
Subject: Re: SMTP Authentication - is it mandatory if supported?
To: Paul Smith <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> authentication (ESMTP 'AUTH' keyword) it doesn't have to require it?

Yes you are.

> require authentication, but mail to remote users does (to allow incoming

This is a very common configuration.

> try without if it isn't supplied.

Well, just because a server views SASL as optional doesn't mean the
client agrees. It is perfectly legitimate to have a client that requires
SMTP authentication.

What makes less sense is to have a client which implements "if SASL is
available its required, if it isn't it is not". This isn't nonstandard,
exactly, but it does lead to suboptimal behavior in quite a few cases.

				Ned

Date: Fri, 31 Aug 2001 20:41:06 +0100
To: [email-masked]
From: Paul Smith <[email-masked]>
Subject: SMTP Authentication - is it mandatory if supported?
Sender: [email-masked]

Which is correct?

Date: Tue, 28 Aug 2001 12:29:13 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
CC: "Kurt D. Zeilenga" <[email-masked]>
Subject: Notes from the SASL BOF
Sender: [email-masked]

I've cleaned up original notes a little bit. Any comments/corrections are
welcome.
==============
  SASL BOF
  August 7 13.00-14.00

  CHAIRS: Kurt Zeilenga <[email-masked]>
    Alexey Melnikov <[email-masked]>

  Notes taken by Roland Hedberg <[email-masked]>

  + Agenda bashing

  No changes where proposed

  + Formation Issues

  Waiting on the IESG for forming a working group, huge queue
  but there doesn't seem to be any unresolved issues with the
  Area Directors.
  Pending review we can keep on working.

  As clarification on the charter it was stated that new
  features of SASL is not within scope, this doesn't mean
  that new features can not be discussed on the mailing
  list it only means that has a lower precedence.

  It was also stated that the C API is not a work item.

  + Technical Issues
    - Base spec issues (Lawrence Greenfield)

  Current version is draft-myers-saslrev-01

   The only mechanism described in this draft is the external.

   Open issues

    Specify authorization identity (AuthID)?

     Currently it is not set. The application has to do this but it is
     further constrained by the mechanism.

     Long discussion on general constraint on AuthIDs. Proposed
     formats where 7-bit ascii without control characters,
     null terminated 8-bit strings, UTF-8 without nulls and control
     characters and unrestricted UTF-8.

     Agreement on that it would be nice to have one common format.
     The plain mechanism has problems with NULLs, CRAM-MD5 has not if
     done carefully.
     LDAP specifies UTF-8 but allows NULLs.

     Should there be a length limit ?

     The question was pushed to the list.

    Max. buffer size

     Plain buffer size or encoded buffer size ?
     The mechanism knows about the overhead of a encoding, hence either
     one can be used.
     The authors is to make a suggestion !

     Implementations also need a way to tell what buffersize is supported.

    Reauthentication

     The only mechanism that supports it is Digest-MD5.
     Should the base spec deal with this ?
     The only thing that could be done in the base spec is to give some guidance,

     otherwise there is a risk of recycling SASL spec to Draft again.

    No generic support for delegation ?

  - DIGEST-MD5 issues (Paul Leach)

   A Mechanism for HTTP originally that was modified to fit SASL framework.

   LDAPinterop has shown some wording problems in the documents, but
   no basic errors in the mechanism as such.

   There is no interoperable DES implementations yet.
   There exists at least three implementation (Microsoft, SUN, ... )
   Microsoft and SUN might have got it working between themselves.
   Happy to drop DES and only use 3DES.

   AES might be added, but not at the cost of slowing down the process
   IESG is not mandating AES yet! Paul agreed to write a separate
   document about using AES for DIGEST-MD5. He is looking for co-authors
   with good knowledge of AES.

   The is a reauth mechanism, SM2 is proposed as another mechanism.
   Microsoft has implementation LDAP client-server
   Messagingdirect does it for IMAP
   Since they have implemented it for different application spaces no
   interoperability testing has been done.
   There where some interest in trying to do some interoperability
   testing before the next meeting.

   Security AD raised issue about RC4 being weak if used without
   a hash function in front. The latter suggests that RC4 is Ok for
   DIGEST-MD5.

   Chris Newman has the editable text
   There is a list of subjects for cleaning up.
   Lawrence Greenfield will present a list of outstanding issues.

  - GSSAPI issues (Lawrence Greenfield)

   The method for using GSSAPI in SASL moved to separate document
    draft-ietf-cat-sasl-gssapi-05.txt

   The SASL mechanism name for the Kerberos V5 GSSAPI mechanism is "GSSAPI"
   and the SASL mechanism for the SPNEGO GSSAPI mechanism is "GSS-SPNEGO".
   The SASL mechanism name for any other GSSAPI mechanism is the concatenation
   of "GSS-" and the Base32 encoding of the first ten bytes of the MD5 hash
   of the ASN.1 DER encoding of the GSSAPI mechanism's OID.

   Suggestions to move base32 description to separate document.

Date: Thu, 09 Aug 2001 06:21:35 -0400
From: Tony Hansen <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Re: SASL C API bar BOF?
Sender: [email-masked]

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

I'm attaching a man page for a C++ server api that I had developed a few
years ago. We might be able to get some ideas from there. Sorry for the
late posting -- the machine this was on was down most of yesterday.

	Tony

Lawrence Greenfield wrote:
> 
> The latest and greatest in Chris Newman/CMU/etc. API is:
> 
> http://bugzilla.andrew.cmu.edu/cvsweb/src/sasl/include/sasl.h?rev=1.43.2.21&content-type=text/x-cvsweb-markup
> 
> I'm going to check with Rob to make sure that he doesn't have any
> pending changes, and then I'll post it in text.
> 
> saslplug.h in the same repository is the plugin api.
> 
> Larry
> 
>    Date: Wed, 08 Aug 2001 07:52:45 -0600
>    From: Alexey Melnikov <[email-masked]>
>    Organization: ACI WorldWide / MessagingDirect
>    CC: Tony Hansen <[email-masked]>, SASL WG <[email-masked]>
> 
>    Leif Johansson wrote:
> 
>    > On Wed, Aug 08, 2001 at 07:11:02AM -0600, Alexey Melnikov wrote:
>    > >
>    > > Actually that what I was thinking myself.
>    > >
>    > > So, we meet on Thursday at 11:30 near IETF message board.
>    >
>    > Could someone forward the latest version of the Chris Newman c-api draft
>    > as a basis for discussion.
> 
>    I suggest we use CMU SASL API as a base for discussion.
--------------F10A0A2EC469F0998F2DBC84
Content-Type: application/x-troff-man;
 name="sasl_server.man"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="sasl_server.man"

Misc. Reference	Manual Pages		       sasl_server(3sasl)

NAME
     sasl_server  -  Simple  Authentication  and  Security  Layer
     server classes

SYNOPSIS
     #include <sasl/sasl_server.h>

     //	SASL server driver
     class sasl_server;

     #include <sasl/sasl_server_plain.h>

     //	SASL  "PLAIN"  mechanism;  draft-newman-tls-imappop-*.txt
     class sasl_server_plain;

     #include <sasl/sasl_server_cram_md5.h>

     //	 SASL  "CRAM-MD5"  mechanism;  RFCs  2095,   2195   class
     sasl_server_cram_md5;

     #include <sasl/sasl_server_external.h>

     //	  SASL	 "EXTERNAL"    mechanism;    RFC    2222    class
     sasl_server_external;

     cc	-lsasl

DESCRIPTION
     The SASL server library is	provided to assist in the writing
     of	 protocol servers that desire to offer Simple Authentica-
     tion and Security Layer (see RFC 2222)  authentication  ser-
     vices.

  General Flow
     The general flow of a server SASL transaction at the  proto-
     col  level	is as follows.	The client sends a SASL	mechanism
     name  and	an  optional  initial  string,	encoded	 in  some
     protocol-dependent	  manner,  to  the  server.   The  server
     decodes the initial string, if there is one, and passes  the
     mechanism name and	initial	string to the SASL server driver.
     The SASL server driver creates a SASL state machine for  the
     chosen  mechanism	and  passes the	intial string to it.  The
     server decodes the	string and passes it to	 the  SASL  state
     machine for processing.  (If the protocol does not	permit an
     initial string to be  passed  at  the  same  time	that  the
     mechanism	is named, an empty string should be passed to the
     SASL state	machine.)

     The SASL state machine may	make callbacks to the server pro-
     cess  to  get  information	 needed	 to  process  the client-
     provided string.  (These callbacks	retrieve information such
     as	passwords, host	names, etc.)  The SASL state machine then

SunOS 5.7		  Last change:				1

Misc. Reference	Manual Pages		       sasl_server(3sasl)

     returns one of three states:

	  LOGIN_OKAY
		    The	passed string contained	 the  information
		    needed  to	authenticate  the user.	 The user
		    name to be used for	 processing,  along  with
		    the	 user  name  used for authenticating, are
		    returned.  An indication of	success	needs  to
		    be returned	to the client.

	  LOGIN_CONTINUE
		    The	passed string was not enough to	authenti-
		    cate  the user and more information	is needed
		    from the client.  A	string	to  send  to  the
		    client program is returned.	 The server needs
		    to encode this string in a protocol-dependent
		    manner  and	 send it to the	client.	 When the
		    server  receives  another  string  from   the
		    client,  it	 needs to pass the next	string to
		    the	SASL server driver.

	  error	codes
		    An error occurred, such as	a  bad	password.
		    An	indication  of	the  error  needs  to  be
		    returned to	the client.
     In	summary, the server loops while	reading	a string from the
     client,  passing it to the	SASL server driver and retrieving
     a string to send back to the client, stopping only	when suc-
     cessful authentication or an error	occurs.

  Specifics
     Step 1:
     The server	must derive a class from each of the SASL mechan-
     isms  that	 it  chooses to	implement.  Currently the choices
     are     sasl_server_plain,	    sasl_server_cram_md5      and
     sasl_server_external.   Each  of these mechanism classes has
     different requirements for	pure virtual functions that  must
     be	 provided.   The  class	 sasl_server_plain  requires  the
     server code to implement a	virtual	function  to  retrieve	a
     password  given  a	 user  name,  and a virtual function that
     indicates whether a given username	is to  be  considered  an
     administrative   user.    The   class   sasl_server_cram_md5
     requires the server code  to  implement  similar  functions,
     plus  a  function to return the host and domain.  The server
     may optionally implement function to return a random set  of
     digits  and  a  timestamp.	  The  class sasl_server_external
     requires the server code to  implement  a	virtual	 function
     that   indicates  whether	credentials  have  been	 provided
     through some external means (such as TLS/SSL or a GEO login)
     and the given username match those	credentials.

SunOS 5.7		  Last change:				2

Misc. Reference	Manual Pages		       sasl_server(3sasl)

     Step 2:
     The server	 instantiates  a  sasl_server  object  (the  SASL
     server driver) and	an object for each of the SASL mechanisms
     that had been derived from	in Step	1.  Each  SASL	mechanism
     is	then registered	with the SASL server driver.

     Step 3: Loop
     The server	receives a mechanism name and possibly an initial
     string  from  the	client in some protocol-dependent manner.
     The intial	string is  passed  to  sasl_server::login().   If
     login() returns LOGIN_CONTINUE, a loop is entered that sends
     the continueString	 (filled  in  by  login())  back  to  the
     client,  retrieves	 another  response  from  the client, and
     invokes sasl_server::continue_login().

     When a return code	of LOGIN_OKAY is received, then	you  know
     that  the	client was able	to successfully	authenticate, and
     the strings retuser and retauthuser will  have  been  filled
     in.

     Any other return code indicates that an error has	occurred,
     and  sasl_server::error_message()	can  be	 used to return	a
     printable version of the error code.

  Class	sasl_server
     class sasl_server : public	sasl_common
     {
     public:
	 sasl_server();
	 ~sasl_server();

	 // Return a string which contains a list of the available SASL
	 // capabilities, separated by the given string.
	 // "show_plaintext_mechanisms"	should be true iff we are on a secure
	 // network in which plaintext passwords are permitted.
	 string	supported_mechanisms(const char	*separator, bool show_plaintext_mechanisms);
	 string	supported_mechanisms(const string &separator, bool show_plaintext_mechanisms);

	 // Return LOGIN_OKAY, LOGIN_CONTINUE or an error condition.
	 login_failures	login(
	  // SASL mechanism to use.
	  const	string &saslName,

	  // are plain text mechanisms permitted?
	  bool usePlaintextMechanisms,

	  // what was the initial string passed	by the client
	  const	string &initialResponse,

	  // the server	challenge upon continue
	  // Filled in upon "LOGIN_CONTINUE"
	  string &continueString,

SunOS 5.7		  Last change:				3

Misc. Reference	Manual Pages		       sasl_server(3sasl)

	  // the username which	was logged in under
	  // Filled in upon "LOGIN_OKAY"
	  string &user,

	  // the authentication	username which was logged in under
	  // Filled in upon "LOGIN_OKAY"
	  string &authuser
	   );

	 // Return LOGIN_OKAY, LOGIN_CONTINUE or an error condition.
	 login_failures	continue_login(
	  // what was the next string passed by	the client?
	  const	string &nextResponse,

	  // the server	challenge upon continue
	  // Filled in upon "LOGIN_CONTINUE"
	  string &continueString,

	  // the username which	was logged in under.
	  // Filled in upon "LOGIN_OKAY"
	  string &user,

	  // the authentication	username which was logged in under
	  // Filled in upon "LOGIN_OKAY"
	  string &authuser
	   );

	 class mechanism;

	 void registerSaslMechanism(sasl_server::mechanism *m);
	 void registerSaslMechanism(sasl_server::mechanism &m);

	 void unregisterSaslMechanism(sasl_server::mechanism *m);
	 void unregisterSaslMechanism(sasl_server::mechanism &m);
     };

     class sasl_common
     {
     public:
	 enum login_failures {	   // keep this	list in	sync with messages[] in	sasl_common.C
	  LOGIN_OKAY = 0,
	  LOGIN_CONTINUE,
	  NO_PLAIN_TEXT,
	  NO_MEMORY,
	  UNKNOWN_METHOD,
	  PROTOCOL_BAD_STATE,
	  PROTOCOL_BAD_PASSWORD,
	  PROTOCOL_TIMED_OUT,
	  PROTOCOL_BAD_RESPONSE,
	  PROTOCOL_EXPIRED_PASSWORD,
	  PROTOCOL_TRANSITION_NEEDED,
	  PROTOCOL_AUTH_TOO_WEAK,

SunOS 5.7		  Last change:				4

Misc. Reference	Manual Pages		       sasl_server(3sasl)

	  PROTOCOL_ENCRYPT_NEEDED,
	  PROTOCOL_CANCELLED_BY_CLIENT,
	  OTHER_PROTOCOL_FAILURE,
	  max_login_failure
	  };

	 // Given a login_failures code, return	a string representation.
	 static	string error_message(login_failures);
     };

     class sasl_server::mechanism
     {
     public:
	 virtual ~mechanism();

	 virtual sasl_server::login_failures login(
	  // what was the initial string passed	by the client
	  const	string &initialResponse,

	  // the server	challenge upon continue
	  // Filled in upon "LOGIN_CONTINUE"
	  string &continueString,

	  // the username which	was logged in under
	  // Filled in upon "LOGIN_OKAY"
	  string &user,

	  // the authentication	username which was logged in under
	  // Filled in upon "LOGIN_OKAY"
	  string &authuser
	   ) = 0;

	 virtual sasl_server::login_failures continue_login(
	  // what was the next string passed by	the client?
	  const	string &nextResponse,

	  // the server	challenge upon continue
	  // Filled in upon "LOGIN_CONTINUE"
	  string &continueString,

	  // the username which	was logged in under.
	  // Filled in upon "LOGIN_OKAY"
	  string &user,

	  // the authentication	username which was logged in under
	  // Filled in upon "LOGIN_OKAY"
	  string &authuser
	   ) = 0;

	 // All	derived	classes	must define their name.
	 virtual string	mechanismName()	const =	0;

SunOS 5.7		  Last change:				5

Misc. Reference	Manual Pages		       sasl_server(3sasl)

	 // All	derived	classes	must say whether they are considered
	 // plaintext or not.
	 virtual bool plaintextMechanism() const = 0;
     };

     class sasl_server_plain : public sasl_server::mechanism
     {
     public:
	 sasl_server_plain();
	 ~sasl_server_plain();
	 sasl_server::login_failures login(
	  const	string &initialResponse,
	  string &continueString,
	  string &user,
	  string &authuser
	   );

	 sasl_server::login_failures continue_login(
	  const	string &nextResponse,
	  string &continueString,
	  string &user,
	  string &authuser
	   );

	 virtual bool plaintextMechanism() const;
	 virtual string	mechanismName()	const;

	 ////////////////
	 // these must be overridden by	the user
	 ////////////////

	 // We have a username,	so get the password
	 virtual bool getPassword(const	string &user, string &pass) const = 0;

	 // is the given user an administrative	user?
	 virtual bool administrativeUser(const string &user) const = 0;
     };

     class sasl_server_cram_md5	: public sasl_server::mechanism
     {
     public:
	 sasl_server_cram_md5();
	 ~sasl_server_cram_md5();
	 sasl_server::login_failures login(
	  const	string &initialResponse,
	  string &continueString,
	  string &user,
	  string &authuser
	   );

	 sasl_server::login_failures continue_login(
	  const	string &nextResponse,

SunOS 5.7		  Last change:				6

Misc. Reference	Manual Pages		       sasl_server(3sasl)

	  string &continueString,
	  string &user,
	  string &authuser
	   );

	 virtual bool plaintextMechanism() const;
	 virtual string	mechanismName()	const;

	 ////////////////
	 // these must be overridden by	the user
	 ////////////////

	 // We have a username,	so get the password
	 virtual bool getPassword(const	string &user, string &pass) const = 0;

	 // Return the host and	domain (foo.bar)
	 virtual string	hostDotDomain()	const =	0;

	 ////////////////
	 // these may be overridden by the user
	 ////////////////

	 // return a series of random digits
	 virtual string	randomDigits();

	 // return the current time as number of seconds since 1970
	 virtual string	timeStamp();
     };

     class sasl_server_external	: public sasl_server::mechanism
     {
     public:
	 sasl_server_external();
	 ~sasl_server_external();
	 sasl_server::login_failures login(
	  const	string &initialResponse,
	  string &continueString,
	  string &user,
	  string &authuser
	   );

	 sasl_server::login_failures continue_login(
	  const	string &nextResponse,
	  string &continueString,
	  string &user,
	  string &authuser
	   );

	 virtual bool plaintextMechanism() const;
	 virtual string	mechanismName()	const;

	 ////////////////

SunOS 5.7		  Last change:				7

Misc. Reference	Manual Pages		       sasl_server(3sasl)

	 // these must be overridden by	the user
	 ////////////////

	 // is an external user	identification known? If so, what is the user name?
	 virtual bool externalUser(string &user) const = 0;
     };

  Example Code
     #include <transform/transform.h>
     #include <sasl/sasl_server.h>
     #include <sasl/sasl_server_plain.h>
     #include <sasl/sasl_server_cram_md5.h>
     #include <sasl/sasl_server_external.h>

     ////////////////////////////////////////////////////////////////
     //// implement a plain sasl mechanism
     ////////////////////////////////////////////////////////////////

     class tplain : public sasl_server_plain
     {
     public:
	 tplain(const string &pass) : _pass(pass) { }

	 // We have a username,	so get the password
	 virtual bool getPassword(const	string &user, string &pass) const;

	 // is the given user an administrative	user?
	 virtual bool administrativeUser(const string &user) const;

     private:
	 string	_pass;
     };

     bool tplain::getPassword(const string &user, string &pass)	const
     {
	 pass =	_pass;
	 return	true;
     }

     bool tplain::administrativeUser(const string &user) const
     {
	 return	false;
     }

     ////////////////////////////////////////////////////////////////
     //// implement an external	sasl mechanism
     ////////////////////////////////////////////////////////////////

     class textern : public sasl_server_external
     {
     public:
	 textern(const string &user) : _user(user) { }

SunOS 5.7		  Last change:				8

Misc. Reference	Manual Pages		       sasl_server(3sasl)

	 // is an external user	identification known? If so, what is the user name?
	 virtual bool externalUser(string &user) const;

     private:
	 string	_user;
     };

     bool textern::externalUser(string &user) const
     {
	 user =	_user;
	 return	true;
     }

     ////////////////////////////////////////////////////////////////
     //// implement a cram-md5 sasl mechanism
     ////////////////////////////////////////////////////////////////

     class tcram : public sasl_server_cram_md5
     {
     public:
	 tcram(const string &pass, const string	&hdotdom) : _pass(pass), _hdotdom(hdotdom) { }

	 // We have a username,	so get the password
	 virtual bool getPassword(const	string &user, string &pass) const;

	 // Return the host and	domain (foo.bar)
	 virtual string	hostDotDomain()	const;

     private:
	 string	_pass, _hdotdom;
     };

     bool tcram::getPassword(const string &user, string	&pass) const
     {
	 pass =	_pass;
	 return	true;
     }

     string tcram::hostDotDomain() const
     {
	 return	_hdotdom;
     }

     ////////////////////////////////////////////////////////////////
     //// test stuff
     ////////////////////////////////////////////////////////////////

     void usage()
     {
	 cerr << "Usage: testserver [-p] -m sasl-mechanism -U user -P password -h hostdotdomain\n"
	   << "-p\tallow plaintext mechanisms\n";
	 exit(1);

SunOS 5.7		  Last change:				9

Misc. Reference	Manual Pages		       sasl_server(3sasl)

     }

     main(int argc, char **argv)
     {
	 string	mechanism;
	 bool allowPlaintextMechanisms = false;
	 string	user, pass, hostdotdomain;

	 int c;
	 while ((c = getopt(argc, argv,	"h:m:pU:P:?")) != -1)
	  switch (c)
	      {
	      case 'm':	mechanism = optarg; break;
	      case 'p':	allowPlaintextMechanisms = true; break;
	      case 'U':	user = optarg; break;
	      case 'P':	pass = optarg; break;
	      case 'h':	hostdotdomain =	optarg;	break;
	      case '?':	usage(); break;
	      }

	 if (!user.size() || !mechanism.size() || !pass.size() || !hostdotdomain.size())
	  usage();

	 sasl_server ss;      // instantiate the server	driver
	 tplain	tp(pass);	   // instantiate a couple of mechanisms
	 textern te(user);
	 tcram tc(pass,	hostdotdomain);

	 ss.registerSaslMechanism(tp);	// register our	mechanisms
	 ss.registerSaslMechanism(te);
	 ss.registerSaslMechanism(tc);

	 string	tmpstring, initialClientResponse, continueString, retuser, retauthuser;

	 cout << "First	string from client (use	quoted-printable)? " <<	flush;
	 cin >>	tmpstring;
	 initialClientResponse = transform::decode_quoted_printable(tmpstring);

	 sasl_server::login_failures ret =
	  ss.login(mechanism, allowPlaintextMechanisms,	initialClientResponse, continueString, retuser,	retauthuser);

	 while (ret == sasl_server::LOGIN_CONTINUE)
	  {
	  cout << "Server response (in qp): '" << transform::encode_quoted_printable(continueString) <<	"'\n";
	  cout << "Next	string from client (use	quoted-printable)? " <<	flush;
	  cin >> tmpstring;
	  string clientResponse	= transform::decode_quoted_printable(tmpstring);
	  ret =	ss.continue_login(clientResponse, continueString, retuser, retauthuser);
	  }

	 if (ret == sasl_server::LOGIN_OKAY)
	  cout << "sasl	success: retuser='" << retuser << "', retauthuser='" <<	retauthuser << "'\n";

SunOS 5.7		  Last change:			       10

Misc. Reference	Manual Pages		       sasl_server(3sasl)

	 else
	  cerr << "sasl	failure: " << long(ret)	<< ", "	<< sasl_server::error_message(ret) << "\n";

	 return	0;
     }

SunOS 5.7		  Last change:			       11

--------------F10A0A2EC469F0998F2DBC84--

Date: Wed, 8 Aug 2001 11:51:38 -0400
From: Lawrence Greenfield <[email-masked]>
To: Leif Johansson <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>, Tony Hansen <[email-masked]>, "Robert J. Siemborski" <[email-masked]>
Subject: Re: SASL C API bar BOF?
Sender: [email-masked]

The latest and greatest in Chris Newman/CMU/etc. API is:

http://bugzilla.andrew.cmu.edu/cvsweb/src/sasl/include/sasl.h?rev=1.43.2.21&content-type=text/x-cvsweb-markup

I'm going to check with Rob to make sure that he doesn't have any
pending changes, and then I'll post it in text.

saslplug.h in the same repository is the plugin api.

Larry

   Date: Wed, 08 Aug 2001 07:52:45 -0600
   From: Alexey Melnikov <[email-masked]>
   Organization: ACI WorldWide / MessagingDirect
   CC: Tony Hansen <[email-masked]>, SASL WG <[email-masked]>

   Leif Johansson wrote:

   > On Wed, Aug 08, 2001 at 07:11:02AM -0600, Alexey Melnikov wrote:
   > >
   > > Actually that what I was thinking myself.
   > >
   > > So, we meet on Thursday at 11:30 near IETF message board.
   >
   > Could someone forward the latest version of the Chris Newman c-api draft
   > as a basis for discussion.

   I suggest we use CMU SASL API as a base for discussion.

Date: Wed, 08 Aug 2001 07:52:45 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Leif Johansson <[email-masked]>
CC: Tony Hansen <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: SASL C API bar BOF?
Sender: [email-masked]

Leif Johansson wrote:

> On Wed, Aug 08, 2001 at 07:11:02AM -0600, Alexey Melnikov wrote:
> >
> > Actually that what I was thinking myself.
> >
> > So, we meet on Thursday at 11:30 near IETF message board.
>
> Could someone forward the latest version of the Chris Newman c-api draft
> as a basis for discussion.

I suggest we use CMU SASL API as a base for discussion.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

Date: Wed, 8 Aug 2001 15:43:46 +0200
From: Leif Johansson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Tony Hansen <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: SASL C API bar BOF?
Sender: [email-masked]

On Wed, Aug 08, 2001 at 07:11:02AM -0600, Alexey Melnikov wrote:
> 
> Actually that what I was thinking myself.
> 
> So, we meet on Thursday at 11:30 near IETF message board.

Could someone forward the latest version of the Chris Newman c-api draft
as a basis for discussion.

	MVH leifj

Date: Wed, 08 Aug 2001 07:11:02 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Tony Hansen <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: SASL C API bar BOF?
Sender: [email-masked]

Actually that what I was thinking myself.

So, we meet on Thursday at 11:30 near IETF message board.

Tony Hansen wrote:

> May I suggest a lunch BOF on Thursday? (We're running out of time
> slots.)
>
>         Tony Hansen
>         [email-masked]
>
> Alexey Melnikov wrote:
> >
> > Some people expressed their interest in C API for SASL. Anybody wants to
> > gather during IETF meeting to discuss this?

--
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

Date: Wed, 08 Aug 2001 09:07:17 -0400
From: Tony Hansen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: SASL C API bar BOF?
Sender: [email-masked]

May I suggest a lunch BOF on Thursday? (We're running out of time
slots.)

	Tony Hansen
	[email-masked]

Alexey Melnikov wrote:
> 
> Some people expressed their interest in C API for SASL. Anybody wants to
> gather during IETF meeting to discuss this?

Date: Wed, 8 Aug 2001 05:58:13 -0700
From: Gregory Neil Shapiro <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: SASL C API bar BOF?
Sender: [email-masked]

> Some people expressed their interest in C API for SASL. Anybody wants to
> gather during IETF meeting to discuss this?

leg+> I'll come if others are interested.

Same here.. But I'll be mostly quiet (except for supporting the idea of
having one).  Currently, Larry is my supplier but it would nice for my
application to support other SASL libraries and having this API would help
with that portability (much like LDAP, IPv6, etc).

Date: Wed, 8 Aug 2001 08:01:21 -0400
From: Lawrence Greenfield <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Re: SASL C API bar BOF?
Sender: [email-masked]

   Date: Wed, 08 Aug 2001 01:17:33 -0600
   From: Alexey Melnikov <[email-masked]>
   Organization: ACI WorldWide / MessagingDirect

   Some people expressed their interest in C API for SASL. Anybody wants to
   gather during IETF meeting to discuss this?

I'll come if others are interested.

Larry

Date: Wed, 08 Aug 2001 01:59:13 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Leif Johansson <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: SASL C API bar BOF?
Sender: [email-masked]

Leif Johansson wrote:

> On Wed, Aug 08, 2001 at 01:17:33AM -0600, Alexey Melnikov wrote:
> >
> > Hi,
> > Some people expressed their interest in C API for SASL. Anybody wants to
> > gather during IETF meeting to discuss this?

> sure

Any preferences regarding time?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

Date: Wed, 08 Aug 2001 01:35:55 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: SASL in HTTP
Sender: [email-masked]

There are two drafts available now:
1).
http://search.ietf.org/internet-drafts/draft-burdis-http-sasl-00.txt, it
uses HTTP upgrade mechanism, the same way HTTP TLS upgrade works.
2).
http://search.ietf.org/internet-drafts/draft-nystrom-http-sasl-00.txt,
it extends WWW-Authenticate/Proxy-Authenticate headers.

Assuming there is an interest in HTTP SASL profile (i.e. vendors are
going to implement it), I would like to discuss idea with authors of
both drafts during IETF meeting. Whoever is interested, please send me
an email. If there is enough interest I will post message to SASL
mailing list with information when and where to meet.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

Date: Wed, 08 Aug 2001 01:17:33 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: SASL WG <[email-masked]>
Subject: SASL C API bar BOF?
Sender: [email-masked]

Hi,
Some people expressed their interest in C API for SASL. Anybody wants to
gather during IETF meeting to discuss this?

--
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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