Subject: Re: Use of NFKC in SASLprep

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 30 Apr 2004 08:08:52 -0700

At 04:19 PM 4/22/2004, Simon wrote:
>FYI, as SASLprep is using NFKC per Unicode 3.2, you might be
>interested in the NFKC stability problem discussed on
><http://www.unicode.org/review/pr-29.html>. The page mention a
>strategy to maintain stability across NFKC revisions, which might be
>relevant for SASLPrep.
>I'd be interested to hear people's opinions on the problem.

Well, I concur that there is a minor inconsistency issue which
*might* lead to a security issue.  However, as PR-29, "we know
of no realistic scenarios that would present such problems."

I have no problem noting that this inconsistency issue exists
and that it *might* lead to a security issue (with an informational
reference to PR-29).  (However, I wouldn't mind if someone suggested
some wording here.)

Beyond that, I don't think we should say much more.  And, in
particular, I don't think we should change the SASLprep algorithm
based upon PR-29 suggestions as the UTC has not yet produced a
corrigendum in this area.

Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 30 Apr 2004 18:09:00 +0200

> corrigendum in this area.

Do I understand correctly if this position mean that an implementation
that receive U+0B47 U+0300 U+0B3E U+0323 can pick any of:

 1) U+0B47 U+0300 U+0B3E U+0323
 2) U+0B4B U+0300 U+0323
 3) U+0B4B U+0323 U+0300

And be compliant?

If not, what is the correct output?

As I understand it, PR-29 was prompted by a discovery of an internal
inconsistency in the NFKC specifications, not by a wish to alter an
existing and implementable specification.  That means that unless the
inconsistency is clarified, there is no guidance on which
interpretation is correct.

One scenario where this issue may be realistic are computer generated
passwords.  In some mechanisms, all-binary passwords are now no longer
possible, so instead you randomize UCS-4 code points, apply SASLPrep
and perform UTF-8 encoding.  Given PR-29, NFKC of such randomized
passwords might not be stable or idempotent.

Thanks,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 30 Apr 2004 11:00:35 -0700

> 1) U+0B47 U+0300 U+0B3E U+0323

Until the UTC publishes a corrigendum on the matter, yes.

>interpretation is correct.

It's not our place to say which interpretation of NKFC is correct.

We should just note the issue and move on.  As PR-29 says:
  the actual cases of problematic data are limited to sequences
  that should never occur in practice.

SASLprep is good enough for Proposed Standard level.

I think this is an issue which Stringprep should address in
going to Draft Standard.  We can then just follow whatever is
done in Stringprep (when we subsequently revise for Draft
Standard).

>passwords.

I think not.  Realistic password generation algorithm need to
produce well-formed text.

>In some mechanisms, all-binary passwords are now no longer
>and perform UTF-8 encoding.

A sequence of random UCS-4 code points (of any length suitable
for use as a password) would likely fail SASLprep.  More
realistically, the randomizer would choose assigned base
character code points where SASLprep(codepoint)==codepoint.

That is, I think:
  do {
    password = SASLprep(randomUnicode()); // returns NULL if SASLprep fails
  } while password == NULL;

is an unrealistic algorithm for generation of random passwords.
A more realistic algorithm would be:
  password = randomApproproiateCodePoints()

where appropriate minimally implies each code is a base character
and the SASLprep of that code is itself.

It's my opinion that that this issue, aside from noting its
existence, should be addressed in NFKC by the UTC, then in
Stringprep by the IETF, and lastly in SASLprep by this WG.
But we shouldn't wait for this, we should publish what we
have as being "good enough" and then revise once the upstream
specifications have been appropriately revised.

Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 30 Apr 2004 18:09:00 +0200

And be compliant?

Thanks,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 30 Apr 2004 11:00:35 -0700

