Subject: Re: more SASLprep/protocol problems

From: John McMeeking <[email-masked]>
Date: Wed, 1 Oct 2003 15:20:31 -0500

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 02 Oct 2003 03:27:52 -0700

RFC 2277 says:
   All protocols MUST identify, for all character data,
   which charset is in use.

That is, we cannot allow clients to transfer character data in
the protocol without providing the server a protocol mechanism
for reliably determining what charset is use.  My previous
suggestion was flawed in that it allowed character data to
be transferred without identifying which charset is in use.

For this reason, I revise my suggestion:
        The simple form of an AuthenticationChoice specifies a
        simple password to be used for authentication.  Passwords
        consisting of character data (text passwords) SHALL be
       transferred as [UTF-8] encoded [Unicode].  Prior to transfer,
       clients SHOULD prepare text passwords by applying the
       [SASLprep] profile of the [Stringprep] algorithm.  Passwords
        consisting of other data (such as random octets) MUST NOT
        be altered.

Keen eyes will see that I've dropped the "MAY prepare textual
passwords using algorithms".  This was done for the following
reasons.

First, it's implicit in the SHOULD.  As RFC 2119 says, there may
exist valid reasons in particular circumstances to ignore this
SHOULD, but the full implications must be understood and
carefully weighted before choosing a different course.  This
allows alternative approaches.

Secondly, RFC 2119 says of implementations supporting an OPTIONAL
feature MUST be prepared to interoperate with implementations which
don't.   If one client prepares text passwords as RECOMMENDED and
another doesn't, the user will likely only be able to use one
client or the other but not both.

Also, we need to ensure that interoperable implementations of
features, even OPTIONAL features, can be independently developed.
Two clients which both use "null" preparation may fail to
interoperate with the server due to platform differences.
For example, if one client send the text as UTF-16 and
another send same text as UTF-32, authentication will fail
one or both of these clients (assuming the server implements
password matching as specified).

Kurt