Kerberizer Readme (9/2003)
I) What is Kerberizer?
II) Installing the Binaries
III) Uninstalling the Binaries
IV) Configuring Windows 2000/XP's Built-in Kerberos
V) How Does Kerberizer Work?
VI) Debugging and Troubleshooting
VII) Using Kerberizer with NAT
VIII) Extra Requirements for Windows 9X and NT
IX) List of Tested Clients
Kerberizer was written by Steven Michaud
(smichaud at pobox.com)
I) What is Kerberizer?
Kerberizer is a Windows Sockets service provider (basically, an
extension of the Microsoft Windows TCP/IP stack) that adds
GSSAPI-based Kerberos 5 authentication to "insecure" POP, IMAP
and FTP Windows clients (ones that (normally) send account names
and passwords across the net in plain text). It can also encrypt
the traffic between the client and the server. (For FTP it
encrypts the control channel and (optionally) the data channel.
For POP and IMAP it can be set to encrypt all traffic -- though
this currently isn't terribly useful.)
Kerberizer has been tested with a small number of clients (see
the list below), but in principle it should work with any Windows
POP, IMAP or FTP client. It works with current versions of all
the major free GSSAPI-Kerberos-5 servers -- UW IMAP, Cyrus IMAP,
the FTP daemons from MIT Kerberos and Heimdal Kerberos, and
ProFTPD with the addition of mod_gss
(http://gssmod.sourceforge.net/). It does not work with non-
GSSAPI Kerberos 5 servers, such as Qualcomm's Qpopper.
Kerberizer works with any version of 32-bit Windows. But it can
only be as secure as the underlying OS, and Windows 9X (Windows
95 through Windows Me) is not very secure. Nor are Windows NT,
2000 and XP sufficiently secure unless the partition where you
install Kerberizer uses the NTFS file system. For this reason I
don't recommend using Kerberizer on Windows 9X, or on Windows
NT/2000/XP without the NTFS file system, unless no-one else has
physical access to your computer (or at least only people you can
trust have access). See "How Does Kerberizer Work?" below for
more information. (Note: Windows 9X and NT users will need to
download and install some extra operating system components. See
"Extra Requirements for Windows 9X and NT" below.)
Kerberizer is not itself a Kerberos package. You can install the
MIT Kerberos for Windows package (or one of its relatives), and
Kerberizer will use that. Or on a suitably configured Windows
2000 or Windows XP computer, Kerberizer can use the operating
system's built-in Kerberos 5 support via the Windows SSPI.
(Though there may be problems doing FTP if you use the Windows
SSPI. See below under "Configuring Windows 2000/XP's Built-in
Kerberos".)
Kerberos is an authentication protocol developed at MIT, designed
for use on a network that is assumed to be insecure. (For
example, it never sends passwords over the net, even encrypted,
and the authentication tokens it does send expire after a few
hours.) As long as the Kerberos servers (where the KDC and
kadmin daemons run) remain secure, it is very unlikely that
compromises to the network or to other computers will result in a
compromise to the authentication system as a whole. In this
respect Kerberos is significantly better than password-over-SSL
(as used by SSL POP or SSL IMAP), which sends accounts and
passwords over an encrypted pipe -- if someone compromises a
single busy server and installs a hacked service daemon, in a few
hours they can harvest most of the users' accounts and passwords.
The MIT and Heimdal Kerberos implementations make it easy to
isolate the KDC and kadmin daemons from other services, which in
turn makes it easier to secure the computers on which these
daemons are run. If you want to know more, the best place to
start is Ken Hornstein's Kerberos FAQ, posted periodically to the
comp.protocols.kerberos newsgroup and also available at
http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html.
For all its technical excellence, Kerberos still isn't very
widely used, especially on non-Unix platforms like Windows.
Setting up a Kerberos authentication system is only slightly more
complex than doing password-based authentication over an
encrypted pipe. But many fewer clients are available with
Kerberos support than with some kind of support for encrypted
pipes. And Microsoft has further muddied the waters by choosing
to go its own way with Kerberos: Microsoft's KDC is emphatically
not isolatable from other services. And though some Kerberos
support is available in Internet Explorer and Outlook, it's not
possible to use it except with Microsoft's servers. (For
example, to use the Kerberos support in Outlook to access your
email, you must use an Exchange server and your computer must
belong to a Windows domain.)
Kerberizer is intended to tackle both of these problems. It adds
Kerberos support to whole categories of Windows clients that
didn't have it before. It adds more flexible Kerberos support to
Outlook and Outlook Express, making it possible for them to use
Kerberos authentication against non-Microsoft servers. And, on
Windows 2000 and Windows XP, it can use these operating systems'
built-in Kerberos support (via Microsoft's SSPI) to authenticate
against non-Microsoft servers.
Kerberizer's starting point was a "Layered Service Provider"
sample program originally distributed by Microsoft. Kerberizer
makes substantial corrections and additions to that code. For an
interesting article on writing a Windows Sockets service
provider, see "Unraveling the Mysteries of Writing a Winsock 2
Layered Service Provider", Wei Hua, Jim Ohlund, Barry Butterklee,
Microsoft Systems Journal, May, 1999 (this article is currently
available at
http://www.microsoft.com/msj/0599/LayeredService/LayeredService.aspx).
II) Installing the Binaries
1) Install and configure Kerberos client software, or (if you
have Windows 2000 or Windows XP) configure the Kerberos
support built into your operating system.
Kerberizer is known to work with MIT's Kerberos for Windows.
It should also work with many of the Kerberos 5 client
packages distributed by universities in the US and Canada --
so long as these packages expose the GSSAPI and KRB5 APIs, and
so long as Kerberizer can find the DLLs containing those APIs
(usually called gssapi32.dll and krb5_32.dll). You will need
either to ensure that the directory containing those DLLs is
the first in your PATH, or that Kerberizer's DllPath and
Krb5DllPath settings are set appropriately. (See Settings.txt
for full information on Kerberizer's settings. Kerberizer
must of course be installed before you can view or change its
settings.)
If you are running Windows 2000 or Windows XP and wish to use
its built-in Kerberos support, see "Configuring Windows
2000/XP's Built-in Kerberos" below. (But note that, because
Windows' SSPI doesn't support "channel bindings", you may need
to patch your MIT or Heimdal FTP server. See Patches.txt for
more information.)
2) Choose a permanent location for Kerberizer's binary files
(those in the Binaries subdirectory of the Kerberizer
distribution). On Windows NT, 2000 and XP this should be a
directory on an NTFS partition to which ordinary users
(Everyone, Guest and members of Guests and Users) don't have
Write or Modify access. (Windows 9X and non-NTFS partitions
on Windows NT/2000/XP lack file and directory level security,
which is one of the reasons I don't recommend using Kerberizer
on any version of Windows 9X, or from a non-NTFS partition,
unless no-one else has physical access to your computer.) On
Windows 2000 and Windows XP it should be safe to install
Kerberizer to a subdirectory of the "Program Files" directory
(if you haven't changed the default security on either
directory). On Windows NT you will always need to tighten the
security of the directory where you install the Kerberizer
binaries. Even on Windows 2000 and XP, you may wish to deny
Write or Modify permissions to everyone but Administrators,
SYSTEM and CREATOR OWNER -- in other words, it may be wise to
remove these permissions even from the Power Users group,
which has them by default.
Run "Register.bat" from where you've installed it. This
registers both Kerberizer (Kerberizer.dll) and Kerberizer
Settings (KerbSettings.dll) with the operating system. Then
go through the following steps to create a shortcut to the
Kerberizer Settings program:
a) Click on the "Start" button and choose "Run".
b) Type "mmc" in the "Open" box, then click on OK.
c) Choose "Add/Remove Snap-in" from the "Console" menu.
d) Make sure the "Standalone" tab is selected, then choose
"Add".
e) Scroll down to "Kerberizer Settings" and double-click on
it. (If you don't see "Kerberizer Settings",
KerbSettings.dll didn't get registered by Register.bat.)
f) Click on the "Close" button in the "Add Standalone Snap-
in" panel.
g) Click on the OK button in the "Add/Remove Snap-in" panel.
h) Choose "Save As" and change the name of the file to
"Kerberizer Settings" (or if you don't hide known file
extensions, "Kerberizer Settings.msc"). Now you will be
able to run Kerberizer Settings by choosing "Programs :
Administrative Tools : Kerberizer Settings" (or
"Kerberizer Settings.msc").
3) If you're using Windows 2000 or Windows XP's built-in Kerberos
support, tell Kerberizer to use SSPI by setting
"UseWindowsSSPI" to "TRUE" (in Kerberizer Settings under
"Settings : GSSAPI").
4) Set up your favorite IMAP, POP or FTP client to connect to a
GSSAPI-Kerberos-5 server. You will need to choose a fake
password (I usually use "password"). For convenience, you
should probably also tell your client to save this fake
password. Kerberizer will intercept the password and do a
true Kerberos authentication. Even the fake password won't
get sent out on the net.
III) Uninstalling the Binaries
WARNING: Do not delete or rename Kerberizer.dll without first
unregistering it. Doing so may make your computer
unresponsive and unbootable.
1) First unregister Kerberizer's binaries by running
"Unregister.bat".
As you can see by looking at Unregister.bat, the command to
unregister just one of the binaries is "regsvr32 /u
Kerberizer" or "regsvr32 /u KerbSettings". The command to
(re)register just one of them is "regsvr32 Kerberizer" or
"regsvr32 KerbSettings". These commands must be run from the
directory where Kerberizer.dll and KerbSettings.dll are
located. There is no harm in unregistering either program
multiple times, or in registering either multiple times --
each program refuses to register itself more than once, or to
unregister itself more than once.
2) Promptly restart your computer.
If you delay restarting for too long after having unregistered
Kerberizer.dll, system DLLs that use the network stack may
start to behave strangely. This only happens on Windows
2000/XP, and as far as I can tell is due to problems with the
Winsock SPI on those platforms.
3) After your computer has restarted, you can delete any or all
of Kerberizer's files.
IV) Configuring Windows 2000/XP's Built-in Kerberos
Note that, because Windows' SSPI doesn't support "channel
bindings", you may need to patch your MIT or Heimdal FTP server
in order to do Kerberized FTP. See Patches.txt for more
information.
If your computer runs Windows 2000/XP and belongs to a Windows
domain whose domain controllers are Windows 2000 or Windows XP
based, you shouldn't need to do any further configuration. You
will be able to use Kerberizer to authenticate against Unix-based
GSSAPI-Kerberos-5 POP, IMAP and FTP services (though the FTP
services may need patching). Unless you've configured your
Windows domain's KDC to trust an MIT or Heimdal KDC (via an
external trust relationship), these POP, IMAP and FTP services
will need to use your Windows KDC for authentication.
Otherwise you should remove your Windows 2000/XP computer from
whatever Windows domain it may belong to and perform the
following steps. They will make your computer authenticate to an
MIT or Heimdal KDC, and will map one or more of its accounts to
"principals" in the Unix-based Kerberos realm.
a) If you haven't done so already, install the Support Tools
which are available in the SUPPORT\TOOLS directory of the
Windows CD. (Run SETUP.EXE.)
b) Ask the administrator of your Kerberos realm to create a
host principal for your Windows 2000/XP computer. The
following command is an example of how this might be done.
You need to know and remember the password, because you will
use it below.
ank -pw password host/mycomputer.domain.edu
c) Log in to your Windows computer as Administrator and enter
commands like the following at a command prompt. (Your
Kerberos realm is assumed to be MYREALM.EDU. Its KDC is
assumed to be running on kdc.domain.edu. The password is
the one from step b.)
C:\> ksetup /setdomain MYREALM.EDU
C:\> ksetup /addkdc MYREALM.EDU kdc.domain.edu
C:\> ksetup /setmachpassword password
d) Reboot your Windows computer and log in again as
Administrator.
e) Create user accounts on your Windows computer and use a
command like the following to map each one to a principal in
your Kerberos realm. It will be most convenient to make
each account name the same as the Kerberos principal, but
this isn't necessary.
C:\> ksetup /mapuser user@MYREALM.EDU user
Alternatively you can use the following command to map all
of your local user accounts to Kerberos principals at the
same time, if both sets of accounts use the same namespace:
C:\> ksetup /mapuser * *
V) How Does Kerberizer Work?
Kerberizer is a Windows Sockets service provider. It uses the
Windows Sockets Service Provider Interface (Winsock SPI) to
"chain" itself to the network protocols underlying the Windows
Sockets Application Programming Interface (Winsock API). Thus it
sits between your computer's network protocol stack(s) and the
programs that use the Winsock API to do networking. A Windows
Sockets service provider can in principle see (and alter) any of
the traffic going into or out of the Winsock API (using any of
the "high level" protocols, such as TCP, UDP, NetBIOS and
AppleTalk). More than one Windows Sockets service provider can
be installed at the same time, in "chains" up to eight levels
deep. The service provider at the bottom of a chain (closest to
a protocol stack, such as the TCP or UDP stack) is the first to
see incoming traffic, and the last to see outgoing traffic.
Kerberizer is interested only in TCP and UDP traffic. With its
default settings, it monitors outbound connections to the
standard ports for IMAP, POP and FTP traffic. (You can add or
substitute non-standard ports.) If it sees a password-based
authentication to any one of these services, it intervenes to
alter it into a GSSAPI-Kerberos-5 based authentication. Neither
the client nor the server are aware that anything unusual is
going on. For the server it's an ordinary GSSAPI-Kerberos-5-
based authentication. The client still thinks it's doing clear-
text-password authentication. So at the appropriate time it
still tries to send a password. But Kerberizer doesn't allow the
password out onto the net (usually the password message is
replaced with some kind of noop message). Since GSSAPI-Kerberos-
5 authentication is challenge-response, it usually generates more
traffic between client and server than password-based
authentication. Kerberizer handles this by calling directly to
the next provider in the chain (usually the "base provider",
which is the actual protocol stack). The Winsock API client
never sees the extra traffic.
After having done GSSAPI-Kerberos-5 authentication on a POP or
IMAP connection, Kerberizer (by default) passes through all
subsequent traffic unchanged. But for FTP connections it
encrypts/decrypts traffic on the control channel, and optionally
also on the data channel. (Kerberizer can also be set to
encrypt/decrypt POP and IMAP traffic, though this currently isn't
very useful.) For various reasons encryption and decryption
requires buffering of the data sent by the server to the client,
so that there isn't necessarily a one-to-one correspondence
between client calls to the Winsock API "read" function and
actual attempts to read data from the server. Once again this is
entirely transparent to both the client and the server.
Kerberizer will also do client-to-server buffering when needed
(which isn't normally the case).
Kerberizer is careful not to interfere with clients that are
already Kerberized, or to secure traffic that should not be
secured (for example an anonymous FTP connection, which it can
identify by the account name that's used -- i.e. "anonymous" or
"guest", or whatever else you add to Kerberizer's
AnonymousAccounts setting). To be more efficient, Kerberizer
monitors as little traffic as possible, and decides early in any
connection whether or not it's interested in the traffic.
Many of you will have noticed that Kerberizer has the same
structure as a "man in the middle" exploit. Of course Kerberizer
wears a white hat, not a black one. But it'd be possible to
alter it to do nasty things (such as adding virus-infected
attachments to your email). So when you install Kerberizer on a
computer, you want to make sure that no-one can replace it with
something sinister. On Windows NT, 2000 and XP, you must use an
account with Administrator privileges to register Kerberizer as a
Windows Sockets service provider. And as long as you install
Kerberizer's binaries to a directory on an NTFS partition whose
permissions are sufficiently restricted, only trusted users will
be able to delete or alter the binaries after they've been
installed. But on Windows 9X (Windows 95 through Windows Me)
anyone can register a Winsock service provider, and anyone (even
on Windows NT/2000/XP) can change or delete files (and
directories) on a non-NTFS partition. For this reason I don t
recommend using Kerberizer on Windows 9X, or from a non-NTFS
partition on any version of Windows, unless you're quite sure
that no-one else with physical access to your computer is going
to replace it with a hacked copy.
VI) Debugging and Troubleshooting
If you set "TracingOn" to TRUE, Kerberizer will log network
traffic to files in the user-level or system-level TEMP
directories. (On Windows 2000 and XP, the user-level TEMP
directory is usually [USERPROFILE]\Local Settings\Temp, and the
system-level TEMP directory is usually [SystemRoot]\Temp.) Each
program that uses Kerberizer (via the Winsock API) gets its own
log file, whose name is the program's executable plus ".log" (so
the log for Outlook Express will be called "msimn.exe.log"). All
Winsock calls get at least minimal entries in the logs.
"Interesting" traffic is logged in full. What counts as
"interesting" is all traffic going to or coming from ports that
Kerberizer considers IMAP, POP or FTP ports, plus any additional
ports listed under "TracedPorts".
To be able to interpret these logs, you will need to understand
the appropriate protocol. The ultimate resources are the RFCs
(the Kerberizer distribution includes recent copies of all the
relevant ones). But you can also learn a lot by comparing logs
of sessions you are trying to secure with logs of insecure
sessions made using the same protocol. Even if you don't have
any trouble with Kerberizer, I think you'll find it interesting
to log brief sessions in all the supported protocols (IMAP, POP
and FTP), then look at the logs.
Don't leave "TracingOn" on continuously. Its log files can grow
large very quickly, and it will slow your network access down
considerably.
NOTE: The debugging technique described in the next three
paragraphs (changing the Winsock service provider order) has
been temporarily disabled, because it has not yet had
sufficient testing.
A second debugging technique is only useful if you are using
Kerberizer together with another Windows Sockets service
provider. Windows Sockets service providers are quite rare, so
it's very unlikely that you're currently using another one. (In
fact, I haven't been able to find one to test Kerberizer with.)
But if you are, it's important to know that Windows Sockets
service providers are installed in chains, and that each
provider's position in the chain determines the order in which it
sees network traffic (service providers at the "bottom" of each
chain see incoming traffic first and outgoing traffic last). So
you may be able to solve problems by changing the order of the
service providers in each chain.
Kerberizer installs itself at the top of each TCP and UDP chain.
If you have another Windows Sockets service provider, you should
be able to see the chain order, and to change it, using the
Kerberizer Settings program. If the "Advanced" view isn't
already on, select it by right-clicking on "Kerberizer Settings",
then selecting "View" and "Advanced". If you have more than one
Windows Sockets service provider, you should see more than one
entry under "Layered Service Provider Order". To change their
order, right-click on one of them and choose "Move Up" or "Move
Down".
Be aware that other Windows Sockets service providers may not
expect you to change their chain order, or to install another
service provider on top of them. They should still function
correctly after the order is changed. But before uninstalling
your first service provider, you should probably change the order
back to what it was originally, and possibly also unregister
Kerberizer.dll (by running the command "regsvr32 /u Kerberizer"
at a command prompt in the directory that contains
Kerberizer.dll).
VII) Using Kerberizer with NAT
In recent years there's been increased demand for a way to share
a single "real" internet address among multiple computers.
(Maybe you don't want to pay your ISP for more than one, or maybe
your subnet doesn't have enough IP addresses available.) A
popular solution is to have one of your computers be a gateway to
the Internet for the others, and run something on it called a
Network Address Translation (NAT) server. Your gateway has a
"real" ip address, but all your other computers have addresses in
one of the "private" ranges (which need not be unique, but which
for that reason are illegal on the "public" Internet, e.g.
192.168.X.X). The NAT server keeps a state table of all the
connections to the Internet from any of your other computers. It
replaces the private ip addresses in outgoing traffic with your
one "real" ip address, so that it seems to the outside world like
all the traffic is coming from your gateway. For incoming
traffic the NAT server "translates" the other way -- using its
state table to route traffic to the computer that originated the
connection (one of your computers with a private ip address).
If a Kerberos client requests it (and many Kerberos packages make
this happen by default), a Kerberized server checks the ip
address of the client it's talking to, to make sure the client
isn't pretending to be someone else. (The client may request
that its ip address be included in the authentication token it
gets from the KDC, which the client sends on to the application
server. If an ip address is present, the application server
checks it against the ip address the client appears to have
connected from, and rejects the connection if they don't match.)
Problem is, after address "translation" the ip address the client
thinks it has will always be different from the ip address the
server thinks the client is connecting from.
Kerberos 5 gives clients the option to turn off address checking
by letting them use "addressless tickets" (which are
authentication tokens that contain no ip addresses). If your
Kerberos client software supports addressless tickets, you can
turn that support on. If it doesn't (like MIT's Kerberos for
Windows 2.1.2), you can work around the problem by turning on the
following Kerberizer options -- "UseKinitPopup",
"PopupGetAddresslessTGT" and possibly also
"PopupForceAddresslessTGT". None of this is necessary if you're
using Windows 2000/XP's built-in Kerberos support, which always
gets addressless tickets.
Addressless tickets work fine with the UW and Cyrus IMAP and POP
servers, ProFTPD-plus-mod_gss, and the most recent version
(1.3.1) of MIT's FTP daemon. But Heimdal's FTP daemon, and all
versions of MIT's but the most recent, also use another kind of
address checking -- this is called "channel bindings" and is part
of the GSSAPI protocol. It doesn't get turned off when you use
addressless tickets. So if you want to use Kerberizer to do FTP
over a NAT server, you may need to patch your FTP server, or
convince the server's administrator to do so. Patches for
Heimdal's FTP daemon and for the last version of MIT's that still
used channel bindings are included with the Kerberizer
distribution. These are discussed in Patches.txt.
You may also need these patches if you want to use Windows
2000/XP's built-in Kerberos support to do Kerberized FTP, even if
you're not using a NAT server. Windows's SSPI has no support for
channel bindings.
VIII) Extra Requirements for Windows 9X and NT
1) Microsoft Management Console (Windows 9X and NT)
The Kerberizer Settings program is an "MMC snap-in", but the
Microsoft Management Console was first released with Windows
2000. So Windows 9X and NT users will need to download an
installer for this component. What appears to be the most recent
version is called IMMC.EXE, and is currently available at
http://support.microsoft.com/support/mmc/MMCus12.asp.
(Note: For reasons that aren't clear, MMC isn't fully functional
on Windows NT, and some of the Kerberizer Settings program's
menus are missing. The most important of these is one that lets
you make all the "Advanced" settings visible. I've worked around
this problem by having Kerberizer Settings always show all
settings on Windows NT.)
2) Regsrv32.exe (Windows 9X and NT)
This is the program that's called by "register.bat" and
"unregister.bat" to register or unregister Kerberizer.dll and
KerbSettings.dll with the operating system. Windows 9X and NT
users can currently download an archive containing this program
at http://support.microsoft.com/?kbid=161983. Copy the program
to either "C:\WINDOWS\SYSTEM" (on Windows 9X) or
"C:\WINNT\SYSTEM32" (on Windows NT).
3) SpOrder.Dll (Windows 9X)
The code in Kerberizer.dll (called by Regsvr32.exe) that
registers and unregisters it with the operating system requires
an "SpOrder.Dll". This comes with Windows NT, 2000 and XP, but
not with Windows 9X. Unfortunately it isn't available in a
convenient download. But it does get installed when you install
the "Core SDK" component of the Microsoft Platform SDK. After
installing this component, copy SpOrder.Dll from the "C:\Program
Files\Microsoft SDK\Bin\winnt" directory to "C:\WINDOWS\SYSTEM".
The Platform SDK is currently available at
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/.
IX) List of Tested Clients
IMAP/POP
Mozilla (1.0 and up)
Netscape (4.X)
Outlook Express (5.X and 6.X)
FTP
FTP Commander (5.80)
Internet Explorer (5.X and 6.X)
Mozilla (1.0 and up)
Netscape (4.X)
Prishtina FTP (1.2)
SmartFTP (1.0)
WS_FTP LE (5.08)
Download Latest Version
Kerberizer1.01.zip (1.6 MB)
