That's wrong then. subscriber_id should be unique for AuthInfo, but not for
AuthTuples. We can (and should!) have multiple auth tuples for a subscriber
and also think of a way how we can cycle through them (or randomly select one
of them each time we need one)
AFAIK, the phone only keeps the data from last authentication ( Kc & key_seq ).
When you send a CIPHER MODE COMMAND, it will use the last negotiated one, no choice there.
The "key sequence" parameter which is given by the network during the authentication is just there so that on the next channel opening, the MS can send it (in LOC UPD REQ / PAGING RESP / CM SERV REQ) and the network can compare it to the last key_seq it emitted for this subscriber.
* If they match, the network 'knows' that the last negotiated Kc is still ok (with a 1/16 chance of being wrong ...) and doesn't need a new authentication.
* If they don't match, it's probably that the GSM has roamed somewhere else at some point and the Kc in the phone and in the Network don't match, so they need to renegotiate a new one.
Keeping multiple AuthTuple for a subscriber would be useless since only the last one has usable data. And it's even easier if we only keep one because this way, to find the next "key sequence", we can just take the old stored one and increment it ...
Sylvain