2ef2da54ab
In case of UMTS AKA, the Kc for ciphering must be derived from the 3G auth tokens. tuple->vec.kc was calculated from the GSM algorithm and is not necessarily a match for the UMTS AKA tokens. To decide (in an upcoming patch) whether to use UMTS AKA derived Kc or the Kc from the auth vector, the set_ciph_mode() from vlr_ops needs to know whether UMTS AKA is being used. This could possibly derived from the msc_conn_ref, but all flags are already available in the vlr_lu_fsm and vlr_access_req_fsm. Hence add a umts_aka flag to the set_ciph_mode() callback invocation. The VLR FSMs thus decide whether UMTS AKA or GSM AKA is to be used during Ciphering Mode Command, which makes more sense than re-implementing the same decision process in the MSC. I considered placing the Kc derivation in vlr_set_ciph_mode() and only tell the MSC's set_ciph_mode() implementation the precise keys it should use, but the RAN particulars, and whether a Kc is used at all, rather belong with the MSC. Related: OS#2745 Prepares: If04e405426c55a81341747a9b450a69188525d5c Change-Id: I983c48347faf4ee1b405d8174b4e006c904157cf |
||
|---|---|---|
| .. | ||
| Makefile.am | ||
| vlr.c | ||
| vlr_access_req_fsm.c | ||
| vlr_access_req_fsm.h | ||
| vlr_auth_fsm.c | ||
| vlr_auth_fsm.h | ||
| vlr_core.h | ||
| vlr_lu_fsm.c | ||
| vlr_lu_fsm.h | ||