rights management

[Michael Fair]

This is always one aspect of Kerberos that still
confuses me and I was wondering if someone could
clear it up for me.

In any given domain (domain.dom for instance), there
will be a set of users and groups (similar to a
Windows Domain).  If you are using a network
authentication system like Kerberos, you are almost
certainly trying to create a system where the
definition of users and groups for your domain
is centralized.

I agree that the services themselves are the best
place to actually handle authorziation instead of
just denying a ticket to the service, but from
what I can tell there's no way for the service
to consistenly attach/hook in to the KDC principals
list, and from what I can tell Kerberos V doesn't
support any kind of group creation mechanism.

Is Kerberos destined to remain just an authentication
architecture and designed to just be part of some
other system when it comes to the needs of most network
environments in regards to user/group/service management?

For instance, I have IMAP email, file servers, printers,
ftp servers, LDAP servers, and client workstations.
Each of these systems could benefit from associating
Access Controls to Kerberos Principals, but from
what I can tell Kerberos provides no standardized
way for those services to get help in managing those
ACLs from the Kerberos system.

I guess all this means is that I end up agreeing with
the MS AD and DCE camps that believe a truly useful
system is going to provide all of Identification,
Authentication, Authorization, and Accounting systems.
(Accounting = logging / tracking who is using what)

Are there any Open Source solutions for implementing
a total package solution (where total package is both
Authentication and Authorization - I'll figure out
the others later)?

Assuming there is a simple solution, please forgive
my fustration.  I thought it would be a relatively
straight forward process - use Open Source tools to
build an MS AD like infrastructure.... I've just
been bumping into road blocks all over the place,
most of which are centered around no centralized
system for authorization data storage/retrieval.

-- Michael --

"Marcus Watts" <mdw at umich.edu> wrote in message
news:200302260947.EAA22335 at quince.ifs.umich.edu...
> 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
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>