That is, I think:
  do {

Kurt 

Date: Fri, 30 Apr 2004 11:00:35 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Cc: [email-masked]
Sender: [email-masked]

That is, I think:
  do {

Kurt 

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Date: Fri, 30 Apr 2004 18:09:00 +0200
Lines: 49
Cancel-Lock: sha1:BThZfMGjqJawEDQQtLTRa0Hbn5I=
Sender: [email-masked]

And be compliant?

Thanks,
Simon

Date: Fri, 30 Apr 2004 08:08:52 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Use of NFKC in SASLprep
Sender: [email-masked]

Kurt

Date: Thu, 29 Apr 2004 19:37:10 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-09.txt
Sender: [email-masked]

This revision addresses most of the comments raised by the IESG.
  https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1282&filename=draft-ietf-sasl-saslprep

The changes include:
- Added examples (typo in 3rd example, s/#3/#2/, is known)
- Added a statement regarding applicability to existing specifications.
- Clarified what "other handling" could be.
  
Additionally, there is now a DISCUSS regarding the NFKC stability
concern Simon raised.  I will shortly post my thoughts on this
concern to the list for discussion.

Kurt

At 12:53 PM 4/29/2004, [email-masked] wrote:
>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           : SASLprep: Stringprep profile for user names and passwords
>        Author(s)       : K. Zeilenga
>        Filename        : draft-ietf-sasl-saslprep-09.txt
>        Pages           : 7
>        Date            : 2004-4-29
>        
>This document describes how to prepare Unicode strings representing
>  user names and passwords for comparison.  The document defines the
>  'SASLprep' profile of the 'stringprep' algorithm to be used for both
>  user names and passwords.  This profile is intended to be used by
>  Simple Authentication and Security Layer (SASL) mechanisms (such as
>  PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging
>  simple user names and/or passwords.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-09.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>[email-masked] with the word unsubscribe in the body of the message.  
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>
>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-saslprep-09.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-saslprep-09.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: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-sasl-saslprep-09.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-09.txt>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-saslprep-09.txt
Date: Thu, 29 Apr 2004 15:53:13 -0400
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		: SASLprep: Stringprep profile for user names and passwords
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-saslprep-09.txt
	Pages		: 7
	Date		: 2004-4-29
	
This document describes how to prepare Unicode strings representing
  user names and passwords for comparison.  The document defines the
  'SASLprep' profile of the 'stringprep' algorithm to be used for both
  user names and passwords.  This profile is intended to be used by
  Simple Authentication and Security Layer (SASL) mechanisms (such as
  PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging
  simple user names and/or passwords.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-saslprep-09.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-saslprep-09.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-saslprep-09.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 29 Apr 2004 13:41:44 +0000
To: "Ietf-sasl" <[email-masked]>
From: "Hartmans" <[email-masked]>
Subject: Re: Hello
Sender: [email-masked]

----------suvwnbmmuzujkjlrxlxy
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------suvwnbmmuzujkjlrxlxy
Content-Type: application/octet-stream; name="Alive_condom.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Alive_condom.exe"

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

----------suvwnbmmuzujkjlrxlxy--

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Use of NFKC in SASLprep
Date: Fri, 23 Apr 2004 01:19:30 +0200
Lines: 9
Cancel-Lock: sha1:WqFBhDWsQoYNh0oxSqciVX3n+zw=
Sender: [email-masked]

relevant for SASLPrep.  I'd be interested to hear people's opinions on
the problem.

Thanks,
Simon

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: SASLprep examples
Date: Thu, 22 Apr 2004 13:30:58 +0200
Lines: 9
Cancel-Lock: sha1:KGOMnWAEPx5S2QuPpi/HYH1Gb6M=
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

>  2  user             user       no transformation
>  3  USER             USER       case preserved, will not match #3 

Additionally, perhaps "#3" should have been "#2".

Thanks,
Simon

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: SASLprep examples
Date: Thu, 22 Apr 2004 08:05:56 +0200
Lines: 36
Cancel-Lock: sha1:UDlkqFH6HI3/m7JsMlIjXYgS5VA=
Sender: [email-masked]

"Kurt D. Zeilenga" <[email-masked]> writes:

> In response to IESG comments, I have prepared the following
> examples to be added to the I-D.  Please verify correctness.
> Also, if you have suggestions for additional (or replacement)
> examples, please provide offer specifics.  -- Kurt
>
>
> 3. Examples
>
>  The following table provides examples of how various
>  character data is transformed by SASLprep string
>  preparation algorithm.
>
>  #  Input            Output     Comments
>  -  -----            ------     --------
>  1  x<U+00AD>y       xy         SOFT HYPHEN mapped to nothing
>  2  user             user       no transformation
>  3  USER             USER       case preserved, will not match #3 
>  4  <U+2163>         xIV        output is NFKC

Shouldn't that be 'IV'?

>  5  <U+0007>                    Error - prohibited character
>  6  <U+0627><U+0031>            Error - bidirectional check

I think it would be useful to add a Unicode code point for a
ISO-8859-1 character that is translated into ASCII as well:

8  <U+00AA>            a          output is NFKC, input exists in ISO-8859-1

This was one of the problematic code points for backwards
compatibility in DIGEST-MD5.

Thanks,
Simon

Date: Wed, 21 Apr 2004 22:00:57 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: SASLprep examples
Sender: [email-masked]

In response to IESG comments, I have prepared the following
examples to be added to the I-D.  Please verify correctness.
Also, if you have suggestions for additional (or replacement)
examples, please provide offer specifics.  -- Kurt

3. Examples

 The following table provides examples of how various
 character data is transformed by SASLprep string
 preparation algorithm.

 #  Input            Output     Comments
 -  -----            ------     --------
 1  x<U+00AD>y       xy         SOFT HYPHEN mapped to nothing
 2  user             user       no transformation
 3  USER             USER       case preserved, will not match #3 
 4  <U+2163>         xIV        output is NFKC
 5  <U+0007>                    Error - prohibited character
 6  <U+0627><U+0031>            Error - bidirectional check

From: "Cyril Drouin - Bysoft" <[email-masked]>
To: <[email-masked]>
Subject: Issue with SASL/Postfix/MySQL - Nightmare for 3 DAYS :-(
Date: Wed, 21 Apr 2004 10:25:12 +0200
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_007F_01C4278A.EE06A700
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
I have tried for 3 days now to integrate SASL/PostFix/MySQL but I can't =
make
it.
=20
What I have done :
=20
- Compile Postfix with the SALS and MySQL support :
=20
make -f Makefile.init makefiles 'CCARGS=3D-DHAS_MYSQL
-I/home/cyril/mysql/include -DUSE_SASL_AUTH -I/usr/local/include/sasl'=20
 'AUXLIBS=3D-L/home/cyril/mysql/lib -lmysqlclient -lz -lm
-L/usr/local/lib/sasl2 -lsasl2'

- Compile SALS with the MySQL support :
=20
env CPPFLAGS=3D"-I/usr/include/mysql" LDFLAGS=3D"-L/usr/lib/mysql
-R/usr/lib/mysql"
./configure --enable-sql --with-mysql=3D/usr/lib/mysql

- Create the smtpd.conf:
=20
sasl_pwcheck_method: auxprop
sasl_auxprop_plugin: mysql
mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
mysql_user: postfix
mysql_passwd: password
mysql_hostnames: localhost
mysql_database: users
mysql_statement: SELECT crypt FROM users WHERE address =3D '%u'
mysql_verbose: yes

- Change my main.cf  to :
=20
#Authentification SASL
=20
smtpd_sasl_auth_enable =3D yes
smtpd_sasl2_auth_enable =3D yes
broken_sasl_auth_clients =3D yes
smtpd_sasl_local_domain =3D
smtpd_sasl_security_options =3D noanonymous
smtpd_recipient_restrictions =3D permit_sasl_authenticated, =
permit_mynetworks,
reject_unauth_destination

What I am sure of is :
- MySQL and POSTFIX integration is working as I can check the email =
through
pop3/imap (I am using courier-imap package)
- Postfix can send message out
=20
Few questions :
=20
1/ When I compile sasl, I got an error saying that :
=20
checking for mysql_select_db in -lmysqlclient... (cached) no
configure: WARNING: MySQL library mysqlclient does not work
=20
I can't figure out why I got this warning. I used the same library than =
for
Mysql

2/ I got nothing in maillog. how can I know if SASL is using Mysql ? =
even
how can I know if Postfix is using SASL ?
=20
Few more details :
1/ Redhat 9
2/ Postfix version 2.0.19 =20
3/ SASL SASL2 2.1.18=20
4/ My password are encrypted in my Database=20
=20
Thanks for your answers..I am getting crazy down here with that.
=20
Cyril
=20

------=_NextPart_000_007F_01C4278A.EE06A700
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>I have =
tried for 3=20
days now to integrate SASL/PostFix/MySQL but I can't make=20
it.</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>What I =
have done=20
:</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>- =
Compile Postfix=20
with the SALS and&nbsp;MySQL&nbsp;support :</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>make =
-f=20
Makefile.init makefiles 'CCARGS=3D-DHAS_MYSQL =
-I/home/cyril/mysql/include=20
-DUSE_SASL_AUTH -I/usr/local/include/sasl' </FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2>&nbsp;'AUXLIBS=3D-L/home/cyril/mysql/lib -lmysqlclient -lz -lm=20
-L/usr/local/lib/sasl2 -lsasl2'<BR></FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>- =
Compile SALS with=20
the MySQL support :</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>env=20
CPPFLAGS=3D"-I/usr/include/mysql" LDFLAGS=3D"-L/usr/lib/mysql=20
-R/usr/lib/mysql"<BR>./configure --enable-sql=20
--with-mysql=3D/usr/lib/mysql<BR></DIV></FONT></SPAN>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>- =
Create the=20
smtpd.conf:</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial =
size=3D2>sasl_pwcheck_method:=20
auxprop<BR>sasl_auxprop_plugin: mysql<BR>mech_list: PLAIN LOGIN CRAM-MD5 =

DIGEST-MD5 NTLM<BR>mysql_user: postfix<BR>mysql_passwd:=20
password</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial =
size=3D2>mysql_hostnames:=20
localhost<BR>mysql_database: users<BR>mysql_statement: SELECT crypt FROM =
users=20
WHERE address =3D '%u'<BR>mysql_verbose: yes<BR></DIV></FONT></SPAN>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>- =
Change my=20
main.cf&nbsp; to :</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial =
size=3D2>#Authentification=20
SASL</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2>smtpd_sasl_auth_enable =3D yes<BR>smtpd_sasl2_auth_enable =3D=20
yes<BR>broken_sasl_auth_clients =3D yes<BR>smtpd_sasl_local_domain=20
=3D<BR>smtpd_sasl_security_options =3D =
noanonymous<BR>smtpd_recipient_restrictions =3D=20
permit_sasl_authenticated, permit_mynetworks,=20
reject_unauth_destination<BR></FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>What I =
am sure of is=20
:</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>- =
MySQL and POSTFIX=20
integration is working as I can check the email through pop3/imap (I am =
using=20
courier-imap package)</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>- =
Postfix can send=20
message out</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>Few =
questions=20
:</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial =
size=3D2>1/&nbsp;When I=20
compile sasl, I got an error saying that :</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial =
size=3D2>checking for=20
mysql_select_db in -lmysqlclient... (cached) no<BR>configure: WARNING: =
MySQL=20
library mysqlclient does not work</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>I =
can't figure out=20
why I got this warning. I used the same library than for Mysql</DIV>
<DIV><BR></DIV></FONT></SPAN>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>2/ I =
got nothing in=20
maillog. how can I know if SASL is using Mysql ? even how can I know if =
Postfix=20
is using SASL ?</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>Few =
more details=20
:</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>1/ =
Redhat=20
9</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial><FONT =
size=3D2>2/ Postfix=20
version 2.0.19<SPAN class=3D163192408-21042004><FONT=20
color=3D#0000ff>&nbsp;&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial><FONT =
size=3D2>3/ SASL SASL2=20
2.1.18<SPAN class=3D163192408-21042004><FONT=20
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D163192408-21042004><FONT color=3D#0000ff>4/ My&nbsp;password are =
encrypted=20
in my Database</FONT>&nbsp;</SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial size=3D2>Thanks =
for your=20
answers..I am getting crazy down here with that.</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2>Cyril</FONT></SPAN></DIV>
<DIV><SPAN class=3D851260608-21042004><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_007F_01C4278A.EE06A700--

To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed text for adaptive plaintext attacks
From: Sam Hartman <[email-masked]>
Date: Tue, 13 Apr 2004 11:51:38 -0400
Sender: [email-masked]

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> I personally don't think that the reference to DIGEST-MD5
    Alexey> belongs here. This is better be addressed in DIGEST-MD5.

I'm OK with dropping it although I'll explain why I put it there.

I believe it is important to characterize how valid a security
assumption is.  In reviewing the security of SASL, I'd like to know
both what the security assumptions are and whether these assumptions
are actually reasonable.

Date: Tue, 13 Apr 2004 11:52:58 +0100
From: Alexey Melnikov <[email-masked]>
To: Sam Hartman <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed text for adaptive plaintext attacks
Sender: [email-masked]

Sam Hartman wrote:

>I propose to replace the following text in section 9:
>
>    Distributed server implementations need to be careful in how they
>    trust other parties and, in particular, authentication secrets should
>    only be disclosed to other parties that are trusted to manage and use
>    those secrets in manner acceptable to disclosing party.  It should be
>    noted that, where those secrets are used to provide data
>    confidentiality protections, if a third party (other than the
>    discloser/disclosee) has knowledge of some portion of the protected
>    information, it can use this knowledge in an attack upon other
>    portions of the protected information.
>
>    <<Section 6.3.1 contains a description of a potential class of attack
>    on a distributed server implementation. The section also gives some
>    recommendations about mitigating such attacks.>>
>
>with the following text:
>
>    Distributed server implementations need to be careful in how they
>    trust other parties and, in particular, authentication secrets should
>    only be disclosed to other parties that are trusted to manage and use
>    those secrets in manner acceptable to disclosing party.  
>
> Applications using SASL assume that SASL security layers providing
> confidentiality are secure even when an attacker chooses the text to
> be protected by the security layer.  Similarly applications assume
> that the SASL security layer is secure even if the attacker can
> manipulate the ciphertext output of the security layer.  With the
> exception of the DES modes of the digest-md5 mechanism, all SASL
> mechanisms standardized by the IETF are believed to meet these
> security assumptions.  New SASL mechanisms MUST meet these assumptions.
>
>
>
>
>Do people feel that explicit text about security considerations of CBC
>belong in the base SASL specification?
>
I personally don't think that the reference to DIGEST-MD5 belongs here. 
This is better be addressed in DIGEST-MD5.

Alexey

Date: Mon, 12 Apr 2004 13:13:49 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-saslprep-08.txt
Sender: [email-masked]

FYI, this revision addresses two issues raised during IETF
Last Call.

1) The StringPrep references now points to RFC 3454.
This to keep SASLprep from blocking on the StringPrep I-D.

2) The SASL reference was reclassified as Informative as
the reader need not read nor understand SASL reference
material to implement or make use of SASLprep.

Kurt

At 12:32 PM 4/12/2004, [email-masked] wrote:
>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           : SASLprep: Stringprep profile for user names and passwords
>        Author(s)       : K. Zeilenga
>        Filename        : draft-ietf-sasl-saslprep-08.txt
>        Pages           : 6
>        Date            : 2004-4-12
>        
>This document describes how to prepare Unicode strings representing
>  user names and passwords for comparison.  The document defines the
>  'SASLprep' profile of the 'stringprep' algorithm to be used for both
>  user names and passwords.  This profile is intended to be used by
>  Simple Authentication and Security Layer (SASL) mechanisms (such as
>  PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging
>  simple user names and/or passwords.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-08.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>[email-masked] with the word unsubscribe in the body of the message.  
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
>to change your subscription settings.
>
>
>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-saslprep-08.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-saslprep-08.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: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-sasl-saslprep-08.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sasl-saslprep-08.txt>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-saslprep-08.txt
Date: Mon, 12 Apr 2004 15:32:28 -0400
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		: SASLprep: Stringprep profile for user names and passwords
	Author(s)	: K. Zeilenga
	Filename	: draft-ietf-sasl-saslprep-08.txt
	Pages		: 6
	Date		: 2004-4-12
	
This document describes how to prepare Unicode strings representing
  user names and passwords for comparison.  The document defines the
  'SASLprep' profile of the 'stringprep' algorithm to be used for both
  user names and passwords.  This profile is intended to be used by
  Simple Authentication and Security Layer (SASL) mechanisms (such as
  PLAIN, CRAM-MD5, and DIGEST-MD5) as well as other protocols exchanging
  simple user names and/or passwords.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-saslprep-08.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-saslprep-08.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-saslprep-08.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Subject: Proposed text for adaptive plaintext attacks
Date: Mon, 12 Apr 2004 14:37:16 -0400 (EDT)
From: [email-masked] (Sam Hartman)
Sender: [email-masked]

I propose to replace the following text in section 9:

    Distributed server implementations need to be careful in how they
    trust other parties and, in particular, authentication secrets should
    only be disclosed to other parties that are trusted to manage and use
    those secrets in manner acceptable to disclosing party.  It should be
    noted that, where those secrets are used to provide data
    confidentiality protections, if a third party (other than the
    discloser/disclosee) has knowledge of some portion of the protected
    information, it can use this knowledge in an attack upon other
    portions of the protected information.

    <<Section 6.3.1 contains a description of a potential class of attack
    on a distributed server implementation. The section also gives some
    recommendations about mitigating such attacks.>>

with the following text:

    Distributed server implementations need to be careful in how they
    trust other parties and, in particular, authentication secrets should
    only be disclosed to other parties that are trusted to manage and use
    those secrets in manner acceptable to disclosing party.  

 Applications using SASL assume that SASL security layers providing
 confidentiality are secure even when an attacker chooses the text to
 be protected by the security layer.  Similarly applications assume
 that the SASL security layer is secure even if the attacker can
 manipulate the ciphertext output of the security layer.  With the
 exception of the DES modes of the digest-md5 mechanism, all SASL
 mechanisms standardized by the IETF are believed to meet these
 security assumptions.  New SASL mechanisms MUST meet these assumptions.

Do people feel that explicit text about security considerations of CBC
belong in the base SASL specification?

--Sam

Date: Mon, 12 Apr 2004 10:44:09 -0700
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Half-anonymous authentication
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 09:03 AM 4/12/2004, Sam Hartman wrote:
>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
>
>    Kurt> As I noted in my response, we use often use the terms based
>    Kurt> on "to authenticate" to mean "to login" instead of "to
>    Kurt> verify".  I think the "A"authentication in SASL is commonly
>    Kurt> used in the "to login" fashion.

I like to replace "to login" in the above comment with "to identify".

I don't may describing ANONYMOUS mechanism as identifying the
user as an anonymous user.  I have a problem saying the that
the ANONYMOUS verifies the user's identity is anonymous.

The latter gives off a number of false impressions.  It particular,
the latter can be read as implying the ANONYMOUS mechanism is
providing verified user identity privacy.

>    Kurt> rfc2222bis needs to be more clear here, as it is dangerous
>    Kurt> to say things are "authenticated" when they are not
>    Kurt> "verified".
>
>With my security hat on, I have to disagree.  Not verified at all is
>just one point along the continuum of verification.  The security
>difference between not verified and poorly verified is not
>particularly significant.

I agree to your statement as it applies to verification.
I would also agree that there is wide continuum of identification.
However, I disagree that the terms verification and identification
are synonymous.  Whether any harm can be caused to inappropriate
interchange depends on the particular case.

My particular gripe with rfc2222bis is not defining well its
terminology and it not terrible self consistent with its use
of that terminology.

Kurt

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: Half-anonymous authentication
From: Sam Hartman <[email-masked]>
Date: Mon, 12 Apr 2004 12:03:59 -0400
Sender: [email-masked]

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> As I noted in my response, we use often use the terms based
    Kurt> on "to authenticate" to mean "to login" instead of "to
    Kurt> verify".  I think the "A"authentication in SASL is commonly
    Kurt> used in the "to login" fashion.

    Kurt> rfc2222bis needs to be more clear here, as it is dangerous
    Kurt> to say things are "authenticated" when they are not
    Kurt> "verified".

With my security hat on, I have to disagree.  Not verified at all is
just one point along the continuum of verification.  The security
difference between not verified and poorly verified is not
particularly significant.

I'm going to try and say less on this issue as making a consensus call
is already going to be challenging.

Date: Sun, 11 Apr 2004 19:49:14 -0700
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: clarification as to the purpose of ANONYMOUS mechanism
Sender: [email-masked]

In response to recent discussions on this list, I propose to
insert the following paragraph between the existing first and
second paragraphs of Section 1 of draft-ietf-sasl-anon-xx.txt:

  Unlike many other SASL mechanisms whose purpose is to authenticate
  and identify the user to a server, the purpose of this SASL mechanism
  is to allow the user to gain access to services or resources
  without requiring the user to establish or otherwise disclose their
  identity to the server.  That is, this mechanism provides an anonymous
  login method.

Comments?

Kurt

Date: Sun, 11 Apr 2004 14:00:12 -0700
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Half-anonymous authentication
Cc: Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

As I noted in my response, we use often use the terms based on
"to authenticate" to mean "to login" instead of "to verify".
I think the "A"authentication in SASL is commonly used in
the "to login" fashion.

rfc2222bis needs to be more clear here, as it is dangerous to say
things are "authenticated" when they are not "verified".

And, I think, we should avoid using terms such as "authentication
mechanism" when there are reasonable alternatives (such as
"SASL mechanism").

At 11:33 AM 4/11/2004, Hallvard B Furuseth wrote:
>(I approached this whole thing from the point of view of a user
>of a SASL library, who knows SASL but may not be aware that there are
>mechanisms that do not provide what the SASL spec might make one assume
>it provides.)

The SASL specification should be more clear that not all mechanisms
verify (or even establish) the user's identity, not all mechanisms
pass authorization identity information, not all mechanism support
security layers, etc..  That is, the range of function that mechanisms
offer can vary widely.

And, I think, it very important that to be clear that SASL does not
abstract away the differences between mechanisms.  Something in the
client/server protocol implementation needs to deal with them.  Maybe
the implementation uses a SASL library that abstracts away some of
these differences, but it should be clear something at both the client
and the server has to deal with the differences.  SASL framework
doesn't hide mechanism particulars from protocols.

>>> Correction: It needs to say which authentication and authorization IDs
>>> it _requests_.  Or provides, or whatever is the correct term.  Hopefully
>>> these IDs will be treated just like IDs from other SASL mechanisms.
>>> Or like no ID (unauthenticated), if that's what the mechanism requests.
>>
>> ANONYMOUS doesn't request nor provide an authentication ID nor an
>> authorization ID.
>
>There has to be _some_ way to say that ANONYMOUS changes the
>authentication ID, or requests a change of it, or however you wish to
>say that, and what that new ID is, or that the new ID is absent, or
>however you wish to say that.

By use of the ANONYMOUS mechanism, the client communicates to the server
that the user wishes to access the services/resources provided by server
on an anonymous basis (e.g., without disclosing its identity to the server).

If the server is willing and able, it responds accordingly to the request
and takes appropriate actions within its authorization system to grant
that access.

Note here the separation between what information is communicated by the
mechanism and what the server implementation does with that information.

Details of how identity information (including lack of knowing the user's
identity) is represented by the server are outside the scope of the
mechanism specification.

>Could you please provide a wording for
>that which you will accept, so we can at least talk about how it relates
>to the authentication ID?

In respect to the mechanism, no authentication ID is communicated.
How a server implementation represents that no authentication ID was
communicated by the mechanism is its business.

>Maybe just some wording to satisfy the SASL
>'Profiling requirements' requirement above.

Above you called this profiling requirement:
    A specification of how the authorization identity passed from the
    client to the server is to be interpreted.

This requirement means that protocol (not mechanism) specifications
are to define the form used to representation the proxy authorization
identity.  It should not be viewed as requiring all mechanisms to
actually pass a proxy authorization identity information from
client-to-server.

>> Anyways, I think it sufficient for the mechanism to say what it
>> provides (no IDs in the case of ANONYMOUS).  How that's used
>> in application protocol (or implementations thereof) is simply
>> beyond the scope of the mechanism specification.
>
>Yes.

Noted.

>>>> It should be obvious that this mechanism does not itself
>>>> establish an authentication identity nor transfer an authorization
>>>> identity.  However, if more clarity is needed, I would suggest
>>>> replacing the paragraph:
>>>>   This mechanism does not provide a security layer.
>>>> with:
>>>>   This mechanism does not establish the identity of the
>>>>   client (or user) nor the server (or service); does not
>>>>   support transfer of an authorization identity; nor
>>>>   provide a security layer.
>>>
>>> I think either 'It requests anonymous authentication and authorization
>>> identities.
>>
>> I assume It == user here.
>
>I meant it = mechanism.  Though it's on behalf of the user, if that's
>what you mean.
>
>> I'm describing what the mechanism
>> establishes and not (in this paragraph) what the user may or
>> may not request using this mechanism.
>
>But 'establishes' is wrong - as you said, how any mechanism affects
>authentication and authorization IDs outside of the mechanism is beyond
>the scope of that mechanism.

I think you are not seeing the separation between what information
a mechanism may or may not provide to the client/server, and how that
information might be used by the client/server.  In the above text,
I was referring to what information the mechanism provides to the
client/server as opposed to affects which are outside the mechanism.

>> Cyrus SASL?
>
>Yes.  But a client and a server which uses the mechanism?

I believe you can configure OpenLDAP to make use of the mechanism.
Likely Cyrus SASL's own sample client/server may use this mechanism.

>Anyway, I kind of hoped someone who already use SASL could tell me,
>so I won't have to compile and install stuff just to find out.

It's no different than supporting any other mechanism.  You need
to understand what information the mechanism provide, its semantics,
and then map that information into your authorization system.
SASL itself doesn't abstract away mechanism differences (but
your SASL library might).

>The only example I know of is openldap ldapsearch.  It does not
>treat auth(c/z) ID as trace ID.

GOOD.

>> It's not to authenticate the entity using the client to the
>> client.
>>
>> This is not to say that clients cannot do that, but the
>> security considerations for using SASL in this fashion are
>> broad and wide.
>
>Perhaps they should be discussed in rfc2222bis?

Like, in my best Elmer Fudd voice, "be very, very careful" :-)

>>> and then grant access to
>>> something on the client side depending on whether or not authentication
>>> succeeds.
>>
>> Such a client would need to treat ANONYMOUS as not establishing
>> the user's entity.  Here, at least, the client can just disallow
>> the mechanism.  A client which uses PLAIN, CRAM-MD5, etc., for
>> such has it far worse.  They need to know which user names
>> have widely known passwords or user names are granted access
>> regardless of what password is provided.  How many PLAIN
>> deployments out there accept any password for "anonymous"?
>
>Do you mean such things come with the default SASL setup with some
>implementations? That sounds scary enough that it might be an idea to
>warn about it in rfc2222bis.

I think we need a brief warning.  SASL purpose is to "login" the client
to the server.  It's not designed "login" the user to the client.
What the server might find acceptable, may not be acceptable to the client.

>Client's using SASL for the purposes of granting access to services/resources
>at the client should be "very, very careful" not to make invalid assumptions
>about the success (or failure) of a SASL mechanism exchange.

>All that any SASL mechanism authenticates is that the client provided
>sufficient credentials to authenticate in the manner it did.  Which is
>none at all, in the ANONYMOUS case.  The administrator who allowed
>that authentication is the one who knows what it means that someone
>authenticated that way, and what access to grant.

Noting that you are using the "to authenticate" (and variants) to
mean "to login", I would have to agree with this statement.  In
particular, I agree that client does not provide any credentials
when using the ANONYMOUS mechanism.  This has been one of my
points through this discussion.

Kurt 

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: rfc2222bis: authentication identity
Date: Sun, 11 Apr 2004 20:54:37 +0200
Sender: [email-masked]

rfc2222bis has added the concept of an authentication identity since
rfc2222.  Is this identity only a parameter to the SASL authentication
process, and can be discarded after SASL authentication is complete?  Or
is it also part of the connecton's authorization state after SASL
authentication?  If so, what for?
Could you clarify that in the draft?

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Half-anonymous authentication
Date: Sun, 11 Apr 2004 20:40:56 +0200
Sender: [email-masked]

Grumble.  Read through a message two times before sending, then discover
a mistake just after sending:-(

I wrote:
>   4.    Profiling requirements
>     5. A specification of how the authorization identity passed from the
>        client to the server is to be interpreted.
> 
> [ANONYMOUS] does not fulfill that requirement.

I meant, [ANONYMOUS] as currently described, or as you describe it,
does not provide such an authorization identity for the protocol to
interpret.  Even if it is not 'passed from the client', the protocol
spec needs to get an authorization identity from the SASL mechanism
in order to fulfill this requirement.

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Half-anonymous authentication
Date: Sun, 11 Apr 2004 20:33:45 +0200
Sender: [email-masked]

Kurt D. Zeilenga writes:
>At 10:33 AM 4/10/2004, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>>At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote:
>>>>Kurt D. Zeilenga writes:
>>>>> The anonymous mechanism doesn't provide any
>>>>> authentication service.  (Not all SASL mechanisms provide
>>>>> authentication services.)
>>>>
>>>> That's not what rfc2222bis says.  It describes SASL mechanisms as
>>>> authentication mechanisms, and describes everything about these in
>>>> terms of authentication.
>>>
>>> Which is a problem.  rfc2222bis should be likely use more
>>> generic terms, like "SASL mechanism" when referring to a
>>> SASL mechanism.
>>
>> rfc2222 does the same thing.
>
> RFC 2222 only once used the term "authentication mechanism".
> This was in the security consideration section,

Sorry, I should have said I looked for 'authentication' and
'authorization' in general.  In particular the term 'authentication
protocol exchange' is recurring.
E.g.:

  3.    Introduction and Overview
    The Simple Authentication and Security Layer (SASL) is a method for
    adding authentication support to connection-based protocols.
    (...)
    If a server supports the requested mechanism, it initiates an
    authentication protocol exchange.
    (...)
    During the authentication protocol exchange, the mechanism performs
    authentication, transmits an authorization identity (...)

  5.3.  Multiple authentications

  4.    Profiling requirements
    5. A specification of how the authorization identity passed from the
       client to the server is to be interpreted.

[ANONYMOUS] does not fulfill that requirement.

>> Did it incorrectly describe existing
>> implementations, or were mechanisms like ANONYMOUS added later?
>
> Often one describes features of protocols based upon what
> purpose they generally serve even though they might not
> always be used for that purpose.  See say "security layer"
> even though the feature (say data compression) may not used
> to provide non-security layer .
>
> The fact that we name these features as we do, it should be
> made clear that they do not always provide the function the
> names imply.  This should be made clear in RFC 2222.

True.  (I approached this whole thing from the point of view of a user
of a SASL library, who knows SASL but may not be aware that there are
mechanisms that do not provide what the SASL spec might make one assume
it provides.)

>> Correction: It needs to say which authentication and authorization IDs
>> it _requests_.  Or provides, or whatever is the correct term.  Hopefully
>> these IDs will be treated just like IDs from other SASL mechanisms.
>> Or like no ID (unauthenticated), if that's what the mechanism requests.
>
> ANONYMOUS doesn't request nor provide an authentication ID nor an
> authorization ID.

There has to be _some_ way to say that ANONYMOUS changes the
authentication ID, or requests a change of it, or however you wish to
say that, and what that new ID is, or that the new ID is absent, or
however you wish to say that.  Could you please provide a wording for
that which you will accept, so we can at least talk about how it relates
to the authentication ID?  Maybe just some wording to satisfy the SASL
'Profiling requirements' requirement above.

I'll hold off replying to part of your message (if a reply to the rest
still seems relevant) until then.

> Note that there could be other mechanisms would also do not
> provide such IDs to the server.

See the section from '4. Profiling requirements' quoted above.

> Consider a mechanism which
> only authenticated the server to the client.

Hmm - I suppose the mechanism could specify that the authentication ID
is the one which was already in use.

> Anyways, I think it sufficient for the mechanism to say what it
> provides (no IDs in the case of ANONYMOUS).  How that's used
> in application protocol (or implementations thereof) is simply
> beyond the scope of the mechanism specification.

Yes.

>>> It should be obvious that this mechanism does not itself
>>> establish an authentication identity nor transfer an authorization
>>> identity.  However, if more clarity is needed, I would suggest
>>> replacing the paragraph:
>>>   This mechanism does not provide a security layer.
>>> with:
>>>   This mechanism does not establish the identity of the
>>>   client (or user) nor the server (or service); does not
>>>   support transfer of an authorization identity; nor
>>>   provide a security layer.
>>
>> I think either 'It requests anonymous authentication and authorization
>> identities.
>
> I assume It == user here.

I meant it = mechanism.  Though it's on behalf of the user, if that's
what you mean.

> I'm describing what the mechanism
> establishes and not (in this paragraph) what the user may or
> may not request using this mechanism.

But 'establishes' is wrong - as you said, how any mechanism affects
authentication and authorization IDs outside of the mechanism is beyond
the scope of that mechanism.

>> How to treat the anonymous ID is up to the protocol or
>> implementation.', or 'It does not affect the authentication and
>> authorization identities'.
>
> The latter is especially dangerous

Well, I hoped that was not what it does.  Your recent messages in this
thread just made me wonder if it did.

>>>> Also, I now wonder how clients typically implement ANONYMOUS.  If they
>>>> support several SASL mechanisms, do clients expect the identity to send
>>>> with ANONYMOUS in the same command line option or whatever which they
>>>> use for the authentication IDs for other SASL mechanisms, or do they use
>>>> some other field?
>>>
>>> I suggest you look at some existing implementations.
>>
>> I don't know where to find any...
>
> Cyrus SASL?

Yes.  But a client and a server which uses the mechanism?
Anyway, I kind of hoped someone who already use SASL could tell me,
so I won't have to compile and install stuff just to find out.
The only example I know of is openldap ldapsearch.  It does not
treat auth(c/z) ID as trace ID.

>>> But
>>> I would hope the user would not be asked or expected to
>>> provide their credentials (or portions of their credentials)
>>> when using this mechanism.
>>
>> If you mean e.g. a password, I agree.
>
> I mean credentials.  Credentials may include many things...
> and generally (but not necessarily) includes a representation of
> the identity they are used to establish.  For instance, in
> PLAIN, the credentials include both a representation of
> the user's identity and a password.  The user has to know
> both to gain access as that user.

OK.

>> However, I was thinking of
>> clients that authenticate to the server
>
> Who are they authenticating?  Themselves or whatever entity is
> using the client?  SASL general function is to authenticate
> the client (or entity which is using a client) to the server.

Sure.

> It's not to authenticate the entity using the client to the
> client.
>
> This is not to say that clients cannot do that, but the
> security considerations for using SASL in this fashion are
> broad and wide.

Perhaps they should be discussed in rfc2222bis?

>> and then grant access to
>> something on the client side depending on whether or not authentication
>> succeeds.
>
> Such a client would need to treat ANONYMOUS as not establishing
> the user's entity.  Here, at least, the client can just disallow
> the mechanism.  A client which uses PLAIN, CRAM-MD5, etc., for
> such has it far worse.  They need to know which user names
> have widely known passwords or user names are granted access
> regardless of what password is provided.  How many PLAIN
> deployments out there accept any password for "anonymous"?

Do you mean such things come with the default SASL setup with some
implementations?  That sounds scary enough that it might be an idea to
warn about it in rfc2222bis.  Otherwise I don't see the problem.  The
client will authenticate against a server which it knows is set up to
authenticate the possible users of that clients.  Other user names will
not be recognized.  Except ANONYMOUS "user names", if the client treats
the trace information sent with ANONYMOUS the same way it treats user
names for other mechanisms.  Anyway, I simply wondered if clients do
that.  I hope not.

>> Or it could refuse the user to specify the ANONYMOUS
>> mechanism, of course.
>
> If a client is going to use mechanisms to authorize users
> to access services AT the client, then it needs to understand
> not only the services provided by the mechanism, but
> protocol/implementation/deployment details of the server
> it using in support of user authentication to the client.

OK.

>>> But it should be clear that anonymous methods in LDAP, FTP,
>>> and elsewhere are not authenticating the user's identity.
>>
>> In LDAP it does not authenticate.  In FTP it does, to the server.  The
>> anonymous user has the access which the filesystem grants to a specific
>> user on the filesystem.
>
> The problem with your statement, in my opinion, is the
> implication that the user's identity seeking anonymous
> access has THEIR identity authenticated.  (...)

I don't think so.

Users of shared accounts don't authenticate as THEIR identities either.

My nearest public library has the public account's username and password
taped to the public computers, so people can reboot the beasts without
running to a librarian for help.  That's not the user's identity either.

All that any SASL mechanism authenticates is that the client provided
sufficient credentials to authenticate in the manner it did.  Which is
none at all, in the ANONYMOUS case.  The administrator who allowed
that authentication is the one who knows what it means that someone
authenticated that way, and what access to grant.

-- 
Hallvard

Date: Sat, 10 Apr 2004 17:49:02 -0700
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Half-anonymous authentication
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 01:58 PM 4/10/2004, Sam Hartman wrote:
>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
>
>    Kurt> This is quite different than saying that anonymous users
>    Kurt> have established (authenticated) THEIR identity in the
>    Kurt> service.
>    >>  I don't see the difference.  IN both cases, the identity (or
>    >> non-identity) you are authorized as establishes your privileges
>    >> in the system.
>
>    Kurt> The difference is that, when using ANONYMOUS, users don't
>    Kurt> establish THEIR identity, they establish some factor in the
>    Kurt> server which allows them access without requiring that they
>    Kurt> establish THEIR identity.  
>That sort of depends on your model for identity.

I think it depends more on who is establishing what, and by what means.

When ANONYMOUS is being used, the USER is not required to establish
THEIR identity.

Whether or not the server-side mechanism implementation represents,
or how it represents, to the server-side protocol implementation that
the USER has requested access be granted on an anonymous-basis
(e.g, with requiring the USER to establish THEIR identity), as well
as how that server-side protocol implementation might then use this
information in authorization decisions is a separate (and separable)
issue.

>It seems completely reasonable to say something along the following
>lines.  Anonymous establishes the anonymous identity with no
>confidence in that identity.  IP address-based authentication
>establishes an identity based on the IP address with low confidence in
>that identity.  AUthentication by assertion establishes the asserted
>identity with low confidence in that assertion.  External
>authentication with a client TLS certificate establishes the
>SubjectName of the certificate as the identity with reasonably high
>confidence in that identity.

In the three non-anonymous examples you provide, each requires the
user to disclose its identity.  In the anonymous case, the user is not
required to disclose information its identity (though the user might
be identifiable otherwise).  So, I think, your analogy is a bit flawed.

But, what concerns me is implication that the ANONYMOUS mechanism
establishes through the exchange an identity representation that refers
users who have not established their entity.  I find that implication
misleading and confusing.  If such a representation is to be established,
it's being established by, for, and within server implementation.
That is, such is being manufactured outside of the mechanism exchange
as defined by this specification.

>Now in this working group we don't really care about the properties of
>the identity established by anonymous authentication.  For example, we
>don't care if the identities resulting from two different anonymous
>authentications compare to be equal or are guaranteed to be distinct.

I agree.

>Again, I think we are arguing about isomorphic models.
>Conceptually,believe there is an identity and some factor indicating
>whether the identity has been established.  I believe that one class
>of identity is the unestablished identity.
>
>So why am I arguing over isomorphisms?

I think we're arguing over whether "to authenticate" means
"to verify" or whether it means "to login (with our without
verification)".

