Kerberos over HIPPI at NCSA: Why it doesn't work right

The problem
Why is this?
So why can't we fix DNS?
The solution

The problem

You use Kerberos telnet, rlogin, ftp, etc. to connect from one host to another over the HIPPI network. The connection works, but when you get there you find you don't have an AFS token and the Kerberos ticket you forwarded doesn't work (you get errors complaining about incorrect network address).

Why is this?

First of all, the problem has nothing to do with the HIPPI network itself, but the way the HIPPI addresses are registered in DNS. To understand why this is the case you need to understand that a Kerberos ticket has one or more IP addresses encoded in it and when you try to use the ticket the Kerberos server (KDC) checks the IP address that your request is coming from against the IP addresses in the ticket. If it doesn't find the address in the addresses in the ticket, it denies the request and you get an "Incorrect net address" error. This is a security feature to help prevent your ticket from being stolen and used by a third party.

What this means is that when you forward your ticket from one host to another it can't just be copied over, it needs to have the IP addresses changed to the IP addresses of the new host. An example might show this more clearly. Let's say we have two hosts, modi4 and hod1. You are on hod1 and making a Kerberos connection to modi4. What happens is that the Kerberos code on hod1 does a DNS lookup on modi4 and gets back modi4's IP address(es) and then makes a new copy of your Kerberos ticket with these addresses encoded and forwards over the ticket. Then when you try to use the ticket on modi4 it sends it to the KDC which checks and verifies that you are on modi4 and it's IP address is in your ticket, so everything works.

But if you are going from hod1 to modi4-hippi, you run into problems. The reason is that when the Kerberos code gets the IP addresses to put into the copied ticket it gets the IP addresses for modi4-hippi. Then when the ticket gets sent to the KDC it sees the ticket come from modi4, but sees an IP address in the ticket is for modi4-hippi, and it rejects the ticket. A big thing to keep in mind here is that despite the similarity in names between modi4 and modi4-hippi there is no way for the KDC to know they are the same host.

So why can't we fix DNS?

It is true we could modify DNS so that when you do a forward lookup on modi4 you also get it's HIPPI address in addition to the other addresses it had. If we did this then Kerberos would work fine.

The reason we can't do this is because DNS servers do something called round-robining. What this means is that if a host had multiple entries in DNS, it will hand them out in turn, one after another. So one query you get one, the next you get another. This works great for things like web servers where you want to distribute the load among a number of machines but, IMHO, break many other things. So what happens if we add the HIPPI interface to the forward lookup is that one connection in every two or three (depending on the number of interfaces) tries to go the HIPPI interface, and since the HIPPI is not reachable from the Internet the connection fails and the HELP desk gets a complaint. Multiply this by a few hundred users and you see why we can't do this.

The solution

The only way to solve the problem of having an unusable ticket when going across HIPPI is to do a kinit once the connection is established and get a new ticket. The connection will be persistent and will remain encrypted if an encrypted session was initiated. This will give you a valid ticket and a usable AFS token.

Back to NCSA Kerberos Information

Questions or comments about this page may be sent to kerberos@ncsa.uiuc.edu