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.
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.
There's added complexity here because when you are using a cache
manager, your token is extended to contain not just your identity (and
key material) but that of the cache manager too. This prevents a
number of cache posioning attacks.
Your chosen GSSAPI mechanism is only involved in the initial
handshake, where it authenticates you, and seeds a pseudo random
number generator which produces further key material for the rest of
the connection.
For those who haven't already seen these, the basic rxgk system is
explained in http://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-00
Per server keys, cache manager key combining, and other AFS specific
extensions are detailed in http://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-afs-00
S.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
