[802SEC] FW: [New-work] WG Review: Kitten (kitten)
Working Group Chairs,
The following new proposed working group within the IETF may be of
interest to your working group members. Feel free to forward this info
onto your working group if appropriate.
From: firstname.lastname@example.org [mailto:email@example.com] On
Behalf Of The IESG
Sent: Wednesday, October 20, 2004 11:27 AM
Subject: [New-work] WG Review: Kitten (kitten)
A new IETF working group has been proposed in the Security Area. The
IESG has not made any determination as yet. The following description
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list (firstname.lastname@example.org) by October
Current Status: Proposed Working Group
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 core GSSAPI
specification and language bindings 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 clarifications and recommendations (e.g., type
utilization, name spaces) 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 including support for 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
o Define a GSSAPI extension to allow applications to store credentials.
Discussions to be started based upon:
o Extensions to solve problems posed by the Global Grid Forum's GSSAPI
o Extensions to deal with mechanism-specific extensibility in a
o Extend the GSS-API to support authorization by portable GSS
applications while also supporting mechanisms that do not have a single
canonical name for each authentication identity.
o Specify a Domain-based GSS service principal name consisting of:
service name, host name, and domain name for use by application services
hosted across multiple servers.
o Extensions to support stackable GSSAPI mechanisms.
o Define a Psuedo-Random Function for GSSAPI
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.
o Update the GSSAPI Java Language Bindings to match actual
This working group is chartered to perform the following new GSSAPI
Language Binding specification work:
o Specify a language binding for C#
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.
New-work mailing list
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.