Subject: 8 bit ASCII support in Kerberos

From: "Tay, William" <[email-masked]>
Date: Tue, 23 Oct 2001 13:52:12 -0400

Hi,  
 
My team is working on a multi-lingual product and was thinking of using
Kerberos mechanism for authentication. I was wondering if the parameters for
kinit (username and password) support 8 bit ASCII characters in the range
x80-xFF (e.g. á, ç, ê). And so I did a simple test to verify. Executed
kadmin followed by cpw (change password) at a unix machine with KDC
installed; then tried to kinit at a windows client with new password say
"fránçois" to get a TGT but failed (password incorrect) . Is Kerberos
currently able to support only 7-bit (x20-x7F) chars and not characters
beyond the range. If that's the case, can  you suggest/explain where is the
limitation of being able to support the 8-bit ASCII chars: are the tools
causing the limit or is the kerberos code limited, or is the
encryption/decrpytion algorithm causing the problem? Is there any
workaround?  
 
Also tried to execute kpasswd on client after doing a kinit to remotely
change password but got a "Ticket not yet valid changing password" error.
What does this actually mean? I was confused what the kpasswd utility
actually do. Does this mean the new password is loped across the network to
update the KDC from the remote client? 
 
Will

---

From: Ken Raeburn <[email-masked]>
Date: 23 Oct 2001 14:17:52 -0400

> x80-xFF (e.g. á, ç, ê). And so I did a simple test to verify. Executed

As I understand it, "8-bit ASCII" is a contradiction; ASCII is a 7-bit
spec.  In order to use all 256 byte values as characters, you have to
choose a character set like ISO Latin-1 or Latin-2.  But that leaves
you with a single larger character set that's still not good enough
for internationalization.  I think the general (though perhaps not
universal) consensus has been that we should try to move towards
UTF-8.

Currently, the MIT implementation ignores the whole 8th-bit problem,
and essentially treats the text as a byte sequence; we've toyed with
the idea of adding code to refuse new principals or passwords unless
they're limited to printing ASCII (no 8th-bit-set characters, no
control characters or escapes) until we can come up with a better
approach to the internationalization problem.  (There will be an
interesting conversion problem, since reportedly some sites are using
such characters already, basically as "whatever local 8-bit character
set is being used".)

> encryption/decrpytion algorithm causing the problem? Is there any

Depends on the implementation, and on the software you're using to
interface between the programs and the user.  The MIT Kerberos code
should handle it transparently, but if for example xterm or xdm or
whatever is stripping away the 8th bit, or if they're not processing
the input characters the same way so that the programs see different
input strings, then you're just doomed....

> update the KDC from the remote client? 

Sounds like maybe the clocks are out of sync and the ticket is issued
with a starting timestamp in the future (probably the near future and
only by a few seconds or minutes).

Ken

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 23 Oct 2001 16:41:33 -0500

I see you have already received two answers to the question. As you will note
this is a problem area. If you have any suggestions, I would like to invite 
you too the upcoming IETF meeting. We will be continuing the internationalization
discussions.  

> "Tay, William" wrote:
> 
> Hi,
> 
> My team is working on a multi-lingual product and was thinking of using Kerberos mechanism
> for authentication. I was wondering if the parameters for kinit (username and password)
> support 8 bit ASCII characters in the range x80-xFF (e.g. á, ç, ê). And so I did a simple
> test to verify. Executed kadmin followed by cpw (change password) at a unix machine with
> KDC installed; then tried to kinit at a windows client with new password say "fránçois" to
> get a TGT but failed (password incorrect) . Is Kerberos currently able to support only
> 7-bit (x20-x7F) chars and not characters beyond the range. If that's the case, can
> you suggest/explain where is the limitation of being able to support the 8-bit ASCII
> chars: are the tools causing the limit or is the kerberos code limited, or is the
> encryption/decrpytion algorithm causing the problem? Is there any workaround?
> 
> Also tried to execute kpasswd on client after doing a kinit to remotely change password
> but got a "Ticket not yet valid changing password" error. What does this actually mean? I
> was confused what the kpasswd utility actually do. Does this mean the new password is
> loped across the network to update the KDC from the remote client?
> 
> Will

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444