 |  |
21.5. Kerberos
Kerberos was developed at MIT by Project Athena (the same folks who developed the X Window System). It is designed to provide authentication and encryption services through modified versions of standard clients and servers (e.g., Telnet clients and servers).Kerberos provides strong authentication in a distributed environment, and it is widely available. It is the primary source of authentication in Windows 2000. Some other vendors also provide Kerberos support with their operating systems; MIT has freely available implementations for many versions of Unix; and the code is freely available if you wish it to port it to an operating system that does not yet have an implementation.
Kerberos attempts to solve the problem where a client wants to talk to a server over an untrusted network. The client and the server don't have to trust each other or the network, but they have to trust the Kerberos server (it is the trusted third party). Imagine a courier attempting to deliver gems to a jewelry store. The jewelry store doesn't want to let in a fake courier who might be a robber; the courier doesn't want to give the gems to a fake jeweler who might be a robber. If both of them trust a third party, that person can verify the identity of both sides of the transaction.
There have been two official releases of Kerberos, version 4 and version 5. Version 5 was released in 1993 and fixed a number of problems. We do not recommend using Kerberos version 4. MIT's Unix code is freely available under license (see Appendix A, "Resources"), but Kerberos is not in the public domain. Because Kerberos needs to be integrated into everything that uses authentication data, implementing Kerberos in your environment can be tricky. Several companies and operating systems vendors offer commercial versions of Kerberos where some or all of this work has been done for you.
21.5.1. How It Works
Kerberos provides secure authentication for clients and servers across an untrusted network, as long as the Kerberos authentication servers themselves are protected from tampering. Figure 21-3 shows the basic requirements for a Kerberos network to be secure. Note that the trust relationships shown are the only important ones. The application server can be completely insecure, without being able to compromise anything. Similarly, the user can be hostile and try to attack the authentication server or the application server, without compromising security. The authentication server must be protected, and the client software must do what the user expects it to do. If either of these fails, security will be compromised. If the time is not synchronized, security may be compromised, but it's more likely that users will just be unable to authenticate.
Figure 21-3. Kerberos requirements
Kerberos uses slightly different terminology from most authentication systems. The area of authority of a Kerberos installation is called a realm. A realm is equivalent to a Windows NT or NIS domain, and in fact Windows 2000 uses domain instead of realm. All versions of Kerberos refer to the parties involved in a transaction as principals. A principal is an entity that needs to be authenticated. In most cases, a transaction involves a user talking to a server (for instance, somebody trying to pick up mail with POP), and therefore principals are normally users and services. In some cases, something else may need to be authenticated. For instance, the principals in the transaction when a machine transfers files for diskless booting are a host and a server instead of a user and a server.The authentication server is also known as a Key Distribution Center, or KDC. In Windows 2000, every domain controller is also an authentication server.
Suppose that you want to use a Kerberized POP server to read your mail, and you haven't done anything else with Kerberos in the last eight hours. When you ask to use the POP server, you will be asked for your password. The client will ask the authentication server for a ticket to the ticket-granting service and use the password to complete the process. It will then present that ticket to the ticket-granting service and ask for a ticket to the POP server. Finally, it will present this second ticket to the POP server. If you check your mail again, the client will give the same ticket to the POP server. If you decide to print a piece of mail to a Kerberized printing system, the client will take the ticket for the ticket-granting service and ask for a ticket to the print server, all without asking you for your password again. Figure 21-4 shows the initial process for speaking to the first application server.
Figure 21-4. Kerberos ticket exchange
In standard Kerberos terminology, the master ticket you get from the ticket-granting service is called a ticket granting ticket, or TGT. In Windows 2000, it is called a user ticket. The ticket that is handed to an application is called a session ticket in standard Kerberos and a service ticket in Windows 2000.Not all services will take a ticket that's given out by the ticket-granting service; for that matter, not all services will let you reuse a ticket. It's up to the service to decide how paranoid to be. Services that let you change your password, for instance, will normally require a ticket direct from the authentication service. If you leave to get a cup of tea, somebody at your keyboard will still be able to get tickets from the ticket-granting service, but not from the authentication service, because getting a ticket from the authentication service always requires providing a password.
In most Kerberos implementations, the password that the user types in as part of the authentication process is a fixed password. This password never crosses the network in the clear (so it can't be sniffed). On the other hand, nothing prevents an attacker from simply guessing the password. Kerberos goes to some lengths to avoid storing the password, even in encrypted form, where an attacker can get at it to optimize guessing attacks, but attackers are still free to try guessing the hard way (simply trying out passwords to see if they work). Some implementations support one-time password systems to prevent these attacks.
21.5.2. Extending Trust
Kerberos realms can trust each other, so that users who authenticate in one Kerberos realm can use resources in another. This is accomplished by using inter-realm tickets, which allow a ticket-granting service in one realm to issue tickets for another. Trust between Kerberos realms is transitive; if the chemistry department's realm trusts the realm run by the college of physical science, and so does the physics department, chemistry and physics trust each other.When a service gets a ticket from outside the service's realm, the ticket includes information about the realm that originally issued the ticket, and all the realms that the ticket has gone through. In the preceding example, when a user in chemistry sends a ticket to a service in physics, the service will see that the ticket was issued in chemistry and passed through the college of physical science. The service can then use this information to decide what privileges the user should have.
Inter-realm trusts don't particularly change the firewall issues with using Kerberos. A firewall that's between two realms will see the same sorts of traffic as a firewall that's between two parts of the same realm, except for initial authentication.
21.5.3. Packet Filtering Characteristics of Kerberos
Kerberos v5 uses the assigned port 88 for ticket request operations. Although the Kerberos protocol specifies the use of UDP, Windows 2000 may also use TCP for some requests. This is because Windows 2000 tickets contain more information than standard Kerberos tickets and therefore may be larger than will fit in a single 1,500-byte UDP packet. When this happens, the client will make an initial request over UDP, receive a truncated answer, and repeat the request over TCP. (This is a standard mechanism in several UDP-based protocols, including DNS and WINS, which allows most requests to use low-overhead UDP, while falling back to the more expensive TCP as an easy means to accommodate occasionally larger data transfers.)| Direction | SourceAddr. | Dest.Addr. | Protocol | Source Port | Dest.Port | ACKSet | Notes |
|---|---|---|---|---|---|---|---|
| In | Ext | Int | UDP | >1023 | 88 |
[134]
|
Request to internal KDC |
| Out | Int | Ext | UDP | 88 | >1023 | [134] | Response from internal KDC |
| Out | Int | Ext | UDP | >1023 | 88 | [134] | Request to external KDC |
| In | Ext | Int | UDP | 88 | >1023 | [134] | Response from external KDC |
| In | Ext | Int | TCP | >1023 | 88 |
[135]
|
Over-length request to internal KDC |
| Out | Int | Ext | TCP | 88 | >1023 | Yes | Over-length response from internal KDC |
| Out | Int | Ext | TCP | >1023 | 88 | [135] | Over-length request to external KDC |
| In | Ext | Int | TCP | 88 | >1023 | Yes | Over-length response from external KDC |
[134]UDP has no ACK equivalent.
[135]The ACK bit will not be set on the first packet but will be set on all subsequent packets.All packets contain authenticators and integrity checksums. In order to start a conversation with a Kerberos server, you need to have previously arranged to share a secret with the server. This means that it is likely that you will be able to detect attempts by foreign machines to obtain Kerberos credentials. On the other hand, it means that you will need to have a set of processes and procedures so that you can add and remove systems from your Kerberos realms.
21.5.4. Proxying and Network Address Translation Characteristics of Kerberos
Kerberos authenticator packets include the IP addresses of the originating system. These addresses are supposed to be checked against the source IP address (although it does not appear that all implementations actually make this check) to prevent the packet from being sniffed and replayed from a different IP address. This makes it difficult to use Kerberos with proxies or network address translation because the IP address in the packet will be the address of the internal host, while the source address will be the proxy server or the translated address.One solution, which requires modifications to the Kerberos sources,[136] is to have the internal systems add the external IP addresses to all Kerberos packets. This effectively disables the IP address checking performed by remote systems. It also means that the internal systems are trusting not only the Kerberos server, but also the proxy or address translation system, which is capable of masquerading as any internal host. This significantly raises the risk; Kerberos servers are highly protected machines, but proxy and address translation servers are extremely exposed.
[136]The modification was written by Ken Hornstein and is available at ftp://ftp.ncsa.uiuc.edu/aces/kerberos/misc_patches/patch.app-proxy.Since Kerberos is UDP-based, there are also the usual problems with UDP proxying; the proxy machine has to keep track of the state in order to know what packets are responses to what requests. This can cause difficulties in situations where there are lots of transactions or where packets are being lost.
It's worth noting that Kerberos also has a concept of proxy tickets. These are tickets that allow a server to act on behalf of another principal (for instance, a print service may use them to access a user's files). They don't have anything to do with proxying in the firewall sense.
21.5.5. Summary of Recommendations for Kerberos
- If you use Kerberos internally and wish to allow machines to authenticate from the Internet, you can allow inbound authentication, but you should use one of the one-time password add-ons to prevent password guessing.
- Allowing internal machines to authenticate to external Kerberos servers requires permitting dangerous amounts of UDP traffic. If you must allow it, restrict it to individual hosts and treat those machines as bastion hosts, or use proxying. Neither solution scales well.
- You must be able to completely trust the security of any Kerberos server you use for authentication. Even if you allow hosts to authenticate against external Kerberos servers, don't accept externally controlled authentication for internal services.
