BBS水木清华站∶精华区
发信人: ghost007@SMTH (笑傲江湖), 信区: Unix
标 题: Kerberous??
发信站: 水木清华 (Mon May 20 06:14:59 1996)
转信站: SMTH
Kerberous 最早是MIT开发的网络安全机制, 采用多路保密字和TICKET等进
行身份验证. Kerberous 在各种网络系统(特别是是公共网)上有很广泛的
应用, 如AFS, Internet等.
再偷回懒, 若有兴趣下面是一个关于Kerberos的FAQ, 顺手牵羊啦.
Kerberos Users' Frequently Asked Questions
-------------------------------------------------------------------------------
Questions addressed in this release:
1. Kerberos and its Many Incarnations
FAQ Table Of Contents...
(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) What are the officially assigned Kerberos port numbers?
(2.4) Are there Kerberos versions of telnet and ftpd?
What other Kerberos clients exist?
(2.5) How do I set up a slave server?
Bibliography
-------------------------------------------------------------------------------
1. Kerberos and its Many Incarnations
Back To TOC ===>
[Image]
(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?
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) 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.4) 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.5) 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).
-------------------------------------------------------------------------------
.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]
-------------------------------------------------------------------------------
Originally compiled by:
Barry Jaspan,
bjaspan@cam.ov.com
OpenVision Technologies
BBS水木清华站∶精华区