Subject: Debugging SASL setup

From: Steve Farmer <[email-masked]>
Date: Thu, 16 Jan 2003 14:07:15 +1100

Hi all,

I am implementing an SMTP client which needs to authenticate using SASL.

I ma having a bit of difficulty debugging against sendmail and I was 
wondering if anyone could point me towards a setup which I can use to 
debug, perhaps IMAP or a http setup would be easier or better.

Or alternatively is there a debug flag for SASL which can generate a logfile?

Regards
Steve Farmer
-- 
-------------------------------------------------
Nearly all men can stand adversity, but if you want to test a man's 
character, give him power.
-Abraham Lincoln, U.S. president (1809-1865)
Support free speech; visit http://www.efa.org.au/

Heads Together Services Pty Ltd http://www.hts.com.au
Email: [email-masked]     Tel: 612 9982 6767     Fax: 612 9981 3081

---

From: Gregory Neil Shapiro <[email-masked]>
Date: Wed, 15 Jan 2003 20:26:11 -0800

> Or alternatively is there a debug flag for SASL which can generate a 

You can try testing against test.smtp.org which offers many SASL
mechanisms as well as access to the logs with a high logging level
set.  For more information, see:

http://test.smtp.org/

---

From: Steve Farmer <[email-masked]>
Date: Thu, 16 Jan 2003 15:57:13 +1100

HI Gregory,

I have my own test SMTP server set up with SASL , I was really trying 
to find out how I can generate a detailed log so that I can figure 
out where my client auth is failing.

Any pointers welcome !

Regards
Steve

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 16 Jan 2003 11:04:29 -0500

>debug, perhaps IMAP or a http setup would be easier or better.

If you're using the Cyrus-SASL library, I've found that the sample
applications (sample-client/sample-server) are pretty good to perform
debugging.  At least they helped me.

--Ken

---

From: Gregory Neil Shapiro <[email-masked]>
Date: Wed, 15 Jan 2003 20:26:11 -0800

http://test.smtp.org/

---

From: Steve Farmer <[email-masked]>
Date: Thu, 16 Jan 2003 15:57:13 +1100

HI Gregory,

Any pointers welcome !

Regards
Steve

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 16 Jan 2003 11:04:29 -0500

--Ken

To: Steve Farmer <[email-masked]>
cc: [email-masked]
Subject: Re: Debugging SASL setup 
Date: Thu, 16 Jan 2003 11:04:29 -0500
From: Ken Hornstein <[email-masked]>
Sender: [email-masked]

--Ken

Posted-Date: Thu, 16 Jan 2003 15:57:15 +1100
Date: Thu, 16 Jan 2003 15:57:13 +1100
To: Gregory Neil Shapiro <[email-masked]>
From: Steve Farmer <[email-masked]>
Subject: Re: Debugging SASL setup
Cc: [email-masked]
Sender: [email-masked]

HI Gregory,

Any pointers welcome !

Regards
Steve

Date: Wed, 15 Jan 2003 20:26:11 -0800
From: Gregory Neil Shapiro <[email-masked]>
To: Steve Farmer <[email-masked]>
Cc: [email-masked]
Subject: Re: Debugging SASL setup
Sender: [email-masked]

http://test.smtp.org/

Posted-Date: Thu, 16 Jan 2003 14:07:18 +1100
Date: Thu, 16 Jan 2003 14:07:15 +1100
To: [email-masked]
From: Steve Farmer <[email-masked]>
Subject: Debugging SASL setup
Sender: [email-masked]

Hi all,

Regards
Steve Farmer

Date: Wed, 15 Jan 2003 13:01:27 +0100
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: SASL @ IETF#56
Sender: [email-masked]

BTW, we'll be meeting in San Francisco.  If you are an editor of
one of the I-Ds explicitly listed in the charter, please submit
a revision as a WG I-D (e.g., draft-ietf-sasl-) for discussion
as soon as possible.

Kurt

Date: Mon, 13 Jan 2003 18:37:17 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Steve Farmer <[email-masked]>
CC: [email-masked]
Subject: Re: 16 Octet Hash
Sender: [email-masked]

Steve Farmer wrote:
> 
> Hi Larry,
> 
> Apologies for that, I am implementing rfc2831 and it states ...

FYI, you might want to look at the the RFC 2831bis draft, which has some
corrections/clarifications:

http://www.ietf.org/internet-drafts/draft-melnikov-rfc2831bis-02.txt

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

Date: Mon, 13 Jan 2003 17:44:18 -0500
From: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: 16 Octet Hash
Sender: [email-masked]

Lawrence Greenfield wrote:
> The document is a little unclear at this point. "HEX(n)" means, given
> n, the 128-bit output of a previous MD5 or HMAC-MD5 operation, encode
> it in 32 hex digits.

... using lower case ...

	Tony Hansen
	[email-masked]

Posted-Date: Tue, 14 Jan 2003 09:35:34 +1100
Date: Tue, 14 Jan 2003 09:35:34 +1100
To: Lawrence Greenfield <[email-masked]>, [email-masked]
From: Steve Farmer <[email-masked]>
Subject: Re: 16 Octet Hash
Sender: [email-masked]

Larry,

Thanks mate , I had assumed that but I wanted to be clear.

Regards from "Down Under"

Steve
At 5:30 PM -0500 13/1/03, Lawrence Greenfield wrote:
>    Date: Tue, 14 Jan 2003 09:25:50 +1100
>    From: Steve Farmer <[email-masked]>
>
>    Apologies for that, I am implementing rfc2831 and it states ...
>
>    "Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the
>    string k, a colon and the string s.
>
>        Let HEX(n) be the representation of the 16 octet MD5 hash"
>
>    Soi I am wondering what to use for the 16 octet hash
>
>As it says, you must use MD5, as described in RFC 1321. The output of
>MD5 is 128-bits (16 octets) long. HMAC-MD5 is described RFC 2104.
>
>You should use exactly the hash operation that is specified.
>
>The document is a little unclear at this point. "HEX(n)" means, given
>n, the 128-bit output of a previous MD5 or HMAC-MD5 operation, encode
>it in 32 hex digits.
>
>Larry

Date: Mon, 13 Jan 2003 17:30:15 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], Steve Farmer <[email-masked]>
Subject: Re: 16 Octet Hash
Sender: [email-masked]

   Date: Tue, 14 Jan 2003 09:25:50 +1100
   From: Steve Farmer <[email-masked]>

   Apologies for that, I am implementing rfc2831 and it states ...

   "Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the 
   string k, a colon and the string s.

       Let HEX(n) be the representation of the 16 octet MD5 hash"

   Soi I am wondering what to use for the 16 octet hash

As it says, you must use MD5, as described in RFC 1321. The output of
MD5 is 128-bits (16 octets) long. HMAC-MD5 is described RFC 2104.

You should use exactly the hash operation that is specified.

The document is a little unclear at this point. "HEX(n)" means, given
n, the 128-bit output of a previous MD5 or HMAC-MD5 operation, encode
it in 32 hex digits.

Larry

Posted-Date: Tue, 14 Jan 2003 09:25:51 +1100
Date: Tue, 14 Jan 2003 09:25:50 +1100
To: Lawrence Greenfield <[email-masked]>, [email-masked]
From: Steve Farmer <[email-masked]>
Subject: Re: 16 Octet Hash
Sender: [email-masked]

Hi Larry,

Apologies for that, I am implementing rfc2831 and it states ...

"Let KD(k, s) be H({k, ":", s}), i.e., the 16 octet hash of the 
string k, a colon and the string s.

    Let HEX(n) be the representation of the 16 octet MD5 hash"

Soi I am wondering what to use for the 16 octet hash

Regards
Steve

