[OpenAFS] Re: Any budding documentation writers

[Russ Allbery]

Simon Wilkinson <sxw@inf.ed.ac.uk> writes:
> On 3 Mar 2010, at 21:16, Russ Allbery wrote:

>> Well, bear in mind that one of the goals of rxgk is to have per-server
>> credentials, so that someone can set up an AFS file server without
>> getting the keys to the entire cell.  This means that a client may have
>> to authenticate separately with each server, which means that in a
>> Kerberos context one cannot do the current aklog trick of getting all
>> the service tickets one needs in advance.  You instead need to give
>> rxgk a TGT so that it can obtain new credentials to authenticate to
>> other servers when needed.

> Actually, the rxgk architecture is a bit more complex than this.

Ack, sorry for the misinformation.  I'm not keeping up as well as I should
be.

> You only do a GSSAPI handshake once, at the start of your session,
> driven by 'aklog' or a similar tool. This provides you with an rxgk
> token, which is stuffed into the cache manager in the usual way. This
> rxgk token allows you to access all of the servers that share a key with
> the one that participated in the initial handshake. Per-server keys are
> implemented by providing a service that allows the client to exchange
> the initial rxgk token for one for a specific server.

In this case, I think it would still make sense to provide some mechanism
for someone to say "use this following mech-specific name to authenticate
to the rxgk service" when debugging or when intentionally bypassing local
configuration.  That would be equivalent to the existing -k option for
aklog.  Obviously, it wouldn't be the default.

For klog.krb5, we really want some API into GSSAPI that would let you
essentialy say "rather than having the mechanism go out and find
credentials via whatever its default search mechanism is, use the
following mechanism-specific blob as the credential store."  For the
Kerberos mechanism, this would probably be a wire-encoded TGT that the
underlying Kerberos mechanism implementation would turn into a private
memory ticket cache before doing further operations.  For an X.509
mechanism, it could be the path to a private TLS key or something
equivalent.

This would also be helpful in threaded server code and similar situations
where the client may want to juggle multiple identities or not store
things on disk.

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