CAT Fanciers:
Four years ago this month, the CAT working group became dormant. Some time after that , the working group concluded. During the intervening years we have gained significant implementation experience with GSSAPI, GSSAPI mechanisms, SPNEGO and other related technologies. There has been significant interest in some continuing evolution of the GSSAPI specifications within the IETF during this time. Doug has proposed that we start a working group to move forward on these issues. I agree. Assuming that we can find a chair for a BOF and potentially for a working group and can find document editors, I propose that we request a BOF slot at IETF 60 for the purpose of starting the offspring of CAT working group (KITTEN). I believe that KITTEN should be chartered for the following tasks and for any additional tasks that members of this list believe have sufficient constituency. * Eventually to advance the base GSSAPI specifications and C bindings to draft standard (but see below) * During the course of implementing GSSAPI and GSSAPI mechanisms, significant problems in the clarity of the base specification and C bindings have been found. KITTEN will identify these problems and will propose changes to the specifications to address issues of clarity. * The handling of channel bindings in the base specification and C bindings has proven problematic. The structure of channel bindings is defined more in the C bindings than in the base specification. This has forced mechanism specifications and protocol documents to refer to the C bindings specification. In addition, there is a desire in several areas of the IETF for more complex channel bindings than IP addresses and more thought to be put into how channel bindings work. KITTEN will clarify specification of channel bindings to meet current needs of the IETF. * Experience with GSSAPI naming has caused implementers and application authors to wish to look at ways of improving naming. KITTEN will examine proposals in this area. * Experience is the Kerberos working group has caused individuals in the Kerberos community to question the assumption behind gss_export_name--that names can reasonably have a single canonical form fixed for some period of time. KITTEN will consider this issue and the general issue of GSSAPI authorization and how it relates to naming. [Martin, yes I know you would object very strongly to dropping gss_export_name. I'm fairly sure there are enough of us who want to revisit the issue that it is important to include in the charter. I fully realize that we do not yet have any consensus for any specific change.] * The Global Grid Forum has advanced several proposals for extensions to GSSAPI. KITTEN will consider these proposals and see if there are mechanisms acceptable to the IETF for accomplishing the same goals as these proposals. * Mechanism implementers have complained that GSSAPI is too complicated and thus they prefer to write SASL mechanisms rather than GSSAPI mechanisms. KITTEN will produce a document describing how to write a GSSAPI mechanism specification. The following work might belong in the KITTEN working group although it currently lives in other IETF working groups: * TThe CCM mechanism in the NFSV4 working group * The domain-based GSSAPI names that will hopefully be a work item of SASL some day -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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]
