Subject: [Kitten] Proposed Charter

From: Jeffrey Altman <[email-masked]>
Date: Wed, 08 Sep 2004 14:25:02 -0400

Attached is the proposed charter as of the IETF 60 BOF.
Now is the time to discuss on the list any changes we would
like to make prior to submitting the Charter to the IESG
for approval.

Jeffrey Altman

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 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 
   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. 

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.

Milestones
Either:
 o Clarifications to GSSAPIv2 (six months to IESG) 
   Informational
   [editor: TBD] 
Or:
 o Generic Security Service Application Program Interface Version 2, Update 2 
   (six months to IESG)
   Proposed Standard
   [editor: TBD] 
 o Generic Security Service API Version 2 : C-bindings (six months to IESG)
   Proposed Standard
   [editor: TBD]
End:
 o The Channel Conjunction Mechanism (CCM) for the GSSAPI (six months 
   to IESG) 
   Proposed Standard
   [editors: Nicolas Williams/Mike Eisler] 
 o 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
 o GSSAPIv3 (18 months to IESG)
   Proposed Standard
   [editor: to be determined]
 o 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
 o 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
 o 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 
 o SPNEGO (RFC 2478) Revisions (18 months to IESG)
   Proposed Standard
   [editor: TBD] 
 o C# Bindings for GSSAPI 
   Proposed Standard
   [editor: Larry Zhu]

End of Milestones

MAILING LIST:
The mailing list for discussions is 

  [email-masked]

Use the following web page to join:

  https://www1.ietf.org/mailman/listinfo/kitten 

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Sep 2004 14:56:50 -0400

Several of us requested adding a PRF for gssapi as an extension.  Nico
has a draft to do this.  There were no objections.

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 8 Sep 2004 18:21:03 -0400

>      (e.g., use pointers to incomplete structs)

Do we need to specify this level of detail, and by implication exclude 
any other issues that may come up?  Would

   o C language utilization clarifications and recommendations (e.g., 
type utilization, name spaces)

suffice?

> GSSAPI v3 to support the following extensions:

I don't think this phrasing goes quite so far in prohibiting us from 
considering changes not explicitly listed....

>  o Specify thread safety extensions to allow multi-threaded 

First, this probably belongs with "language bindings specification 
work".  Second, as stated, this is not limited to the C bindings, 
correct?  I don't recall if we ever discussed that point.

>  o Generic Security Service API Version 2 : C-bindings (six months to 

... Update 1?

>  o GSSAPI Mechanisms without a Single Canonical Name (12 months to 

Perhaps "Unique" rather than "Single"?  That might be redundant, but 
"without a single..." makes me think "zero", not "not precisely one".

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 09 Sep 2004 14:35:06 -0400

> any other issues that may come up?  Would

I do not think that we need to specify this level of detail.

> correct?  I don't recall if we ever discussed that point.

I don't think we discussed this in detail.  My assumption was that
thread safety is language binding specific but that part of the problem
was that there is a lack of expectations set by the base document.

At the moment we do not have a separate section of work items for
the Language Bindings vs the base document.

Do we need to list the impact of the proposed extensions on the
Language Bindings separately?

Jeffrey Altman