SASL mechanisms are login mechanisms: some provide authenticated
login capabilities, some provide anonymous login capabilities.

>Unfortunately, the particular
>conceptual model we use seems to appear at least in part in the text
>of the base specification.

I think the base specification has problems in three areas (that
impact this discussion):

1) The base specification does not use terms consistently,
2) The base specification doesn't always define the terms it uses, and
3) The base specification is not clear that as to the range of
function that a SASL mechanism can provide.

>I believe that treating everything as
>authentication will make that base specification easier to understand
>at the cost of hiding conceptual complexity in anonymous.

To a certain degree I agree that some of the conceptual complexity
can be hidden in ANONYMOUS, excepting the base specification needs to
be clear that not everything fits the easier to understand model which
the base specification puts forth.

Anyways, in regards to the ANONYMOUS specification, I'm going to offer a
slightly revised intro text for the WG to consider here shortly.

However, I think the base specification needs work to be more easily
understood.  For instance, 2222bis uses of the terms:
        SASL authentication mechanism,
        SASL mechanism,
        authentication mechanism, and
        mechanism
generally in an interchangeable fashion.  However, in some uses in the
document where it obvious that they are not interchangeable.  This
confuses all the uses which the author used them interchangeable,
leaving a mess for the reader to decipher.

I think it would be far better if we would consistently use the term
"SASL mechanism" (and "mechanism" only where it is clear we're referring
to a SASL mechanism) as RFC 2222 generally did.  And I think we should be
more clear as to what functions SASL mechanisms generally provide
(and how some may offer vastly different functions than other mechanisms).

