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

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-02-07


Jeffrey Altman <jaltman@columbia.edu>

Security Area Director(s):

Russell 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:

Nov 04  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-01.txt
  • draft-ietf-kitten-gssapi-domain-based-names-00.txt
  • draft-ietf-kitten-gssapi-prf-02.txt
  • draft-ietf-kitten-krb5-gssapi-domain-based-names-00.txt
  • draft-ietf-kitten-krb5-gssapi-prf-02.txt
  • draft-ietf-kitten-gssapi-rfc2853-update-for-csharp-00.txt
  • draft-ietf-kitten-rfc2853bis-00.txt
  • draft-ietf-kitten-gssapi-v3-guide-to-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

    No Request For Comments

    Current Meeting Report

    IETF62 Minutes for Kitten Working Group
    Wednesday, March 9 2005 1:00-3:00 Central Standard Time.
    Chairperson: Jeffrey Altman

    Thanks to Jeffrey Hutzelman and Nico Williams for Jabber Scribing
    Thanks to Love Hörnquist Åstrand for taking notes.

    agenda bashing:
    no comments

    Larry Zhu updates on SPNEGO:
    - sent to IESG, Last Call ends March 22.

    - implementations include Longhorn beta 1, Heimdal, and a future update to solaris 10

    - there is no open issues; please read draft

    - no questions

    - first document from kitten, beats the milestone.

    - a big thanks to Larry

    Nico Williams update on several documents:

    - PRF extentions
    * edits from last meeting folded into -01
    * PRF_READY added in -02
    * ready for last call (draft-ietf-kitten-gssapi-prf-02.txt)

    - Kerberos side of PRF, same comments
    * edits from last meeting folded into -01
    * No PRF_READY
    * don't use PROT_READY
    * can call PRF as soon as you want. if the PRF isn't ready, the function will return gss_not_avaible.
    * ready for last call (draft-ietf-kitten-krb5-gssapi-prf-02.txt)

    - GSS Domain based names
    * folded in edits from last meeting
    * Seems to be ready for last call, less review then the PRF documents. should wait if there are some comments.

    - Kerberos domain names
    * folded in edits from last meeting
    * realm derivation changed - realm is derived from the domain part of the domain-based name, not the host part
    * Seems to be ready for last call, less review then the PRF documents. should wait if there are some comments.

    - Stackable pseudeo mech and extended mech inquiry APIs
    * originally a single documetn individual submission
    now split into to two:
    * Both drafts needs review. Esp with the some issues from the document split.
    * Stackable mechs very simple concept.

    - Guide to the GSS-APIv3
    * Not many changes; just naming draft.

    - IANA registry draft
    * currently only has text about what submissions look like. no rules, no initial content.
    * talked to IANA - they would like to see a section with allocation rules, and an appendix with initial content.
    * overloading all the information into a single registry may or may not be the right way to do it; I don't know.
    * like to get some feedback on document
    * Nico will work with the chair to work out IANA details

    - Channel bindings draft from NFSv4 WG
    * for ipsec, we still need to decide what channel bindings are going to be. draft in kitten tells you. this needs some review.
    * draft not ready for last call
    * lots of discussion about where the definition of protocol specific bindings belong
    + hartmans: defining protocol specific channel bindings not in the charter for Kitten or BTNS; and Russ has objected. IPSec is not accepting new work. I think it should be done as ain individual submission.
    nico: OK, but not what we discussed before.

    - Comments for Nico:
    * channel bindings
    + Love: how can a protocol running on top of gss do channel bindings to gss?
    + Nico reply: its there in the NFSv4 draft, but could be done better.
    * IANA
    + hartmans: uneasy about having to register every gss_ symbol with iana
    + Chair: this topic needs to go to list, not enough people have read the draft
    + Matt Peterson: what was IANA's response to being asked to do api registry
    + Nico: IANA doesn't care about what being registered, then just want to be told how to do it.
    + Chair: The question is "what do we want to have done by standards actions?" One benefit of registries is having a place people can look
    + Nico: part of this discussion is to allow for vendor-specific extensions

    Sam Hartman updates GSS Naming:
    - draft-ietf-kitten-gss-naming-01.txt
    - the goal is to be a direction statement to describe the problems we're trying to solve, and approaches we're considering
    - received a lot of comments from nico
    - hoping to get comments from Martin Rex, but so far he has never actually responded directly to this draft
    - I think -02 will be ready for last call. There is one issue I'd like to get some discussion on today.
    * currrently today, names are atoms - indivisible strings with no structure
    * one proposal is to turn them into sets and/or sequences
    + <missed discussion>
    + nico & I think we'll probably need to do that anyway
    * another proposal... allow us to choose the initiator name based on what target we're talking to. can't currently do that. there is some desire in kerberos to be able to do that
    * another issue that came up, which we have no closure on yet...
    + mechanisms that can assert multiple identities
    + example - X.509 mech, you may have multiple subjectAltName you may want to say which of these names you want to claim for a given context for pure (GSSAPI) v3 mechanisms being used by V3 apps (understand composite names), you probably don't need it do we want something like this for v2 applications
    + I believe if we can solve that issue, we can last call -02
    + nico: how to do that is easy. whether we want to do that is another story I believe spkm had a thing where you could assert a Name in its tokens from a v3 POV, that's irrelevant
    + unless someone comes forward and says they want to do that,we're not going to. If you care, you need to speak up by end of WGLC.
    + nico: your draft is informational...
    + at this time, it doesn't make sense for me to be editor of a document...maybe if my day job had less management work...do we want to poll the room, see people interested in being doc editors? Nico would do a good job, but have lots of docs on your plate
    + jaltman: I as chair would be more comfortable with load spread out.
    + matt peterson volunteering someone from his organization
    + jaltman: no other volunteers

    Update java and C# bindings
    - neither of the authors were able to come to this ietf
    - two new documents:
    * draft-ietf-kitten-gssapi-rfc2853-update-for-csharp-00.txt
    * draft-ietf-kitten-rfc2853bis-00.txt
    - c# - submitted from novell, new editor
    * describes how to morph 2853 java bindings for c#
    * very little discussion of this doc. novell is in the process of implementing; if others are interested, we'd love to hear your opinions
    - second doc (RFC2853bis) describes what things in RFC2853 were implemented differently in the Java Class Libraries from what's in the spec.
    - the document is in good shape.
    - next step is to merge the two drafts.
    - nico: do you have an editor for that?
    - yes; one from Sun (Seema Malkani), one from Novell (Juan Carlos Luciani)
    - hartmans: a little concerned about style/format of these docs I don't think IETF spec by diff works
    - the next step is to merge these and rfc2853 into a new doc that would obsolete the old one

    Open mike:
    [Editor's note - This discussion did not belong in Kitten]
    [The contents of this section are stolen from the Jabber logs]

    joe salowey:

    the topics that have been coming up lately. ISM WG, enhancements to EAP, EAP has been held to be not applicable we're looking to see if the GSS-API is applicable this is a heads up about interest in this also I'm looking at a number of IETF auth frameworks (SASL, GSS, EAP...), at some point we should look at merging these things some of the GSS v3 enhancements could help (PRF, Naming, ...)

    sam hartman:
    so we seem to have some time left joe brought up some interesting points this is very much half-baked, joe's the primary instigator we have a miserable situation in the IETF w/ sec mechs (long list of technologies) and one-off mechs too you know, hash stuff and SSH! and so there's a kind of matrix: if I pick this protocol, what auth techs can I use some are very limited (HTTP has ...) blah, blah and really, the way I want the matrix to look is: regardless of what protocol I pick I can use any mech I want because if I do that I only have to get security right once in my organization so, to get folks thinking about this all these mechs do roughly the same thing you're stopped by small problems of standardization and programming we can do the standardization here so I'm going to compare everything to GSS cause we're here now EAP is like GSS but the server send first token no wrap/unwrap the mechs folks use today have a "key fallout" two keys, actually EAP has a better developed sense of .... naming/channel binding their concept of channel binding may map onto our concept of naming their client ID is weaker than our names but more useful there are stackable pseudo-mechs for EAP and when you do that you need channel bindings between layers they call that cryptographic binding they have a description language for the sec properties of their mechs SASL is like GSS but lacks the PRF, its concept of naming is not as well developed, except when doing GSS it has this funky thing called an authorization ID SASL supports either the client or server as initiators of the exchange this depends on the protocol and the mechanism I think this is even as bad as implementation dependent GSS is a lot like GSS
    For EAP the negotiation model is that the server decides what mech to use for SASL the client generally picks from a list offered by the server w/o downgrade attack ("bidding down") you can abort in the middle of auth for GSS we have SPENGO SPNEGO if you don't know how it works, now's the time to find out! SSH I like the client and server shout at each other offers the client picks one and the server rejects or the key exchange fails the client loses the key exchange ends in two things: a key and an exchange hash and ssh authenticates the server to the client this protocol doesn't have a good concept of naming pubkeys are not named then there's the ssh user authentication protocol this has something like the SASL authz IDthe client tries one mech then the server tells whether we can do this or are done or how to continue the client needs to know what it's tried so it doesn't try again

    Jeffrey Hutzelman:
    this is all implementation dependent the client has to keep trying until it can't go on or succeeds

    TLS supports pubkey certs, PSK and it supports Kerberos, sortof (details) are there any other actual authentication frameworks in IETF...? MIKEY has some authentication goop

    Uri Blumenthal:
    MIKEY is good, but it's multicast specific it's auth deals in multicast key distribution -- Kerberos, EAP, etc...wouldn't be aplicable

    [details lost]

    consider using certs to get access to the multicast stream and consider that MMUSIC uses MIKEY to configure unicast streams if I was an admin I'd be annoyed if MIKEY didn't support the mechanism I wanted

    [details lost]

    I want to be able to use any mechanism in any app

    Jeffrey Hutzelman:
    so you want developers to be able to pick the most applicable framework for their protocol, but be able to use any mech


    so mech gateways

    that's one way I want a solution, but I'm not particularly interested in any one of them

    I'd rather see these mechs (new mechs) developed together for all frameworks rather than rely on 'gateways'

    long term I'd like to live in a world where ppl know about gateways and new mechs will work through them all but basically I agree with you that if the gateways are not easily workable, then it might not fly so my assumption is that we can get the gateways to get to the point where they'll meet most folks' needs and then look at mechs-all-at-once

    it would be more efficient to design the mechs with these different frameworks in mind

    I don't necessarily want to know what mechs I'll be using, I need to know what capabilities I need and what caps each mech offers nico's draft may be a start point it goes a bit deeper than that we need to be able to plug-in mechs the framework implementations have to be pluggable I'm wondering if the WG can do anything about this and refining the semantics of the default mech (GSS_C_NULL_OID)

    Sam and Mark argue about sysadmin vs. app policy

    I think this is moving into a different topic I'm happy to do that, but...

    Joe, any more questions?

    I'd like to explore the idea of developing mechs in parallel.

    want to be able to reuse as much of the mech spec and implementation as possible don't want to have case statements in spec

    it would be good if mechs would just perform a few extra tasks export identities, exact crypto protections it uses, key material this is why people are looking at eap

    we think we have the generic keying material in the GSS PRF
    we'd like your review

    already sent some comments

    quick response to uri
    for some mechs, we won't know in advance what it uses.
    e.g. kerberos
    for others, we know up front what it will use current gssapi qop concept is badly broken

    in some protocols, access control is based on identity, accessed object, and under what sort of protection

    wow, this is an interesting meeting!

    what I was hearing is there's a desire to define a base set of operations on which things can be built is that right? if so, where? not in kitten's charter

    Bob Morgan:
    another distinguishing factor is integration model one of sasl's successes is it makes it clear how to integrate into app proto gssapi - not sure what integration model is

    gss is clearly a lot of rope
    all of these frameworks meet different app domains it's interesting that the mechs are very similar, even though the frameworks are very different

    Bob Morgan:
    maybe different frameworks come from different needed integration models

    if you want an easy integration model, use sasl
    if you understand your needs really well and have complex requirements, use gss

    matt, the default mech/mech set don't have to be global config file as in Solaris
    the right default is "whatever mechs you have credentials for"
    the right default mech is "the first one for which you have credentials"

    Matt Peterson:
    what if you have creds for more than one mech

    either it's nondeterministic or its the first one I know you want this to be app-specific config, but I don't feel not sympathetic - you can make app provide the right oid

    Matt: ...

    what I hear you saying is you want pluggable mechanisms we can't tell people to do that. there are monolithic and pluggable multi-mech implementations, and ther eare single-mech implementations

    do you have specific platforms in mind?

    for example, aix or some mobile thing, where I want to port my app

    you're always going to have something older that doesn't have the functionality

    Milestones (Chair):
    - we're not making the milestone on GSS-API _v2_ clarifications
    * hartmans: as an individual, it's not clear we want to do v2 clarifications
    * is it worth reviewing and clarifying GSS-APIv2 update 1
    * wyllys: It seems like an extra step and maybe not necessary.
    * jhutz: are you asking if GSS-APIv2 update 2 is worth doing?
    * no, the clarifications would be for inclusion into the v3 document
    * wyllys: oh, thats a little different.
    * all the various little issues that we talked about on the list
    * we need someone to volunteer to go through the CAT and KRB mailing lists and collect all of the details from the discussions which lead to the formation of this working group
    * Matt Peterson will assign one of Vintela's people to go over the archive and compile the complaints.
    * Update this milestone to May 2005.
    - No need to revise the other milestones since we are making
    good progress.



    SPNEGO bis
    Nico's KITTEN I-Ds Updates
    Updates to Java and C# Bindings