Kitten (Daughter of CAT) BOF (kitten)
Monday, August 2 at 1530-1730
=============================
CHAIR: Jeffrey Altman <
[email protected]>
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
[email protected].
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.
