You can use cryptographic authentication to solve an important
security problem found in many network applications: the transmission of
passwords in plain text. Without cryptographic authentication, a client must
identify itself by sending a plain-text username and password.
For example, assume your Internet email account name is Harpo and your
password is swordfish. If your email service has POP3, the service uses the
following sequence of commands and responses to retrieve messages (C: denotes a
message from the client to the server; S: denotes a response from the server to
the client):
C: (opens TCP connection to server on port 110)
S: +OK POP3 Server Ready
C: USER harpo
S: +OK
C: PASS swordfish
S: +OK user/password acceptable
If your email service has Internet Mail Access Protocol 4 (IMAP4), the
service uses similar commands and responses to retrieve messages. In either
case, anyone with access to your network and a network sniffer can easily see
your valid username and password. Intruders can also use various software
utilities (such as NT 4.0's Network Monitor) designed to access all network
messages to learn your username and password. And the intruders don't even need
to be on site. They can use a remote client to access your network if your LAN
is connected to the Internet without adequate safeguards, such as a firewall.
You don't have to fall victim to intruders, however. Several preventive
measures exist, and the most common one is Kerberos.
For a Kerberos measure to work, you need to meet three requirements. First,
you must have a properly installed Kerberos authentication server on your
network. Second, the authentication server must recognize your mail user and
email server. Third, your email client and server software must support Kerberos
authentication.
In POP3, the authentication process is in the optional AUTH command. (RFC
1734 defines AUTH.) This command supports authentication with a variety of
mechanisms. The basic idea is for the client to request cryptographic
authentication via some scheme (in this example, Kerberos 4).
If the POP3 server supports the AUTH command, the server and the client go
through a short Kerberos challenge/response exchange, using information obtained
from a common Kerberos authentication server or ticket-granting service. If the
client supplies appropriate Kerberos credentials during the exchange, the server
accepts the connection.
With AUTH, the exchange between the client and server looks like this:
C: (open TCP connection to POP3 server on port 110)
S: +OK POP3 Server ready
C: AUTH KERBEROS_V4
S: + AmFYig
S: +OK Kerberos V4 authentication successful
In IMAP4, the authentication process is also optional. The basic IMAP
standard (RFC 2060) contains the authentication definitions. With the
authentication process, the exchange between the client and server looks like
the following:
C: (open TCP connection to IMAP4 server on port 143)
S: * OK IMAP4rev1 Server Ready
C: A001 AUTHENTICATE KERBEROS_V4
C: +amFYig
S: A001 OK Kerberos V4 authentication successful
Five important events occur when you use a Kerberos authentication process:
1. The server knows that the client is who it claims to be.
2. The client knows that the server is who it claims to be.
3. The client and server securely exchange a DES session key.
4. At no time is the user's name or password sent over the Internet
in plain text.
5. If a third party records the exchange, it cannot play back the
message to obtain fraudulent access to the system because timestamps are used in
the exchange.
You can further benefit from the authentication process if you take
advantage of an option in POP3 and IMAP4. Ordinarily, authentication processes
create a DES session key for one particular connection--the key is never used
again. In POP3 and IMAP4, however, you can implement a protection mechanism that
will let you use a DES session key to encrypt all subsequent messages. This
protection mechanism will prevent hackers from impersonating a valid user and
from viewing the contents of emails (regardless of whether traffic has been
secured with end-to-end encryption schemes). Unfortunately, the protection
mechanism is in effect only for data being exchanged between an email client
(user agent) and the local server. In addition, it works only during email
retrieval.