[AFS3-std] rxgk-afs: moving SetCallBackKey to a separate document?

[Simon Wilkinson]

On 2 Mar 2013, at 03:15, Benjamin Kaduk wrote:

> I agree with jhutz that the risk of needing changes to rxgk in order =
to get secure callbacks is quite low, as we only need a token and shared =
key for the rxgk security class to work.

On the contrary, as someone who has actually implemented this, you =
absolutely will need changes to rxgk to get secure callbacks to work. If =
you separate out secure callbacks from rxgk-afs, you will need to come =
back and constrain the behaviour of AFSCombineTokens (and the rxgk-afs =
combined token) at a later date. If you end up doing that once =
implementations of the old token format are in the wild, there will be a =
major interoperability headache.

I think we need to consider them as a single entity, at least until we =
have defined these constraints.

[and, in another message]

> Jeff has described the current situation with regard to callbacks and =
information leakage and denial of service possibility.  Given that even =
with rxgk and a secure callback channel, we still have the problem of rx =
aborts being unauthenticated,

I think you're misrepresenting the RX abort problem. RX aborts aren't a =
particular denial of service risk - with any encrypted protocol, an =
attacker can inject forged packets into the network stream (or cause =
existing packets to never be delievered). The response to both of these =
events is a connection abort. So no amount of encryption can protect you =
from an attacker who can block your connection. The RX abort problem =
comes about when you rely upon either the fact that the connection =
failed, or the reason given for the connection failure, to make security =
decisions.

On 2 Mar 2013, at 01:50, Jeffrey Hutzleman wrote:

> It seems clear to me that callback protection is not nearly as
> completely fleshed out as either rxgk or rxgk AFS integration.  I see
> nothing that makes rxgk depend on callback protection, or that =
justifies
> holding up rxgk until callback protection is done.  Therefore, I think
> it would be better to split the latter into a separate document.

The reason for this is that the descriptions of the former were produced =
at the same time as I was writing the YFS rxgk implementation. Those =
descriptions were then refined with the hindsight of implementation. So, =
what was described in the last version of the documents I published was =
an implementable form of rxgk and rxgk-AFS. However, at that point, I =
had yet to implement either callback channel protection, or key =
registration. The complete lack of timely review of the rxgk documents =
convinced me that there was no point in writing up what we actually did, =
as it would never actually be read.

I'm quite happy to contribute language that describes what YFS is doing =
now for callback protection, but I will note (as mentioned above) that =
it does require changes outside of just the SetCallbackKey RPC. So, if =
we are to consider it, it needs to be considered as part of the main =
rxgk-afs document.

Cheers,

Simon