Re: userPassword Octet String

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 04:46 PM 5/16/01, Michael Ströder wrote:
>attributetype ( 2.5.4.35 NAME 'userPassword'
>        EQUALITY octetStringMatch
>        SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
>
>How should a client behave when the user types in a password with
>NON-ASCII characters? Very likely you receive the password in some
>type of character set/encoding within your system environment.
>
>Personally I encode the user input as UTF-8 before setting the
>userPassword attribute or doing a bind. But according to the schema
>definition above this might be wrong. But if there's no rule how to
>encode user's input every LDAP client would be free to store any
>password value leading to incompatible password handling.

There is no rule in LDAPv3 other than what X.509 says:
  Simple authentication is intended to provide local
  authorization based upon the distinguished name of
  a user, a bilaterally agreed (optional) password,
  and a bilateral understanding of the means of using
  and handling this password within a single domain. 

  Simple authentication may be achieved by several means:
   a) the transfer of the user?s distinguished name and
      (optional) password in the clear (non-protected) to
      the recipient for evaluation;
   b) the transfer of the user?s distinguished name, password,
      and a random number and/or a timestamp, all of which are
      protected by applying a one-way function;
   c) the transfer of the protected information described in b)
      together with a random number and/or a timestamp, all of
      which is protected by applying a one-way function.

That is, use of simple bind credentials is site specific.

>Or did I misunderstand something?

No.  I think you understand the limitations of "simple"
authentication.  I suggest folks avoid "simple"
authentication and use SASL instead.   If you really
want plain passwords, use SASL/PLAIN over TLS.  SASL/PLAIN
uses a UTF-8 encoding.

As far those wishing to support "simple" authentication
in applications they develop, I suggest they support both
"as is" handling and "transliterate to Unicode, encode as
UTF-8" handling (with the latter being the default).

I note that simple (or SASL/PLAIN) authentication should
only be used when adequate protective services are in
place.

Kurt