Previous section.
X/Open Single Sign-on Service (XSSO) -<br>
Pluggable Authentication Modules
X/Open Single Sign-on Service (XSSO) -
Pluggable Authentication Modules
Copyright © 1997 The Open Group
Internationalization
The issue of codesets is viewed by the working group as a general issue
that requires addressing globally. It would be to parochial to try and
address currently in PAM.
This appendix documents the issue and some proposals as presented to and
discussed by the working group.
Introduction
The PAM architecture assumes that usernames and passwords are selected
from the same codeset and handled using C programming character pointers.
This may not be true since there are a variety of codesets available. In
addition, not all characters sets are handled using C character pointers.
A proposal from Hewlett-Packard recommends a parameter to maintain the
codeset type.
Single System Codesets
A username and corresponding password are compared against stored data,
(/etc/passwd on a simple UNIX machine). On a stand-alone machine, the
comparison data and the interface which captures data, utilize the same
codeset.
A simple byte by byte match between the text collected by the interface
and the comparison data may be used for the username. Yet, passwords
comparisons are not so simple since it is dependent upon the codeset by
which the password is represented.
For example, let us consider a user with password "ABCD" on a system
where the password comparison data is formed in the UNIX manner.
If the system uses the ASCII codeset, an encryption key is generated from
{0x41, 0x42, 0x43, 0x44} and a fixed plaintext is encrypted with this key.
If the system uses EBCDIC, the encryption key is generated from
{0xC1, 0xC2, 0xC3, 0xC4}.
Therefore, even if the plaintext is encrypted using identical algorithms
on these two systems, the results will differ due to the codeset.
Usernames
If the login interface and the authentication service (AS) do not reside
on the same machine, it is not reasonable to assume compatible codesets
are deployed.
For example, in a Japanese enterprise where the username is in Kanji, a
user logs into a machine which uses Shift-JIS. But suppose the
authentication service is based upon eucJP. In order to achieve
successful authentication, the Shift-JIS username must be recognized
by the eucJP service.
Passwords
A system may restrict passwords to a particular set of characters which
exist in all versions of EBCDIC and localizations of ISO 646, such as
ASCII. The system may also perform conversions to ISO 646 prior to
processing. Although this guarantees consistent comparison data, it may
be undesirable. Technically, this approach is not sufficient - as the
character set decreases, passwords become weaker. In addition, it is
inconvenient to use an unfamiliar set of characters for password selection.
Proposed Solution
From the previous example, a user has a Kanji password (Shift-JIS codeset)
but an AS which requires a different codeset, eudJP. One potential
solution involves passing the Shift-JIS password, with a tag indicating
the codeset type, from the client to the AS though a protected channel.
The AS converts the password to eucJP and proceeds with its comparison to
the stored data.
The stored value in the remote AS differs from the encrypted Shift-JIS
password (on the local machine) since different codesets are employed.
If local authentication is required, password synchronization between
the machines may not be achieved by simply copying the remote AS's
stored value to the client, even though both use the same encryption
algorithm.
Further complications arise if the client attempts to convert the
password to the codeset used by the remote AS. That is, the client must
determine the codeset used by the AS. In addition, if local
authentication is required, the client must not only verify the type of
codeset applied to generate the data, but also securely retrieve the
stored value from the remote AS.
Regardless of codesets, authentication services must function properly.
Smart Cards
The issues discussed above apply to smart cards which are used primarily
as a repository of passwords and computations are performed elsewhere.
If passwords on a card are indexed by username, there may be complications
if identical usernames are used on machines with different codesets.
However, if passwords are indexed by system name and username pairs,
smart cards may hold passwords in the localized codeset.
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy
of this publication.