Excessive TGS_REQ krbtgt/REALM@REALM (Possible misbehaviour in NetidMgr)

Tue Jul 6 19:43:52 EDT 2010

Hi all,

i've seem to come across some unexplainable behaviour (at least for me).

Situation sketch:

Linux Slackware KRB server A: MIT Kerberos 1.8.2 KDC/Kadmind
Linux Slackware HTTP server A: Apache 2.2.9 + mod_auth_kerb
Linux Slackware SSH server A: Openssh 5.3p1 +
openssh-5.3p1-gsskex-all-20100124.patch
Linux Slackware client A: MIT Kerberos 1.8.2 Client libraries/software
MAC OS X Snow Leopard client A: MIT Kerberos Libraries
Windows XP client A: Firefox browser / Putty development snapshot
2010-07-05:r8971 / KFW 3.2.2 + NiM 1.3.1

Now, from what i've understood, a usual KRB(5) transaction (soemwhat) goes
as follows:
(Assuming 'MAC OS X Snow Leopard client A' makes a SSH connection to 'Linux
Slackware SSH Server A')

MAC OS X Snow Leopard client A$ AS_REQ to KRB5KDC requesting
krbtgt/REALM at REALM
Linux Slackware KRB server A$ Requests PREAUTH
MAC OS X Snow Leopard client A$ AS_REQ to KRB5KDC requesting
krbtgt/REALM at REALM <-- After PREAUTH
Linux Slackware KRB server A$ Issues krbtgt/REALM at REALM to 'MAC OS X Snow
Leopard client A'

MAC OS X Snow Leopard client A$ TGS_REQ to KRB5KDC requesting
host/fqdn at REALM
Linux Slackware KRB server A$ Issues host/fqdn at REALM ticket to 'MAC OS X
Snow Leopard client A'

Focussing on the TGS_REQ specifically for the krbtgt/REALM at REALM we can
conclude the following:

A normal KRB(5) transaction will generate:
- 1 TGS_REQ for krbtgt/REALM at REALM
- 1 TGS_REQ for host/fqdn at REALM

Within the limits of the ticket expiration window these TGS_REQ should
generate a local credentials cache sufficient to reconnect from 'MAC OS X
Snow Leopard client A' to 'Linux Slackware SSH server A' without another
TGS_REQ for krbtgt/REALM at REALM or a TGS_REQ for host/fqdn at REALM. Meaning
that during ticket validity only 1 TGS_REQ for both krbtgt/REALM at REALM and
host/fqdn at REALM is made, despite of amount of SSH connections requested.

This very basic KRB ticket issuance process sketch is true in reality.
During my tests, when connecting with the local SSH client from 'MAC OS X
Snow Leopard
client A' to 'Linux Slackware SSH server A' this is exactly what happens.

Now for the possible 'misbehaviour'

Repeating the same actions (making an SSH connection from kerberized SSH
client to kerberized SSH server) from 'Linux Slackware client A' to 'Linux
Slackware SSH server A' generates a TGS_REQ for krbtgt/REALM at REALM every
time a new SSH connection is initiated to 'Linux Slackware SSH server A'.
The same goes for SSH Putty connections from 'Windows XP client A' to 'Linux
Slackware SSH server A'. Every new SSH connection generates another TGS_REQ
for krbtgt/REALM at REALM.

Can anybody explain me this behaviour ? Is it expected ? I myself would not
expect another TGS_REQ for krbtgt/REALM at REALM every time a SSH connection is
initiated, because it can use the local credentials cache for the
krbtgt/REALM at REALM ticket. Also, the behaviour from 'MAC OS X Snow Leopard
client A' is as expected (described above), which could indicate that the
"issue/misconfiguration" would be on the client side, and not on the server
side.

Now, to mix yet another chain in this picture.

When initiating a HTTPS session with Safari as well as Firefox from 'MAC OS
X Snow Leopard client A' to 'Linux Slackware HTTP server A', i see a
expected KRB ticket issuance conversation. Per HTTPS virtual host 1 TGS_REQ
for HTTP/fqdn at REALM and 1 TGS_REQ for krbtgt/REALM at REALM regardless of
amount of HTTPS TCP connections.

On the other hand, when initiating a HTTPS session with Firefox from
'Windows XP client A' to 'Linux Slackware HTTP server A' a TGS_REQ for
krbtgt/REALM at REALM is processed for every single HTTPS TCP connection made.
Imagine opening a website containing 100 pictures. This would mean 100
TGS_REQ for krbtgt/REALM at REALM.
The strangest behaviour i've seen so far must be that when i close NetidMgr
1.3.1, -after-, receiving a ticket for HTTP/fqdn at REALM and
krbtgt/REALM at REALM, the excessive TGS_REQ's are not showing in the MIT
Kerberos logs anymore.

Would anyone be so kind to elaborate on this behaviour or point out that
this is a bug/misconfiguration ? The frustration here is that the 'MAC OS X
Snow Leopard client A' seems to be doing it all right whereas the other
clients don't. The most annoying about all this must be the thousands of
TGS_REQ (krbtgt/REALM at REALM) log entries for every single HTTPS
connection...

On a final note i would like to share some configuration files:

Linux Slackware KRB server A:
kdc.conf -> http://pastebin.com/ETd6MKya
krb5.conf -> http://pastebin.com/uaKAsikf

Linux Slackware HTTP server A:
krb5.conf -> http://pastebin.com/uaKAsikf
https-syslog.svh.domain.tld.vhost -> http://pastebin.com/fHy0F7wj (Apache
HTTPD virtual host configuration)

Linux Slackware SSH server A:
krb5.conf -> http://pastebin.com/tc50XqKj
sshd_config -> http://pastebin.com/s6JqZgiY
ssh_config -> http://pastebin.com/wm3TvJ3V

Linux Slackware client A:
krb5.conf -> http://pastebin.com/tc50XqKj
ssh_config -> http://pastebin.com/wm3TvJ3V

MAC OS X Snow Leopard client A:
/Library/Preferences/edu.mit.Kerberos -> http://pastebin.com/T1srBwaa
/etc/ssh_config -> http://pastebin.com/JVg3itrd

Windows XP client A:
C:\windows\krb5.ini -> http://pastebin.com/w9FtmEVH

All the best,

Pavlovski