Last Modified: 2004-11-03
| 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 |
|
IETF 61: Kitten Working Group Summary
Monday, November 8, 2004 Jeffrey Altman <jaltman@secure-endpoints.com> [chair] Presentations: http://web.mit.edu/jaltman/Public/Kitten/ietf61/ietf61-kitten.pdf The chair announced the creation of the working group by the IESG; reviewed the charter and the group's initial milestones. (please see the presentation slides for details). Since the BOF at IETF 60 there has been significant progress on: + describing the GSS Naming problem + solving the interoperability problems between protected SPNEGO and implementations which have been widely deployed + defining the requirements and interfaces for PRFs + C# bindings + producing a roadmap document Nico Williams gave a presentation on Pseudo-random function API: Many applications would like to obtain an encryption key from the GSSAPI context. Breaking the abstraction layer to obtain the negotiated key is dangerous. To solve the problem we are proposing the use of a new PRF seeded with internal keying material. Calls to GSS_Pseudo_Random() will be deterministic. When initialized with the same context and input it will produce the same output. Nico Williams gave a presentation on a Kerberos v5 GSS Mech PRF: We will construct the Krb5 PRF based on the Kerberos v5 crypto framework PRF. For new mechanisms we will always use the acceptor's subkey. For 1964 mechs the initiator subkey can be used. Key usage to be determined. Nico Williams gave a presentation on Domain based Service Names for GSS and the Krb5 Mechanism: Domain based Service names are meant mitigate against attacks caused by the use of insecure DNS SRV to obtain the host/service pair for a given domain. The generic name syntax is: <service>@<domain>@<host> an OID for GSS_C_NT_DOMAINBASED_SERVICE needs to be allocated. Since the I-Ds were published the Krb5 name form was changed to <service>/<hostname>/<domain>@<REALM> An open question is "how do we determine the realm of the domain?" We do not want the realm to be that of the host. + Must fold edits in for: ? Domain name not optional in 'query' name form ? Switch order of krb5 princ name components - Add Security considerations Both I-Ds will soon be ready for WG Last Call Chair presented Corby Morris' presentation on C# Bindings: # bindings will be very similar to the Java bindings except for some minor differences in the method declarations due to language requirements. draft-morris-java-gssapi-update-for-csharp Note: Java Security team will soon submit an update to RFC 2853 which will correct differences between the rfc and the implemented org.ietf.jgss package. Larry Zhu gave a presentation on SPNEGO: The goals for this work is to update 2478 to restore the 'P' in SPNEGO while maintaining backwards compatibility with the existing Windows SPNEGO implementation. Initial draft published: draft-zhu-spnego-2478bis-00 The basis of the backwards compatibility is provided by a set of rules called: Safe-To-Omit-MIC rules. Significant issues: + Safe-to-omit MIC rules: what are they? and when can they be used? + should we protect reqFlags? + SHOULD or MAY use optimistic token? + How is the MIC token computed? + Do we need out -of-band negotiation with down-level clients and servers? There was heavy discussion on the need for negotiation and the case for maintaining compatibility with existing implementations even though they do not implement the existing RFC. Conclusions were that negotiation is important and there is a need to provide protected negotiation while maintaining interoperability if it can be done securely. The discussion on the use of the optimistic token did not produce an opinion on the use of SHOULD vs MAY. There were strong feelings against supporting the use of mechanisms which do not provide integrity protection. No conclusion was reached on how the MIC token is to be computed. Is it over the OCTET-STREAM, with or without the OID. Sam Hartman gave a presentation on GSS Naming: The immediate goal of this document has been to describe problems that we're trying to solve to prevent scope creep. We want to support authentication of internal identities (uuids) and allow applications to work with parts of composite names. Applications should be able to query available credentials and presented names based on components and thereby find the most appropriate credential for a target. (Martin Rex points out that you can't do authentication of internal identities portably today) We think it can be portable, and Nico and I think at least we can do a lot better than we can do today. There are several levels of GSSAPI v2 compatibility we need to look at. + New mechanisms used by old applications (should they be visible? Or only do GSSAPI v2 features?) + File formats for ACLs containing names Possible Solutions include name attributes, GSSAPI credential extensions, client given ability to assert a name, a facility for enumerating the credentials that we have, choose different credential depending on the party that they're talking to. name attributes: names are composed of attributes. attributes are OID label plus ?????? client aserted names: allow clients to assert part of a name to be exported. tell implementation what part of the name that it gets. this would provide better compatibility with older applications credential extensions: add labelled extensions to credentials similar in functionality to name attirubutes, but requires more changes to contexts. credential enumeration: Basically a "GSSAPI klist" facility to find credentials that are available. Consensus was reached that we will have a document describing the solution space. Chair lead discussion on whether or not implementation of Kerberos 5 mechanism support for PRF and Domain Names should take place in kitten or krb-wg. Close of Meeting. DECISIONS (to be validated on the list): + Maintaining interoperability with existing deployed SPNEGO implementations is more important then the ability to add new features such as protect reqFlags + No consensus was reached on whether the use of an optimistic token in SPNEGO will be SHOULD or MAY. + There are strong feelings against the relaxing the MUST NOT applied to the negotiation of mechanisms which do not support integrity protection + The GSS Naming document will describe the problem space and not just solutions + The Kerberos 5 mechanism documents will working group documents of Kitten. We will work closely with the Kerberos WG to ensure proper review and we we last call in both. This decision was made by flipping a coin. ACTION ITEMS: + Larry Zhu will follow up on the outstanding issues with SPNEGO and report to the list by Fri Nov 19 + The chair will send a list of working group documents to the secretariat + Nico Williams will publish new I-Ds for PRF and Domain Names including results of recent on-list discussions + The Chair will contact Sun Java Security team to obtain a draft describing the incompatibilities between RFC and org.ietf.jgss + Sam Hartman will revise GSS Naming document and then hand it off to a new editor MILESTONES:
|