Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!ucbvax!decwrl!shelby!ATHENA.MIT.EDU!jis From: jis@ATHENA.MIT.EDU (Jeffrey I. Schiller) Newsgroups: comp.protocols.kerberos Subject: Re: using kerberos for secure mail Message-ID: <8904040318.AA01052@OSIRIS.MIT.EDU> Date: 4 Apr 89 03:18:14 GMT References: Sender: daemon@shelby.Stanford.EDU Organization: The Internet Lines: 70 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