Archive-name: kerberos-faq/user Version: 1.14 Kerberos Users' Frequently Asked Questions September 14, 1995 Compiled by: Barry Jaspan, <bjaspan@cam.ov.com> OpenVision Technologies Kerberos; also spelled Cerberus. n. The watch dog of Hades, whose duty it was to guard the entrance--against whom or what does not clearly appear; . . . it is known to have had three heads. . . -Ambrose Bierce, The Enlarged Devil's Dictionary This document answers Frequently Asked Questions about the Kerberos authentication system. It is freely distributable. Direct all responses and questions to bjaspan@cam.ov.com. Most of the information presented here has been collected from postings to the comp.protocols.kerberos newsgroup (gatewayed to the mailing list kerberos@mit.edu). DISCLAIMER: OpenVision Technologies makes no representations about the suitability of this information for any purpose. It is provided "as is" without express or implied warranty. In particular, this document is not intended as legal advice for exporting Kerberos, DES, or any other encryption software. Release Notes: The Web version of this document ( http://www.ov.com/misc/krb-faq.html) is now the master version. ASCII versions will continue to the posted to news.answers and comp.answers and archived on RTFM.MIT.EDU as before. ------------------------------------------------------------------------------- Questions addressed in this release: 1. Kerberos and its Many Incarnations (1.0) Where can I get more information? (1.1) What is Kerberos? What is it good for? (1.2) What different versions and distributions of Kerberos exist? (1.3) Where can I get Kerberos version 4 or 5? (1.4) What is the current status of version 4? (1.5) What is the current status of version 5? (1.6) Are version 4 and version 5 compatible? (1.7) How/why is Transarc's Kerberos different from MIT Kerberos V4? Can they interoperate? (1.8) How/why is OSF DCE Security different from MIT Kerberos V5? Can they interoperate? (1.9) How/why is DEC Ultrix Kerberos different from MIT Kerberos V4? Can they interoperate? (1.10) What is Bones? What is it for? 2. Building, Using, Installing, and Administering Kerberos (2.1) Can I use Kerberos for local password validation? (2.2) What is the export status of Kerberos? (2.3) How can I delete a principal from the database? (2.4) What are the officially assigned Kerberos port numbers? (2.5) Are there Kerberos versions of telnet and ftpd? What other Kerberos clients exist? (2.6) Why does rlogin print "Warning: No Kerberos tickets obtained"? (2.7) What vendors provide commercial support for Kerberos? (2.8) Why do I get an error message from ld when make_commands is executed? (2.9) What is libkrb.a, and why can't ld find it? (2.10) How do I set up a slave server? 4. Miscellaneous (4.1) List references for Kerberos and network security in general. (4.2) Where are archives of comp.protocols.kerberos (a.k.a kerberos@mit.edu)? ------------------------------------------------------------------------------- 1. Kerberos and its Many Incarnations (1.0) Where can I get more information? The Kerberos mailing list is kerberos@mit.edu. There is a bi-directional gateway between the list and the newsgroup comp.protocols.kerberos. Send subscription requests to kerberos-request@mit.edu. *** PLEASE DO NOT SEND SUBSCRIPTION REQUESTS TO kerberos@mit.edu. *** There are a number of Kerberos-related WWW sites. In no particular order: * < http://www.ov.com/misc/krb-faq.html>. This FAQ, of course. * < http://www.contrib.andrew.cmu.edu/usr/shadow/kerberos.html>. This site contains links to a variety of other documents, some about Kerberos, some related Kerberos, and some unrelated to Kerberos. * < http://nii.isi.edu/info/kerberos>. This site contains references to Kerberos documentation and technical papers, available Kerberos distributions, Kerberos-related applications (only NetCheque, currently), and Kerberos vendor information from this FAQ. * < http://pscinfo.psc.edu/~studarus/Kerberos>. This site contains information on setting up Kerberos V5 to use Sandia kadmin, the r-commands, and the sample server. * < http://ubvms.cc.buffalo.edu/~tkslen/kerberos.html>. This site contains installation and configuration notes and help as well as pointers to a variety of other documents. (1.1) What is Kerberos? What is it good for? Kerberos is a network authentication system for use on physically insecure networks, based on the key distribution model presented by Needham and Schroeder.[3] It allows entities communicating over networks to prove their identity to each other while preventing eavsdropping or replay attacks. It also provides for data stream integrity (detection of modification) and secrecy (preventing unauthorized reading) using cryptography systems such as DES. Kerberos works by providing principals (users or services) with tickets that they can use to identify themselves to other principals and secret cryptographic keys for secure communication with other principals.[1] A ticket is a sequence of a few hundred bytes. These ticket can then be embedded in virtually any other network protocol, thereby allowing the processes implementing that protocol to be sure about the identity of the principals involved. Practically speaking, Kerberos is mostly used in application-level protocols (ISO model level 7), such as TELNET or FTP, to provide user to host security. It is also used, though less frequently, as the implicit authentication system of data stream (such as SOCK_STREAM) or RPC mechanisms (ISO model level 6). It could also be used at a lower level for host to host security, in protocols like IP, UDP, or TCP (ISO model levels 3 and 4), although such implementations are currently rare, if they exist at all. It is important to realize that Kerberos is a one-trick pony. It provides for mutual authentication and secure communication between principals on an open network by manufacturing secret keys for any requestor and providing a mechanism for these secret keys to be safely propagated through the network. Kerberos does not, per se, provide for authorization or accounting, although applications that wish to can use their secret keys to perform those functions securely. Kerberos also does not provide password validation for individual workstations unless care is taken; see question 2.1. It is also important to understand that using Kerberos on time-sharing machines greatly weakens its protections, since a user's tickets are then only as secure as the 'root' account (read: not very). Furthermore, dumb terminals and most X terminals do not understand the Kerberos protocol and as a result their cable connections remain insecure. (1.2) What different versions and distributions of Kerberos exist? There are several different versions and distributions of Kerberos. Most of them are based on an MIT distributions in one form or another but the lineage is not always simple. Some of the distributions are freely available, some are stand-alone commercial products, and others are part of a larger free or commercial systems. This list is certain to be incomplete: Versions of Kerberos V4: * MIT Kerberos V4. Freely available; see question 1.4. * Bones. Freely available; see questions 1.3 and 1.10. * Transarc AFS. Commercial; see question 1.7. * Digital Unix. Commercial; see question 1.9. * Also see question 2.7. Versions of Kerberos V5: * MIT Kerberos V5. Freely available; see question 1.5. * OSF DCE Security. Commercial; see question 1.8. * Also see question 2.7. (1.3) Where can I get Kerberos version 4 or 5? In the United States and Canada (*), Kerberos is available via anonymous FTP from athena-dist.mit.edu (18.71.0.38). For specific instructions, cd to pub/kerberos and get the file README.KRB4 (for version 4) or README.KRB5_BETA5 (for version 5). Note that *YOU WILL NOT BE ABLE TO RETRIEVE KERBEROS WITHOUT READING THIS FILE*. Outside the United States, you can get Bones via anonymous ftp from ftp.funet.fi (128.214.6.100) in pub/unix/security/kerberos. A DES library is available from the same place. See question 1.10 for information on Bones. (*) Kerberos and DES can be exported to Canada. See question 2.2. (1.4) What is the current status of version 4? With the release of patch level 10 on December 10, 1992, MIT Kerberos 4 is now in its final form. MIT does not anticipate ever making a new Kerberos 4 release. Several vendors provide their own versions of Kerberos which may contain improvements or extensions; see question 2.7. (1.5) What is the current status of version 5? The newest version of MIT Kerberos V5 is beta 5, released 5 May 1995. It contains substantial (and backwards-incompatible) changes to the krb5 API, a new admin server, improved portability, and numerous bug fixes and improvements. See question 1.3 for instructions on acquiring it. (1.6) Are version 4 and version 5 compatible? No. Versions 4 and 5 are based on completely different protocols. The MIT Kerberos V5 distribution contains some compatibility code, however: (a) the Kerberos server can optionally service V4 requests; (b) there is a program to convert a V4 format Kerberos database to a V5 format database; (c) an administration server that accepts V4 requests and operates on a V5 database is provided. (1.7) How/why is Transarc's Kerberos different from MIT Kerberos V4? Can they interoperate? This is a fairly complex question, and this answer is known to be incomplete. The issue is regularly discussed on the info-afs-kerberos@transarc.com mailing list; send mail to the -request list for subscriptions. Years ago, the designers of AFS decided to implement their own security system based on the Kerberos specification instead of using the (then, not yet publicly available) MIT Kerberos V4. As a result, Transarc's AFS Kerberos speaks a different protocol but also understands the MIT Kerberos V4 protocol. They can, in principal, talk to each other; however, there are a sufficient number of annoying details and an insufficient number of advantages such that it may not be practical. The two versions use a different string-to-key function (the algorithm that turns a password into a DES key); the AFS version uses the realm name as part of the computation while the MIT version does not. A program that uses a password to acquire a ticket (e.g. kinit or login) will only work with one version, unless it is hacked up to try both string-to-key algorithms. The two versions also use a different method of finding Kerberos servers. MIT Kerberos uses krb.conf and krb.realms to map hostnames to realms and realms to Kerberos servers. AFS kaservers for a realm, by definition, are located on the AFS database servers and can therefore be located using /usr/vice/etc/CellServDB. This means that a program built using the MIT Kerberos libraries will look in one place for the information while a program built using the AFS Kerberos libraries will look in another. You can certainly set up all three files and use both libraries, but be sure that everything is consistent. The two versions have a different password changing protocol, so you must use the correct 'kpasswd' program for the server you are talking to. In general, AFS clients that talk directly to the kaserver use an Rx-based protocol, instead of UDP as with MIT Kerberos, so those AFS clients cannot talk to an MIT server. In summary, AFS Kerberos and MIT Kerberos can interoperate once you've acquired a ticket granting ticket, which you can do with kinit (MIT) or klog (AFS). With a tgt, Kerberos applications such as rlogin can talk to an MIT or AFS Kerberos server and achieve correct results. However, it is probably best to pick one implementation and use it exclusively. (1.8) How/why is OSF DCE Security different from MIT Kerberos V5? Can they interoperate? [ This answer is based on information provided by Joe Pato (pato@apollo.hp.com). ] DCE Security is based on Kerberos V5, and uses the same wire protocol for AS and TGS requests; that means that standard Kerberos applications like kinit and telnet should work using a DCE Security Server. The implementation for the DCE Security Server, secd, was based on an early MIT releases and has evolved independently of the MIT code base and as a result some minor incompatibilities exist. DCE 1.2 slated for release in 1996 is planned to be fully conformant with IETF RFC 1510 at which time any remaining protocol nits will be resolved (interoperability problems with "vanilla" Kerberos clients will be treated as bugs in DCE). An MIT Kerberos V5 server cannot replace the DCE Security Server, however. First, DCE applications communicate with secd via the DCE RPC. Second, the DCE security model includes a Privilege Server (PS) that fills in the authorization field of a principal's ticket with DCE-specific data, and the DCE Security Server has a PS built in. In order for the MIT Kerberos V5 server to support DCE clients it would need to talk to a stand-alone PS and, although the necessary information is available, no such PS presently exists. The DCE does not support the Kerberos V5 API. It does, however, provide the GSS-API with Kerberos V5 mechanism (in addition to a DCE mechanism). Since a Kerberos V5 GSS-API mechanism is also provided in the current MIT Kerberos V5 distribution, applications developed against the GSS-API with this mechanism should operate with either an MIT Kerberos server or a DCE secd. For this reason, the GSS-API should now be considered the API of choice for Kerberos application development. (1.9) How/why is DEC Ultrix Kerberos different from MIT Kerberos V4? Can they interoperate? DEC ULTRIX contains Kerberos for a single reason, namely, to provide authenticated name service for the ULTRIX enhanced security option. It does not support user-level authentication in the normal manner. DEC's version is essentially the same as (and derived from) MIT Kerberos V4 with a few changes. The most significant change is that the ability to perform any kind of end-to-end user data encryption has been eliminated in order to comply with export restrictions. Minor changes include the placement of ticket files (/var/dss/kerberos/tkt vs. /tmp) and the principal names used by some standard Kerberos services (e.g.: kprop vs. rcmd); there are probably other minor changes as well. These changes make it annoying but not impossible to use DEC ULTRIX Kerberos in the normal way. However, there is no reason at all to do so, because the MIT distribution supports ULTRIX directly. [This may not be completely true. I imagine that using ULTRIX Kerberos for enhanced security and MIT's Kerberos at the same time would cause problems. Has anyone tried this?] (1.10) What is Bones? What is it for? Bones is a system that provides the Kerberos API without using encryption and without providing any form of security whatsoever. It is a fake that allows the use of software that expects Kerberos to be present when it cannot be. Why does it exist? Kerberos is a network security system which relies on cryptographic methods for its security. Since Kerberos' encryption system, DES, is not exportable, Kerberos itself cannot be exported or used outside of the United States in its original form. (See question 2.2 for more information.) As a partial solution to this problem, the Kerberos source code was modified by the addition of #ifdef NOENCRYPTION around all calls to DES functions. Compiling this version with the symbol NOENCRYPTION defined results in a system that looks like Kerberos from an application's point of view but that does not require DES libraries (and, as a result, does not speak the real Kerberos protocol and does not provide any security). The final piece in this puzzle is a program called "piranha" which takes the Kerberos sources and removes all of the calls to the encryption routines, replacing it with the code which was under #ifdef NOENCRYPTION, producing the system known as Bones. Bones has the property that there is absolutely no question about whether or not it is legal to transport its sources across national boundaries, since it neither has any encryption routines nor any calls to encryption routines. #ifdef NOENCRYPTION was not documented, and it was only intended to be used in the above manner. Someone who tries compiling Kerberos with that #define has in some sense "voided the warranty", and will get something which is both (a) not secure and (b) not Kerberos. Copies of the Kerberos Bones with DES routines and calls added back in by foreign programmers are called `eBones', and are available by anonymous FTP from machines in Sweden, Germany, Israel, Finland, Australia, and France (so far); check with "archie". ------------------------------------------------------------------------------- 2. Using and Administering Kerberos (2.1) Can I use Kerberos for local password validation? Yes, but only under certain circumstances and only if you are careful. Requests for Kerberos ticket granting tickets (tgts) (e.g. from kinit or login) are sent in plaintext to the Kerberos server, which then responds with credentials encrypted in the requesting principal's secret key. The program then attempts to decrypt the data with the supplied password and considers the authentication "successful" if the decryption appears to yield meaningful results (such as the correct principal name). The problem here is that the requesting program cannot know for sure whether the decryption succeeded or, more importantly, whether the response actually came from the Kerberos server. An attacker could, for example, walk up to an unattended machine and "log in" as a non-existent user. Kerberos will eventually respond with an appropriate error, but the attacker can arrange for another program to deliver a fake response to login first; he then types the correct password (which he knows because he created the fake response in the first place) and succeeds in spoofing login. The solution to this problem is for login to verify the tgt by using it to acquire a service ticket with a known key and comparing the results. Typically, this means requesting an rcmd.<hostname> ticket, where <hostname> is the local hostname, and checking the response against the key stored in the machine's /etc/srvtab file. If the keys match then the original tgt must have come from Kerberos (since the key only exists in the srvtab and the Kerberos database), and login can allow the user to log in. The solution works only so long as the host has a srvtab containing an rcmd.<hostname> (or any other standard principal) entry. This is fine for physically secure or single-user workstations, but does not work on public workstations in which anyone could access the srvtab file. (2.2) What is the export status of Kerberos? [ There is a great deal of activity relating to this question and the answer below is somewhat out of date. ] The export status of Kerberos is unclear, largely because the export regulations are unclear in general. There's an overview of cryptography export cases in http://www.cygnus.com/~gnu/export.html . Several companies, including OpenVision and DEC, have received export licenses for commercial products that contain Kerberos binaries and/or programming libraries. Contact the Kerberos vendors listed in question 2.7 for more information. Export of technology is controlled by both the State Department and by the Commerce Department. The two agencies' jurisdictions don't actually legally overlap, but nobody really knows which agency has jurisdiction over which products. So there is a process by which you, as a potential exporter, can ask the State Department which agency controls your particular export. It's called a Commodity Jurisdiction Request or CJR. There is a "CJR Kit" for helping you to file CJR's available at ftp://ftp.cygnus.com/pub/export/cjr.kit . The State Department has the power to regulate exports of even publicly available (published) materials, in apparent contradiction to the First Amendment. The Commerce Department regulations (Commerce Control List) specifically exempts publicly available materials from export controls (section 779.3), allowing their export under `General License' GTDA, which requires no paperwork and is usable by everyone except a few hundred people or companies who have abused export controls in the past. The State Department regulation (International Traffic in Arms Regulations, or ITAR) exempts `public domain information' (22 CFR 120.11) but fails to define `information'. The State Department takes the position that software is not `information'. Kerberos is an authentication system, and export of authentication software and hardware is controlled by the Commerce Department. However, the State Department has never formally said where the line between authentication and encryption is, so they are also apparently interested in Kerberos. Cygnus Support filed a CJR for the Kerberos Bones software, and got back a formal notification that it was controlled by the Commerce Dept. We then filed a CCATS request with the Commerce Department, and eventually found out that it is exportable to all destinations without paperwork under the GTDA license (because it is `publicly available' without charge on the Internet). The formal documents are in ftp://ftp.cygnus.com/pub/export . This just confirms what we all suspected anyway -- if you take the crypto out of Kerberos (which is how the Bones were generated), it's exportable. The Bones are available at ftp://athena-dist.mit.edu/pub/kerberos; look at README.ftp for instructions. As for the exportability of full strength Kerberos in source code, nobody has apparently applied for this. (Please let us know if you know of a case.) I believe that the best bet for threading the export maze is to define and defend Kerberos as an authentication product, to get it past the State Department, and then to show that it is publicly available, to get it past the Commerce Department. To do this, you actually have to be trying to export a publicly available version of Kerberos, though. Canada is considered a part of the United States for export control purposes so Kerberos can be exported to Canada without problems. (2.3) How can I delete a principal from the database? MIT Kerberos V4 does not include a single command to delete a Kerberos principal. This was an intentional omission based on the assumption that by making deletion difficult, accidents were less likely to happen. If you want to delete a principal, do "kdb_util dump", edit the ASCII dump with an editor, and do a "kdb_util load". Obviously, you can write a shell script to make this more convenient. The admin tools for AFS Kerberos, MIT Kerberos V5, DCE Kerberos, and virtually every commercial version of Kerberos have a delete command. (2.4) What are the officially assigned Kerberos port numbers? The file src/prototypes/services.append in the MIT Kerberos distribution contains the commonly used port assignments. This file is not the whole story, however. "kerberos" has officially been moved to port 88, although people will have to listen on port 750 for some time to come, and assume that many servers won't be converted to listen to port 88 for some time. "kerberos_master" and "krb_prop" have not been reserved, but they are only used for intra-site transactions so having them reserved probably isn't necessary. Furthermore, both of their port numbers have already been assigned to other services, so requesting an official assignment will force them to change. "eklogin", "kpop", and "erlogin" have not been officially reserved, but probably should be. Their ports are not currently assigned to other services, so hopefully they will not have to change if an official assignment is requested. (2.5) Are there Kerberos versions of telnet and ftpd? (a) TELNET. An experimental Telnet Authentication Option has been defined, and is described in RFC1416. A separate document, RFC1411, describes how that option is to be used with Kerberos V4, but no RFC exists for its use with Kerberos V5. These RFC's only define how authentication is to be performed; the standard for full encryption is still under development. An implementation of Kerberos V4 telnet is available via anonymous ftp from ftp.uu.net, in /networking/telnet.91.03.25.tar.Z, but it predates both of the above-mentioned RFCs and is therefore almost certainly not compliant with them. A Kerberos V5 telnet implementation is contained in MIT Kerberos 5 beta 4 and subsequent releases. (b) FTP. The IETF Common Authentication Technology (CAT) Working Group has published the Internet Draft "FTP Security Extensions" <draft-ietf-cat-ftpsec-NN.txt> which defines Kerberos V4 and GSS-API authentication systems. Please note that the extensions are still in the Draft stage and may change at any time, in incompatible ways. A freely available version of FTP using Kerberos V4 used to exist on thumper.bellcore.com but is no longer there [Anyone know where it went?]. Commercial versions of secure FTP are available; see question 2.7. (2.6) Why does rlogin print "Warning: No Kerberos tickets obtained"? Kerberos rlogin uses a standard Kerberos exchange to prove the identity of the user to the remote host, after which it uses the /etc/passwd and a .klogin file to determine whether the user is authorized to log in. Since the user never types a password, klogind on the remote host cannot obtain a new ticket granting ticket. The user's existing tgt cannot be used on the remote host, because MIT Kerberos V4 tickets are host-specific. Therefore, even though the user has logged in to the remote host, there is no ticket granting ticket for the user available on the remote host. The warning message is merely a reminder of this fact. The most recent release of MIT Kerberos V4 (patchlevel 10) contains a system called "rkinit" that allows a user to obtain a ticket granting ticket on a remote machine. Using this system, it is possible first to obtain a tgt on a machine and then log into it with Kerberos rlogin, thereby achieving a secure remote login with tickets. Alternatively, you use Kerberos V5 which has forwardable tickets. However, forwardable tickets do not seem to work in the current release of MIT Kerberos V5. (2.7) What vendors provide commercial support for Kerberos? This answer contains contact information for Kerberos vendors. Any vendor can submit an entry. NOTE: The current author of this list works for OpenVision Technologies, Inc. ---------------------------------------- Vendor: CyberSAFE Corporation formerly Open Computing Security Group (OCSG) Product: Challenger Contact: Sales Department (206) 883-8721 sales@ocsg.com Base version: MIT Kerberos 5 Last update: 4/6/95 ---------------------------------------- Vendor: Cygnus Support Product: Cygnus Network Security (CNS) Contact: Dwayne Shirakura or Kathy Powers +1 415 903 1400 voice +1 415 903 0122 fax network-security@cygnus.com Base version: MIT Kerberos 4 Last update: 4/20/95 References: o Product information: <http://www.cygnus.com/data/cns.html> ---------------------------------------- Vendor: Digital Equipment Corporation Product: DECathena Contact: Steve Omand (508) 952-4350 omand@athena.tay.dec.com Base version: MIT Kerberos 4 Last update: 4/11/95 References: ftp://ftp.digital.com/pub/Digital/info/whitepaper/decathena-solution.* ftp://ftp.digital.com/pub/Digital/info/whitepaper/secure-distributed-computing.* http://www.digital.com/info/whitepaper/decathena-solution.abs.html http://www.digital.com/info/whitepaper/secure-distributed-computing.abs.html ---------------------------------------- Vendor: Emulex Network Systems Product: a line of communications servers Contact: (714) 662-5600 ext 8065 sales@emulex.com Base version: MIT Kerberos 4 Last update: 11/23/94 ---------------------------------------- Vendor: OpenVision Technologies, Inc. Product: OpenV*Secure Contact: Brian Breton (617) 374-3700 (voice) (617) 374-3715 (fax) brian.breton@ov.com Base version: MIT Kerberos 5 Last update: 7/18/95 References: o Product information: <http://www.ov.com/product/> o Technical paper: _GSS-API Security for ONC RPC_ <ftp://ftp.cam.ov.com/pub/users/bjaspan/rpc_paper.ps> ---------------------------------------- Vendor: TGV, Inc. 101 Cooper Street Santa Cruz, CA 95060 Product: MultiNet for OpenVMS V3.3 Rev D Contact: (408) 457-5200 sales@tgv.com, info@tgv.com Base version: MIT Kerberos 4 Last update: 1/20/95 ---------------------------------------- Vendor: Xyplex, Inc. 295 Foster St. Littleton, MA 01460 Product: terminal servers Contact: (508) 952-4700 (508) 952-4702 (fax) mkt@xyplex.com Base version: MIT Kerberos 4 and 5 Last update: 4/17/95 ---------------------------------------- (2.8) Why do I get an error message from ld when make_commands is executed? The make_commands program (from the file util/ss/make_commands.c, around line 101) spawns ld as part of its normal operation. The arguments to ld are hard-coded into the exec() call and are not correct for all systems. To fix the problem, examine the call and determine the correct arguments for your environment; once you know the correct arguments, the change to the source code will be obvious. (2.9) What is libkrb.a, and why can't ld find it? The MIT Kerberos V5 server (krb5kdc) can operate in a V4 compatibility mode in which it accepts and responds to standard V4 requests (see question 1.5). In order to do so, it needs the V4 Kerberos library, libkrb.a. That library is not part of the V5 beta 4 and earlier distributions. It is assumed that if you want V4 compatibility you already have V4 built and installed; see question 1.3 for information on obtaining V4. To get krb5kdc to link properly, run configure with the argument "--with-krb4=" where is a directory that contains directories called "include" and "lib" that contain the V4 include files and libraries. Starting with the beta 5 release, the MIT Kerberos V5 distribution contains the V4 code so it is no longer necessary to obtain and build it separately. (2.10) How do I set up a slave server? This answer is written for Kerberos V5, but the same setup works for V4 with different program names. A slave database propagation consists of four steps: 1. Dumping the database to a transportable form. Use the command as "kdb5_edit -R 'dump_db /krb5/slave_datatrans'". 2. Transmitting the file from the master server with kprop. Use the command "kprop " for each slave server you want to propagate to. This requires that the master's host principal appear in the master's keytab (e.g.: /etc/v5srvtab). 3. Receiving the file on each slave server with kpropd. kpropd is intended to be run out of inetd with a line such as krb5_prop stream tcp nowait root /var/sbin/kpropd kpropd -p /var/sbin/kdb5_edit kpropd requires that the slave server's host principal exist in its keytab. 4. Loading the transported database with kdb5_edit load. If everything goes well up to this point, kpropd will automatically invoke kdb5_edit (via the path you specified in /etc/inetd.conf) and load the database so that the slave KDC can use it. Given this system, all you have to do is make sure that a krb5kdc gets started on all of your slave servers and that the propagation takes place at whatever schedule you desire. A common solution is to write a script to perform steps 1 and 2 above that is run from cron(1). ------------------------------------------------------------------------------- 4. Miscellaneous (4.1) List references for Kerberos and network security in general. See the bibliography at the end of this document. (4.2) Where are archives of comp.protocols.kerberos (a.k.a kerberos@mit.edu)? Archives are available via anonymous FTP from athena-dist.mit.edu in the directory pub/kerberos/krb-mail. The kerberos@mit.edu archives presently extend up to the end of 1992. Some archives of the kerberos protocol mailing list are also available. ------------------------------------------------------------------------------- BIBLIOGRAPHY The FTP site for a reference, when known, is listed in square brackets following the entry. Yes, I know that these are not in Officially Blessed Bibliography Format. Sue me. [1] Jennifer G. Steiner, Clifford Neuman, Jeffrey I. Schiller. "Kerberos: An Authentication Service for Open Network Systems", USENIX Mar 1988. [athena-dist.mit.edu:pub/kerberos/doc/usenix.PS] [2] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, "Kerberos Authentication and Authorization System", 12/21/87. [3] R. M. Needham and M. D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers," Communications of the ACM, Vol. 21(12), pp. 993-999 (December, 1978). [4] V. L. Voydock and S. T. Kent, "Security Mechanisms in High-Level Network Protocols," Computing Surveys, Vol. 15(2), ACM (June 1983). [5] Li Gong, "A Security Risk of Depending on Synchronized Clocks", Operating Systems Review, Vol 26, #1, pp 49--53. [6] S.M. Bellovin and M. Merritt, "Limitations of the Kerberos Authentication System," USENIX Jan 1991. [research.att.com:dist/internet_security/kerblimit.usenix.ps] [7] Refik Molva, Gene Tsudik, Els Van Herreweghen, and Stefano Zatti, "KryptoKnight Authentication and Key Distribution System." [jerico.usc.edu:pub/gene/www/paps/mtvz.ps.Z] [8] C. Neuman and J. Kohl, "The Kerberos Network Authentication Service (V5)," RFC 1510, September 1993. [9] B. Clifford Neuman and Theodore Ts'o, "Kerberos: An Authentication Service for Computer Networks," IEEE Communications, 32(9), September 1994. [http://nii.isi.edu/publications/kerberos-neuman-tso.html] ------------------------------------------------------------------------------- Barry Jaspan, bjaspan@cam.ov.com OpenVision Technologies -- Barry Jaspan, bjaspan@cam.ov.com OpenVision Technologies
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |