Subject: Working Group Last Call (Take Two): Desired Enhancements to GSSAPI Naming

From: Jeffrey Altman <[email-masked]>
Date: Wed, 19 Apr 2006 17:48:41 -0400

This note announces the start of a two week working group last call
for the Kitten work item "Desired Enhancements to GSSAPI Naming".
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04..txt

This document is intended to be published as Informational.  The
document provides scope for the naming issues Kitten is attempting to solve.

The author believes that all responses received during the previous WGLC
have been addressed.  Please perform another review and send feedback to
the list stating that the review has been performed regardless of
whether or not there are comments.

This WGLC ends at 00:00 EST on Thursday May 4, 2006.

Jeffrey Altman
_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Martin Rex <[email-masked]>
Date: Fri, 21 Apr 2006 23:23:46 +0200 (MET DST)

> http://www.ietf.org/internet-drafts/draft-ietf-kitten-gss-naming-04..txt

One thing that hasn't be addressed, but which is probably an
issue (in particular with the IESG...):  I18N.

The C-Bindings document mentions at one place that printable strings
use the ISO Latin 1 codepage, but what actual implementations of
GSS-API mechanism really use (and what applications expect)
varies.

e.g. we do ship our application (and a particular oem library with
a gssapi mechanism) for two native EBCDIC platforms (OS/390 and OS/400),
and both use an EBCDIC codepage for the printables -- which differs
from ISO Latin 1 even for 7-bit ASCII (IA5) characters.

Even for language bindings that natively support Unicode (like Java),
the use of non-ASCII characters in the underlying GSS-API mechanism
may create interoperability problems, i.e. with Kerberos 5 principal
names and rfc1510 communication peers.

It might be a good idea if a gssapi mechanism and an application caller
(of the GSS-API C-Bindings) could agree on (or negotiate) the use of
UTF8-strings for printables instead of the currently defined
ISO-Latin-1 per rfc-2744 and the (de-facto) implementation defined
behaviour of exisiting implementations.

Supporting UTF-8 for printables (and have mechanism and application
negotiate or agree upon this) will usually require code changes
in both.  I may be forced to implement a proprietary extension
for interoperabitity of third-party gssapi libraries with our
application through an additional API call (for "negotiating"
the use of UTF-8 for printables) for our east european and asian
customers.  The use of non-ASCII and non-ISO-Latin-1 characters
within Subject DNames of X.509 certs is quite popular there and
so is the use of SPKM or SPKM-like gssapi mechanisms for Single Sign-On.

printable strings are "names" as input parameter to gss_import_name()
and output parameter from gss_display_name() as well as the
textual representations of minor and major status codes as
returned from gss_display_status().

Thoughts? Experiences?

Has anyone else encountered I18N issues with GSS-API (C-Bindings)
or already devised a solution?
What codepage does your (gss-api) implementation use or your
application expect/use?

AFAIK MIT Kerberos 5 has traditionally use the "just send 8(-bit)"
not just on the network, but also at the (GSS-)API.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Apr 2006 17:04:30 -0500

> issue (in particular with the IESG...):  I18N.

That is orthogonal to the naming extensions work.

> GSS-API mechanism really use (and what applications expect)

Typically they use whatever the current locale demands, which is what
RFC2744 should have said all along.

> names and rfc1510 communication peers.

This is a mechanism-specific issue.

> behaviour of exisiting implementations.

IMO this way lies madness -- it makes the GSS-API not so generic.

I believe applications and the GSS-API functions that receive text
inputs or which produce text outputs should use the current locale and
nothing but.

We may want new major status codes to indicate codeset conversion
issues, but we can always get by with minor status codes.

Mechanisms should do, in their tokens and protocols, whatever their
specifications say, converting to/from the application locale as
necessary.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Sat, 22 Apr 2006 17:53:28 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Jeffrey Altman wrote:
    >>  This note announces the start of a two week working group last
    >> call for the Kitten work item "Desired Enhancements to GSSAPI
    >> Naming".

    Martin> One thing that hasn't be addressed, but which is probably
    Martin> an issue (in particular with the IESG...): I18N.

    Martin> The C-Bindings document mentions at one place that
    Martin> printable strings use the ISO Latin 1 codepage, but what
    Martin> actual implementations of GSS-API mechanism really use
    Martin> (and what applications expect) varies.

Good point.

    Martin> e.g. we do ship our application (and a particular oem
    Martin> library with a gssapi mechanism) for two native EBCDIC
    Martin> platforms (OS/390 and OS/400), and both use an EBCDIC
    Martin> codepage for the printables -- which differs from ISO
    Martin> Latin 1 even for 7-bit ASCII (IA5) characters.

    Martin> Even for language bindings that natively support Unicode
    Martin> (like Java), the use of non-ASCII characters in the
    Martin> underlying GSS-API mechanism may create interoperability
    Martin> problems, i.e. with Kerberos 5 principal names and rfc1510
    Martin> communication peers.

    Martin> It might be a good idea if a gssapi mechanism and an
    Martin> application caller (of the GSS-API C-Bindings) could agree
    Martin> on (or negotiate) the use of UTF8-strings for printables
    Martin> instead of the currently defined ISO-Latin-1 per rfc-2744
    Martin> and the (de-facto) implementation defined behaviour of
    Martin> exisiting implementations.

    Martin> Thoughts? Experiences?

    Martin> Has anyone else encountered I18N issues with GSS-API
    Martin> (C-Bindings) or already devised a solution?  What codepage
    Martin> does your (gss-api) implementation use or your application
    Martin> expect/use?

