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..
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
