From: MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 18-OCT-1992 14:27:07.16 To: info-vax@kl.sri.com CC: Subj: Re: KERBEROS as replacement for SYSUAF In article <16117@umd5.umd.edu>, bill@bill.ab.umd.edu (Bill Bame) writes: > Wow, looks like I stirred up a real hornets nest. Even though it was not > my intention to cause this much DEC-bashing/flaming, it's obvious that I hit > on a real sore spot. Good. > Every once in a while, I think it's necessary that things like this occur in order to provide a means of venting the pressure that has built up on all sides involved. It's a healthy thing, if for no other reason than that it gets all of the frustrations out into the open, and hopefully, will cause everyone involved to ponder what was said, so that the "heat of discussion can be turned into the light of reason." > > In case you are wondering why I insist on UCX, it's because I get it for "free" > under DECs CSLG agreement. Besides, I don't think it's as horrible as other > people seem to - not that I would turn down a free multinet (or WIN/TCP) > license :) > I think you are correct in insisting that UCX be supported. My argument would be that it should go farther than that, to include support for ALL the major players in the field. As an example, we're running the ANU-NEWS software here. It supports every TCP/IP implementation I am familiar with. Why can't a Kerberos implementation do the same thing? Answer: It can, but only if it is properly driven. > > In the mean time, why don't we make a wishlist of features we would like in > a network security "product"; just in case we/I actually form a working group > of some sort. > I'll better you on that one. I move that we go ahead and form a working group for purposes of implementing a Kerberos-style security system for the VAX/VMS and ALPHA/whatever systems. It's better that we take the initiative now and DO IT ourselves, so that we can drive the thing and make certain that it will be plug-compatible with other Kerberos implementations. > > I'll throw out some general wishes to start it off (remember, > this is a WISH list, not a spec). Feel free to add more specific items to the > list (even if you think they only matter at your site). > > 1) Cross-platform operability covering (at least) VMS, u*x (various), DOS, > Mac/OS, OS/2, and Windows/NT. I'm not sure how/if it would fit with Novell. > > 2) It should be fully integrated into each OS. This means it should be a > low-level replacement for $GETUAI, $SETUAI, and any other applicable system > services under VMS (and DEC should rewrite the sections of VMS that bypass > these system services). It should handle validation for Appleshare services > on Macs. Use your imagination for other OSs. > absolutely. Like any well-designed layered protocol, you should not tell that you are logging into a Kerberized machine. > > 3) It should have a complete and well designed API which is easily usable from > several common languages. > I know under the Wollongong WIN/TCP for VMS, they offer you the choice of either doing the network programming using the $QIO interface, or using the standard Berkley calls. Something that like would nicely tie into this, so that the higher-level source code is at least nominally transportable across architectural platforms. Perhaps this would best be accomplished by implementing it as a user-written system service, which would have entries for VAX/VMS "optimized" procedures, and another architecture-independent set of routines. > > 3) It should offer network protocol independence. It should be implemented at > a high enough level that any transport protocol can carry it. Technically > this is true of Kerberos, even though I am not aware of any non-TCP/IP > implementations - with a library of DECnet socket routines it should be > simple to make it work over DECnet. > I like this, but with an addition: If I didn't miss it in the Kerberos specs, a routing layer should be added between the transports and the Kerberos "network" itself, so that a client can talk to a server, regardless of how many differing protocols that packet ultimately must traverse. This might imply the notion of tunneling, and perhaps even a data presentation layer, if (for example) you chose to have all data packets encrypted, and not just the tickets themselves. > 4) It should handle multiple/redundant servers appropriately. Changes to the > security database should be propagated to all appropriate servers. > It would also have to support architectural anomalies easily. For example, the concept of a "privilege mask" does not exist in the Mac or DOS worlds. Suppose you have somebody logging into a VAX and your authentication server runs on a Mac, or an IBM Mainframe. What then? An abstraction is needed that can easily be customizable on a per-user basis, that would allow for some sort of object definition and recognition, something along the lines of the VMS "identifier" abstraction. > 5) A knowledgeable user should be able to add functionality to it without > jumping through too many hoops. > > 6) It should be in the public domain (or be the CMU-Tek variety of shareware), > but be maintained by experienced and dedicated people. dream, can't I> > It happened with ARCHIE, didn't it? It can happen with Kerberos. I agree with the public domain aspect of it, except that the copyright (or facsimile) should be governed by someone like DARPA, in order to force compliance and true inter-operability across the board. After all, look what it did to promote TCP/IP. Apart from that, the next best thing is to have an open working group that is driving the thing, and is willing to roll up their sleeves and actually start implementing the code. Maybe if we can produce a slick-enough product that actually is "the best thing since sliced bread," and offer it to all of the major TCP/IP vendors out there, for free with the proviso that they don't muck around with it in order to try and obtain some competitive advantage and end up making it incompatible, then it's worth it. I'll close with this as an idea: I remember that DEC was announcing something called "OpenVMS" as part of their ALPHA product line. Maybe DEC could be persuaded to encourage this thing, by making the source code for VMS available to us? (Hopefully, on a zero-cost basis ) I write device drivers, ACPs, system services, etc., for mental relaxation anyway. I for one am willing to write code and screw up VMS for free (:-) -- Bill Laut Internet: laut@alien.gici.com Gull Island Consultants, Inc. Phone: (616) 780-3321 Muskegon, MI 49440 >> "Usual disclaimers, apply within" << "Praise the Lord from the earth, ye dragons and all deeps." Psalm 148:7