[OpenAFS] Re: feasibility of moving lightweight-principals issue "upstream" to kerberos

[Russ Allbery]

Adam Megacz <megacz@cs.berkeley.edu> writes:
> Russ Allbery <rra@stanford.edu> writes:

>> But you're still going to be doing authentication (and therefore
>> identity management, since you want your authentication system to
>> satisfy certain identity binding requirements which will require at
>> least some form of identity management).

> I agree.  I think the really tough hurdle I'm trying to get over here in
> this thread is if OpenAFS is willing to accept use-cases where the task
> above is delegated outside the sphere of the "AFS software suite"
> (OpenAFS, Kerberos, and various extensions to Kerberos).

Well, the fundamental issue with doing so is that you need some way to
generate a token and do useful things with that token.  Right now, the
token format is fairly wide open, and you can actually generate one in
many different ways if you're willing to write the code.  Longer term, I'm
not sure if this is going to continue to be the case in quite the same
way.  A real Kerberos v5 AFS implementation, which would be an excellent
thing to have for a whole host of reasons, is likely to want to be more
specific about the contents of the token so that one can, for instance,
give file servers independent keys without requiring all of one's file
servers to have god-like AFS privileges.

Because of that, I think you'd be best off if whatever technical solution
you came up with looked like Kerberos from the AFS perspective.  AFS has a
lot of issues to deal with and, compared to getting Kerberos working
properly inside AFS, I think this one is relatively less important for
most sites (and much less likely to draw a lot of specifically AFS
development).  Plus, if you can implement something like this at the
Kerberos level rather than the AFS level, you solve the problem not only
for AFS but for any Kerberized service.

As such, I think you're pursuing a very difficult technical course if you
do this as something other than an extension to or a management policy
around a Kerberos realm that AFS can otherwise treat as any other Kerberos
realm.  I don't think you'll find a lot of resources to help you with
that, just because AFS development resources are limited and such things
as real Kerberos v5 support will make a huge and immediate difference for
a lot of people.  (It would, for example, potentially allow people who are
not strongly trusted with the keys to the kingdom to run their own file
servers in an AFS cell, although there are a lot of details to work out
before we get to that point and the VLDB interaction is tricky.)

On the other hand, I think fast generation of new Kerberos principals,
better ways of doing Kerberos trust, and better ways of trusting Kerberos
realms within AFS are all areas ripe for exploration and areas where you'd
see a lot of support and interest.  The problem of identity management and
*simple* account creation for loose affiliates is a *huge* problem for
many universities and one that many of us would love to see solved in as
systematic a fashion as possible.

pkinit and pkcross look to me like potentially useful technical components
to a larger solution and worth pursuing for that as well as in their own
right.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>