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
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten