Unfortunately, "supporting Kerberos" can mean a number of things.

The most basic level of Kerberos support is verifying a plaintext password
against the Kerberos database. Depending on the application, this may or may
not be secure. For example, since the Unix xlock application is designed to
verify passwords and (hopefully) is only run from on your local workstation,
verifying passwords against a Kerberos database is perfectly adequate.
However, if you have a POP server that verifies the PASS command by checking
the password against a Kerberos database, that is NOT secure, because the
password will travel over the network in the clear.

There are different levels of password verification, however. Unless a
program that does plaintext password verification uses the acquired TGT to
get a service ticket for a locally trusted service (that is, with the key in
a keytab on local disk), then an attacker can spoof the client with a TGT
encrypted in a known password.

The next level of Kerberos support is a "true" Kerberized application that
uses Kerberos tickets to verify identity and/or encrypt data. This is the
way that Kerberos was designed to function, and it provides the highest
level of security that Kerberos has to offer. Unfortunately, relatively few
applications support Kerberos to this degree.

If you use an application that claims to support Kerberos, you should find
out exactly what this means and determine if that is appropriate for your
environment. If you use Kerberos primarily as a single-signon system, then
having a POP server that verifies plaintext passwords against a Kerberos
database may be acceptable to you.

All of the Unix replacement commands that come with the MIT Kerberos
distributions (telnet, ftp, rlogin, rsh, etc), are "true" Kerberized
applications.