Subject: RE: Status update for Kerberos Revisions

From: "John Brezak" <[email-masked]>
Date: Mon, 19 Nov 2001 09:47:36 -0800

Below-

-----Original Message-----
From: Jeffrey Altman [mailto:[email-masked]] 
Sent: Monday, November 19, 2001 9:19 AM
To: John Brezak
Cc: Jeffrey Hutzelman; Clifford Neuman; [email-masked]
Subject: RE: Status update for Kerberos Revisions

> inline [JBrezak]

inline

> -----Original Message-----
> From: Jeffrey Altman [mailto:[email-masked]]
> Sent: Thursday, November 15, 2001 9:53 AM
> To: John Brezak
> Cc: Jeffrey Hutzelman; Clifford Neuman; [email-masked]
> Subject: RE: Status update for Kerberos Revisions
> 
> 
> > below [JBrezak]
> 
> inline response
> 
> The scope of the problem is that current Kerberos implementations do 
> not restrict user input to 7-bit ASCII.  There are some but not many 
> sites that do indeed use ISO-8859 character sets when specifying their

> user principal names.
> 
> [JBrezak] What is missing from the I-D is how to handle Unicode 
> characters as GeneralStrings. Currently they are encoded as UTF-8. 
> Windows 2000 does not use different character sets - just Unicode.

John, the whole point of the draft is that you cannot place Unicode
characters into GeneralStrings.  GeneralStrings are only allowed to
store characters from ISO-646 compliant character sets.  There is no 
method for placing any form of Unicode in these strings.  If there were,
we would not be in such a bind and I would not need to publish an
Informational draft stating

  DO NOT USE ANYTHING OTHER THAN 7-BIT ASCII FOR ANY FORM OF 
  DATA ENTRY.  NOT NAMES, NOT PASSWORDS, ...

[JBrezak] Sorry, but that will not work for thousands of existing
deployed customers. I do not see where Unicode is explicitly prohibited.

> We have no idea how many people use non-ASCII characters as part of 
> their passwords.
> 
> [JBrezak] Nor do I. Currently the DES types are ambiguous as to what 
> the input form is for the string2key function. This should also be 
> called out in your I-D and definitely handled in the 
> kerberos-revisions. When Windows 2000 is using the RC4-HMAC enctype, 
> the defined string2key function always requires a Unicode string as 
> the input.

Which may also be a problem.

[JBrezak] The RC4-HMAC isn't a problem. However the DES ones are. Can
you add a section with recommendations on how to properly encode a
character string for input to the String2Key functions?

> can't tell a new message from an old one we are in deep trouble.  It 
> is at that point where the version number must be incremented.
> 
> [JBrezak] What will happen with other existing implementations with 
> they get UTF-8 encoded GeneralStrings? Do they return an ASN.1 decode 
> error? I would still like to see that GeneralStrings in Kerberos are 
> ASCII7 or UTF-8 Unicode characters when escapes are not specified. Are

> there any implementations that do other than that?

A proper ASN.1 parser will return a decode error.  Of course, the
parsers in MIT Kerberos do not.

[JBrezak] That alone needs to be fixed.

We have already been told by the powers that be that we may not ignore
the definition of GeneralString as per ASN.1.  The IESG and the ITU will
now allow it.  Back at Pittsburgh when this problem was first recognized
that is the path ath Tom, Jeff, Ken and I wanted to pursue.  It was not
accepted.

[JBrezak] We need to separate what needs to be done with existing
implementations and then how to fix the Kerberos standard. There needs
to be a realization that what is needs to continue to work for all
customers, anything else will be unacceptable regardless of the
political implications.

 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: Ken Hornstein <[email-masked]>
Date: Mon, 19 Nov 2001 15:40:50 -0500

>deployed customers. I do not see where Unicode is explicitly prohibited.

John, I know you've said that you've got thousands of existing customers,
but I really do wonder how many are using 8-bit usernames.  I've gotten
the sense that large sites that want to interoperate with the rest of the
world simply use ASCII for usernames if for no other reason to make email
simpler (I don't believe I've ever received email from someone with an
8-bit username -- real name field, yes, but that has a well-defined escape
mechanism).  My sense may be wrong, of course, but I'd be glad to hear
some firm numbers to the contrary.

I can definately believe that there are 8-bit passwords out there, because
I've already seen interoperability failure reports about them :-/  At least
that's a much simpler problem to deal with.

--Ken