>I may be wrong; this may confuse people to much and be important to change.

At the moment, some readers of 2222bis are going to be confused as some
of the terminology is new and different than what was used in RFC 2222,
BUT the largest problem is that much of the terminology (new and old)
is not well-defined and/or not used consistently.

>I'm also arguing to show that this is not an editorial correction to
>the base specification.  You're proposing changing how we think about
>SASL or at least expanding an area of thought about SASL where our
>previous thinking was vague.

I don't think I am arguing that we change how we think about SASL.
I am mostly arguing that we clean up our terminology.  And I am
objecting to use of language which is not consistent with our
terminology.  Of course, "what is our terminology" is a bit of
an open question given that 2222bis does well-define our
terminology.

>Making that change is a reasonable thing
>for the working group to do, but it does need to meet a slightly
>higher bar than an editorialclarification.

Inconsistent use of poorly-defined terminology is, I think, not just
an "editorial clarification" concern, it's a general technical quality
concern.

Kurt 

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: Half-anonymous authentication
From: Sam Hartman <[email-masked]>
Date: Sat, 10 Apr 2004 16:58:21 -0400
Sender: [email-masked]

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> This is quite different than saying that anonymous users
    Kurt> have established (authenticated) THEIR identity in the
    Kurt> service.
    >>  I don't see the difference.  IN both cases, the identity (or
    >> non-identity) you are authorized as establishes your privileges
    >> in the system.

    Kurt> The difference is that, when using ANONYMOUS, users don't
    Kurt> establish THEIR identity, they establish some factor in the
    Kurt> server which allows them access without requiring that they
    Kurt> establish THEIR identity.  
That sort of depends on your model for identity.

It seems completely reasonable to say something along the following
lines.  Anonymous establishes the anonymous identity with no
confidence in that identity.  IP address-based authentication
establishes an identity based on the IP address with low confidence in
that identity.  AUthentication by assertion establishes the asserted
identity with low confidence in that assertion.  External
authentication with a client TLS certificate establishes the
SubjectName of the certificate as the identity with reasonably high
confidence in that identity.

Now in this working group we don't really care about the properties of
the identity established by anonymous authentication.  For example, we
don't care if the identities resulting from two different anonymous
authentications compare to be equal or are guaranteed to be distinct.
You probably want one of the two to be true and for most purposes you
don't care which.

Again, I think we are arguing about isomorphic models.
Conceptually,believe there is an identity and some factor indicating
whether the identity has been established.  I believe that one class
of identity is the unestablished identity.

So why am I arguing over isomorphisms?  Unfortunately, the particular
conceptual model we use seems to appear at least in part in the text
of the base specification.  I believe that treating everything as
authentication will make that base specification easier to understand
at the cost of hiding conceptual complexity in anonymous.  I may be
wrong; this may confuse people to much and be important to change.

I'm also arguing to show that this is not an editorial correction to
the base specification.  You're proposing changing how we think about
SASL or at least expanding an area of thought about SASL where our
previous thinking was vague.  Making that change is a reasonable thing
for the working group to do, but it does need to meet a slightly
higher bar than an editorialclarification.

    Kurt> Sure, a system can associate some
    Kurt> identity representation to all users which have not
    Kurt> established THEIR identity, but that imply the user has
    Kurt> established THEIR identity.

    Kurt> And, I would hope, we can agree on whether or not the system
    Kurt> does associate some identity representation to all users
    Kurt> which not established THEIR identities or not, or what that
    Kurt> identity representation might be, is completely beyond the
    Kurt> scope of this mechanism.  Just as what authorization
    Kurt> identity representation the system might associate with an
    Kurt> user who DOES establish their identity is beyond the scope
    Kurt> of the mechanism.

Agreed.

Date: Sat, 10 Apr 2004 13:47:08 -0700
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Half-anonymous authentication [corrected]
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

I need to slow down...

At 11:09 AM 4/10/2004, Sam Hartman wrote:
>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
>
>    Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote:
>    Hallvard> See above.  Also, Sam's statement that all ANONYMOUS
>    Hallvard> users have the _same_ authorization ID, not _no_
>    Hallvard> authorization ID.  Which made me realize that anonymous
>    Hallvard> auth is not a SASL term, but one I'm used to from LDAP,
>    Hallvard> where it means the same as no auth.  OTOH, FTP (at least
>    Hallvard> on Unix) implements anonymous auth the way Sam
>    Hallvard> describes: A specific user on the server's system, with
>    Hallvard> limited access.
>    >>  I think my statement is still generally true.  It may happen
>    >> that the authorization ID of anonymous users is also the same
>    >> as the authorization ID of users who have engaged in no
>    >> authentication exchange.
>
>    Kurt> But here you are talking about some authorization ID which
>    Kurt> the service merely associates with the state of being
>    Kurt> anonymous (having an unknown or concealed identity).  
>
>Agree.d
>
>    Kurt> This
>    Kurt> is quite different than saying that anonymous users have
>    Kurt> established (authenticated) THEIR identity in the service.
>
>I don't see the difference.  IN both cases, the identity (or
>non-identity) you are authorized as establishes your privileges in the
>system.

The difference is that, when using ANONYMOUS, users don't
establish THEIR identity, they establish some factor in the
server which allows them access without requiring that they
establish THEIR identity.  Sure, a system can associate
some identity representation to all users which have not
established THEIR identity, but that DOES NOT imply the
user has established THEIR identity.

And, I would hope, we can agree on whether or not the
system does associate some identity representation to
all users which not established THEIR identities or
not, or what that identity representation might be,
is completely beyond the scope of this mechanism.
Just as what authorization identity representation the
system might associate with an user who DOES establish
their identity is beyond the scope of the mechanism.

Date: Sat, 10 Apr 2004 13:25:22 -0700
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Half-anonymous authentication
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11:09 AM 4/10/2004, Sam Hartman wrote:

>>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:
>
>    Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote:
>    Hallvard> See above.  Also, Sam's statement that all ANONYMOUS
>    Hallvard> users have the _same_ authorization ID, not _no_
>    Hallvard> authorization ID.  Which made me realize that anonymous
>    Hallvard> auth is not a SASL term, but one I'm used to from LDAP,
>    Hallvard> where it means the same as no auth.  OTOH, FTP (at least
>    Hallvard> on Unix) implements anonymous auth the way Sam
>    Hallvard> describes: A specific user on the server's system, with
>    Hallvard> limited access.
>    >>  I think my statement is still generally true.  It may happen
>    >> that the authorization ID of anonymous users is also the same
>    >> as the authorization ID of users who have engaged in no
>    >> authentication exchange.
>
>    Kurt> But here you are talking about some authorization ID which
>    Kurt> the service merely associates with the state of being
>    Kurt> anonymous (having an unknown or concealed identity).  
>
>Agree.d
>
>    Kurt> This
>    Kurt> is quite different than saying that anonymous users have
>    Kurt> established (authenticated) THEIR identity in the service.
>
>I don't see the difference.  IN both cases, the identity (or
>non-identity) you are authorized as establishes your privileges in the
>system.

The difference is that, when using ANONYMOUS, users don't
establish THEIR identity, they establish some factor in the
server which allows them access without requiring that they
establish THEIR identity.  Sure, a system can associate
some identity representation to all users which have not
established THEIR identity, but that imply the user has
established THEIR identity.

And, I would hope, we can agree on whether or not the
system does associate some identity representation to
all users which not established THEIR identities or
not, or what that identity representation might be,
is completely beyond the scope of this mechanism.
Just as what authorization identity representation the
system might associate with an user who DOES establish
their identity is beyond the scope of the mechanism.

Date: Sat, 10 Apr 2004 13:03:52 -0700
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Half-anonymous authentication
Cc: Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:33 AM 4/10/2004, Hallvard B Furuseth wrote:

>Kurt D. Zeilenga writes:
>>At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote:
>>>Kurt D. Zeilenga writes:
>>>>At 09:41 AM 4/7/2004, Sam Hartman wrote:
>>>>>>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:
>>>>>
>>>> The anonymous mechanism doesn't provide any
>>>> authentication service.  (Not all SASL mechanisms provide
>>>> authentication services.)
>>>
>>> That's not what rfc2222bis says.  It describes SASL mechanisms as
>>> authentication mechanisms, and describes everything about these in
>>> terms of authentication.
>> 
>> Which is a problem.  rfc2222bis should be likely use more
>> generic terms, like "SASL mechanism" when referring to a
>> SASL mechanism.
>
>rfc2222 does the same thing.

RFC 2222 only once used the term "authentication mechanism".
This was in the security consideration section, when referring to
relative strengths of various mechanisms.  It failed to
distinguish that some mechanisms do not provide authentication
services.  That should be corrected.

Everywhere else in RFC 2222, RFC 2222 used generic terms.

>Did it incorrectly describe existing
>implementations, or were mechanisms like ANONYMOUS added later?

Often one describes features of protocols based upon what
purpose they generally serve even though they might not
always be used for that purpose.  See say "security layer"
even though the feature (say data compression) may not used
to provide non-security layer .

The fact that we name these features as we do, it should be
made clear that they do not always provide the function the
names imply.  This should be made clear in RFC 2222.

>>> One which doesn't authenticate, from what you say.
>> 
>> I would hope it obvious that ANONYMOUS does not authenticate anything.
>
>If it affects the authorization or authentication IDs, it... well,

yes.

>un-authenticates, I suppose.

I prefer to say that the ANONYMOUS mechanism, like all mechanisms,
is used to establish a new authorization state which displaces
the previous authorization state.  In particular, ANONYMOUS is
used to establish an anonymous authorization state.  That is,
the purpose of ANONYMOUS is to provide access of that of a
user without requiring the user to establish their identity.

>If it doesn't, it seems to violate rfc2222 and rfc2222bis.

