Subject: Re: request for agenda items

From: Martin Rex <[email-masked]>
Date: Fri, 1 Jul 2005 19:11:48 +0200 (MET DST)

Sam Hartman wrote:
> 
> I'd like to have a discussion on what it would take to move 2743/2744
> to draft?  Would we have to respin the documents?

The most important task is to demonstrate independent interoperable
implementations.  Formally, a WG needs to reconsider the document
and remove parts that are not being used or failed to show
interoperability (those parts that can be removed without
breaking the spec).

Since GSS-API (in particular rfc2743/2744) are a first of all a definition
of a common API, this means that we need "portable" applications
that show plug-and-play with different gssapi mechanisms.

John Linn (the original WG chair of ietf-cat) contacted me in May 2001
about an effort to move GSS-API to draft standard, but it appears he
couldn't raise enough momentum to make it happen.
Maybe you should talk to him again.

I do have some experience with plug-n-play of our application
with more than a dozen independent gssapi mechanisms.

We have set up an interoperability certification for our application
with third-party gssapi mechanisms.  I was given the permission to
publish as OpenSource the software (called "GSSTEST") which we use
to perform (GSS-)API-level testing of third-party gssapi mechanisms.
(ftp://ftp.sap.com/pub/ietf-work/gssapi/gsstest/gsstest-1.26.zip)

The tested functionality is focused on the functionality that
we need and how we use it, and therefore a subset of GSS-API v2.
GSSTEST checks characteristics which I admit to be SAP
specific interoperability constraints, and things that
*I* believe are general requirements, but others may disagree.  :)

But although it's been availabe for more than 5 years, it doesn't
seem to be very popular (or known) among gssapi implementors.

GSSTEST is happy with MIT Kerberos 1.2.x, HP-UX Kerberos (which seems
to be very close to MIT's 1.2.1) and recent Heimdal implementations.
It has serious problems with Sun's Kerberos, and if Microsoft would
be using it, it would have saved them a couple of hotfixes...

The things that may need to be removed because of a lack of
interoperability are according to *MY* experience:
 - channel bindings
 - hostbased service names

Reason: Few (if any) portable applications request and use it,
and the majority of gssapi mechanisms simply doesn't implement
either one.  Actually, the single mechanism that I know to
implement it is Kerberos, and even there Microsoft didn't
implement channel bindings...

Entirely removing these features is impossible without breaking
the spec, and I do know that there are niches in the Kerberos
area where these features are actively used.  However the
spec needs to be updated with guidelines on its use and
a general caution that applications will encounter gssapi
mechanisms that do not offer these features.

Another difficult area is the use of (printable) names
with GSS-API.  The seriously underspecified RFC-2025
(The Simple Public Key GSS-API mechanism) does not
define a mechanism specific name format, which significantly
impairs interoperability in a heterogeneous environment
and may outright prevent interoperability in a heterogeneous
distributed environment.

The definition of the name format in the Kerberos gssapi mechanism spec
rfc-1964 has saved Kerberos from the most serious troubles, but
the transition from just-send-8 to Unicode/UTF-8 characters exists.

This is an area where GSS-API v2 can be considered underspecified.

The data type when passing a printable name through a gssapi function
is "octet string" with an accompanying nametype OID, and the most
common implementation tradition is to use whatever 8-bit character
set is the default on the platform.

When printable names are the input to gssapi calls, it should be
possible to add a nametype-OID for every existing with the
same inpretation, just indicating that the encoding is UTF-8
rather than the default local 8-bit charset.

The two difficulties that come to my mind with this approach:

(1) installed base applications don't know about the UTF-8
    nametypes and will continue to use the existing nametypes

(2) installed base applications will probably choke when
    gss_display_name() suddenly returns an unknown nametype

(1) should not be a problem (except constraining the use of names
while older applications are still being used), but (2) is difficult:
how can a gssapi mechanism distinguish when it is ok to return a
newer UTF-8 style nametype from gss_display_name(), and when
doing it will cause the calling (old) application to choke and break.

So when we add UTF8-encoded nametypes, then we should define how
an application can indicate to the gssapi-mechanism that it is
a new application and aware of UTF-8 and will not break when
gss_display_name returns an UTF-8 based nametype or
gss_display_status returns UTF8-encoded text.
  
-Martin

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 1 Jul 2005 14:09:17 -0500

> interoperability are according to *MY* experience:

There are interoperable implementations of channel bindings.

For years MIT's FTP w/ GSS-API implementation used channel bindings.

>  - hostbased service names

There are interoperable implementations of hostbased service names.

A number of NFS implementors interoperate using the Kerberos V mechanism
and hostbased service names.

Demonstrations can be arranged.

> and may outright prevent interoperability in a heterogeneous

I'd like SPKM to be moved to Historic.

> set is the default on the platform.

RFC2744 speaks of Latin-1 -- a really poor choice.  Instead the
character encoding and any language settings (for localization in
gss_display_status(), say) should be platform-specific, with conversions
to/from UTF-8 or any other character set/encoding left to mechanisms
where they require it.

Most platforms nowadays have a concept of locale.

POSIX should have a thread-safe notion of locale, and one could be
grafted on to it, and really should be, but it's not there yet.

> rather than the default local 8-bit charset.

Or the application could communicate this to the GSS implemantation
using locales, letting the mechanisms convert as necessary.

This is not a perfect solution, to be sure, as it's not possible to
enter all Unicode characters or equivalents in most non-Unicode locales.

But then, if users are running in non-Unicode locales and need to enter
or display Unicode characters that their non-Unicode locales don't allow
for, well, then they should start using Unicode locales.

I.e., I see the GSS-API I18N issues as mostly, or entirely, even, a
platform- and mechanism-specific issue.

Nico
--