[1827] in Kerberos
Kerberos access restriction... (FYI)
daemon@ATHENA.MIT.EDU (Dan Sorak)
Tue Mar 24 17:00:14 1992
From: sorak@dimsum.eng.hou.compaq.com (Dan Sorak)
To: kerberos%Athena.MIT.EDU@twisto.eng.hou.compaq.com (Kerberos Mailing List)
Date: Tue, 24 Mar 92 15:09:39 CST
Someone mentioned that they would like to know the following. I am posting it
on an informational basis ONLY. I do not guarantee that it will work or that
it is secure implementation (although I can't find anything wrong with it...)
The following is a description of how we will implement access
restriction (to specific machines) on a per user basis with our V4
kerberos system. It involves making minor additions to the service
ticket granting portion of the kerberos authorization daemon ONLY.
NO CLIENT PROGRAMS NEED BE CHANGED. In addition to the daemon
changes, only adding data to the kerberos principal/instance database
will be required.
In case you're wondering, the references to login below refer to a
version of login that we have "kerberized". We have done this by
having the login program request a ticket granting ticket with the
typed-in password and then using that ticket on a local service
ticket request. If the local service accepts the service ticket,
"login" will let the user log in.
The following is a description of how the system works with the
modifications I have come up with.
--------
When any user logs in to a machine (or uses kinit) and types the correct
password they will get a TGT (Ticket Granting Ticket) that will be requested
from the kerberos master. The principal will be the user login name and the
instance will be null (this principal/instance pair will have the only password
they need worry about). If the "user login name" principal and null instance
do not exist (or the incorrect password is used), the user will never get a TGT
and therefore be unable to use any kerberos services.
In order to verify a valid TGT, the login program will request a service
ticket for a local service and try to use it to verify it's validity. Other,
network-based services (i.e. rcmd) will also be accounted for (read on...)
The kerberos daemon will receive the service ticket request (containing the
TGT and machine name to which the service ticket is requested) from the client
machine. Based upon the information contained within the request, our modified
kerberos daemon will make another query to it's principal/instance database
with the user login name (from the TGT) as the principal and the machine name
for which the service ticket is requested as the instance. The presence or
absence of this entry will determine whether or not the daemon will return the
service ticket to the requestor (note that the password on this principal/
instance pair will never be used, so it may be set to RANDOM). This is the
key to the whole idea. It is to let the source of all service tickets (the
kerberos master) make the call as to whether or not to grant a service ticket.
And do this not only based on the presence of a TGT, but also through an
"access list" that can be provided by principal/instance lookups from it's
database (a mechanism that is already built into the system). This will allow
propagation to even the slave servers without any additional code.
Without a service ticket, the user will be unable to use the service, thereby
failing the login criteria and/or failing to gain access to the remote
service/machine.
Administrative users will have a special principal/instance pair that will
indicate that they should have access to all services/machines. This
principal/instance will be checked if the "user.machine" principal/instance
fails. It will also be possible to grant/deny particular service tickets
contingent upon the same criteria (i.e. the kerberos daemon will only grant
a "foo" service ticket to a user that has a "user.foo" principal/instance
pair). As you can see, this mechanism can be applied in a variety of
different ways without ever having to change a single client program.
--------
That's it! Please don't ask for patches or code samples as we have
not fully implemented it yet. I welcome your comments on how this
may be improved. I also welcome any criticism. :-) (But please
limit it to criticism of the implementation, not criticism on whether
or not this is "the way kerberos was meant to be used") Thanks!
--
Dan Sorak Compaq Computer Corporation
Systems Programmer MS 050701
sorak@compaq.com 20555 S.H. 249
(713) 378-7152 Houston, TX 77070
