Subject: Some DIGEST-MD5 nits

From: Simon Josefsson <[email-masked]>
Date: Sun, 19 Dec 2004 00:21:57 +0100

Hi Alexey, all.  Some random notes on -04:

In the challenge, it doesn't say what should happen when "cipher"
occur more than once, I guess adding this:
      <<What if this directive is present multiple times? Error, or take
      the union of all values?>>
would be useful, to mimic the qop-options field, until the issue is
resolved fully.  IMHO, multiple directives should be rejected.

In the "response" token, it says that "realm" values SHOULD match the
realms offered by the server.  Given that the challenge "realm" text
now require UIs to offer to enter a different realm, maybe the SHOULD
could be relaxed to a MAY?

For the "response" token nonce-count value, I suggest describing that
authentication MUST fail if the value is 0.  I.e., replace the final
sentence with:
   This directive is required and MUST be present exactly once;
   otherwise, or if the value is 0, authentication fails.

The response authzid doesn't say what should happen if multiple
occurrences are encountered, I suggest to replace the first sentence
with:
   This directive may appear at most once; if multiple instances are
   present, the client MUST abort the authentication exchange.

The response digest-uri field seem to be indented incorrectly.

The challenge "charset" field doesn't say what happen when it is sent
when not needed (i.e., server announced charset field in response), or
not sent when needed.  I suggest failing authentication in both cases;
clients must already support UTF-8 so it doesn't make sense to allow
clients to use ISO-8859-1 when the server has announced support of
UTF-8.

If the finishing response-auth token is changed to allow for optional
tokens, there should be a size limit on it as well, I suggest:
   The size of a response-auth MUST be less than 2048 bytes.

One of the open issues in the document are:
   1). The latest revision prohibits escaped characters in nonce/cnonce.
   This is different
       from HTTP Digest. Any objections?
If DIGEST-MD5 is different from HTTP Digest, why not limit
nonce/cnonce to printable ASCII characters?  I wonder how many
implementations handle nonce/cnonce strings with ASCII #0 or #255.  If
the rationale for breaking backwards compatibility is to reduce code
complexity, why not really reduce complexity by forbidding #0.  If
code complexity wasn't the rationale, what is?

The SASLprep discussions should mention, for each string, whether the
output string may contain unassigned code points or not.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 20 Dec 2004 04:08:35 +0100

A few additional notes:

I suggest making AES the mandatory to implement cipher.  Currently,
there is no reference for rc4 in the document, there are papers on
weaknesses (such as Wagner's [1]), and there is no discussion in the
current document how to deal with Shamir's findings (see [2]).  If
there are concerns with AES-CBC, perhaps AES-CCM (RFC 3610) is better.

It is not clear what should happen if, in the challenge, the qop field
only contain auth-conf and the cipher field only contain unrecognized
ciphers.  There is this text regarding ciphers:

      if the client recognizes no cipher, it MUST behave as if
      "auth-conf" qop option wasn't provided by the server

and this text regarding qop:

      This directive is optional; if not present it defaults to "auth".
      The client MUST ignore unrecognized options; if the client
      recognizes no option, it MUST abort the authentication exchange.

So does removing auth-conf from qop due to unrecognizable ciphers lead
to a qop default or an authentication rejection?  I suggest the
latter.

In the response, it does not say what should happen if the cipher
field contain an unrecognized cipher.  I suggest failing
authentication.

Thanks,
Simon

[1] http://www.mindspring.com/~dmcgrew/rc4-03.pdf
[2] http://www.rsasecurity.com/rsalabs/node.asp?id=2009

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Dec 2004 12:18:25 +0000

Few more responses:

>   The size of a response-auth MUST be less than 2048 bytes.
Done.

> <>In the response, it does not say what should happen if the cipher 
> field contain an unrecognized cipher. I suggest failing authentication. 

I've added:

  If the cipher chosen by the client is not one of the ciphers 
advertised by the server, authentication fails.

Some servers might not advertise some obsoleted ciphers, but might still 
support them. The new text should prevent that (hopefully).

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Dec 2004 12:08:25 +0000

Simon, answering to some pieces of your messages:

>resolved fully.  IMHO, multiple directives should be rejected.
If you are talking about cipher-opts the document says:

A list of ciphers that the server supports. This directive must be
present exactly once if "auth-conf" is offered in the ...

>[...]
Fixed, thanks.

>   present, the client MUST abort the authentication exchange.
Ok, but "the server MUST abort ..."

>The response digest-uri field seem to be indented incorrectly.
Looks Ok to me in my copy of -04

>[...]
I agree. I've added:

If the client recognizes no cipher and the server only advertised 
"auth-conf" in the qop option,
the client MUST abort the authentication exchange.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 20 Dec 2004 17:59:23 +0100

> present exactly once if "auth-conf" is offered in the ...

Ah, thanks.

If cipher-opts cannot occur more than once, perhaps it make sense to
use the same strategy for qop-options?  That would solve the <<>>
issue above.

> Ok, but "the server MUST abort ..."

Right, thanks.

> Looks Ok to me in my copy of -04

On page 13?  The first paragraph of the digest-uri description is
indented correctly, but the next four paragraphs are not indented.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Dec 2004 20:01:50 +0100

Sam Hartman <[email-masked]> writes:

>>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
>
>     Simon> A few additional notes:
>
>     Simon> I suggest making AES the mandatory to implement cipher.
>     Simon> Currently, there is no reference for rc4 in the document,
>     Simon> there are papers on weaknesses (such as Wagner's [1]), and
>     Simon> there is no discussion in the current document how to deal
>     Simon> with Shamir's findings (see [2]).  
>
> Your citation does a good job of explaining why Shamir's results against WEP don't apply to digest-md5:
>
> A) It does not generate a new key per packet 
>
> b) Keys are the result of hashing; you won't get related keys.
>
> rc4 is the mandatory to implement cipher because it is the one for
> which we have interoperable implementations.  It's strong in this
> application--or at least we don't know about any attacks--and it is
> correctly implemented in existing implementations.

As far as I can tell, DIGEST-MD5 does not use HMAC-MD5 except for the
message integrity layer; rather it uses MD5 directly.  I understand
HMAC-MD5 are considered safe today, but that issues with MD5 are
acknowledged.

Encryption in DIGEST-MD5 use two keys, one in each direction, and both
are generated from repeated MD5 hashing of various strings.  The first
256 bytes of the PRNG are not discarded, as appear to be recommended.

So the attacker see the first 256 bytes of encrypted output from the
PRNG, in both directions.  In the case of SMTP, the plaintext can
probably be regarded as known in typical environments, and sometimes
(e.g., if a user resend an incoming e-mail) even chosen plaintext.
The keys are derived as:

Kc = MD5(MD5(MD5(username:realm:password)|nonce|cnonce|authzid)|string1)
Ks = MD5(MD5(MD5(username:realm:password)|nonce|cnonce|authzid)|string2)

My point with this is to raise a question:

Is everyone comfortable with the use of MD5 in DIGEST-MD5?

To give you my answer, I'm not completely comfortable with it.

>     Simon> If there are concerns
>     Simon> with AES-CBC, perhaps AES-CCM (RFC 3610) is better.
>
> You may recall some previous comments to the working group about CBC
> modes and whether we would not be better off with CCM.  Would you be
> willing to supply text for aes-ccm if the working group decides they
> want to go that direction?

One option is to use AES-CCM with keys derived via PKCS#5 PBKDF2.

Speaking as someone who not yet have an application for encryption
layers in DIGEST-MD5, I'm not sure I'm willing to invest time in this,
though.  I considered implementing the mandatory cipher just to get a
complete DIGEST-MD5 implementation, otherwise I wouldn't have read
that part of the document.

Right now, I prefer to not implement the encryption layer at all, to
avoid giving potentially false expectations.

Given that DIGEST-MD5 uses MD5 directly, I see some potential for an
improved CRAM-MD5 that support authorization identities, since CRAM is
be based on HMAC.  But if such a mechanism is specified, it might as
well use SHA-1 or SHA-256 instead.  I.e., CRAM-SHA1.  I would be
willing to work on that.

Thanks,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Sun, 19 Dec 2004 23:40:54 -0500

--Sam

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 20 Dec 2004 04:08:35 +0100

A few additional notes:

Thanks,
Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Dec 2004 12:18:25 +0000

Few more responses:

Done.

I've added:

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Dec 2004 12:08:25 +0000

Fixed, thanks.

I agree. I've added:

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 20 Dec 2004 17:59:23 +0100

Ah, thanks.

Right, thanks.

Thanks,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Dec 2004 20:01:50 +0100

Thanks,
Simon

---

From: Sam Hartman <[email-masked]>
Date: Sun, 19 Dec 2004 23:40:54 -0500

--Sam

To: [email-masked]
Subject: Re: Some DIGEST-MD5 nits
From: Sam Hartman <[email-masked]>
Date: Sun, 19 Dec 2004 23:40:54 -0500
Sender: [email-masked]

--Sam

From: Simon Josefsson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: [email-masked]
Subject: Re: Some DIGEST-MD5 nits
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Date: Wed, 22 Dec 2004 20:01:50 +0100
Sender: [email-masked]

Thanks,
Simon

Content-class: urn:content-classes:message
Subject: RE: Some DIGEST-MD5 nits
Date: Mon, 20 Dec 2004 11:26:56 -0800
From: "Paul Leach" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Simon Josefsson
> Sent: Sunday, December 19, 2004 7:09 PM
> To: [email-masked]
> Subject: Re: Some DIGEST-MD5 nits
> 
> 
> A few additional notes:
> 
> current document how to deal with Shamir's findings (see [2]).
[Paul Leach] I would suggest that either RC4 be deprecated, or that a
new RC4-based cipher specifier be added that discards the first 256
bytes of the RNG. If the latter is the choice, security considerations
should be added referencing the above, and noting that discarding 256
bytes handles the problems.

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Some DIGEST-MD5 nits
Date: Mon, 20 Dec 2004 17:59:23 +0100
Lines: 39
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:LiVgreHvU2dsDVJmzrMDd+Ewn/E=
Sender: [email-masked]

Ah, thanks.

Right, thanks.

Thanks,
Simon

Date: Mon, 20 Dec 2004 12:18:25 +0000
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: Some DIGEST-MD5 nits
Sender: [email-masked]

Few more responses:

Done.

I've added:

Date: Mon, 20 Dec 2004 12:08:25 +0000
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: Some DIGEST-MD5 nits
Sender: [email-masked]

Fixed, thanks.

I agree. I've added:

