Aspectos de consideración

Kerberos uses the workstation time to help identify the current user. Kerberos tickets have fixed lifetimes, and are not valid before their issue timestamp or after their expiration. These mechanisms prevent replay attacks, where a hacker reuses an eavesdropped ticket to masquerade as a valid user. Though Kerberos includes several mechanisms to prevent replay attacks, it is critical that all workstations and servers on your net- work have the correct time and that time be synchronized closely with the Kerberos Key Distribution Center (KDC).

Fortunately, Solaris provides xntpd for this purpose. The network time daemon communicates with higher-level timeservers to determine the correct time, adjusts for clock skew, and keeps workstations on the same time as peer hosts.

Large Kerberos sites usually use a GPS clock for a timeserver. For most locations, a few servers configured to poll a reliable Internet timeserver like the Washington Naval Observatory or NIST are sufficient. Other servers and workstations can, in turn, poll these servers for the correct time. A list of NIST time servers can be found at www.boulder .nist.gov/timefreq/service/time-servers.html.

configuration, and how it can be used to secure your network.We’ll also discuss some of the pitfalls and security risks associated with Kerberos.

To understand Kerberos and its strengths as an authentication system, we need to look at a conventional service, such as rlogin.When a client initiates an rlogin connection, rlogin sends the name of the local user to the server for identifica- tion. If the server trusts the client or the user (through hosts.equiv or an .rhosts file), the connection is allowed and the user logs in. In the event that no host- based trust is present, the user is forced to present a password as identification. One problem with this is that the password travels in the clear on the network, where any eavesdropper can easily obtain it. Furthermore, this system assumes that there are circumstances in which a remote host can be implicitly trusted simply by virtue of its IP address.

The Secure Shell (SSH) mitigates some of these problems through the use of encryption.The server end of the connection is identified by public key cryptog-

raphy. If the server’s public key matches the one previously cached by the client,

the user can be certain that he has reached the correct host. All authentication credentials (and indeed the entire connection) travel over an encrypted channel. This would seem to be ideal but, in fact, suffers from two significant weaknesses. First, SSH includes no mechanism for securely identifying a remote host to a client for that initial connection.The user must assume that he has reached the intended destination, and keep a copy of the public key first presented. If an attacker can redirect that initial session, he can control all future sessions without giving the client any noticeable signs of trouble. Second, SSH, like its insecure counterparts, is a based on a disclosing authentication system.That is, a password is disclosed during the authentication process, and thus may be captured and reused by a compromised server.

Kerberos seeks to address both of these issues; it is a nondisclosing authenti- cation system that provides a mechanism to securely identify each end of the connection.

When a user is first added to the KDC, their initial password is used to gen- erate a unique hash, which is stored by that server.The account creation process, through kadmin, is secure, and the passwords are not recoverable.When a user first logs in, the login process contacts the KDC and requests a Ticket Granting Ticket(TGT).This ticket contains information like the username, the validity period of the ticket, some cryptographic identifiers of the KDC that issued it, etc. The entire ticket is then encrypted, using the stored hash as the secret key. A login is successful when the login process, using the password you provided, is able to decrypt and store that ticket locally in what Kerberos calls a credentials

cache. As you are the only person in possession of the correct password with

which to decrypt that ticket, you have been correctly identified. A file previously placed on your workstation called a keytab identifies your machine and is used during the login process to ensure that the TGT it just received came from the real KDC. In this way, the Kerberos server has granted you its trust and ensured that the machine you just logged in to is the one it identified once before. Most importantly, your password is never disclosed to the KDC and it never travels across the network, even in encrypted form.This is one of the fundamental tenets of Kerberos and, as we’ll see later, a weakness to its widespread adoption.

