Re: Proposal to export gssapi context

Could we please call anything in that direction an optional extension
to GSS-API that doesn't change the existing base spec in any way?

The issues that people have raised can be and ought to be addressed
with an optional extension, there is no change necessary to the base
spec to accomodate any of that.  Changing the base spec would be
extremely counter-productive, it would break existing code or make
existing code non-compliant to the revised spec.

Such silly behaviour used to be a bad habit of the ISO-related standard
bodies with standards such as ASN.1, X.509 and such where people didn't
think ahead in time and broke previous code/specs with new revisions
of the spec.  But when ASN.1-199x is not FULLY backward compatible
ASN.1-199y (y<x) then it is misleading to call them both ASN.1.

The IETFs tradition originally was to extend protocols/specs without
breaking installed base (think of Punycode for example).  Just that
in our case here defining kgss_* calls and new data structures for
optional extensions will be much cleaner and straight forward than
Punycode.  It should be possible for all of you GSS-API extension
fanciers to live up to this IETF tradition.


Some of you may want one or the other extra feature for your niches,
but that is going to be a niche-specific GSS-API extension that
is not going to be of interest to the majority of GSS-API implementors
and not going to be usable for portable GSS-API based applications
(portable in the sense that rfc-2743 defines).

Feel free to create an discuss an document for optional GSS-API
extensions (new calls, new data structures), but don't touch the
base spec.

Many years ago there was a proposal for a GSS-API extension (XGSS-API)
to deal with authorization (group membership, ACLs and such),
an extension that was an integral part of the SESAME architecture
and that really had a significant level of abstraction (much better
than any of the gssapi extensions proposals that I've seen on
the Kerberos mailing list over the past few years).

Anyway, there was so little interest outside of the SESAME niche
that there never was any real discussion in the CAT WG.  The document
died with I-D expiration; it was not even published as Informational
although it was a good and workable spec for a realworld architecture
and middleware.

However the best thing about XGSS-API was that is was an optional
extension that didn't mess with or require changes to base GSS-API!

-Martin


Douglas E. Engert wrote:
> 
> Sounds like a plan.
> 
> 
> Sam Hartman wrote:
> > 
> > >>>>> "Douglas" == Douglas E Engert <[email protected]> writes:
> > 
> >     Douglas> Are you proposing that at the 60th IETF we get the CAT
> >     Douglas> group going again to address GSSAPI deffeciencies? I
> >     Douglas> think that would be a great idea!
> > 
> > Several of us have wanted to do that soon.  I think IETF 60 sounds
> > like as good a start as any.  I'll send out my proposed set of issues
> > for a WG w to work on later today.  Then we can see if we can find
> > people to chair a BOF and to be document editors.
> > 
> > If so, we should propose a BOF to Russ and Steve.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]