Re: more SASLprep/protocol problems

[John McMeeking <jmcmeek@us.ibm.com>]

Sorry if there are multiples of this -- mail was having major hiccups ;-(

Hallvard B Furuseth writes:

>> Take, for example, that the external system is EBCDIC based as
>> are existing clients.  It is quite unlikely that any independently
>> developed system would interoperate with such a system.

> True, but at least clients developed _there_ would interoperate with
> both outside systems and their own server if these clients had options
> to both prepare and to not prepare passwords.

> For that matter, these clients developed on the outside of the EBCDIC
> campus would at least _allow_ users to type in passwords that would be
> accepted, if they too had a 'do not prepare' option.  Users would have
> to mess with character tables or something in order to know the right
> character codeds for the passwords, but it could be done.  I'm not sure
> how strong an arugment that is though - I'd like to hear from people on
> EBCDIC systems what they do when they telnet 'home' from an outside
> system.

I believe the OS/400 TELNET server performs code page translation to
convert data as sent for the negotiated mode (probably US ASCII for VT100)
to or from the system code page (an EBCDIC CCSID).  Valid passwords are
limited to the characters that can be entered by the user, exist in the
negotiated mode, and can be converted to the system CCSID.  When I telnet
from my Windows box to OS/400, I assume the Windows telnet client is not
using TELNET 5250 or EBCDIC (help says it supports vt100, vt52, ansi, ...).

================

The OS/400 LDAP server generally assumes passwords in a bind request (or
userPassword attribute, for that matter) are UTF-8.  We have two sources of
passwords:

-  LDAP entries containing a userPassword value.  The bind credentials and
userPassword value are compared as octet strings.  The may compare hashes
of the two values, as we allow the user to control how userPassword values
are stored.

-  Native OS/400 user profiles.  The bind password is converted from UTF-8
to the job CCSID before calling OS/400 authentication services.

The OS/400 LDAP client API, broadly speaking, has two modes:

-  local code page I/O: strings (including password parameter on the simple
bind API) are in the local EBCDIC CCSID on the application side, and
converted to/from UTF-8 to flow in the protocol

- UTF-8 I/O: application works with data in UTF-8 and is responsible for
doing its own data conversion

The server understands how the password store works and performs the
necessary conversions from the credential presented in the bind request to
the form required by the password store.  To some extent, the server
doesn't really care what the credentials are.  And I recall having this
discussion with our then architect a few years ago.  It is very well for
the server to treat credentials as bytes, but people do not enter "bytes"
when they type in a password.  They enter characters that they expect to be
treated the same whether they are entering those characters at an ASCII
system, an EBCDIC system, running in English, German or Chinese, or a Java
application.  The application has to convert a string of characters to a
set of bytes in a consistent way.  We came to the conclusion that textual
credentials, at least, had to be represented in UTF-8.

===============

As to what to do to [PROTOCOL]... I think a SHOULD for
Unicode+SASLPrep+UTF-8 and a SHOULD (MUST?) for the ability for an
application to specify an arbitry octet string to be used as the
credentials is reasonable.

I view the first part as necessary for interoperability between arbitrary
client and server implementations.  The second part may be necessary for a
mix of "new" and "legacy" clients and / or servers, but I tend to view it
more as a bandage on what may have been an overly constrained
implementation.


John  McMeeking