Re: Proposed Charter (Draft #3)

[Wyllys Ingersoll <[e-mail]>]

I'm volunteering to edit the new SPNEGO document.

-Wyllys


Jeffrey Altman wrote:

> * incorporates proposed text change from Nico
>
> * incorporates new work item: domain service principal name
>
> any other 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 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 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. 
> o Update the GSSAPI Java Language Bindings to match actual implementation
>
>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: Mike Eisler/Nicolas Williams] 
>   draft-ietf-nfsv4-ccm-03.txt
>   (Currently in NFSv4 Working Group - should it be moved?)
> o On the Use of Channel Bindings to Secure Channels (six months to IESG) 
>   Proposed Standard
>   [editor: Nicolas Williams]
>   draft-ietf-nfsv4-channel-bindings-02.txt
>   (Currently in NFSv4 Working Group - should it be moved?)
> 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