Re: more SASLprep/protocol problems

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:

> I think here are opposing objectives.   One fraction of the
> community is attempting to improve interoperability between
> independently developed implementations.  One faction is
> attempting to support legacy systems.

Are there some implementations that do prepare passwords, or at least
translate them to UTF-8, and are widely used on non-ASCII or ASCII-
superset sites with hashed passwords, and thus prove that the problem
is smaller than I think?

> (Note: It is possible to split the preparation between the client
> and the server, PLAIN does this (client handles transcoding
> to Unicode and UTF-8 encoding, server handles SASLprep).  With
> LDAP, this is not a good option as the server has no way to
> determine whether the password is textual or not.)

I've seldom wondered about so many things in so short a statement:-)

What do you mean by textual and non-textual passwords, exactly?

Why are PLAIN passwords more textual than LDAP passwords?  Is it simply
because PLAIN _requires_ passwords to be UTF-8 which is presumably text,
while LDAP only will recommend it?

If the server and therefore the sysadmin doesn't know whether to prepare
a bind password or not, how is the client supposed to know - unless the
user tells it?

Which scenario are you thinking of when you say the server doesn't know?
Not that I disagree that client-side preparation is most flexible,
but... usually all passwords will be UTF-8 or none of them will,
depending on how the sysadmin put them there, so the server will know.
OTOH, the server won't know if they should be prepared if the users
stored userPasswords as they pleased, both UTF-8 and non-UTF-8.  But
then you _really_ need a client option to say whether or not to prepare
bind passwords, so I don't suppose that's what you are talking about...
(Hey! That's another argument for recommending that client option!:-)

> How's this?
>
>      The simple form of an AuthenticationChoice specifies a simple
>      password to be used for authentication.  To improve matching
>      of textual passwords, clients SHOULD prepare textual passwords
>      for transfer by transcoding to [Unicode], applying [SASLprep],
>      and encoding as UTF-8.  Clients MAY prepare textual passwords
>      using other algorithms (including null preparation) to support,
>      for instance, legacy systems.  Non-textual passwords MUST NOT
>      be mutated.

I should mention that I do prefer that text over the current one, though
as you know I still want options.  I'd prefer to replace "legacy
systems" with something like "servers using existing hashed password
stores", since "legacy systems" has rather negative connotations.  Also
I wonder what "Non-textual passwords MUST NOT be mutated" means, see
comments above.

-- 
Hallvard