Subject: RE: Status update for Kerberos Revisions

From: "John Brezak" <[email-masked]>
Date: Tue, 20 Nov 2001 10:17:27 -0800

below - [JBrezak]

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2001 10:00 AM
To: John Brezak
Cc: [email-masked]
Subject: Re: Status update for Kerberos Revisions

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

[JBrezak] "... be liberal in what you accept ..."

John Brezak wrote:
> 
> > Cc: Jeffrey Hutzelman; Clifford Neuman; [email-masked]
> > Subject: RE: Status update for Kerberos Revisions
> > 
> > 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.

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.

[JBrezak] GeneralString can contain any character set as long as it is
properly escaped. The "properly escaped" is the part that many people
have missed in many places even outside of Kerberos. In fact many
protocols have stayed away from GeneralString just because of this.
GeneralString can contain UTF-8 characters as long as they are prefixed
with the correct escape sequence. But these escaping rules require you
to sift through many different specs between many different standards
bodies. The escaping of GeneralStrings doesn't seem to be an issue with
the ASN.1 package we are using, it doesn't deal with it. You need to
present to it the correct string and it tags and packs it. However that
is an implementation detail.

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

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.

[JBrezak] Unicode is used in the string2key function for RC4-HMAC only.
For DES, the input form is not specified in 1510.

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

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 13:59:09 -0500

>>>>> "Tom" == Tom Yu <[email-masked]> writes:

    Tom> I seem to recall that the encoding of the Unicode isn't
    Tom> specified.  Is it UTF-8?

no, utf16.

---

From: Tom Yu <[email-masked]>
Date: 20 Nov 2001 13:49:22 -0500

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

John> [JBrezak] GeneralString can contain any character set as long as
John> it is properly escaped. The "properly escaped" is the part that
John> many people have missed in many places even outside of
John> Kerberos. In fact many protocols have stayed away from
John> GeneralString just because of this.  GeneralString can contain
John> UTF-8 characters as long as they are prefixed with the correct
John> escape sequence.

It may not.  The definition of GeneralString in Clause 36, Table 3 of
X.680(1997) defines GeneralString to include "All G and C sets + SPACE
+ DELETE".  Nowhere does it say anything about encoding outside of ISO
2022.  UTF-8 isn't a G set or a C set.  It is a completely different
encoding.  Furthermore Clause 8.20.5.1 of X.690(1997) specifies that
"An escape sequence shall not be used unless it is one of those
specified by the registrations numbers used to define the character
string type in ITU-T Rec. X.680|ISO/IEC 8824-1".  I interpret this to
exclude escapes to other encoding schemes.  UTF-8 isn't an ISO 2022
character set; it is a completely different encoding from ISO 2022.

John> But these escaping rules require you to sift through many
John> different specs between many different standards bodies. The
John> escaping of GeneralStrings doesn't seem to be an issue with the
John> ASN.1 package we are using, it doesn't deal with it. You need to
John> present to it the correct string and it tags and packs
John> it. However that is an implementation detail.

There is a registry of character sets that is centrally maintained,
along with the escape sequences.  The framework for the escape
sequences is specified in ISO 2022.

It seems that your ASN.1 package has the same problem as the MIT
implementation does, which is that it will believe your assertion that
the string you feed it is correct for it to encode bit-for-bit as the
selected type.

John> [JBrezak] Unicode is used in the string2key function for
John> RC4-HMAC only.  For DES, the input form is not specified in
John> 1510.

I seem to recall that the encoding of the Unicode isn't specified.  Is
it UTF-8?

---Tom

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 Nov 2001 14:37:09 -0500

>     Tom> specified.  Is it UTF-8?

But UTF-16 doesn't support as many characters as UTF-8... Oh well.

Of course, many characters cannot be entered without some visual
feedback, and since passwords are usually not echoed back to the user
during prompting... ;)

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.