Understanding Kerberos pt. 2

I'll tightly follow the explanations of The Moron's Guide to Kerberos. If you've read and understood it, you can probably skip this chapter.

If a user wants to access a service, then he has to authorize. For authorization in kerberos there is a Authorization Center (AC). On the MIT kerberos implementation, the AC is included in the KDC server. Here's what happens:

• The user talks to the AC and asks for acessing the service.
• The AC creates a random key (session key)
• Two packets are sent back to the user (or client process):
  • the session key and a string specifiing the service, both encrypted with the users password. If the client can decrypt it, then he can read the service string and therefore verify if he could decrypt it. If only the session key would have been sent, the user could not verify, because a key looks like a piece of random bytes.
  • the session key and the username, both encrypted with the service key. Here the mindful reader may ask, where this key comes from. Yes, we did not yet create this key. For later reference you should remember that these keys are random keys generated in the kerberos database using admin and that the service reads the key from a keytab file. These are simply shared secrets and file access to the keytab should only granted to the service itself.
• The client process decrypts the 1st package and stores the session key. On unix it is stores in a temporary file, on Windows it is stored in volatile shared memory.
• The client process creates a package that contains the current time and is encrypted with the session key. This 3dr package and the second package are sent to the server process. The timestamp is for avoiding "replay attacks", that means, if someone reads the package from network, he cannot reuse it later. The server will refuse the package if the "time skew" is to big.
• The server decrypts the 2'nd package and verifies the username. He also obtains the session key from there. After checking the integrity with the 3rd package, he can grant the user access to the service.

So what did we learn? If we want to make a user access a service, we need that:

• kerberos knows the user, and that the user posesses a password in the kerberos database. This is done by making a principal with "add_princpal username" in kadmin. kadmin asks you for a password.
• kerberos has to have a random key(= random password) for the service. This is acheived by making a "add_principal -randkey service/instance" in kadmin and then exporting the key to a keytab file on the service server machine with "ktadd -k keytabfile service/instance"
• In the above scenario everytime a user asks the AC for access to a service, he has to decrypt the 1st package with his password. Storing tis password is unsafe so he always has to enter the password! That's not what we want. How kerberos avoids this, you can read in pt. 3 of "understanding kerberos".