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

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-03


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 2005  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 2005  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 2005  Submit 'The Channel Conjunction Mechanism (CCM) for the GSSAPI' to the IESG as Proposed Standard
Jul 2005  Submit 'On the Use of Channel Bindings to Secure Channels' to the IESG as Proposed Standard
Jul 2005  Submit 'The Simple and Protected GSS-API Negotiation Mechanism (Revised)' to the IESG as Proposed Standard
Nov 2005  Submit 'GSSAPI Mechanisms without a Unique Canonical Name' to the IESG as Proposed Standard
Jul 2006  Submit 'Generic Security Service Application Program Interface Version 3' to the IESG as Proposed Standard
Jul 2006  Submit 'Generic Security Service API Version 3 : C-bindings' to the IESG as Proposed Standard
Jul 2006  Submit 'Generic Security Service API Version 3 : Java and C# bindings' to the IESG as Proposed Standard
Nov 2006  Charter Review


  • draft-ietf-kitten-gss-naming-03.txt
  • draft-ietf-kitten-gssapi-domain-based-names-01.txt
  • draft-ietf-kitten-gssapi-prf-07.txt
  • draft-ietf-kitten-krb5-gssapi-domain-based-names-01.txt
  • draft-ietf-kitten-krb5-gssapi-prf-04.txt
  • draft-ietf-kitten-gssapi-v3-guide-to-01.txt
  • draft-ietf-kitten-extended-mech-inquiry-01.txt
  • draft-ietf-kitten-stackable-pseudo-mechs-01.txt
  • draft-ietf-kitten-gssapi-channel-bindings-01.txt
  • draft-ietf-kitten-gssapi-store-cred-01.txt
  • draft-ietf-kitten-gssapi-extensions-iana-01.txt
  • draft-ietf-kitten-gssapi-naming-exts-01.txt

    Request For Comments:

    RFC4178 Standard The Simple and Protected Generic Security ServiceApplication Program Interface (GSS-API) Negotiation Mechanism

    Current Meeting Report

    ** IETF 64 - Vancouver, BC
    ** GSSAPI Next Generation (Kitten) Working Group
    ** Wed, Nov 9 - 09:00-11:30
    Chair:  Jeffrey Altman
    Scribe:	Love Hörnquist Åstrand
    Jabber: Bob Morgan, Leif Johansson
    The presentation materials are available at:
    The Audio Stream is available at
    The Jabber Logs are available at:
    Agenda =====================================================================
    * Preliminaries - Jeffrey Altman (5 min)
      - Introduction
      - Blue Sheets
      - Scribe, Jabber
      - Agenda Bashing
    * Document Status - Jeffrey Altman (15 min)
      - Sam's Naming Draft
      - PRF drafts
      - C Sharp Binding
    * Technical Discussions:
      - GSS-API Naming Extensions (Nico Williams, Sun Microsystems)   (60 min)
      - Review CAT and KRB-WG mailing list archives to determine contents of
        'Clarifications to GSSAPIv2' as Informational   (60 min)
    * Update Milestones - Chair and Participants (10 min)
    Document Status=============================================================
    * PRF API extension for GSS
      - draft-ietf-kitten-gssapi-prf-07.txt submitted to IESG
    * PRF API extension for GSS KRB5 mech
      - draft-ietf-kitten-krb5-gssapi-prf-04.txt submitted to IESG
    * C# Bindings
      - draft-ietf-kitten-gssapi-csharp-bindings-00.txt
        Juan Carlos Luciani has split the C# Bindings from the Java Bindings 
        into a new draft that has been submitted to Internet-Drafts for 
    * Desired Enhancements to GSS Naming draft
      - draft-ietf-kitten-gss-naming-03.txt WG last call in progress ending 
        Nov 23rd
    * GSS-API Naming Extensions
      - draft-ietf-kitten-gssapi-naming-exts-01.txt
        Topic of technical discussion at this meeting.
    * Clarifications to GSSAPI v2 Update 1
      - No draft yet published.  
        Topic of technical discussion at this meeting.
    Technical Discussions: GSS-API Naming Extensions===========================
    Nico Williams led the working group in a review of the open issues with 
    this document.
      * gss inquire name attributes is scary
      * negatives acl entries vs paritial identity
      * attribute values as tagged blobs vs native types
      * concerns that naming is too hard
      * anonymity/pseudonymity
    Discussions were held on the merits of the gss_inquire_name_attribute()
    functionality.  There are concerns that this function is hard to make 
    work correctly with names that the application does not know how to deal 
    with.  The ability to know how to deal with a particular type can be 
    very environment specific.   This functionality is nice but is not required.
    A preliminary decision was made to remove the functionality from the draft 
    as it has the potential to significantly reduce the portability of 
    Lengthy discussions were held on the support of negative ACLs.  The
    fundamental problem with supporting negative ACLs is that in order for
    them to be valid the evaluator must be able determine that the complete
    set of relevant membership information is available.  This is possible
    to enforce when there is only a single source of ACEs.  However, in the
    model being considered, ACEs can be provided from multiple sources and
    it is extremely difficult to ensure that conflicts or a failure to
    provide relevant ACEs do not occur.  The WG believes there is a need to
    support negative ACLs for applications such as NFSv4.  The WG proposes
    supporting negative ACLs and writing appropriate Security Considerations
    text describing the dangers of certain use cases.
     * negative ACLs only work if all the information is available to 
       the service relying on them to make decisions
     * open questions of how they should work:
       - can there be a special attribute to indicate completeness?
       - should we do nothing and simply wish applications that utilize 
         negative ACLs good luck?
       - can there be mixed deny/allow orderings?
     * Bill Sommerfeld feels there is "lots of doom" in this space.   Partial
       identities are going to be a fact of life in the GSS space.  He is not
       confident a workable solution can be found.
     * Sam Hartman wants us to make sure that we need Negative ACLs.  The WG
       should produce some use cases.   
     * Larry Zhu provided a high level overview of how Negative ACLs are used
       in the Windows Domain.   Negative ACLs are safe to use in this environment
       because Active Directory is able to guarrantee that all of the applicable
       Universal and Domain Global Groups are present in the ACLs.  The ACL 
       management tools will not permit the construction of negative ACLs using 
       groups that might not be present.
    Tagged Blobs:
    The former CAT draft "Extended Generic Security Service APIs: XGSS-APIs
    Access control and delegation extensions" was discussed as it applied to
    the choice between supporting enumerated native types vs. OID tagged
    blobs.  A preliminary decision was made to use OID tagged blobs.
    Is Naming Too Hard?
    Summary of the problem.  GSS "NAME"s are too simple.  APIs to access SAML
    data would be good when SAML data exists but that won't work for X.509.
    Nor would it work for the wide range of other identity (web v2) solutions 
    that are beginning to appear.
    The Kerberos WG is examining a draft which describes an anonyomus mode for
    Kerberos 5.  Kitten needs to consider the implications for GSS.
    Much Rat-holing:
    It is clear that the use of "NAME" in GSS to refer to the "principal"
    (the entity being authenticated) is confusing for many people.  The
    documents need to be extra careful to specify the terminology.
    Technical Discussions: GSS API v2 upd 1 Clarifications====================
    The working group during the meeting wrote text for this document.
    Sections include:
     - Character-set issues
     - Thread safety issues
     - Channel Bindings
       + what to do about lack of a GSS_C_AF_INET6 symbol
     - C language utilization
       + type utilization
       + name spaces
    Chair guidelines:  
     * This is a clarifications document.  No new definitions.  We can discuss
       the lack of necessary symbols but propose solutions.   New definitions 
       should be published as a new document.
    Proposed Text from Ken Raeburn:
     - "pointer or arithmetic type" and ABI (no text yet, just a note)
     - "const" misuse in bindings
     - GSS_C_AF_INET6 (not defined, but we need it now)
     - name spaces (reserved prefixes etc)
     - thread safety
    The use of "const" in function parameters in the GSSAPI C bindings
    specification is mostly ineffective.  According to the C language
    specification, qualifiers like "const" on function parameters (note:
    NOT values pointed to by function parameters) are essentially
    meaningless.  (Even if they had meaning, the only meaning would be
    that a C implementation could not change the values of the arguments
    (holding pointers or arithmetic values) themselves, with no impact on
    the handling of any storage indicated by these handles.)
    There is one case where the use of "const" is actually incorrect.  The
    function gss_accept_sec_context has a parameter "src_name" which is a
    pointer to "const gss_name_t", yet the pointed-to storage is for an
    optional output value.  (This is according to the prototype in
    [RFC2744] section 5.1; the sample header in Appendix A of the same
    document has a different, more correct prototype.)
    The intent appears to be to indicate that the referenced storage -- a
    credential, a buffer, and so on -- is not modified by the GSS
    function.  In cases with opaque types, this can probably be assumed to
    apply only to the semantic value of the underlying object, not merely
    just the immediately-pointed-to storage in the cases where they are
    implemented with pointers.
    Ref: ISO C '99.
    pointer vs arithmetic type -- even aside from varying sizes of arithmetic 
    types, pointers and integers can be passed differently in some platform ABIs, 
    so specifying "pointer or arithmetic type" is not sufficient to define an 
    interoperable ABI.
    ** GSS_C_AF_INET6
    To be fair, this is more of a registry issue.  The list of address
    families, their associated numeric codes, and the encoding are written
    into the C bindings and used by other bindings, when they should be
    language-independent.  The list also predates widespread use of IPv6,
    so it is not surprising that it was left out, when other values like
    GSS_C_AF_CHAOS, which probably has never been used, were included.
    Today, this list would probably be put in an IANA registry, with RFCs
    describing the encoding of each, independent of the languange
    bindings, and information in the language bindings indicating how to
    transform the registered name to [...guess i stopped writing here...]
     ** name spaces
    Aside from names starting with "gss" and "GSS", what names are likely
    to be defined, declared, or used in gssapi.h?  Are any names not
    explicitly defined in [RFC2744] reserved for future use?
    If the header file is provided by the operating system vendor, this
    might qualify it as part of the C implementation, and thus names
    starting with "__" may be used for any internally-used macros or
    typedef names.
    When xom.h is available on a system, it is specified that xom.h is
    included by gssapi.h, so clearly any namespace used by that header (at
    least "OM_*" and "OMP_*" symbols) may be defined by the inclusion of
     ** thread safety
    The simple, safe answer is that a GSSAPI implementation need not be
    thread-safe.  It is likely that implementations will not be safe to
    use in multiple threads simultaneously; it may well be the case that
    some implementations are not safe to use from more than one thread
    under any circumstances.  Even if the implemenation has no internal
    static storage modified by multiple threads, it may call out to other
    routines (in the system libraries or elsewhere) that may not be thread
    safe.  Even if the application uses a mutex lock to ensure that only
    one thread uses the GSSAPI routines at any one time, non-thread-safe
    functions called from it may conflict with non-GSSAPI calls the
    application may make in other threads.
    On the other hand, some implementations have attempted to provide some
    measure of thread safety.  Implementors are encouraged to document
    what level of thread safety they provide, and any restrictions related
    to multithreaded programming.  Portable applications should not use
    GSSAPI in multiple threads, though multithreaded applications may be
    written for specific implementations.
    See also [Boehm] for a discussion of issues in attempting to discuss
    thread support without making it integral to the base language
    Ref: Boehm, Hans-J.  "Threads Cannot Be Implemented As a Library",
    conference proceedings, ACM SIGPLAN 2005 Conference on Programming
    Language Design and Implementation.
    Proposed Text from Nico Williams: Character Set issues.  
    RFC 2744 refers to Latin-1.  However, the character set issues 
    within mechanisms expose themselves via GSS.  Nico proposes 
    removing references to Latin-1 in the C Bindings and adding text 
    to the generic API specifying:
      the character set used for gss_import_name(), gss_display_name(), 
      gss_display_status() and any other places where one is needed will 
      be determined by the application's/platform's locale
    Open issues:
    * Are channel bindings defined on a per-mechanism basis or are they 
    supposed to be defined in a general manner?
    Ken Raeburn will be editor for this draft.
    Decision Summary===================================================
    * remove gss_inquire_name_attribute() from 
    * draft-ietf-kitten-gssapi-naming-exts-01.txt will use OID tagged
      blobs for ACL data
    * Ken Raeburn will edit the GSS API v2 Upd 1 Clarifications draft
    Action Items=======================================================
    * Nico will publish revisions to 
    * Milestones were not revised at this meeting


    Chairs Notes including Agenda and Document Status
    GSS Naming Discussion Points - Nico Williams