Date: Sun, 19 Dec 2004 19:38:41 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Last Call: 'The Anonymous SASL Mechanism' to Proposed Standard
Cc: [email-masked]
Sender: [email-masked]

At 09:18 AM 12/9/2004, Simon Josefsson wrote:

>The IESG <[email-masked]> writes:
>
>> The IESG has received a request from the Simple Authentication and Security 
>> Layer WG to consider the following document:
>>
>> - 'The Anonymous SASL Mechanism '
>>    <draft-ietf-sasl-anon-04.txt> as a Proposed Standard
>
>A comment on the following grammar entry:
>
>   email       = addr-spec
>                    ;; as defined in [IMAIL], except with no free
>                    ;; insertion of linear-white-space, and the
>                    ;; local-part MUST either be entirely enclosed in
>                    ;; quotes or entirely unquoted
>
>Assuming it is intentional to use RFC 822 and not RFC 2822 as the
>reference for IMAIL, the last additional requirement on local-part
>above seem to suggest that:
>
>"foo"."bar"@example.org
>
>should be expressed as:
>
>"foo.bar"@example.org
>
>but as far as I know, these aren't semantically the same e-mail
>addresses.
>
>I believe interpretation of local-part should not be done outside of
>the administrative realm of the e-mail domain.  Collapsing the first
>e-mail address above into the second appear to assume that these two
>forms are equivalent.
>
>How about using RFC 2822 and addr-spec without additional
>requirements?

I am fine with this change.  Unless there are objections, I
will update the I-D accordingly.

Kurt 

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Some DIGEST-MD5 nits
Date: Mon, 20 Dec 2004 04:08:35 +0100
Lines: 34
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:Vm8esb+VoIF3/iiZI6V+Ry0hSnI=
Sender: [email-masked]

A few additional notes:

Thanks,
Simon

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Implementing SASL PLAIN servers
Date: Mon, 20 Dec 2004 03:41:17 +0100
Lines: 108
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:BgugeOTjCG3QR39CTjJOezOJeOI=
Sender: [email-masked]

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

> At 08:54 AM 12/9/2004, Simon Josefsson wrote:
>
>>"Kurt D. Zeilenga" <[email-masked]> writes:
>>
>>> I note that the text also doesn't reflect the apparent consensus 
>>> that use of SASLprep be RECOMMENDED (instead of REQUIRED)
>>> (see <http://www.imc.org/ietf-sasl/mail-archive/msg01835.html>
>>> for latest text).  Addressing this, and making the text read well,
>>> is a bit of a challenge.
>>
>>I can try to update my proposed text.
>
> Appreciated.

If there is consensus to change to RECOMMENDED, I believe that it
would be easier for me to suggest modifications if there was a new
document that reflect current consensus.  Otherwise most of my
suggested text would likely just rewrite other aspect of the document.

My main concern is that it should be clear, for each string, whether
it may contain unassigned code points or not.  I thought it would be
simple to add small clarifying text for each string to address this.

>>>>  If the server store unprepared passwords and authentication
>>>>  identities ("server strings"), the server prepare these using
>>>>  SASLprep, allowing unassigned code points in the output.  The server
>>>>  verify the authentication by comparing the prepared client strings
>>>>  with the prepared server strings.
>>>
>>> This behavior is counter to the specified behavior of SASLprep
>>> and StringPrep, from Section 7 of RFC 3454.
>>>    The goal of the requirements in this section is to prevent
>>>    comparisons between two strings that were both permitted to
>>>    contain unassigned code points.
>>> Since we allowing unassigned code points in the presented
>>> strings, we must prohibit them in the stored strings.
>>
>>Unless I misunderstood him, or remember incorrectly, Sam proposed this
>>approach.  I would have implemented it differently -- I would treat
>>the unprepared strings using SASLprep treating the strings as stored
>>strings.  I don't care which option is chosen, only that there is a
>>plan and that the plan is expressed in the document.
>
> All "server strings" should be regarded as "stored strings",
> e.g., unassigned code prohibited in them.

We agree.  Sam, can you live with this?

For what its worth, this is also the approach I have implemented.
http://josefsson.org/cgi-bin/viewcvs.cgi/gsasl/lib/plain/server.c?view=markup

>>>>  Verification when a non-reversible transformation is stored in the
>>>>  database is more complex.  We have several cases, that differ in
>>>>  what is being used as input to the transformation.  For example, in
>>>>  some designs the database is keyed on the authentication identity,
>>>>  and store a transformation of the password.  In some design, the
>>>>  database is keyed on the authentication identity, and store a
>>>>  transformation of the password and the authentication identity.
>>>>  Conceivable, some designs could key the database on a transformation
>>>>  of the password and authentication identity, and storing the
>>>>  authentication identity.  However, which mode is used does not
>>>>  matter, as long as the earlier rules are followed.
...
>>However, I agree that the second paragraph does not add anything to
>>the protocol, so if you don't believe it is useful, then it could be
>>dropped.  I tried to write something that would improve the document.
>
> Understand.  My thoughts are that this last paragraph is a bit
> distracting and that document would read better without it.

Then let's drop it.

I recall that Sam suggested that the document should discuss the two
aspects of a server implementation.  I don't think it is necessary if
you consider "server strings" as "stored strings", but if you don't,
it becomes critical.  Here is some discussion:

At least two conceptual parts of a server is involved in invoking
SASLprep.

First, there is the part that store passwords in the database.  As far
as I can tell, everyone agrees that the application should validate
the user input using SASLprep, treating the input as a stored string.

There doesn't seem to be consensus about what to store in the database
(original or prepared string), but I don't think it matters; either
approach should work.  (I'm not planning to implement a database that
store prepared strings, except as possibly an optimization, if the
original string is also stored.)

The second part of the server is the online part that receives
passwords from the client, and from the database.  Kurt and I seem to
be in agreement that it should prepare all strings (i.e., both from
client and from database) treating them as stored strings.  (Of
course, if the database store prepared strings, the server need not
prepare them again.)  If I understood him (and remember) correctly,
Sam suggested the server should treat all strings as query strings.
Given the current document, I have been trying to argue that this is
an entirely reasonable interpretation, so the document must be
clarified.

Right now, I have stopped caring about which approach is adopted, as
long as some approach is adopted.

Thanks,
Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Some DIGEST-MD5 nits
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Date: Sun, 19 Dec 2004 00:21:57 +0100
Sender: [email-masked]

Thanks,
Simon

From: bzsidlnt <[email-masked]>
To: <[email-masked]>
Subject: Fw:  Merry Christmas!
Date: Cz, 16 gru 2004
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_861_4718_00662600.65158861
Content-Type: multipart/related;
	type="multipart/alternative";
	boundary="----=_NextPart_408_1362_38012651.47180066"

------=_NextPart_408_1362_38012651.47180066
Content-Type: multipart/alternative;
	boundary="----=_NextPart_588_6147_18006626.26004081"

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

Happy Hollydays!

:) bzsidlnt
------=_NextPart_588_6147_18006626.26004081
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#008000><FONT face=3D"Comic Sans MS"><FONT =
size=3D4><FONT size=3D6>*=20
</FONT><FONT size=3D4>Happy....<IMG alt=3D"" hspace=3D0=20
src=3D"cid:000501c4d3e8$a2bcc490$6701a8c0@Tomi" align=3Dbaseline=20
border=3D0>&nbsp;....Hollydays!<FONT size=3D5> *</FONT></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D4></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#008000 face=3D"Comic Sans MS" size=3D4><STRONG>:) bzsidlnt<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#008000 face=3D"Comic Sans MS"=20
size=3D2>________________________________________________________________=
___</FONT></DIV>
<DIV><FONT size=3D2><STRONG><U><FONT color=3D#0000ff face=3DArial>
http://imc.org/link.postcard.gif7001
</U>
<FONT color=3D#008000>- Picture Size: 11 KB, Mail: +OK</FONT></STRONG></FONT></DIV></BODY></HTML>

------=_NextPart_588_6147_18006626.26004081--

------=_NextPart_408_1362_38012651.47180066
Content-Type: image/gif;
	name="b.gif"
Content-Transfer-Encoding: base64
Content-ID: <000501c4d3e8$a2bcc490$6701a8c0@Tomi>

R0lGODlhGAAUAKECAAICov7+AgAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQJCgACACwAAAAA
GAAUAAACTJQPqQvnD4KcNLTnYrVaXtxVCfVl2+lhQuihJXIu0wKh8zibthXDdogrsUg/32ZI0ol2
L5YGJwLJiFHQj6EyKHaWrLHnRQwTYSnNUQAAIfkECQoAAgAsAgAAABUAFAAAAkmUBakL5waCnDS0
h6pM9J6oWeDmjFtIfprZleEyKSq6cSlb4VaGmvals3RGDV3wlqOleMLYq2TrrB5Bhgd63GEgtOs2
Wtt+F48CACH5BAkKAAIALAEAAAAWABQAAAJIlA2pC+cHgpw0tIeqTPS6qFng9oxbSH6a2ZXhMikQ
2nEpu74C3tU3yrJZdi/ar8JrZWK91UeRQ2KSDE9JqMPMgNor0tqFLB4FACH+JyhDKSBodHRwOi8v
cGFyYWxsYXgubnNrLnN1IDIwMDABVVNTUENNVAA7

------=_NextPart_408_1362_38012651.47180066--

------=_NextPart_861_4718_00662600.65158861
Content-Type: application/x-zip-compressed;
	name="link.postcard.gif7001.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="link.postcard.gif7001.zip"

------=_NextPart_861_4718_00662600.65158861--

Date: Wed, 15 Dec 2004 21:23:47 -0800
To: "Gavin Young" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Cyrus -> LDAP Authentication
Cc: <[email-masked]>
Sender: [email-masked]

Please note that this list is for discussing the standardization
of SASL.  Discussions specific to any given implementation of
SASL, such as Cyrus SASL, should be directed to forums particular
to the implementation.  For Cyrus SASL, please use the
<[email-masked]>.  See
<http://asg.web.cmu.edu/sasl/#mailinglists> for subscription
details.

Thanks, Kurt (SASL WG chair)

From: "Tim Kehres" <[email-masked]>
To: "Gavin Young" <[email-masked]>, <[email-masked]>
Subject: Re: Cyrus -> LDAP Authentication
Date: Thu, 16 Dec 2004 08:15:14 +0800
Sender: [email-masked]

Gavin,

> Has anyone else set-up a Postfix + Cyrus mail server authentication
against OpenLDAP using saslauthd?

