rights management

[Marcus Watts]

Ulrich Weber <uweber at epost.de> writes:
> is there nothing in kerberos to allow/deny tickets per each user for 
> services?
> Ex.: Allow user1 at REAL ftp/server1 at REALM and telnet/server1 at REALM
>       but DENY user2 at REALM telnet/server1 at REALM and only ALLOW 
> ftp/server1 at REALM
> (technical there would be no problem cause you get a ticket for every
> service from the kdc).

This sounds awful like something that ought to be in some FAQ.

Basically, this is an *authorization* decision.  Kerberos V only does
*authentication*.  The two are subtly, but distinctly different.

Authentication says "you are who you say you are"

Authorization says "you are allowed to do FOO to BAR".

There is also a 3rd member of the triad, identification "you have name
X".  Other users might well be able to refer to you as name X
separately from authentication, as for instance in setting permissions
on objects -- ie, manipulating fine grained authorization.

It is worth spending the time to keep the 3 notions separate and
distinct (remember the acronym IAA) as it will save you from many
design mistakes.

Getting back to the question at hand -- authorization is almost
certainly something you want to do at the service level, and not inside
the KDC.  That is because the KDC can at best only do yes/no decisions
on service tickets, which is almost never what you really want to do
with authorization decisions.  By having this enforced at the service
level, the service has the opportunity to
	log failures
	return a more appropriate error message to the user
	use additional criteria to decide permissions
		(such as time of day, IP address connecting from, etc.)
	implement fine grained permissions on objects *within* the
		service, such as:
			you have kerberos tickets for k5 principal FOO.
			You can log in via ftp as local user BAR, but
			not local user BAZ.
		you can read file X, but not file Y
		you can read file X, but you can't write file X.
	implement more flexible notions of permissions, such as
		you are a member of group G.  Members of group G
			can do BAR...
	implement a level of indirection between user names and
		internal permissions, such that if K5 principal
		X is deleted or renamed, then a new K5 principal X
		is added, if they have a different UID or ViceID
		(or whatever) they don't necessarily get the old
		person's permissions, and if the old principal was
		renamed (and this renaming is managed in parallel
		inside the authorization mechanism) the old user
		retains his permissions.
None of these would be possible if the KDC limited service ticket
availability, which is why that's a bad way to do authorization.

As an interesting aid to authorization, the K5 protocol has a hook for
"authdata" within a service ticket.  There is not anything in current
versions of MIT K5 to do stuff with this, and much controversy about
how to properly handle it.  The catch is you want authorization data to
come from outside the KDC, but the KDC needs to construct the ticket
returned to the user.  That's ugly.  The flip side of this coin is in
DCE and MicroSoft AD -- here the kdc has access to additional
permission data, and fills in authdata with interesting stuff.  But
this too has problems; now you're tied to the permission data the KDC
can access, in the case of MicroSoft the KDC becomes part of a much
more complicated piece of software, with corresponding opportunities
for bugs, and to make matters worse, for a long time MicroSoft failed
to properly document what was in their data.  All in all, a big mess.
So, for now, "authdata" is probably not of immediate use to you (and it
may never be useful), but it is interesting...

Today, the best generic answer to authorization is to solve this, using
appropriate tools, within the service.  For telnet/ftp, sometimes it
suffices just to list the right people in the local password file.
There is also an ajunct to this -- "kuserok" and "~/.klogin") that
provides some interesting twists to this.  Another interesting example
is the kadm5 "acl" code, which kadmind uses to decide who is allowed to
do what to principals.  This has the disadvantage of not being
distributed or manageable from the network.  A more sophisicated model
is the "pt" or "prot" service (pts, ptserver) in OpenAFS.  pt + acls
gives you argueably a pretty flexible scheme, but there are some small
issues that remain (how do you manage permissions securely to do
"getcps" without having one powerful key "afs"?).

				-Marcus Watts
				UM ITCS Umich Systems Group