Subject: Draft 0 of proposed charter

From: [email-masked] (Sam Hartman)
Date: Tue, 11 May 2004 15:37:20 -0400 (EDT)

Here's a proposed charter.  I realize that it's too long for a real
charter.  For now I'd like to have an exaustive list of all the work
we plan to do so we can evaluate whether our scope is too extensive.
I'd appreciate suggestions on how to actually organize things for a
normal length charter.

Also, feedback is needed on work items.  We need to know if any should
be removed or added.

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
or included in a GSSAPI version 3.  While version 2 of the GSSAPI may
be clarified, no backward incompatible changes may be made to this
version of the API.

This working group is chartered to work on the following extensions to
GSSAPI:

    - Definitions of channel bindings for TLS, IPSec  and other
      cryptographic  channels based on work started in the NFSV4
      working  group.

    - AN interface to store credentials based on
      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.

    - Clarify the portable use of channel bindings and better specify
      channel bindings in a language-independent manner.

    - Specify threading requirements for GSSAPI.

    - Extend GSSAPI to support mechanisms that do not have a single
      canonical name for each authentication identity.

    - Extensions to support stackable GSSAPI mechanisms.

In addition to these extensions  the following mechanism work  is chartered:

    - The CCM mechanism

    - Revisions to RFC 2748 (SPNEGO) to correct problems that make the
      spec unimplementable and to document problems in
      widely-deployed attempts to implement this spec.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 11 May 2004 15:54:22 -0500

On Tue, May 11, 2004 at 03:37:20PM -0400, Sam Hartman wrote:
>            Extensions may be published as separate drafts or

Right.  It should be clear that many of these extensions are "optional"
from the point of view of GSS-API v2 implementors.

It should also be clear that, while in some cases we seek to make the
use of mechanism-specific or platform-specific extensions more feasible
(particularly in a mechglue environment) we mostly seek to do generic
exntension work (plus mechanisms, like CCM).

I believe most of your list can be summarized in a paragraph or two.

Add to the list of work items to consider:

 - Guidelines for GSS-API mechanism designers

 - Guidelines for GSS-API application protocol designers

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 11 May 2004 17:29:16 -0400

I do not believe this proposed charter is too long.  It does indicate 
that there
are a lot of work items which the KITTEN working group would be expected
to complete.

In order to gain permission for the BOF we should put together a
document for the IESG containing an executive summary of each of the
proposed charter items.  I think a relative priority associated with each
item would also be useful.  With a list this long the two things we are
going to have to demonstrate to the IESG is that there are enough
participants interested in performing the work; as well as the will to get
the work done in a timely manner.

Jeffrey Altman