[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Schema: encrypted 8-bit userPassword and SASLprep
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". What is the target of the
conversion? This is LDAP, so UTF-8 is a reasonable choice. Assuming that
we don't want UTF-8, what other choices do we have? 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. 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).
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
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.
I think those are compatible with the proposed "the application SHOULD
prepare..." wording.
I also think it is reasonable to extend the code page conversion discussion
to SASLprep, though I admit to a great deal of ignorance in that area. My
understanding is that there are multiple ways of representing some
characters in Unicode. Just like EBCDIC and ASCII produce different byte
representations for 'A', different input sources might produce different
Unicode representations of a given character. SASLprep attempts to ensure
that those different representations are normalized so that users typing in
the same string from different sources will send the same password to the
server. A server might be able to do this normalization for simple bind,
but not for something like DIGEST-MD5.
At least that's how I understand this.
John McMeeking
Hallvard B Furuseth
<h.b.furuseth@usit.u To: Michael Ströder <michael@stroeder.com>
io.no> cc: ietf-ldapbis@OpenLDAP.org
Sent by: Subject: Re: Schema: encrypted 8-bit userPassword and SASLprep
owner-ietf-ldapbis@O
penLDAP.org
09/12/2003 08:10 AM
Michael Ströder writes:
>Hallvard B Furuseth wrote:
>> [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.
>
> 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