Subject: Re: 8 bit ASCII support in Kerberos

From: Jeffrey Altman <[email-masked]>
Date: Tue, 23 Oct 2001 14:06:08 EDT

The is no notion of character-set in Kerberos.  Therefore, as long as
you use the same character set to input the password with kadmin and
kinit everything will be fine.

Microsoft is using Unicode as their character-set with the UTF-8
encoding.

Until such time as there is a migration strategy declared for the use
of characters beyond 7-bit ASCII, I would restrict myself to that
character range.

- Jeff

> 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. =E1, =E7, =EA). 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=E1n=E7ois" 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

 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 Beta available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 24 Oct 2001 13:02:20 EDT

Will:

The encoding scheme is the character-set.  The server is ISO-8859-1
and the client is CP1252.  They encodings do not match therefore the
passwords are considered to be different.

- Jeff

> Recall that the KDC returns a TGT encrypted with the password and data is
> transmitted as byte sequence. If the character encoding scheme at the client
> and at the machine where I change my password (where KDC is) is the same,
> say UTF-8 and the character set used is ISO-8859-1, I should expect a
> successful authentication albeit the password used include chars in x80-xFF
> range?  
> 
> In the experiment which I did, kinit was executed at the MSDOS prompt (of
> WinNT4 client), not sure what encoding scheme is used but CodePage is 1252;
> kpasswd is executed at the Solaris 2.6 machine using ISO-8859-1 charset and
> UTF-8 encoding, I believe. Though the characters supported in CP1252 and
> ISO-8859-1 varies, the code points of the characters which I experiment with
> in the password are common in both charsets. I'm suspecting it is the
> difference in the character encoding scheme used in the two environment that
> causes the problem (password incorrect when kinit). Would appreciate your
> comments.
> 
> Will 
>

---

From: "Tay, William" <[email-masked]>
Date: Wed, 24 Oct 2001 12:43:59 -0400

>Currently, the MIT implementation ignores the whole 8th-bit problem,
>and essentially treats the text as a byte sequence; 

>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....

Will