Talking about tokens.

[Love]

Per Boussard <Per.Boussard at era-t.ericsson.se> writes:

> This just got me more confused. I've seen this before but refused to
> believe that this was the only information available. Maybe there are some
> incorrect assumptions on my behalf. I assume --
> 
> 0) The struct ClearToken is issued by kerberos, not by the afs server.

The ClearToken is the afs equivalent of the kerberos CREDENTIALS (with some
informations striped out).

> 1) HandShakeKey is a 64 bit random number. Nothing is coded in it. Each
> time I authenticate afresh (get new tokens, say) I get a new HandShakeKey.

HandShakeKey is the kerberos session key (CREDENTIALS->session).

> 2) AuthHandle is a handle that (as a handle) is private to the afs server
> and that tells the server what afs id I am.

Its the key version.

> ?) How can arlad/xfs know to enforce the acl's? If user A and B are active
> on the same machine, A gets some data using his token, and then B asks for
> it (the same data). How does xfs/arlad know whether to give out that data
> (how to enforce the access policy dictated by the ACL for the directory)
> given that it doesn't know about the real ID's of A and B with any
> certainty. Is this done brute-force (i.e. arlad always asks again for the
> data for a new user)?

In the AFSFetchStatus struct that we get from most RXAFS calls contain a
field called `CallerAccess'. This information is stored for this PAG. So
for each new pag your are forced to ask the server for the CallerAccess of
this pag. This is cached for speed.

There is also a field called AnonymousAccess that contain the access-rights
that a anonymous use should have. Its possible that this matches for the
second user so we check it too before fetching a new AFSFetchStatus over
the net.

The content of a ACL is never known by arla, its opaque from the fileserver
to fs.
 
> ?) How is the AuthHandle built? Is that some encoding/hash of my afs id
> using the K(afs,krb) shared secret? Can the server use that to know my
> identity?

Its the kvno, it should be used to tell the server what version of the
afs@{cell,REALM} key we have.

> ?) In order to use the HandShakeKey in a hand-shake, the afs server must
> know that key. This conflicts with 1) and 3) above in conjunction -- The
> key must be fresh for each session (or something like that) and it cannot
> be correlated with or depend on or be derived from AuthHandle.

The HandShakeKey is for us, the server get its HandShakeKey in the rxkad
challange-response part. We send over a KTEXT_ST to the server (just like
in kerberos) and and in it is the HandShakeKey.
 
> > Another option is removing the printing of Id's by klist (or make it
> > not the default). :-)
> 
> I sort of agree. Incorrect information is worse than no information. I'm
> just not ready to believe that there can be no information about neither
> the afs id nor the client name in the data available to xfs/arlad. I can't
> figure out how that can be made secure. Maybe it isn't ... ;)

It a boot-strap problem. We get all our userland programs from kth-krb,
including the one that insert userid to xfs/arlad. And to get correct
information you need a rx implementation (or part thereof).
 
Love