All ACAP sessions begin in the Nonauthenticated State. The client cannot issue most commands until properly authenticating to the server. This is done by the client issuing the AUTHENTICATE command.

Like IMAP’s AUTHENTICATE command and POP’s AUTH command, ACAP’s AUTHENTICATE command can be extended as necessary by implementing new authentication mechanisms. ACAP servers, as we have seen, advertise the mechanisms that they support. It is up to the client to choose a valid mechanism from the list.^[19]

ACAP authentication is generally done with the Challenge-Response Authentication Mechanism (CRAM) described in RFC 2195. Since this mechanism uses MD5 digesting, this is commonly called CRAM-MD5. This mechanism is also used by some IMAP and POP servers. It provides a better authentication capability than plain text username/password schemes since no unencrypted passwords need to be stored on a server or transmitted in the clear via the Internet.

There is generally no simple authentication mechanism in ACAP, although a server and client could implement one. This is due to the supposition that ACAP servers are to be used to store personal information in an Internet environment, so stronger authentication is preferred. All ACAP implementations are required by the proposed standard to implement at least CRAM-MD5 authentication.

A complete discussion of the CRAM-MD5 algorithms is beyond the scope of a book on email. However, take note that CRAM-MD5 requires that the client and server share a secret. That is, they must both be told to store the same piece of information before they can connect to one another. This is an attempt to make ACAP clients and servers more secure than most of today’s POP and IMAP clients and servers, but it also means that the systems administration overhead of setting up ACAP accounts will be significantly more difficult. Too, if a traveler wishes to use an arbitrary MUA with ACAP, she will need to carry appropriate authentication credentials with her. This may be an interesting part of attempting to widely deploy ACAP. One way to solve this would be for client and server to use an X.509 certificate scheme, much like current SSL-enabled Web browsers and clients.

A sample authentication with CRAM-MD5 shows the server responding to a client’s request with a string that includes a random number, a time/date stamp, and the full server name. The client uses that information along with the shared secret to compute its response. For example:

Client:  GH0l AUTHENTICATE "CRAM-MD5"
Server:  + "<[email protected]>"
Client:  "dwood 19d8a609da4da7a4904ce6e739d8a75d3890"
Server:  GH0l OK "CRAM-MD5 authentication successful"

Table 12-4 lists the ACAP commands that are valid in the Nonauthenticated State.