I think ANONYMOUS is fairly consistent with RFC 2222 and
2222bis.  I think 2222bis needs some further clarification
here and there.

>>> However, I think the ANONYMOUS draft does need to say explicitly how it
>>> affects the authentication and authorization IDs.
>> 
>> How any mechanism affects authentication and authorization IDs
>> outside of the mechanism is beyond the scope of that mechanism.
>
>Beyond the scope of any mechanism, I think.
>
>Correction: It needs to say which authentication and authorization IDs
>it _requests_.  Or provides, or whatever is the correct term.  Hopefully
>these IDs will be treated just like IDs from other SASL mechanisms.
>Or like no ID (unauthenticated), if that's what the mechanism requests.

ANONYMOUS doesn't request nor provide an authentication ID nor an authorization ID.

Note that there could be other mechanisms would also do not
provide such IDs to the server.  Consider a mechanism which
only authenticated the server to the client.

Anyways, I think it sufficient for the mechanism to say what it
provides (no IDs in the case of ANONYMOUS).  How that's used
in application protocol (or implementations thereof) is simply
beyond the scope of the mechanism specification.

>> It should be obvious that this mechanism does not itself
>> establish an authentication identity nor transfer an authorization
>> identity.  However, if more clarity is needed, I would suggest
>> replacing the paragraph: 
>>   This mechanism does not provide a security layer.
>> with:
>>   This mechanism does not establish the identity of the
>>   client (or user) nor the server (or service); does not
>>   support transfer of an authorization identity; nor
>>   provide a security layer.
>
>I think either 'It requests anonymous authentication and authorization
>identities.

I assume It == user here.  I'm describing what the mechanism
establishes and not (in this paragraph) what the user may or
may not request using this mechanism.

>How to treat the anonymous ID is up to the protocol or
>implementation.', or 'It does not affect the authentication and
>authorization identities'.

The latter is especially dangerous because confusing between
whether we're talking about the identity established by the
user through authentication, and some identity value which
represents the user has not established THEIR identity through
authentication.

>>> Also, I now wonder how clients typically implement ANONYMOUS.  If they
>>> support several SASL mechanisms, do clients expect the identity to send
>>> with ANONYMOUS in the same command line option or whatever which they
>>> use for the authentication IDs for other SASL mechanisms, or do they use
>>> some other field?
>> 
>> I suggest you look at some existing implementations.
>
>I don't know where to find any...

Cyrus SASL?

>> But
>> I would hope the user would not be asked or expected to
>> provide their credentials (or portions of their credentials)
>> when using this mechanism.
>
>If you mean e.g. a password, I agree.

I mean credentials.  Credentials may include many things...
and generally (but not necessarily) includes a representation of
the identity they are used to establish.  For instance, in
PLAIN, the credentials include both a representation of
the user's identity and a password.  The user has to know
both to gain access as that user.

>However, I was thinking of
>clients that authenticate to the server

Who are they authenticating?  Themselves or whatever entity is
using the client?  SASL general function is to authenticate
the client (or entity which is using a client) to the server.
It's not to authenticate the entity using the client to the
client.

This is not to say that clients cannot do that, but the
security considerations for using SASL in this fashion are
broad and wide.

>and then grant access to
>something on the client side depending on whether or not authentication
>succeeds.

Such a client would need to treat ANONYMOUS as not establishing
the user's entity.  Here, at least, the client can just disallow
the mechanism.  A client which uses PLAIN, CRAM-MD5, etc., for
such has it far worse.  They need to know which user names
have widely known passwords or user names are granted access
regardless of what password is provided.  How many PLAIN
deployments out there accept any password for "anonymous"?

>Such a client must not treat the ID sent with ANONYMOUS as an
>authentication ID.

Whether the trace information provided by the client
has any semantical value to the client is beyond the
scope of the mechanism.  The mechanism is quite clear
that the email address, if provided, as no semantical
value to the mechanism and should only be used by
the server for trace purposes.

>Or it could refuse the user to specify the ANONYMOUS
>mechanism, of course.

If a client is going to use mechanisms to authorize users
to access services AT the client, then it needs to understand
not only the services provided by the mechanism, but
protocol/implementation/deployment details of the server
it using in support of user authentication to the client.

>>>> I also find it odd the implication (in Hallvard's comments) that an
>>>> anonymous user has an established identity.  I take the view that an
>>>> anonymous user is one whose's identity has not been established
>>>
>>> See above.  Also, Sam's statement that all ANONYMOUS users have the
>>> _same_ authorization ID, not _no_ authorization ID.
>> 
>> I think Sam's statement is problematic in that implies that the
>> mechanism is establishing or authenticating the user's identity.
>> The server might be associating an identity with anonymous
>> users, but the server certainly is not establishing
>> or authenticating the user's identity.
>
>I don't see why not.  The user just doesn't have anything to do with any
>information sent in the authentication requests. Instead the user is
>built into the mechanism itself.  Once it is established, it has the
>access which the server grants that user, just like with authenticated
>users.

The distinction is wether or not the mechanism is authenticating
the user's identity or whether the server-side implementation of
the mechanism is merely associating some identity representation
that indicates that the user's identity has not been established
by the mechanism.  That latter is an implementation detail.

>>> Which made me realize that anonymous auth is not a SASL term, but one
>>> I'm used to from LDAP, where it means the same as no auth.  OTOH, FTP
>>> (at least on Unix) implements anonymous auth the way Sam describes: A
>>> specific user on the server's system, with limited access.
>> 
>> But it should be clear that anonymous methods in LDAP, FTP,
>> and elsewhere are not authenticating the user's identity.
>
>In LDAP it does not authenticate.  In FTP it does, to the server.  The
>anonymous user has the access which the filesystem grants to a specific
>user on the filesystem.

The problem with your statement, in my opinion, is the
implication that the user's identity seeking anonymous
access has THEIR identity authenticated.  No, the user
seeking anonymous access is asserting a well-known account
name which grants access to anyone and everyone regardless
of what password is provided.  So, while one is going
through a login process, it is an anonymous login process.
That is, the user is not required to provide THEIR credentials
for authentication.  They are granted access without
authentication of who THEY are.

It should be clear in ANONYMOUS that there is no well-known
identity representation transferred to obtain anonymous
access nor is any particular identity representation implies
to have been transferred to the server by use of ANONYMOUS.

>>>> (or is concealed).
>>>
>>> Oh dear.  I wish you hadn't added that.
>> 
>> RFC 2828:
>>    $ anonymous
>>       (I) The condition of having a name that is unknown or concealed.
>> 
>>> Which identity do you mean?
>> 
>> The identity of the user (or a user).
>> 
>>> Authentication or authorization identity, after all?
>> 
>> Both, as they both refer to identities of users.
>> 
>>> And who is it concealed from?  The server, or other users?
>> 
>> In this case, they are concealed from (at least) the server.
>
>Uh... An authorization identity concealed to the server is not
>a concept I can quite wrap my head around.  The server grants
>access based on some specific authorization identity.
Or lack thereof.

But more to the point is that the authorization identity it
uses is something it constructs (possible directly from information
provided in the exchange).

A user can be said to be anonymous to the server if the
identity of THAT user (a particular user) is not known
to the server.  That is, the identity of the user has
been concealed by the user, the client, and the choice
of mechanism.

Hence, where a server might associate some special authorization
identity representation to all users who have not established
their identity as implying that the special identity representation
used by the server is authenticated or identifies the particular
user.

>>>> Hallvard: I'm not sure what your question is (in your last
>>>> response).  If your asking whether SASL itself or the
>>>> ANONYMOUS mechanism defines a particular identity representation
>>>> to refer to anonymous users (users which have no established
>>>> identity), I think the answer is no.  If your asking whether
>>>> SASL or ANONYMOUS explicitly provides a facility for a user
>>>> to authenticate oneself and assume the authorization of an
>>>> anonymous user, I think the answer is no.
>>>
>>> Almost...  I'm wondering if SASL even allows an authentication
>>> mechanism to revert the authentication and authorization IDs back
>>> to unauthenticated - that is, the same state as before the first
>>> authentication.
>> 
>> SASL doesn't support "revert", it supports moving to a new
>> authorization state.
>
>Replace "revert" back to "unauthenticated", then.

That would make even less sense: unauthenticate the authentication ID?

>> That new authorization state could be an anonymous one (one where the
>> identity of the user is not established (authenticated)).
>
>I can't find any place in rfc2222bis which says so.  Where?

As I said before, RFC 2222bis needs work here.  A number
of the clarifications added to RFC 2222bis are causing
confusion.  Those clarifications need refinement. 

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: Half-anonymous authentication
From: Sam Hartman <[email-masked]>
Date: Sat, 10 Apr 2004 14:09:29 -0400
Sender: [email-masked]

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> At 09:58 AM 4/10/2004, Sam Hartman wrote:
    Hallvard> See above.  Also, Sam's statement that all ANONYMOUS
    Hallvard> users have the _same_ authorization ID, not _no_
    Hallvard> authorization ID.  Which made me realize that anonymous
    Hallvard> auth is not a SASL term, but one I'm used to from LDAP,
    Hallvard> where it means the same as no auth.  OTOH, FTP (at least
    Hallvard> on Unix) implements anonymous auth the way Sam
    Hallvard> describes: A specific user on the server's system, with
    Hallvard> limited access.
    >>  I think my statement is still generally true.  It may happen
    >> that the authorization ID of anonymous users is also the same
    >> as the authorization ID of users who have engaged in no
    >> authentication exchange.

    Kurt> But here you are talking about some authorization ID which
    Kurt> the service merely associates with the state of being
    Kurt> anonymous (having an unknown or concealed identity).  

Agree.d

    Kurt> This
    Kurt> is quite different than saying that anonymous users have
    Kurt> established (authenticated) THEIR identity in the service.

I don't see the difference.  IN both cases, the identity (or
non-identity) you are authorized as establishes your privileges in the
system.

Date: Sat, 10 Apr 2004 10:38:45 -0700
To: Sam Hartman <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Half-anonymous authentication
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

At 09:58 AM 4/10/2004, Sam Hartman wrote:
>    Hallvard> See above.  Also, Sam's statement that all ANONYMOUS
>    Hallvard> users have the _same_ authorization ID, not _no_
>    Hallvard> authorization ID.  Which made me realize that anonymous
>    Hallvard> auth is not a SASL term, but one I'm used to from LDAP,
>    Hallvard> where it means the same as no auth.  OTOH, FTP (at least
>    Hallvard> on Unix) implements anonymous auth the way Sam
>    Hallvard> describes: A specific user on the server's system, with
>    Hallvard> limited access.
>
>I think my statement is still generally true.  It may happen that the
>authorization ID of anonymous users is also the same as the
>authorization ID of users who have engaged in no authentication
>exchange.

But here you are talking about some authorization ID which the
service merely associates with the state of being anonymous
(having an unknown or concealed identity).  This is quite different
than saying that anonymous users have established (authenticated)
THEIR identity in the service.

Kurt 

From: Hallvard B Furuseth <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Half-anonymous authentication
Date: Sat, 10 Apr 2004 19:33:31 +0200
Sender: [email-masked]

Kurt D. Zeilenga writes:
>At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>>At 09:41 AM 4/7/2004, Sam Hartman wrote:
>>>>>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:
>>>>
>>> The anonymous mechanism doesn't provide any
>>> authentication service.  (Not all SASL mechanisms provide
>>> authentication services.)
>>
>> That's not what rfc2222bis says.  It describes SASL mechanisms as
>> authentication mechanisms, and describes everything about these in
>> terms of authentication.
> 
> Which is a problem.  rfc2222bis should be likely use more
> generic terms, like "SASL mechanism" when referring to a
> SASL mechanism.

rfc2222 does the same thing.  Did it incorrectly describe existing
implementations, or were mechanisms like ANONYMOUS added later?

>> One which doesn't authenticate, from what you say.
> 
> I would hope it obvious that ANONYMOUS does not authenticate anything.

If it affects the authorization or authentication IDs, it... well,
un-authenticates, I suppose.  If it doesn't, it seems to violate rfc2222
and rfc2222bis.

>> However, I think the ANONYMOUS draft does need to say explicitly how it
>> affects the authentication and authorization IDs.
> 
> How any mechanism affects authentication and authorization IDs
> outside of the mechanism is beyond the scope of that mechanism.

Beyond the scope of any mechanism, I think.

Correction: It needs to say which authentication and authorization IDs
it _requests_.  Or provides, or whatever is the correct term.  Hopefully
these IDs will be treated just like IDs from other SASL mechanisms.  Or
like no ID (unauthenticated), if that's what the mechanism requests.

> It should be obvious that this mechanism does not itself
> establish an authentication identity nor transfer an authorization
> identity.  However, if more clarity is needed, I would suggest
> replacing the paragraph: 
>   This mechanism does not provide a security layer.
> with:
>   This mechanism does not establish the identity of the
>   client (or user) nor the server (or service); does not
>   support transfer of an authorization identity; nor
>   provide a security layer.

I think either 'It requests anonymous authentication and authorization
identities.  How to treat the anonymous ID is up to the protocol or
implementation.', or 'It does not affect the authentication and
authorization identities'.

>> Also, I now wonder how clients typically implement ANONYMOUS.  If they
>> support several SASL mechanisms, do clients expect the identity to send
>> with ANONYMOUS in the same command line option or whatever which they
>> use for the authentication IDs for other SASL mechanisms, or do they use
>> some other field?
> 
> I suggest you look at some existing implementations.

I don't know where to find any...

> But
> I would hope the user would not be asked or expected to
> provide their credentials (or portions of their credentials)
> when using this mechanism.

If you mean e.g. a password, I agree.  However, I was thinking of
clients that authenticate to the server and then grant access to
something on the client side depending on whether or not authentication
succeeds.  Such a client must not treat the ID sent with ANONYMOUS as an
authentication ID.  Or it could refuse the user to specify the ANONYMOUS
mechanism, of course.

