Subject: RE: Status update for Kerberos Revisions

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

inline [JBrezak]

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

> [JBrezak] Are there any other implementations that use character set 
> encodings with Kerberos GeneralStrings other than ascii or Unicode? We

> should recognize the scope of the problem and work to come to a 
> resolution around a few specific cases. I would like to see that a new

> KDC be able to recognize a Win2000 client that is using non-ASCII 
> characters (unicode) in principal names. Something like - the *old* 
> GeneralString can be encoded as UTF-8 unicode or the 7-bit ascii 
> character sets. This would satisfy my requirement for 
> interoperability.

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.

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.

> The point of the extensions is not to define what the proper behavior 
> of GeneralString is, but to define what the proper behavior of 
> KerberosString will be.  If you receive a KerberosString using Choice 
> UTF8String then you will be sure of what you are getting. Otherwise, 
> you will be just as confused about the meaning of the character set in

> the GeneralString as you are now.
> 
> John, when a Windows 2000 system receives a GeneralString encoded in 
> ISO Latin2, Code Page 437 or JIS, how does it behave?
> 
> [JBrezak] Do you mean as an escaped string? If so I'm checking.

Not an escaped string.  No one uses escapes.  Part of the problem is
that even escaping to an ISO-8859 character set is illegal in
GeneralString. 

It is possible that you can receive a string from a client that is just
a set of octets whose input was any arbitrary ISO character-set or OEM
code page.

[JBrezak] Then windows 2000 will just interpret it as UTF-8 and try to
decode it into a Unicode string. If it fails to decode, an asn.1
decoding error will be generated.

> Does it return an error?  If so, what?
> 
> We must expect that the behavior in the future which be identical to 
> the way it is today.
> 
> [JBrezak] But I'm very concerned when old clients talk to new KDCs and

> servers. Also when new clients talk to old KDCs and servers.

So are we all.  None of these changes can take place in vacuum.  If we
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? 

 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: Martin Rex <[email-masked]>
Date: Tue, 20 Nov 2001 19:00:11 +0100 (MET)

John,

Your quoted Emails are quite hard to read.
All versions of Outlook that I've seen were at least able to do correct
indent-quoting, why don't you give it a try...

> Windows 2000 does not use different character sets - just Unicode.

UTF-8 shouldn't be tagged as GeneralString, and correct of-the-shelf
ASN.1 compilers should prevent you from doing so.  (Neither should
any 8-bit extension of ASCII be tagged GeneralString).  I'm really
amazed that Microsoft never brought up this issue while they were
working on their implementation.

In those places where people are actually using any characters besides
US-ASCII they will have problems.  Strange Email Addresses is just
one of the possibilities.  Existing software or existing APIs that
are also limited to US-ASCII will be one area of such problems.
It doesn't matter whether the infrastructure supports it as long
as there is software running on top of APIs that does NOT support it.

> function always requires a Unicode string as the input.

Unicode string as input for string2key?  I strongly hope that the
acutal spec is precise about what it means.  UTF-8 (inspite of its
ambiguities) would probably be ok, but talking of Unicode in general
when specifying the input of a hash function makes no sense.

> implementations that do other than that? 

I don't know whether any Kerberos implementation uses a commercial ASN.1
parser that is correct and "adds value" when decoding GeneralString.
Apparently even Microsoft isn't using such a thing.

However when considering to preclude the use of correct ASN.1 parsers,
then we should strip most of the ASN.1 from all other Kerberos-related
protocol documents, starting with those that absolutely don't need it
in the first place... :)

AFAIK, MIT Kerberos (and probably most derived implementations) will treat
it as an arbitrary 8-bit charset.  When displayed to the user or
when printable input is entered/provided by the user, no conversion is
done, i.e. the local charset will be used.

Since there is no encoding and no conversion, there are also no
decoding/conversion errors.  

-Martin

---

From: Sam Hartman <[email-masked]>
Date: 20 Nov 2001 15:25:50 -0500

>>>>> "John" == John Brezak <[email-masked]> writes:

not    John> The scope of the problem is that current Kerberos
not    John> implementations do not restrict user input to 7-bit ASCII.
not    John> There are some but not many sites that do indeed use
not    John> ISO-8859 character sets when specifying their user principal
not    John> names.

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

I think it is reasonable for you to require that the standards track
protocol allow old Microsoft Kerberos implementations to talk to new
new Microsoft implementations or for new Microsoft implementations to
talk to old Microsoft implementations and for these implementations to
use UTF8 when they talk amongst each other.

However it seems that your compatibility requirement goes beyond this.
IT seems that you want an old Microsoft implementation to be able to
use UTF8 when say talking with a new MIT implementation.  You
acknowledge that since old MIT implementations do not support UTF8 you
will never get them to use UTF8 with an old Microsoft implementation.

Why is this additional compatibility requirement reasonable to place
on the protocol?