[685] in Kerberos
Re: using kerberos for secure mail
daemon@TELECOM.MIT.EDU (Jeffrey I. Schiller)
Mon Apr 3 23:32:44 1989
From: Jeffrey I. Schiller <jis@ATHENA.MIT.EDU>
To: ZBEN@umd2.umd.edu
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Ben Cranston's message of Sat, 01 Apr 89 20:20:38 EST <M1989$020210.016118BEN.ZBEN@UMD2.UMD.EDU>
How about this scheme (which is implementable completely
outside of the kerberos server):
Define a "Mail Key Transmission" service. This service works as follows:
Sender: Build a list containing the name of the sender and a list of
recipients of the message (the AMRL). Hand the "Mail Key Server" (MKS)
a Ticket (say for the "mailkey" service with instance equal to the
mail key server's name) along with the AMRL in a standardized format
with a cryptographic checksum based on the session key of the included
ticket.
If the sender of the AMRL is authenticated to be the specified sender,
the MKS returns the AMRL with a new cryptographic checksum (which only
it can validate) a session key enciphered in a private key of the MKS,
a private key version number (for inclusion with the message) and the
same session key encrypted in the sender's session key (as provided in
the ticket above).
The sender now encrypts the message with the session key provided by
the MKS and includes along the checksumed AMRL and "sealed" session
key.
The Recipient:
Contacts the MKS with a copy of the checksumed AMRL, a ticket and the
"sealed" session key. The MKS verifies the authenticity of the AMRL by
recomputing the cryptographic checksum and then determining if the
recipient is a member of the recipient list. If the recipient list is
valid and the requester is a member of it, then unseal the supplied
session key and reencrypt it in the session key supplied in the ticket
of the recipient.
Once the recipient has the necessary session key, the message can be
decrypted.
Advantages:
Simple. No (or very little) actual state required in the MKS. All it
really needs is a kerberos service key and possibly a set of private
keys.
No modification to the base kerberos protocol or database required.
The MKS can also be administered by a different entity then the
kerberos realm that it is registered in.
Disadvantages:
No mechanism is specified to handle inter-realm messages. They can be
transmitted, but the recipients must all go the the same MKS as the
original sender.
Issues not directly addressed:
I haven't really addressed the issue of mail name to kerberos
principal name here. This can be wing'd by having the AMRL contain
kerberos principal names while the rest of the mail header contains
actual mail names.
*META COMMENT*:
I don't really like this system because it gives the administrators of
the MKS (not to mention the kerberos realm administrators) the ability
to read private messages. I feel that any system for handling mail
should be secure from all individuals no matter whether or not they
administer a kerberos realm or MKS. Public Key systems under
discussion solve this problem.
-Jeff
