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