>>> I also find it odd the implication (in Hallvard's comments) that an
>>> anonymous user has an established identity.  I take the view that an
>>> anonymous user is one whose's identity has not been established
>>
>> See above.  Also, Sam's statement that all ANONYMOUS users have the
>> _same_ authorization ID, not _no_ authorization ID.
> 
> I think Sam's statement is problematic in that implies that the
> mechanism is establishing or authenticating the user's identity.
> The server might be associating an identity with anonymous
> users, but the server certainly is not establishing
> or authenticating the user's identity.

I don't see why not.  The user just doesn't have anything to do with any
information sent in the authentication requests.  Instead the user is
built into the mechanism itself.  Once it is established, it has the
access which the server grants that user, just like with authenticated
users.

>> Which made me realize that anonymous auth is not a SASL term, but one
>> I'm used to from LDAP, where it means the same as no auth.  OTOH, FTP
>> (at least on Unix) implements anonymous auth the way Sam describes: A
>> specific user on the server's system, with limited access.
> 
> But it should be clear that anonymous methods in LDAP, FTP,
> and elsewhere are not authenticating the user's identity.

In LDAP it does not authenticate.  In FTP it does, to the server.  The
anonymous user has the access which the filesystem grants to a specific
user on the filesystem.

>>> (or is concealed).
>>
>> Oh dear.  I wish you hadn't added that.
> 
> RFC 2828:
>    $ anonymous
>       (I) The condition of having a name that is unknown or concealed.
> 
>> Which identity do you mean?
> 
> The identity of the user (or a user).
> 
>> Authentication or authorization identity, after all?
> 
> Both, as they both refer to identities of users.
> 
>> And who is it concealed from?  The server, or other users?
> 
> In this case, they are concealed from (at least) the server.

Uh... An authorization identity concealed to the server is not
a concept I can quite wrap my head around.  The server grants
access based on some specific authorization identity.

>>> Hallvard: I'm not sure what your question is (in your last
>>> response).  If your asking whether SASL itself or the
>>> ANONYMOUS mechanism defines a particular identity representation
>>> to refer to anonymous users (users which have no established
>>> identity), I think the answer is no.  If your asking whether
>>> SASL or ANONYMOUS explicitly provides a facility for a user
>>> to authenticate oneself and assume the authorization of an
>>> anonymous user, I think the answer is no.
>>
>> Almost...  I'm wondering if SASL even allows an authentication
>> mechanism to revert the authentication and authorization IDs back
>> to unauthenticated - that is, the same state as before the first
>> authentication.
> 
> SASL doesn't support "revert", it supports moving to a new
> authorization state.

Replace "revert" back to "unauthenticated", then.

> That new authorization state could be an anonymous one (one where the
> identity of the user is not established (authenticated)).

I can't find any place in rfc2222bis which says so.  Where?

>> But perhaps it would be problematic if the did,
>> since it would mess up for protocols that require authentication.
> 
> ANONYMOUS allows protocols which previously required authentication
> of the user to support processing without authentication of the
> user.  That is, it allows the "authenticate" command to be used
> in a fashion which doesn't actually authenticate anything.

-- 
Hallvard

To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: Half-anonymous authentication
From: Sam Hartman <[email-masked]>
Date: Sat, 10 Apr 2004 13:00:01 -0400
Sender: [email-masked]

>>>>> "Kurt" == Kurt D Zeilenga <[email-masked]> writes:

    Kurt> Which is a problem.  rfc2222bis should be likely use more
    Kurt> generic terms, like "SASL mechanism" when referring to a
    Kurt> SASL mechanism.

I don't tend to agree with this.  IT seems that viewing anonymous
authentication as authentication is a smaller change at this date than
assuming not all SASL mechanisms authenticate.

>From a practical standpoint, I believe they are isomorphic models.
Should I would prefer to choose the model that is most consistent with
our documents.

--Sam

To: Hallvard B Furuseth <[email-masked]>
Cc: "Kurt D. Zeilenga" <[email-masked]>, [email-masked]
Subject: Re: Half-anonymous authentication
From: Sam Hartman <[email-masked]>
Date: Sat, 10 Apr 2004 12:58:01 -0400
Sender: [email-masked]

    Hallvard> See above.  Also, Sam's statement that all ANONYMOUS
    Hallvard> users have the _same_ authorization ID, not _no_
    Hallvard> authorization ID.  Which made me realize that anonymous
    Hallvard> auth is not a SASL term, but one I'm used to from LDAP,
    Hallvard> where it means the same as no auth.  OTOH, FTP (at least
    Hallvard> on Unix) implements anonymous auth the way Sam
    Hallvard> describes: A specific user on the server's system, with
    Hallvard> limited access.

I think my statement is still generally true.  It may happen that the
authorization ID of anonymous users is also the same as the
authorization ID of users who have engaged in no authentication
exchange.

It may be the case (and generally is) that the authorization ID of
anonymous users cannot be represented as a string transmitted over the
wire.

--Sam

Date: Sat, 10 Apr 2004 09:12:40 -0700
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Half-anonymous authentication
Cc: Sam Hartman <[email-masked]>, [email-masked]
Sender: [email-masked]

At 07:53 AM 4/10/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 09:41 AM 4/7/2004, Sam Hartman wrote:
>> 
>>>>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:
>>>
>>>    Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see
>>>    Hallvard> that a mechanism may make either ID anonymous at all.
>>>    Hallvard> It was just so "obvious" that it could do so, that I
>>>    Hallvard> didn't notice that it couldn't.  Anyway, is that
>>>    Hallvard> intended?
>>>
>>>I believe the authorization ID of all users authenticated using the
>>>anonymous mechanism is the same.
>> 
>> "users authenticated using the anonymous mechanism", I think,
>> is a odd phrase.  The anonymous mechanism doesn't provide any
>> authentication service.  (Not all SASL mechanisms provide
>> authentication services.)
>
>That's not what rfc2222bis says.  It describes SASL mechanisms as
>authentication mechanisms, and describes everything about these in terms
>of authentication.

Which is a problem.  rfc2222bis should be likely use more
generic terms, like "SASL mechanism" when referring to a
SASL mechanism.

>So according to rfc2222bis, ANONYMOUS is an authentication mechanism.

rfc2222bis shouldn't imply that all SASL mechanisms provide
authentication services.

>One which doesn't authenticate, from what you say.

I would hope it obvious that ANONYMOUS does not authenticate anything.

>Anyway, at first I thought this meant the identity sent with ANONYMOUS
>had to be the authentication ID, but I now notice that this is wrong.

The only information ANONYMOUS transfers is for trace purposes.
It has no semantical value to the mechanism.

>However, I think the ANONYMOUS draft does need to say explicitly how it
>affects the authentication and authorization IDs.

How any mechanism affects authentication and authorization IDs
outside of the mechanism is beyond the scope of that mechanism.
It should be obvious that this mechanism does not itself
establish an authentication identity nor transfer an authorization
identity.  However, if more clarity is needed, I would suggest
replacing the paragraph: 
  This mechanism does not provide a security layer.
with:
  This mechanism does not establish the identity of the
  client (or user) nor the server (or service); does not
  support transfer of an authorization identity; nor
  provide a security layer.

and relocate this paragraph more towards the top of the section.

>Also, I now wonder how clients typically implement ANONYMOUS.  If they
>support several SASL mechanisms, do clients expect the identity to send
>with ANONYMOUS in the same command line option or whatever which they
>use for the authentication IDs for other SASL mechanisms, or do they use
>some other field?

I suggest you look at some existing implementations.  But
I would hope the user would not be asked or expected to
provide their credentials (or portions of their credentials)
when using this mechanism.

>Anyway, 
>
>> I also find it odd the implication (in Hallvard's comments) that an
>> anonymous user has an established identity.  I take the view that an
>> anonymous user is one whose's identity has not been established
>
>See above.  Also, Sam's statement that all ANONYMOUS users have the
>_same_ authorization ID, not _no_ authorization ID.

I think Sam's statement is problematic in that implies that the
mechanism is establishing or authenticating the user's identity.
The server might be associating an identity with anonymous
users, but the server certainly is not establishing
or authenticating the user's identity.

>Which made me realize that anonymous auth is not a SASL term, but one I'm used to from
>LDAP, where it means the same as no auth.  OTOH, FTP (at least on Unix)
>implements anonymous auth the way Sam describes: A specific user on the
>server's system, with limited access.

But it should be clear that anonymous methods in LDAP, FTP,
and elsewhere are not authenticating the user's identity.

>> (or is concealed).
>
>Oh dear.  I wish you hadn't added that.

RFC 2828:
   $ anonymous
      (I) The condition of having a name that is unknown or concealed.

>Which identity do you mean?

The identity of the user (or a user).

>Authentication or authorization identity, after all?

Both, as they both refer to identities of users.

>And who is it concealed from?  The server, or other users?

In this case, they are concealed from (at least) the server.

>> Hallvard: I'm not sure what your question is (in your last
>> response).  If your asking whether SASL itself or the
>> ANONYMOUS mechanism defines a particular identity representation
>> to refer to anonymous users (users which have no established
>> identity), I think the answer is no.  If your asking whether
>> SASL or ANONYMOUS explicitly provides a facility for a user
>> to authenticate oneself and assume the authorization of an
>> anonymous user, I think the answer is no.
>
>Almost...  I'm wondering if SASL even allows an authentication
>mechanism to revert the authentication and authorization IDs back
>to unauthenticated - that is, the same state as before the first
>authentication.

SASL doesn't support "revert", it supports moving to a new
authorization state.  That new authorization state could be
an anonymous one (one where the identity of the user is not
established (authenticated)).

>But perhaps it would be problematic if the did,
>since it would mess up for protocols that require authentication.

ANONYMOUS allows protocols which previously required authentication
of the user to support processing without authentication of the
user.  That is, it allows the "authenticate" command to be used
in a fashion which doesn't actually authenticate anything.

Which, BTW,
>(BTW, note the command 'A002 AUTHENTICATE ANONYMOUS' in the
>example in the ANONYMOUS draft.)

is what's happening here.  This AUTHENTICATE command does not
cause anything to be authenticated.

>Maybe an 'anonymous user' is a better concept, which protocols
>can treat either the same way as unauthenticated or as a normal
>user with limited access.
>
>> I note, nothing explicitly prevents application protocol
>> specifications from providing such facilities, including
>> by means of defining a particular identity representation
>> to refer to users who have not established their identity.
>
>-- 
>Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: Half-anonymous authentication
Date: Sat, 10 Apr 2004 16:53:53 +0200
Sender: [email-masked]

Kurt D. Zeilenga writes:
>At 09:41 AM 4/7/2004, Sam Hartman wrote:
> 
>>>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:
>>
>>    Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see
>>    Hallvard> that a mechanism may make either ID anonymous at all.
>>    Hallvard> It was just so "obvious" that it could do so, that I
>>    Hallvard> didn't notice that it couldn't.  Anyway, is that
>>    Hallvard> intended?
>>
>>I believe the authorization ID of all users authenticated using the
>>anonymous mechanism is the same.
> 
> "users authenticated using the anonymous mechanism", I think,
> is a odd phrase.  The anonymous mechanism doesn't provide any
> authentication service.  (Not all SASL mechanisms provide
> authentication services.)

That's not what rfc2222bis says.  It describes SASL mechanisms as
authentication mechanisms, and describes everything about these in terms
of authentication.  So according to rfc2222bis, ANONYMOUS is an
authentication mechanism.  One which doesn't authenticate, from what you
say.  (BTW, note the command 'A002 AUTHENTICATE ANONYMOUS' in the
example in the ANONYMOUS draft.)

Anyway, at first I thought this meant the identity sent with ANONYMOUS
had to be the authentication ID, but I now notice that this is wrong.

However, I think the ANONYMOUS draft does need to say explicitly how it
affects the authentication and authorization IDs.

Also, I now wonder how clients typically implement ANONYMOUS.  If they
support several SASL mechanisms, do clients expect the identity to send
with ANONYMOUS in the same command line option or whatever which they
use for the authentication IDs for other SASL mechanisms, or do they use
some other field?

Anyway, 

> I also find it odd the implication (in Hallvard's comments) that an
> anonymous user has an established identity.  I take the view that an
> anonymous user is one whose's identity has not been established

See above.  Also, Sam's statement that all ANONYMOUS users have the
_same_ authorization ID, not _no_ authorization ID.  Which made me
realize that anonymous auth is not a SASL term, but one I'm used to from
LDAP, where it means the same as no auth.  OTOH, FTP (at least on Unix)
implements anonymous auth the way Sam describes: A specific user on the
server's system, with limited access.

> (or is concealed).

Oh dear.  I wish you hadn't added that.  Which identity do you mean?
Authentication or authorization identity, after all?  And who is
it concealed from?  The server, or other users?

> Hallvard: I'm not sure what your question is (in your last
> response).  If your asking whether SASL itself or the
> ANONYMOUS mechanism defines a particular identity representation
> to refer to anonymous users (users which have no established
> identity), I think the answer is no.  If your asking whether
> SASL or ANONYMOUS explicitly provides a facility for a user
> to authenticate oneself and assume the authorization of an
> anonymous user, I think the answer is no.

Almost...  I'm wondering if SASL even allows an authentication
mechanism to revert the authentication and authorization IDs back
to unauthenticated - that is, the same state as before the first
authentication.  But perhaps it would be problematic if the did,
since it would mess up for protocols that require authentication.
Maybe an 'anonymous user' is a better concept, which protocols
can treat either the same way as unauthenticated or as a normal
user with limited access.

> I note, nothing explicitly prevents application protocol
> specifications from providing such facilities, including
> by means of defining a particular identity representation
> to refer to users who have not established their identity.

-- 
Hallvard

