[26] in Kerberos
Re: RVD authorization and Kerberos i
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:16:38 1987
From wesommer@ATHENA.MIT.EDU Fri Jul 25 11:24:36 1986
To: bcn@athena.mit.edu
Cc: saltzer@athena.mit.edu
Cc: kerberos@athena.mit.edu, rvd-info@athena.mit.edu
Subject: Re: RVD authorization and Kerberos integration plan
In-Reply-To: Your message of Fri, 25 Jul 86 10:33:48 EDT.
<8607251433.AA07502@MENELAUS>
Date: Fri, 25 Jul 86 11:21:25 -0500
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
If you encrypt the authorization data, you also get the additional
side effect (for better or worse) that only the end service can
determine the contents of the ACLS ticket.
Why not do as you do with Kerberos, which is to enclose the plaintext
part of the ticket in unencrypted form in the reply, along with the
encrypted form; the whole thing could be wrapped up and encrypted in
the user's key.
I think that it might also be reasonable to provide some form of local
ACL library for some applications, to cut down the burden on the
central ACLS and to reduce the amount of network latency
involved. Presumably, the ACL, which would be a list of pairs
of the form "name of principal", "access allowed" (with some wildcarding of
the "name of principal"), could be stored in a protected file on the
server, and manipulated using utilities on the server or using an
extension to the protocol. This is the approach which is being taken
by Stan Zanarotti in his "discuss" system (a networked notes- or
Multics forum-like conferencing system).
- Bill