We have encountered issues but have not managed to solve them.

I don't think we can propose specific solutions in this draft
basically because I don't think we have them yet, and I don't want to
hold up this draft.  I do think we can add a section describing the
problem and claiming it needs to be solved.  I will post text shortly.
Assuming there are not other issues I'd prefer to last call that text
but not re last call the entire document.

--Sam

---

From: Jeffrey Altman <[email-masked]>
Date: Sat, 22 Apr 2006 18:27:33 -0400

> but not re last call the entire document.

Speaking as Chair, I would be happy to consider a separate WGLC on
just a new section of text.

Speaking as an Individual, I wonder whether Internationalization of
GSS-API should be considered part of the Naming draft.  It clearly is
a problem that needs to be solved but it is not in the same category
of scope definition that the rest of this draft attempts to provide.

Jeffrey Altman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 24 Apr 2006 12:18:43 -0400

> RFC2744 should have said all along.

Agree, to a point.

> inputs or which produce text outputs should use the current locale and

For the exsting API functions, I agree.
However, I would not be opposed to defining an alternate set of interfaces 
which use UTF-8 for all text, allowing the application to fully take charge 
of locale issues.  If the only API available is one that depends on the 
current locale, then it is impossible for an application to receive names 
from the GSSAPI which contain characters not in the local character set, 
even if both the application and the underlying mechanism support such 
names.  Since in the IETF we have for some time been encouraging 
(requiring) application protocols to use UTF-8, it would seem to maek sense 
to make it possible for implementations of GSSAPI-using protocols to do so 
in a portable way.

> specifications say, converting to/from the application locale as

... or to/from UTF-8, if that is the API in use.

I agree with others who have suggested that this is a separate issue from 
naming extensions, and should be handled separately.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Apr 2006 11:31:19 -0500

> to make it possible for implementations of GSSAPI-using protocols to do so 

Sure.

> naming extensions, and should be handled separately.

I agree.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 24 Apr 2006 17:28:29 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Friday, April 21, 2006 05:04:30 PM -0500 Nicolas
    Jeffrey> Williams
    Jeffrey> <[email-masked]> wrote:

    >> Typically they use whatever the current locale demands, which
    >> is what RFC2744 should have said all along.

    Jeffrey> Agree, to a point.

    >> I believe applications and the GSS-API functions that receive
    >> text inputs or which produce text outputs should use the
    >> current locale and nothing but.

    Jeffrey> For the exsting API functions, I agree.  However, I would
    Jeffrey> not be opposed to defining an alternate set of interfaces
    Jeffrey> which use UTF-8 for all text, allowing the application to
    Jeffrey> fully take charge of locale issues.  If the only API
    Jeffrey> available is one that depends on the current locale, then
    Jeffrey> it is impossible for an application to receive names from
    Jeffrey> the GSSAPI which contain characters not in the local
    Jeffrey> character set, even if both the application and the
    Jeffrey> underlying mechanism support such names.  Since in the
    Jeffrey> IETF we have for some time been encouraging (requiring)
    Jeffrey> application protocols to use UTF-8, it would seem to maek
    Jeffrey> sense to make it possible for implementations of
    Jeffrey> GSSAPI-using protocols to do so in a portable way.

I wonder if the right way to do this is to create new OIDs for UTF8
variants of name types?

This is very half-baked.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 24 Apr 2006 17:39:14 -0400 (EDT)

> I wonder if the right way to do this is to create new OIDs for UTF8

I don't think so, because I think there are cases where you'll expect a
name to retain the same type end-to-end, and I think the question of
whether to use a locale-based API or a UTF-8-based one is at least partly
a matter for the application implementation.

But I could be wrong; I haven't thought about this idea more than you
have.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Mon, 24 Apr 2006 23:51:02 +0200 (MET DST)

> I wonder if the right way to do this is to create new OIDs for UTF8

For the input, it would be easy and straight-forward to create
seperate nametypes that indicate UTF-8 encoding.

However this does not address/solve 2 remaining issues:

- what about gss_display_name() -- where the gssapi mechanism
  has to decide which nametype to emit and the use of an UTF-8 implying
  nametype is a change that might upset/confuse non-UTF-8-aware callers

- what about the printables returned from gss_display_status(),
  where one can not overload an accompanying nametype with character
  encoding (codepage)

