Mail Certificate Authentication Protocol

Author: Adam Back, Bill Heelan
$Date: 2001/04/23 13:57:08 $
$Revision: 1.3 $

Description

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:

pkt-vers
A 1 byte value indicating the version of this packet format.
pkt-type
A 1 byte value indicating the type of this packet. Here it would identify it as a symmetric mail certificate.

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:

cert-vers
An unsigned value specifying the certificate version. Normally 2 (?) bytes.

Note: This field is only necessary if we want to do revocation.
cert-expiration
A signed value, specifying the expiration date of the certificate, in seconds since the epoch. Normally 8 bytes (uses a ZkClock object).

Note: This field is only necessary if we want to do expiration.
entity-id
A block of data identifying the certificate owner. This is a standard entity identifier, consisting of a one byte entity id, followed by a (up to) 64 byte name. Normally, the entity will be a nym.

Question: Use a standard, fixed 65 byte entity field, or make it variable length to save space? (This is what was implemented.)
nym-type
Indicates the type of nym, if the entity is in fact a nym, otherwise it should have a value of 0. This field distinguishes between trial nyms, paid nyms, etc. Normally 1 byte (?).

Note: We should use the same size and value used by the nym server to distinguish types.
mail-limit
An unsigned value specifying the number of pieces of mail the owner may send during a given time period (usually 24 hours). Normally 4 bytes.

Note: This value is included in the cert so that the mail system can avoid doing an extra lookup to get it.
volume-limit
An unsigned value specifying the total number of bytes of mail the owner may send during a given time period (usually 24 hours). Normally 4 bytes.

Note: This value is included in the cert so that the mail system can avoid doing an extra lookup to get it.
pop-quota
An unsigned value specifying the maximum allowed size, in bytes, of the owner's mail box. Normally 4 bytes.

Note: This value is included in the cert so that the mail system can avoid doing an extra lookup to get it.
{MAC | Sig}
A MAC, or a signature, generated over the preceding fields. The MAC key is a secret key shared by the nym server, which creates the certificates, and the mail system, which verfies them. The MAC value should be no less than 10 bytes, and no more than 20. The format of a signature is not yet defined.

Question: Settle on one of the two MAC lengths? (Currently set to 10.)

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.

Implementation Notes


Copyright © 2000 Zero-Knowledge Systems Inc.
All Rights Reserved