ticket steal possibility

[Nikolai Tenev]

 Hi everyone,
I need some help or information source, to resolve one big (for me) problem 
with MIT Kerberos.

Software:
CentOS 4.4
Kerberos 1.3.4
OpenSSH 3.9p1

The Network Description:

Used realm is @EXAMPLE.NET
Two servers from same realm and two clients from same realm but different 
instances.

Server one has a host ticket host/server1.example.net at EXAMPLE.NET
Server two has a host ticket host/server2.example.net at EXAMPLE.NET
Client one has a client ticket client1/support at EXAMPLE.NET
Client two has a client ticket client2/developer at EXAMPLE.NET

On server one (server1) in krb5.conf I have a record:

 auth_to_local = {
   RULE:[2:$2](support)s/^.*$/root/
 }

On server two (server2) in krb5.conf I have a record:

 auth_to_local = {
   RULE:[2:$2](support)s/^.*$/root/
   RULE:[2:$2](developer)s/^.*$/root/
 }

Both clients use ssh to conect to remote servers from their workstations.
According this client2 with realm client2/developer at EXAMPLE.NET can do login 
as root on server2 but can not to do login on server1. Other user client1 
with realm client1/support at EXAMPLE.NET can do login as root on both servers. 
At this time everything is OK, and work as I expect.

The problem:

When client1 is logged in from his workstation1 as root on server2, the ticket 
of client1 is forwarded and stored in file /tmp/krb5cc_0_r10108 owned by root 
(root:root) and chmoded 600. But if in same time client2 make connection from 
his workstation2 to server2 as root, he can read/copy ticket file 
(/tmp/krb5cc_0_r10108 ) of client1 locally on his workstation2 and after that 
is easy to represent self as client1 to server1 and grant root access before 
ticket of client1 expire.

I search in Google for information how to resolve this problem and find three 
common type of solutions.

1) To lock clients ticket by IP. Disadvantage is that some of users use their 
laptops remotely from different networks, and they need addressless tickets.

2) To not forward tickets from client to server. This solution works, but for 
now most of users use ssh-agent to forward their private keys from one 
session to another (in example client1 make ssh to server1 and the from 
server1 copy data to server2 via scp with his own ssh key). It's not good to 
drop this possibility for them on condition that they find it as usable. But 
supporting hundred ssh public keys on great number of servers is little hell 
that I hope to resolve with kerberos.

3) One "alternative" solution is to make ticket available for a short-short 
time (something about 2-3 seconds). But this not sound good enough to me. 
Even if our corporate network speed allow this solution, we can not be sure 
for others network. And even if the speed and times are perfect, if someone 
know about this system weakness, he can find way to catch the ticket and make 
ssh connection to another remote server with ticket that is steal. When ssh 
connection is established, even if ticket expire, connection not drop.

 Does anyone have some idea how to resolve this, or just link to useful 
documentation ?

 Thanks in advance !


-- 

Nikolai Tenev
Hosting Systems Support Engineer
Orbitel EAD - office Sofia
---------------------------------
Orbitel - Next Generation Telecom