First you will have to decide if you are going to use PAM or SASLAUTHD as
your authentication method.   I've been using saslauthd as I don't need the
extra flexibility (complexity) afforded by PAM.   Have also gone through a
similar exercise lately, and barely lived to tell about it.  All is
relatively straightforward until you hit one of the Cyrus modules it seems.

> I'm really struggling so any help including links to existing documents
would be very useful. My main concern at the moment is getting Cyrus IMAP to
authenticate against LDAP. I have been told to use saslauthd but any easier
suggestions would be welcomed. Sorry for the long post but I'm trying not to
miss anything.
>
> I am using Fedora Core 2 on the test box but it will be RHEL3 when in
production. My postifix+cyrus install works correctly with local accounts
using the setup below:

Using FC2 here and saslauthd.   Try to use the testsaslauthd utility to make
sure that all is working properly before having Cyrus IMAP use it.   Running
saslauthd in a shell so that you can see debugging output while at the same
time turning on debugging in OpenLDAP can be extremely helpful.   The use of
Cyrus realms sometimes causes problems depending on your configuration, and
the debugging output should tell you exactly what is being sent to
saslauthd, and then down the line to OpenLDAP.

> /etc/sysconfig/saslauthd
> SOCKETDIR=/var/run/saslauthd
> #MECH=shadow --default FC3, couldn't get cyradm to work
> MECH=pam
> FLAGS=

For saslauthd, you should use:

MECH="ldap"

For my site, I also had to modify /etc/rc.d/init.d/saslauthd and change the
default MECH (MECH=ldap).

Also make sure that /var/run/saslauthd exists.   The Cyrus SASL code, at
least on Fedora 2 seems to have several problems in default directories.
The install does not seem to identify and adjust to different
configurations.   Potential problems exist for SOCKETDIR as well as where
the default libraries are installed.   If you are running the standard FC2
RPM's however there should be fewer problems.  Just make sure you understand
where the saslauthd configuration file is for the particular version / build
you are running.  If I remember correctly, if you build from source, the
default is /usr/local/etc/saslauthd.conf, but the RedHat RPM's default to
/etc/saslauthd.conf.

For my configuration (you will most likely need to modify per your local
network as well as your LDAP schema you are using), my saslauthd.conf is:

ldap_servers: ldap://cebu.jade.net:389/
ldap_password_attr: userPassword
ldap_default_realm: jade.net
ldap_filter: uid=%U@%r
ldap_search_base: uid=%U@%r,dc=jade,dc=net

> /etc/imapd.conf
> configdirectory: /var/lib/imap
> partition-default: /var/spool/imap
> admins: cyrus
> sievedir: /var/lib/imap/sieve
> sendmail: /usr/sbin/sendmail
> hashimapspool: true
> sasl_pwcheck_method: saslauthd
> sasl_mech_list: PLAIN
> tls_cert_file: /usr/share/ssl/certs/cyrus-imapd.pem
> tls_key_file: /usr/share/ssl/certs/cyrus-imapd.pem
> tls_ca_file: /usr/share/ssl/certs/ca-bundle.crt

This looks ok.

> When testing with "testsaslauthd -u john -p password" or "testsaslauthd -u
[email-masked] -p password" testauthd returns: 0: NO "authentication
failed"

Try to run saslauthd with debugging in a separate shell that you can monitor
what is being passed to it.   At the same time turn on debuggin in the LDAP
server and try to see into the LDAP server.   Cyrus realms get in the way
sometimes here.

> /var/log/messages
> saslauthd[6142]: do_auth : auth failure: [user=john] [service=imap]
[realm=] [mech=ldap] [reason=Unknown]
>
> Reading the saslauthd ldap documentation
> ( <http://www.irbs.net/internet/info-cyrus/0207/att-0599/LDAP_SASLAUTHD>)
it explains how to define ldap servers etc but when I place this in
/etc/sysconfig/saslauthd and restart saslauthd I get "line x: ldap_servers::
command not found". Should this info be placed somewhere else?
>
> HELP!
> 1) Are there are any other log files I should be watching for hints?
> 2) Have I missed a config file somewhere?
> 3) Am I testing correctly?
> 3) Do I need to define more than just the base in /etc/ldap.conf (ie
username field = uid and the password field = userPassword?

Check the configuration of your saslauthd.conf file and make sure it is
consistent with your schema that you are trying to authenticate against in
LDAP.  Make sure that the ldap filter saslauthd is using is proper for your
setup.

If you have any other specific issues, feel free to drop me a line and I can
go through my notes to see if I can be of any further assistance.

Best Regards,

Tim Kehres

content-class: urn:content-classes:message
Subject: Cyrus -> LDAP Authentication
Date: Thu, 16 Dec 2004 11:49:10 +1300
From: "Gavin Young" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hopefully someone here can help me...

Has anyone else set-up a Postfix + Cyrus mail server authentication against OpenLDAP using saslauthd?

I'm really struggling so any help including links to existing documents would be very useful. My main concern at the moment is getting Cyrus IMAP to authenticate against LDAP. I have been told to use saslauthd but any easier suggestions would be welcomed. Sorry for the long post but I'm trying not to miss anything.

I am using Fedora Core 2 on the test box but it will be RHEL3 when in production. My postifix+cyrus install works correctly with local accounts using the setup below:

/etc/sysconfig/saslauthd
SOCKETDIR=/var/run/saslauthd
#MECH=shadow --default FC3, couldn't get cyradm to work
MECH=pam
FLAGS=

/etc/imapd.conf
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
admins: cyrus
sievedir: /var/lib/imap/sieve
sendmail: /usr/sbin/sendmail
hashimapspool: true
sasl_pwcheck_method: saslauthd
sasl_mech_list: PLAIN
tls_cert_file: /usr/share/ssl/certs/cyrus-imapd.pem
tls_key_file: /usr/share/ssl/certs/cyrus-imapd.pem
tls_ca_file: /usr/share/ssl/certs/ca-bundle.crt

/etc/openldap/ldap.conf
HOST localhost
BASE dc=example,dc=org

/etc/ldap.conf
host 127.0.0.1
base dc=example,dc=org
ssl no
pam_password md5

To try an get Cyrus to authenticate against LDAP these are the steps I have taken:

1) Install saslauthd
--cyrus-sasl-2.1.18-2.2 (+devel & md5) RPMS are installed

2) Choose ldap as auth mechanism if supported
--ldap seems supported, saslauthd -v outputs:
saslauthd 2.1.18
authentication mechanisms: getpwent kerberos5 pam rimap shadow ldap
--changed /etc/sysconfig/saslauthd config file to:
SOCKETDIR=/var/run/saslauthd
#MECH=shadow --default FC3, couldn't get cyradm to work
#MECH=pam
MECH=ldap
FLAGS=

3) Edit ldap.conf so that it fits your ldap server
--no changes, defaults ok??

4) Edit imap.conf so auth method = saslauthd
--no change required, already set to saslauthd
--restarted cyrus-imapd and saslauthd

When testing with "testsaslauthd -u john -p password" or "testsaslauthd -u [email-masked] -p password" testauthd returns: 0: NO "authentication failed"

When testing with "./imtest -a john localhost" and ""./imtest -a [email-masked] localhost" login fails. Log output:

/var/log/maillog
badlogin: localhost.localdomain [127.0.0.1] plaintext john SASL(-13):
authentication failure: checkpass failed

/var/log/messages
saslauthd[6142]: do_auth : auth failure: [user=john] [service=imap] [realm=] [mech=ldap] [reason=Unknown]

Reading the saslauthd ldap documentation
( <http://www.irbs.net/internet/info-cyrus/0207/att-0599/LDAP_SASLAUTHD>) it explains how to define ldap servers etc but when I place this in /etc/sysconfig/saslauthd and restart saslauthd I get "line x: ldap_servers:: command not found". Should this info be placed somewhere else?

HELP!
1) Are there are any other log files I should be watching for hints?
2) Have I missed a config file somewhere?
3) Am I testing correctly?
3) Do I need to define more than just the base in /etc/ldap.conf (ie username field = uid and the password field = userPassword?

Any help would be greatly appreciated.

Regards,
Gavin

Date: Tue, 14 Dec 2004 20:50:16 -0800
To: "Spencer Dawkins" <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Gen-ART review of draft-ietf-sasl-anon-04.txt
Cc: <[email-masked]>, "Sam Hartman" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 08:33 PM 12/13/2004, Spencer Dawkins wrote:
>This specification is reasonable for publication as a proposed standard. All of my comments could be addressed in AUTH-48.
>
>My nit collection looks like this:
>
>- how deeply embedded is the word "trace" in the SASL community? The document defines it more than once, consistently, but every time I saw the word I kept finding myself wondering what "trace" had to do with this protocol specification. If it's too late to change it, that's fine - I'm just asking.

In the I-D, the word 'trace' has two basic uses.
        1) trace information
        2) the "trace" profile

The latter is intended to be named after the former.  The
former is descriptive of the kind of information being
carried.  I recall some discussion of alternatives; this
was the best we came up with.

>- Does this document replace RFC 2245, or obsolete it (the RFC-Editor word),
> or something else?

    Obsoletes: RFC 2245

    This document replaces RFC 2245.  Changes since RFC 2245 are
    detailed in Appendix A.

>- I thought "No additional characters are prohibited" was awkward -

As Stringprep says:
   It is important to note that a profile of this document MAY prohibit
   additional characters.
I felt it appropriate to note that no additional characters are
prohibited.  The sentence likely could be deleted without
causing implementor confusion.

>is the document saying "All other characters are permitted"?

No.

>- I thought "Information about who accesses an anonymous archive on a sensitive subject (e.g., sexual abuse) has strong privacy needs" was awkward 
>- at the very least, "who" has strong privacy needs, but the sentence seems to say the information has strong privacy needs. Possibly "Anyone who accesses an anonymous archive on a sensitive subject (e.g. sexual abuse) likely has strong privacy needs"?

Works for me.

Date: Fri, 10 Dec 2004 11:52:42 -0800
To: [email-masked]
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: minutes of the IETF#61 SASL session
Sender: [email-masked]

Simple Authentication and Security Layer (SASL) WG
==================================================
Chair(s): Kurt Zeilenga <[email-masked]>
       Sam Hartman <[email-masked]>

Tuesday, 9 November 2004  1545-1645

Minutes compiled by Kurt Zeilenga from notes taken by
Philip Guenther, Jeff Altman, others on Jabber.  Minutes
are not necessarily presented in chronological order.

The Chair opened the meeting shortly after 1545.  Philip
Guenther agreed to take meeting notes.  Jeff Altman agreed
to be our Jabber scribe.

