Subject: RE: Status update for Kerberos Revisions

From: "John Brezak" <[email-masked]>
Date: Wed, 14 Nov 2001 13:00:41 -0800

Below [Jbrezak]

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2001 11:46 AM
To: John Brezak
Cc: Clifford Neuman; [email-masked]
Subject: RE: Status update for Kerberos Revisions

On Wed, 14 Nov 2001, John Brezak wrote:

> It is not acceptable to call a very large number of existing users 
> "cheaters". Since there are existing realms using GeneralString with 
> the UTF-8 Unicode character set, this should be accomodated. There is 
> no easy way to get these converted without regard to _both_ forward 
> and backward compatibility.

It is worth noting that these existing users (admittedly through no
fault of their own) are doing something not permitted by RFC1510.  So
are the people who are using unescaped ISO-8859 or other native
encodings. 
Nonetheless, the focus here is on interoperability, not on punishing
people who have existing nonstandard installations.  So, we will do the
best we can to support these users.

[Jbrezak] Agreed. Just realize that what is there will need to
interoperate. You cannot tell them to
limit their names to only ascii characters.

> I'd propose a change that would recognize that implementations prior 
> to 1510bis can represent GeneralStrings encoded as UTF-8 characters in

> the unicode character set. If a KDC or server is unable to convert 
> from this and is restricted to the ASCII character set, then they 
> should return a KRB-ERR-GENERAL-STRING (or something like that).

On the contrary, while 1510bis should recognize that there are existing
implemenations which encode GeneralStrings containing other than
US-ASCII, it should _not_ describe what these possible encodings are or
provide recommendations on their use.  The Microsoft UTF-8 behaviour is
not the only possible interpretation of non-US-ASCII in a GeneralString,
and we should not assume that it is.  Please also see my original
posting in this thread, in which I relayed specific advice from a IESG
member that the semantics of non-US-ASCII GeneralStrings remain
unspecified.

[Jbrezak] There can be other interprettations, however the UTF-8 unicode
interprettation is by far the
most widely adopted.

There really is no need for a new error message, either.  New
implemenations should always be using UTF-8 to talk to each other, so
one new implementation will never send your KRB-ERR-GENERAL-STRING to
another. 
An old implementation will certainly never send that error, and will be
unable to interpret the error if it receives one.  Not all cases where
this may happen have a clear error path, and even when there is one, it
may not be authenticated. 

[Jbrezak] The error is intended for old implementations to add given the
proliferation of UTF-8/unicode.

New implementations may certainly send UTF-8 or whatever other garbage
they want in a GeneralString in order to interoperate with an old
implementation.  But that will only work if the guess about what the
other side is expecting is correct, just as today.

[Jbrezak] There needs to be a specific mechanims described for interop.
What does a KDC or server do when it receives a GeneralString that it
cannot decode to a local character set? What are the failure modes? How
does
A client detect when such a failure mode is present?

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 14 Nov 2001 16:30:35 -0500 (EST)

> limit their names to only ascii characters.

Indeed, we can, and that's exactly what Jeff Altman's draft does.  Of
course, we can't expect them to actually _listen_, but people who limit
themselves to US-ASCII are going to have less pain both before and during
transition.

> does A client detect when such a failure mode is present? 

All of these things are implementation-defined -- the semantics of
GeneralStrings in Kerberos are undefined, and should remain so.  If you
want people to be compatible with your particular implementation, then
perhaps you should publish an informational RFC describing exactly what
your semantics are.