2.6.6 Kitten (GSS-API Next Generation) (kitten)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-01


Jeffrey Altman <jaltman@columbia.edu>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: kitten@lists.ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/kitten
Archive: http://www1.ietf.org/mail-archive/web/kitten/current/index.html

Description of Working Group:

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
based on experience using GSSAPI over the last 10 years. Extensions may
be published as separate drafts or included in a GSSAPI version 3.
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
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

This working group is chartered to perform the following new GSSAPI
Language Binding specification work:

o Specify a language binding for C#


o Clarifications to GSSAPIv2 (May 2005 to IESG)Informational
[editor: TBD]
o Generic Security Service Application Program Interface Version 2,
Update 2
[editor: TBD]
o Generic Security Service API Version 2, Update 1 : C-bindings
[editor: TBD]

o The Channel Conjunction Mechanism (CCM) for the GSSAPI
[editors: Mike Eisler/Nicolas Williams]
(based on draft-ietf-nfsv4-ccm, which has been discussed previously in
the NFSv4 WG)

o On the Use of Channel Bindings to Secure Channels
[editor: Nicolas Williams]
(based on draft-ietf-nfsv4-channel-bindings, which has been discussed
previously in the NFSv4 WG)

[editor: to be determined]

o Stackable Generic Security Service Pseudo-mechanisms
[editor: Nicolas Williams]

o GSS-APIv2 Extension for Storing Delegated Credentials
[editor: Nicolas Williams]

o GSSAPI Mechanisms without a Unique Canonical Name
[editor: Sam Hartman]

o SPNEGO (RFC 2478) Revisions
[editor: Wyllys Ingersoll / Larry Zhu]

o Guide to the GSS-APIv3
[editor: Nicolas Williams]

o Namespace Considerations and Registries for GSS-API Extensions
[editor: Nicolas Williams]

o GSS-API Domain-Based Service Names and Name Type
[editor: Nicolas Williams]

o GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS
[editor: Nicolas Williams]

o A PRF API extension for the GSS-API
[editor: Nicolas Williams]

o A PRF for the Kerberos V GSS-API Mechanism
[editor: Nicolas Williams]

o Generic Security Service API Version 2 : Java & C# Bindings
[editors: Larry Zhu / Corby Morris]

Goals and Milestones:

