Subject: Re: Textual/non-textual passwords and SASLprep

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 12 Nov 2003 08:45:11 -0700

(Lifting snippets from here and there) How does this sound?
 
Textual passwords (consisting of a character sequence with a known character set and encoding) SHALL be transferred as [UTF-8] encoded [Unicode]. 
The determination of whether a password is textual is a local client matter.   
Prior to transfer, clients SHOULD prepare text passwords by applying the [SASLprep] profile of the [Stringprep] algorithm. 
Passwords consisting of other data (such as random octets) MUST NOT be altered. 

Jim

>>> Michael Ströder <[email-masked]> 11/12/03 7:38:55 AM >>>
Hallvard B Furuseth wrote:
> Michael Ströder writes:
> 
>>
>>Even if passwords are read from file they can be textual ;-)
> 
> I quite agree, but that seemed to be what you suggested in article
> < http://www.openldap.org/lists/ietf-ldapbis/200305/msg00112.html >, which
> you referred me to when I asked how to tell if a password was textual.

There's no text in my former posting stating that textual passwords can't be 
read from a file.

>>and the application MUST have the a-priori knowledge to decide what to
>>do with passwords stored in file. Which mainly boils down to that you
>>also have to specify your file format exactly and your application
>>following the format correctly.
> 
> So the password file contains a mark which says whether the following
> password is textual or not, or something like that?

Not necessarily. That's simply subject of local definition.

>>Hallvard, I have to admit that I don't see your problem at all... :-/
> 
> I want [Protocol] to either say something about how to decide if a
> password is textual or not (even if it's just "it's the client's
> responsibility to know this"),

Then we go for "it's the client's responsibility to know this a priori". ;-)

> or to drop the SHALL/MUST treat
> textual and non-textual passwords differently.

No!

> For example, am I doing anything wrong if I
> declare that passwords given to my client are always non-textual, even
> passwords typed in by users, maybe unless the user gives an option
> saying they are textual?

Even "passwords typed in by users" could be binary. ;-)

Since you cited my former posting I'll grab text from there:

"More formally one could define textual passwords as a character sequence 
with a known character set and encoding."

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 12 Nov 2003 17:37:42 +0100

> Passwords consisting of other data (such as random octets) MUST NOT be altered. 

Sounds ok for me.

Ciao, Michael.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 12 Nov 2003 18:03:27 +0100

Jim Sermersheim writes:
> Textual passwords (consisting of a character sequence with a known
> character set and encoding) SHALL be transferred as [UTF-8] encoded
> [Unicode].  The determination of whether a password is textual is a
> local client matter.  Prior to transfer, clients SHOULD prepare text
> passwords by applying the [SASLprep] profile of the [Stringprep]
> algorithm.  Passwords consisting of other data (such as random octets)
> MUST NOT be altered.

OK for the client-side passwords.

On the server side, I think it should be specified that the server
itself does not apply [SASLprep] to Simple Bind; one should apply
[SASLprep] before storing a textual password in the server.  (The SASL
bind case is more complicated, see below.)  The userPassword text in
[syntaxes] might then refer to this text.

[SASL] will probably recommend SASL mechanism definitions to specify
that the server does apply [SASLprep] to server-side passwords, see
message
  http://www.imc.org/ietf-sasl/mail-archive/msg01134.html
and, if you wish, the surrounding thread.

Maybe LDAP (authmeth) should override this, and emphasize that SASLprep
must be expected to have been applied already.  I'm not sure if that
will be possible - maybe some SASL implementations will not offer an
option to _not_ apply SASLprep to server-side passwords?

Or we could accept that with SASL methods, the server may apply SASLprep
even to non-textual passwords (since I take it the server doesn't know
which passwords are textual), or to textual passwords which incorrectly
have not been SASLprep'ed.  Which would mean that simple bind could fail
and SASL bind could succeed with the same incorrect password.  That's a
bit ugly, but I don't know if it's important enough to worry about.  In
particular since simple bind in any case could succeed when SASL bind
fails with the same _correct_ non-textual password - since SASL bind
would incorrectly assume the password was textual and apply SASLprep.

A final option is to bring the issue up at the SASL list, and request
that protocol profiles may specify that the server should not apply
SASLprep to server-side passwords, but depend on it already having been
applied.  They may dislike such an increase of the protocol profile,
which is getting big enough already.

-- 
Hallvard