NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/protocol/kerberos/682

Text File | 1992-09-09 | 18.2 KB | 419 lines

Newsgroups: comp.protocols.kerberos
Path: sparky!uunet!stanford.edu!ATHENA.MIT.EDU!bjaspan
From: [e-mail] ("Barry Jaspan")
Subject: RELEASED: Kerberos FAQ Version 0.0
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 9 Sep 1992 16:15:39 GMT
Lines: 408


Enclosed below is the first draft of the Kerberos Users' FAQ.  Some of
you may have heard that Craig Lien was working on this project, but
turned out not to have enough time and handed the project over to us.

This is a "beta release" of the Kerberos FAQ.  The choice of questions
was based on articles posted to the Kerberos mailing list starting
January 1, 1992.  Please make suggestions and contribute any
information that you can.  Version 1.0 will be released within a week
or two.

Barry Jaspan, [e-mail]

---- snip snip ----

Kerberos Users' Frequently Asked Questions Version 0.0
September 1, 1992
Compiled by: Barry Jaspan, <[e-mail]>
             Geer Zolot Associates

     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; .  . . 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 [e-mail].  Most of the
information presented here has been collected from postings to the
comp.protocols.kerberos newsgroup (gatewayed to the mailing list
[e-mail]) and in general credit has not been given;
complain if you feel offended.

DISCLAIMER: Geer Zolot Associates 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: This is a "beta release" of the Kerberos FAQ.  The
choice of questions was based on articles posted to the Kerberos
mailing list starting January 1, 1992.  Please make suggestions and
contribute any information that you can.  Version 1.0 will be released
within a week or two.

Questions addressed in this release:
    (a * indicates that no answer is currently available)

(1)    What is Kerberos?  What is it good for?
(2)    Where can I get Kerberos version 4 or 5?
(3)    What is the current status of version 4?
(4)    What is the current status of version 5?
(5)    Are version 4 and version 5 compatible?
(6)    How/why is Transarc's Kerberos different from MIT Kerberos V4?
    Can they interoperate?
(7)*    How/why is OSF DCE Kerberos different from MIT Kerberos V5?
    Can they interoperate?
(8)    List references for Kerberos and network security in general.
(9)    Can I use Kerberos for local password validation?
(10)    What operating systems has Kerberos been ported to?
    What vendors provide commercial support for Kerberos?
(11)    What is the export status of Kerberos?
(12)    What is Bones?  What is it for?
(13)    How can I delete a principal from the database?
(14)    What are the officially assigned Kerberos port numbers?
(15)    Are there Kerberos versions of telnet and ftpd?
(16)    Why doesn't KRB5_defs.h exist when I build version 5?

----------------------------------------------------------------------

(1)    What is Kerberos?  What is it good for?

The following is an excerpt from [1]:

   Kerberos is a trusted third-party authentication service based on
   the model presented by Needham and Schroeder.[3] It is trusted in
   the sense that each of its clients believes Kerberos' judgement as
   to the identity of each of its other clients to be accurate.

