Партнёры:
Хостинг:
Archive-name: kerberos-faq/general
Posting-Frequency: monthly
URL: http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html
Copyright: (c) 2000 United States Government as represented by the
Secretary of the Navy. All rights reserved.
Table of Contents:
* 0. Introduction
* 1. General information about Kerberos
o 1.1. What is Kerberos?
o 1.2. Where does the name "Kerberos" come from?
o 1.3. Hey! I remember my Greek mythology, and I thought the dog
that guarded the entrance was called Cerberus! What gives?
o 1.4. Where can I find out more information about Kerberos?
o 1.5. What is the latest version of Kerberos available from MIT?
o 1.6. Are there any other free version of Kerberos available?
o 1.7. What are the differences between Kerberos Version 4 and
Version 5?
o 1.8. What are the differences between AFS Kerberos and "normal"
Kerberos?
o 1.9. What is the format of principals?
o 1.10. How are realms named? Do they really have to be uppercase?
o 1.11. What is ASN.1?
o 1.12. I see the acronyms TGT and TGS used a lot. What do they
mean?
o 1.13. What is the export status of Kerberos?
o 1.14. What is a "Kerberos client", "Kerberos server", and
"application server"?
o 1.15. I use software package <foo>, and it claims it supports
Kerberos. What does that mean?
o 1.16. What is cross-realm authentication?
o 1.17. Are there security risks involved in cross-realm
authentication?
o 1.18. Are there any known weaknesses in Kerberos?
o 1.19. What is preauthentication?
o 1.20. Why do I need to synchronize my system clocks to run
Kerberos?
o 1.21. What computer vendors support Kerberos?
o 1.22. Can I use Kerberos 4 clients with Kerberos 5? How about the
reverse?
o 1.23. What is a "key salt"? "kvno"?
o 1.24. Does Kerberos support multi-homed machines?
o 1.25. What is "user to user" authentication?
o 1.26. What are forwardable tickets?
o 1.27. What are renewable tickets?
o 1.28. What are postdatable tickets?
o 1.29. What are the advantages/disadvantages of Kerberos vs. SSL?
o 1.30. What are proxiable tickets?
* 2. Administration questions
o 2.1. Okay, I'm the administrator of a site, and I'd like to run
Kerberos. What do I need to do?
o 2.2. What sort of resources do I need to dedicate to a KDC?
o 2.3. What programs/files need to go on each application server?
o 2.4. What programs/files need to go on each client?
o 2.5. There's a lot of stuff in the krb5.conf and kdc.conf files.
What does it all mean, and what do I really need?
o 2.6. How do I change the master key?
o 2.7. How do I set up slave servers?
o 2.8. What do I need to do to make V4 clients work with my V5 KDC?
o 2.9. I just added a host key to a machine with ktadd, and the kvno
got incremented! What just happened?
o 2.10. How do I run kadmin from a shell script unattended?
o 2.11. I can't use kadmin to talk to the admin server of another
realm. What am I doing wrong?
o 2.12. We run AFS at our site currently. Is there a way we can run
Kerberos along with AFS?
o 2.13. Employee <X> just left the company, and he had root on our
KDC. What should I do?
o 2.14. How should I configure my DNS for Kerberos?
o 2.15. What do I need to do to setup cross-realm authentication?
o 2.16. Can I configure the admin server to reject bad passwords?
o 2.17. Is there a hook I can use to do further password checking?
o 2.18. How come the "Last xxx" fields in the Kerberos database
don't seem to get updated?
o 2.19. What does krb524d do? Do I need to run it?
o 2.20. What is v5passwdd? Do I need to run it?
o 2.21. How do a rename a principal?
o 2.22. What is the difference between the "-a valid" and the "-a
user" flags for telnetd?
o 2.23. I already have a standard Unix password database for my user
population. Can I convert this to a Kerberos password database?
o 2.24. Can I have multiple realms on a single KDC?
o 2.25. What is the kadm5.acl file?
* 3. User and application questions
o 3.1. What happens when my tickets expire?
o 3.2. How do I run a cron job with Kerberos authentication?
o 3.3. How do I use renewable tickets?
o 3.4. What is the .k5login file, and how do I use it?
o 3.5. I've hear Microsoft will support Kerberos in Windows 2000. Is
that true?
o 3.6. How can I be authenticated as two different principals at the
same time?
o 3.7. How come Kerberos rlogin works to a machine, but when I use
Kerberos telnet I'm still asked for a password?
o 3.8. How do I use Kerberos telnet/rlogin to connect to a system as
a userid other than my current one?
o 3.9. Is there any way to do Kerberos authentication across the
WWW?
o 3.10. Is there a way to use Kerberos to authenticate my X windows
connections? I tried compiling the Kerberos support in X, but it
didn't work.
o 3.11. I need to use Kerberos through a firewall. What does my
firewall administrator need to do?
* 4. Error messages and other problems.
o 4.1. "No such file or directory"
o 4.2. "Decrypt integrity check failed"
o 4.3. "Cannot find/read stored master key"
o 4.4. "Incorrect net address"
o 4.5. "Initial Ticket response appears to be Version 4 error"
o 4.6. "Message stream modified"
o 4.7. "Illegal cross-realm ticket"
o 4.8. "Couldn't authenticate to server: Bad sendauth version was
sent"
o 4.9. When I try using Kerberos ftp, it doesn't work, but it says,
"No error".
o 4.10. When I telnet from a Linux machine to a Solaris machine with
Kerberos and hit Ctrl-C, the connection hangs.
* 5. Programming with Kerberos.
o 5.1. How do I start programming with Kerberos?
o 5.2. What is GSSAPI?
o 5.3. What is SASL?
o 5.4. Is there a reference for the Kerberos API?
------------------------------------------------------------
Subject: 0. Introduction
Welcome to the Kerberos FAQ! The intent of this document is to answer many
of the recurring questions that appear on the [email protected] mailing list,
as well as the comp.protocols.kerberos newsgroup. It is also intended to
serve as a repository of information for people who want to know more about
the Kerberos authentication system.
In general, this FAQ deals with the freely available MIT releases of
Kerberos. If a question deals specifically with another implementation of
Kerberos, then it will be explicitly mentioned.
Questions and comments should be directed to the FAQ maintainer, Ken
Hornstein, <[email protected]>.
------------------------------------------------------------
Subject: 1. General information about Kerberos
------------------------------------------------------------
Subject: 1.1 What is Kerberos?
From <http://web.mit.edu/kerberos/www/>
Kerberos is a network authentication protocol. It is designed to
provide strong authentication for client/server applications by
using secret-key cryptography. A free implementation of this
protocol is available from the Massachusetts Institute of
Technology. Kerberos is available in many commercial products as
well.
The Internet is an insecure place. Many of the protocols used in
the Internet do not provide any security. Tools to "sniff"
passwords off of the network are in common use by systems
crackers. Thus, applications which send an unencrypted password
over the network are extremely vulnerable. Worse yet, other
client/server applications rely on the client program to be
"honest" about the identity of the user who is using it. Other
applications rely on the client to restrict its activities to
those which it is allowed to do, with no other enforcement by the
server.
Some sites attempt to use firewalls to solve their network
security problems. Unfortunately, firewalls assume that "the bad
guys" are on the outside, which is often a very bad assumption.
Most of the really damaging incidents of computer crime are
carried out by insiders. Firewalls also have a significant
disadvantage in that they restrict how your users can use the
Internet. (After all, firewalls are simply a less extreme example
of the dictum that there is nothing more secure then a computer
which is not connected to the network --- and powered off!) In
many places, these restrictions are simply unrealistic and
unacceptable.
Kerberos was created by MIT as a solution to these network
security problems. The Kerberos protocol uses strong cryptography
so that a client can prove its identity to a server (and vice
versa) across an insecure network connection. After a client and
server have used Kerberos to prove their identity, they can also
encrypt all of their communications to assure privacy and data
integrity as they go about their business.
Kerberos is freely available from MIT, under a copyright
permission notice very similar to the one used for the BSD
operating and X11 Windowing system. MIT provides Kerberos in
source form, so that anyone who wishes to use it may look over the
code for themselves and assure themselves that the code is
trustworthy. In addition, for those who prefer to rely on a
professional supported product, Kerberos is available as a product
from many different vendors.
In summary, Kerberos is a solution to your network security
problems. It provides the tools of authentication and strong
cryptography over the network to help you secure your information
systems across your entire enterprise. We hope you find Kerberos
as useful as it has been to us. At MIT, Kerberos has been
invaluable to our Information/Technology architecture.
------------------------------------------------------------
Subject: 1.2. Where does the name "Kerberos" come from?
The name Kerberos comes from Greek mythology; it is the three-headed dog
that guarded the entrance to Hades.
------------------------------------------------------------
Subject: 1.3. Hey! I remember my Greek mythology, and I thought the dog that
guarded the entrance was called Cerberus! What gives?
I personally wonder about this myself. I have seen references in "The
Devil's Dictionary" that claim it is Kerberos, but when I checked this
myself I only found the "Cerberus" variant.
I never actually heard of the "Kerberos" spelling/pronunciation until I got
involved with Kerberos myself.
From: Tom Yu <[email protected]>
"Cerberus" is the Latin spelling of the Greek "Kerberos", and
according to the OED is pronounced like "serberus", but that is
quite at odds with the Greek, as the initial consonant is a "k".
MIT Project Athena chose to use the Greek spelling and
pronunciation.
From: Jan Sacharuk <[email protected]>
Tom Yu is correct, Cerberus is the Latin spelling. However, the
fact that the OED says that the 'c' is pronounced as an 's' is an
English affectation. In Latin, the letter 'c' is always hard. So
Cerberus is pronounced 'Ker-ber-ous'. The letter 'u' is also
slightly different, making it somewhere in between 'oos' and
'ous'.
From: Michael A. Covington <[email protected]>
"Kerberos" is the original Greek name. In Latin, the letter K is
not normally used, and in Roman times, C always represented the K
sound. Also, "-os" is a Greek suffix (nominative masculine
singular) whose nearest equivalent in Latin is the suffix "-us"
(very familiar in Latin names). That's why the name goes into
Latin as Cerberus.
(See, a Ph.D. in linguistics is good for something! :)
------------------------------------------------------------
Subject: 1.4. Where can I find out more information about Kerberos?
If you're new to Kerberos, I would suggest you read:
* Bill Bryant, "Designing an Authentication System: A Dialogue in Four
Scenes."
<http://web.mit.edu/kerberos/www/dialogue.html>
A cute explanation of Kerberos protocol, in plain English. Technobabble
is kept to a minimum.
* Jeffrey I. Schiller, "Secure Distributed Computing", Scientific
American, November 1994, pp 72-76.
An excellent overview that covers all of the important details of the
Kerberos protocol. It also explains how it's used at MIT as a "real
world" example. This article could be useful in persuading manager
droids that Kerberos is a good thing.
* J. G. Steiner, B. Clifford Neuman, and J.I. Schiller, "Kerberos: An
Authentication Service for Open Network Systems".
<ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS>
The original paper describing Kerberos. A good general overview. It
describes the encryption notation used by many other Kerberos papers,
so it is definitely worth reading if you want to read other Kerberos
papers.
* Brian Tung, "The Moron's Guide to Kerberos"
<http://www.isi.edu/~brian/security/kerberos.html>
Despite the title, goes into a fair amount of detail. I would suggest
reading this after you have read one or more of the higher-level
papers.
The MIT Kerberos web page <http://web.mit.edu/kerberos/www/> has many links
pointing to Kerberos resources.
One of the best tutorials for Kerberos is Jim Rowe's, "How To Kerberize Your
Site", which is available at:
* <http://www.y12.doe.gov/~jar/HowToKerb.html>
There is an RFC for Kerberos 5: RFC 1510, which is available at:
<http://www.ietf.org/rfc/rfc1510.txt>
But it is a rather difficult read unless you already know a lot about how
Kerberos works.
------------------------------------------------------------
Subject: 1.5. What is the latest version of Kerberos available from MIT?
The latest version of Kerberos 4 from MIT is patchlevel 10. You can get it
by reading <ftp://athena-dist.mit.edu/pub/kerberos/README.KRB4> and
following the directions in that file.
Kerberos 4 is officially considered "dead" by MIT; all current development
is concentrated on Kerberos 5.
The latest version of Kerberos 5 is 1.2.1. You can get it from the following
location:
http
Go to the Kerberos web page <http://web.mit.edu/kerberos/www/>, select
the link marked, "Release 1.2", and from there, select "Retrieving".
Note that only U.S. & Canadian citizens can legally download Kerberos from
MIT. However, Kerberos 5 is available for ftp from:
<ftp://ftp.ox.ac.uk/pub/comp/security/software/Kerberos5>
I have no idea if it is legal for non-US residents to download Kerberos from
this ftp site.
------------------------------------------------------------
Subject: 1.6. Are there any other free version of Kerberos available?
Cygnus Solutions has announced the release of KerbNet 1.2. This is based on
the MIT 1.0pl1 release, but with a number of enhancements. You can find out
more information about KerbNet at <http://www.cygnus.com/technie/kerbnet/>.
The Center for Parallel Computers at the Royal Institute of Technology in
Stockholm, Sweden have a version of eBones (Bones with crypto calls added
back in). This is a version of Kerberos 4 that is exportable to other
countries (assuming that your country allows you to import cryptographic
software). It is available at
<ftp://ftp.pdc.kth.se/pub/krb>.
A web page for KTH krb4 is available at:
* <http://www.pdc.kth.se/kth-krb>
There is also work at the Center for Parallel Computers to create a freely
available version of Kerberos 5 called Heimdal. Mailing lists to discuss
Heimdal are are available at:
* <[email protected]> - low-volume announcement only, moderated
* <[email protected]> - high-volume discussion
Send email to <[email protected]> to subscribe to either one of these
mailing lists.
A web page for heimdal is also available at:
<http://www.pdc.kth.se/heimdal/>
As of this writing, the latest release is 0.03a.
------------------------------------------------------------
Subject: 1.7. What are the differences between Kerberos Version 4 and
Version 5?
The paper "The Evolution of the Kerberos Authentication System" is a very
good description of the limitations of Kerberos 4 and what changes were made
in Kerberos 5. This paper is available from
<ftp://athena-dist.mit.edu/pub/kerberos/doc/krb_evol.PS>.
However, here is a quick list of the more important changes:
* The key salt algorithm has been changed to use the entire principal
name.
* The network protocol has been completely redone and now uses ASN.1
encoding everywhere.
* There is now support for forwardable, renewable, and postdatable
tickets.
* Kerberos tickets can now contain multiple IP addresses and addresses
for different types of networking protocols.
* A generic crypto interface module is now used, so other encryption
algorithms beside DES can be used.
* There is now support for replay caches, so authenticators are not
vulnerable to replay.
* There is support for transitive cross-realm authentication.
------------------------------------------------------------
Subject: 1.8. What are the differences between AFS Kerberos and "normal"
Kerberos?
The Kerberos used in AFS (formerly known as the Andrew File System) was
developed from the Kerberos 4 papers, but before the protocol was
formalized.
As a result, AFS Kerberos uses the RX protocol for all communication between
the clients and database servers (which function as KDCs in Kerberos
termology)
The standard AFS clients that perform authentication discard the TGT after
they acquire an AFS service ticket. This means that you can't get tickets
for other services using your AFS token.
It is possible to use regular Kerberos instead of AFS Kerberos. For more
information, see Question 2.12.
------------------------------------------------------------
Subject: 1.9. What is the format of principals?
In Kerberos 4, a principal was divided into three parts:
1. The principal name
2. An optional instance
3. The Kerberos realm
Kerberos 4 principals are written in the following format:
name.instance@realm
Kerberos 5 principals are written in a slightly different format:
component/component/component@realm
The terms "name" and "instance" are still used for the first and the second
components respectively.
Note that in both Kerberos 4 and Kerberos 5, the way that principals are
encoded into strings have nothing to do with the way they are stored
internally in Kerberos.
There is an established convention as to how principals are named.
Generally, you will encounter three different types of principals.
1. A principal without an instance. This is used for users, with the
username being used as the principal name. Some examples:
[email protected]
[email protected]
2. A principal with a hostname for an instance. This is used to
distinguish between the same service on different machines. Some
examples:
host/[email protected]
ftp/[email protected]
3. A principal with a unique instance that is not a hostname. For these
principals the instance has other significance.
krbtgt/[email protected]
krbtgt/[email protected]
While the specification for Kerberos 5 allows more than two components, in
practice this is not used.
The two most important differences between Kerberos 4 principals and
Kerberos 5 principals are:
1. The instance separator in Kerberos 4 is a period (.) where in Kerberos
5 the instance separator is a forward slash (/).
2. In principals where the hostname is used as the instance, the "short"
hostname (without a domain name) is used as the instance for Kerberos
4. In Kerberos 5, the fully qualified domain name is used as the
instance.
------------------------------------------------------------
Subject: 1.10. How are realms named? Do they really have to be uppercase?
In theory, the realm name is arbitrary. You can call your realm whatever you
want.
However, in practice a Kerberos realm is named by uppercasing the DNS domain
name associated with the hosts in the to-be named realm. In other words, if
your hosts are all in the foo.org domain, you might call your Kerberos realm
FOO.ORG.
If you wish to have more than one Kerberos realm associated with the same
DNS domain name, the convention is to create realms that are in the same
hierarchy of your DNS domain name. For example, if you wish to have two
Kerberos realms in the DNS domain foo.org for Human Resources and Sales, you
might create the Kerberos realms HR.FOO.ORG and SALES.FOO.ORG.
The convention to use uppercase for realms names arose out of the desire to
easily distinguish between DNS domain names (which are actually
case-insensitive) and Kerberos realms. The Kerberos realm name is case
sensitive (the realm foo.org is different than the realm FOO.ORG). You are
not required to have an uppercase Kerberos realm, but I would strongly
advise it.
It is worth noting that the recent revisions to the Kerberos standard have
specified that uppercase realm names are preferred and lowercase realm names
have been depreciated.
------------------------------------------------------------
Subject: 1.11. What is ASN.1?
ASN.1 is short for Abstract Syntax Notation One. It is a notation for
describing abstract types and values. Using ASN.1, one can describe the
format of complex objects by putting together more simpler types.
However, ASN.1 does not specify how these objects are encoded into strings
of ones and zeros. For that, you must use a set of encoding rules. The two
most common encoding rules are the Basic Encoding Rules (BER) and the
Distinguished Encoding Rules (DER). The only difference between BER and DER
is that there are multiple ways to encode objects in the BER, but the DER is
a subset of the BER such that there is only one possible way to encode each
object.
Kerberos 5 uses ASN.1 and the DER to encode and decode all of the Kerberos
protocol messages. Unless you are planning on adding to the Kerberos
protocol itself, you don't really need to worry about ASN.1 at all.
If you wish to learn more about ASN.1, I would suggest reading:
* Burton S. Kaliski Jr., "A Layman's Guide to a Subset of ASN.1, BER, and
DER"
<ftp://ftp.rsa.com/pub/pkcs/ps/layman.ps>
* Brian Tung, "ASN.1: Wherefore Art Thou?"
<http://www.isi.edu/~brian/security/asn1.html>
------------------------------------------------------------
Subject: 1.12. I see the acronyms TGT and TGS used a lot. What do they mean?
TGT is the acronym for a "Ticket Granting Ticket".
TGS is the acronym for the "Ticket Granting Service".
While it may seen that the two acronyms are used interchangeably, they refer
to two very different things. The Ticket Granting Ticket is a Kerberos
ticket for the Ticket Granting Service. Both play a special role in
Kerberos.
When a user first authenticates to Kerberos, he talks to the Authentication
Service on the KDC to get a Ticket Granting Ticket. This ticket is encrypted
with the user's password.
When the user wants to talk to a Kerberized service, he uses the Ticket
Granting Ticket to talk to the Ticket Granting Service (which also runs on
the KDC). The Ticket Granting Service verifies the user's identity using the
Ticket Granting Ticket and issues a ticket for the desired service.
The reason the Ticket Granting Ticket exists is so a user doesn't have to
enter in their password every time they wish to connect to a Kerberized
service or keep a copy of their password around. If the Ticket Granting
Ticket is compromised, an attacker can only masquerade as a user until the
ticket expires.
The documentation in Question 1.4 explains all of this in further detail.
------------------------------------------------------------
Subject: 1.13. What is the export status of Kerberos?
This is a topic of much discussion, and it appears that there is no clear
answer. Your best bet is to contact a lawyer for a definitive answer. But if
you're willing to listen to "educated guesses", read on.
The recent US Government relaxation of export controls has caused much
discussion on this topic. The current belief is that under the new
regulations, Kerberos source code can be exported everywhere, except for the
so-called "T7" countries (countries that are defined by the US State
Department as being terrorist countries).
The definitive source for the exact regulations is the Bureau of Export
Administration, and their web site is at:
<http://www.bxa.doc.gov/Encryption/>
Specifically, if you look at the Encryption License Exemption Chart,
<http://www.bxa.doc.gov/Encryption/lechart1.htm>
you can see that under "Unrestricted, encryption source code (open source
code)" that the only restriction is to not knowingly export to T7 countries.
The official response from MIT with respect to the export status of Kerberos
5 is that they have contacted their legal staff, and they have not yet given
them an answer.
However, Question 1.5 does list a non-US ftp site for Kerberos 5. The
legality of downloading Kerberos from this site is unknown.
------------------------------------------------------------
Subject: 1.14. What is a "Kerberos client", "Kerberos server", and
"application server"?
In Kerberos, all authentication takes place between clients and servers. So
in Kerberos termology, a "Kerberos client" is any entity that gets a service
ticket for a Kerberos service. A client is typically a user, but any
principal can be a client (unless for some reason the administrator has
explicitly forbidden this principal to be a client).
The term "Kerberos server" generally refers to the Key Distribution Center,
or the KDC for short. The KDC implements the Authentication Service (AS) and
the Ticket Granting Service (TGS). The KDC has a copy of every password
associated with every principal. For this reason, it is absolutely vital
that the KDC be as secure as possible.
Most KDC implementations store the principals in a database, so you may hear
the term "Kerberos database" applied to the KDC.
For reliability purposes, it is possible to have backup KDCs. These are
referred to as slave servers. The slaves all synchronize their databases
from the master KDC.
In most Kerberos implementations there is also an administration server
which allows remote manipulation of the Kerberos database. This
administration server usually runs on the KDC.
The term "application server" generally refers to Kerberized programs that
clients communicate with using Kerberos tickets for authentication. For
example, the Kerberos telnet daemon (telnetd) is an example of an
application server.
------------------------------------------------------------
Subject: 1.15. I use software package <foo>, and it claims it supports
Kerberos. What does that mean?
Unfortunately, "supporting Kerberos" can mean a number of things.
The most basic level of Kerberos support is verifying a plaintext password
against the Kerberos database. Depending on the application, this may or may
not be secure. For example, since the Unix xlock application is designed to
verify passwords and (hopefully) is only run from on your local workstation,
verifying passwords against a Kerberos database is perfectly adequate.
However, if you have a POP server that verifies the PASS command by checking
the password against a Kerberos database, that is NOT secure, because the
password will travel over the network in the clear.
There are different levels of password verification, however. Unless a
program that does plaintext password verification uses the acquired TGT to
get a service ticket for a locally trusted service (that is, with the key in
a keytab on local disk), then an attacker can spoof the client with a TGT
encrypted in a known password.
The next level of Kerberos support is a "true" Kerberized application that
uses Kerberos tickets to verify identity and/or encrypt data. This is the
way that Kerberos was designed to function, and it provides the highest
level of security that Kerberos has to offer. Unfortunately, relatively few
applications support Kerberos to this degree.
If you use an application that claims to support Kerberos, you should find
out exactly what this means and determine if that is appropriate for your
environment. If you use Kerberos primarily as a single-signon system, then
having a POP server that verifies plaintext passwords against a Kerberos
database may be acceptable to you.
All of the Unix replacement commands that come with the MIT Kerberos
distributions (telnet, ftp, rlogin, rsh, etc), are "true" Kerberized
applications.
------------------------------------------------------------
Subject: 1.16. What is cross-realm authentication?
Any Kerberos principal can authenticate to other principals within the same
Kerberos realm. However, it is also possible to configure a Kerberos realm
so principals in one realm can authenticate to principals in another realm.
This is called cross-realm authentication.
The way this is implemented is the KDCs in the two realms share a special
cross-realm secret, and this secret is used to prove the identity of
principals when crossing the boundary between realms.
Kerberos 5 supports an additional variant of this called transitive
cross-realm authentication. In traditional cross-realm authentication, each
pair of realms that wish to authenticate need to share a cross-realm secret.
This means in a group of N realms, 2 * ((N - 1) ** 2) secrets will need to
be exchanged in order to cover all possible cross-realm authentication
paths.
In transitive cross-realm authentication you can define a path of realms
connected via cross-realm secrets and use this path to "hop" between realms
until you get credentials in the desired realm.
Information on configuring cross-realm authentication can be found in the
answer to Question 2.15
------------------------------------------------------------
Subject: 1.17. Are there security risks involved in cross-realm
authentication?
When you set up a cross-realm secret, you are in essence trusting the remote
KDC to only issue cross-realm tickets for the correct users. If you do not
trust the foreign KDC then all principals from the foreign realm are
suspect.
However, a realm which you share a cross-realm secret with cannot acquire a
ticket for a user in your local realm; a foreign KDC can only cause tickets
to be issued that identify users from the foreign realm (in other words,
there's no way a KDC can cause a ticket to be generated for a principal in a
realm other than it's own).
All of the daemons that come with the MIT Kerberos 5 release do not trust
principals in foreign realms by default; you have to explicitly enable them
using ACLs. So as long as foreign-realm principals are not on any ACLs in
your realm, there isn't a risk.
If you do decide to place foreign-realm principals on ACLs, you will have to
remember that the security of that principal depends on the security of the
foreign realm.
------------------------------------------------------------
Subject: 1.18. Are there any known weaknesses in Kerberos?
Kerberos makes no provisions for host security; it assumes that it is
running on trusted hosts with an untrusted network. If your host security is
compromised, then Kerberos is compromised as well.
However, the degree to which Kerberos is compromised depends on the host
that is compromised. If an attacker breaks into a multi-user machine and
steals all of the tickets stored on that machine, he can impersonate the
users who have tickets stored on that machine .... but only until those
tickets expire.
Kerberos uses a principal's password (encryption key) as the fundamental
proof of identity. If a user's Kerberos password is stolen by an attacker,
then the attacker can impersonate that user with impunity.
Since the KDC holds all of the passwords for all of the principals in a
realm, if host security on the KDC is compromised, then the entire realm is
compromised.
In Kerberos 4, authenticators are valid for 5 minutes. If an attacker sniffs
the network for authenticators, they have a 5 minute window in which they
can re-use it and gain access to the same service you used. Kerberos 5
introduced a replay cache which prevents any authenticator from being used
more than once.
Since anybody can request a TGT for any user, and that ticket is encrypted
with the user's secret key (password), it is simple to perform a offline
attack on this ticket by trying to decrypt it with different passwords.
Kerberos 5 introduced preauthentication to solve this problem.
A excellent critique of Kerberos is:
* S. M. Bellovin and M. Merritt. "Limitations of the Kerberos
Authentication System"
<ftp://research.att.com/dist/internet_security/kerblimit.usenix.ps>
It was written for Kerberos 4, but has an appendix which also covers
Kerberos 5.
------------------------------------------------------------
Subject: 1.19. What is preauthentication?
As mentioned in Question 1.18, one weakness in Kerberos is the ability to do
an offline dictionary attack by requested a TGT for a user and just trying
different passwords until you find one that decrypts the TGT successfully.
One way of preventing this particular attack is to do what is known as
preauthentication. This means to simply require some additional
authentication before the KDC will issue you a TGT.
The simplest form of preauthentication is known as PA-ENC-TIMESTAMP. This is
simply the current timestamp encrypted with the user's key.
There are various other types of preauthentication, but not all versions of
Kerberos 5 support them all.
------------------------------------------------------------
Subject: 1.20. Why do I need to synchronize my system clocks to run
Kerberos?
The actual verification of a client's identity is done by validating an
authenticator. The authenticator contains the client's identity and a
timestamp.
To insure that the authenticator is up-to-date and is not an old one that
has been captured by an attacker, the timestamp in the authenticator is
checked against the current time. If the timestamp is not close enough to
the current time (typically within five minutes) then the authenticator is
rejected as invalid. Thus, Kerberos requires your system clocks to be
loosely synchronized (the default is 5 minutes, but it can be adjusted in
Version 5 to be whatever you want).
The paper:
* Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks
Adrift: History, Protocols, and Implementation"
<http://world.std.com/~dtd/synch/synch.ps>
explains a way for Kerberos principals to securely determine the time
without having to rely on a external time source. This is implemented for
clients only in the Kerberos 5 release. With this in place, clients do not
need to synchronize their system clocks to use Kerberos; however,
application servers need to.
Note that it is possible to use the above technique for application servers
as well as clients; it is just not currently implemented that way.
------------------------------------------------------------
Subject: 1.21. What vendors support Kerberos?
Please note that this is by no means a definitive list; I am only listing
the ones that I know about. Corrections to this list are especially welcome.
A number of software vendors sell versions of Kerberos, or provide support
for Kerberos:
* CyberSafe sells and supports Kerberos 4 and Kerberos 5 with their
TrustBroker product. In additional to normal Kerberos passwords,
TrustBroker also supports the use of PKINIT authentication using public
key certificates.
You can find out more information from <http://www.cybersafe.com>.
* WRQ Inc. supports Kerberos on Win32 platforms with their Reflection
Secure and Reflection Signature products. This includes a telnet client
that does Kerberos 5 authentication and a graphical FTP client which
supports Kerberos 5 (GSSAPI) authentication, data integrity, and
privacy.
You can find out more information from <http://www.wrq.com>.
* Hummingbird Communications Ltd. supports Kerberos on Win32 platforms
with their HostExplorer product. This includes a telnet client that
does Kerberos 4 authentication and encryption.
You can find out more information from <http://www.hummingbird.com>.
* Columbia University's Kermit Project supports Kerberos 4 and Kerberos 5
in Kermit 95 for Windows 95/98/NT and in C-Kermit for Unix. Kermit's
scripting language can be used to automate a variety of ticket
management tasks. Kerberos authentication and DES encryption applies to
telnet connections.
The Internet Kermit Service daemon (C-Kermit 7.0) supports Kerberos for
automated client authentication.
For further information see <http://www.kermit-project.org/>.
In additional to independent vendors, a number of computer vendors have
integrated Kerberos into some of their products:
* Sun ships a basic set of Kerberos 4 utilities with Solaris (kinit,
klist, kdestroy), and the RPC that comes with Solaris supports a
Kerberos 4 authentication mechanism.
Sun has also announced a complete Kerberos 5 product that will also act
as a Microsoft KDC. This product is available world-wide with 56 bit
DES with no key recovery/escrow requirements.
For the press release on this product announcement, see
<http://www.sun.com/smi/Press/sunflash/9907/sunflash.990719.1.html>.
For more specific documentation, please see
<http://docs.sun.com:80/ab2/coll.384.1/@Ab2CollView>.
* Cisco routers support Kerberos 5 authentication for incoming and
outgoing telnet connections. It was broken for a very long time, but I
have heard reports that it's fixed now. However, ticket forwarding (as
of last report) is still broken.
* Microsoft has stated that they will support some version of Kerberos 5
in Windows 2000.
------------------------------------------------------------
Subject: 1.22. Can I use Kerberos 4 clients with Kerberos 5? How about the
reverse?
The MIT Kerberos 5 release can speak the Kerberos 4 protocol, assuming it
was built with the --with-krb4 option (which is the default). So with a
little work (see Question 2.8) you should be able to use all Kerberos 4
programs with your Kerberos 5 KDC and application servers.
However, since the protocol is so different, there is really no way to make
Kerberos 5 clients work with Kerberos 4 application servers and KDCs.
------------------------------------------------------------
Subject: 1.23. What is a "key salt"? "kvno"?
To understand a key salt, it's important to remember that in Kerberos you
prove your identity by being able to decrypt or encrypt data using an
encryption key that you share with the KDC.
However, a 56-bit DES key is hard for humans to remember. So, whenever a
person enters in their "Kerberos password", it is really converted to a
encryption key by a function called string2key(). This function converts the
plaintext password via a one-way hash algorithm to an encryption key. In
Kerberos 4 this is always a DES key. In Kerberos 5 it could be a key for
algorithms other than DES (but currently DES is still the most widely used
algorithm in Kerberos 5).
The string2key() function takes an optional argument called the key salt.
This is an additional input to the one-way hash algorithm. If a salt is
supplied, it is concatenated to the plaintext password and the resulting
string is converted using the one-way hash algorithm.
In Kerberos 4, a salt was never used. The password was the only input to the
one-way hash function. This has a serious disadvantage; if a user happens to
use the same password in two Kerberos realms, a key compromise in one realm
would result in a key compromise in the other realm.
In Kerberos 5 the complete principal name (including the realm) is used as
the salt. This means that the same password will not result in the same
encryption key in different realms or with two different principals in the
same realm.
AFS uses a different string2key algorithm than Kerberos 4 and Kerberos 5,
and uses the Kerberos realm name (not the cell name) as the key salt.
The MIT Kerberos 5 KDC stores the key salt algorithm along with the
principal name, and that is passed back to the client as part of the
authentication exchange. This means that if you convert your Kerberos
database from Kerberos 4 to Kerberos 5, Kerberos 5 clients can use the
correct string2key algorithm to convert your password to the matching
encryption key. The same is true with AFS, and the AFS-Kerberos 5 migration
kit comes with tools to let you do this (see Question 2.12 for more
information).
It's worth pointing out that this is only an issue for the cases when you
need to convert a plaintext password to an encryption key. Programs that
deal directly with encryption keys (such as application servers) never deal
with plaintext passwords, and as a result this is not an issue with them.
The term "kvno" is simply an acronym for "Key version number". To help
distinguish between multiple keys associated with the same principal (for
example, if a user changes his password), each key is assigned a key version
number. Key version numbers typically start at zero when the principal is
first created and are incremented by one every time the password/encryption
key is changed.
------------------------------------------------------------
Subject: 1.24. Does Kerberos support multi-homed machines?
In both Kerberos 4 and Kerberos 5, a machine's network address is part of
the ticket information. This address is used as an additional check to make
sure the ticket hasn't been stolen and is being used on another machine.
In Kerberos 4, there was room for only one IP address in the ticket, which
did not work with multihomed machines. KTH krb4 includes some hacks to make
it work with Kerberos 4.
Kerberos 5 supports multiple IP addresses in a ticket, thus allowing
Kerberos 5 tickets to deal with multi-homed machines. However, doing so
requires careful configuration of your DNS server. Question 2.14 explains
this in further detail.
------------------------------------------------------------
Subject: 1.25. What is "user to user" authentication?
From: Don Davis <[email protected]>
User-to-user authentication is a special Kerberos application
protocol, that allows users to host secure application services on
their desktop machines. It is increasingly common for users to
offer desktop services that merit secure authentication, such as
nfs and ftp. When users configure their desktop servers with a
long-lived srvtab key, this long-lived key becomes a very
attractive target for theft. User-to-user authentication enables a
user to run a server without keeping a long-lived key on disk.
Instead, the user's short-lived TGS session-key takes the place of
the usual srvtab secret key, in the server's authentication
handshakes.
Authentication in Kerberos happens between a client and server.
The client gets a ticket for a service, and the server decrypts
this ticket using its secret key. This works fine for a
physically- secure server, which keeps its secret key on its local
disk. But, storing the server's key on disk doesn't work for
services that run on users' desktop machines, since no-one should
keep a long-lived secret key on an insecure disk drive.
The solution to this problem is called user-to-user
authentication, and it is implemented in Kerberos 5. In the
user-to-user protocol, one user acts as a server, and the other
user acts as a client. at the client-user's request, the
server-user sends his TGT (but not his session key) to the
client-user, who then gets credentials from the KDC, encrypted
with the session keys of both TGTs. Both users can decrypt the new
session-key and use it to verify each other's identity. The
advantage of the U2U scheme is that the server-user exposes only
his short-lived TGS session-key to theft; he keeps his long-lived
secret, his password, in his biological memory. An attacker is
less likely to bother to steal a short-lived server-key. However,
U2U's downside is that the desktop server cannot operate
autonomously; the service-operator has to refresh his TGT in order
for the server to keep accepting clients' requests.
Applications have to handle user-to-user authentication as a
special case; Kerberos 5 does not offer an API that hides the
difference between desktop servers and physically-secure servers.
For this reason, very few services currently support the
user-to-user protocol. The user-to-user protocol was originally
designed for authenticating X-windows sessions, where the server
usually runs on an insecure desktop machine. See Question 3.10 for
more information on this.
The motivation and theory behind user to user authentication is described in
the paper:
* Don Davis, Ralph Swick, "Workstation Services and Kerberos
Authentication at Project Athena"
<ftp://athena-dist.mit.edu/pub/ATHENA/kerberos/doc/user2user.ps>
------------------------------------------------------------
Subject: 1.26. What are forwardable tickets?
Inside of the Kerberos ticket is encoded the IP address of the client. This
is used by application servers and the KDC to verify the address of the
client. This means that a ticket that was acquired on one host cannot be
used on another.
Kerberos 5 introduced the concept of forwardable tickets. During the initial
TGT acquisition, a client can request that the ticket be marked forwardable.
If the KDC chooses to honor this request (the administrator has the option
of disallowing forwardable tickets on a per-site or per-principal basis),
the TKT_FLG_FORWARDABLE flag will be set in the flags field in the ticket.
Once the TKT_FLG_FORWARDABLE flag is set on a ticket, the user can use this
ticket to request a new ticket, but with a different IP address. Thus, a
user can use their current credentials to get credentials valid on another
machine.
In the MIT Kerberos 5 release, all of the remote login programs (telnet,
rlogin, rsh) support forwarding a user's TGT to the remote system.
------------------------------------------------------------
Subject: 1.27. What are renewable tickets?
One practical problem with Kerberos is that the tickets eventually expire. A
practical balance has to be made between the desire to reduce the usefulness
of stolen tickets (short lifetime) versus the ease-of-use for the user (long
lifetime).
This problem becomes a much larger issue when dealing with long-running user
processes. Jobs run on some supercomputer systems can run for days or weeks,
but having tickets that last that long can be a security nightmare.
The compromise for this problem that was introduced in Kerberos 5 is the
support for renewable tickets. Renewable tickets have expiration times, like
normal tickets. However, they also have a maximum renewable lifetime.
A renewable ticket can be renewed by asking the KDC for a new ticket with an
extended lifetime. However, the ticket itself has to be valid (in other
words, you cannot renew a ticket that has expired; you have to renew it
before it expires). A renewable ticket can be renewed up until the maximum
renewable ticket lifetime.
This scheme has two important advantages over long-lived tickets:
1. It reduces the window of usefulness for stolen tickets. If an attacker
gets access to a renewable ticket after it has expired, then it is
useless.
2. After a user is finished with a renewable ticket, he can notify the KDC
that he no longer needs the ticket, and the KDC will refuse to renew
this ticket any more (note that although this is in the protocol, I
don't think any version of Kerberos actually implements this part).
------------------------------------------------------------
Subject: 1.28. What are postdatable tickets?
Normally, a ticket is valid starting from the time you request it until it
expires.
However, there may be some cases where a user would like a ticket that is
valid some time in the future. For example, a user may wish to run a batch
job next week, but your maximum ticket lifetime is only one day.
To accommodate this need, Kerberos 5 introduced postdatable tickets. These
are tickets which are initially invalid, and have a starting time some time
in the future.
To use a postdatable ticket, the user must send it back to the KDC to have
it validated during the ticket's valid lifetime.
------------------------------------------------------------
Subject: 1.29. What are the advantages/disadvantages of Kerberos vs. SSL?
From: Jonathan Kamens <[email protected]>
In brief, the question seems to be, "What does Kerberos give me
that SSL doesn't?"
That question is specific case of the general question, "What are
the advantages and disadvantages of a private-key,
trusted-third-party authentication system vs. a public-key,
certificate-based authentication system?"
As I see it, SSL has two major advantages over Kerberos: (1) It
doesn't require an accessible trusted third party; (2) it can be
used to establish a secure connection even when one end of the
connection doesn't have a "secret" (a.k.a. "key" or "password").
These two advantages make it ideal for secured Web communication
and for similar applications where there is a large user base
which is not known in advance.
[ Here are some disadvantages of SSL: ]
1) Key revocation. If a Verisign certificate issued to a user is
compromised and must be revoked, how will all the servers with
whom that user interacts know that the certificate is no longer
valid? Either revocation certificates have to be circulated to all
relevant servers and cached for a long time, or servers have to
verify incoming user certificates against a "revocation server."
In that case, the revocation server must be a highly available
third party, which means you've eliminated one of the two major
advantages of SSL over Kerberos. Kerberos principals can be
disabled at will on the KDC and will then become unusable as soon
as any cached tickets expire, on the order of hours, without any
action by servers.
2) Key security. If I'm issued a Verisign certificate, it has to
live on my hard disk. Yes, it may be encrypted there such that I
have to unlock it with a password before I can use it, but it's
still on the hard disk and therefore vulnerable to cracking
attacks. On the other hand, I don't need any sort of certificate
to authenticate to Kerberos -- all I need is my password, which is
in my brain, not on a hard disk.
3) Cost of use. Kerberos doesn't infringe on any patents. Which
means that it can be used for free, while SSL users may have to
pay.
4) Open standards. Kerberos has been free from the beginning. The
standards documenting it are open and have been developed openly
from the start. On the other hand, SSL was developed by a company
with a commercial interest in ensuring that its standards become
THE standard. Let's just say that Netscape is not exactly known
for "playing by the rules" when it comes to developing Internet
standards.
5) Flexibility. I'm under the impression, although I may be wrong
(if so, I hope someone will correct me), that Kerberos is somewhat
more flexible than SSL. For example, if I want to add a new
authentication technology to Kerberos (e.g., a new kind of
SmartCard with its own algorithm), all I have to do is modify my
KDC and my ticket-acquiring client to know how to do the new
authentication. Then, it can be used to get Kerberos tickets which
will look the same as any other Kerberos tickets and will be
usable with any Kerberos-capable application. On the other hand,
if I want to implement a new authentication technology for SSL, I
believe I'd have to get new versions of all my SSL-capable
applications.
I'm probably forgetting some advantages and disadvantages of
Kerberos and SSL, but my object here isn't to be comprehensive. My
point is that there are applications for which SSL is superior to
Kerberos and vice versa.
Another good reference for comparing public-key cryptography to symmetric
key systems like Kerberos can be found at:
* Don Davis, "Compliance Defects in Public-Key Cryptography"
<http://world.std.com/~dtd/compliance/compliance.ps>
------------------------------------------------------------
Subject: 1.30. What are proxiable tickets?
As discussed in Question 1.26, Kerberos tickets contain the IP addresses of
hosts they are to be used on.
In addition to forwardable tickets, Kerberos 5 introduce the concept of
proxiable tickets. A proxiable ticket is a ticket (generally only a TGT)
that allows you to get a ticket for a service with IP addresses other than
the ones in the TGT.
This is different than forwardable tickets in that you cannot proxy a new
TGT from your current TGT; you can only proxy non-TGT service tickets. In
other words, forwardable tickets let you transfer your complete identity
(TGT) to another machine, where proxy tickets only let you transfer
particular tickets.
In general practice, proxiable tickets are not used that often.
------------------------------------------------------------
Subject: 2. Administration questions
------------------------------------------------------------
Subject: 2.1. Okay, I'm the administrator of a site, and I'd like to run
Kerberos. What do I need to do?
An excellent question!
Please note that this information applies to the MIT Kerberos 5 release. If
you're using one of the commercial versions of Kerberos, then you should
consult the documentation that came with it.
First, you should read at least some of the documentation in Question 1.4.
You will find that administrating Kerberos is much easier once you
understand the fundamentals.
Once you feel you understand the basics, you should download the software
from MIT. You can get it from any of the places listed in Question 1.5. Note
that Kerberos is usually distributed as three tar files containing the src,
doc, and crypto directories; you'll want to download all three tar files.
The doc directory contains three important files that you'll want to read:
the Kerberos installation guide, the Kerberos administration guide, and the
Kerberos user's guide. The first one you'll need to read is the installation
guide.
After you have everything downloaded, you should compile the Kerberos
distribution. If you don't have the space or would rather not, binary
snapshots of Kerberos are available from the Kerberos web site mentioned in
Question 1.5 for some of the more popular versions of Unix.
If you're compiling Kerberos yourself, the installation guide explains how
to do it, and lists most of the options you can give to configure program.
Unless you have special needs the defaults are usually sufficient.
Building the MIT Kerberos 5 distribution requires GNU make. I have not had
success with any vendor's make.
Once Kerberos is built, you should follow the instructions in the install
guide for Chapter 4: "Installing Kerberos 5".
Unfortunately, it is difficult to give specific directions on how to deploy
Kerberos at your site, since every site is different. The deployment of
Kerberos at your site may have political issues that are beyond the scope of
this FAQ :-).
A fair amount of practical advice can be found at:
* <http://www.y12.doe.gov/~jar/HowToKerb.html>
------------------------------------------------------------
Subject: 2.2. What sort of resources do I need to dedicate to a KDC?
You will need a dedicated machine to run the KDC on. The database stored on
this machine is quite sensitive, if it's compromised your entire realm will
be compromised. Therefore, this machine needs to be as secure as possible.
Preferably it should not run any services other than the KDC. The
secure-minded administrator might only allow logins on the console.
This machine also has to be reliable. If it is down, you will not be able to
use any Kerberized services unless you have also configured a slave server.
Running the Kerberos server requires very little CPU power and a small
amount of disk. An old PC with some hundreds of megabytes of free disk space
should do fine. Most of the disk space will be used for various logs.
Because the KDC has all of the keys for all of the principals in your realm,
loss of the Kerberos database would require your entire realm to be rekeyed.
Thus, backing up your Kerberos database is critical. However, precisely
because the database contains all of your keys, you should treat backups of
the KDC with the same security that you treat the KDC itself (in other
words, don't leave the dump tapes lying around on your desk).
------------------------------------------------------------
Subject: 2.3. What programs/files need to go on each application server?
As a MINIMUM, on each application server, you'll need to put:
* A Kerberos configuration file (/etc/krb5.conf).
* The Kerberos application server daemons (telnetd, rlogind, ftpd, etc).
* At least one encryption key (usually stored in /etc/krb5.keytab).
The encryption key is really the critical part; it needs to be transmitted
to the application server host in a secure fashion. This is typically the
key for the host principal (host/foo.bar.org@REALM). Note that the MIT admin
client kadmin encrypts all of the transfers between it and the admin server,
so using ktadd from inside of kadmin is safe, provided that you're not
sending your admin password over the network in the clear.
You'll probably want to put the Kerberos client binaries on each application
server as well, if you plan on having interactive user logins on your
application servers.
------------------------------------------------------------
Subject: 2.4. What programs/files need to go on each client?
The bare minimum:
* A configuration file (usually /etc/krb5.conf, but with MIT Kerberos you
can set the environment variable KRB5_CONFIG to point to the location
of the configuration file).
* The Kerberos client binaries. At a minimum, you would need:
o kinit
o kdestroy
o klist
o telnet
And whatever other client programs your users would use (rlogin, ftp).
As a data point, our Kerberos client kits we distribute to our user
community contain the following files:
* krb5.conf
* kinit
* kdestroy
* klist
* kpasswd
* telnet
* rcp
* rlogin
* rsh
* ftp
------------------------------------------------------------
Subject: 2.5. There's a lot of stuff in the krb5.conf and kdc.conf files.
What does it all mean, and what do I really need?
For krb5.conf, there are six different stanzas used:
[libdefaults]
Various configuration parameters used by the Kerberos library. The
krb5.conf man page lists all of the available parameters. Ones you
should take special note of are:
default_realm
The default Kerberos realm. THIS IS REQUIRED!
default_keytab_name
The default keytab used by application servers. In pre-1.0
releases of Kerberos 5, the default was /etc/v5srvtab, but
starting with 1.0 it is now /etc/krb5.keytab. This field could be
used to ease the transition from a pre-1.0 installation to an
up-to-date version of Kerberos 5.
ccache_type
This sets the credential cache type used by Kerberos. The default
credential cache type is 3.
Credential cache type 1 is also understood by DCE 1.0.3a systems,
and credential cache type 2 is also understood by DCE 1.1 systems.
If you wish to have interoperability with DCE, you may want to set
this value.
If you wish to use the kdc_timesync feature, you will need to set
this value to 4, as this is the credential cache type that
supports header tags, which are used by the clock skew correction
code.
kdc_timesync
Setting this variable to 1 enables Kerberos clients to
automatically correct for a difference between the local clock and
the clock used by the KDC. Note that you will need to set
ccache_type to a value of 4 to use this feature.
[login]
This configures the behavior of login.krb5. The man page for login.krb5
explains these in more detail.
[realms]
This section lists all of the Kerberos realms known to this client. If
a realm is not listed in this section, than it cannot be accessed by
the client that is using this configuration file.
Configuration variables of note used in this section are:
default_domain
This lists the default domain used to convert V4 instances (which
were not fully qualified host names) to V5 instances (which are
fully qualified).
When converting a principal name from Kerberos 4 to Kerberos 5,
the default_domain is appended to the instance. When converting
from Kerberos 5 to Kerberos 4, it is removed.
v4_instance_convert
This is used to configure exceptions to the default_domain mapping
rule. In this subsection is a list of V4 instance names and their
V5 equivalents.
Note that neither of these two variables are required if you're not
planning on using the Kerberos 4 compatibility of Kerberos 5. Question
2.8 explains the use of these two variables in more detail.
[domain_realm]
This section defines the mapping from hostnames to Kerberos realms.
When using host-based services, a Kerberos client needs to know the
Kerberos realm that the service lives in so it can contact the proper
KDC (and optionally request cross-realm tickets if necessary). This is
determined by the rules found in the domain_realm section.
If you're only using one Kerberos realm, and your realm is the
uppercase version of your domain name, then you don't need a
domain_realm section.
One point about the [domain_realm] stanza that confuses a lot of people
is whether or not to use a leading period when referring to domains
(most people put both just to be safe). For example:
[domain_realm]
foo.bar.org = FOO.BAR.ORG
.foo.bar.org = FOO.BAR.ORG
The rules are very simple. Anything with a leading period matches all
hosts in that domain. So the entry for .foo.bar.org matches all hosts
in the foo.bar.org domain. Entries without a leading period only match
that specific host. So in this case, the entry for foo.bar.org only
matches the host foo.bar.org.
An important side note is that domain wildcard entries do not match a
host who's name is the name of your domain. In other words, the entry
for .foo.bar.org doesn't match a host called foo.bar.org.
If this is too confusing, remember these simple rules:
1. You almost always need an entry for your domain with a leading
period.
2. You only need an entry without a leading period if you have a host
named the same as your domain name (in other words, your domain is
foo.bar.org, and you have a host called foo.bar.org).
[logging]
This section describes the way different Kerberos programs perform
logging. Currently this is only used by the KDC and the admin servers,
so this section is only required on on your master and slave Kerberos
servers.
[capaths]
This section defines a set of valid authentication paths when doing
transitive cross-realm authentication. The use of this section is
explained further in Question 2.15.
A bare minimum krb5.conf will need to contain a default_realm entry and a
[realms] section describing your default realm. For example:
[libdefaults]
default_realm = FOO.BAR
[realms]
FOO.BAR = {
kdc = kdc1.foo.bar
kdc = kdc2.foo.bar
admin_server = kdc1.foo.bar
}
If your realm name is different than your domain name, then you'll need an
appropriate mapping entry under [domain_realm].
[libdefaults]
default_realm = TEST.BAR
[realms]
TEST.BAR = {
kdc = kdc1.foo.bar
kdc = kdc2.foo.bar
admin_server = kdc1.foo.bar
}
[domain_realm]
.foo.bar = TEST.BAR
The kdc.conf uses the same format. The man page describes all of the
sections and variables used. The critical ones are:
max_life
This is the maximum lifetime for all tickets issued from this KDC. The
default is 10 hours. If you wish to increase the ticket lifetime, you
will need to increase this variable (in addition to increasing the
lifetime of the principals in the database).
supported_keytypes
This lists all of the key/salt combinations that will be created for
new principals or principals that change their password. This is
important if you wish to support Kerberos 4 or AFS clients.
Since it is impossible to change a key from one salt type to another, I
always advise people to configure in support for V4 salted keys when
they first set up their realm, since it may require users to change
their passwords if you find out you need V4 compatibility at a later
date (depending on what sort of V4 compatibility you need). Question
2.8 has more information on the subject of configuring V4
compatibility.
A minimal kdc.conf would be:
[realms]
FOO.BAR = {
supported_keytypes = des:normal
}
If you wanted to support V4 and AFS salted keys, you might have:
[realms]
FOO.BAR = {
supported_keytypes = des:normal des-cbc-crc:v4 des-cbc-crc:afs3
}
------------------------------------------------------------
Subject: 2.6. How do I change the master key?
In Kerberos 5 .. you don't :-)
It is possible for you to change the master key using the kadmin. However,
the master key is also probably stored in a stash file (depending on your
site) and is used to encrypt all of the entries in the database. If you
change the master key with kadmin, you won't change it in the stash file or
reencrypt all of the entries in the database.
Note that there are no technical obstacles in doing this; Kerberos 4
provided a command to change the master key, and it did all of the right
things. However, no one has implemented this functionality (yet) for
Kerberos 5.
------------------------------------------------------------
Subject: 2.7. How do I set up slave servers?
Setting up a slave KDC is fairly simple. Here are the steps you need to
perform:
1. Create host principals for your master and slave KDCs. These will look
like host/[email protected], or something similar.
2. In the Kerberos database directory (/usr/krb5/lib/krb5kdc using the
default configuration) on both your masters and slaves, create a file
called kpropd.acl and place in it all of the host principals for your
KDCs.
For example, if you had three KDCs, kdc1.foo.bar, kdc2.foo.bar, and
kdc3.foo.bar, this file would contain:
host/[email protected]
host/[email protected]
host/[email protected]
3. On your slave KDCs, add an entry for kpropd in inetd.conf. A sample
entry would look like:
krb5_prop stream tcp nowait root /usr/krb5/sbin/kpropd kpropd
4. On the master KDC, dump the database into a file using kdb5_util.
Depending on where you told Kerberos to live, a sample command would
look like:
/usr/krb5/sbin/kdb5_util dump /usr/krb5/lib/krb5kdc/slave_datatrans
5. Run kprop on the master to propagate the database to each slave:
/usr/krb5/sbin/kprop -f /usr/krb5/lib/krb5kdc/slave_datatrans kdc2.foo.bar
/usr/krb5/sbin/kprop -f /usr/krb5/lib/krb5kdc/slave_datatrans kdc3.foo.bar
Once you have this working, you probably want to write a script to propagate
the database at regular intervals. Here is the one that I use:
#!/bin/sh
#
kdclist="kdc1.foo.bar kdc2.foo.bar"
/usr/krb5/sbin/kdb5_util dump /var/krb5/krb5kdc/slave_datatrans
for kdc in $kdclist
do
/usr/krb5/sbin/kprop $kdc > /dev/null
done
The most common error people get when setting up their KDC is the extremely
confusing "Decrypt integrity check failed". This means that the host keys
stored in the KDC don't match the keys stored in the corresponding keytabs
(I bet you recreated the database a couple of times while you were playing
around with the KDC, didn't you?). Installing new host keys on the master
and the slaves will fix this problem.
------------------------------------------------------------
Subject: 2.8. What do I need to do to make V4 clients work with my V5 KDC?
First off, it's important to understand the issues involved.
The main differences between V4 and V5 (for the purpose of this discussion)
are:
1. The network protocol used is very different.
2. The string-to-key algorithm is different.
3. The format of the encrypted tickets is very different.
The MIT V5 KDC can speak the V4 protocol as well as the V5 protocol, so
difference number 1 isn't a big problem.
The MIT V5 KDC also supports the V4 string-to-key algorithm, and will use
this to encrypt tickets when it gets V4 requests. If you read Question 2.5,
then you already have your KDC set up to support this before you started
adding users :-).
The MIT distribution also included a special daemon called krb524d. This can
be used to convert an encrypted Kerberos 5 ticket into an encrypted Kerberos
4 ticket.
A number of the MIT application servers (telnetd, rlogind, rshd) support V4
clients as well as V5.
So, all of the pieces are there ... now, how do you use them?
If your application needs to get a Kerberos 4 TGT, then you need to
configure your KDC to support Kerberos 4 salted keys. You can tell if your
application needs to get a V4 TGT if you have to give it a Kerberos password
at some point.
If your application needs to get V4 service tickets, then you have the
option of using krb524init to convert your V5 TGT into a V4 TGT, and then
your application can use the V4 TGT to acquire V4 service tickets. Question
2.19 explains more about krb524init and krb524d.
If you can modify your application, then you can change it so it converts a
V5 service ticket into a V4 service ticket internally. This is the approach
used by the aklog program in the AFS-Kerberos 5 migration kit. Question 2.12
explains this in greater detail.
If you want to support a V4 application server, you need to create a V4
format keytab containing the principal used by the application server. You
can do this by using ktutil to convert a V5 format keytab into the
corresponding V4 keytab.
If you simply wish to support incoming Kerberos 4 telnet or rlogin, then all
you need to do is configure the daemons to support V4 connections. This is
done by an additional flag in inetd.conf for the Berkeley r-commands. The V4
compatibility routines can read a Kerberos 5 keytab, so there's no need to
copy it over.
There is a bug in telnetd that prevents it from talking correctly to V4
clients; to work around it, you simply need to create an empty /etc/srvtab.
There is one more important point when dealing with V4 clients. You should
never create V4 format principals in your KDC; you should use the V5 names.
For example, you shouldn't create rcmd.foo; you should instead always use
host/foo.bar.org
The KDC automatically converts back and forth between V4 and V5 principal
names at the appropriate times. This is trivial for user principals, but is
trickier for host-based principals. Since the instance was the "short" name
in V4 and is now fully qualified in V5, rules have to be configured to
convert between V4 and V5 instances. This is done via the default_domain and
the v4_instance_convert lines in krb5.conf.
The default_domain variable is used to indicate the DNS domain name that is
removed or added when converting between V4 and V5 principals. For example,
if you have:
[realms]
FOO.BAR.ORG = {
kdc = kdc1.foo.bar.org
default_domain = foo.bar.org
}
Then the V5 principal host/sun1.foo.bar.org will be converted to the V4
principal rcmd/sun1.
The v4_instance_convert variable is used to configure exceptions to the
default mapping rule. For example, let's say the above realm has a host
called foo.bar.org. Under V4 the host principal for this machine would be
called rcmd/foo, but the default_domain rule would fail to convert this
principal name correctly. However, if we place the following in in our
krb5.conf:
v4_instance_convert = {
foo = foo.bar.org
}
Then the instance will be converted correctly.
Since all of these name translations take place on the KDC, you generally
only need to make sure the krb5.conf files on the KDC are the ones that are
up-to-date (but it's a good idea to keep the configuration file consistent
across machines).
------------------------------------------------------------
Subject: 2.9. I just added a host key to a machine with ktadd, and the kvno
got incremented! What just happened?
The protocol that kadmin uses has no way of extracting a key from the
database. That was a deliberate design decision; it prevents a compromised
admin account from being able to read out all of the keys from the database.
However, there is a way to create a new random key and return this key to
the client program. This is used by the ktadd command of kadmin to get a new
key to add to a keytab. A new random key is created for the principal, and
as a result, the kvno gets incremented (just like when a user changes their
password). The returned random key then gets added to the keytab.
This has a couple of noteworthy side effects. You can't use ktadd to add the
same key to more than one host, because the key will be changed on the
second host you add it to. Also, since you'll be creating a new key, tickets
created with the old key will no longer be valid. You can work around this
by saving the old key in the keytab, but if you're regenerating a key
because the previous one didn't match the one in the KDC, you will need to
have your users acquire new service tickets (by running kinit or the
equivalent) before they will get tickets encrypted with the new key.
------------------------------------------------------------
Subject: 2.10. How do I run kadmin from a shell script unattended?
To do this, it's important to understand that to authenticate to Kerberos,
one of two things has to happen:
1. A human has to enter in a secret at some point.
2. A secret has to be stored somewhere on a computer.
You can play some funny games with either of these two things, but it
basically boils down to #1 or #2.
Now, to truly run kadmin unattended, you need to store the secret key of a
privileged user somewhere on the computer that will run kadmin. That means
that if the system is ever compromised, the attacker could gain access to
this secret key and use it to do nasty things to your Kerberos database. You
need to decide if you want to open yourself up to this risk.
That being said .... here's how you do it.
1. Create the admin principal you wish to use.
2. Put the key for the admin principal somewhere on your machine.
3. Use kinit to acquire a Kerberos ticket for the principal from the
keytab, and run kadmin with the -q to perform whatever tasks you wish.
Here's an example of a shell script that does this.
#!/bin/sh
#
PATH=$PATH:/path/to/kerberos; export PATH
KRB5CCNAME=/tmp/krb5cc_root_$$; export KRB5CCNAME
trap kdestroy 0 1 2 3 5 15
kinit -S kadmin/admin -k -t /path/to/keytab admin_principal
kadmin -c $KRB5CCNAME -q "delprinc foo"
exit 0
------------------------------------------------------------
Subject: 2.11. I can't use kadmin to talk to the admin server of another
realm. What am I doing wrong?
Even though you can specify an alternate realm to kadmin with the -r option,
it doesn't change the default realm for the admin principal. You need to
specify the complete admin principal (including the realm!) with the -p
option:
kadmin -r BAR.ORG -p user/[email protected]
------------------------------------------------------------
Subject: 2.12. We run AFS at our site currently. Is there a way we can run
Kerberos along with AFS?
Yes! You should get the AFS-Kerberos 5 Migration Kit. It comes with all of
the tools and documentation you should need. And since it was developed by
the FAQ author, you can be sure it was done by someone who claims they know
what they're talking about.
The latest version of the AFS-Kerberos 5 Migration Kit is 1.2, and includes
patches for Kerberos 1.0.5. You can get it from:
ftp
<ftp://ftp.cmf.nrl.navy.mil/pub/kerberos5/afs-krb5-1.2.tar.Z>
afs
<file:///afs/transarc.com/public/afs-contrib/tools/afs-krb5-1.2.tar.Z>
However, if you'd rather not run Kerberos 5, the AFS kaserver already
implements a perfectly adequate Kerberos 4 KDC. In addition to that,
Transarc provides drop-in replacements for the klog, pagsh, and tokens
commands which are Kerberos 4 aware, and retain the Kerberos TGT after
authentication has completed.
------------------------------------------------------------
Subject: 2.13. Employee <X> just left the company, and he had root on our
KDC. What should I do?
If a person had root on your KDC, then they had the ability to grab a copy
of your entire Kerberos database. While the database is encrypted with the
master key, a root user could have read the master key out of the stash
file, or even attached a debugger to the KDC process to read the master key
out of the KDC's memory.
So, this now becomes a question of what to do when every key in your
database is compromised.
When a user's key is compromised, the attacker can impersonate that user.
If a host key is compromised, then an attacker could generate forged service
tickets for that host with any user in the ticket.
However, the worst key to get compromised is the krbtgt key, as an attacker
could use this to generate a valid TGT for any principal in your realm!
The steps you should take depend on the exact circumstances of the incident
and your local site policy. However, it's important to keep in mind that the
worst-case scenario is that your realm would need to be completely re-keyed.
If I personally was responsible for our KDC and this situation happened to
me (a person who had root on our KDC left under questionable circumstances),
I would immediately change the key for the krbtgt and the admin principals,
and force a global user password change over some period of time (assuming
we weren't expiring passwords at this point).
As a side note, a compromised master key isn't quite as bad as one would
normally fear. The master key is only used to encrypt the Kerberos database
and as a seed for the random number generator. As long as access to your KDC
is secure, an attacker can't do much with the master key.
------------------------------------------------------------
Subject: 2.14. How should I configure my DNS for Kerberos?
Your DNS should be configured so that gethostbyname() and gethostbyaddr()(or
your operating system equivalent) returns the fully qualified domain name
for a host.
Now, this is technically NOT true. The "real" answer is that you can do it
either way, as long as you're consistent. When MIT Kerberos figures out
service principal names, it calls:
gethostbyaddr(gethostbyname(host))
So if you have your name service configured to return "short" names, then as
long as you use the short name in the instance of the service principal,
then everything will be fine.
That being said .... YOU DO NOT WANT TO DO THIS!
First and foremost, it will break people who are not in your domain who try
to use your Kerberized services. It will also undo the very wise change from
the way instances were handled in Kerberos 4.
Trust me when I say that configuring your name service the "right" way will
be better in the long run.
Unfortunately, things are less clear when multi-homed hosts are involved.
The issue of multi-homed hosts is a large one; very few things deal with
multi-homed hosts well, and there are a number of schools of thought on how
multi-homed hosts should be treated.
This FAQ does not claim to address the issue of multi-homed hosts. It does,
however, try to explain the issues involved with multi-homed hosts and
Kerberos, and the FAQ author does make a "recommendation" as to the way you
should configure your DNS. Take it with the appropriate grain of salt :-)
I have seen two basic schools of thought when it comes to dealing with
multi-homed hosts:
1. Treat the host as a bunch of different single-homed machines, all of
which happen to magically share the same hardware (the "one name per
interface" scheme).
2. Treat the host as a single machine, with a bunch of network interface
cards (the "multiple address records per machine" scheme).
Both of these approaches have their advantages and disadvantages. I
personally recommends the second approach ("multiple address records per
machine"), as I feel it is closer to reality. Also, the Host Requirements
RFC (RFC 1123) says:
2.3 Applications on Multihomed hosts
When the remote host is multihomed, the name-to-address
translation will return a list of alternative IP addresses. As
specified in Section 6.1.3.4, this list should be in order of
decreasing preference. Application protocol implementations SHOULD
be prepared to try multiple addresses from the list until success
is obtained. More specific requirements for SMTP are given in
Section 5.3.4.
However, RFC 1122 does admit:
Multihoming introduces considerable confusion and complexity into
the protocol suite, and it is an area in which the Internet
architecture falls seriously short of solving all problems.
Regardless of the way you configure your host name resolution, it's critical
to understand the issues involved.
When connecting to a Kerberized host, the service instance used is derived
from the fully qualified host name. If there is one host key but multiple
canonical names per host, connections to the interfaces who's names do not
match the name of the host used in the Kerberos instance will fail.
If that was too confusing, here's an example:
We have a host called foo.bar.org, that's in the BAR.ORG realm. It has one
host key, host/[email protected], and three interfaces:
foo.bar.org IN A 1.2.3.4
foo-fddi.bar.org IN A 1.2.4.4
foo-en.bar.org IN A 1.2.5.4
If I say "telnet foo.bar.org" (using my Kerberized telnet), everything works
fine. But if I try connecting to foo-en.bar.org, then this will fail,
because there is no such principal called host/[email protected].
You can create multiple keys per host, but that won't solve all of your
problems either. Some Kerberized application servers will only accept
principals for services who's instance is the FQDN of the local hostname.
ftpd is an example of one such application server (in the above example, for
our host called "foo", this means that ftpd would only accept principals
with the instance of foo.bar.org).
There is considerable debate about whether or not application servers should
accept any valid service key, or only ones that match their canonical name.
However, in the case of ftpd, RFC 2228 is quite clear that ftpd is doing the
right thing according to the FTP Security Specification.
Another issue with multihomed hosts is the issue of credential forwarding.
When credentials are forwarded to a remote machine, the IP address(es) of
the remote machine are placed in the ticket. When you go to use this ticket,
the KDC verifies the addresses in the ticket against the source address of
the request.
There is currently no way for Kerberos to know all of a machine's interfaces
when using the "one name per interface" scheme. So when you forward
credentials to a multihomed machine using this configuration, you must make
sure that the address you place in the ticket is the IP address that the
remote machine will use to talk to the KDC (and if you're using cross-realm,
you have to make sure it's the same interface to all KDCs).
Both of these issues go away when using the "multiple address records per
host" scheme. However, you can use this setup and have the ability to refer
to different interfaces. Here's an example DNS setup:
my.host.name. A 1.2.3.4
A 1.2.4.4
A 1.2.5.4
my-en0.host.name. A 1.2.3.4
my-en1.host.name. A 1.2.4.4
my-en2.host.name. A 1.2.5.4
4.3.2.1 PTR my.host.name.
4.4.2.1 PTR my.host.name.
4.5.2.1 PTR my.host.name.
In summary, you can make both ways work. The FAQ author recommends using
"multiple address records per host", but you can do things the other way if
you're careful.
One final note: if you're using NIS instead of DNS for hostname resolution,
you will find that you cannot use the "multiple address records per host"
setup, because of the way NIS works (it's a key-value map, and silently
strips out all but one address record). This holds true even if you're using
DNS to hold your zone information and you've configured NIS to fall back to
DNS!
------------------------------------------------------------
Subject: 2.15. What do I need to do to setup cross-realm authentication?
The simplest case is having two realms cross-realm authenticate with each
other. To do this, you need to create two special cross-realm principals on
each KDC:
* krbtgt/REALM2@REALM1
* krbtgt/REALM1@REALM2
The keys of the corresponding principals have to match on the two KDCs, but
the different cross-realm principals don't have to have matching keys. In
other words, krbtgt/REALM2@REALM1 has to have the same key on each KDC, but
krbtgt/REALM2@REALM1 and krbtgt/REALM1@REALM2 don't have to match.
Another important point is that the corresponding kvnos have to match up as
well.
When clients want to connect to a server in another realm, they will use
their current TGT to get a cross-realm TGT from the local KDC. They will
then use that cross-realm TGT to request service tickets from the foreign
KDC.
Two principals are needed for each direction of the authentication path
(REALM1 to REALM2, and vice versa). When a client in REALM1 wishes to talk
to a server in REALM2, it uses the krbtgt/REALM2@REALM1 TGT. Note that this
is different than the procedure in V4, where only one cross realm secret was
created (krbtgt.FOREIGN-REALM@LOCAL-REALM) and used for both directions.
Since each principal corresponds to the different authentication paths, if
you only want one-way cross-realm authentication you can simply only create
one of the cross-realm principals.
V5 also supports transitive cross-realm, which lets you define
authentication paths between different KDCs so you don't have to share as
many keys. The difference is O(n**2) versus O(2**n), so depending on the
number of realms you plan on working with, it can make a big difference on
the number of keys you have to manage.
There are two ways to organize your transitive cross-realm authentication
paths: hierarchical and [capaths].
Hierarchical cross-realm authentication is fairly simple. Your realms must
be organized in a hierarchy almost identical to DNS domain names, and
clients magically "know" to traverse up the realm tree to talk to neighbors.
For example, if you have the realms:
* FOO.ORG
* BAR.FOO.ORG
* BIZ.FOO.ORG
* BLAH.FOO.ORG
You would have the BAR, BIZ, and BLAH sub-realms each share a cross-realm
key with the parent FOO.ORG realm, and all of the clients and application
servers would do the right things without any extra work on your part.
One thing to be careful of is that there is an implied trust when doing
hierarchical cross-realm. If you create a new realm in the above hierarchy
called BLARGH.FOO.ORG and have it share a cross-realm key with the parent
FOO.ORG realm, then all of your realms will implicitly trust cross-realm
tickets from this realm, and that may not be what you want (depending on
your environment).
The other way to do transitive cross-realm is to use the [capaths] section
of the Kerberos configuration file. The krb5.conf man page explains the
format of this section fairly well, so I'll only cover the the concepts
here.
The [capaths] section defines a series of authentication paths to use when
doing transitive cross-realm. This is used by the clients to determine the
correct path for doing transitive cross-realm, and by the application
servers to determine that a cross-realm authentication path is actually
valid.
Since each application server verifies authentication paths using this
section, the addition of a new path to one realm does not assign any
implicit trust to the other realms. The downside is that the krb5.conf file
must be updated on every host when a new authentication path is created.
------------------------------------------------------------
Subject: 2.16. Can I configure the admin server to reject bad passwords?
Yes. In your kdc.conf file, in the [realms] section, you can set a variable
called dict_file that can point to a file containing a list of passwords
that are not permitted to be used. The kadmind man page has more
information.
------------------------------------------------------------
Subject: 2.17. Is there a hook I can use to do further password checking?
There isn't a well-defined hook, but the admin server uses the passwd_check
function in lib/kadm5/srv/server_misc.c to do it's password quality
checking. You could add your own function there.
------------------------------------------------------------
Subject: 2.18. How come the "Last xxx" fields in the Kerberos database don't
seem to get updated?
By default the support for this is not compiled into the KDC; you need to
specify the --with-kdc-kdb-update option to configure if you wish to enable
this support.
Note that this feature is marked in the Kerberos documentation as "not
regularly tested", so you should be careful if you decide to use this
option. It also doesn't work with slave servers.
------------------------------------------------------------
Subject: 2.19. What does krb524d do? Do I need to run it?
The krb524d daemon is used to convert a Kerberos 5 service ticket to a
Kerberos 4 service ticket. This is primarily used by the krb524init program
and the AFS-Kerberos 5 Migration Kit.
To use this daemon, you need to either run it on your KDC, or give it access
to the keys for the service principals who's tickets you wish to convert. It
needs access to the principals' keys because it decrypts the Kerberos 5
ticket, converts it to a Kerberos 4 ticket, and re-encrypts it. Everyone I
know of that uses krb524d runs it on their KDC.
Depending on your use of Kerberos 4, you may or may not need it. If you plan
on using krb524init or the AFS-Kerberos 5 Migration kit, then you definitely
need it.
To use krb524init, run krb524d on your KDCs and simply run krb524init after
you've acquired a V5 TGT. Your V5 TGT will be converted to a V4 TGT, which
can then be used by V4 applications.
Note that login.krb5 can be configured to convert your credentials
automatically as well. See the man page for more information.
------------------------------------------------------------
Subject: 2.20. What is v5passwdd? Do I need to run it?
The v5passwdd daemon implements the "old" Kerberos 5 password changing
protocol (before OpenVision donated their admin server).
This protocol is used by a few Kerberos 5 clients; the only ones I know of
are the MIT Win32 Kerberos client, and some Xyplex terminal servers. If you
don't have any programs that use this protocol, or you don't want people who
use those clients to be able to change their password, then you don't need
to run it.
If you do need to run it, you'll need to do the following things:
* Create a special changepw principal, of the form:
o changepw/[email protected]
Make sure this principal has the same attributes as the kadmin/changepw
principal; specificially, set the DISALLOW_TGS_REQ and
PASSWORD_CHANGING_SERVICE attributes.
* Add this principal's key to the admin keytab (see the original
installation instructions for this procedure)
* Start the v5passwdd with the following sample command line:
o v5passwdd -port 464 -T /path/to/admin/keytab
------------------------------------------------------------
Subject: 2.21. How do a rename a principal?
In Kerberos 5, you don't :-)
There currently is no way to rename a principal using the MIT V5 admin
system (even though the man page for kadmin claims otherwise).
The issue is that in Kerberos 5, the key is salted using the full principal
name, so changing the principal name would invalidate the user's password.
However, since the Kerberos database provides the ability to store an
alternate key salt, this could actually be implemented.
The current workaround is to simply delete the old principal name and create
the new principal name.
------------------------------------------------------------
Subject: 2.22. What is the difference between the "-a valid" and the "-a
user" flags for telnetd?
In the current MIT release, there is no difference due to a bug in telnetd.
Here's a patch that fixes this and makes the these flags behave according to
the man page.
Index: lib/appl/telnet/libtelnet/kerberos.c
===================================================================
--- kerberos.c 1997/06/02 21:54:38 1.1.1.1
+++ kerberos.c 1997/08/25 23:12:44 1.3
@@ -435,8 +430,15 @@
if (UserNameRequested && !kuserok(&adat, UserNameRequested)) {
strcpy(name, UserNameRequested);
return(AUTH_VALID);
- } else
+ } else {
+ /*
+ * Always copy in UserNameRequested if the authentication
+ * is valid, because the higher level routines need it.
+ */
+ if (UserNameRequested)
+ strcpy(name, UserNameRequested);
return(AUTH_USER);
+ }
}
#define BUMP(buf, len) while (*(buf)) {++(buf), --(len);}
Index: lib/appl/telnet/libtelnet/kerberos5.c
===================================================================
--- kerberos5.c 1997/12/15 18:51:31 1.1.1.2
+++ kerberos5.c 1997/12/15 19:15:50 1.4
@@ -682,8 +690,16 @@
{
strcpy(name, UserNameRequested);
return(AUTH_VALID);
- } else
+ } else {
+ /*
+ * Always copy in UserNameRequested if the authentication
+ * is valid, because the higher level routines need it.
+ */
+ if (UserNameRequested)
+ strcpy(name, UserNameRequested);
+
return(AUTH_USER);
+ }
}
#define BUMP(buf, len) while (*(buf)) {++(buf), --(len);}
------------------------------------------------------------
Subject: 2.23. I already have a standard Unix password database for my user
population. Can I convert this to a Kerberos password database?
From: Jeffrey Hutzelman <[email protected]>
It does you no good to know the contents of the password field in
/etc/passwd or /etc/shadow; to do this you would have to know the
user's actual password. Note that the entry you see in /etc/shadow
is not merely scrambled; it is the result of passing the user's
password through a one-way hash function. That is, it's easy to
compute the scrambled value from the plaintext, but very, very
hard to go the other way. If this weren't so, then any user could
look at the password field in /etc/passwd (on systems without
shadow passwords), compute the password of anyone they liked, and
then log in as that person.
The values that are actually stored in the Kerberos database are
the result of applying a different one-way hash function to the
user's password. Now, you might ask why they don't use the same
function, to make the conversion process easy. There are two
reasons for this, but they both stem from the fact that in AFS (or
Kerberos, for that matter), the output of the hash function is
used as a DES encryption key, which is used to encrypt sensitive
data passed between the user and the Kerberos server.
Rather than having users type the DES key themselves, Kerberos
uses a hash function to translate the user's password into a key
(note: See Question 1.23 for more information). This means the
user gets to remember an easy-remember word, phrase, or whatever,
and you still get a good distribution of keys. However, this
operation is done by the client (login, kinit, or whatever), not
by the Kerberos server - the user never tells the Kerberos server
his password; he merely proves that he knows it. An attacker who
knows the key but not the password used to produce it can still
authenticate just as if he were the user.
(Ed note: This isn't technically true in V5 - you do tell the
admin server your password when you change it, but that's so it
can perform password strength checking on it. But it doesn't get
stored; The Kerberos database stores keys, not passwords).
Since anyone who knows a user's key could become the user, it
would be a Bad Thing(tm) to use a predictable value for the user's
key, like the contents of the password field in /etc/passwd from
just before the conversion. Since anyone could see that file,
every user's key would essentially be publicly-known!
So, now that we know that there is no easy way to "convert" the
existing Unix passwords to something the Kerberos server can use,
you still have a problem. The usual solution is to set up a
registration mechanism, where users run some program, give it
their UNIX password, and the program verifies the password against
/etc/passwd and then registers it with the Kerberos server.
Ideally, this would be done automatically in login, so that any
user who logged in (except root!) would be converted
automatically.
The problem here is that in order to register the user's password,
your registration program (or login) must be able to authenticate
to the Kerberos server as an administrator. Or, it must be able to
authenticate to a separate registration service, which itself is
an administrator and enforces certain restrictions (i.e. a user
can only be registered once).
I have heard of sites modifying login to use the host key stored on machines
for this purpose, and giving the host principal the ability to add accounts
via the admin server (obviously, this is for Kerberos 5 only). However, no
one has made such code publically available.
------------------------------------------------------------
Subject: 2.24. Can I have multiple realms on a single KDC?
From: Christopher Misra <[email protected]>
I run a single KDC that maintains three databses all kept in
separate subdirs. I then run three kadmin processes, and just
manually configure the port to be in sync.
Here is a list of the processes as running (from ps):
.../sbin/krb5kdc -r <realm1> -r <realm2> -r <realm3>
.../sbin/kadmind -r <realm1>
.../sbin/kadmind -r <realm2> -port 748
.../sbin/kadmind -r <realm3> -port 747
Although maybe not exactly the way it should be done, it has
worked for me. Presently I only keep a slave KDC for one of the
three databases, but it should be reasonably trivial to run an
additional slave of one of the other db's.
Included below is a cleaned up version of my kdc.conf and
kpropd.acl just to be complete.
Also included below is the command line for running kprop, as I
remember it taking me the better part of a day to get it all
working.
Hope this helps. All this is, good or bad, provided without any
guarantee, etc.
--- kdc.conf:
[kdcdefaults]
[realms]
<realm1> = {
profile = /etc/krb5.conf
database_name = .../var/krb5kdc/<realm1>/principal
admin_database_name = .../var/krb5kdc/<realm1>/principal.kadm5
admin_database_lockfile = .../var/krb5kdc/<realm1>/principal.kadm5.lock
admin_keytab = .../var/krb5kdc/<realm1>/kadm5.keytab
acl_file = .../var/krb5kdc/<realm1>/kadm5.acl
dict_file = .../var/krb5kdc/kadm5.dict
key_stash_file = .../var/krb5kdc/<realm1>/.k5stash
kadmind_port = 748
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = <enc-type>
}
<realm2> = {
profile = /etc/krb5.conf
database_name = .../var/krb5kdc/<realm2>/principal
admin_database_name = .../var/krb5kdc/<realm2>/principal.kadm5
admin_database_lockfile = .../var/krb5kdc/<realm2>/principal.kadm5.lock
admin_keytab = .../var/krb5kdc/<realm2>/kadm5.keytab
acl_file = .../var/krb5kdc/<realm2>/kadm5.acl
dict_file = .../var/krb5kdc/kadm5.dict
key_stash_file = .../var/krb5kdc/<realm2>/.k5stash
kadmind_port = 749
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = <enc-type>
}
<realm3> = {
profile = /etc/krb5.conf
database_name = .../var/krb5kdc/<realm3>/principal
admin_database_name = .../var/krb5kdc/<realm3>/principal.kadm5
admin_database_lockfile = .../var/krb5kdc/<realm3>/principal.kadm5.lock
admin_keytab = .../var/krb5kdc/<realm3>/kadm5.keytab
acl_file = ...var/krb5kdc/<realm3>/kadm5.acl
dict_file = .../var/krb5kdc/kadm5.dict
key_stash_file = .../var/krb5kdc/<realm3>/.k5stash
kadmind_port = 747
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = <enc-type>
}
--- kpropd.acl
host/<master_kdc.domain>@<realm1>
host/<slave_kdc.domain>@<realm1>
--- kprop command line arguments
.../sbin/kprop -r <realm1> -f <filename> -P <port> <slave_kdc.domain>
This requires kpropd be running on the appropriate slave_kdc (I do
it from inetd, this could be argued to be bad, but oh well...)
with a -R <realm1> argument
------------------------------------------------------------
Subject: 2.25 What is the kadm5.acl file?
From: Dan E. Anderson <[email protected]>
The kadm5.acl (access control list) file resides on the KDC host
and controls access to the Kerberos database. The location of the
kadm5.acl is specified in the kdc.conf file for each realm under
the [realms] stanza:
[realms]
FOOBAR.ORG = {
acl_file = /var/krb5kdc/kadm5.acl
}
The ACL format is documented in the "Kerberos V5 Installation
Guide". It contains the principal names (including "*" as
wildcards) and the access permissions ("*" for everything)
followed by an optional principal the ACL applies (if omitted, it
applies to all principals). For example:
*/[email protected] *
Allows all admin principals all access (add, delete, modification
of principals). The following just allows adding, listing, and
inquire of principals for principal fred/admin:
fred/[email protected] ali
Of course, Fred must use the fred/admin principal to access the
Kerberos database (with kadmin).
------------------------------------------------------------
Subject: 3. User and application questions
------------------------------------------------------------
Subject: 3.1. What happens when my tickets expire?
First off, you won't be able to get tickets for new services.
What happens to the Kerberized services that you are using depends on how
they are implemented.
All implementations of telnetd, rlogind, and other remote login utilities
generally only check the ticket expiration time at login time, and don't
care about it afterwards. However, AFS will not give you access to your
files anymore, even if you already have files open.
Note, however, that this is just a matter of implementation. Someone could
write a version of telnetd that closed your connection when your ticket
expired, but I doubt that it would be very popular :-)
------------------------------------------------------------
Subject: 3.2. How do I run a cron job with Kerberos authentication?
Nothing can authenticate to Kerberos without providing a password/encryption
key. The same holds true for cron jobs.
In practice, you typically have two choices for providing Kerberos
authentication for any program:
1. A human types in a password on a keyboard.
2. A password/encryption key is stored somewhere on a machine
Obviously, both of these also apply to cron jobs. So to provide Kerberos
authentication to cron jobs, you would either have to have a human type in a
password at the appropriate time, or store the password/encryption key
somewhere where the cron job could read it.
What I (and others) have done with success is the following:
1. Create a special "cron" user (possibly username/cron).
2. Use kadmin to place a keytab for that user on the workstation where you
are going to use cron.
kadmin: ktadd -k user.keytab username/cron
3. Use the -k flag to kinit to get a TGT for that user using the stored
keytab.
kinit -k -t user.keytab username/cron
Note that this applies to any sort of unattended programs that you wish to
run, not just cron. Of course, you have to evaluate whether or not this is
acceptable to you; if the machine where you store this principal is
compromised, then this principal is compromised.
As an additional note, if you are just going to be running programs as root,
I would personally use the host principal, since it will likely already be
in place and is already used by other programs that run as root (telnetd,
ftpd, etc).
------------------------------------------------------------
Subject: 3.3. How do I use renewable tickets?
First, you have to get a renewable ticket; you can do this using the -r flag
to kinit.
Once this is done, you can renew your ticket using the -R option to kinit.
Note that you have to renew your ticket before the ticket expires.
The FAQ author has a program that will renew a ticket automatically; contact
him for details.
------------------------------------------------------------
Subject: 3.4. What is the .k5login file, and how do I use it?
The ~/.k5login (~/.klogin in the V4 world) is a list of the Kerberos
principals authorized to login to your account. It's stored in the home
directory of the user and should of course not be writable by anybody else.
This file is consulted by a lot of different programs (rlogind, rshd,
telnetd, ftpd, su, ...) to figure out if the authenticated user has the
right to do something as a particular user.
------------------------------------------------------------
Subject: 3.5. I've hear Microsoft will support Kerberos in Windows 2000. Is
that true?
This is true, but it is unclear how compatible Microsoft's version of
Kerberos will be with the standard. It is evident that some degree of
incompatibility will exist; the exact extent of that incompatibility is
unknown at this writing. What seems to be the case is that with the
proprietary ticket extension created by Micrososft KDCs, a non-Microsoft KDC
won't be able to include any group membership information in the ticket.
This may or may not impact you, depending on how critical Windows group
membership information is to your Windows infrastructure.
This article, written by Ted T'so, gives what I feel is a reasonable summary
of the situation. This originally appeared in the November 1997 NT special
edition of ;login:, and is used here with permission.
From: Ted T'so <[email protected]>
Microsoft Embraces and Extends Kerberos V5
There has been a lot of excitement generated by Microsoft's
announcement that NT 5.0 would use Kerberos. This excitement was
followed by a lot of controversy when it was announced by
Microsoft would be adding proprietary extensions to the Kerberos
V5 protocol. Exactly what and how Microsoft did and tried to do
has been a subject of some confusion; here's the scoop about what
really happened.
NT 5.0 will indeed use Kerberos. However, this protocol has been
"embraced and extended" by Microsoft, by adding a digitally signed
Privilege Attribute Certificate (PAC) to the Kerberos ticket. The
PAC will contain information about the user's 128-bit NT unique
id, as well as a list of groups to which the user belongs.
The NT PAC is unfortunately not compatible with the PAC's used by
the Open Software Foundation's Distributed Computing Environment
(DCE). It is also somewhat debatable whether the NT PAC is legal
with respect to RFC-1510, the IETF Kerberos V5 protocol
specification. The original intent of RFC-1510 prohibited what
Microsoft was trying to do, but Microsoft found what they claimed
to be a loophole in RFC-1510 specification.
Many folks, including Paul Hill and myself at MIT, as well as
Cliff Neumann at ISI, have tried to work with Microsoft to find a
more compatible way of doing what they wanted to do. To that end,
we made changes in the upcoming revision of RFC-1510 to add a
clean and compatible way of adding extensions such as Microsoft's
PAC to the Kerberos ticket.
To Microsoft's credit, they agreed to change NT 5.0 to use a
cleaner and more compatible way of adding extensions to the
Kerberos V5 ticket. They also pledged that they would make
available to us detailed technical information about the NT PAC
after the beta release of NT 5.0. This pledge was very important
to MIT and other commercial, educational, and government sites
which have an extensive deployed base of Kerberos V4 applications
(for example Transarc's AFS), as we had planned to add the ability
to generate an NT PAC to the MIT Kerberos V5 implementation, which
has backwards compatibility for Kerberos V4 applications.
Unfortunately, at the Microsoft Professional Developers Conference
(PDC) in September, Microsoft appears to be backing away from this
commitment. For the first time, Microsoft revealed that they had
chosen to implement the NT Domain Controller such that the Active
Directory Server and the Microsoft KDC ran in the same process
space, and that NT clients could not be configured to split a
Domain Controller across two machines. Thus, it would not be
useful for Microsoft to reveal their proprietary extensions to the
Kerberos protocol.
However, at the PDC, Microsoft did indicate that they had licensed
their Domain Controller to a few UNIX vendors. So it may
eventually be possible to run a Domain Controller on a non-NT
machine but there is no indication what the license may cost each
site. It is doubtful, however, whether Kerberos V4 support will be
included in those products.
Microsoft should be commended for using a mature industry standard
such as Kerberos for their authentication protocol. Kerberos has
had a long review period, and its use has been proven in many
operational environments. It seems ironic, however, that Microsoft
would choose to design and deploy their implementation with
features that are guaranteed to alienate the early adopters of
Kerberos, the very people that have helped to create and improve
the technology that Microsoft has chosen to "embrace and extend."
Microsoft has issed a number of technical reports explaining how they have
implemented Kerberos 5 and procedures for interoperating with "vanilla"
Kerberos 5. They include:
* Windows 2000 Kerberos Authentication
<http://www.microsoft.com/windows2000/library/howitworks/security/kerberos.asp>
* Windows 2000 Kerberos Interoperability
<http://www.microsoft.com/WINDOWS2000/library/howitworks/security/kerbint.asp>
* Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability
<http://www.microsoft.com/windows2000/library/planning/security/kerbsteps.asp>
Unfortunately, none of the above documents can be read on a non-Microsoft
operating system; the FAQ author notes the irony of this situation.
------------------------------------------------------------
Subject: 3.6. How can I be authenticated as two different principals at the
same time?
In most Kerberos implementations, there can only be a single principal per
credential cache (or ticket file). You can however choose which cache to use
by setting the KRB5CCNAME (in V5) and KRBTKFILE (in V4) environment
variable.
------------------------------------------------------------
Subject: 3.7. How come Kerberos rlogin works to a machine, but when I use
Kerberos telnet I'm still asked for a password?
The default for Kerberos telnet as shipped in the MIT distribution is to not
do authentication. You have to explicitly use the -a flag to request an
authenticated session.
If you are using -a and you still get a password prompt, the chances are
good that you're not talking to a Kerberos telnet daemon for some reason.
------------------------------------------------------------
Subject: 3.8. How do I use Kerberos telnet/rlogin to connect to a system as
a userid other than my current one?
Use the -l option to both telnet and rlogin to specify an alternate user
name, e.g.:
telnet -l user hostname
rlogin -l user hostname
------------------------------------------------------------
Subject: 3.9. Is there any way to do Kerberos authentication across the WWW?
There was code in some versions of NCSA httpd 1.5 and Mosaic 2.7beta to do
Kerberos authentication. Unfortunately this was non-standard and was not
carried forward into any modern software.
There are a number of ways to provide Kerberos password verification over an
SSL-protected pipe, but be aware that these schemes all are fraught with a
number of serious security problems. Nevertheless, you can find one example
of a module at:
* <http://stonecold.unity.ncsu.edu/software/mod_auth_kerb/index.html>
The CyberSafe TrustBroker SSO/Web product provides a way to do Kerberos
authentication over the web. For more information, look at:
* <http://www.cybersafe.com/solutions/trustbroker.html>
Probably the best protocol to use for this is the Kerberos Cipher Suites for
TLS, which is documented in IETF RFC 2712:
* <http://www.ietf.org/rfc/rfc2712.txt>
An open-source implementation of this, called KSSL, can be found at
SourceForge:
* <http://sourceforge.net/projects/kssl/>
------------------------------------------------------------
Subject: 3.10. Is there a way to use Kerberos to authenticate my X windows
connections? I tried compiling the Kerberos support in X, but it
didn't work.
The Kerberos support in X11R6 is written for old betas of MIT Kerberos 5. It
also only authenticates the connection startup and does not encrypt any of
the data.
Another approach to this problem is taken by the `kx' and `kxd' programs. It
allows you to have Kerberos authenticated and encrypted sessions by going
through a proxy X server. These programs are distributed as part of the KTH
krb4 distribution and V5 versions of them will be part of the Heimdal
distribution. For information about these distributions see Question 1.6.
------------------------------------------------------------
Subject: 3.11. I need to use Kerberos through a firewall. What does my
firewall administrator need to do?
From: Von Welch <[email protected]>
There are three components in the Kerberos world: the kerberos
client applications (e.g. kinit, telnet, pop), the server
applications (e.g. telnetd, popper), and the Kerberos KDC. Each
pair has different types of traffic that go between them.
Depending on the pair of components your firewall is between, you
will need to allow different types of traffic through your
firewall.
The notation 'xxxx/udp' or 'xxxx/tcp' below refers to a ephemeral
port number (>1024). This refers to a return port that is assigned
by the system. The only assumption you can make about the port
number is that it will be greater than 1024.
Between a client program and the KDC, your firewall may need to
allow traffic on the following ports/protocols:
Client Application To KDC Return traffic
Initial ticket request (i.e. kinit) 88/udp xxxx/udp
Kerberos 5-to-4 ticket conversion 4444/udp xxxx/udp
Changing password (kpasswd under unix) 749/tcp xxxx/tcp
Changing password (under windows, old
interface) 464/tcp xxxx/tcp
Changing password (under windows, new
interface) 464/udp xxxx/udp
Running kadmin (also requires initial
ticket, 88/udp) 749/tcp xxxx/tcp
Between an application server and the KDC, your firewall may need
to allow traffic on the following ports/protocols:
Application Server To KDC Return traffic
Initial ticket request (i.e. kinit) 88/udp xxxx/udp
Kerberos 5-to-4 ticket conversion 4444/udp xxxx/udp
Between an client program and an application server, your firewall
may need to allow traffic on the following ports/protocols:
Application program/server To server To client
rlogin/rlogind (w/o encryption) 543/tcp xxxx/tcp
rlogin/rlogind (w/encryption) 2105/tcp xxxx/tcp
rsh/rshd 544/tcp xxxx/tcp
pop/popper 1109/tcp xxxx/tcp
telnet/telnetd Same as non-kerberized
telnet/telnetd
ftp/ftpd Same as non-kerberized ftp/ftpd
------------------------------------------------------------
Subject: 4. Error messages and other problems
------------------------------------------------------------
Subject: 4.1. "No such file or directory"
This error is generally returned by application servers when they can't find
a keytab. Make sure you've created a keytab for the service in question.
Note that in pre-1.0 releases of Kerberos 5, the keytab was called
/etc/v5srvtab, but it got renamed to /etc/krb5.keytab for the 1.0 release.
If you're running a pre-1.0 release of Kerberos 5, you'll need to deal with
this when you upgrade.
------------------------------------------------------------
Subject: 4.2. "Decrypt integrity check failed"
This confusing looking error really means, "Password incorrect" (and in fact
it's the error that kinit looks for when it goes to print the "Password
incorrect" message). It means that the encryption key used to encrypt the
data in this message didn't match the encryption key used for decryption,
and as a result the checksum comparison didn't work.
The most common time I've seen this message is when trying to set up a slave
KDC. In this case, the two keys that don't match are the encryption keys for
the host principal that are stored in the KDC database and on the slave.
This is generally caused because the administrator was confused about the
location of host keys and put both host keys on both machines (the master
and the slave). Unfortunately, this causes problems because every use of
ktadd generated a new key (see Question 2.9 for more information). The
solution in this case is to delete the keytabs on each machine, and only add
the host principal's key to their corresponding machine; e.g., add
host/master.your.domain ONLY to your master KDC and add
host/slave.your.domain ONLY to your slave KDC.
In general, this means that the encryption key stored in a keytab doesn't
match the key stored in the KDC for a particular principal. As mentioned
above, generating a new key will fix this problem. Note that you'll need to
get rid of any old cached tickets by using kdestroy, otherwise the various
Kerberos programs will continue to use an old ticket encrypted with the
wrong encryption key.
------------------------------------------------------------
Subject: 4.3. "Cannot find/read stored master key"
This means that the program in question was unable to find the copy of the
master key that is stored in the database (this is different from the stash
file, which also holds the master key but is in a separate file).
Since this is one of the first operations that the database library does, it
is also a sort of catch-all error for problems with your Kerberos database.
------------------------------------------------------------
Subject: 4.4. "Incorrect net address"
Included in the Kerberos ticket is a list of IP addresses that this ticket
can be used on. If you try to use a Kerberos ticket from a machine who's IP
address is not listed in the ticket, you will get an "Incorrect net
address".
This mostly occurs when using multihomed machines. Question 2.14 explains
the issues associated with using multihomed machines with Kerberos in
greater detail.
------------------------------------------------------------
Subject: 4.5. "Initial Ticket response appears to be Version 4 error"
This means that the reply to a message sent to the KDC didn't make any
sense, but it seemed to bear a remarkable resemblance to a Kerberos 4 error
packet.
This means that your Kerberos 5 program is trying to talk to a Kerberos 4
KDC. While Kerberos 5 is compatible with Kerberos 4, the compatibility is
only one-way. Kerberos 4 clients can talk to an appropriately configured
Kerberos 5 KDC, but Kerberos 5 clients cannot talk to a Kerberos 4 KDC.
------------------------------------------------------------
Subject: 4.6. "Message stream modified"
This is returned from the krb5_rd_safe() function. It means that the
checksum used to verify the data packet didn't match what was expected,
which would imply a corrupted data stream or a possible attack.
I have seen this occasionally when propagating our Kerberos database to
slave servers. As far as I can tell, it seems to be benign in this case. It
occurs very infrequently, I haven't had a chance to figure out what is going
on.
------------------------------------------------------------
Subject: 4.7. "Illegal cross-realm ticket"
This means that you were using transitive cross-realm authentication and
that the authentication path wasn't valid.
Question 2.15 explains in greater detail how to configure transitive
cross-realm authentication. Note that currently you need to set up your
configuration file correctly on every application server, since currently it
is the application servers that enforce this restriction. In the next
version of the Kerberos protocol it will be possible to have the KDC do the
transitive realm check.
------------------------------------------------------------
Subject: 4.8. "Couldn't authenticate to server: Bad sendauth version was
sent"
This comes from the krb5_sendauth() function call. The protocol used by this
function includes a version string that the remote side can use to verify
that they are speaking the same protocol.
Every time I have seen this problem, it is with the Kerberized Berkeley
r-commands (rlogin, rsh, etc etc). The appropriate server is closing the
remote end of the connection for some reason (for example, if you don't have
tcp wrappers configured to let in Kerberos rlogins) and this is the first
thing that fails.
------------------------------------------------------------
Subject: 4.9. When I try using Kerberos ftp, it doesn't work, but it says,
"No error".
What you probably saw were errors like the following:
GSSAPI error major: No error
GSSAPI error minor: No error
There is an error here, it's just not being reported very well.
This comes from the ftp daemon; it is trying to build a service principal
for the ftp service using the fully-qualified local hostname as the
principal instance, and it's not finding it in the local keytab. This
generally results in a confusion between the machine's local hostname and
it's hostname in DNS.
Note that ftpd is currently the only program that deals with service
principals this way, so this is why these problems crop up with the Kerberos
ftp daemon and not other Kerberized services.
------------------------------------------------------------
Subject: 4.10. When I telnet from a Linux machine to a Solaris machine with
Kerberos and hit Ctrl-C, the connection hangs.
From: Christopher Blizzard <[email protected]>
The solution was to define "NO_URGENT" when building the telnetd
daemon on Solaris. When sending urgent data to a Linux client, one
or the other is getting confused.
------------------------------------------------------------
Subject: 5. Programming with Kerberos.
------------------------------------------------------------
Subject: 5.1. How do I start programming with Kerberos?
From: Jim Doyle <[email protected]>
In the Kerberos V5 distribution, I believe there is a s
simple-server/simple-client pair that demonstrates the code
skeleton needed to implemented per-connection authentication.
A word of caution to new Kerberizers of applications. :) Dont just
go off and craft your product's Kerberos implementation around one
day's worth of hacking on the V5 demo examples... Take the time to
understand all the subtleties of the protocol and all of the
features of design in V5 that you have available to you.
Some common mistakes that newbies do when they Kerberize their
first client-server application:
1. They hard-code various things into their code, such as the
location of the keytab file, or the server's principal name.
Bad ideas. Consider that people may want to put the keytab
files in places other than your products' installation
directory.
Further, you should also make sure that end-users can choose
whatever principal name they wish for each server instance...
This has a side effect that the client side protocol needs to
be able to discover the principal name of the server process
before getting and sending an authenticator. Without the
ability to choose principal names, it may be difficult to
multiply-instantiate servers in a Kerberos realm.
2. Put lots of debugging trace statements in your
implementation. These are invaluable for diagnosing Kerberos
related problems once your product is in deployment.
3. Consider using generic GSSAPI services.
Another point worth mentioning is that if you are using a standardized
protocol (such a POP, IMAP, etc etc) it is strongly recommended that you
work within the framework of that protocol. In the case of protocols like
POP and IMAP, there is already a standard authentication framework into
which Kerberos fits. This saves you the work of having to design a protocol
for your application. This doesn't apply to custom protocols developed
internally, of course, but the design decisions made for standardized
protocols might give you some ideas to apply to your own protocol.
------------------------------------------------------------
Subject: 5.2. What is GSSAPI?
GSSAPI is an acronym; it stands for Generic Security Services Application
Programming Interface.
The GSSAPI is a generic API for doing client-server authentication. The
motivation behind it is that every security system has it's own API, and the
effort involved with adding different security systems to applications is
extremely difficult with the variance between security APIs. However, with a
common API, application vendors could write to the generic API and it could
work with any number of security systems.
How does this relate to Kerberos? Included with most major Kerberos 5
distributions is a GSSAPI implementation. Thus, if a particular application
or protocol says that it supports the GSSAPI, then that means that it
supports Kerberos, by virtue of Kerberos including a GSSAPI implementation.
The relevant standards for GSSAPI include:
* RFC 2743 - Generic Security Services Application Program Interface
Version 2, Update 1.
<http://www.ietf.org/rfc/rfc2743.txt>
* RFC 1509 - Generic Security Service API: C-bindings
<http://www.ietf.org/rfc/rfc1509.txt>
* RFC 1964 - The Kerberos Version 5 GSS-API Mechanism
<http://www.ietf.org/rfc/rfc1964.txt>
In terms of programming guides, the only one available that I know about is
the one from Sun Microsystems. It seems fairly complete and is a excellent
starting point:
* <http://docs.sun.com:80/ab2/coll.610.1/GSSAPIPG/>
------------------------------------------------------------
Subject: 5.3. What is SASL?
SASL is an acronym; it stands for Simple Authentication and Security Layer.
SASL is a generic protocol framework for doing various sorts of
authentication between clients and server. In SASL termology, application
protocols such as POP, IMAP, and SMTP specify a "SASL profile," which
describes how to encapsulate SASL negotiation and SASL messages for that
protocol. Different authentication schemes are called "mechanisms" in the
SASL framework.
How does this relate to Kerberos? One of the supported mechanisms for SASL
is GSSAPI, and since Kerberos is one of the standardized GSSAPI mechanisms,
protocols that use SASL for authentication support Kerberos authentication
via the GSSAPI.
It's important to clarify one thing: while a protocol may support SASL, it's
not required that applications that implement that protocol support all
security mechanisms. In other words, a particular mail reader may support
SASL, but it might not support the GSSAPI mechanism. You need to talk to the
vendor to find out which mechanisms each application supports.
SASL is described by the following RFC:
* RFC 2222 - <http://www.ietf.org/rfc/rfc2222.txt>
Some example of SASL profiles for application protocols are:
POP
RFC 1734 - <http://www.ietf.org/rfc/rfc1734.txt>
IMAP
RFC 1731 - <http://www.ietf.org/rfc/rfc1731.txt>>
SMTP
RFC 2554 - <http://www.ietf.org/rfc/rfc2554.txt>
A number of SASL libraries are available for programmers who don't wish to
write their own SASL code. The most common open-source one is Cyrus SASL.
It's available at:
* <ftp://ftp.andrew.cmu.edu/pub/cyrus-mail>
------------------------------------------------------------
Subject: 5.4. Is there a reference for the Kerberos API?
There is a semi-complete list of the basic Kerberos 5 API functions included
in the distribution under $(KRB5)/doc/api. It's not complete list of all API
functions, but it's definitely a good start.
If you have trouble converting the LaTeX documentation, Jeff Mahoney at the
Computer Science House of RIT has very kindly converted this document to
HTML format and made it available on the Web. You can get it at:
* <http://www.csh.rit.edu/~jeffm/docs/krb5api/>
------------------------------------------------------------
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |