Kitten (GSS-API Next Generation) (kitten)

Kitten (GSS-API Next Generation) (kitten)
-----------------------------------------

Charter
Last Modified: 2007-03-12

Current Status: Active Working Group

Chair(s):
Jeffrey Altman <[email protected]>

Security Area Director(s):
William Polk <[email protected]>
Sam Hartman <[email protected]>

Security Area Advisor:
Sam Hartman <[email protected]>

Mailing Lists:
General Discussion:[email protected]
To Subscribe: https://www1.ietf.org/mailman/listinfo/kitten
Archive: http://www1.ietf.org/mail-archive/web/kitten/current/index.html

Description of 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
o Document internationalization issues

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 GSS-API
o Define a GSS-API 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 GSS-API
extensions document.
o Extensions to deal with mechanism-specific extensibility in a
multi-mechanism environment.
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 pseudo-Random Function for GSS-API
o Specify extensions to GSS-API to address internationalization issues.

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
implementation

This working group is chartered to perform the following new GSS-API
Language Binding specification work:

o Specify a language binding for C#

Goals and Milestones:

Done First Meeting

Mar 2005 First drafts of either 'Clarifications to GSSAPIv2' as
Informational ORsubmit 'Generic Security Service Application
Program Interface Version 2, Update 2' and 'Generic Security
Service API Version 2, Update 2 : C-bindings' to the IESG as
Proposed Standard

Jul 2005 Submit either 'Clarifications to GSSAPIv2' as Informational OR
submit 'Generic Security Service Application Program Interface
Version 2, Update 2' and 'Generic Security Service API Version
2, Update 2 : C-bindings' to the IESG as Proposed Standard

Jul 2005 Submit 'The Channel Conjunction Mechanism (CCM) for the GSSAPI'
to the IESG as Proposed Standard

Jul 2005 Submit 'On the Use of Channel Bindings to Secure Channels' to
the IESG as Proposed Standard

Jul 2005 Submit 'The Simple and Protected GSS-API Negotiation Mechanism
(Revised)' to the IESG as Proposed Standard

Nov 2005 Submit 'GSSAPI Mechanisms without a Unique Canonical Name' to
the IESG as Proposed Standard

Jul 2006 Submit 'Generic Security Service Application Program Interface
Version 3' to the IESG as Proposed Standard

Jul 2006 Submit 'Generic Security Service API Version 3 : C-bindings' to
the IESG as Proposed Standard

Jul 2006 Submit 'Generic Security Service API Version 3 : Java and C#
bindings' to the IESG as Proposed Standard

Nov 2006 Charter Review

Internet-Drafts:

Posted Revised I-D Title <Filename>
------ ------- --------------------------------------------
Dec 2004 Sep 2006 <draft-ietf-kitten-gssapi-domain-based-names-03.txt>
GSS-API Domain-Based Service Names and Name Type

Dec 2004 Sep 2006 <draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt>
GSS-API Domain-Based Service Names Mapping for the Kerberos V
GSS Mechanism

Request For Comments:

RFC Stat Published Title
------- -- ----------- ------------------------------------
RFC4178Standard Oct 2005 The Simple and Protected Generic Security
ServiceApplication Program Interface (GSS-API)
Negotiation Mechanism

RFC4401Standard Feb 2006 A Pseudo-Random Function (PRF) API Extension for the
Generic Security Service Application Program Interface
(GSS-API)

RFC4402Standard Feb 2006 A Pseudo-Random Function (PRF) for the Kerberos V
Generic Security Service Application Program Interface
(GSS-API) Mechanism

RFC4768 I Dec 2006 Desired Enhancements to Generic Security Services
Application Program Interface (GSS-API) Version 3 Naming