6.5 Firewalls, NAT, and Kerberos

Since Kerberos relies heavily on the proper functioning of DNS and some protocol messages include IP addresses in them, firewalls and NAT in particular pose obstacles to the proper functioning of Kerberos. First, let's examine what ports must be opened on a firewall if Kerberos protocol messages need to pass through it, and then look at the thorny issue of using NAT and Kerberos together.

There are several situations to consider from the perspective of a firewall administrator. The most common is a setup where client machines are located outside of a corporate firewall, and the KDCs and application servers are located inside of the firewall. All machines involved have public IP addresses and NAT is not in use. This setup is pictured in Figure 6-4.

Figure 6-4. Clients outside firewall, KDC and application servers inside firewall

In order for outside clients to obtain tickets for your Kerberos realm, several ports need to be opened through the firewall to your KDCs. These ports are required in addition to whatever ports are already open to communicate with the application servers. In a scenario like this one, it is very important that no plain text passwords pass through the firewall through your application servers; therefore, it is still recommended that individual applications use a layer of encryption on top of their usual protocol to prevent an accidental password exposure.

6.5.1 Kerberos Network Ports

To enable the clients outside of the corporate firewall to communicate with the KDC and Kerberized services inside the firewall, some ports must be opened on the corporate firewall (Table 6-1).

Table 6-1. Kerberos 5 ports for client-to-KDC communication

Machine	Local port (server)	Remote port (client)	Description
All KDCs	88/udp 88/tcp	Above 1024	Kerberos 5 ticket service
All KDCs	749/tcp	Above 1024	Kerberos 5 kpasswd service for client password changes
All KDCs	4444/udp	Above 1024	Kerberos 5 to 4 ticket conversion service
All KDCs	749/tcp	Above 1024	Kerberos 5 administration service (MIT and Heimdal)
Master/Administrative KDC	464/udp	Above 1024	Kerberos 5 password changing service (older password-changing protocol)

Strictly speaking, the only port that needs to be open for Kerberos to function properly is 88. The other ports can be opened as needed to provide their respective services to clients outside of the firewall.

Because of the inherent flaws in the Kerberos 4 protocol, it is not recommended that you open Kerberos 4 to the Internet. However, if you must open Kerberos 4 through your firewall, Table 6-2 lists the ports that it uses for client/KDC communication.

Table 6-2. Kerberos 4 ports for client-to-KDC communication

Machine	Local port (server)	Remote port (client)	Description
All KDCs	750/udp750/tcp	Above 1024	Kerberos 4 ticket service
All KDCs	751/udp751/tcp	Above 1024	Kerberos 4 admin service
All KDCs	761/tcp	Above 1024	Kerberos 4 password changing service

6.5.2 Kerberos and NAT

The next firewall scenario to consider is pictured in Figure 6-5. In this scenario, all of the KDCs and application servers are behind a corporate firewall, with publicly accessible, routable IP addresses. Clients are located outside of the corporate firewall but live in private IP address space behind a small NAT firewall.

Figure 6-5. KDCs and application servers behind firewall, with clients using NAT

Network Address Translation, or NAT, enables multiple machines to share a single IP address. In a NAT setup, clients inside of the NAT device have private, non-routable IP addresses, as defined in RFC 1918. These IP addresses, while valid, are not directly accessible to the Internet at large. The NAT device takes care of relaying requests between the internal machines and the larger Internet. NAT presents a problem to Kerberos since ticket requests contain the requestor's IP address. Because the clients requesting tickets in this case are using NAT, the IP address they provide to the KDC will be nonroutable. Since the private address on the ticket does not match the public address of the NAT device, Kerberized services will not honor any tickets issued for NAT clients.

For example, you have a user on a cable modem with a small NAT device. The public IP address of the NAT device is 132.68.153.28, and the internal network is the RFC 1918 range 192.168.1.0 to 192.168.1.255. A client at 192.168.1.2 requests a TGT from the Kerberos KDC inside of the corporate firewall. A TGT, valid only for the IP address of 192.168.1.2, is returned to the client.

The TGT exchange works fine, but the only valid address listed on the returned TGT is the internal NAT address of the client. As soon as the client attempts to obtain a service ticket using this TGT, the application will fail. Since the address listed on the ticket does not match the public address of the NAT device, an "incorrect net address" error will be returned to the client, and the authentication attempt will fail.

There are two approaches to solving this issue. Either every client in the NAT network can be configured to request tickets with the IP address of the external interface on the NAT device, or clients can be configured to request "addressless" tickets, that is, tickets that can be used from any IP address.

For MIT and Heimdal clients, use the -A option to kinit to request addressless tickets. Another, more general, solution if you're using MIT clients is to add the following line to the [libdefaults] section of your /etc/krb5.conf file:

noaddresses = true

This line is recognized by all applications that use the MIT Kerberos 5 libraries, and will cause applications to request tickets without addresses.

Using addressless tickets to support clients behind NAT devices presents little degradation in security. The only vulnerability that it presents is that if an attacker were able to obtain a copy of your credential cache, he could use your tickets regardless of his source IP address. It also makes replay attacks a bit easier, but as discussed in the previous section, Section 6.2.2, Kerberos includes other safeguards against replay attacks.