[This really isn't a very good description.]

It is important to realize that Kerberos is a one-trick pony.  It
provides for mutual authentication between principals on an open
network.  It does not provide a mechanism for authorization; that is
left to the application.  It also does not provide password validation
for individual workstations unless care is taken; see question 7.

(2)    Where can I get Kerberos version 4 or 5?

In the United States, Kerberos is available via anonymous FTP from
athena-dist.mit.edu (18.71.0.38).  For specific instructions, obtain
and read the README file in pub/kerberos (for version 4) and
pub/kerberos5 (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 11 for
information on Bones.

(3)    What is the current status of version 4?

MIT Kerberos 4 is stable and more or less cast in stone; MIT is no
longer putting any resources into its development.  From time to time
minor bugs are reported; these may or may not be included in MIT's
distribution.

Several vendors provide their own versions of Kerberos which may
contain improvements or extensions; see question 8.

(4)    What is the current status of version 5?

A beta release of MIT Kerberos V5 is available; see question 2.  The
release is a year old, however, and is somewhat out of date and not
conformant with the latest protocol specification.  The next beta
release was scheduled for the end of July; obviously, it's late.

[What is the status of DCE Kerberos?]

(5)    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) there is a library which converts Kerberos V4 library
calls into Kerberos V5 requests, so you can run many V4 programs in a
V5 environment by relinking; (b) the Kerberos server can optionally
service V4 requests; (c) there is a program to convert a V4 format
Kerberos database to a V5 format database.  The names used by the V5
library have a prefix "krb5_" so they do not conflict with the V4
library.

(6)    How/why is Transarc's Kerberos different from MIT Kerberos V4?
    Can they interoperate?

Transarc's AFS Kerberos and MIT Kerberos V4 use the same protocol and
can therefore, in principal, talk to each other.  There are a few
caveats, however.

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 granting ticket (e.g.
kinit or login) will only work with one version.

The two versions also use a different method of finding Kerberos
servers.  MIT Kerberos uses /etc/krb.conf and /etc/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.

So, 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 with the -tmp option (AFS).  With a tgt, Kerberos
programs such as rlogin can talk to an MIT or AFS Kerberos server and
achieve correct results, assuming the libraries it is built with can
locate an appropriate Kerberos server.

(7)*    How/why is OSF DCE Kerberos different from MIT Kerberos V5?
    Can they interopate?

(8)    List references for Kerberos and network security in general.

See the bibliography at the end of this document.

(9)    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 store in the machine's /etc/srvtab file.  If the keys
match then the original tgt must have come from Kerberos (otherwise
the TGS would not have issued the service ticket), 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.

(10)    What operating systems has Kerberos been ported to?
    What vendors provide commercial support for Kerberos?

The following port survey is compiled from data obtained from the
first SF Bay Area Kerberos User Group meeting, plus additional
information obtained from other sources. Corrections and additions
welcomed (to [e-mail] and/or
[e-mail]).  Note that this is guaranteed to be
incomplete and out of date and almost certainly contains errors.

         Kerberos Port Survey - 17 June 1992

5 - Kerberos v5 port done
D - DCE version of Kerberos done
d - DCE version of Kerberos being ported or planned
4 - K4 port done, works
p - porting or planned port of version 4
- - no product here

who        c  f  m  o  p  r  t  w  z  ?
AIX 3.2        4  -  -  4  -  -  -  -  -  -
Cisco        -  -  -  -  -  -  -  -  p  -
Convex        -  -  -  -  -  -  -  -  -  -  LMSC partial port
Cray            -  -  -  -  -  -  -  -  -  -  LLNL partial port, LMSC porting
DECstation      4  -  -  -  -  -  -  -  -  -
HP        -  -  -  -  -  -  -  -  -  d
Intel Sv.4    -  -  -  -  -  -  -  -  -  d
Mac 6.x        p  -  -  4  -  -  -  -  -  -
Mac 7.x        p  -  -  4  -  -  -  -  -  -
MsDos            -  4  -  4  -  -  -  -  -  -
MVS        -  -  -  p  -  -  -  -  4d -
NeXT        -  -  -  4  -  -  -  -  -  -
Novell          -  -  -  p  -  -  -  -  d  -
Pyramid            -  -  -  -  -  -  -  -  p  -
Sequent        -  -  -     p  -  -  -  -  -  -
SGI Irix 4.0.3    4  -  -  -  -  -  -  -  -  p Sandia port
Solaris 2.0    p  -  -  -  -  -  -  -  d  -
SunOS 4.0.1    4  -  4  4  -  -  -  -  -  -
SunOS 4.1    4  -  4  4  -  -  -  -  -  -
Ultrix 4.1    4  -  -  -  -  -  -  -  4  -
VM        -  -  -  -  -  -  -  -  d  -
VMS        -  -  -  -  4d -  4  4  -  -
Win3.1          -  -  -  -  -  -  -  -  -  p
Xyplex        -  -  -  -  -  -  -  -  4  -
who        c  f  m  o  p  r  t  w  z  ?

c --> Cygnus Support /Steve Wilson 415/322-3811 [e-mail]
f --> FTP Software  /Kristine Kilduff 617/246-0900 [e-mail]
m --> MIT release
o --> Open Computing Security Group  /Michael Evans 206/883-8721
p --> Project Pilgrim  /Art Gaylord 413/545-2420 [e-mail]
r --> Cisco Routers & Bridges
t --> TGV  /S. Vance 800/tgv-3440 [e-mail]
w --> Wollengong (sp)
x --> Xyplex (terminal server)
z --> Product for one OEM/self

Rumored ports by:
  Gradient Technologies
  Transarc - makes DCE developers kits
  Security Dynamics ?

(11)    What is the export status of Kerberos?

There is a tremendous amount of confusion on this topic.

In general, the COCOM treaty, signed by twenty or so countries
including the United States, says that all cryptographic material will
be treated as munitions.  This means that these countries treat
exporting DES the same way they would treat exporting weapons, fighter
planes, and other nasty stuff.  You cannot export such materials to
any other country without an export license.

However, it *is* possible to get an export license for Kerberos (DEC
apparently has one for ULTRIX) provided it is hacked up in the correct
way.  The correct way appears to include making it impossible to
perform encryption on arbitrary user data; authentication is okay, but
secrecy is not.  Since the Kerberos API provides this functionality,
it must be carefully removed before an export license will be granted.

Of course, I am not a lawyer; this information is merely a collection
of what others (who are also not lawyers) have said and should not be
interpreted as legal advice.  If anyone out there has firm legal
advice, feel free to contribute it.

(12)    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.

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.

(13)    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.

Kerberos V5's admin tools have a simple delete request.

(14)    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.

(15)    Are there Kerberos versions of telnet and ftpd?

A Kerberos telnet is available via anonymous ftp from ftp.uu.net, in
/networking/telnet.91.03.25.tar.Z.  There is also a Kerberos telnet in
the V5 distribution which is based on the 4.4BSD telnet/telnetd.

A distributable Kerberos version of ftpd does not appear to exist.

(16)    Why doesn't KRB5-types.h exist when I build version 5?

There's a bug in Sun's imake/cpp setup, so the Makefile that is
generated in lib/asn.1 is broken.  KRB5-types.h is generated by the
ISODE program pepsy; look in the makefile just before pepsy is called.
It's fairly obvious where a tab character is missing.

----------------------------------------------------------------------

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.  Usenix
paper "Kerberos: An Authentication Service for Open Network Systems",
3/30/88.  [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," Computer Communications Review 20(5), pp.
119-132 (October 1990).  [research.att.com:dist/kerblimit.usenix.ps]

[7] Refik Molva, Gene Tsudik, Els Van Herreweghen, and Stefano Zatti,
"KryptoKnight Authentication and Key Distribution System."
[jerico.esc.edu:pub/gene/kryptoknight.ps.Z]