On 16 Feb 2013, at 21:42, Andrew Deason wrote: > On Sat, 16 Feb 2013 15:26:43 +0000 > Simon Wilkinson <[email protected]> wrote: > >> There's two issues here. Firstly, only machines hosting vlservers have >> access to the key material necessary to accept GSSNegotiate calls for >> afs-rxgk@_afs.cell. Machines with the rxgk cell-wide key can accept >> rxgk challenges using cell-wide tokens, but the failure mode here is >> such that I don't think you'd want to base a key negotiation on it. > > What failure mode?
It's the whole RX abort problem again - errors in the RX challenge/response are conveyed by means of RX aborts, which are unprotected. So an attacker can cause security connection establishment to fail with whatever error code they like. This means that where there is a choice (of mechanisms, or of keys) an attacker can force the connection to proceed using the a configuration of their choosing. Relying on this for key negotiation opens us up to a downgrade attack. Cheers, Simon _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
