There are several approaches to skinning a cat, but what some people are trying to do with GSS-API is the most awkard approach I could imagine.
The only correct solution to the problems with Kerberos name-games and it's incompatibility is to provide a directory service. Everyone that has trying to do large scale Kerberos infrastructures combined with non-trivial (Posix-style) access control (lists) knows that pretty well. DCE has a Directory service, even Microsoft has it (although their architecture is a real mess since there are plenty of serious bugs and there is no small and clean API to deal with access control, names, transformation between names and management of ACLs.) Adding name-canonicalization to Kerberos without adding a Directory to provide the necessary transformation to ACL maintenance will significantly impair the usefulness of vanilla Kerberos 5, because this pig will no longer fly with distributed gssapi-based applications when any such features are used. -Martin Ken Hornstein wrote: > > My only comment is that I find it ironic that these two paragraphs > appear in the same message: > > >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. Why? rfc-2743/rfc-2744 is not going to change, what's so ironic about that. That means that one cannot pull the rug from under gssapi v2 compliant apps and gssapi mechanisms. And I have plenty of running code to proof that what is in gssapi v2 is useful as it is. So even if someone comes up with a gssapi v3 that is backward incompatible with gssapi v2, then this will definitely *NOT* obsolete gssapi v2. Just as IPv6 does not obsolete IPv4 for quite some time to come. > > [...] > > >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. This was about the gssapi extensions proposals from GRID. Their best bet is to just submit their current specs as informational, saving everyone time and headaches. -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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]
