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).
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.)
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:
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.
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.
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.
SUPPORT\TOOLS directory of the
Windows CD. (Run SETUP.EXE.)ank -pw password host/mycomputer.domain.edu
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
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 * *
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.
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.
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).
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.
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.)
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).
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/.
IMAP/POP
FTP