[27] in Kerberos
Access Control Lists and RVD
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:16:46 1987
From bcn@ATHENA.MIT.EDU Mon Jul 28 13:37:21 1986
From: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Date: Mon, 28 Jul 86 13:21:41 EDT
To: kerberos, rvd-info
Subject: Access Control Lists and RVD
On Friday, Jerry and I worked out some more of the details of an Access
Control List Server (ACLS), and how it could be used by RVD.
The ACLS will be contacted by the user and authenticated via Kerberos.
The user tells that ACLS the name of the service he wishes to use and
the name of the list he claims to be in.
The ACLS will determine whether the user is in that list. If not, it
will return an error.
If so, it will generate an ACLS ticket that consists of the following:
A Kerberos authenticator authenticating the ACLS to the service.
This consists of:
A Kerberos ticket issued to the ACLS for the service and
additional information encrypted in the session key from the
ticket.
Authorization data including the name of the authorized principal,
his network address, and the name of the access control list of
which the principal is a member. This data is also encrypted in
the session key from the ticket.
The user will use the ACLS authenticator in place of the Kerberos
authenticator. This is possible because the ACLS ticket begins with a
Kerberos ticket. When the service receives an authenticator it decrypts
it, and sees that the authenticated principal is "ACLS" "machinename".
This tells it that it is from an ACLS, and that there is more to the
authenticator. It then reads the name of the list from the remainder of
the authenticator, and it generates a list name to be compared with its
internal database of who is authorized to spinup what disks.
It is important to note that local authorization data is still
maintained. This data is a list of a fixed number of principals
authorized to use a service/disk. What we have done through the ACLS,
is to allow that list to contain groups. i.e. anyone on a particular
ACL.
At first we decided that a list name would appear as "ACLS" "listname".
This would, if desired, allow one to create a principal with the same
name as a list, and thus one could bypass the ACLS if desired by the
people maintaining Kerberos. Since our discussion, I found one problem
with such names in that, if one did allow bypassing, the person with the
password for an ACLS principal could pretend to be an ACLS, and thus
falsely certify his membership in any ACL. This is easy to fix,
although it makes things a bit less clean, by having the apparent
principal for lists be "ACL" "listname". Thus, the service end not only
fills in the instance from the last part of the ACLS authenticator, but
it also changes "ACLS" into "ACL". Thus, we can still allow bypassing
the ACLS if desired, but we do not have to resort to remembering the
instance names of all certified ACLSs.
One unresolved issue (we just didn't think of it while discussing this)
has to do with final authentication of the user to the service. Can an
ACL authenticator be reused? If so, do we require a user to
authenticate himself to an end service in addition to presenting the
ACLS authenticator? If the answer to the above are Yes, and No, then
the only thing that stops an attacker from stealing the ACL
authenticator off the net and reusing it is the presence of a network
address inside. But, this can be easily gotten around. Requiring the
user to additionally authenticate himself to the end service will solve
this problem but may complicate the protocol. If we only allow an ACL
authenticator to be used once, then we must require that it is returned
to the user encrypted in the session key from the ticket the user used
to authenticate himself to the ACLS. This also requires many additional
calls to the ACLS, and, thus, is undesirable.
The above is a rough design for an ACLS server. Comments are welcome,
as are offers to help finish/refine the design, and to implement it.
~ Cliff
