لطفا منتظر باشید ...
Understanding
Kerberos Operation
Effectively using Kerberos on your network
requires you to install a Kerberos password server (more commonly called a key distribution center, or KDC )
and add both client and server software that uses the KDC for authentication
(these are often called Kerberized applications ).
Understanding the basics of the Kerberos protocols, including the interactions
between these elements, is important for effective use of Kerberos on a
network. This section therefore presents the basic principles of the protocol's
operation, including information on various Kerberos products and requirements
for a KDC.
Basic Principles of Kerberos Operation
Described in a single sentence, Kerberos is a
centralized user authentication protocol that uses encryption to protect
against various forms of attack. This description, however, is incomplete;
Kerberos's encryption system is fairly complex so that it can meet various
specific design goals. The structure of a Kerberos network also involves
certain features that require some discussion.
Kerberos Network Elements
As already described, a Kerberos network is
built around a KDC. This KDC is responsible for authenticating machines in a
Kerberos realm. Typically, a realm corresponds
to an Internet domain or subdomain. For instance, the threeroomco.com domain might contain a single Kerberos realm, which would probably
be called THREEROOMCO.COM . Kerberos realm names are case-sensitive, unlike Internet domain
names. The convention is to use all-uppercase letters for Kerberos realms
simply to distinguish in writing between the functions of a realm and a domain,
although the two may consist of the same set of computers. It's possible for a
Kerberos realm to span less than an entire domain, or to include computers in
multiple domains. If you want to use two separate Kerberos realms in a single
domain, the common practice is to add a separate element to the start of the
Kerberos realm names, such as REALM1.THREEROOMCO.COM and REALM2.THREEROOMCO.COM .Kerberos works by assigning tickets for various services. Like an airline or
movie theater ticket, a Kerberos ticket grants the holder access to something. As
described shortly, there are two main types of ticket.A Kerberos server
is, as you might expect, a computer that runs the Kerberos server software, or
the server software itselfin other words, the KDC. A Kerberos
client is a computer or program that obtains a service ticket from the
Kerberos server. Normally, this system is associated with a user who initiates
a request to obtain service. The name for a computer that the Kerberos client
is ultimately trying to use (say, a print server) is the application server.Kerberos assigns tickets to principals, which as a first approximation are similar
to users or server programs. Principals are described as three components: a primary, an instance,
and a realm. These three components are expressed as primary/instance@realm . The primary is a username, in the case of a user requesting a
ticket. If it's a computer that requests the ticket, the primary is the word host . A
principal can also be associated with a specific server, in which case the
primary is usually the server name, such as ftp . The instance is
optional, and is used to create separate entries for a single primary for
different purposes. For instance, the user fluffy might have a
regular principal for ordinary use, but another principal that uses the admin instance
for administering the realm. If the realm is THREEROOMCO.COM , these
two principals would be expressed as fluffy@THREEROOMCO.COM and fluffy/admin@THREEROOMCO.COM .
Kerberos Design Goals and Operation
In order to better understand why Kerberos
does things the way it does, it's helpful to look at the Kerberos design goals.
These include the following: Provide network
authentication Servers must be able to
authenticate the identities of users attempting to use their services to
prevent unauthorized access to servers. As important in many environments, but
less obvious, the clients must be able to verify the identifies of the servers
they use to prevent one system from pretending to be a server and thus
intercepting print jobs, e-mail, or other potentially sensitive data. This
is Kerberos's raison d'etre. Protect passwords Many services, as described in various chapters of this book, use
unencrypted passwords by default. This is a security liability, because these
passwords can be intercepted, thus compromising the network's security. Some
protocols encrypt passwords to avoid this problem, but Kerberos uses an unusual
approach: Rather than send passwords in an encrypted form, it uses the password
as an encryption key for transmitting data required for Kerberos's operation. Thus,
the password isn't transmitted, but only a user with the correct password can
use the data. Allow single-login
operation Kerberos allows users to enter
passwords once, when they log in to their computers. Subsequent transfers using
Kerberized applications don't require password entry. For instance, you need
not reenter your password when you retrieve e-mail using a Kerberized pull mail
server or log in to another computer using a Kerberized remote login server. (Of
course, if you access a system outside of your local Kerberos network, this
benefit won't extend to the remote systems.) The tickets you get when you enter
a password are time-limited, though, so you may need to periodically reenter
your password if you use the system for a long time. You won't need to reenter
the password when you use new servers or reuse old ones within the lifetime of
the tickets.NOTE
align=left border=0> Many applications that use passwords to
access remote servers provide the user with the option of saving the
password. This is common in pull mail clients, for instance. (
Mail Protocols: POP and IMAP, covers these protocols.) When a password is
saved in this way, the user doesn't need to reenter it; however, saving the
password to disk is a security risk in the event of a break-in of the
workstation. Furthermore, if the user changes a password, it may have to be
changed in several programs, which can be a nuisance. Kerberos
eliminates both problems.
Kerberos was also designed to meet various
technical requirements that are partly dependent upon design details of the
system, but the preceding three are the main requirements from a user's or
administrator's point of view. To achieve these goals, Kerberos relies upon its
tickets. The process works something like this:
use a service, and so enters a username and password.
2. The workstation (a Kerberos
client) sends the username to the KDC with a request to obtain a ticket-granting ticket (TGT). This request is
processed by a particular Kerberos subset known as the ticket-granting service (TGS).
3. The KDC checks for the username in
its database. If the username is present, the KDC responds with a TGT. This
ticket includes information such as the username for which the TGT is useful,
the time the TGT was issued, and the time span over which the TGT is valid. The
KDC uses the password in the username database to encrypt the TGT, and sends it
back to the client.
4. The client receives the TGT, and
attempts to decrypt the TGT with the password the user entered. If this process
is successful, the client holds onto the ticket, transparent to the user.
5. The client sends a request to
obtain a ticket for a specific server to the KDC, using data extracted from the
TGT. The KDC recognizes this data as valid (because it's been successfully
decrypted and then reencrypted) and replies by sending a ticket for the server.
This ticket is encrypted with the target server's
password (which is known only to the server and the KDC), and includes
information such as the username of the person making the request, the name of
the service being requested, a time stamp, a time period for which the ticket
is valid, and a session key, which is another
password created by the KDC and shared with the server and client. This
ticket's lifetime is short to reduce the risk of its being intercepted and
abused.
6. The client receives the service ticket, which it
holds, transparent to the user. (The client doesn't attempt to decrypt
this ticket.)
7. The client sends the service
ticket to the server in question, requesting a data transfer session.
8. The server decrypts the ticket
with its password; this will work properly if and only if the ticket was
properly encrypted by the KDC. If the request is in order (it decrypted
properly, it's from a valid user, and so on), the server uses the session key
to encrypt a reply to the client.
9. The client receives the server's
reply. If and only if this reply is valid, the client can assume that the
server is authentic, so the client completes the connection and begins its data
transfer only if it receives the correct reply from the server.
From here, the data transfer proceeds
more-or-less as it would without Kerberos in the picture, although some
Kerberized applications support data encryption features that are unavailable
to their non-Kerberized counterparts. Eventually, the TGT and server tickets
will expire, but the expiration times are set to long enough values (several
hours) that this seldom poses a problem for individual users. If a
ticket does expire, it can be renewed.WARNING
align=left border=0> The preceding procedure uses time stamps in
several exchanges. If computers' clocks are set to different times, these
time stamps may cause a transaction to fail, or may reduce the security on
the network. It's therefore extremely important that all computers on a
Kerberos network be set to the same time. You can accomplish this goal by
running a Network Time Protocol (NTP) server on all computers, as described
in Chapter 10 ,
Maintaining Consistent Time: Time Servers.
Requirements
for the Kerberos Server
This design has several consequences. Most
importantly, the KDC is an extremely sensitive
system, from a network security point of view. The KDC should run as few other
network servers as possible (normally only those required to administer
itideally none), it should have no ordinary users except for its
administrators, you should pay particular care to keeping its software up to
date, and it should be physically secure. Because use of many network services
depends upon the KDC, you should be prepared with contingency plans in case it
fails. Keep backups of the KDC's data and have backup hardware ready in case of
failure. You might even want to maintain a slave
or backup KDC, which pulls its configuration
from the master KDC, so that the slave can take
over KDC functions in case of a failure of the master KDC.The hardware requirements of the KDC depend
upon the size of your network, both in terms of the number of computers and the
number of users. A KDC for a small network of a few dozen systems might require
what is by today's standards a very low-end computerafter all, such a system
would need to field only a few requests every hour. A system with a low-end
Pentium CPU, 32MB of RAM, and a hard disk of a few hundred megabytes should be
more than sufficient. A KDC for a network with hundreds or thousands of
computers might require more computing power, particularly in terms of CPU
power and network connectivity. In any event, you should ensure that the KDC is
placed somewhere on your network topology that ensures maximum reliability and
minimum data transit times. If your network is large enough and segmented in
such a way as to make it likely that sections of it may become isolated from
each other, you may want to place slave KDCs in each segment to minimize
disruption in case of a break in network routing.
Kerberos Versions and Variants
The main Kerberos package is available from
platforms, but not for Linux as of Kerberos V5 Release 1.2.1. You can also
obtain the older Kerberos V4 from this official site and versions of the
software for Windows and MacOS (both the older MacOS Classic and the newer
MacOS X). All other things being equal, Kerberos V5 is superior to Kerberos V4;
V5 adds a few features and fixes bugs in V4.The Kerberos license is similar to that of X,
and so various open source and commercial variants of the original MIT code
have emerged. One of these is distributed by the Royal Institute of Technology
in Sweden , and is available
from their Web page, target="_blank">http://www.pdc.kth.se/kth-krb/ . This variant is known as eBones, but package filenames typically
begin with the string krb4 . The eBones Web site officially distributes only source code, but
the FTP site includes a binaries subdirectory with some contributed binary packages, including
directories for Linux. These may be out of date, though. Indeed, eBones itself
is based on the Kerberos V4 release, at least as of eBones version 1.1.The Center for Parallel Computers has
developed a Kerberos implementation known as Heimdal, headquartered at
source code and compiled Linux executables from the Web site, including RPMs
for Red Hat, although the binary versions may lag behind the latest (currently
0.4e).Some Linux distributions now ship with
Kerberos support. In particular, Debian 2.2 ships with both eBones and Heimdal,
Mandrake 8.1 ships with Kerberos V5, Red Hat 7.2 ships with Kerberos V5, and
SuSE 7.3 ships with Heimdal. Caldera 3.1, Slackware 8.0, and TurboLinux 7.0 do
not ship with Kerberos support, but you can add packages by compiling the
source, or possibly by installing a package intended for another distribution.NOTE
align=left border=0> Subsequent sections of this chapter
describe MIT's Kerberos V5. Kerberos V4 differs in some important
configuration details, and even V5 derivatives like Heimdal may not work
precisely as described here. In writing this chapter, I used both Red Hat's
Kerberos V5 packages and builds of the original MIT source code as
references.
Understanding
Kerberos Operation
Effectively using Kerberos on your network
requires you to install a Kerberos password server (more commonly called a key distribution center, or KDC )
and add both client and server software that uses the KDC for authentication
(these are often called Kerberized applications ).
Understanding the basics of the Kerberos protocols, including the interactions
between these elements, is important for effective use of Kerberos on a
network. This section therefore presents the basic principles of the protocol's
operation, including information on various Kerberos products and requirements
for a KDC.
Basic Principles of Kerberos Operation
Described in a single sentence, Kerberos is a
centralized user authentication protocol that uses encryption to protect
against various forms of attack. This description, however, is incomplete;
Kerberos's encryption system is fairly complex so that it can meet various
specific design goals. The structure of a Kerberos network also involves
certain features that require some discussion.
Kerberos Network Elements
As already described, a Kerberos network is
built around a KDC. This KDC is responsible for authenticating machines in a
Kerberos realm. Typically, a realm corresponds
to an Internet domain or subdomain. For instance, the threeroomco.com domain might contain a single Kerberos realm, which would probably
be called THREEROOMCO.COM . Kerberos realm names are case-sensitive, unlike Internet domain
names. The convention is to use all-uppercase letters for Kerberos realms
simply to distinguish in writing between the functions of a realm and a domain,
although the two may consist of the same set of computers. It's possible for a
Kerberos realm to span less than an entire domain, or to include computers in
multiple domains. If you want to use two separate Kerberos realms in a single
domain, the common practice is to add a separate element to the start of the
Kerberos realm names, such as REALM1.THREEROOMCO.COM and REALM2.THREEROOMCO.COM .Kerberos works by assigning tickets for various services. Like an airline or
movie theater ticket, a Kerberos ticket grants the holder access to something. As
described shortly, there are two main types of ticket.A Kerberos server
is, as you might expect, a computer that runs the Kerberos server software, or
the server software itselfin other words, the KDC. A Kerberos
client is a computer or program that obtains a service ticket from the
Kerberos server. Normally, this system is associated with a user who initiates
a request to obtain service. The name for a computer that the Kerberos client
is ultimately trying to use (say, a print server) is the application server.Kerberos assigns tickets to principals, which as a first approximation are similar
to users or server programs. Principals are described as three components: a primary, an instance,
and a realm. These three components are expressed as primary/instance@realm . The primary is a username, in the case of a user requesting a
ticket. If it's a computer that requests the ticket, the primary is the word host . A
principal can also be associated with a specific server, in which case the
primary is usually the server name, such as ftp . The instance is
optional, and is used to create separate entries for a single primary for
different purposes. For instance, the user fluffy might have a
regular principal for ordinary use, but another principal that uses the admin instance
for administering the realm. If the realm is THREEROOMCO.COM , these
two principals would be expressed as fluffy@THREEROOMCO.COM and fluffy/admin@THREEROOMCO.COM .
Kerberos Design Goals and Operation
In order to better understand why Kerberos
does things the way it does, it's helpful to look at the Kerberos design goals.
These include the following: Provide network
authentication Servers must be able to
authenticate the identities of users attempting to use their services to
prevent unauthorized access to servers. As important in many environments, but
less obvious, the clients must be able to verify the identifies of the servers
they use to prevent one system from pretending to be a server and thus
intercepting print jobs, e-mail, or other potentially sensitive data. This
is Kerberos's raison d'etre. Protect passwords Many services, as described in various chapters of this book, use
unencrypted passwords by default. This is a security liability, because these
passwords can be intercepted, thus compromising the network's security. Some
protocols encrypt passwords to avoid this problem, but Kerberos uses an unusual
approach: Rather than send passwords in an encrypted form, it uses the password
as an encryption key for transmitting data required for Kerberos's operation. Thus,
the password isn't transmitted, but only a user with the correct password can
use the data. Allow single-login
operation Kerberos allows users to enter
passwords once, when they log in to their computers. Subsequent transfers using
Kerberized applications don't require password entry. For instance, you need
not reenter your password when you retrieve e-mail using a Kerberized pull mail
server or log in to another computer using a Kerberized remote login server. (Of
course, if you access a system outside of your local Kerberos network, this
benefit won't extend to the remote systems.) The tickets you get when you enter
a password are time-limited, though, so you may need to periodically reenter
your password if you use the system for a long time. You won't need to reenter
the password when you use new servers or reuse old ones within the lifetime of
the tickets.NOTE
align=left border=0> Many applications that use passwords to
access remote servers provide the user with the option of saving the
password. This is common in pull mail clients, for instance. (
Mail Protocols: POP and IMAP, covers these protocols.) When a password is
saved in this way, the user doesn't need to reenter it; however, saving the
password to disk is a security risk in the event of a break-in of the
workstation. Furthermore, if the user changes a password, it may have to be
changed in several programs, which can be a nuisance. Kerberos
eliminates both problems.
Kerberos was also designed to meet various
technical requirements that are partly dependent upon design details of the
system, but the preceding three are the main requirements from a user's or
administrator's point of view. To achieve these goals, Kerberos relies upon its
tickets. The process works something like this:
use a service, and so enters a username and password.
2. The workstation (a Kerberos
client) sends the username to the KDC with a request to obtain a ticket-granting ticket (TGT). This request is
processed by a particular Kerberos subset known as the ticket-granting service (TGS).
3. The KDC checks for the username in
its database. If the username is present, the KDC responds with a TGT. This
ticket includes information such as the username for which the TGT is useful,
the time the TGT was issued, and the time span over which the TGT is valid. The
KDC uses the password in the username database to encrypt the TGT, and sends it
back to the client.
4. The client receives the TGT, and
attempts to decrypt the TGT with the password the user entered. If this process
is successful, the client holds onto the ticket, transparent to the user.
5. The client sends a request to
obtain a ticket for a specific server to the KDC, using data extracted from the
TGT. The KDC recognizes this data as valid (because it's been successfully
decrypted and then reencrypted) and replies by sending a ticket for the server.
This ticket is encrypted with the target server's
password (which is known only to the server and the KDC), and includes
information such as the username of the person making the request, the name of
the service being requested, a time stamp, a time period for which the ticket
is valid, and a session key, which is another
password created by the KDC and shared with the server and client. This
ticket's lifetime is short to reduce the risk of its being intercepted and
abused.
6. The client receives the service ticket, which it
holds, transparent to the user. (The client doesn't attempt to decrypt
this ticket.)
7. The client sends the service
ticket to the server in question, requesting a data transfer session.
8. The server decrypts the ticket
with its password; this will work properly if and only if the ticket was
properly encrypted by the KDC. If the request is in order (it decrypted
properly, it's from a valid user, and so on), the server uses the session key
to encrypt a reply to the client.
9. The client receives the server's
reply. If and only if this reply is valid, the client can assume that the
server is authentic, so the client completes the connection and begins its data
transfer only if it receives the correct reply from the server.
From here, the data transfer proceeds
more-or-less as it would without Kerberos in the picture, although some
Kerberized applications support data encryption features that are unavailable
to their non-Kerberized counterparts. Eventually, the TGT and server tickets
will expire, but the expiration times are set to long enough values (several
hours) that this seldom poses a problem for individual users. If a
ticket does expire, it can be renewed.WARNING
align=left border=0> The preceding procedure uses time stamps in
several exchanges. If computers' clocks are set to different times, these
time stamps may cause a transaction to fail, or may reduce the security on
the network. It's therefore extremely important that all computers on a
Kerberos network be set to the same time. You can accomplish this goal by
running a Network Time Protocol (NTP) server on all computers, as described
in Chapter 10 ,
Maintaining Consistent Time: Time Servers.
Requirements
for the Kerberos Server
This design has several consequences. Most
importantly, the KDC is an extremely sensitive
system, from a network security point of view. The KDC should run as few other
network servers as possible (normally only those required to administer
itideally none), it should have no ordinary users except for its
administrators, you should pay particular care to keeping its software up to
date, and it should be physically secure. Because use of many network services
depends upon the KDC, you should be prepared with contingency plans in case it
fails. Keep backups of the KDC's data and have backup hardware ready in case of
failure. You might even want to maintain a slave
or backup KDC, which pulls its configuration
from the master KDC, so that the slave can take
over KDC functions in case of a failure of the master KDC.The hardware requirements of the KDC depend
upon the size of your network, both in terms of the number of computers and the
number of users. A KDC for a small network of a few dozen systems might require
what is by today's standards a very low-end computerafter all, such a system
would need to field only a few requests every hour. A system with a low-end
Pentium CPU, 32MB of RAM, and a hard disk of a few hundred megabytes should be
more than sufficient. A KDC for a network with hundreds or thousands of
computers might require more computing power, particularly in terms of CPU
power and network connectivity. In any event, you should ensure that the KDC is
placed somewhere on your network topology that ensures maximum reliability and
minimum data transit times. If your network is large enough and segmented in
such a way as to make it likely that sections of it may become isolated from
each other, you may want to place slave KDCs in each segment to minimize
disruption in case of a break in network routing.
Kerberos Versions and Variants
The main Kerberos package is available from
platforms, but not for Linux as of Kerberos V5 Release 1.2.1. You can also
obtain the older Kerberos V4 from this official site and versions of the
software for Windows and MacOS (both the older MacOS Classic and the newer
MacOS X). All other things being equal, Kerberos V5 is superior to Kerberos V4;
V5 adds a few features and fixes bugs in V4.The Kerberos license is similar to that of X,
and so various open source and commercial variants of the original MIT code
have emerged. One of these is distributed by the Royal Institute of Technology
in Sweden , and is available
from their Web page, target="_blank">http://www.pdc.kth.se/kth-krb/ . This variant is known as eBones, but package filenames typically
begin with the string krb4 . The eBones Web site officially distributes only source code, but
the FTP site includes a binaries subdirectory with some contributed binary packages, including
directories for Linux. These may be out of date, though. Indeed, eBones itself
is based on the Kerberos V4 release, at least as of eBones version 1.1.The Center for Parallel Computers has
developed a Kerberos implementation known as Heimdal, headquartered at
source code and compiled Linux executables from the Web site, including RPMs
for Red Hat, although the binary versions may lag behind the latest (currently
0.4e).Some Linux distributions now ship with
Kerberos support. In particular, Debian 2.2 ships with both eBones and Heimdal,
Mandrake 8.1 ships with Kerberos V5, Red Hat 7.2 ships with Kerberos V5, and
SuSE 7.3 ships with Heimdal. Caldera 3.1, Slackware 8.0, and TurboLinux 7.0 do
not ship with Kerberos support, but you can add packages by compiling the
source, or possibly by installing a package intended for another distribution.NOTE
align=left border=0> Subsequent sections of this chapter
describe MIT's Kerberos V5. Kerberos V4 differs in some important
configuration details, and even V5 derivatives like Heimdal may not work
precisely as described here. In writing this chapter, I used both Red Hat's
Kerberos V5 packages and builds of the original MIT source code as
references.
