summaryrefslogtreecommitdiff
path: root/cesar/mac
diff options
context:
space:
mode:
authorYacine Belkadi2012-11-20 16:40:46 +0100
committerYacine Belkadi2012-12-12 11:48:27 +0100
commitbc9a8896da07c993d236a2d491778bf3007241b2 (patch)
treeb67c22670374d1c78a35bbed4bd09b4f9cc953f5 /cesar/mac
parent412307fcd83e5ecd558d0058c97bf43fdbd2a7a0 (diff)
cesar/cp/cco/action: fix EKS in NEK update process, closes #3346
Periodically (each HPAV_NEK_CHANGE_MS), the CCO changes the NEK. It sends the new NEK and its EKS to the STA. The problem was that instead of sending a new EKS for the new NEK, it sent the current EKS. So the NEK update didn't work. On the first update, the STA was able to recover by sending a GET_KEY_REQ, but not on the second NEK update. So the traffic stopped after the second NEK update. Then the STA leaves the AVLN, re-joins, the cycle goes on. Below is the detailed explanation: Initially, after auth/assoc: CCO: Current: NEK[O] = { EKS:0, key:A }, Next: NEK[1] = { EKS:_, Key:_ } STA: Current: NEK[O] = { EKS:0, key:A }, Next: NEK[1] = { EKS:_, Key:_ } nek_change: CCO generates a new NEK (B), but because of data_req.new_eks = bsu_nek_index_current (ctx->bsu); in cp_av_cco_action_cm_set_key_cnf_receive, it sends the current EKS as the next one. So we get: CCO: Current: NEK[O] = { EKS:0, key:A }, Next: NEK[1] = { EKS:1, Key:B } STA: Current: NEK[O] = { EKS:0, key:A }, Next: NEK[1] = { EKS:0, Key:B } When the STA sees that the next EKS announced by the beacon is EKS=1, and that it doesn't have it, it sends a GET_KEY_REQ. The CCO responds with the correct new EKS and key. Thus we get: CCO: Current: NEK[O] = { EKS:0, key:A }, Next: NEK[1] = { EKS:1, Key:B } STA: Current: NEK[O] = { EKS:0, key:A }, Next: NEK[1] = { EKS:1, Key:B } and everything is fine on the nek_switch: CCO: Next: NEK[O] = { EKS:0, key:A }, Current: NEK[1] = { EKS:1, Key:B } STA: Next: NEK[O] = { EKS:0, key:A }, Current: NEK[1] = { EKS:1, Key:B } On the next nek_change, the CCO generates a new NEK (C). The exchange results in: CCO: Next: NEK[O] = { EKS:0, key:C }, Current: NEK[1] = { EKS:1, Key:B } STA: Next: NEK[O] = { EKS:1, key:C }, Current: NEK[1] = { EKS:1, Key:B } Then the STA sees new_EKS=0 in the beacon. It sends a GET_KEY_REQ. But when it receives the GET_KEY_CNF, it is unable to decrypt it. The received GET_Key_CNF was encrypted with { EKS:1, Key:B }. pbproc_frda__handle() looks in NEK[0] first and finds EKS:1, so it (wrongly) decrypts with Key:C. Thus, GET_KEY_CNF is not processed, the new NEK is not received, the STA resends a few GET_KEY_REQ in vain, traffic stops, and after a moment the STA leaves.
Diffstat (limited to 'cesar/mac')
0 files changed, 0 insertions, 0 deletions