I really dislike the idea of using the "locale".  While it might
be OK to some extent to influence the textual messages returned
from gss_display_name(), I would consider it a real problem
for the purpose of names.  Names are supposed to be unique,
and I have a real problem if changing the locale would also cause
an authentication of one principal match for the ACL entry of
another one.  Remember, the original GSS-API v1 suggested to
perform authentication based on printable names (only) --
binary canonical names (which are hopefully immune to locales
even for Nico's gssapi implementations) were invented for GSS-API v2
because *we* desperately needed them. :)

Still, the target name for the mutual authentication is normally
derived from a printable (on the initator side), even with
ACLs containing binary canonical names at the acceptor side.

I also do not want a change in the locale to mess up the generation
of ACLs containing binary canonical names from admin/human-maintained
printable originals.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Apr 2006 16:53:18 -0500

> I wonder if the right way to do this is to create new OIDs for UTF8

That would work for GSS_Import_name().  What about GSS_Display_name()
and GSS_Display_status()?

IF we can't rely on the current locale using Unicode THEN we need new
functions, IMO.

However, I suspect we (OS vendors) are all moving towards UTF-8
locales anyways, which would tend to make this matter moot.

As an implementor I find it a lot easier to push users to use UTF-8
locales and put conversions wherever they are necessary.

Sometimes one has no choice.  E.g., filesystem I18N, where we (Sun) will
be pursuing a convention where all path/component names between the
syscall layer and the VFS are assumed to be in UTF-8 -- userland will
get pushed to use UTF-8 locales and perhaps we'll have libc syscall
stubs do codeset conversions for legacy locales, while filesystem
modules will be able to do their own conversions (e.g., to UTF-16) and
optionally (but by default?) reject malformed inputs.

In the GSS-API case we could add convenience extensions that explicitly
use UTF-8, but this wouldn't deal with legacy applications; the only way
to deal with those is what pretty much all implementors do: assume the
current locale's codeset and convert where necessary -- this seems to
work well enough, so why bother adding new interfaces?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 24 Apr 2006 18:03:13 -0400

Jeffrey> On Mon, 24 Apr 2006, Sam Hartman wrote:
    >> I wonder if the right way to do this is to create new OIDs for
    >> UTF8 variants of name types?

    Jeffrey> I don't think so, because I think there are cases where
    Jeffrey> you'll expect a name to retain the same type end-to-end,
    Jeffrey> and I think the question of whether to use a locale-based
    Jeffrey> API or a UTF-8-based one is at least partly a matter for
    Jeffrey> the application implementation.

    Jeffrey> But I could be wrong; I haven't thought about this idea
    Jeffrey> more than you have.

I think the display name issue is a huge problem with my proposal.
However I do believe that there is no expectation that names will
retain the same type end-to-end.  Consider for example the fact that
user name types typically become MNs.

There are issues having to do with ACLs which Martin points out, but
that is weaker than what you cleam.

---

From: Martin Rex <[email-masked]>
Date: Tue, 25 Apr 2006 00:10:53 +0200 (MET DST)

> IF we can't rely on the current locale using Unicode THEN we need new

Thinking about it, that actually seems to be the most fool-proof
approach for migrating existing installations.

> locales and put conversions wherever they are necessary.

I will have to support all of the existing installations in the
fashion in which they now (sometimes by mere chance) work in
customer installations, and I will have to provide a migration
path to utf-8 aware interoperability independent of locale
in the future -- and gracefully deal with every conceivable
mix of now and then gss-api implementations and applications.

Currently, neither gss-api mechanism nor application knows or
has a way to figure out which locales are supported by the other
and really, I consider it a security problem when the representation
of a name, as it appears on an ACL changes when changing the locale!

There may be an extremely low risk with names from the ASCII
character set to be confused, but I do have a very bad feeling
about the non-ascii codepages (and they're the reason why
we're looking into this).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Apr 2006 17:19:25 -0500

> approach for migrating existing installations.

We agree.  Interesting ;)

> fashion in which they now (sometimes by mere chance) work in
                             ^^^^^^^^^^^^^^^^^^^^^^^^

Yes, the joys of just-use-8/just-send-8/just-dont-normalize.

> mix of now and then gss-api implementations and applications.

I think in the Unix world the trend will be to UTF-8 locales.  That
should help.  I think app vendors should seriously think about requiring
the use of UTF-8 locales.

Of course, merely expecting that use of UTF-8 locales solves all
problems only "improves" the situation from a that-really-really-sucks
world of just-use-8 to a that-just-sucks world of just-dont-normalize.

Normalization (and stringprep profiling!) matters.

Fortunately as far as the KITTEN WG is concerned codeset conversion,
normalization and stringprep profiles are ALL mechanism-specific matters
(provided we fix RFC2744 to say "current locale's codeset" instead of
"Latin-1;" it helps that this is the only reasonable thing to do).

> of a name, as it appears on an ACL changes when changing the locale!

Mechanisms need to specify this.  Kerberos V does (currently: printable
US-ASCII; soon full I18N based on UTF-8 and stringprep profiling).

> we're looking into this).

Confusables?  Let's not go there.  This is the KITTEN WG :)  Go check
the SAAG archives if you really want to have fun with confusables.

Cheers,

Nico
--