cosmetic prep: tell vlr_ops.set_ciph_mode() whether UMTS AKA is used
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
diff --git a/include/osmocom/msc/vlr.h b/include/osmocom/msc/vlr.h
index df7d354..b625608 100644
--- a/include/osmocom/msc/vlr.h
+++ b/include/osmocom/msc/vlr.h
@@ -207,7 +207,7 @@
int (*tx_cm_serv_rej)(void *msc_conn_ref, enum vlr_proc_arq_result result);
int (*set_ciph_mode)(void *msc_conn_ref, enum vlr_ciph ciph_mode,
- bool retrieve_imeisv);
+ bool umts_aka, bool retrieve_imeisv);
/* UTRAN: send Common Id (when auth+ciph are complete) */
int (*tx_common_id)(void *msc_conn_ref);
@@ -433,6 +433,7 @@
struct osmo_fsm_inst *fi,
void *msc_conn_ref,
enum vlr_ciph ciph_mode,
+ bool umts_aka,
bool retrieve_imeisv);
bool vlr_use_umts_aka(struct osmo_auth_vector *vec, bool is_r99);