Re: Proposed Charter (Draft #2)

[Nicolas Williams <[e-mail]>]

Are we taking the CCM document from the NFSv4 WG?  Also, I'm not the
editor of that one -- Mike Eisler is (I'm not sure if he's on this list
either).

My understanding was that we'd last call CCM in both WGs.

Also, I take it the C# bindings are now part of KITTEN's charter?  (I
don't mind, mind you.)  If so, Sun has some corrections to make to the
Java bindings RFC (the error codes used by Sun's implementation don't
agree with the ones in the RFC; it's easier to change the RFC than to
fix the implementations and recompile the apps).

Nico


On Thu, Sep 09, 2004 at 02:38:49PM -0400, Jeffrey Altman wrote:
> Incorporating PRF and most of Ken Raeburn's comments.
> 

> 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 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  
>    group. 
>  o Define 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. 
>  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. 
> 
> 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, Update 1 : 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 Unique 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 Pseudo-Random Function for GSSAPI
>    to be folded into GSSAPIv3
>    [editor: Nicolas Williams]
>  o C# Bindings for GSSAPI 
>    Proposed Standard
>    [editor: Larry Zhu]
> 
> End of Milestones
> 
> 
> MAILING LIST:
> The mailing list for discussions is 
> 
>   [e-mail]
> 
> Use the following web page to join:
> 
>   https://www1.ietf.org/mailman/listinfo/kitten 
> 




> _______________________________________________
> Kitten mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/kitten


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