At 1:19 PM -0500 13/1/03, Lawrence Greenfield wrote:
>    Date: Mon, 13 Jan 2003 12:17:42 +1100
>    From: Steve Farmer <[email-masked]>
>[...]
>    I may be missing something simple here. I am implementing a SMTP
>    client using SASL.  However the rfc specifies a 16 octet hash as well
>    as a 16 octet MD5 hash.
>
>    Since MD4 gives a 16 octet  result , is it OK to use this ?  If not
>    what should I be using for the 16 octet hash?
>
>What RFC are you talking about? What are you interested in doing?
>
>I can't think of any case where you can freely substitute one hash for
>another in an over-the-wire protocol, but your question leaves out too
>many details for me to understand what you're trying to do.
>
>Larry

Date: Mon, 13 Jan 2003 13:19:03 -0500
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], Steve Farmer <[email-masked]>
Subject: Re: 16 Octet Hash
Sender: [email-masked]

   Date: Mon, 13 Jan 2003 12:17:42 +1100
   From: Steve Farmer <[email-masked]>
[...]
   I may be missing something simple here. I am implementing a SMTP 
   client using SASL.  However the rfc specifies a 16 octet hash as well 
   as a 16 octet MD5 hash.

   Since MD4 gives a 16 octet  result , is it OK to use this ?  If not 
   what should I be using for the 16 octet hash?

What RFC are you talking about? What are you interested in doing?

I can't think of any case where you can freely substitute one hash for
another in an over-the-wire protocol, but your question leaves out too
many details for me to understand what you're trying to do.

Larry

Posted-Date: Mon, 13 Jan 2003 12:17:45 +1100
Date: Mon, 13 Jan 2003 12:17:42 +1100
To: [email-masked]
From: Steve Farmer <[email-masked]>
Subject: 16 Octet Hash
Sender: [email-masked]

Hi all,

I may be missing something simple here. I am implementing a SMTP 
client using SASL.  However the rfc specifies a 16 octet hash as well 
as a 16 octet MD5 hash.

Since MD4 gives a 16 octet  result , is it OK to use this ?  If not 
what should I be using for the 16 octet hash?

Regards
Steve Farmer

To: [email-masked]
Subject: [[email-masked]] I-D ACTION:draft-josefsson-sasl-kerberos5-00.txt
From: Sam Hartman <[email-masked]>
Date: Fri, 10 Jan 2003 14:53:11 -0500
Lines: 112
Sender: [email-masked]

--=-=-=

I understand this is out of scope for our working group, but it seems
that forwarding the initial announcement is reasonable.

--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-josefsson-sasl-kerberos5-00.txt
Date: Fri, 10 Jan 2003 13:49:18 -0500
Sender: [email-masked]

--===-=-=

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

	Title		: A Kerberos 5 SASL Mechanism
	Author(s)	: S. Josefsson
	Filename	: draft-josefsson-sasl-kerberos5-00.txt
	Pages		: 11
	Date		: 2003-1-9
	
This document specifies a Simple Authentication and Security Layer
(SASL) [3] mechanism for Kerberos 5 Client/Server Authentication [1],
with optional initial Authentication Service (AS) and/or
Ticket-Granting-Service (TGS) exchanges.

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

--===-=-=
Content-Type: multipart/alternative; boundary="====-=-="

--====-=-=
Content-Type: message/external-body; access-type=mail-server

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

ENCODING mime
FILE /internet-drafts/draft-josefsson-sasl-kerberos5-00.txt

--====-=-=
Content-Type: message/external-body;
  name=draft-josefsson-sasl-kerberos5-00.txt; access-type=anon-ftp

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

--====-=-=--

--===-=-=--

--=-=-=--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-anon-00.txt
Date: Thu, 09 Jan 2003 09:24:27 -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 Simple Authentication and Security Layer Working Group of the IETF.

	Title		: The Anonymous SASL Mechanism
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-anon-00.txt
	Pages		: 8
	Date		: 2003-1-8
	
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-ietf-sasl-anon-00.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-ietf-sasl-anon-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-sasl-anon-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-sasl-anon-00.txt

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

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

--OtherAccess--

--NextPart--