ZBEN@UMD2.UMD.EDU (Ben Cranston) (03/31/89)
I have been looking at the Davis and Swick paper with an eye to using the Kerberos protocols (or an extension of same) to generate encryption keys for secured mail messages. I see how their scheme could be used as stands to generate a user-to-user session key, but this would require that both the sender and receiver have valid TGS keys (i.e. actually be signed on). I would like to design a scheme under which the receiver would generate some cookie and transfer it to the sender, who could then generate encrypted messages autonomously. I have also done a paper on using (an extension to) Kerberos to generate digital signatures (basically sealing a checksum for the user). Since both of these schemes touch upon the idea of session keys (tickets) that last longer than the 8 hours or so of a maximal workstation session, they are somewhat related. If anybody is currently working in this area or has good ideas I would like to know about it. (But, but, but it's MY wheel! And, and, and it's just big enough to reach the ground! :-)
bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman) (04/01/89)
The existing Kerberos protocol can be used to securely pass encryption keys for secured mail messages without requiring the recipient to be logged in at the time the message is sent. The recipient of a message can chose the maximum clock skew allowed. Thus, someone sending a message could obtain a ticket for the recipient, encrypt the message in the session key, and pass the ticket along with the encrypted message. The main drawback for this scheme is that the recipient of the message would have to enter his key (password) in order to decrypt the message. The way you are looking to do things, the recipent would maintain a "cookie" that is transfered to the sender which could then generate the encrypted messages autonomously (Actually, it would still be necessary for the sender to send this cookie to the KDC). In this case, you are assuming that this "cookie" contains a long lived key. How are you going to protect that key? ~ Cliff
jis@ATHENA.MIT.EDU (Jeffrey I. Schiller) (04/04/89)
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
ZBEN@UMD2.UMD.EDU (Ben Cranston) (04/05/89)
You describe essentially what we were about to propose, extended to the case of multiple recipients! We see two main problem areas. One is the stability of the private key used to encrypt the AMRL while in transit from sender to reader. If one wants to change this key periodically but retain the ability to provide the key recovery service for a fairly long period of time (perhaps months) this will result in a large number of extant private keys. The second is the foreign Kerberos problem you also allude to. There is nothing to prevent the user from using her own keys, distributed by her own ingenuity, if she doesn't trust the Kerberii or their keepers. I see an emerging need for some form of mail privacy protection, that encryption is one reasonable route, that key distribution needs to get done. When the Davis and Swick paper came out that started me thinking along the lines of user to user authentication. It now seems that what we want to do can be done without their extensions. I do think we should be looking at this issue now so that when the time comes that people want to implement there will be a reasonably stable standard for them to write to. This is more important that who gets credit. Actually, having a standard may be more important than the gritty details of what the standard actually is...
gnu@hoptoad.uucp (John Gilmore) (04/10/89)
Jeffrey Schiller proposed a scheme for secure mail. At first reading
it strikes me that the mail key transmission service will be contacted
many times per message (once by the sender and once by each recipient)
and will get a full list of who is sending the mail and who all the
recipients are. To me this sounds like a perfect place to do traffic
analysis ("intelligence gathering" in which an adversary finds out who
is talking to who). It would not even be necessary to break into
the MKS, most of what you need is in the addresses in the packet headers.
I would prefer a protocol where local systems can cache the private
keys of the people who they talk to often, and could generate their own
session keys if required, so that a central key server would only be
able to track a small fraction of the traffic.
Mr. Schiller's proposal also seems to require:
* that the full list of recipients be divulged to each recipient
(including bcc's)
* that the recipients must contact the mail key server to decrypt
the received message *from the addressed machine*, that is, if they
have their mail forwarded elsewhere, they will be unable to decrypt
it since their new location is not on the "recipient list".
--
John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com
"Use the Source, Luke...."
Copyright 1989 John Gilmore; you may redistribute only if your recipients may.