Author: Adam Back, Bill Heelan
$Date: 2001/04/23 13:57:08 $
$Revision: 1.3 $
In the pop mail system (project Cacophonix), it is planned to use the existing authentication mechanisms of POP, and ESMTP. These mechanisms typically involve the user sending his username and password to the server, and the server having a database of user names and passwords.
The following authentication protocol is designed to remove a database lookup, and to allow the user's password to securely pass attributes about the user. In particular, we want to avoid having to contact the nym server or key server in order to authenticate the user.
The certificate is generated by the nymserver at nym creation time, and sent to the user. (At the same time, the nym server will also generate and send the MAC key (nym-mac-key.html) shared by the mail system and the nym.) The certificate has the following required fields:
cert-vers
cert-expiration
cert-owner
nym-type
mail-limit
volume-limit
pop-quota
{Sig | MAC}
Question: Give the cert birth, retirement and death times, to avoid problems in the future? (I.e. learn from public key cert experience?)
Question: Do we need a cross-post limit for news?
The certificate is preceded by one byte packet version and type fields, having the following definition:
Each field of the certificate is a pair, consisting of a name and a value. Both the name and the value have a one byte length, followed by that many bytes of data. An exception is if the length byte is all 1s (i.e. 255), in which case the following 3 bytes (in network byte order) contain the length. All multi-byte data fields are considered to be in network byte order (big endian).
The certificate fields have the following meanings:
The secret key is shared by the mail system and the nymserver. When the user connects to the mail server using ESMTP or POP, he sends his nym name as the USER and the certificate as the PASS field. The mail system can store the nym's current certificate version in a file in its mail directory. It can cheaply verify the certificate using the check-password function, which will just verify that the MAC is valid, and that the version numbers are correct.
Note: We only need to check the cert version number if we want to downgrade an indivdual nym's capabilities, otherwise we can trust the nym not to use an older cert with fewer capabilities.
Note: The only fields really need at the moment are cert-owner, nym-type and the MAC. Mail-limit and size-limit are needed if we want to avoid lookups for per-nym information.
The user must keep the certificate secret, and the certificate should never be sent in the clear to the mail server as, someone may snoop on the connection and get it. The certificate authentication mechanism is vulnerable to replay if used directly so must always be used inside an encrypted tunnel, which has replay protection, or inside trusted networks.
If the secret key is compromised, the mail server check-password function can tell the user that the user name and authentication failed. Then the nym can authenticate itself to the nymserver using its signature key, and get a replacement certificate using the new secret key.
Copyright © 2000 Zero-Knowledge Systems Inc.
All Rights Reserved