Keytabs in Kerberos

[Ken Raeburn]

greg at wind.enjellic.com (Dr. Greg Wettstein) writes:
> Actually a great idea, would the core team accept patches if they were
> to be worked up?

Unless people disagree with this approach -- and I haven't really
talked to them much about any specifics -- I don't see why not.  (With
caveats about code quality, test cases, copyright or license terms,
etc.)  At this point, I doubt we'd try to fold it into the 1.3
release, though; maybe for 1.4....

There may be some issues to investigate, though.  For example, if a
server is written so as to accept authentication to any service
principal name indicated in the ticket (and follow it with some check
that the name is actually a permitted one, like "host/*" for a host
with multiple names), should such a change as this cause that server
to now be capable of looking in multiple files?  What error is
reported if some of those files are not readable by the server?
Should the syntax permit part of the supplied service principal name
to be used in forming the pathname to look up?  If so, how do you
avoid the security problems that suggests?

> The Hurderos Project is facing a similar problem with keytabs.  The
> service identities need the keytab entry both for authentication
> purposes as well as for generating the authorization identity.

Hm, I hadn't heard of Hurderos.  Is this the same as www.hurderos.com?
Looks like some interesting stuff there, though it does talk about
using patented technologies....

> I was worried about this issue from a security perspective since some
> of the applications which needed to carry out authentication and
> authorization were non-root processes.  The ability for an application
> to have their own keytab would enable the keys to be partitioned
> according to application and or security requirements.

Exactly.  Most network services should have little or no need to run
with root privileges.  And most of those that do, currently, could
probably be fixed by finer-grained privilege administration, like
giving ntpd the ability to set the system clock but *not* to read
users' private files.  And giving various servers, like named, access
to certain so-called privileged ports but no other special privileges.
And of course they should be separated from each other, so that
compromising one service running as "nobody" doesn't let you break
into all the other services also running as "nobody".

Oops.  Pushed one of my buttons there, sorry... :-)

But yes, Kerberos keytab administration issues should not stand in the
way of trying to implement a reasonable separation of privileges
between servers.

Ken