Talking about tokens.

[Per Boussard]

Assar,

> Yes, but as others have said, that's not the way it works with AFS.
> The stuff that's available to you is (used by VIOCGETTOK, VIOCSETTOK):
> 
> struct ClearToken {
>   int32_t AuthHandle;
>   char HandShakeKey[8];
>   int32_t ViceId;
>   int32_t BeginTimestamp;
>   int32_t EndTimestamp;
> };

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.
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.
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.
3) At the point in time when I ask the tgs for an afs ticket, no
communication between kerberos and afs is required. All authentication
'stuff' between afs and kerberos needed is the shared secret (the
K(afs,krb) key) which is put there at some time by a competent
administrator.

?) 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)?

?) 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?

?) 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.


> 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 ... ;)

> I hope this clarifies matters and partly our reasons for the way we
> have done things.

Well. Soon... 
:)

Thanks
//Per
----
Per Boussard, KI/ERA/T/VA          Office: +46 8 404 55 11
UNIX System Administrator          Fax: +46 8 757 55 50
Ericsson Radio Systems AB          Home: +46 8 570 349 67
S-164 80 STOCKHOLM, SWEDEN         Email: Per.Boussard at era-t.ericsson.se