Date: Fri, 09 Apr 2004 17:06:16 -0700
To: Sam Hartman <[email-masked]>, Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Half-anonymous authentication
Cc: [email-masked]
Sender: [email-masked]

At 09:41 AM 4/7/2004, Sam Hartman wrote:

>>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:
>
>    Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see
>    Hallvard> that a mechanism may make either ID anonymous at all.
>    Hallvard> It was just so "obvious" that it could do so, that I
>    Hallvard> didn't notice that it couldn't.  Anyway, is that
>    Hallvard> intended?
>
>I believe the authorization ID of all users authenticated using the
>anonymous mechanism is the same.

"users authenticated using the anonymous mechanism", I think,
is a odd phrase.  The anonymous mechanism doesn't provide any
authentication service.  (Not all SASL mechanisms provide
authentication services.)  I also find it odd the implication
(in Hallvard's comments) that an anonymous user has an
established identity.  I take the view that an anonymous user
is one whose's identity has not been established (or is
concealed).

While some implementations (and maybe even some application
protocols) might associate a particular identity representation
to users who are anonymous (have no established identity), this
by no means implies that anonymous mechanism establishes
(authenticates) the identity of the user.  It doesn't.

Hallvard: I'm not sure what your question is (in your last
response).  If your asking whether SASL itself or the
ANONYMOUS mechanism defines a particular identity representation
to refer to anonymous users (users which have no established
identity), I think the answer is no.  If your asking whether
SASL or ANONYMOUS explicitly provides a facility for a user
to authenticate oneself and assume the authorization of an
anonymous user, I think the answer is no.

I note, nothing explicitly prevents application protocol
specifications from providing such facilities, including
by means of defining a particular identity representation
to refer to users who have not established their identity.

Kurt 

Date: Fri, 09 Apr 2004 13:53:39 -0700
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Family of mechanism (Was: draft-ietf-sasl-crammd5-02 / additional mechanisms ?)
Cc: [email-masked]
Sender: [email-masked]

At 03:54 AM 4/9/2004, Simon Josefsson wrote:
>One idea for solving this problem would be to make the SASL mechanism
>family matter purely an IETF/IANA procedural matter, and not an
>intrinsic part of the SASL protocol. 

It should be clear in the revised SASL base specification,
if not already so, that families of mechanisms is purely a
name space matter.  To the protocol, each name/mechanism
is independent of all other name/mechanism pairs.

Kurt

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ?
Date: Fri, 09 Apr 2004 22:37:33 +0200
Lines: 49
Cancel-Lock: sha1:w3uSLJKW9MRW3uxSLUDknYXVXV4=
Sender: [email-masked]

Tino Reichardt <[email-masked]> writes:

>> But the code that selects the proper module to implement a specific
>> SASL mechanism, based on a family name, will be more complicated than
>> it was in 2222.  To use GSS as an example (since there is a
>> specification for it, so we can get into details), to be flexible the
>> SASL library would have to recognize the "GSS-" prefix, and load
>> e.g. libgsasl-gss.so, which in turn loads the GSS implementation,
>> iterates over all supported GSS mechanisms (which can change over
>> time, without the SASL library knowing about it), compute the
>> truncated MD5 and check whether it match the GSS-<B32DATA> string.
>> Compare this to the 2222 approach, where you load (e.g.)
>> libgsasl-<SASLMECHANISMNAME>.so and that's it.
>
> The applications should just load what they need to support some
> special typ of SASL mechanism. But such a implementation can't be the
> reason for not specifying new mechanisms.

Right, the argument was a reason for not introducing SASL mechanism
families at all, at least not as a protocol matter, in 2222bis.  Don't
take it as criticism of your idea specifically, it wasn't meant as
such.  Your idea just made me think of the general topic of SASL
mechanism families.

>> Yes.  Or, if 2222bis is approved with SASL mechanism families, you can
>> write a document for the entire CRAM-* family, if you make sure it
>> doesn't collide with CRAM-MD5.
>
> HMAC-SHA1 and HMAC-RIPEMD is also spcified in rfc 2104. So why
> shouldn't CRAM-SHA1 + CRAM-RIPEMD be mentioned in a new CRAM-MD5 rfc ?
> Maybe the name isn't the best one than - okay :)

As Kurt Zeilenga said, the agenda for CRAM-MD5 is rather limited.
Delaying it further because it can be generalized, does not sound like
a good idea to me.  This doesn't mean you can't work on CRAM-* in
parallel though, and since you quoted existing software that uses it,
having it documented and registered with IANA would be a good idea.
The document for CRAM-* could begin by explaining what the technical
motivations for developing it was.  At least I'm curious about that.
(Don't you trust MD5?  Is the code size of MD5 too large?  Etc.)

>> It appears as if a document describing CRAM-SHA1 would be a useful
>> contribution.  You can add a link to it on the IANA SASL page.
> Who?

See http://www.iana.org/assignments/sasl-mechanisms

Regards,
Simon

Date: Fri, 9 Apr 2004 22:29:54 +0200
From: Tino Reichardt <[email-masked]>
To: [email-masked]
Subject: Re: [corrected] Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ?
Reply-To: Tino Reichardt <[email-masked]>
Mail-Followup-To: Tino Reichardt <[email-masked]>, [email-masked]
Sender: [email-masked]

* "Kurt D. Zeilenga" <[email-masked]> wrote:
> 
> My previous note had a few unfortunate typos in it.  This should be
> more clear.  Sorry for any confusion. -- Kurt
No problem :)

> Tino,
> 
> The SASL WG's CRAM-MD5 work item is limited to revising the SASL
> CRAM-MD5 authentication mechanism.  Engineering of other CRAM-based
> mechanisms is simply beyond the scope of this working group.  I
> suggest you pursue the specification of other mechanisms on an
> individual basis.
Okay, I will do so.

> 
> I do note that this list is an acceptable forum for review of
> SASL-related submissions produced by individuals (as long as
> such review does not impede progress on WG deliverables).
Sorry, if I was to pertly :)

-- 
regards, TR

Date: Fri, 09 Apr 2004 12:41:41 -0700
To: Tino Reichardt <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: [corrected] Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ?
Cc: [email-masked]
Sender: [email-masked]

My previous note had a few unfortunate typos in it.  This should be
more clear.  Sorry for any confusion. -- Kurt

Tino,

The SASL WG's CRAM-MD5 work item is limited to revising the SASL
CRAM-MD5 authentication mechanism.  Engineering of other CRAM-based
mechanisms is simply beyond the scope of this working group.  I
suggest you pursue the specification of other mechanisms on an
individual basis.

I do note that this list is an acceptable forum for review of
SASL-related submissions produced by individuals (as long as
such review does not impede progress on WG deliverables).

Regards, Kurt (as co-chair of the SASL-WG)

At 03:26 AM 4/8/2004, Tino Reichardt wrote:

