Subject: Schema: encrypted 8-bit userPassword and SASLprep

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 12 Sep 2003 13:09:26 +0200

[Schema] 2.41 (userPassword) says:

   The application SHOULD prepare textual strings used as passwords
   by transcoding them to Unicode, applying SASLprep [SASLprep], and
   encoding as UTF-8.

This is incompatible with passwords written in 8-bit character sets and
stored encrypted in files that cannot easily be decrypted, e.g. Unix
/etc/passwd files.  Since the server does not know the plaintext
passwords, it cannot prepare them as above.

Well, in some cases the server could convert the bind passwords back
from UTF-8 to a locally configured character set.  But I think that's an
ugly hack, and an impossible one on multi-charset sites (or rather,
servers that serve several different sites on one campus that have
different default character sets.)  I don't want the standard to mandate
that.

So I suggest this is added:

   The application SHOULD also provide an option to turn off such
   preparation of passwords.

The alternative would be to force sites as above to write their own
applications, which is not always feasible.  We can hardly expect them
to write their own version of Netscape, for example.

-- 
Hallvard

---

From: Michael Ströder <[email-masked]>
Date: Fri, 12 Sep 2003 14:57:17 +0200

> passwords, it cannot prepare them as above.

IMHO the password should be encoded as UTF-8 before applying the hash. Maybe 
the wording is somewhat misleading though I'm not sure.

Note that hashed passwords are non-standard anyway... ;-)

Ciao, Michael.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 12 Sep 2003 15:10:00 +0200

Michael Ströder writes:
> IMHO the password should be encoded as UTF-8 before applying the hash.
> Maybe the wording is somewhat misleading though I'm not sure.

No.  LDAP can't mandate how Unix should encode its /etc/passwd files,
and therefore also how the login, su and passwd programs should work.

> Note that hashed passwords are non-standard anyway... ;-)

No, they are irrelevant to the standard:
- The client binds with a plaintext password (hopefully inside TLS).
  So the hashed password doesn't affect the protocol.
- The server matches the password from the client against the hashed
  password, with the same algorithm as the login program does.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 12 Sep 2003 06:54:59 -0700

>   by transcoding them to Unicode, applying SASLprep [SASLprep], and

s/application/client/

The intent here was to recommend that clients prepare textual
passwords before storing them or using them (to improve
interoperability).

Note that it is not a mandate.  It is a recommendation.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 12 Sep 2003 16:02:15 +0200

> passwords before storing them or using them (to improve

Huh?  If clients do that but servers don't, the passwords won't match.

> Note that it is not a mandate.  It is a recommendation.

Sure, but if implementations follow that recommendation, sites with
servers using Unix /etc/passwd passwords are in trouble.  Unless they
also follow a recommendation to allow this to be turned off.

It applies to Windows servers too, I think - though passwords there are
apparently so easy to break that servers almost could do it during the
bind operation:-(

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 12 Sep 2003 09:15:18 -0700

>Huh?  If clients do that but servers don't, the passwords won't match.

userPassword values are matched with octetStringMatch.
If client A stores a string into userPassword and
client B asserts that the attribute contains a string,
that assertion will be True if and only those strings
are, octet-wise, the same.  The preparation ensures that
equivalent user inputted textual strings of characters
are treated as being equivalent.

>also follow a recommendation to allow this to be turned off.

I don't see how 2.41 of [Schema] applies to passwords not
held in userPassword.  ([AuthMeth] requirements might apply,
but you specifically referenced 2.41 of [Schema].)

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 12 Sep 2003 18:36:23 +0200

> are treated as being equivalent.

True.  I was thinking of the case where the userPassword attribute is
created by another means that storing it through the protocol.  Or
rather, I wasn't thinking at all, otherwise I'd have mentioned that
detail:-)

> but you specifically referenced 2.41 of [Schema].)

True.  I should have said [Schema] _and_ [Protocol].

But never mind.  As you say, let's stick to [Protocol]/[AuthMeth]
issues for now.

-- 
Hallvard