Sam Hartman wrote: > > * During the course of implementing GSSAPI and GSSAPI mechanisms, > significant problems in the clarity of the base specification and C > bindings have been found. KITTEN will identify these problems and > will propose changes to the specifications to address issues of > clarity.
Strange--I'm not aware of any such problems; and I'm sure I would know if there were any real problem with it. I remember that coming up with a different language binding requires discussion (the JAVA guys realized that), however the C-Bindings itself is sufficiently clear. Could you elaborate on this? > > * The handling of channel bindings in the base specification and C > bindings has proven problematic. The structure of channel bindings > is defined more in the C bindings than in the base specification. > This has forced mechanism specifications and protocol documents to > refer to the C bindings specification. In addition, there is a > desire in several areas of the IETF for more complex channel bindings > than IP addresses and more thought to be put into how channel > bindings work. KITTEN will clarify specification of channel bindings > to meet current needs of the IETF. Channel bindings are actually non-portable anyway, many gss-api mechanisms don't implement them (even Microsoft's Kerberos doesn't) and portable applications don't use them anyway. Routing&multihoming issues, NATs and all that interfere in all sorts of ways. So far I've primarily seen clear breaches of the abstraction when IPv4 channel bindings where used with Kerberos and the Kerberos gssapi mechanism did not only verify the channel bindings at both ends with the application provided values, but also peeked inside the channel bindings and matched them up against credentials. > > * Experience with GSSAPI naming has caused implementers and > application authors to wish to look at ways of improving naming. > KITTEN will examine proposals in this area. You got it backwards. Experience with GSSAPI naming has shown that implementors of gssapi mechanisms (aka Kerberos) invented name-games in a fashion that is incompatible with GSS-API and completely breaks name-based authentication, the architectural foundation of GSS-API. > > * Experience is the Kerberos working group has caused individuals in > the Kerberos community to question the assumption behind > gss_export_name--that names can reasonably have a single canonical > form fixed for some period of time. KITTEN will consider this issue > and the general issue of GSSAPI authorization and how it relates to > naming. It is not gss_export_name() which is a problem. That is absolutely required to implement ACLs for the name-based authentication of GSS-API which can be efficiently checked/matched. The real problem is with certain extensions of the gssapi mechanisms that are incomplete (e.g. name canonicalization). The GSS-API spec describes in very details and with an ASCII arts diagram how gss_canonicalize_name() must be implemented. So in order for a Kerberos 5 gssapi mechanism to offer name canonicalization at the KDC, it must implement a name canonicalization functionality independent of a security context establishment which needs to be done everytime when gss_canonicalize_name() is used. gss_export_name() is close to zero work after that. > > [Martin, yes I know you would object very strongly to dropping > gss_export_name. I'm fairly sure there are enough of us who want to > revisit the issue that it is important to include in the charter. I > fully realize that we do not yet have any consensus for any specific > change.] Fortunately you cannot change GSS-API v2, and I will do all that I can to prevent a spec from entering the standards track that calls itself a revision of GSS-API v2 does not have gss_canonicalize_name() and gss_export_name() fully backwards compatible with current GSS-API v2. > > * The Global Grid Forum has advanced several proposals for extensions > to GSSAPI. KITTEN will consider these proposals and see if there > are mechanisms acceptable to the IETF for accomplishing the same > goals as these proposals. Haven't looked at those lately. When I looked at it a few years ago they looked like dirty hacks due to insufficient abstraction. But once you start shipping there's a strong reluctance to change. A few years ago the IESG was quite explicit that the IETF is not a rubber-stamping authority. If you want something standardized you must be prepared for changes to the (initial) proposal. I hope the IESG still lives up to its standards. > > * Mechanism implementers have complained that GSSAPI is too > complicated and thus they prefer to write SASL mechanisms rather than > GSSAPI mechanisms. KITTEN will produce a document describing how to > write a GSSAPI mechanism specification. Well, there is a SASL-scheme to use GSS-API mechanisms for performing the actual work. I don't see a problem. Most of those that say GSS-API is too complicated are all interested in a quick hack rather than a robust and scalable solution for a real-world sized Single Sign-On infrastructure. So far, GSS-API is an extremely useful abstraction. And if you're really serious about implementing a GSS-API mechanism, then reading and understanding the specs and implementing it correctly really isn't that much work. It is certainly magnitudes easier than reading, understanding and implementing Kerberos5. I'm not counting the SPNEGO spec here that some people think of as GSS-API. It's polluted with ASN.1 and even *I* would have a really hard time to implement it. But normally you don't need SPNEGO. We don't need it, none of our >20 gssapi providers has it or needs it, none of our customer needs it. The gsskrb5.dll wrapper code that I wrote and which my company provides as OpenSource should be one possible example on how to do it. Initially I wanted to implement a really *generic* gssapi mechanism in order to verify the consistency of the gssapi spec. Lacking time, I only implemented those features that our application actually used (and this does not include channel_bindings btw.), and when Microsoft started shipping SSPI with the NTLM SSP I re-used that code to build the gssntlm.dll wrapper, and later on I re-used the code once again to provide gsskrb5.dll wrapper. Internally the code is layered, and both wrappers do not only build from the same source, but also link most of the same objects. You can even build it as a multi-mechanism (I just never really tested that part). The code includes hooks to print all parameters of all gssapi calls on call entry and on call exit. It works, but so far it's a compile time feature, still lacking dynamic runtime configurability. We also provide gsstest, an extensive automated gssapi mechanism validation tool for free. So there is really not much one needs to do to create and ship a gssapi mechanism. -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to [EMAIL PROTECTED]
