Subject: Request to create KITTEN (daughter of CAT) Working Group within the IETF Security Area

From: Jeffrey Altman <[email-masked]>
Date: Mon, 24 May 2004 14:28:07 -0400

Russ and Steve:

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:

    * 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.
    * 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.
    * There is an apparent consensus that a new GSSAPI v3 specification
      be created to support the extended functionality that is required.
    * 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.
    * 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.

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:

    * Use of channel bindings
    * Thread safety restrictions
    * 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)
    * Guidelines for GSS-API mechanism designers
    * 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:

    * Clarify the portable use of channel bindings and better specify
      channel bindings in a language-independent manner.
    * Specify thread safety extensions to allow multi-threaded
      applications to use GSSAPI
    * Definitions of channel bindings for TLS, IPSec, SSH and other
      cryptographic  channels based on work started in the NFSV4
      working  group.
    * 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
    * Extensions to solve problems posed by the Global Grid Forum's
      GSSAPI extensions document.
    * Extensions to deal with mechanism-specific extensibility in a
      multi-mechanism environment.
    * Extend GSSAPI to support mechanisms that do not have a single
      canonical name for each authentication identity.
    * Extensions to support stackable GSSAPI mechanisms.

This working group is chartered to perform the following GSSAPI 
mechanism specification work:

    * Specify a GSSAPI v2/v3 Channel Conjunction Mechanism
    * 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

    * Clarifications to GSSAPIv2 (six months to IESG)
      Informational
      [editor: Jeffrey Altman]
    * The Channel Conjunction Mechanism (CCM) for the GSSAPI (six months
      to IESG)
      Proposed Standard
      [editors: Nicolas Williams/Mike Eisler]
    * On the Use of Channel Bindings to Secure Channels (six months to
      IESG)
      Proposed Standard
      [editor: Nicolas Williams]
      draft-ietf-nfsv4-channel-bindings-01.txt
    * GSSAPIv3 (18 months to IESG)
      Proposed Standard
      [editor: to be determined]
    * Stackable Generic Security Service Pseudo-mechanisms
      Proposed Standard or to be folded into GSSAPIv3
      [editor: Nicolas Williams]
      draft-williams-gssapi-stackable-pseudo-mechs-00.txt
    * GSS-APIv2 Extension for Storing Delegated Credentials
      Proposed Standard or to be folded into GSSAPIv3
      [editor: Nicolas Williams]
    * draft-williams-gssapi-store-deleg-creds-00.txt SPNEGO (RFC 2478)
      Revisions (18 months to IESG)
      Proposed Standard
      [editor: to be determined]

End of Milestones

Chairperson
The proposed chairperson for the Kitten WG is Jeffrey Altman.

Mailing List
The current mailing list for discussions is [email-masked].
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.

Sincerely,

Jeffrey Altman (for the participants of the ietf-cat-wg mailing list)