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
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/
IJmrMG+25a4DT+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/
ydHJUwYFdWwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw
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
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/
IJmrMG+25a4DT+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/
ydHJUwYFdWwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or //EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw
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.