Done  First Meeting
Mar 05  First drafts of either 'Clarifications to GSSAPIv2' as Informational ORsubmit 'Generic Security Service Application Program Interface Version 2, Update 2' and 'Generic Security Service API Version 2, Update 2 : C-bindings' to the IESG as Proposed Standard
Jul 05  Submit either 'Clarifications to GSSAPIv2' as Informational OR submit 'Generic Security Service Application Program Interface Version 2, Update 2' and 'Generic Security Service API Version 2, Update 2 : C-bindings' to the IESG as Proposed Standard
Jul 05  Submit 'The Channel Conjunction Mechanism (CCM) for the GSSAPI' to the IESG as Proposed Standard
Jul 05  Submit 'On the Use of Channel Bindings to Secure Channels' to the IESG as Proposed Standard
Jul 05  Submit 'The Simple and Protected GSS-API Negotiation Mechanism (Revised)' to the IESG as Proposed Standard
Nov 05  Submit 'GSSAPI Mechanisms without a Unique Canonical Name' to the IESG as Proposed Standard
Jul 06  Submit 'Generic Security Service Application Program Interface Version 3' to the IESG as Proposed Standard
Jul 06  Submit 'Generic Security Service API Version 3 : C-bindings' to the IESG as Proposed Standard
Jul 06  Submit 'Generic Security Service API Version 3 : Java and C# bindings' to the IESG as Proposed Standard
Nov 06  Charter Review


  • draft-ietf-kitten-2478bis-05.txt
  • draft-ietf-kitten-gss-naming-02.txt
  • draft-ietf-kitten-gssapi-prf-04.txt
  • draft-ietf-kitten-krb5-gssapi-prf-04.txt
  • draft-ietf-kitten-rfc2853bis-00.txt
  • draft-ietf-kitten-gssapi-v3-guide-to-00.txt
  • draft-ietf-kitten-extended-mech-inquiry-00.txt
  • draft-ietf-kitten-stackable-pseudo-mechs-00.txt
  • draft-ietf-kitten-gssapi-channel-bindings-00.txt
  • draft-ietf-kitten-gssapi-store-cred-00.txt
  • draft-ietf-kitten-gssapi-extensions-iana-00.txt
  • draft-ietf-kitten-gssapi-naming-exts-00.txt

    No Request For Comments

    Current Meeting Report

    The Kitten working group met at IETF63 in one of the new style rooms.
    We really lucked out because the room contained at least three mobile
    microphones that were handed out to the audience.  It enabled
    realtime discussions in a much more flexible format.  We would like
    to see more of this at future IETF meetings.  More mobile mics the
    Summarized document status:
    * PRF API extension for GSS draft -05 submitted
      Addresses issues raised during the most recent WGLC.
      Will be submitted for a short WGLC next week
    * PRF API for Kerberos 5 GSS draft -04 passed WGLC
      Being held until the generic PRF extension document
      passes WGLC
    * Corrections and Updates of GSS-API Java Bindings
      The existing draft contains a list of changes from RFC 2853.
      These changes were the result of the Java Community Process
      making changes after the RFC was finished.  The JCP is what
      was implemented.   The IETF is effectively rubber stamping
      these changes as no one implements the RFC.
      It has been made clear to Sun that for current work the JCP
      cannot make changes after the documents pass last call.  A
      new draft will be submitted shortly that is 2853 with all of
      the changes applied.
    * C# Bindings
      Since IETF62 consensus was reached to split the C# and Java
      Bindings into separate documents.
      A new draft providing a full C# binding based upon
      RFC 2853 will be published next week.
    * Desired Enhancements to GSS Naming
      An informational draft providing scope for the naming problems
      the working group will solve.   All sections but number 7
      appear to be ready for WGLC.  The chair wishes to expand the
      description of the credential selection problem described by
      section 7 before it moves forward.
    * GSS-API Naming Extensions
      Draft -00 submitted in May but has not received discussion
      on the mailing list.
    * Clarifications to GSSAPI v2 Update 1
      No draft yet published and the milestone has been missed
      Previous volunteers to work on this draft have withdrawn.
    Technical Discussions: GSS-API Naming Extensions
    The working group reviewed the contents of the draft for the
    purpose of boot strapping discussion as no one had read it
    before the meeting.
    The draft has a summary of the problems caused by the limited
    naming capabilities of GSS import and export name when attempting
    to use the authenticated name for the purpose of constructing ACLs.
    This is followed by five sections describing how to extend GSS names
    with name attributes including sections on how to use pkix attributes
    and kerberos authorization data.   The details are very incomplete
    and need significant review.  We especially need volunteers from
    the pkix community to assist in this effort.
    The document describes a proposed abstract api plus C and java
    language bindings.  There is also an IANA considerations.
    * use of names on ACLs
    * the need for including critical bit on attributes.  This is expected
      to be easy for PKIX but it is not authenticated.
    * corrections to the use of kerberos cross realm transit paths.
      cross realm transit path lists are not ordered.  they only provide
      a list of the realms that were crossed.
    * the current draft's description of how to reference x.509 trust paths
      is very incomplete.  The full path from the trust anchor must be
    * Inclusion of PKIX proxy certificates must be specified
    * Must ensure that the EKU OID is used as part of PKIX names
    * There is concern that naming is an extremely broad and highly complex
      problem.  Can it be done in a simple generic manner?
    * The inquire function scares many people.
    * name attributes are being treated as tagged blobs.  This results in
      problems both with how to represent dependencies between blobs and
      how to handle in a generic manner how to extract sub-parts of a blob.
    * there is a concern with how we can successfully compare names when
      there are arbitrary sets of name attributes.   What is the canonical
      name?   Part of the justification for this work is because there is
      not always a canonical name that is static for all time.
    * there needs to be a means of limiting the credentials provided to
      an application based upon the needs of the application and the
      qualities the credentials support.
    * Denis Pikas wrote for CAT a draft to describe how to represent
      group membership.  It can be found via google.  The wg should
    * Review closely the saml attribute work
    * There is a desire to support negative attributes.   In order to
      do so there must be some means of indicating that for a given set
      of positive and negative ACLs that all of the negative ACLs have
      been included and none have been removed.
    The wg ran out of time.  Clearly more discussion is required on the
    list.  Please read the draft.
    Technical Discussion:  Moving RFC2743 and RFC2744 to Draft
    Our AD, Sam Hartman, requested that the WG consider the steps necessary
    to move RFCs 2743 and 2744 from Proposed to Draft.
    The wg discussed the scope of interoperability testing at both the
    wire and language layers.  The wg intends to design a test matrix that
    is rough grained across implementation of features.   Nico Williams
    will ask for assistance within Sun Microsystems for assistance to the
    chair in putting together the test matrix.  The WG will look at
    gssmonger as a source of tests.
    Technical Discussion:  Review ML archives to find content for
    'Clarifications to GSSAPIv2'
    The wg ran out of time to discuss this topic.   The chair is going
    to ask specific people for assistance with this task.  If this milestone
    is not being bet the wg will have to stop working on other efforts
    people care a great deal about.


    Agenda, Document Status, and Technical Outline
    Naming Extensions Draft