Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.21] [Fwd: [802SEC] FW: [New-work] WG Review: Kitten (kitten)]



Eric,

My email was for informational purposes ONLY. First, no decision has been made
by IESG on the formation of the group. Second, I have not made any determination
of if or how this work would impact us. If any one has any thoughts they are
welcome to let our group know about it.

regards,
-ajay


On 10/22/2004 11:14 AM, NJEDJOU Eric RD-RESA-REN wrote:
> Hi ajay, Does the creation of this group really impact our work in 21? I can
> not figure out how... Best Regards Eric
>
> -----Message d'origine----- De : owner-stds-802-21@listserv.ieee.org
> [mailto:owner-stds-802-21@listserv.ieee.org] De la part de Ajay Rajkumar
> Envoyé : vendredi 22 octobre 2004 15:28 À : STDS-802-21@listserv.ieee.org
> Objet : [Fwd: [802SEC] FW: [New-work] WG Review: Kitten (kitten)]
>
> Folks,
>
> FYI. This is new work being proposed in the IETF.
>
> -ajay Chair, IEEE 802.21 WG
>
> -------------------------------------------------------------------------
>
> A new IETF working group has been proposed in the Security Area.  The IESG
> has not made any determination as yet. The following description was
> submitted, and is provided for informational purposes only. Please send your
> comments to the IESG mailing list (iesg@ietf.org) by October 27th.
>
> Kitten (kitten) ================
>
> Current Status: Proposed Working Group
>
> Description:
>
> 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.