Now that you have a TGT, let’s attempt to sort out the series of events set in motion by the login process for a typical service, like a Kerberized rlogin.The Kerberos server generates a random session key along with an identifier for the remote service and encrypts this with your session key, which is now stored in your TGT. It also stores that session key, along with your username, in a ticket which is encrypted with the service key owned by the remote server.When your copy of rlogin receives both tickets, it decrypts yours, using the key stored in the TGT, to recover the session key. Rlogin can’t decrypt the other ticket; only the remote server can do that. So rlogin takes the current time, encrypts that with the session key as proof that you posses a valid TGT, and sends this new ticket, along with the other undecipherable one, to the server.

When the remote server receives these two tickets, it decrypts the first one with its own key, recovering the random session key. It can then use this key to recover the time you sent. If its time matches your time, within a little slop to allow for slightly different clocks, the server has proof that you are who you say you are. As only the server you tried to contact could possibly recover the session key, you can be certain that you have connected to the correct host. As an added benefit, each side of the connection now has a unique, random key which can be guaranteed secure from eavesdropping or tampering and may now be used to encrypt the rlogin connection.You never had to type your password and, as long as your TGT is valid, you never will. At no time in this exchange was your pass- word revealed to the remote service or to the KDC. It’s a complex chain of events, but when correctly implemented it provides an immensely powerful authentication system.

Sun’s SEAM package brings Kerberos to Solaris. SEAM provides the pam_krb5 module that performs authentications, plus Kerberized versions of the FTP, rlogin, rsh, rcp, and Telnet services. During the SEAM installation process, a new Kerberos realm is created. Realms are roughly the Kerberos equivalents of NIS or NIS+ domains.They represent a collection of user and administrator authentication data,

service credentials, and host-identifying keytabs. At installation time, SEAM will create a properly formatted krb5.conf, similar to the following:

[libdefaults] default_realm = INCOMING-TRAVELLER.COM [realms] INCOMING-TRAVELLER.COM { kdc = kdc.incoming-traveller.com admin_server = kdc.incoming-traveller.com } [domain_realm] .incoming-traveller.com = INCOMING-TRAVELLER.COM [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log

The incoming-traveller.com realm holds all of the Kerberos authentication data.The domain_realm section is used by Kerberos to map hostnames to a Kerberos realm.The realm section gives the hostname of the Key Distribution Center that will handle authentication credentials. KDCs come in two forms: master and slave.The master KDC contains user principals, which are the Kerberos equivalents of an account, service principals, administrator principals, and host keytabs.The slave KDC receives periodic updates of this data over a secure, authenticated process. Slave Key Distribution Centers are used to ensure redundancy and authentication performance.

To gain access to the Kerberized versions of common utilities, along with some Kerberos-specific commands, users should prepend /usr/krb5/bin to their PATH environments.

SEAM provides a Kerberos PAM to handle ticket management at login. When a user logs in, through the dtlogin for example, the PAM gathers a user- name and password from the user and requests a Ticket Granting Ticket from the KDC.The krb5.conf is used by the PAM to locate the correct KDC for the cur- rent realm. If the authentication is successful, the PAM stores the ticket in a cre- dentials cache in /tmp, in a form readable only by the user.The klist command shows what credentials are present and each one’s lifetime:

% /usr/krb5/bin/klist -f Ticket cache: /tmp/krb5cc_3551

Default principal: [email protected]

When using Kerberos, the default logout process should contain the kdestroy command. Kdestroy simply deletes the credentials cache from /tmp. File permis- sions are all that prevent someone from masquerading as another user for the life- time of the TGT. It is imperative that these caches be removed by kdestroy at logout.

SEAM provides a series of Kerberized commands that take advantage of this unique authentication mechanism. Sites whose users make regular use of Kerberized and conventional hosts may have interoperability problems, as the Kerberized commands may not always communicate correctly with non- Kerberos-aware services on other hosts.

The rlogin, rsh, rcp, and Telnet commands operate in the same ways as their non-Kerberized equivalents, but provide two new benefits: once you have obtained a TGT, these commands will not prompt for a password for the validity period of that ticket.This provides true single-sign-on. Users log in once and, for the next few hours, never have to retype their password. Additionally, by using the -x option, these commands can, in strong contrast to their conventional counter- parts, encrypt the entire session.