Date: Tue, 19 May 1992 19:52:48 GMT From: gp15@cunixf.cc.columbia.edu (Gerald Pulver) Reply-To: Gerald Pulver <gp15@columbia.edu> To: kerberos@shelby.Stanford.EDU Have you had any experience (or heard any rumors) of kerberos being used on novell networks? I'd like to know what has already been done. (pointers: both direct & indirect, would be appreciated.) Thanks.
Date: 27 May 92 00:15:40 GMT From: keith@novell.com (Keith Brown) To: kerberos@shelby.Stanford.EDU In article < 1992May19.195248.19623@cunixf.cc.columbia.edu> Gerald Pulver <gp15@columbia.edu> writes: >Have you had any experience (or heard any rumors) of kerberos being used >on novell networks? I'd like to know what has already been done. (pointers: >both direct & indirect, would be appreciated.) Thanks. NetWare has been walking down the RSA trail in terms of authentication services. Use of Kerberos has not been entirely eliminated but RSA looks far more commercially viable today. Distribution and implementation of RSA technology is carefully controlled and limited (it must be licensed from the one source). As a consequence, there is a defacto standard RSA and implementations can be trusted. Kerberos suffers from the fact that its source is widely available and abusable by any Joe on the internet whose figured out how to use FTP. Being such a Joe, I could FTP it over from MIT now, change a few lines of code, insert a back door or two and unleash my kludgery upon an unsuspecting planet. Is this what you would wish your bank to be using? Keith - Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 2180 Fortune Dr, San Jose, California 95131 Net: keith@novell.COM
Date: Wed, 27 May 92 11:15:59 -0400 From: tytso@Athena.MIT.EDU (Theodore Ts'o) To: kerberos@Athena.MIT.EDU In-Reply-To: Keith Brown's message of 27 May 92 00:15:40 GMT, Date: 27 May 92 00:15:40 GMT From: keith@novell.com (Keith Brown) NetWare has been walking down the RSA trail in terms of authentication services. Use of Kerberos has not been entirely eliminated but RSA looks far more commercially viable today. Distribution and implementation of RSA technology is carefully controlled and limited (it must be licensed from the one source). As a consequence, there is a defacto standard RSA and implementations can be trusted. Kerberos suffers from the fact that its source is widely available and abusable by any Joe on the internet whose figured out how to use FTP. Being such a Joe, I could FTP it over from MIT now, change a few lines of code, insert a back door or two and unleash my kludgery upon an unsuspecting planet. Is this what you would wish your bank to be using? How so? Any random Joe on the internet can grab Kerberos, but it certainly isn't the case that they would be able to unleash it on an unsuspecting planet. How would they do that? If someone wants Kerberos, they can get it from MIT, or some other trusted party --- for example, there are a number of places that will sell you a Kerberos tape and support to go with it. They're not going to get it from your random Joe on the internet. The issue you raise is a complete red herring! When Novell (or any other computer vendor) puts together a system using RSA, or Kerberos, that vendor will always be able to install back doors into the system, and "unleash it unto an unsuspecting planet". Whether or not source is widely available is irrelevent. Furthermore, RSA is just an encryption algorithm. Kerberos is a complete authentication package (which uses DES) and which has stood the test of time. If you just get RSA from RSA DSI, it is up to you to take that encryption and turn it into a viable authentication scheme. That scheme may not be compatible with the rest of the world; true, there are standards for the format of certificates and encrypted objects, but there's more to an authentication system than that --- for example, what sort of packet format and what sort of exchange sequence do you use? So Novell is going to have to put together an authentication system using RSA, and then the rest of the world (who won't be given access to the source code), will have to hope that (1) Novell designed it correctly, and (2) the green implementation which they did doesn't have any bugs. If I were a bank security officer, I would much rather have a system where (1) the system has stood the test of time and (2) the sources are available so that an independent third party could audit them. I fail to see how having freely available source code could ever be a disadvantage. Security through obscurity is no security whatsoever --- and I'm speaking as someone who has disassembled quite a few of programs in my time, including the Internet worm/virus, and a couple of copy protection schemes. :-) - Ted
From: smb@ulysses.att.com To: keith@novell.com (Keith Brown) Cc: tytso@Athena.MIT.EDU (Theodore Ts'o), kerberos@Athena.MIT.EDU Date: Wed, 27 May 92 11:40:47 EDT Ted is absolutely correct in his comments. At the risk of immodesty, let me quote what Michael Merritt and I wrote in our critique of Kerberos (Usenix, Jan '91, also available as dist/kerblimit.usenix.ps on research.att.com): Is Kerberos correct? By that we are asking if there are bugs (or trapdoors!) in the design or implementation of Kerberos, bugs that could be used to penetrate a system that relies on Kerberos. Some would say that by making the code widely available, the implementors have enabled would-be penetrators to gain a detailed knowledge of the system, thereby simplifying their task considerably. We reject that notion. ..... Kerberos is designed primarily as an authentication system incorporating a traditional cryptosystem (the Data Encryption Standard) as a component. Never the less, the philosophy guiding Kerckhoffs' evaluation criterion applies to the evaluation of the security of Kerberos. The details of Kerberos's design and implementation must be assumed known to a prospective attacker, who may also be in league with some subset of servers, clients, and (in the case of hierarchically-configured realms) some authentication servers. Kerberos is secure if and only if it can protect other clients and servers, beginning only with the premise that these client and server keys are secret, and that the encryption system is secure. Moreover, in the absence of a central, trusted ``validation authority'', each prospective user of Kerberos is responsible for judging its security. Of course, a public discussion of system security and publication of security evaluations will facilitate such judgements. By describing the Kerberos design in publications and making the source code publically available, the Kerberos designers and implementors at Project Athena have made a commendable effort to encourage just such a public system validation. Obviously, this document is itself part of that process. However, the system design and its implementation have undergone significant modification, in part as a consequence of this public discussion. We stress that each modification to the design and implementation results in a new system whose security properties must be considered anew. (Examples of such modifications are the incorporation of hierarchically-organized servers and forwardable tickets in Version 5.) Kerberos has been exposed to several years of public scrutiny. The Novell scheme has not. Even though its basis (public key cryptography) gives it a considerable edge, there are still innumerable ways to commit subtle errors in the implementation. Of course, I have no reason to think there are such security holes -- but I also have no reason to think that there aren't. --Steve Bellovin