[AFS3-std] rxgk: Rekeying

[Chaskiel Grundman]

> By "application layer" - do you mean the application (ie, fileserver,
> ptserver) instead of the security mechanism?  I can't speak for the
> rxgk side of things, but speaking from the rxk5 side of things this
> is something I was specifically seeking to avoid: application/mechanism
> specific glop.  Or, in a world, "yuck".  But, ignoring that problem...
Well, more like the client application (cache manager, ubik). When the 
key expires, all calls on that connection start to fail, you throw it away, 
and call rx_NewConnection, which gets you a new cid, which means you get a 
new TK. The fileserver has some code for this, but I think it never gets 
triggered (i.e. it's leftover from the bcrypt days)

> From the rx side of things, there is a problem: there may be handling multiple
> calls, they may be in different stages of completion, and there is no
> guarantee on how long any given call might last.  On the server side, it's
> not possible to know what calls the client might have sent, are in-flight,
> but haven't been received on the server.  This means there is no
> logical "good" place timing-wise for the server to return "VICETOKENDEAD".
> Waiting for idle moments on a connection on the server may not be possible
> for a sufficiently busy connection.  Adding slop in will reduce problems,
> but not eliminate them.
Once you decide the key is expired, all in progress rpcs start failing in 
_CheckPacket, as if the token was expired (but with an error code that 
causes an immediate retry)

> idempotent.  And, of course, if a bulk data write is larger than the
> "byte window" in rxgk, things get worse.
I had hoped to avoid additional complexity, but that's a good reason to 
either do rekeying, or make the byte life more advisory (i.e. the 
transport doesn't enforce it at all, but the app enforces it at the 
begining of an rpc if it wants to, as src/viced/host.c:GetClient() 
redundantly does for token lifetimes).


> Presumably the client or server would not accept a key change signalled
> by a bogus packet that cannot be decrypted successfully.  So why would
> an attacker be able to cause a key change?
"Presumably". I just want that to be stated explicitly. I could see a 
naiive implementation not doing the right thing..