Kitten (Daughter of CAT) BOF (kitten) Monday, August 2 at 1530-1730 ============================= CHAIR: Jeffrey Altman AGENDA: * Introduction and Welcome [5 minutes] - Jeffrey Altman * Discussion of the Global Grid Forum GSS requirements [15 minutes] - To Be Determined * Discussion of channel bindings portability issues (C struct et all) [10 minutes] - Sam Hartman * Discussion of GSSAPI naming [15 minutes] - Sam Hartman * Discussion of need for cryptographic channel bindings and CCM [10 minutes] - Nicolas Williams * Discussion of specific channel bindings [10 to 15 minutes] - To Be Determined * Discussion of Stackable Psuedo Mechanisms [10 minutes] - Nicolas Williams * Discussion of the SPNEGO issues [10 minutes] - Wyllys Ingersol * Charter discussion [15 minutes] - Jeffrey Altman DESCRIPTION: During the years since the Security Area's Common Authentication Technology working group closed its doors there has been significant new experience gained by those designing applications which utilize GSSAPI v2 update 1 and the GSSAPI v2 C Language Bindings. This experience has demonstrated several areas within the existing RFCs (2743 and 2744) which are less than well-defined and/or lacking in functionality. Attempts to address these deficiencies have resulted in discussions taking place in many inappropriate forums. Some attempts have occurred within existing IETF working groups which have rejected the work as being outside the existing charter. Other attempts have been pursued by third party organizations such as Global Grid Forum which have chosen to extend IETF standards on their own due to an inability to find a forum within IETF to pursue their work. The discussions on the IETF-CAT mailing list over the last several months have been quite contentious not to mention fun to read. The fruits of these discussions are the following: o There are a number of interested parties who would like to produce an new and improved GSSAPI specification be created to address issues related to credentials management; thread safety; channel binding usability (as discussed at IETF Minneapolis SAAG); C Language usage; ABI stability; mechanism specific extensibility; and support for mechanisms which do not provide a single canonical name. o There is an apparent consensus that the existing GSSAPI v2 RFCs should be revised to include improved language to clarify areas which have resulted in confusion for GSS mechanism implementors and application developers. There should be new text describing the lack of thread safety in GSSAPI v2 as well as descriptions of how to support IPv6 in the existing channel bindings. However, these revisions must not change the specification in any way which would affect backward interoperability with either existing implementations of GSSAPI v2 or even GSSAPI v1. o There is an apparent consensus that a new GSSAPI v3 specification be created to support the extended functionality that is required. o There is rough consensus that work should proceed to develop new forms of non-address based channel bindings which may be used to bind GSS to TLS, IPSec, SSH, and other cryptographic channels. o There are also proposals that a new mechansism for negotiating and properly using channel bindings (CCM) should be defined and that SPNEGO (RFC 2748) be updated to correct flaws in its design and specification. The current participants of the IETF-CAT mailing list believe the time is right to form the Common Authentication Technology Next Generation working group (aka Kitten) to address these work areas. As such we would like permission from the IESG to form the working group at San Diego or if necessary to hold a BOF to discuss the need for the working group and the scope of its charter. What follows is a proposed charter for the Kitten Working Group. o Proposed Charter The Generic Security Services API [RFC 2743, RFC 2744] provides an API for applications to set up security contexts and to use these contexts for per-message protection services. The Common Authentication Technology Next Generation Working Group (Kitten) will work on standardizing extensions and improvements to the GSSAPI that the IETF believes are necessary based on experience using GSSAPI over the last 10 years. Extensions may be published as separate drafts or included in a GSSAPI version 3. While version 2 of the GSSAPI may be clarified, no backward incompatible changes will be made to this version of the API. This working group is chartered to revise the GSSAPI v2 RFCs for the purpose of clarifying areas of ambiguity: o Use of channel bindings o Thread safety restrictions o C Language utilization o use of const o utilization of gss types by the application o gss name space o improve recommendations for implementation specific types (e.g., use pointers to incomplete structs) o Guidelines for GSS-API mechanism designers o Guidelines for GSS-API application protocol designers This working group is chartered to specify a non-backward compatible GSSAPI v3 to support the following extensions: o Clarify the portable use of channel bindings and better specify channel bindings in a language-independent manner. o Specify thread safety extensions to allow multi-threaded applications to use GSSAPI o Definitions of channel bindings for TLS, IPSec, SSH and other cryptographic channels based on work started in the NFSV4 working group. o Defined a GSSAPI extension to allow applications to store credentials. Discussions to be started based upon: o draft-williams-gss-store-deleg-creds-xx.txt o Extensions to solve problems posed by the Global Grid Forum's GSSAPI extensions document. o Extensions to deal with mechanism-specific extensibility in a multi-mechanism environment. o Extend GSSAPI to support mechanisms that do not have a single canonical name for each authentication identity. o Extensions to support stackable GSSAPI mechanisms. This working group is chartered to perform the following GSSAPI mechanism specification work: o Specify a GSSAPI v2/v3 Channel Conjunction Mechanism o Revise RFC 2748 (SPNEGO) to correct problems that make the specification unimplementable and to document the problems found in widely-deployed attempts to implement this spec. End of Proposed Charter The participants of the IETF-CAT mailing list realize the quantity of work which we desire to undertake is quite ambitious in scope. This is simply an indication of how much work has accumulated over the last few years since the CAT working group disbanded. We believe that we can accomplish the stated work items in 18 months. Milestones o Clarifications to GSSAPIv2 (six months to IESG) o Informational o [editor: Jeffrey Altman] o The Channel Conjunction Mechanism (CCM) for the GSSAPI (six months to IESG) o Proposed Standard o [editors: Nicolas Williams/Mike Eisler] o On the Use of Channel Bindings to Secure Channels (six months to IESG) o Proposed Standard o [editor: Nicolas Williams] o draft-ietf-nfsv4-channel-bindings-01.txt o GSSAPIv3 (18 months to IESG) o Proposed Standard o [editor: to be determined] o Stackable Generic Security Service Pseudo-mechanisms o Proposed Standard or to be folded into GSSAPIv3 o [editor: Nicolas Williams] o draft-williams-gssapi-stackable-pseudo-mechs-00.txt o GSS-APIv2 Extension for Storing Delegated Credentials o Proposed Standard or to be folded into GSSAPIv3 o [editor: Nicolas Williams] o draft-williams-gssapi-store-deleg-creds-00.txt o GSSAPI Mechanisms without a Single Canonical Name (12 months to IESG) o to be folded into GSSAPIv3 o [editor: Sam Hartman] o draft-hartman-gss-naming-00.txt o SPNEGO (RFC 2478) Revisions (18 months to IESG) o Proposed Standard o [editor: to be determined] End of Milestones MAILING LIST: The current mailing list for discussions is ietf-cat-wg@lists.stanford.edu. Due to the facts that no one at Stanford is actively involved in the discussions and the mailing list software is quite old, the working group when formed will switch to a new mailing list.