Subject: Request to create KITTEN (daughter of CAT) BOF at IETF 60

From: Jeffrey Altman <[email-masked]>
Date: Mon, 12 Jul 2004 11:22:03 -0400

[NOTE: Most of this e-mail is the same text as was sent on May 24th.
The changes are in the subject "Request for BOF" instead of "Request
for Working Group"; the addition of a new draft on GSSAPI Naming to the
Charter; the addition of a BOF Agenda section; the addition of a BOF
scheduling preferences section.]

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

use of const

utilization of gss types by the application

gss name space

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:

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

GSSAPI Mechanisms without a Single Canonical Name (12 months to
IESG)

to be folded into GSSAPIv3

[editor: Sam Hartman]

draft-hartman-gss-naming-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.

Kitten BOF Agenda for IETF 60

The following charter is proposed for the Kitten BOF.   The BOF will
require a 2 hour time slot.

* 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

Kitten BOF Scheduling Requests

Please do not schedule on Friday as it is known that two of the
speakers will not

be able to attend due to scheduling conflicts with other events

Presenters at the Kitten BOF are also active draft authors or working
group chairs in

the following groups:  NFSv4, KRB-WG or SASL

Please attempt to avoid scheduling opposite other Security Area working
groups

Sincerely,

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