Date: 5 Oct 90 00:54:04 GMT From: eay@surf.sics.bu.oz (Eric the Young) Reply-To: eay@surf.sics.bu.oz (Eric the Young) To: kerberos@shelby.Stanford.EDU With eager anticipation I installed Ultrix 4.0 with the expectation that a complete version of kerberos would be included, boy was I wrong. (For those that don't know, DEC claimed that kerberos with full encryption (in binary form only) was being sent will all versions with ultrix 4, including sites outside of the USA) What do I find, NO DES ENCRYPTION ROUTINES IN THE DES LIBRARY !!! a simple ar t of /usr/lib/libdes.a __________ELEL_ key_sched.o debug_decl.o quad_cksum.o random_key.o read_password.o string_to_key.o weak_key.o key_parity.o new_rnd_key.o util.o (and a strings - -9 of the library reveals no des_*_encrypt routines). To top it off the des_*_encrypt sections of the man page has been commented out of /usr/man/man/des_encrypt.3krb. The only interesting things is that there are files with names like pcbc_inline.c and des_inline.c compiled into files like /usr/etc/kerberos. So, des is in the kerberos application binaries, but since there is no des in the libraries and there are no user level kerberos application i.e. kerberised rlogin and rcp, this (IMHO) is a total waste of time and appears to be a bit of missinformation of DECs behalf. I will concede that Ultrix is only calmed to have binary versions of des encryption in the export version, but I take this to mean no source code, not no object files. Have other non US sites found this with their ultrix 4.0 installations or am I making a fool of my self :-). I feels a bit cheated :-( (I should also not that the kerberos library looks as thought it has been fiddled with as well :-( Non of the above is a reflection of the opinion or of the policies of Bond University, it is just the grumbling of an annoyed system programmer (me). -- Eric Young | "It is always best to start running System Programmer, SICS Bond Uni.| away early, before the rush. That way ACSnet: eay@surf.sics.bu.oz.au | there are fewer bodies to trip over."
Date: Fri, 5 Oct 90 10:59:20 EDT From: Jerome H Saltzer <Saltzer@mit.edu> To: eay@surf.sics.bu.oz Cc: kerberos@ATHENA.MIT.EDU In-Reply-To: Eric the Young's message of 5 Oct 90 00:54:04 GMT <1322@surf.sics.bu.oz> > (For those that don't know, DEC claimed that kerberos with full encryption > (in binary form only) was being sent will all versions with ultrix 4, > including sites outside of the USA) > > What do I find, NO DES ENCRYPTION ROUTINES IN THE DES LIBRARY !!! Eric, What you found in the Ultrix distribution is precisely what one would expect to find if Digital had pushed everything to the limit currently permitted by U.S. export controls. (The current interpretation permits encryption routines to be included in an authentication system but only if they embedded in such a way that they not easily accessible for general purpose use.) So the complaint you have is not with the distribution itself--the people who put it together did everything the law allowed. If there is a complaint, it is with whatever Digital may have said would be in the distribution. I haven't seen that description, but it would be interesting, in light of your observation, to go back and review that description carefully. Since the word "binary" is used both to mean "inside a loaded image" and "in the form of a *.o file" there is certainly the possibility of simple misinterpretation--especially after the message has passed through a couple of intermediaries who aren't fully aware that there is a difference. Another possible source of misinterpretation is that a lot of possible distribution methods have been discussed: with no encryption at all, with DES replace with a light-weight encryption system, with hooks for your own encryption, and with real DES. Is it possible that the message Digital was trying to deliver was that they had chosen the last possibility rather than one of the others? Jerry Saltzer
Date: 8 Oct 90 00:58:25 GMT From: eay@surf.bu.oz.au (Eric the Young) Reply-To: eay@surf.bu.oz.au (Eric the Young) To: kerberos@shelby.Stanford.EDU In article <1322@surf.sics.bu.oz>, eay@surf.sics.bu.oz (Eric the Young (me)) wri tes: >(For those that don't know, DEC claimed that kerberos with full encryption >(in binary form only) was being sent will all versions with ultrix 4, This statement (as was most of the article) was harsh on Digital and I should not have written it. I apologize for any discredit I may have brought on Digital's name. I fully appreciate the efforts Digital have made in trying to export a complete working version of kerberos (with des) and that the restrictions are due to U.S. export controls. (And it is those export controls that I am frustrated with not Digital). My reason for posting was caused by my misunderstanding of the definitions of object code. I am a system programmer and my interest in kerberos is writing applications that can use kerberos authentication. I have been using Bones (kerberos without the libdes.a routines) and when I hear the word kerberos I think of authenticated logins etc. Kerberos is an authentication system, so the use of the kerberos in user applications is (IMHO) a major part of kerberos. When I found that the kerberos package in the export version of Ultrix could not be used to develop new applications _I_ felt that an integral part of the kerberos package was missing. The kerberos (or Bones) package as distributed by MIT provides the kerberos server, development libraries and some application programs. >From what I have seen so far, the export Ultrix version provides the server, development libraries (minus des encryption) and some applications (I am not sure which ones, but not rlogin). Since kerberos is an authentication system, I fell that leaving out some parts of the library (so that is is not usable), does not conform with my personal image of what kerberos is. It appears that all I have to do is write my own versions of des (which I have done), but how can I be sure it will be compatible with the (non export) Ultrix version. The way kerberos operates would make it possible for me, in Australia to login to MIT (when I am IP connected) with kerberos authentication, but only if my des routines were exactly the same as MIT's. I find it so annoying that when there are several different versions of libdes.a available outside the US, that the US is IP connected to the rest of the world (Oh, look what we have here, the kerberos distribution, lets just ftp it back to Australia/Finland/Eastern Europe, or lets just have some-one email it to me). I have modified Bones so that it now uses encryption but I will never be able to say the libraries are a replacement for MIT's until I can test them against a working USA version. It was my hope that the Ultrix version would let me test my routines and then be able to say my version would let people with kerberos on ultrix machines authenticate with people with my version of kerberos. eric None of the above is a reflection of the opinion or of the policies of Bond University, it is just the grumbling of an annoyed system programmer (me) -- Eric Young System Programmer, SICS Bond Uni. ACSnet: eay@surf.sics.bu.oz.au
To: eay@surf.sics.bu.oz.au (Eric the Young) Cc: kerberos@ATHENA.MIT.EDU, bbrown@decvax.dec.com In-Reply-To: Your message of 05 Oct 90 00:54:04 +0000. Date: Mon, 08 Oct 90 15:33:09 EDT From: bbrown@abyss.zk3.dec.com In article <1322@surf.sics.bu.oz>, eay@surf.sics.bu.oz (Eric the Young (me)) wri tes: >(For those that don't know, DEC claimed that kerberos with full encryption >(in binary form only) was being sent will all versions with ultrix 4, Hi, I am the engineer who, as you put it, fiddled with the kerberos libraries. In the future you should first get all of your facts straight before loudly and publicly complaining about the product. After you understand what you have you may not be as upset. In order to ship the kerberos libraries overseas, any ability that the MIT kerberos libraries had to serve as a general purpose encryption facility was stripped. A general purpose encryption facility is anything which allows the user to encrypt text of his/her choosing and decrypt the same. This means, for example, that the krb_mk_priv and krb_rd_priv routines were not included in the Ultrix version of libkrb.d. This does not mean that the libraries do not perform DES encryption and decryption. They do DES encrypt and decrypt data, but, only data which is choosen by the libraries in order to allow for the authentication of a principle A to a principle B. So, an application built with the ULTRIX kerberos libraries supports the same on the wire protocol as an application built with the U.S. distribution of the MIT Athena Kerberos V4 libraries. This is the most functionality from the kerberos libraries you could possibly hope for from any vendor shipping product from the U.S given the current export laws. DEC is the first and only vendor who supplies it. Yes, kerberos was not integrated into login and the "r*" commands in ULTRIX 4.0. If you need this sort of functionality immediately you can build it using the tools you already have, an ULTRIX source license, the ULTRIX 4.0 libraries, and the International distribution of MIT Athena Kerberos 4.0 source code. Add the MIT Kerberos changes to the "r*" commands to the ULTRIX source making sure that any use made of the libraries would not allow the user of the "r*" tools to use the libraries to encrypt or decrypt data of his/her choosing. This implies that, for example, the MIT's rlogin program must be stripped of its abililty to provide an encrypted session. Compile the new code with the ULTRIX libraries. If any routines or options are missing from the libraries then you have not completely stripped the "r*" commands of their ability to encrypt generic data. Once you get the package to work correctly you will have a set of binaries that could be run at MIT and would successfully interoperate with the rest of the Athena environment. Bill Brown p.s. Just so you don't feel discriminated against, you should know that there is no U.S. specific distribution of ULTRIX kerberos. Nobody gets the source code, nobody gets to use the libraries as a general encryption service. Since we have no internal method to ship a different kit to the U.S., we opted to eliminate the possibility of sending the fully functioning libraries to the U.S. in order to provide authentication abilities to our overseas customers. Your business is very important to DEC.