It was noted that Sam Hartman would be stepping down as
stepping down as co-chair after the session as he accepted
an appointment to the IESG.

draft-ietf-sasl-rfc2222bis (SASL base spec) was discussed.
As Alexey (our Editor) was only able to participate via Jabber,
the Chair, using the summary Alexey posted to the list, briefly
went through the issues.
 - Identity terminology: this is the most significant
   outstanding issue.  The "requested identity" proposal
   discussed at WG LC turned out to be problematic,
   especially in regards to its impact on mechanism
   specifications and existing implementation conventions.
   While its appears the subsequently suggested approach to
   discussion "identity concepts" may resolve some of the
   terminology issues, further work is needed.  The chairs
   stated that the Editor needed additional direction here.
   The chairs to work with the Editor, giving the Editor as
   much free hand as possible, to come up with suitable text.
   But what's really needed is more WG review and comment.
 - Rekeying: consensus seems to be consistent with the
   chairs WGLC summary discussing this issue, but the text
   may need minor modification to reflect that consensus.
 - It was noted that document may need work in other areas.
 - The chairs asked who in the room had reviewed the document
   "front-to-back", few had.  The chairs noted that additional
   WG review was needed and called for WG members to review
   this document.

draft-ietf-sasl-rfc2831bis (DIGEST-MD5) was discussed.

As Alexey (our Editor) was only able to participate via Jabber,
the Chair provided a brief summary of the issues.
 - Alexey has a few minor editors to make,
 - Sam noted he would send crypto comments (CBC-fix) to list.
 - The chairs polled the room as to who has reviewed this I-D,
   few had.  The chairs noted that additional WG review was
   needed and called for WG members to review this document.

draft-ietf-sasl-gssapi-01.txt (GSSAPI mechanisms) was discussed.
The chairs polled the room as to who has reviewed this I-D, few
had.  The chairs noted that the document would not go to WGLC
until it received appropriate review.  Nico noted that apparent
consensus was for the "GSSAPI" (aka krb5) will not do rekeying,
but that a new doc to describe GSS family of mechanisms,
rolling in support for rekeying and reduced round-trips.
That is, draft-ietf-sasl-gssapi would detail on the "GSSAPI"
mechanism as implemented today.  The chairs noted that this new
document would not be taken on until the current drafts have
moved forward.

draft-ietf-sasl-crammd5 (CRAM-MD5)
The chairs polled the room as to who has reviewed this I-D, few
had.  The chairs, after determining that few in the room had
read the draft, would twist arms to get necessary review.  As
the Editor was unavailable, the I-D was not discussed further.

Milestones
The chairs lead a brief discussion of milestones.  The Chair
noted that another WGLC would likely be needed before progressing
draft-ietf-sasl-rfc2222bis, and before end of year.  Alexey
noted that he needs clear suggestions.

The chairs also noted that we will not commit resources to new
docs until existing ones are reviewed.

Other comments:

A question was raised about status of LOGIN mechanism.  The
chairs noted that engineering of this mechanism was not on the
charter and the mechanism was generally considered obsolete in
favor of the PLAIN mechanism.  However, the chairs did not that
individuals were free to pursue a LOGIN I-D and discuss it on
the WG list.

There was a brief exchange regarding generic GSS mech family vs
new non-GSS mechanisms.  The discussion was deferred.

Russ and the WG acknowledged Sam's service to the WG as co-chair.
The WG looks forward to working with Sam as our Security Area
Director.  Russ also noted that those interested in serving as
SASL co-chair are encouraged to contact him and/or Sam.

The session concluded at 1630.

Date: Fri, 10 Dec 2004 11:22:46 +0000
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: Extensibility of response-auth in DIGEST-MD5
Sender: [email-masked]

Simon Josefsson wrote:

>>>So my proposal would be to replace in section 2.1.3:
>>>
>>>   response-auth = "rspauth" "=" response-value
>>>
>>>with:
>>>
>>>   finish = 1#( response-auth | auth-param )
>>> 
>>>
>>>      
>>>
>>I've changed "finish" to "auth-info", to be consistent with HTTP Digest 
>>(RFC 2617).
>>
>>Looking at syntax in RFC 2617, your proposal is consistent with how RFC 
>>2617.
>>    
>>
>
>Ah, thanks, I didn't look in RFC 2617.  There should probably text
>like the following for the response-auth field as well:
>
>   This directive is required and MUST appear exactly once; if not
>   present, or if multiple instances are present, the client SHOULD
>   abort the authentication exchange.
>  
>
Yes, I've already added something like this.

>>>Further, I believe the following is unacceptable:
>>>
>>>  Since it is cut-and-paste from the HTTP specifications, not all
>>>  productions may be used in this specification. It is also not quite
>>>  legal ABNF; again, the errors were copied from the HTTP
>>>  specifications.
>>>      
>>>
>>This is actually not true anymore. I've already fixed few things.
>>    
>>
I've removed the second sentence.

>
>Excellent!  I'm extracting the ABNF grammar from the document, which
>is used as input to the parser generator, so I'll be able to confirm
>that the grammar is self contained.
>
Good.

