The Authorization State
The POP Authorization State can take many forms and still comply with the standard. In fact, any given POP client or server must only support one type of user authentication. This means, of course, that there may exist standards-compliant POP server and client implementations that cannot communicate. This situation should be avoided by supporting at least the basic username/password authentication mechanism in any new POP implementation.
There are an unlimited number of possible authentication mechanisms in POP, but only two are part of the standard protocol: username/password and the MD5-based APOP command. RFC 1734 proposed an extensible command (AUTH) to enable as many types of authentication as may be found necessary. RFC 1734 is a proposed standard.
Note
You don’t have to support the basic username/password authentication, especially if you are trying to enforce stronger authentication means. As we shall see with the APOP and AUTH commands, their effectiveness is reduced if a user’s mailbox can be accessed by user name/password authentication. In order to ensure interoperability though, we recommend that any POP server implementation allow a mailbox to be accessed by username/password authentication if no other mechanism is selected for that mailbox and that any POP client attempt username/password authentication if the preferred authentication mechanism is supported by the server.
POP clients should attempt to use the authentication mechanism that they prefer and be prepared to be rejected. If rejected by a server, they should continue to propose authentication mechanisms until they run out of available mechanisms or are unwilling to connect with a less secure means. Unfortunately, there is no way within the standard to allow POP servers to advertise which authentication mechanisms it supports.
Note
A POP server could advertise the available mechanisms in the comments of its banner greeting upon connection, but this would not be supported by existing clients. If you do something like this, test to see if such information is present, but do not rely upon it. That way, your implementation maintains standards compliance and the ability to talk to other servers than the ones you write!
Username/password authentication
The username/password and APOP mechanisms described in the standard only make an attempt to authenticate the user, they provide no transmission security. All standard POP transactions occur in plain text over the network. However, the proposed standard AUTH command does allow transmission security of the data if both the server and the client support it.
If basic username/password authentication is to be used, the USER command must be given, followed by the PASS command. Positive responses to both must be received before the server can be assumed to be in the Transaction State.
The USER command takes a single string as an argument that must exactly match a valid POP mailbox on the server. In addition, the server must allow username/password authentication for the particular mailbox.
The PASS command also takes a single argument; a string that must exactly match the plain text password of the user already identified by the USER command. This command can only be given immediately after a successful USER command.
Servers must decide when to return errors. If a server returns a positive status for a USER command only if such an account exists, the server is giving away account information, possibly to an intruder probing for valid accounts to attack. Therefore, servers may send negative responses only after the PASS command. In this way, the client will not know whether the server denied access based on the username, the password, or both.
Here’s an example of a POP login using the USER and PASS commands:
Client: USER mmouse Server: +OK User mmouse recognised Client: PASS mickey Server: +OK Welcome mmouse!
APOP authentication
The APOP command offers a simple way to enhance security on a POP server. This command has two arguments: a username that is identical to the username given in the USER command and an MD5 digest of a server-supplied timestamp and a password.
Combining a timestamp from the server and a shared secret (the password), APOP authentication effectively prevents replay attacks and avoids sending a password in plain text over the network. Naturally, this method still requires the password to be stored in plain text on both the server (and the client, unless the user is asked to provide it every time).
An APOP-capable server sends a timestamp to the client as part of the banner greeting. The banner greeting is the comment in the message sent to the client after the initial connection. The timestamp is required to be a world-unique string of the same form as the message identification (msg-id) for email messages described in RFC 822 and Chapter 2, Simple Text Messages. The timestamp should look like:
<[email protected]>
On a Unix system, each process has a unique identification number (called the process id, or pid). That number is guaranteed to be unique among running processes at that time. Also, the value of the system clock may be converted to decimal format at the time that the request is received from the client. So a server timestamp might take the form of:
<[email protected]>
where pid is the process id and
clock is the decimal value of the system clock at
that time. The server saves the timestamp as well as sending it to
the client in the banner greeting. The client combines it with the
password for the appropriate account and creates an MD5 digest to include in the APOP
command. The server also looks up the account’s password and
computes the same MD5 digest. When the server receives the
APOP command, it simply compares the two
strings, one from the client and the other calculated locally, and
sends a positive or negative reply based on the result.
The MD5 digest is sent in network byte order octets in hexadecimal format, where the hexadecimal alphabet uses lowercase ASCII characters (0123456789abcdef).
Naturally, the server must also check to see if APOP authentication is acceptable for the mailbox in question.
Details on the MD5 algorithm may be found in RFC 1321, if you need to create an MD5 encoder. However, most modern programming languages have MD5 functions available.[18]
An example APOP authentication sequence looks like this:
Client: APOP mmouse c4c9334bac560ecc979e58001b3e22fb Server: +OK mai1drop has 5 messages (18762 octets)
AUTH authentication
The AUTH command provides an extensible way for POP clients and servers to negotiate the appropriate authentication mechanism. It allows a POP client to propose an authentication mechanism and for the server to accept or reject it. There is no standard way for a server to advertise which authentications mechanisms that it supports.
The AUTH command is a proposed standard extension to POP3. It is defined in RFC 1734 and borrows heavily from the IMAP AUTHENTICATION command described in RFC 1731.
As with all other POP commands, the client initiates an AUTH request and names the authentication mechanism to be used. The server then responses with a series of challenges to which the client must respond. Each challenge by the server will consist of a plus sign character (+) followed by a space and some data in base64 encoding (see Chapter 3, Multipurpose Internet Mail Extensions, for details on encoding strings in base64). Client responses each consist of a line base64 encoded. When the negotiation is complete, the server will signify the acceptance or rejection of the process with a positive or negative status indicator.
The server must respond with a negative status indicator immediately if it does not support the authentication mechanism requested.
A client can cancel an AUTH negotiation
at any time during the negotiation by sending a line consisting of
just an asterisk (*) and a CRLF sequence. A server must then respond
with a negative status indicator (-ERR),
acknowledging the cancellation.
Optionally, clients and servers can negotiate a transmission encryption scheme, if both support it. This is done during the negotiation phase. If a transmission encryption scheme is negotiated, it takes effect immediately for the client after it sends the last response and for the server after it sends the positive status indicator. Once negotiated, the transmission encryption scheme encrypts all data between the two for the remainder of the session.
If a transmission encryption scheme is used, data must be sent between the parties as octet streams prepended by a four-octet field in network byte order (big-endian) that gives the length of the data stream. Obviously, the length of the data must fit into four octets, which limits the size of the data stream (to a very large value!) although the actual length of the data stream will be limited by the transmission encryption scheme used.
According to the standard, POP servers and clients can support any types of authentication mechanisms and transmission encryption schemes that they desire, as long as the negotiation and data transfer occurs as stated previously. For an example of a standards track authentication mechanism that can be used for either POP or IMAP, see RFC 2195 for the Challenge Response Authentication Mechanism (CRAM).
The QUIT command is valid in either the Authorization State or the Transaction State. In the Authorization State, this command informs the server that the POP session is complete and that the server should unlock any mailbox that was locked by a successful login.
The QUIT command looks like this:
Client: QUIT Server: +OK 1 message expunged. Bye!
Table 10-1 lists the POP3 Authorization State commands.
Command | Arguments | Description | Response | Status |
USER | <username> | Requests that the server use username/password authentication. Provides the name of a valid POP mailbox on the server. | Single line | Optional |
PASS | <password> | Provides the plain text password of a valid POP mailbox on the server. | Single line | |
APOP | <username> <digest> | Requests that the server use APOPauthentication. Provides the name of a valid POP mailbox on the server and an MD5 digest of a server-supplied timestamp and a password. | Single line | Optional |
AUTH | <authentication mechanism> | Requests that the server use the authentication mechanism given in the argument. A negotiation to verify the authentication follows this command if the server supports the mechanism requested. | Single line | Optional |
QUIT | Informs the server that the client is closing the session. | Single line | Required |