[199] in Kerberos
missing kerberos feature needed for
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:41:05 1987
From jis@BITSY.MIT.EDU Mon Apr 27 15:28:43 1987
Date: Mon, 27 Apr 87 15:27:29 AST
From: Jeffrey I. Schiller <jis@BITSY.MIT.EDU>
To: Saltzer@ATHENA.MIT.EDU
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Jerome H. Saltzer's message of Mon, 27 Apr 87 14:58:13 EDT <8704271858.AA13937@HERACLES.MIT.EDU>
Subject: missing kerberos feature needed for mailing lists
Date: Mon, 27 Apr 87 14:58:13 EDT
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
Originating-Client: <E40-391A-1.MIT.EDU>
ARPANET RFC 989 ("Privacy Enhancement for Internet Electronic Mail")
identifies a key-distribution feature that we don't currently have in
Kerberos: The ability to ask Kerberos for a bunch of tickets all of
which have the same session key inside.
The use would be in the case where one is sending a message to a
mailing list of, say, 20 other users. You would ask Kerberos for a
mail ticket for each of the 20 people (probably Kerberos would seal
mail tickets using the recipient's private key) but specify that it
should materialize a single temporary session key and seal that one
key inside every ticket.
Then you encipher the message contents once, under the session key,
and for each recipient, include that recipient's ticket in the header
of that recipient's copy.
Using the facilities that Kerberos now provides, each ticket has a
different session key inside it. If used for mail, distinct session
keys would require that the entire message text be reenciphered once
for each recipient.
This comment applies either to the case where the originator of the
message does the mailing list explosion, or where the originator
sends the message to a trusted list-exploder, in which case the
list-exploder is the one that needs the extended Kerberos function.
Comments? How soon do we need to start thinking about
privacy-enhanced mail? I suspect soon, in the M.I.T. non-Athena
context.
Jerry
Actually I looked into this RFC when it first came out. My idea would
be to choose a common session key with which to encipher the message,
then encipher this session key in the per ticket session key for
each user ie:
To: User1, User2
Ticket-For-User1: T {K }
User1 m K
T
User1
Ticket-For-User2: T {K }
User2 m K
T
User2
Message: {{Message Text per RFC } } (Encoded per RFC)
K
m
-Jeff