>  (These tools are unfinished, so I
>haven't run the complete current grammar through the tools yet.)
>  
>

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Extensibility of response-auth in DIGEST-MD5
Date: Thu, 09 Dec 2004 23:59:33 +0100
Lines: 41
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:Wtp8Rsz6PJWMFfN6tiTe/LotFGk=
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

>>So my proposal would be to replace in section 2.1.3:
>>
>>    response-auth = "rspauth" "=" response-value
>>
>>with:
>>
>>    finish = 1#( response-auth | auth-param )
>>  
>>
> I've changed "finish" to "auth-info", to be consistent with HTTP Digest 
> (RFC 2617).
>
> Looking at syntax in RFC 2617, your proposal is consistent with how RFC 
> 2617.

Ah, thanks, I didn't look in RFC 2617.  There should probably text
like the following for the response-auth field as well:

   This directive is required and MUST appear exactly once; if not
   present, or if multiple instances are present, the client SHOULD
   abort the authentication exchange.

>>Further, I believe the following is unacceptable:
>>
>>   Since it is cut-and-paste from the HTTP specifications, not all
>>   productions may be used in this specification. It is also not quite
>>   legal ABNF; again, the errors were copied from the HTTP
>>   specifications.
>>  
>>
> This is actually not true anymore. I've already fixed few things.

Excellent!  I'm extracting the ABNF grammar from the document, which
is used as input to the parser generator, so I'll be able to confirm
that the grammar is self contained.  (These tools are unfinished, so I
haven't run the complete current grammar through the tools yet.)

Thanks,
Simon

Date: Thu, 09 Dec 2004 12:40:34 +0000
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: Extensibility of response-auth in DIGEST-MD5
Sender: [email-masked]

Simon Josefsson wrote:

>>Simon has pointed out to me that both step 1 ("digest-challenge" 
>>non-terminal) and step 2 ("digest-response" non-terminal) of the 
>>DIGEST-MD5 (currently draft-ietf-sasl-rfc2831bis-04.txt) allow for 
>>"auth-param", which is described as:
>>
>>  auth-param
>>     This construct allows for future extensions; it may appear more
>>     than once. The client MUST ignore any unrecognized directives.
>>
>>However, the "response-auth" non-terminal used in step 3 doesn't allow 
>>for any extensibility.
>>Is there a good reason for that and does anybody mind if I add 
>>"auth-param" to the "response-auth"?
>>    
>>
>
>Perhaps I should mention the background for my question.
>
>I'm writing a parser for the DIGEST-MD5 grammar.  The challenge and
>response tokens are defined by ABNF using the '1#' construct, but the
>finish step does not use '1#'.
>
>That has consequences for how white space and empty fields are
>handled.  For example, according to the ABNF, the challenge/response
>tokens can validly start with:
>
>  , , ,,,,
>
>So my proposal would be to replace in section 2.1.3:
>
>    response-auth = "rspauth" "=" response-value
>
>with:
>
>    finish = 1#( response-auth | auth-param )
>  
>
I've changed "finish" to "auth-info", to be consistent with HTTP Digest 
(RFC 2617).

Looking at syntax in RFC 2617, your proposal is consistent with how RFC 
2617.

>    response-auth = "rspauth" "=" response-value
>  
>
>Further, I believe the following is unacceptable:
>
>   Since it is cut-and-paste from the HTTP specifications, not all
>   productions may be used in this specification. It is also not quite
>   legal ABNF; again, the errors were copied from the HTTP
>   specifications.
>  
>
This is actually not true anymore. I've already fixed few things.

>The intention of the document should be that the grammar is free of
>errors.  I think that the known errors should be fixed, and ideally
>also sent to the RFC editor as an errata to the HTTP specification.
>  
>
Yes, I agree.

Date: Thu, 09 Dec 2004 09:27:17 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Implementing SASL PLAIN servers
Cc: [email-masked]
Sender: [email-masked]

At 08:54 AM 12/9/2004, Simon Josefsson wrote:

>"Kurt D. Zeilenga" <[email-masked]> writes:
>
>> I note that the text also doesn't reflect the apparent consensus 
>> that use of SASLprep be RECOMMENDED (instead of REQUIRED)
>> (see <http://www.imc.org/ietf-sasl/mail-archive/msg01835.html>
>> for latest text).  Addressing this, and making the text read well,
>> is a bit of a challenge.
>
>I can try to update my proposed text.

Appreciated. 

>> At 07:59 PM 12/8/2004, Simon Josefsson wrote:
>>>NEW:
>>>  The server prepare the authentication identity and password received
>>>  from the client ("client strings") using SASLprep, allowing
>>>  unassigned code points in the output (see Section 7 of
>>>  [StringPrep]).
>>
>> I believe the text needs to explicitly state that these
>> strings are to be regarded as "query" strings.  This for
>> continuity with Section 7 of [StringPrep].  I think that
>> can be worked in without too much problem.  (Likewise for
>> "stored" strings.)
>
>Good point.  How about this:
>
>The server prepare the authentication identity and password received
>from the client ("client strings") using SASLprep, treating them as
>query strings, i.e., unassigned code points are allowed in the output
>(see Section 7 of [StringPrep]).

That seems fine to me.

>>>  If the server store unprepared passwords and authentication
>>>  identities ("server strings"), the server prepare these using
>>>  SASLprep, allowing unassigned code points in the output.  The server
>>>  verify the authentication by comparing the prepared client strings
>>>  with the prepared server strings.
>>
>> This behavior is counter to the specified behavior of SASLprep
>> and StringPrep, from Section 7 of RFC 3454.
>>    The goal of the requirements in this section is to prevent
>>    comparisons between two strings that were both permitted to
>>    contain unassigned code points.
>> Since we allowing unassigned code points in the presented
>> strings, we must prohibit them in the stored strings.
>
>Unless I misunderstood him, or remember incorrectly, Sam proposed this
>approach.  I would have implemented it differently -- I would treat
>the unprepared strings using SASLprep treating the strings as stored
>strings.  I don't care which option is chosen, only that there is a
>plan and that the plan is expressed in the document.

All "server strings" should be regarded as "stored strings",
e.g., unassigned code prohibited in them.

>>>  If the server store a non-reversible transformation (i.e., a hash)
>>>  of the authentication identity or password, the input strings to
>>>  that transformation MUST have been prepared and unassigned code
>>>  points MUST NOT be part of the prepared output.  Strings that are
>>>  not used as input to the transformation (i.e., strings used to look
>>>  up data in the database) MUST be prepared so that unassigned code
>>>  points are permitted in the output.
>>>
>>>  Verification when a non-reversible transformation is stored in the
>>>  database is more complex.  We have several cases, that differ in
>>>  what is being used as input to the transformation.  For example, in
>>>  some designs the database is keyed on the authentication identity,
>>>  and store a transformation of the password.  In some design, the
>>>  database is keyed on the authentication identity, and store a
>>>  transformation of the password and the authentication identity.
>>>  Conceivable, some designs could key the database on a transformation
>>>  of the password and authentication identity, and storing the
>>>  authentication identity.  However, which mode is used does not
>>>  matter, as long as the earlier rules are followed.
>>
>> I see this elaboration as at best extraneous and at worse
>> distracting.  I don't see how it clarifies any of the key
>> issues you raise.
>
>Requirements like those in the first paragraph above are needed if
>servers should use SASLprep in the same way. 

My last comment was in regards only to the last paragraph of your
suggested text.

>However, I agree that the second paragraph does not add anything to
>the protocol, so if you don't believe it is useful, then it could be
>dropped.  I tried to write something that would improve the document.

Understand.  My thoughts are that this last paragraph is a bit
distracting and that document would read better without it.

>I think the text reads OK if MUST is replaced with SHOULD.

I note that the MUST v SHOULD applies to SASLprep preparation
of ALL strings (e.g., SASLprep SHOULD be used).   If SASLprep is
used, then it is be used as detailed (e.g., unassigned code
points MUST NOT appear in prepared output of server strings).

Kurt 

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Last Call: 'The Anonymous SASL Mechanism' to Proposed Standard
Date: Thu, 09 Dec 2004 18:18:48 +0100
Lines: 39
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:Fp78OJyyR+slBkWAZ00dhlz2YBs=
Sender: [email-masked]

The IESG <[email-masked]> writes:

> The IESG has received a request from the Simple Authentication and Security 
> Layer WG to consider the following document:
>
> - 'The Anonymous SASL Mechanism '
>    <draft-ietf-sasl-anon-04.txt> as a Proposed Standard

A comment on the following grammar entry:

   email       = addr-spec
                    ;; as defined in [IMAIL], except with no free
                    ;; insertion of linear-white-space, and the
                    ;; local-part MUST either be entirely enclosed in
                    ;; quotes or entirely unquoted

Assuming it is intentional to use RFC 822 and not RFC 2822 as the
reference for IMAIL, the last additional requirement on local-part
above seem to suggest that:

"foo"."bar"@example.org

should be expressed as:

"foo.bar"@example.org

but as far as I know, these aren't semantically the same e-mail
addresses.

I believe interpretation of local-part should not be done outside of
the administrative realm of the e-mail domain.  Collapsing the first
e-mail address above into the second appear to assume that these two
forms are equivalent.

How about using RFC 2822 and addr-spec without additional
requirements?

Thanks,
Simon

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Implementing SASL PLAIN servers
Date: Thu, 09 Dec 2004 17:54:02 +0100
Lines: 92
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:gQR1DcW8HAcy5YdRPEfxv+BwGiM=
Sender: [email-masked]

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

> I note that the text also doesn't reflect the apparent consensus 
> that use of SASLprep be RECOMMENDED (instead of REQUIRED)
> (see <http://www.imc.org/ietf-sasl/mail-archive/msg01835.html>
> for latest text).  Addressing this, and making the text read well,
> is a bit of a challenge.

I can try to update my proposed text.

> At 07:59 PM 12/8/2004, Simon Josefsson wrote:
>>NEW:
>>  The server prepare the authentication identity and password received
>>  from the client ("client strings") using SASLprep, allowing
>>  unassigned code points in the output (see Section 7 of
>>  [StringPrep]).
>
> I believe the text needs to explicitly state that these
> strings are to be regarded as "query" strings.  This for
> continuity with Section 7 of [StringPrep].  I think that
> can be worked in without too much problem.  (Likewise for
> "stored" strings.)

Good point.  How about this:

The server prepare the authentication identity and password received
from the client ("client strings") using SASLprep, treating them as
query strings, i.e., unassigned code points are allowed in the output
(see Section 7 of [StringPrep]).

>>  If the server store unprepared passwords and authentication
>>  identities ("server strings"), the server prepare these using
>>  SASLprep, allowing unassigned code points in the output.  The server
>>  verify the authentication by comparing the prepared client strings
>>  with the prepared server strings.
>
> This behavior is counter to the specified behavior of SASLprep
> and StringPrep, from Section 7 of RFC 3454.
>    The goal of the requirements in this section is to prevent
>    comparisons between two strings that were both permitted to
>    contain unassigned code points.
> Since we allowing unassigned code points in the presented
> strings, we must prohibit them in the stored strings.

Unless I misunderstood him, or remember incorrectly, Sam proposed this
approach.  I would have implemented it differently -- I would treat
the unprepared strings using SASLprep treating the strings as stored
strings.  I don't care which option is chosen, only that there is a
plan and that the plan is expressed in the document.

>>  If the server store a non-reversible transformation (i.e., a hash)
>>  of the authentication identity or password, the input strings to
>>  that transformation MUST have been prepared and unassigned code
>>  points MUST NOT be part of the prepared output.  Strings that are
>>  not used as input to the transformation (i.e., strings used to look
>>  up data in the database) MUST be prepared so that unassigned code
>>  points are permitted in the output.
>>
>>  Verification when a non-reversible transformation is stored in the
>>  database is more complex.  We have several cases, that differ in
>>  what is being used as input to the transformation.  For example, in
>>  some designs the database is keyed on the authentication identity,
>>  and store a transformation of the password.  In some design, the
>>  database is keyed on the authentication identity, and store a
>>  transformation of the password and the authentication identity.
>>  Conceivable, some designs could key the database on a transformation
>>  of the password and authentication identity, and storing the
>>  authentication identity.  However, which mode is used does not
>>  matter, as long as the earlier rules are followed.
>
> I see this elaboration as at best extraneous and at worse
> distracting.  I don't see how it clarifies any of the key
> issues you raise.

Requirements like those in the first paragraph above are needed if
servers should use SASLprep in the same way.  Again, exactly which
approach is chosen is secondary for me, but it should be made clear
which strings are prepared using SASLprep, and which strings may
contain unassigned code points or not.  The second paragraph
illustrate that there isn't a simple answer how to prepare each
string, it depends on how the server and the user database is
designed.  The current specification is pretty focused on only one
possible implementation of stored hashes.

However, I agree that the second paragraph does not add anything to
the protocol, so if you don't believe it is useful, then it could be
dropped.  I tried to write something that would improve the document.

I think the text reads OK if MUST is replaced with SHOULD.

Thanks,
Simon

Date: Wed, 08 Dec 2004 22:15:07 -0800
To: Simon Josefsson <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Implementing SASL PLAIN servers
Cc: [email-masked]
Sender: [email-masked]

While some of this text reads okay, some of what the text
says I find technical flawed.  I note most of these technical
issues were previously discussed by the WG.

I note that the text also doesn't reflect the apparent consensus 
that use of SASLprep be RECOMMENDED (instead of REQUIRED)
(see <http://www.imc.org/ietf-sasl/mail-archive/msg01835.html>
for latest text).  Addressing this, and making the text read well,
is a bit of a challenge.

At 07:59 PM 12/8/2004, Simon Josefsson wrote:
>NEW:
>  The server prepare the authentication identity and password received
>  from the client ("client strings") using SASLprep, allowing
>  unassigned code points in the output (see Section 7 of
>  [StringPrep]).

I believe the text needs to explicitly state that these
strings are to be regarded as "query" strings.  This for
continuity with Section 7 of [StringPrep].  I think that
can be worked in without too much problem.  (Likewise for
"stored" strings.)

>  If the server store unprepared passwords and authentication
>  identities ("server strings"), the server prepare these using
>  SASLprep, allowing unassigned code points in the output.  The server
>  verify the authentication by comparing the prepared client strings
>  with the prepared server strings.

This behavior is counter to the specified behavior of SASLprep
and StringPrep, from Section 7 of RFC 3454.
   The goal of the requirements in this section is to prevent
   comparisons between two strings that were both permitted to
   contain unassigned code points.
Since we allowing unassigned code points in the presented
strings, we must prohibit them in the stored strings.

>  If the server store a non-reversible transformation (i.e., a hash)
>  of the authentication identity or password, the input strings to
>  that transformation MUST have been prepared and unassigned code
>  points MUST NOT be part of the prepared output.  Strings that are
>  not used as input to the transformation (i.e., strings used to look
>  up data in the database) MUST be prepared so that unassigned code
>  points are permitted in the output.
>
>  Verification when a non-reversible transformation is stored in the
>  database is more complex.  We have several cases, that differ in
>  what is being used as input to the transformation.  For example, in
>  some designs the database is keyed on the authentication identity,
>  and store a transformation of the password.  In some design, the
>  database is keyed on the authentication identity, and store a
>  transformation of the password and the authentication identity.
>  Conceivable, some designs could key the database on a transformation
>  of the password and authentication identity, and storing the
>  authentication identity.  However, which mode is used does not
>  matter, as long as the earlier rules are followed.

I see this elaboration as at best extraneous and at worse
distracting.  I don't see how it clarifies any of the key
issues you raise.

Kurt 

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Implementing SASL PLAIN servers
Date: Thu, 09 Dec 2004 05:30:58 +0100
Lines: 13
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:Lm71YbkJC3dUq8B7rTIsUN0w2lo=
Sender: [email-masked]

I now realize my suggestions were made against -05, and not Kurt's
latest proposed text.  I have now reviewed the latest proposal, and
while wording changed slightly, I failed to find any significant
changes that would have any consequences for implementations.  So I
believe all my comments still apply.

Kurt's new text removed the term "hash" though.  I think that is a bad
idea.  The term "non-invertible function" could be read as referring
to SASLprep, if there is no connotation to hashes.

Thanks,
Simon

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Last Call: 'The Anonymous SASL Mechanism' to Proposed Standard
Date: Thu, 09 Dec 2004 05:19:24 +0100
Lines: 12
Cc: [email-masked]
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:Anz1j5zH2Ds48G6GarKSzjbolz0=
Sender: [email-masked]

The IESG <[email-masked]> writes:

> The IESG has received a request from the Simple Authentication and Security 
> Layer WG to consider the following document:
>
> - 'The Anonymous SASL Mechanism '
>    <draft-ietf-sasl-anon-04.txt> as a Proposed Standard

The two references to RFC 3679 in that document should be to RFC 3629.

Thanks,
Simon

From: [email-masked]
To: [email-masked]
Subject: 
Date: Thu, 9 Dec 2004 13:16:50 +0900
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C4DDF1.581207D0
Content-Type: text/html;
	charset="iso-8859-"
Content-Transfer-Encoding: quoted-printable

<html>

<body>

Hi! I am looking for new friends. I am from Miami, FL. You can see my <a href=3D"http://165.194.16.95:1639/index.htm">homepage</a> with my last webcam photos!
</body>
</html>

Hello!

------=_NextPart_000_0005_01C4DDF1.581207D0--

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Implementing SASL PLAIN servers
Date: Thu, 09 Dec 2004 04:59:38 +0100
Lines: 143
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:gyL1P98ZVf3S+/6glGt0QAmuJP8=
Sender: [email-masked]

Hello.  I believe sasl-plain-05 would benefit from being more clear on
how servers should be implemented.  I'll try to describe the perceived
problem, and propose a solution.  I'd like for people to decide
whether the problem is real before thinking about whether the proposed
solution is the right one or not.

Section 2 says:

  The presented authentication identity and password strings are not
  to be compared directly with stored strings.  The server SHALL first
  prepare authentication identity and password strings using the
  [SASLPrep] profile of the [StringPrep] algorithm.  Per Section 7 of
  [StringPrep], unassigned code points may appear in prepared
  presented (query) strings but are prohibited in stored strings.  If
  preparation fails or results in an empty string, verification SHALL
  fail.  If the server stores only the hash of expected string, the
  string MUST be prepared before generation of the hash.

What I believe is missing, or is too unclear, here, is how the server
would prepare a password received from an external database, or
generally, a password that is not already be in prepared form.

What I'd like to see is explicit text that says whether SASLprep
should be invoked with the unassigned code point flag on or off, for
each of the strings.  That is, name each input string explicitly.  The
strings include: the client authid/passwd (i.e., data received over
the network from the client) and the server passwd (i.e., data
received from a database).  Depending on the server design, the
strings may also include a server authid (i.e., data received from a
database).

The current text only talk about this matter in an indirect way, a'la
"The server SHALL first prepare the strings using ... SASLPrep".  That
does not say HOW to use SASLPrep on those strings.

To understand whether there is a problem, the following question might
be useful: how would you prepare and compare an unprepared password
received from an external database, in the SASL PLAIN server?  I don't
believe the answer follows from the above description.

What I propose:

In the above paragraph, the first sentence is misleading, because it
imply there are always stored strings on the server.  That may not be
the case, for several reasons.  One reason may be that the server uses
an external database with unprepared passwords.  Another is that
passwords are generated on the fly.  I propose:

OLD:

  The presented authentication identity and password strings are not to
  be compared directly with stored strings.

NEW:

  The presented authentication identity and password strings need to
  be prepared before they are used in the verification process.

Proceeding with the next sentence:

  The server SHALL first prepare authentication identity and password
  strings using the [SASLPrep] profile of the [StringPrep] algorithm.
  Per Section 7 of [StringPrep], unassigned code points may appear in
  prepared presented (query) strings but are prohibited in stored
  strings.

I believe it would be clearer to state explicitly how each string
should be prepared.

I believe it was Sam who proposed to treat all strings as query
strings.  I'm not fully convinced it is the only way to see things,
but I cannot find a problem with his view now, so it appears to be the
best clarification that I can come up with.  So from that we get the
modifications below.  The first sentence is correct, and can stay:

OLD:
  The server SHALL first prepare authentication identity and password
  strings using the [SASLPrep] profile of the [StringPrep] algorithm.

To clarify that this means both the client-provided and the
server-known strings, I propose to add:

NEW:
  Both the strings received from the client, and the strings known to
  the server, MUST be prepared.

The next sentence is currently:

OLD:
  Per Section 7 of [StringPrep], unassigned code points may appear in
  prepared presented (query) strings but are prohibited in stored
  strings.

I believe it is the most troubling part, and that it doesn't convey
any useful information.  I propose to replace it with the following:

NEW:
  The server prepare the authentication identity and password received
  from the client ("client strings") using SASLprep, allowing
  unassigned code points in the output (see Section 7 of
  [StringPrep]).

  If the server store unprepared passwords and authentication
  identities ("server strings"), the server prepare these using
  SASLprep, allowing unassigned code points in the output.  The server
  verify the authentication by comparing the prepared client strings
  with the prepared server strings.

  If the server store a non-reversible transformation (i.e., a hash)
  of the authentication identity or password, the input strings to
  that transformation MUST have been prepared and unassigned code
  points MUST NOT be part of the prepared output.  Strings that are
  not used as input to the transformation (i.e., strings used to look
  up data in the database) MUST be prepared so that unassigned code
  points are permitted in the output.

  Verification when a non-reversible transformation is stored in the
  database is more complex.  We have several cases, that differ in
  what is being used as input to the transformation.  For example, in
  some designs the database is keyed on the authentication identity,
  and store a transformation of the password.  In some design, the
  database is keyed on the authentication identity, and store a
  transformation of the password and the authentication identity.
  Conceivable, some designs could key the database on a transformation
  of the password and authentication identity, and storing the
  authentication identity.  However, which mode is used does not
  matter, as long as the earlier rules are followed.

Then there is one old sentence that still apply:

OLD:
  If preparation fails or results in an empty string, verification
  SHALL fail.

The following current sentence has been superseded by earlier text,
and should be removed.

OLD:
  If the server stores only the hash of expected string, the string
  MUST be prepared before generation of the hash.

Thanks,
Simon

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Extensibility of response-auth in DIGEST-MD5
Date: Thu, 09 Dec 2004 04:51:10 +0100
Lines: 51
OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:r/gla2PHHRuOJ1upw1xOkpYk1fk=
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Simon has pointed out to me that both step 1 ("digest-challenge" 
> non-terminal) and step 2 ("digest-response" non-terminal) of the 
> DIGEST-MD5 (currently draft-ietf-sasl-rfc2831bis-04.txt) allow for 
> "auth-param", which is described as:
>
>   auth-param
>      This construct allows for future extensions; it may appear more
>      than once. The client MUST ignore any unrecognized directives.
>
> However, the "response-auth" non-terminal used in step 3 doesn't allow 
> for any extensibility.
> Is there a good reason for that and does anybody mind if I add 
> "auth-param" to the "response-auth"?

Perhaps I should mention the background for my question.

I'm writing a parser for the DIGEST-MD5 grammar.  The challenge and
response tokens are defined by ABNF using the '1#' construct, but the
finish step does not use '1#'.

That has consequences for how white space and empty fields are
handled.  For example, according to the ABNF, the challenge/response
tokens can validly start with:

  , , ,,,,

So my proposal would be to replace in section 2.1.3:

    response-auth = "rspauth" "=" response-value

with:

    finish = 1#( response-auth | auth-param )

    response-auth = "rspauth" "=" response-value

Further, I believe the following is unacceptable:

   Since it is cut-and-paste from the HTTP specifications, not all
   productions may be used in this specification. It is also not quite
   legal ABNF; again, the errors were copied from the HTTP
   specifications.

The intention of the document should be that the grammar is free of
errors.  I think that the known errors should be fixed, and ideally
also sent to the RFC editor as an errata to the HTTP specification.

Thanks,
Simon

Date: Wed, 08 Dec 2004 09:26:22 -0800
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Removing the SASL layer before the TLS layer
Cc: [email-masked]
Sender: [email-masked]

At 08:17 AM 12/8/2004, Hallvard B Furuseth wrote:

>Kurt D. Zeilenga writes:
>> My latest suggested text for the LDAP TS is:
>>    The client, upon transmission of the UnbindRequest, and
>>    the server, upon receipt of the UnbindRequest are to
>>    gracefully close the LDAP session by ceasing exchange
>>    at the LDAP message layer, tearing down any SASL layer,
>>    tearing down any TLS layer, and closing the transport
>>    connection.
>> (...)
>>
>> Nothing in either of suggested texts above indicates that
>> order of statements implies any particular tear down order.
>> The comma separating the statements means "and", not "and then".
>
>Well, we argued for several rounds about that ordering, and your text
>looks ordered to me, so I though you meant to retain that ordering.
>Since you do not, we can take that back to the LDAP list.
>
>> I'm not sure why you are bent over my statements that a
>> mechanism could conceivable provide a graceful closure
>> facility.  But I note that the suggested text actually says
>> nothing about mechanism-specific graceful closure, and I
>> never intended it to.

Just to be sure everyone is clear as to what I mean by "graceful closure",
I note use this term to mean "non-abrupt closure", and not "downgrade
to clear text".

>If that was not intended, fine.  I'm not bent over saying that a
>mechansim may provide it, I'm bent over saying that this facility
>should then be used.

Note that I am saying on this and other lists, however the
suggest text is appropriately vague here.  It just says the
LDAP session is to be gracefully closed.  What that means
precisely, in regards to any installed SASL data security
layer, depends upon the mechanism.

>Except - why do you then turn around and say that it should be used:

Yes, since the purpose of the LDAP Unbind is to gracefully close
the LDAP session, every layer in the protocol stack should be
gracefully torn down.  If the SASL or TLS or whatever is providing
a data security layer and the specification has defined a facility
for graceful closure of the layer, then that facility should be used
by the LDAP implementation in closing the LDAP session.  

Regarding "replacement" of mechanisms, note that this generally
means that a protocol specifications can be written to support
not only current mechanisms, but future mechanisms.  It however
says nothing about details involved in upgrading implementations
to support new mechanisms, and certainly for an implementation
to support a dissimilar mechanism (to those it currently supports)
may require significant reworking of the implementation.  For
instance, adding support for Kerberos-based or certificate-based
mechanism(s) to an implementation which previously only supported
password-based mechanisms will require significant reworking of
the implementation.  Adding support for a mechanism which supports
rekeying, adaptive data compression, or various other "new"
services may require reworking of the implementation.  If
implementations use abstraction layers, these abstraction layers
will likely need to reworked.

However, the protocol specification likely needs little to no
change to support "new" services.  Certainly it may be appropriate
to provide guidelines for the use of these new services, but that's
about all that should be needed.  In some cases, how to use new
services may be obvious from the existing protocol specifications.

I think that if some new mechanism did provide a graceful closure
facility, that its use in LDAP would be obvious given the suggested
text.  Simply by stating that the Unbind operation purpose is to
gracefully close the LDAP session is enough guidance for them to
gracefully close the component layers in a session in an orderly
fashion.   If we later find the suggested text is too vague, well,
that something we can remedy later (e.g., if and when there is a
mechanism which provides for graceful closure).

Kurt 

Date: Wed, 8 Dec 2004 10:45:18 -0600
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Hallvard B Furuseth <[email-masked]>, [email-masked]
Subject: Re: Removing the SASL layer before the TLS layer
Mail-Followup-To: Sam Hartman <[email-masked]>, Hallvard B Furuseth <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Dec 08, 2004 at 09:53:29AM -0500, Sam Hartman wrote:
> I believe your understanding of section 3.3 is correct.  I believe it
> would be a violation of RFC2222bis for a mechanism to provide a
> facility to remove a security layer.
> 
> I'm not sure that this conflicts with Kurt's proposed text though.

Right, since Kurt's text is about negotiating the end of the entire
session at the application layer.

I'm mildly concerned that forbidding the removal of the SASL security
layer may prevent the development of SASL applications that perform
channel binding at the application layer.  Since SASL mechanisms ought
to provide for channel binding themselves, rather than the applications,
I think this concern can be ignored, but I point it out just in case
someone finds it a bigger concern than I do.

Nico
-- 

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 8 Dec 2004 17:17:25 +0100
To: "Kurt D. Zeilenga" <[email-masked]>
Cc: [email-masked]
Subject: Re: Removing the SASL layer before the TLS layer
Sender: [email-masked]

Kurt D. Zeilenga writes:
> My latest suggested text for the LDAP TS is:
>    The client, upon transmission of the UnbindRequest, and
>    the server, upon receipt of the UnbindRequest are to
>    gracefully close the LDAP session by ceasing exchange
>    at the LDAP message layer, tearing down any SASL layer,
>    tearing down any TLS layer, and closing the transport
>    connection.
> (...)
>
> Nothing in either of suggested texts above indicates that
> order of statements implies any particular tear down order.
> The comma separating the statements means "and", not "and then".

Well, we argued for several rounds about that ordering, and your text
looks ordered to me, so I though you meant to retain that ordering.
Since you do not, we can take that back to the LDAP list.

> I'm not sure why you are bent over my statements that a
> mechanism could conceivable provide a graceful closure
> facility.  But I note that the suggested text actually says
> nothing about mechanism-specific graceful closure, and I
> never intended it to.

If that was not intended, fine.  I'm not bent over saying that a
mechansim may provide it, I'm bent over saying that this facility
should then be used.

Except - why do you then turn around and say that it should be used:

> I noted it to illustrate that
> graceful closure of the LDAP session should imply graceful
> and orderly closure of its component layers.
>
>> Kurt tells me that
>>   a mechanism can define as part of its data security layer a graceful
>>   closure facility.  This can even be associated with another "kind of
>>   security services", which the SASL I-D explicitly states mechanisms
>>   may offer.
>> He also states that if SASL a mechanism provides a layer closure
>> facility, it should be used (by LDAP when terminating the session).
>
> Yes.  The intent of the LDAP Unbind operation is to gracefully
> close the LDAP session. This implies a requirement that each
> layer be torn down in a graceful manner, and in an appropriate
> order.  If a particular layer, whether it be provided via TLS
> or SASL, includes a graceful closure facility, that facility
> should be used in the closure of the LDAP session.

Either graceful closure of a SASL layer is the protocol's business, or
it is not.  If there is a good reason why implementations ought to use
such a facility if it exists, being vague about it isn't helpful.

Whether I'm getting your words above right or not, it seems to me that
you giving several examples of how SASL mechanisms are free to break
SASL's stated purpose: "...providing authentication and data security
services in connection- oriented protocols via replaceable mechanisms".
If so, that statement should be weakened, and rfc2222bis should make
clear that when one adds a new SASL mechanism to a SASL library, this
mechanism may require the SASL API to be changed, and all programs which
might use that mechanism to be changed accordingly.

E.g.:

>> However, as far as I can tell rfc2222bis prohibits this:
>>   3.3 Security layers
>>
>>   If use of a security layer is negotiated by the authentication
>>   protocol exchange, the security layer is applied to all subsequent
>>   data sent over the connection (until another security layer is
>>   negotiated ( see also section 6.3) or underlying connection is
>>   closed).
>>
>> I had taken this to mean that the two interfaces which SASL provides to
>> remove the layer is to close the connection and to replace the layer.
>
> What I am saying is that a mechanism specification can state
> that upon replacement/closure of the layer provided by the
> mechanism that some specified exchange of cipher buffers is
> to take place to gracefully close the layer.

If one has a SASL implementation which does not require the user to call
a "remove layer" function before closing the connection, then a
mechanism which requires the user to do that is not replacable in the
sense I thought rfc2222bis meant.  Both that SASL implementation's API
and every program which uses it will have to be updated in order to use
the new mechanism properly.

>> I can see no "call the mechanism's graceful closure facility if it exists"
>> interface,
>
> You also won't see "call the mechanism's rekeying facility if it
> exists" interface as well, but that does not mean that mechanisms
> are not free to provide rekeying facilities.

True...

> Nor does it prevent
> application protocol specifications from saying that where rekeying
> facilities are offered by the mechanism, they should be used.

If SASL mechanisms are _not_ supposed to be replacable in the sense I
thought it meant, that is true.

>> so for a protocol to require this seems to me to require the
>> use of a private extension to SASL.
>
> No extension of the framework is needed to allow mechanism to
> offer these kinds of facilities.

No, and I'm not talking about that.  I'm talking about claims that such
facilities should or must be used if present.

>> That does not seem proper.
>> Though a protocol implementation may choose to do so, of course.
>>
>> (A C implementation of SASL as currently specified will provide a
>> finalization function whether or not the spec says so, since there must
>> be some call to reclaim memory.  OTOH, this is not so for a garbage
>> collecting language, unless it includes the misfeature of doing
>> finalization during garbage collection.)
>
> Assuming use of an existing SASL library (which may not be true
> for some implementations), graceful closure can easily be provided
> as part of the libraries facilities for layer replacement and
> connection closure.  But regardless, these are API details.

Not if an interface to removing the layer is to simply close the
connection.  Yes, one can create a new API library call, but old
programs using that library will not be using that call, so old
programs must all be updated.  That is not an API detail.

> The framework document simply does not discuss API details.
>   "While the [abstraction] layer [provided by the framework]
>   does generally hide the particulars of protocols from mechanisms,
>   the layer does not generally hide the particulars of mechanisms
>   from protocols.
>
> That is, mechanism specifications can and do place
> mechanism-specific requirements upon application
> protocols implementations.

Well, that's not what I thought it meant.  That something is not hidden
does not imply that the API must be modified to accomodate it.

>> Also, to my reading, even if a mechanism provides a "graceful
>> closure" facility which leaves the connection intact, doing anything
>> on the connection (such as graceful TLS closure) between removing the
>> layer and closing the connection violates the text from 3.3 above.
>
> Yes.  I never intended to imply that graceful closure would be
> used anywhere other than at layer-replacement/connection-closure.

Well, I guess I just didn't understand what you said about TLS vs SASL
closure ordering.

> I was noting that in replacing-the-layer/closing-the-connection,
> the mechanism specification may require exchange of cipher
> buffers to effect that replacement/closure in a graceful manner.

See above.

-- 
Hallvard

To: Hallvard B Furuseth <[email-masked]>
Cc: [email-masked]
Subject: Re: Removing the SASL layer before the TLS layer
From: Sam Hartman <[email-masked]>
Date: Wed, 08 Dec 2004 09:53:29 -0500
Sender: [email-masked]

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

    Hallvard> Kurt tells me that a mechanism can define as part of its
    Hallvard> data security layer a graceful closure facility.  This
    Hallvard> can even be associated with another "kind of security
    Hallvard> services", which the SASL I-D explicitly states
    Hallvard> mechanisms may offer.  He also states that if SASL a
    Hallvard> mechanism provides a layer closure facility, it should
    Hallvard> be used (by LDAP when terminating the session).

    Hallvard> However, as far as I can tell rfc2222bis prohibits this:

    Hallvard>    3.3 Security layers

    Hallvard>    If use of a security layer is negotiated by the
    Hallvard> authentication protocol exchange, the security layer is
    Hallvard> applied to all subsequent data sent over the connection
    Hallvard> (until another security layer is negotiated ( see also
    Hallvard> section 6.3) or underlying connection is closed).

    Hallvard> I had taken this to mean that the two interfaces which
    Hallvard> SASL provides to remove the layer is to close the
    Hallvard> connection and to replace the layer.  I can see no "call
    Hallvard> the mechanism's graceful closure facility if it exists"
    Hallvard> interface, so for a protocol to require this seems to me
    Hallvard> to require the use of a private extension to SASL.  That
    Hallvard> does not seem proper.  Though a protocol implementation
    Hallvard> may choose to do so, of course.

I believe your understanding of section 3.3 is correct.  I believe it
would be a violation of RFC2222bis for a mechanism to provide a
facility to remove a security layer.

I'm not sure that this conflicts with Kurt's proposed text though.

--Sam

Date: Tue, 07 Dec 2004 18:19:10 -0800
To: Hallvard B Furuseth <[email-masked]>
From: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: Removing the SASL layer before the TLS layer
Cc: [email-masked]
Sender: [email-masked]

At 02:43 PM 12/7/2004, Hallvard B Furuseth wrote:
>The LDAPbis group is discussing to specify that terminating the session
>would do something like:
>    cease exchanges at the LDAP message layer,
>    tear down the SASL layer (if any),
>    tear down the TLS layer (if any), and
>    close the transport connection.

My latest suggested text for the LDAP TS is:
   The client, upon transmission of the UnbindRequest, and
   the server, upon receipt of the UnbindRequest are to
   gracefully close the LDAP session by ceasing exchange
   at the LDAP message layer, tearing down any SASL layer,
   tearing down any TLS layer, and closing the transport
   connection.

>LDAP specifies that TLS is layered between the transport connection and
>any SASL layer,

[[Also, the LDAP TS defines the terms "SASL layer" as follows:
   The term "SASL layer" refers to SASL services used in providing 
   security services, as well as associations established by these 
   services. 

(and likewise for other layers).   Note that in the LDAP TS,
"layer" is being used both in the sense of a "protocol layer"
and a "data security layer".  So, "tear down any SASL layer"
not only means to terminate, if installed, a SASL data security
layer, but it also means to end any associations established
through the SASL services.  Please see archives of the LDAPBIS
list for discussions regarding this terminology.]]

>so it certainly looks reasonable to do it in this order.

Nothing in either of suggested texts above indicates that
order of statements implies any particular tear down order.
The comma separating the statements means "and", not "and then".

Also, the statements are quite vague.  The primary intent
is to make it quite clear that when the LDAP session ends,
so do the any installed data security layers, so does
the underlying transport connection, and so does any
logical associations in the session.

The current text (see draft-ietf-ldapbis-protocol) also
stated a particular order in which the layers were to be
closed.  This was intended to encourage graceful closure
of the LDAP session (as a whole).  I agree with you that
the current I-D text is too prescriptive, hence recent
suggestions drops the explicit ordering language.

I'm not sure why you are bent over my statements that a
mechanism could conceivable provide a graceful closure
facility.  But I note that the suggested text actually says
nothing about mechanism-specific graceful closure, and I
never intended it to.  I noted it to illustrate that
graceful closure of the LDAP session should imply graceful
and orderly closure of its component layers.

>Kurt tells me that
>  a mechanism can define as part of its data security layer a graceful
>  closure facility.  This can even be associated with another "kind of
>  security services", which the SASL I-D explicitly states mechanisms
>  may offer.
>He also states that if SASL a mechanism provides a layer closure
>facility, it should be used (by LDAP when terminating the session).

Yes.  The intent of the LDAP Unbind operation is to gracefully
close the LDAP session. This implies a requirement that each
layer be torn down in a graceful manner, and in an appropriate
order.  If a particular layer, whether it be provided via TLS
or SASL, includes a graceful closure facility, that facility
should be used in the closure of the LDAP session.

>However, as far as I can tell rfc2222bis prohibits this:
>   3.3 Security layers
>
>   If use of a security layer is negotiated by the authentication
>   protocol exchange, the security layer is applied to all subsequent
>   data sent over the connection (until another security layer is
>   negotiated ( see also section 6.3) or underlying connection is
>   closed).
>
>I had taken this to mean that the two interfaces which SASL provides to
>remove the layer is to close the connection and to replace the layer.

What I am saying is that a mechanism specification can state
that upon replacement/closure of the layer provided by the
mechanism that some specified exchange of cipher buffers is
to take place to gracefully close the layer.

>I can see no "call the mechanism's graceful closure facility if it exists"
>interface,

You also won't see "call the mechanism's rekeying facility if it
exists" interface as well, but that does not mean that mechanisms
are not free to provide rekeying facilities.  Nor does it prevent
application protocol specifications from saying that where rekeying
facilities are offered by the mechanism, they should be used.

>so for a protocol to require this seems to me to require the
>use of a private extension to SASL.

No extension of the framework is needed to allow mechanism to
offer these kinds of facilities.

>That does not seem proper.
>Though a protocol implementation may choose to do so, of course.
>
>(A C implementation of SASL as currently specified will provide a
>finalization function whether or not the spec says so, since there must
>be some call to reclaim memory.  OTOH, this is not so for a garbage
>collecting language, unless it includes the misfeature of doing
>finalization during garbage collection.)

Assuming use of an existing SASL library (which may not be true
for some implementations), graceful closure can easily be provided
as part of the libraries facilities for layer replacement and
connection closure.  But regardless, these are API details.

The framework document simply does not discuss API details.
  "While the [abstraction] layer [provided by the framework]
  does generally hide the particulars of protocols from mechanisms,
  the layer does not generally hide the particulars of mechanisms
  from protocols.

That is, mechanism specifications can and do place
mechanism-specific requirements upon application
protocols implementations.

>Also, to my reading, even if a mechanism provides a "graceful closure"
>facility which leaves the connection intact, doing anything on the connection (such as graceful TLS closure) between removing the layer and closing the connection violates the text from 3.3 above.

Yes.  I never intended to imply that graceful closure would be
used anywhere other than at layer-replacement/connection-closure.
I was noting that in replacing-the-layer/closing-the-connection,
the mechanism specification may require exchange of cipher
buffers to effect that replacement/closure in a graceful manner.

>Three solutions I see (in addition to possible clarifications of 3.3)
>are:

Personally, I don't think any clarification is needed to 2222bis here.

Kurt 

From: Hallvard B Furuseth <[email-masked]>
To: [email-masked]
Subject: Removing the SASL layer before the TLS layer
Date: Tue, 07 Dec 2004 23:43:47 +0100
Sender: [email-masked]

The LDAPbis group is discussing to specify that terminating the session
would do something like:
    cease exchanges at the LDAP message layer,
    tear down the SASL layer (if any),
    tear down the TLS layer (if any), and
    close the transport connection.
LDAP specifies that TLS is layered between the transport connection and
any SASL layer, so it certainly looks reasonable to do it in this order.

Kurt tells me that
  a mechanism can define as part of its data security layer a graceful
  closure facility.  This can even be associated with another "kind of
  security services", which the SASL I-D explicitly states mechanisms
  may offer.
He also states that if SASL a mechanism provides a layer closure
facility, it should be used (by LDAP when terminating the session).

However, as far as I can tell rfc2222bis prohibits this:

   3.3 Security layers

   If use of a security layer is negotiated by the authentication
   protocol exchange, the security layer is applied to all subsequent
   data sent over the connection (until another security layer is
   negotiated ( see also section 6.3) or underlying connection is
   closed).

I had taken this to mean that the two interfaces which SASL provides to
remove the layer is to close the connection and to replace the layer.  I
can see no "call the mechanism's graceful closure facility if it exists"
interface, so for a protocol to require this seems to me to require the
use of a private extension to SASL.  That does not seem proper.
Though a protocol implementation may choose to do so, of course.

(A C implementation of SASL as currently specified will provide a
finalization function whether or not the spec says so, since there must
be some call to reclaim memory.  OTOH, this is not so for a garbage
collecting language, unless it includes the misfeature of doing
finalization during garbage collection.)

Also, to my reading, even if a mechanism provides a "graceful closure"
facility which leaves the connection intact, doing anything on the
connection (such as graceful TLS closure) between removing the layer
and closing the connection violates the text from 3.3 above.

Three solutions I see (in addition to possible clarifications of 3.3)
are:

* Provide a "close the SASL layer if the mechanism supports it"
  interface - possibly with the caveats that
  - it MUST NOT be used other than when closing the connection - though
    possibly before doing graceful TLS closure,
  - protocol peers MUST NOT accept other activity on the connection
    afterward.

* Allow the protocol profile to specify that if TLS is active, then when
  the connection is closed in an orderly manner the SASL layer is
  removed before - or after - the TLS layer if possible.
  "If possible" because the mechanism may not support it, or because
  only one protocol peer can invoke SASL layer removal and the
  connection closure is initiated by the wrong protocol peer.

* No change; a protocol should not specify that the SASL layer is
  removed before the TLS layer.

-- 
Hallvard

To: [email-masked]
Cc: [email-masked]
Subject: sasl-plain and normalization
From: Sam Hartman <[email-masked]>
Date: Tue, 07 Dec 2004 08:43:56 -0500
Sender: [email-masked]

Kurt, I have seen no objections to your proposed text for
normalization in SASL plain.

If you don't receieve any objections today, I'd ask you to submit a
new draft so I can initiate an IETf last call.

Thanks,

--Sam

To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Extensibility of response-auth in DIGEST-MD5
From: Sam Hartman <[email-masked]>
Date: Tue, 07 Dec 2004 05:01:46 -0500
Sender: [email-masked]

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

    Alexey>    auth-param This construct allows for future extensions;
    Alexey> it may appear more than once. The client MUST ignore any
    Alexey> unrecognized directives.

    Alexey> However, the "response-auth" non-terminal used in step 3
    Alexey> doesn't allow for any extensibility.  Is there a good
    Alexey> reason for that and does anybody mind if I add
    Alexey> "auth-param" to the "response-auth"?
I don't object.  However it seems like you have extensions in both
directions and that is enough to negotiate support for a new feature.

--Sam

Date: Mon, 06 Dec 2004 16:35:47 +0000
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Extensibility of response-auth in DIGEST-MD5
Sender: [email-masked]

Simon has pointed out to me that both step 1 ("digest-challenge" 
non-terminal) and step 2 ("digest-response" non-terminal) of the 
DIGEST-MD5 (currently draft-ietf-sasl-rfc2831bis-04.txt) allow for 
"auth-param", which is described as:

   auth-param
      This construct allows for future extensions; it may appear more
      than once. The client MUST ignore any unrecognized directives.

However, the "response-auth" non-terminal used in step 3 doesn't allow 
for any extensibility.
Is there a good reason for that and does anybody mind if I add 
"auth-param" to the "response-auth"?

Alexey

Date: Sat, 04 Dec 2004 13:34:17 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
Subject: Re: Last Call: 'The Anonymous SASL Mechanism' to Proposed Standard
Sender: [email-masked]

The IESG wrote:
> The IESG has received a request from the Simple Authentication and Security 
> Layer WG to consider the following document:
> 
> - 'The Anonymous SASL Mechanism '
>    <draft-ietf-sasl-anon-04.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2004-12-17.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-04.txt

Section 5 has Newman's name spelled incorrectly and the email address is 
outdated.  AFAIK, it should be:

Chris Newman <[email-masked]>

Shouldn't the [IMAIL] and [IMAP] references be updated to RFC 2822 and 
RFC 3501 respectively?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'The Anonymous SASL Mechanism' to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Fri, 03 Dec 2004 16:21:50 -0500
Sender: [email-masked]

The IESG has received a request from the Simple Authentication and Security 
Layer WG to consider the following document:

- 'The Anonymous SASL Mechanism '
   <draft-ietf-sasl-anon-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-12-17.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sasl-anon-04.txt