>Hello ietf-sasl list.
>
>First of all: my english isn't the best and I am new to this list.
>
>I think the draft 'The CRAM-MD5 SASL Mechanism' should not only
>specify the CRAM-MD5 mechanism.
>Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar
>and then specify also some other standard hash routines as SASL CRAM
>mechanisms:
>
>: CRAM-MD5
>160bit: CRAM-SHA1
>160bit: CRAM-RIPEMD-160
>320bit: CRAM-RIPEMD-320
>
>
>ps: The CRAM-SHA1 mechanism is already used by serveral servers and
>    clients.
>
>
>references:
>
>[SHA1]   http://www.itl.nist.gov/fipspubs/fip180-1.htm
>[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html
>
>
>-- 
>regards, TR

Date: Fri, 09 Apr 2004 11:41:52 -0700
To: Tino Reichardt <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ?
Cc: [email-masked]
Sender: [email-masked]

Tino,

The WG CRAM-MD5 work item is limited to revising the SASL CRAM-MD5
authentication mechanism.  Engineering of other CRAM-based
mechanisms is simply beyond the scope of the working group.  I
suggest you pursue the specification of other mechanisms on an
individual basis.

I do not that this list is an acceptable forum for review of
SASL-related submissions produced by individuals (as long as
such review does not impede progress on WG deliverables).

Regards, Kurt (as co-chair of the SASL-WG)

At 03:26 AM 4/8/2004, Tino Reichardt wrote:

>Hello ietf-sasl list.
>
>First of all: my english isn't the best and I am new to this list.
>
>I think the draft 'The CRAM-MD5 SASL Mechanism' should not only
>specify the CRAM-MD5 mechanism.
>Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar
>and then specify also some other standard hash routines as SASL CRAM
>mechanisms:
>
>: CRAM-MD5
>160bit: CRAM-SHA1
>160bit: CRAM-RIPEMD-160
>320bit: CRAM-RIPEMD-320
>
>
>ps: The CRAM-SHA1 mechanism is already used by serveral servers and
>    clients.
>
>
>references:
>
>[SHA1]   http://www.itl.nist.gov/fipspubs/fip180-1.htm
>[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html
>
>
>-- 
>regards, TR

Date: Fri, 9 Apr 2004 19:45:34 +0200
From: Tino Reichardt <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ?
Reply-To: Tino Reichardt <[email-masked]>
Mail-Followup-To: Tino Reichardt <[email-masked]>, [email-masked]
Sender: [email-masked]

* Simon Josefsson <[email-masked]> wrote:
> 
> Tino Reichardt <[email-masked]> writes:
> 
> > * Simon Josefsson <[email-masked]> wrote:
> >> 
> >> Tino Reichardt <[email-masked]> writes:
> >> 
> >> > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only
> >> > specify the CRAM-MD5 mechanism.
> >> > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar
> >> > and then specify also some other standard hash routines as SASL CRAM
> >> > mechanisms:
> >> >
> >> > : CRAM-MD5
> >> > 160bit: CRAM-SHA1
> >> > 160bit: CRAM-RIPEMD-160
> >> > 320bit: CRAM-RIPEMD-320
> >> 
> >> For what it's worth, I'm not convinced this is a good idea.  Unless
> >> there is something wrong with the authentication part of CRAM-MD5, it
> >> would only decrease interoperability if variations were added.
> >> Especially considering that a stored, non-plain, password database is
> >> not compatible across hash functions.
> > This is true ... can you tell me applications where contexts are
> > stored ?
> 
> I believe Cyrus SASL has a mode in which it doesn't store plain-text
> passwords, only mechanism specific contexts.  I'm sure other
> implementations can do the same.
Okay, but for SMTP + POP3 servers doesn't that matter, because the
initial server response differs every time ...
So storing contexts here, makes no sense. As far as I know - Maybe I
am on the wrong track :)

> 
> >> Further, I dislike SASL mechanism families.  This also applies to the
> >> new GSS-API mechanisms.  It is a change compared to 2222, and it makes
> >> the generic parts of a SASL library needlessly complicated (think
> >> dynamically loading the proper SASL module based on SASL mechanism
> >> name).
> > Do you think on a special application ? Who loads what dynamically ?
> > Adding SHA1 + RIPEMD hash algorithms to an application isn't very
> > complex... just see [QPASSWD].
> 
> This was a generic comment, not specific to CRAM-*.  Adding code for
> SHA1/RIPEMD is easy, I agree.
> 
> But the code that selects the proper module to implement a specific
> SASL mechanism, based on a family name, will be more complicated than
> it was in 2222.  To use GSS as an example (since there is a
> specification for it, so we can get into details), to be flexible the
> SASL library would have to recognize the "GSS-" prefix, and load
> e.g. libgsasl-gss.so, which in turn loads the GSS implementation,
> iterates over all supported GSS mechanisms (which can change over
> time, without the SASL library knowing about it), compute the
> truncated MD5 and check whether it match the GSS-<B32DATA> string.
> Compare this to the 2222 approach, where you load (e.g.)
> libgsasl-<SASLMECHANISMNAME>.so and that's it.

The applications should just load what they need to support some
special typ of SASL mechanism. But such a implementation can't be the
reason for not specifying new mechanisms.
They have to load for every new SASL mechanism another library, when
it doesn't work another way.  Maybe the concept of those
implementations is wrong, because when I want to by a car, I don't
choose the tires first and then the car, which has to fit to them.

> 
> One idea for solving this problem would be to make the SASL mechanism
> family matter purely an IETF/IANA procedural matter, and not an
> intrinsic part of the SASL protocol.  I mean, the GSS SASL mechanism
> should not imply that an implementation should go through the above
> procedure in order to find the proper GSS mechanism to use, but that
> each GSS mechanism to be used within SASL is registered as such, using
> the truncated MD5 as the registered name, and only after that should
> SASL implementations be assumed to recognize it automatically.  (Of
> course, we can't stop implementations from recognizing non-standard
> SASL mechanisms, perhaps by implementing the above algorithm.)

Hm...

> >> Still, nothing prevents you from register CRAM-SHA1 at IANA, write
> >> your own specification, and using it.  But, to re-iterate, I believe
> >> it isn't useful to change the current CRAM-MD5 document into a CRAM-*
> >> family.  If you need a SASL mechanism that can use other hashes, have
> >> a look at GSS-*, or perhaps KERBEROS_V5.
> > Okay, we need for every good hash a good draft ?
> 
> Yes.  Or, if 2222bis is approved with SASL mechanism families, you can
> write a document for the entire CRAM-* family, if you make sure it
> doesn't collide with CRAM-MD5.

HMAC-SHA1 and HMAC-RIPEMD is also spcified in rfc 2104. So why
shouldn't CRAM-SHA1 + CRAM-RIPEMD be mentioned in a new CRAM-MD5 rfc ?
Maybe the name isn't the best one than - okay :)

> It appears as if a document describing CRAM-SHA1 would be a useful
> contribution.  You can add a link to it on the IANA SASL page.
Who?

-- 
regards, TR

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ?
Date: Fri, 09 Apr 2004 12:54:05 +0200
Lines: 103
Cancel-Lock: sha1:LICyAxXKMJ2RG80AW0HISuHUHx8=
Sender: [email-masked]

Tino Reichardt <[email-masked]> writes:

> * Simon Josefsson <[email-masked]> wrote:
>> 
>> Tino Reichardt <[email-masked]> writes:
>> 
>> > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only
>> > specify the CRAM-MD5 mechanism.
>> > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar
>> > and then specify also some other standard hash routines as SASL CRAM
>> > mechanisms:
>> >
>> > : CRAM-MD5
>> > 160bit: CRAM-SHA1
>> > 160bit: CRAM-RIPEMD-160
>> > 320bit: CRAM-RIPEMD-320
>> 
>> For what it's worth, I'm not convinced this is a good idea.  Unless
>> there is something wrong with the authentication part of CRAM-MD5, it
>> would only decrease interoperability if variations were added.
>> Especially considering that a stored, non-plain, password database is
>> not compatible across hash functions.
> This is true ... can you tell me applications where contexts are
> stored ?

I believe Cyrus SASL has a mode in which it doesn't store plain-text
passwords, only mechanism specific contexts.  I'm sure other
implementations can do the same.

>> Further, I dislike SASL mechanism families.  This also applies to the
>> new GSS-API mechanisms.  It is a change compared to 2222, and it makes
>> the generic parts of a SASL library needlessly complicated (think
>> dynamically loading the proper SASL module based on SASL mechanism
>> name).
> Do you think on a special application ? Who loads what dynamically ?
> Adding SHA1 + RIPEMD hash algorithms to an application isn't very
> complex... just see [QPASSWD].

This was a generic comment, not specific to CRAM-*.  Adding code for
SHA1/RIPEMD is easy, I agree.

But the code that selects the proper module to implement a specific
SASL mechanism, based on a family name, will be more complicated than
it was in 2222.  To use GSS as an example (since there is a
specification for it, so we can get into details), to be flexible the
SASL library would have to recognize the "GSS-" prefix, and load
e.g. libgsasl-gss.so, which in turn loads the GSS implementation,
iterates over all supported GSS mechanisms (which can change over
time, without the SASL library knowing about it), compute the
truncated MD5 and check whether it match the GSS-<B32DATA> string.
Compare this to the 2222 approach, where you load (e.g.)
libgsasl-<SASLMECHANISMNAME>.so and that's it.

One idea for solving this problem would be to make the SASL mechanism
family matter purely an IETF/IANA procedural matter, and not an
intrinsic part of the SASL protocol.  I mean, the GSS SASL mechanism
should not imply that an implementation should go through the above
procedure in order to find the proper GSS mechanism to use, but that
each GSS mechanism to be used within SASL is registered as such, using
the truncated MD5 as the registered name, and only after that should
SASL implementations be assumed to recognize it automatically.  (Of
course, we can't stop implementations from recognizing non-standard
SASL mechanisms, perhaps by implementing the above algorithm.)

>> Still, nothing prevents you from register CRAM-SHA1 at IANA, write
>> your own specification, and using it.  But, to re-iterate, I believe
>> it isn't useful to change the current CRAM-MD5 document into a CRAM-*
>> family.  If you need a SASL mechanism that can use other hashes, have
>> a look at GSS-*, or perhaps KERBEROS_V5.
> Okay, we need for every good hash a good draft ?

Yes.  Or, if 2222bis is approved with SASL mechanism families, you can
write a document for the entire CRAM-* family, if you make sure it
doesn't collide with CRAM-MD5.

>> > ps: The CRAM-SHA1 mechanism is already used by serveral servers and
>> >     clients.
>> 
>> Do you have any pointers?
> Not much, but since it isn't mentioned in any standard:
>
> Hamster SMTP+POP3+NNTP Server/Client:
> http://www.tglsoft.de/misc/hamster_en.htm
>
> Cone Mail Client:
> http://www.courier-mta.org/cone/cone00index.html
>
> Radius Server:
> http://www.freeradius.org
> (http://www.freeradius.org/radiusd/doc/ChangeLog)
>
> also:
> - courier-imapd
> - postfix
>
>
> [QPASSWD] http://www.mcmilk.de/projects/qpasswd/

It appears as if a document describing CRAM-SHA1 would be a useful
contribution.  You can add a link to it on the IANA SASL page.

Regards,
Simon

Date: Fri, 9 Apr 2004 09:38:08 +0200
From: Tino Reichardt <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ?
Reply-To: Tino Reichardt <[email-masked]>
Mail-Followup-To: Tino Reichardt <[email-masked]>, [email-masked]
Sender: [email-masked]

* Simon Josefsson <[email-masked]> wrote:
> 
> Tino Reichardt <[email-masked]> writes:
> 
> > I think the draft 'The CRAM-MD5 SASL Mechanism' should not only
> > specify the CRAM-MD5 mechanism.
> > Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar
> > and then specify also some other standard hash routines as SASL CRAM
> > mechanisms:
> >
> > : CRAM-MD5
> > 160bit: CRAM-SHA1
> > 160bit: CRAM-RIPEMD-160
> > 320bit: CRAM-RIPEMD-320
> 
> For what it's worth, I'm not convinced this is a good idea.  Unless
> there is something wrong with the authentication part of CRAM-MD5, it
> would only decrease interoperability if variations were added.
> Especially considering that a stored, non-plain, password database is
> not compatible across hash functions.
This is true ... can you tell me applications where contexts are
stored ?

> 
> Further, I dislike SASL mechanism families.  This also applies to the
> new GSS-API mechanisms.  It is a change compared to 2222, and it makes
> the generic parts of a SASL library needlessly complicated (think
> dynamically loading the proper SASL module based on SASL mechanism
> name).
Do you think on a special application ? Who loads what dynamically ?
Adding SHA1 + RIPEMD hash algorithms to an application isn't very
complex... just see [QPASSWD].

> 
> Still, nothing prevents you from register CRAM-SHA1 at IANA, write
> your own specification, and using it.  But, to re-iterate, I believe
> it isn't useful to change the current CRAM-MD5 document into a CRAM-*
> family.  If you need a SASL mechanism that can use other hashes, have
> a look at GSS-*, or perhaps KERBEROS_V5.
Okay, we need for every good hash a good draft ?

> 
> > ps: The CRAM-SHA1 mechanism is already used by serveral servers and
> >     clients.
> 
> Do you have any pointers?
Not much, but since it isn't mentioned in any standard:

Hamster SMTP+POP3+NNTP Server/Client:
http://www.tglsoft.de/misc/hamster_en.htm

Cone Mail Client:
http://www.courier-mta.org/cone/cone00index.html

Radius Server:
http://www.freeradius.org
(http://www.freeradius.org/radiusd/doc/ChangeLog)

also:
- courier-imapd
- postfix

[QPASSWD] http://www.mcmilk.de/projects/qpasswd/

-- 
regards, TR

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ?
Date: Thu, 08 Apr 2004 23:22:28 +0200
Lines: 38
Cancel-Lock: sha1:yPsGiWO39gDyhgw2Q376kQO4L8w=
Sender: [email-masked]

Tino Reichardt <[email-masked]> writes:

> I think the draft 'The CRAM-MD5 SASL Mechanism' should not only
> specify the CRAM-MD5 mechanism.
> Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar
> and then specify also some other standard hash routines as SASL CRAM
> mechanisms:
>
> : CRAM-MD5
> 160bit: CRAM-SHA1
> 160bit: CRAM-RIPEMD-160
> 320bit: CRAM-RIPEMD-320

For what it's worth, I'm not convinced this is a good idea.  Unless
there is something wrong with the authentication part of CRAM-MD5, it
would only decrease interoperability if variations were added.
Especially considering that a stored, non-plain, password database is
not compatible across hash functions.

Further, I dislike SASL mechanism families.  This also applies to the
new GSS-API mechanisms.  It is a change compared to 2222, and it makes
the generic parts of a SASL library needlessly complicated (think
dynamically loading the proper SASL module based on SASL mechanism
name).

Still, nothing prevents you from register CRAM-SHA1 at IANA, write
your own specification, and using it.  But, to re-iterate, I believe
it isn't useful to change the current CRAM-MD5 document into a CRAM-*
family.  If you need a SASL mechanism that can use other hashes, have
a look at GSS-*, or perhaps KERBEROS_V5.

> ps: The CRAM-SHA1 mechanism is already used by serveral servers and
>     clients.

Do you have any pointers?

Thanks,
Simon

Date: Thu, 08 Apr 2004 16:43:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Tino Reichardt <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-sasl-crammd5-02 / additional mechanisms ?
Sender: [email-masked]

Tino Reichardt wrote:

>Hello ietf-sasl list.
>
>First of all: my english isn't the best and I am new to this list.
>
>I think the draft 'The CRAM-MD5 SASL Mechanism' should not only
>specify the CRAM-MD5 mechanism.
>Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar
>and then specify also some other standard hash routines as SASL CRAM
>mechanisms:
>
>: CRAM-MD5
>160bit: CRAM-SHA1
>160bit: CRAM-RIPEMD-160
>320bit: CRAM-RIPEMD-320
>
I am afraid documenting those is outside of the scope for this working 
group.
However you can contact me offline if you want to document this/help out 
to document this.

>ps: The CRAM-SHA1 mechanism is already used by serveral servers and
>    clients.
>
>
>references:
>
>[SHA1]   http://www.itl.nist.gov/fipspubs/fip180-1.htm
>[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html
>  
>
Regards,
Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

Date: Thu, 8 Apr 2004 12:26:01 +0200
From: Tino Reichardt <[email-masked]>
To: [email-masked]
Subject: draft-ietf-sasl-crammd5-02 / additional mechanisms ?
Reply-To: Tino Reichardt <[email-masked]>
Mail-Followup-To: Tino Reichardt <[email-masked]>, [email-masked]
Sender: [email-masked]

Hello ietf-sasl list.

First of all: my english isn't the best and I am new to this list.

I think the draft 'The CRAM-MD5 SASL Mechanism' should not only
specify the CRAM-MD5 mechanism.
Maybe it can be renamed to 'The CRAM SASL Mechanism family' or similar
and then specify also some other standard hash routines as SASL CRAM
mechanisms:

: CRAM-MD5
160bit: CRAM-SHA1
160bit: CRAM-RIPEMD-160
320bit: CRAM-RIPEMD-320

ps: The CRAM-SHA1 mechanism is already used by serveral servers and
    clients.

references:

[SHA1]   http://www.itl.nist.gov/fipspubs/fip180-1.htm
[RIPEMD] http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html

-- 
regards, TR

From: Hallvard B Furuseth <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: Half-anonymous authentication
Date: Wed, 7 Apr 2004 19:30:40 +0200
Sender: [email-masked]

Sam Hartman writes:
> >>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:
> 
>     Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see
>     Hallvard> that a mechanism may make either ID anonymous at all.
>     Hallvard> It was just so "obvious" that it could do so, that I
>     Hallvard> didn't notice that it couldn't.  Anyway, is that
>     Hallvard> intended?
> 
> I believe the authorization ID of all users authenticated using the
> anonymous mechanism is the same.

Not that I can see.  However, Security Considerations refer to 'the
anonymous user'.  Looks like a good idea for the section which defines
the mechanism.

However, for SASL in general I was thinking of explicitly setting up the
connection to have the same authorization or authentication ID as
unauthenticated connections, not setting them to a special 'anonymous
user'.  The former is called 'anonymous' in LDAP.  Sorry about bringing
the term over here without explaining.

-- 
Hallvard

To: Hallvard B Furuseth <[email-masked]>
Cc: [email-masked]
Subject: Re: Half-anonymous authentication
From: Sam Hartman <[email-masked]>
Date: Wed, 07 Apr 2004 12:41:04 -0400
Sender: [email-masked]

>>>>> "Hallvard" == Hallvard B Furuseth <[email-masked]> writes:

    Hallvard> Uh... OTOH, on second reading of rfc2222bis, I can't see
    Hallvard> that a mechanism may make either ID anonymous at all.
    Hallvard> It was just so "obvious" that it could do so, that I
    Hallvard> didn't notice that it couldn't.  Anyway, is that
    Hallvard> intended?

I believe the authorization ID of all users authenticated using the
anonymous mechanism is the same.

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: Re: Half-anonymous authentication
Date: Tue, 6 Apr 2004 22:25:40 +0200
Sender: [email-masked]

Uh... OTOH, on second reading of rfc2222bis, I can't see that a
mechanism may make either ID anonymous at all.  It was just so "obvious"
that it could do so, that I didn't notice that it couldn't.  Anyway, is
that intended?

I wrote:

> As far as I can tell, a SASL authentication method may make the
> authentication ID _or_ the authorization ID anonymous, but not the
> other one.

Also a bit unfortunate wording.  Of course it may make both
non-anonymous (or anonymous?) too:-)

-- 
Hallvard

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: Half-anonymous authentication
Date: Tue, 6 Apr 2004 22:05:16 +0200
Sender: [email-masked]

As far as I can tell, a SASL authentication method may make the
authentication ID _or_ the authorization ID anonymous, but not the
other one.  Is that correct?  Should it be correct?

Non-anonymous authentication ID + anonymous authorization ID seems
useful for the ANONYMOUS mechanism.  Currently, servers that implement
ANONYMOUS must make a special case to ensure that they don't give any
access to apparently authenticated users who used this method.  However,
if ANONYMOUS sets the authorization ID to anonymous, servers will give
anonymous access by default.  That seems a lot safer, though whether it
is a good idea or not depends on what the mechanism is intended to be
used for.  I suggested that some time ago, but got no response - it
drowned in another subthread.

OTOH, I can't think of a use for anonymous authentication ID with
non-anonymous authorization ID, other than those which could just as
well be fulfilled by setting the authentication ID as well.  Like
EXTERNAL.  Don't know if that is any reason to forbid it, though.

-- 
Hallvard