[OpenAFS] Re: Any budding documentation writers

[Simon Wilkinson]

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.