Re: Schema: encrypted 8-bit userPassword and SASLprep

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

Since [Schema] says userPassword must be stored unencrypted, I'll switch
to talk about this text in [Protocol] 4.2 (Bind Operation), and passwords
stored encrypted in the server in some other way than userPassword:

     To improve matching, applications SHOULD prepare textual strings
     used as passwords. Applications which prepare textural strings used
     as password are REQUIRED to prepare them by transcoding the string
     to [Unicode], apply [SASLprep], and encode as UTF-8.

If we do something about that text, we can align userPassword with it
later.

BTW, it's unclear whether or not the above text only applies to simple
auth, since the previous sentence is

     The simple form of an AuthenticationChoice specifies a simple
     password to be used for authentication.

That should be clarified.


Well.  Onwards ---
John McMeeking writes:

> To perform a bind, the client application gets a password in some form --
> I'll assume some sort of string input -- and it has to create a binary
> "credentials" to send to the server.  The input bytes might be US ASCII,
> EBCDIC, some multi-byte (or 8-bit) character set, maybe a Java String.  So
> in general, the client side must perform some sort of conversion from the
> input string to that binary "credentials".

True.

> What is the target of the conversion?  This is LDAP, so UTF-8 is a
> reasonable choice.

I didn't think of that.  You may be right, but I think not - not as the
only option, anyway.  That would have been nice, but the server still
cannot convert the stored password to UTF-8 if it only knows an
encrypted form of the password.  Which is probably is rather common.  So
if it receives an UTF-8 password from the client, it must instead
convert that to the encoded character set of the stored passwords and
then match the passwords.  Unfortunately I believe the mapping from
Unicode to some character sets/encodings is 1->many or many<->many, so
the resulting passwords may not match.

Applying Strprep before binding makes this worse, since Strprep e.g.
removes some characters from the password.  The server can't put them
back before matching.

> Assuming that we don't want UTF-8, what other choices do we have?

I think this will have to be chosen by the sysadmin, but:

Another option is to treat passwords as raw binary strings.  The user
can bind with the same password that he originally set, as long as he is
using the same character set, or at least no characters that differ in
the different character sets in use.  He can't bind from somewhere using
a totally different character set, but at least it will work properly on
campus.

With EBCDIC, I suppose a third option is to treat characters common to
EBCDIC and ASCII specially.  I don't want to think about that; maybe
someone who knows EBCDIC will say something:-)

> In particular, what choices do we have that don't require the client
> to know something about the server implementation?  I don't see any.

Me neither.  And that includes the current wording.

> And I don't think it is reasonable, in general, for a client to need
> to know that the server is using a Unix /etc/password file that
> contains hashed 8-bit code page passwords (as an example).

It doesn't need to know that.  What it needs to know in that case is
that passwords on the server side are encoded the same way as on the
client side.  (To be sure, they are hashed on the server side, but the
server takes care of that detail.)

> I'll concede that there may be cases where a client needs to bind to a
> server using /etc/password with some 8-bit code page instead of UTF-8.
> Two ways to handle that come to mind:
> 1) restrict passwords to the 7-bit character set so that UTF-8 conversion
>    is not a factor

Can only be done only be done if the passwd program, or whatever users
use to change their passwords, is written by someone with this problem
in mind - e.g. someone on campus.  Even so, it may not be compatible
with EBCDIC passwords.

Another option:

1.5) If one does have a local password-changing program, let it produce
both the hash that the system needs and the UTF-8 strprep'ed hash that
LDAP needs.

> 2) provide some option in the client that allows an application that
> "knows what it is doing" to provide binary credentials that the client
> wraps in an octet string for the bind request.

Yes, that's more or less what I was suggesting.  Don't say that
applications SHOULD translate passwords unless we also say that they
SHOULD provide an option not to do so, and/or to do some implementation-
defined conversion (like EBCDIC<->ASCII).

Though I'm not sure UTF-8/strprep is a good default.  It may be better
to just say that it should provide these options.

> I think those are compatible with the proposed "the application SHOULD
> prepare..." wording.

Formally, yes.  In practice, I'd expect that wording to lead to a lot of
clients that do prepare and don't provide an option not to do so.

-- 
Hallvard