home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / protocol / kerberos / 964 < prev    next >
Encoding:
Text File  |  1992-12-15  |  24.5 KB  |  560 lines

  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!stanford.edu!ATHENA.MIT.EDU!bjaspan
  3. From: bjaspan@ATHENA.MIT.EDU (Barry Jaspan)
  4. Subject: Kerberos Users' Frequently Asked Questions 1.2
  5. Message-ID: <kerberos-faq.user_724468225@athena.mit.edu>
  6. Sender: owner-comp-protocols-kerberos@shelby.Stanford.EDU
  7. Organization: Aktis, Inc.
  8. Date: Wed, 16 Dec 1992 01:10:35 GMT
  9. Lines: 549
  10.  
  11. Archive-name: kerberos-faq/user
  12. Version: 1.2
  13.  
  14. Kerberos Users' Frequently Asked Questions
  15. December 15, 1992
  16. Compiled by: Barry Jaspan, <bjaspan@athena.mit.edu>
  17.              Aktis, Inc.
  18.  
  19.      Kerberos; also spelled Cerberus.  "n.  The watch dog of
  20.      Hades, whose duty it was to guard the entrance--against
  21.      whom or what does not clearly appear; .  . . is known to
  22.      have had three heads. . ."
  23.  
  24.         -Ambrose Bierce, The Enlarged Devil's Dictionary
  25.  
  26. This document answers Frequently Asked Questions about the Kerberos
  27. authentication system.  It is freely distributable.  Direct all
  28. responses and questions to bjaspan@athena.mit.edu.  Most of the
  29. information presented here has been collected from postings to the
  30. comp.protocols.kerberos newsgroup (gatewayed to the mailing list
  31. kerberos@athena.mit.edu) and in general credit has not been given;
  32. complain if you feel offended.
  33.  
  34. DISCLAIMER: Aktis, Inc., makes no representations about the
  35. suitability of this information for any purpose.  It is provided "as
  36. is" without express or implied warranty.  In particular, this document
  37. is not intended as legal advice for exporting Kerberos, DES, or any
  38. other encryption software.
  39.  
  40. Please make suggestions and contribute any information that you can.
  41.  
  42. Questions addressed in this release:
  43.     (a * indicates that no answer is currently available)
  44.  
  45. 1.  Kerberos and its Many Incarnations
  46. ----------------------------------------------------------------------
  47.  
  48. (1.1)    What is Kerberos?  What is it good for?
  49. (1.2)    Where can I get Kerberos version 4 or 5?
  50. (1.3)    What is the current status of version 4?
  51. (1.4)    What is the current status of version 5?
  52. (1.5)    Are version 4 and version 5 compatible?
  53. (1.6)    How/why is Transarc's Kerberos different from MIT Kerberos V4?
  54.     Can they interoperate?
  55. (1.7)*    How/why is OSF DCE Kerberos different from MIT Kerberos V5?
  56.     Can they interoperate?
  57. (1.8)    How/why is DEC Ultrix Kerberos different from MIT Kerberos V4?
  58.     Can they interoperate?
  59. (1.9)    What is Bones?  What is it for?
  60.  
  61. 2.  Using and Administering Kerberos
  62. ----------------------------------------------------------------------
  63.  
  64. (2.1)    Can I use Kerberos for local password validation?
  65. (2.2)    What is the export status of Kerberos?
  66. (2.3)    How can I delete a principal from the database?
  67. (2.4)    What are the officially assigned Kerberos port numbers?
  68. (2.5)    Are there Kerberos versions of telnet and ftpd?
  69.     What other Kerberos clients exist?
  70. (2.6)    Why does rlogin print "Warning: No Kerberos tickets obtained"?
  71. (2.7)    What operating systems has Kerberos been ported to?
  72.     What vendors provide commercial support for Kerberos?
  73.  
  74. 3.  Building and Installing Kerberos
  75. ----------------------------------------------------------------------
  76.  
  77. (3.1)    Why do I get an error message from ld when make_commands is
  78.     executed?
  79. (3.2)    Why doesn't KRB5_defs.h exist when I build version 5?
  80.  
  81. 4.  Miscellaneous
  82. ----------------------------------------------------------------------
  83.  
  84. (4.1)    List references for Kerberos and network security in general.
  85. (4.2)    Where are archives of comp.protocols.kerberos (a.k.a 
  86.     kerberos@athena.mit.edu)?
  87.  
  88. ======================================================================
  89.  
  90. 1.  Kerberos and its Many Incarnations
  91. ----------------------------------------------------------------------
  92.  
  93. (1.1)    What is Kerberos?  What is it good for?
  94.  
  95. The following is an excerpt from [1]:
  96.  
  97.    Kerberos is a trusted third-party authentication service based on
  98.    the model presented by Needham and Schroeder.[3] It is trusted in
  99.    the sense that each of its clients believes Kerberos' judgement as
  100.    to the identity of each of its other clients to be accurate.
  101.  
  102. [This really isn't a very good description.]
  103.  
  104. It is important to realize that Kerberos is a one-trick pony.  It
  105. provides for mutual authentication between principals on an open
  106. network.  It does not provide a mechanism for authorization; that is
  107. left to the application.  It also does not provide password validation
  108. for individual workstations unless care is taken; see question 2.1.
  109.  
  110. (1.2)    Where can I get Kerberos version 4 or 5?
  111.  
  112. In the United States and Canada (*), Kerberos is available via
  113. anonymous FTP from athena-dist.mit.edu (18.71.0.38).  For specific
  114. instructions, cd to pub/kerberos and get the file README.KRB4 (for
  115. version 4) or README.KRB5_BETA2 (for version 5).  Note that *YOU WILL
  116. NOT BE ABLE TO RETRIEVE KERBEROS WITHOUT READING THIS FILE*.
  117.  
  118. Outside the United States, you can get Bones via anonymous ftp from
  119. ftp.funet.fi (128.214.6.100) in pub/unix/security/kerberos.  A DES
  120. library is available from the same place.  See question 1.9 for
  121. information on Bones.
  122.  
  123. (*) Kerberos and DES can be exported to Canada.  See question 2.2.
  124.  
  125. (1.3)    What is the current status of version 4?
  126.  
  127. With the release of patch level 10 on December 10, 1992, MIT Kerberos
  128. 4 is now in its final form.  MIT does not anticipate ever making a new
  129. Kerberos 4 release.
  130.  
  131. Several vendors provide their own versions of Kerberos which may
  132. contain improvements or extensions; see question 2.7.
  133.  
  134. (1.4)    What is the current status of version 5?
  135.  
  136. A new beta release of MIT Kerberos V5 is available as of September 30,
  137. 1992; see question 1.2.  This release brings MIT's implementation into
  138. full compliance with the current protocol.  It is not backwards
  139. compatible with the previous beta release; according to MIT, this is
  140. the last release that will contain non-backwards compatible changes.
  141.  
  142. (1.5)    Are version 4 and version 5 compatible?
  143.  
  144. No.  Versions 4 and 5 are based on completely different protocols.
  145. The MIT Kerberos V5 distribution contains some compatibility code,
  146. however: (a) there is a library which converts Kerberos V4 library
  147. calls into Kerberos V5 requests, so you can run many V4 programs in a
  148. V5 environment by relinking; (b) the Kerberos server can optionally
  149. service V4 requests; (c) there is a program to convert a V4 format
  150. Kerberos database to a V5 format database.  The names used by the V5
  151. library have a prefix "krb5_" so they do not conflict with the V4
  152. library.
  153.  
  154. (1.6)    How/why is Transarc's Kerberos different from MIT Kerberos V4?
  155.     Can they interoperate?
  156.  
  157. This is a fairly complex question, and my answer is almost guaranteed
  158. to be incomplete.  The issue is regularly discussed on the
  159. info-afs-kerberos@transarc.com mailing list; send mail to the -request
  160. list for subscriptions.
  161.  
  162. Years ago, the designers of AFS decided to implement their own
  163. security system based on the Kerberos specification instead of using
  164. the (then, not yet publicly available) MIT Kerberos V4.  As a result,
  165. Transarc's AFS Kerberos speaks a different protocol but also
  166. understands the MIT Kerberos V4 protocol.  They can, in principal,
  167. talk to each other; however, there are a sufficient number of annoying
  168. details and an insufficient number of advantages such that it may not
  169. be practical.
  170.  
  171. The two versions use a different string-to-key function (the algorithm
  172. that turns a password into a DES key); the AFS version uses the realm
  173. name as part of the computation while the MIT version does not.  A
  174. program that uses a password to acquire a ticket (e.g.  kinit or
  175. login) will only work with one version.
  176.  
  177. The two versions also use a different method of finding Kerberos
  178. servers.  MIT Kerberos uses /etc/krb.conf and /etc/krb.realms to map
  179. hostnames to realms and realms to Kerberos servers.  AFS kaservers for
  180. a realm, by definition, are located on the AFS database servers and
  181. can therefore be located using /usr/vice/etc/CellServDB.  This means
  182. that a program built using the MIT Kerberos libraries will look in one
  183. place for the information while a program built using the AFS Kerberos
  184. libraries will look in another.  You can certainly set up all three
  185. files and use both libraries, but be sure that everything is
  186. consistent.
  187.  
  188. The two versions have a different password changing protocol, so you
  189. must use the correct 'kpasswd' program for the server you are talking
  190. to.  In general, AFS clients that talk directly to the kaserver use an
  191. Rx-based protocol, instead of UDP as with MIT Kerberos, so those AFS
  192. clients cannot talk to an MIT server.
  193.  
  194. In summary, AFS Kerberos and MIT Kerberos can interoperate once you've
  195. acquired a ticket granting ticket, which you can do with kinit (MIT)
  196. or klog (AFS, use the version that writes a ticket file).  With a tgt,
  197. Kerberos applications such as rlogin can talk to an MIT or AFS
  198. Kerberos server and achieve correct results.  However, it is probably
  199. best to pick one implementation and use it exclusively
  200.  
  201. (1.7)*    How/why is OSF DCE Kerberos different from MIT Kerberos V5?
  202.     Can they interoperate?
  203.  
  204. (1.8)    How/why is DEC Ultrix Kerberos different from MIT Kerberos V4?
  205.     Can they interoperate?
  206.  
  207. DEC ULTRIX contains Kerberos for a single reason, namely, to provide
  208. authenticated name service for the ULTRIX enhanced security option.
  209. It does not support user-level authentication in the normal manner.
  210.  
  211. DEC's version is essentially the same as (and derived from) MIT
  212. Kerberos V4 with a few changes.  The most significant change is that
  213. the ability to perform any kind of end-to-end user data encryption has
  214. been eliminated in order to comply with export restrictions.  Minor
  215. changes include the placement of ticket files (/var/dss/kerberos/tkt
  216. vs. /tmp) and the principal names used by some standard Kerberos
  217. services (e.g.: kprop vs. rcmd); there are probably other minor
  218. changes as well.
  219.  
  220. These changes make it annoying but not impossible to use DEC ULTRIX
  221. Kerberos in the normal way.  However, there is no reason at all to do
  222. so, because the MIT distribution supports ULTRIX directly.  [This may
  223. not be completely true.  I imagine that using ULTRIX Kerberos for
  224. enhanced security and MIT's Kerberos at the same time would cause
  225. problems.  Has anyone tried this?]
  226.  
  227. (1.9)    What is Bones?  What is it for?
  228.  
  229. Bones is a system that provides the Kerberos API without using
  230. encryption and without providing any form of security whatsoever.  It
  231. is a fake that allows the use of software that expects Kerberos to be
  232. present when it cannot be.
  233.  
  234. Why does it exist?  Kerberos is a network security system which relies
  235. on cryptographic methods for its security.  Since Kerberos' encryption
  236. system, DES, is not exportable, Kerberos itself cannot be exported or
  237. used outside of the United States in its original form.  (See question
  238. 2.2 for more information.)
  239.  
  240. As a partial solution to this problem, the Kerberos source code was
  241. modified by the addition of #ifdef NOENCRYPTION around all calls to
  242. DES functions.  Compiling this version with the symbol NOENCRYPTION
  243. defined results in a system that looks like Kerberos from an
  244. application's point of view but that does not require DES libraries
  245. (and, as a result, does not speak the real Kerberos protocol and does
  246. not provide any security).
  247.  
  248. The final piece in this puzzle is a program called "piranha" which
  249. takes the Kerberos sources and removes all of the calls to the
  250. encryption routines, replacing it with the code which was under #ifdef
  251. NOENCRYPTION, producing the system known as Bones.  Bones has the
  252. property that there is absolutely no question about whether or not it
  253. is legal to transport its sources across national boundaries, since it
  254. neither has any encryption routines nor any calls to encryption
  255. routines.
  256.  
  257. #ifdef NOENCRYPTION was not documented, and it was only intended to be
  258. used in the above manner.  Someone who tries compiling Kerberos with
  259. that #define has in some sense "voided the warranty", and will get
  260. something which is both (a) not secure and (b) not Kerberos.
  261.  
  262. 2.  Using and Administering Kerberos
  263. ----------------------------------------------------------------------
  264.  
  265. (2.1)    Can I use Kerberos for local password validation?
  266.  
  267. Yes, but only under certain circumstances and only if you are
  268. careful.
  269.  
  270. Requests for Kerberos ticket granting tickets (tgts) (e.g. from kinit
  271. or login) are sent in plaintext to the Kerberos server, which then
  272. responds with credentials encrypted in the requesting principal's
  273. secret key.  The program then attempts to decrypt the data with the
  274. supplied password and considers the authentication "successful" if the
  275. decryption appears to yield meaningful results (such as the correct
  276. principal name).
  277.  
  278. The problem here is that the requesting program cannot know for sure
  279. whether the decryption succeeded or, more importantly, whether the
  280. response actually came from the Kerberos server.  An attacker could,
  281. for example, walk up to an unattended machine and "log in" as a
  282. non-existent user.  Kerberos will eventually respond with an
  283. appropriate error, but the attacker can arrange for another program to
  284. deliver a fake response to login first; he then types the correct
  285. password (which he knows because he created the fake response in the
  286. first place) and succeeds in spoofing login.
  287.  
  288. The solution to this problem is for login to verify the tgt by using
  289. it to acquire a service ticket with a known key and comparing the
  290. results.  Typically, this means requesting an rcmd.<hostname> ticket,
  291. where <hostname> is the local hostname, and checking the response
  292. against the key store in the machine's /etc/srvtab file.  If the keys
  293. match then the original tgt must have come from Kerberos (since the
  294. key only exists in the srvtab and the Kerberos database), and login
  295. can allow the user to log in.
  296.  
  297. The solution works only so long as the host has a srvtab containing an
  298. rcmd.<hostname> (or any other standard principal) entry.  This is fine
  299. for physically secure or single-user workstations, but does not work
  300. on public workstations in which anyone could access the srvtab file.
  301.  
  302. (2.2)    What is the export status of Kerberos?
  303.  
  304. There is a tremendous amount of confusion on this topic.
  305.  
  306. In general, the COCOM treaty, signed by twenty or so countries
  307. including the United States, says that all cryptographic material will
  308. be treated as munitions.  This means that these countries treat
  309. exporting DES the same way they would treat exporting weapons, fighter
  310. planes, and other nasty stuff.  You cannot export such materials to
  311. any other country (except Canada**) without an export license.
  312.  
  313. However, it *is* possible to get an export license for Kerberos (DEC
  314. apparently has one for ULTRIX) provided it is hacked up in the correct
  315. way.  The correct way appears to include making it impossible to
  316. perform encryption on arbitrary user data; authentication is okay, but
  317. secrecy is not.  Since the Kerberos API provides this functionality,
  318. it must be carefully removed before an export license will be granted.
  319.  
  320. Of course, I am not a lawyer; this information is merely a collection
  321. of what others (who are also not lawyers) have said and should not be
  322. interpreted as legal advice.  If anyone out there has firm legal
  323. advice, feel free to contribute it.
  324.  
  325. **Canada has been granted a general exemption to DES export
  326. restrictions; the exemption is detailed in Title #22, Code of Federal
  327. Regulations, "International Traffic in Arms Rgulations," Section 126.5.
  328. You can export DES to Canada providing that it is not re-exported to
  329. another country and that the above regulation is referenced.  This
  330. information has been confirmed with Mr. Alan Sushinsky, Munitions
  331. Control, The State Department, (703) 875-6621.
  332.  
  333. (2.3)    How can I delete a principal from the database?
  334.  
  335. MIT Kerberos V4 does not include a single command to delete a Kerberos
  336. principal.  This was an intentional omission based on the assumption
  337. that by making deletion difficult, accidents were less likely to
  338. happen.  If you want to delete a principal, do "kdb_util dump", edit
  339. the ASCII dump with an editor, and do a "kdb_util load".  Obviously,
  340. you can write a shell script to make this more convenient.
  341.  
  342. AFS Kerberos' and Kerberos V5's admin tools have a simple delete
  343. request.
  344.  
  345. (2.4)    What are the officially assigned Kerberos port numbers?
  346.  
  347. The file src/prototypes/services.append in the MIT Kerberos
  348. distribution contains the commonly used port assignments.  This file
  349. is not the whole story, however.
  350.  
  351. "kerberos" has officially been moved to port 88, although people will
  352. have to listen on port 750 for some time to come, and assume
  353. that many servers won't be converted to listen to port 88 for some
  354. time.
  355.  
  356. "kerberos_master" and "krb_prop" have not been reserved, but they are
  357. only used for intra-site transactions so having them reserved probably
  358. isn't necessary.  Furthermore, both of their port numbers have already
  359. been assigned to other services, so requesting an official assignment
  360. will force them to change.
  361.  
  362. "eklogin", "kpop", and "erlogin" have not been officially reserved,
  363. but probably should be.  Their ports are not currently assigned to
  364. other services, so hopefully they will not have to change if an
  365. official assignment is requested.
  366.  
  367. (2.5)    Are there Kerberos versions of telnet and ftpd?
  368.  
  369. A Kerberos telnet is available via anonymous ftp from ftp.uu.net, in
  370. /networking/telnet.91.03.25.tar.Z.  There is also a Kerberos telnet in
  371. the V5 distribution which is based on the 4.4BSD telnet/telnetd.
  372. [NOTE: Telnet has been "temporarily" removed from the V5 beta 2
  373. release.]
  374.  
  375. A distributable Kerberos version of ftpd does not yet appear to exist.
  376.  
  377. (2.6)    Why does rlogin print "Warning: No Kerberos tickets obtained"?
  378.  
  379. Kerberos rlogin uses a standard Kerberos exchange to prove the
  380. identity of the user to the remote host, after which it uses the
  381. /etc/passwd and a .klogin file to determine whether the user is
  382. authorized to log in.
  383.  
  384. Since the user never types a password, klogind on the remote host
  385. cannot obtain a new ticket granting ticket.  The user's existing tgt
  386. cannot be used on the remote host, because MIT Kerberos V4 tickets are
  387. host-specific.  Therefore, even though the user has logged in to the
  388. remote host, there is no ticket granting ticket for the user available
  389. on the remote host.  The warning message is merely a reminder of this
  390. fact.
  391.  
  392. (2.7)    What operating systems has Kerberos been ported to?
  393.     What vendors provide commercial support for Kerberos?
  394.  
  395. Note: This was written by Greg Edwards, edwardsg@iscnvx.is.lmsc.lockheed.com.
  396.  
  397. The following is a list on Kerberos Ports that I know of as of 23 
  398. October 1992. If you have additional information please send it to me. 
  399. This listing is of announced ports, not ports that I have tested. In 
  400. addition, it does not mention any problems that I may be aware of or 
  401. heard rumors of in certain ports. Most vendors are trying to make their 
  402. Kerberos ports more complete and remove problems all the time, so this 
  403. chart will need updating soon.
  404.  
  405. Kerberos Ports Key (inside matrix)
  406. 4     K4 port done
  407. 5     Kerberos v5 port done 
  408. D     DCE version of Kerberos done
  409. d     DCE version of Kerberos being ported or planned
  410. p     porting version 4 at this time
  411. P     porting Kerberos v5
  412. h    planned port of v4
  413. H    planned port of v5
  414. t    Kerberos v4 being tested
  415. T    Kerberos v5 being tested
  416. A    Athena (of which Kerberos 4 is a part)
  417. -    no product known
  418.  
  419. Porting Companies (y-axis)
  420. c     Cygnus Support      Steve Wilson 415/433-3811 swilson@cygnus.com
  421.                 network-security@cygnus.com
  422. d       DEC (DECathena?)        John O'Hara 508/486-7402 
  423.                     johara@athena.lkg.dec.com
  424. e    Essex                Vince Stasio 508/532-5511
  425. f     FTP Software            Kristine Kilduff 617/246-0900 kpk@ftp.com
  426. i    IBM
  427. m    MIT release
  428. o    Open Computing Security Group    Dan Webb 206/883-8721 dwebb@ocsg.com
  429.                 or Bob Gassen 206/883-8721 bobg@ocsg.com
  430. p    Project Pilgrim        Art Gaylord 413/545-2420 art@cs.umass.edu
  431. r    Cisco Routers & Bridges
  432. t    TGV                    S. Vance 800/tgv-3440 vance@tgv.com
  433. .    Telebit 408/734-4333
  434. w    Wollongong         Denise Earhart 415/962-7211
  435. x    Xyplex (terminal server) Rich Fitzgerald 714/725-9489
  436. z    Product for one OEM/self
  437.  
  438. Notes: Cray Kerberos supplied as part of UNICOS 7.0, DCE version later
  439.         DECs Ultrix Kerberos does not authenticate users, only servers
  440.         DECAthena does authenticate users
  441.  
  442. Rumored ports by:
  443.     Emulex    714/662-5600
  444.       Gradient Technologies
  445.     HP
  446.       Transarc for AFS (Andrew File System) & makes DEC developers kits
  447.  
  448.  
  449. Kerberos Ports        23 Oct 1992
  450.  
  451. who        c  d  e  f  i  m  o   p  r  t  w  z  other
  452. Amdahl        -  -  -  -  -  -  -   -  -  -  -  4  -
  453. AIX 3.2    4      -  A  -  -  d  4  tT  -  -  -  -  P  -
  454. Cisco        -  -  -  -  -  -  -   -  -  -  -  p  -
  455. Convex        -  -  -  -  -  -  -   -  -  -  -  -  4  LMSC partial port of K4
  456. Cray        -  -  -  -  -  -  -   -  -  -  -  4d 4  LLNL partial port of K4
  457. HP        -  A  -  -  -  -  hT  -  -  -  -  -  d
  458. Intel Sv.4    -  -  -  -  -  4  H   -  -  -  -  -  d
  459. Irix 4.0.3    4  -  -  -  -  -  -   -  -  -  -  -  p
  460. Mac 6.x        p  -  -  -  -  4  4H  -  -  -  -  -  -
  461. Mac 7.x        p  -  -  -  -  4  4H  -  -  -  -  -  -
  462. MsDos        -  -  4  4  -  4  4H  -  -  -  -  -  -
  463. MVS        -  -  -  -  4  -  pP  -  -  -  -  4d -
  464. NCR        -  -  -  -  -  -  pH  -  -  -  -  -  -
  465. NCSATelnetPC    -  -  -  -  -  -  t   -  -  -  -  -  -
  466. NCSATelnetMac    -  -  -  -  -  -  t   -  -  -  -  -  -
  467. NeXT        -  -  -  -  -  4  4H  -  -  -  -  -  -
  468. who        c  d  e  f  i  m  o   p  r  t  w  z  other
  469. Novell        -  -  -  -  -  -  H   -  -  -  -  d  -
  470. OS/2        -  -  4  -  4d -  -   -  -  -  -  4  -
  471. Pyramid        -  -  -  -  -  -  H   -  -  -  -  p  -
  472. SCO        p  -  -  -  -  -  -   -  -  -  -  -  -
  473. SecDynamics    -  -  -  -  -  -  tH  -  -  -  -  -  -
  474. Sequent        -  -  -  -  -  -  4H  -  -  -  -  -  -
  475. Solaris 2.0    p  -  -  -  -  -  4T  -  -  -  -  d  4 Cray has a K4 port
  476. SunOS 4.0.1    4  A  -  -  -  4  4T  -  -  -  -  -  -  
  477. SunOS 4.1    4  A  -  -  -  4  4T  -  -  -  -  -  -
  478. Telebit        -  -  -  -  -  -  -   -  -  -  -  4  -  
  479. Ultrix 4.1    4  A4 -  -  -  4  -   -  -  -  -  4  -  
  480. VM        -  -  -  -  4  -  -   -  -  -  -  4  -
  481. VMS        -  -  -  -  -  -  -   4d -  4  4  -  -
  482. Win3.1        -  -  -  -  -  -  tH  -  -  -  -  -  p
  483. Xyplex        -  -  -  -  -  -  -   -  -  -  -  4  -
  484. who        c  d  e  f  i  m  o   p  r  t  w  z  other
  485.  
  486. Please send updates to Greg Edwards, edwardsg@iscnvx.is.lmsc.lockheed.com
  487.  
  488. 3.  Building and Installing Kerberos
  489. ----------------------------------------------------------------------
  490.  
  491. (3.1)    Why do I get an error message from ld when make_commands is
  492.     executed? 
  493.  
  494. The make_commands program (from the file util/ss/make_commands.c,
  495. around line 101) spawns ld as part of its normal operation.  The
  496. arguments to ld are hard-coded into the exec() call and are not
  497. correct for all systems.  To fix the problem, examine the call and
  498. determine the correct arguments for your environment; once you know
  499. the correct arguments, the change to the source code will be obvious.
  500.  
  501. (3.2)    Why doesn't KRB5-types.h exist when I build version 5?
  502.  
  503. There's a bug in Sun's imake/cpp setup, so the Makefile that is
  504. generated in lib/asn.1 is broken.  KRB5-types.h is generated by the
  505. ISODE program pepsy; look in the makefile just before pepsy is called.
  506. It's fairly obvious where a tab character is missing.
  507.  
  508. 4.  Miscellaneous
  509. ----------------------------------------------------------------------
  510.  
  511. (4.1)    List references for Kerberos and network security in general.
  512.  
  513. See the bibliography at the end of this document.
  514.  
  515. (4.2)    Where are archives of comp.protocols.kerberos (a.k.a 
  516.     kerberos@athena.mit.edu)?
  517.  
  518. Archives are available via anonymous FTP from athena-dist.mit.edu in
  519. the directory pub/kerberos/krb-mail.  The kerberos@athena.mit.edu
  520. archives prensently extend up to 24 September 1992.  Some archives of
  521. the kerberos protocol mailing list are also available.
  522.  
  523. ----------------------------------------------------------------------
  524.  
  525. BIBLIOGRAPHY
  526.  
  527. The FTP site for a reference, when known, is listed in square brackets
  528. following the entry.  Yes, I know that these are not in Officially
  529. Blessed Bibliography Format.  Sue me.
  530.  
  531. [1] Jennifer G. Steiner, Clifford Neuman, Jeffrey I. Schiller.
  532. "Kerberos: An Authentication Service for Open Network Systems", USENIX
  533. Mar 1988.  [athena-dist.mit.edu:pub/kerberos/doc/usenix.PS]
  534.  
  535. [2] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer,
  536. "Kerberos Authentication and Authorization System", 12/21/87.
  537.  
  538. [3] R. M. Needham and M. D.  Schroeder, "Using Encryption for
  539. Authentication in Large Networks of Computers," Communications of the
  540. ACM, Vol.  21(12), pp. 993-999 (December, 1978).
  541.      
  542. [4] V. L. Voydock and S. T. Kent, "Security Mechanisms in High-Level
  543. Network Protocols," Computing Surveys, Vol.  15(2), ACM (June 1983).
  544.  
  545. [5] Li Gong, "A Security Risk of Depending on Synchronized Clocks",
  546. Operating Systems Review, Vol 26, #1, pp 49--53.
  547.  
  548. [6] S.M. Bellovin and M. Merritt, "Limitations of the Kerberos
  549. Authentication System," USENIX Jan 1991.
  550. [research.att.com:dist/internet_security/kerblimit.usenix.ps]
  551.  
  552. [7] Refik Molva, Gene Tsudik, Els Van Herreweghen, and Stefano Zatti,
  553. "KryptoKnight Authentication and Key Distribution System."
  554. [jerico.usc.edu:pub/gene/kryptoknight.ps.Z]
  555.  
  556. [8] C. Neumann and J. Kohl, "The Kerberos(tm) Network Authentication
  557. Service (V5)," April 1992.  Currently released as an Internet Draft.
  558. --
  559. Barry Jaspan, bjaspan@mit.edu
  560.