Subject: Re: request for agenda items

From: Martin Rex <[email-masked]>
Date: Fri, 1 Jul 2005 20:01:08 +0200 (MET DST)

Sam Hartman wrote:
> 
> I actually suspect Martin may well already have sufficient data to
> meet the interop requirements for draft standard.  I don't know if he
> would be willing to share that data with us or whether his
> confidentiality agreements would allow him to do so.

As you mention it, it is actually surprising that with most
vendors that asked for interoperability certification, they
downloaded and used gsstest and sent me the output for review and
comment long before they signed a formal certification agreement
(because that comes with a cost).

There is, of course, the expectation of privacy of those Email
discussions as well as the general confidentiality agreement on
work-related issues with my employer.

Because of the procedure that we use for certification (there
is also a test plan how to verify interoperability with our
real application, not just gsstest, and we have a department with
several offices worldwide which performs the real certification
procedure when the vendor thinks he's ready, based on the
test-plan, gsstest, and my review/comments on the output of gsstest).
Myself, I have no hands-on experience with most of the gssapi mechanisms
that we certified for interoperability with our application, i only
know what gsstest told me about their behaviour and characteristics.

It should be OK if I sent Emails to the developers
who worked on the interoperability certification and
ask them whether they would be willing to participate
official interoperability testing for the IETF purpose
to advance the GSS-API spec to draft standard.

Some of the developers may have changed jobs/companies meanwhile
and their Email addresses no longer work, and most of them have
probably never particiated an IETF activity...

But in order to get participation, we should have a plan how
this is going to done -- what those developers/companies
would have to do in order to help us.

-Martin

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

---

From: "Tim Alsop" <[email-masked]>
Date: Fri, 1 Jul 2005 19:07:31 +0100

Martin,

We regularly use gsstest, and I am willing to submit our gsstest reports
for IETF consideration if required.

Thanks, Tim 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: 01 July 2005 19:01
To: Sam Hartman
Cc: [email-masked]
Subject: Re: request for agenda items

> confidentiality agreements would allow him to do so.

As you mention it, it is actually surprising that with most vendors that
asked for interoperability certification, they downloaded and used
gsstest and sent me the output for review and comment long before they
signed a formal certification agreement (because that comes with a
cost).

Because of the procedure that we use for certification (there is also a
test plan how to verify interoperability with our real application, not
just gsstest, and we have a department with several offices worldwide
which performs the real certification procedure when the vendor thinks
he's ready, based on the test-plan, gsstest, and my review/comments on
the output of gsstest).
Myself, I have no hands-on experience with most of the gssapi mechanisms
that we certified for interoperability with our application, i only know
what gsstest told me about their behaviour and characteristics.

It should be OK if I sent Emails to the developers who worked on the
interoperability certification and ask them whether they would be
willing to participate official interoperability testing for the IETF
purpose to advance the GSS-API spec to draft standard.

Some of the developers may have changed jobs/companies meanwhile and
their Email addresses no longer work, and most of them have probably
never particiated an IETF activity...

But in order to get participation, we should have a plan how this is
going to done -- what those developers/companies would have to do in
order to help us.

-Martin

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Sat, 2 Jul 2005 16:23:38 -0700

Note that channel bindings are implemented for Kerberos SSP on WinXP and
later.

I believe our customers were able to use our channel bindings to interop
with MIT's FTP servers.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Friday, July 01, 2005 10:12 AM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: request for agenda items

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