|
|
|
@ -101,32 +101,56 @@ operating system on which OsmoMSC is running. |
|
|
|
|
|
|
|
|
|
=== Authentication |
|
|
|
|
|
|
|
|
|
Authorized subscribers must be entered in the HLR database, see the _OsmoHLR |
|
|
|
|
reference manual_ <<userman-osmohlr>>. If authentication tokens (such as KI for |
|
|
|
|
2G, or K and OP/OPC for UMTS) are present in the HLR, OsmoMSC will only attach |
|
|
|
|
a subscriber after successful authentication. |
|
|
|
|
A subscriber's IMSI must be entered in the HLR database to be able to attach. A |
|
|
|
|
subscriber-create-on-demand feature is also available, see the _OsmoHLR |
|
|
|
|
reference manual_ <<userman-osmohlr>>. |
|
|
|
|
|
|
|
|
|
If no authentication keys are present in the HLR for a given subscriber, |
|
|
|
|
OsmoMSC will attach the subscriber _without_ authentication. You can reject |
|
|
|
|
subscribers that lack authentication info in the HLR with this setting: |
|
|
|
|
A known IMSI in the HLR may or may not have authentication keys associated, |
|
|
|
|
which profoundly affects the ability to attach and the algorithms used to |
|
|
|
|
negotiate authentication, as the following sections explain for 2G and 3G. |
|
|
|
|
|
|
|
|
|
==== Authentication on 2G |
|
|
|
|
|
|
|
|
|
If authentication tokens (such as KI for 2G, or K and OP/OPC for UMTS) are |
|
|
|
|
present in the HLR, OsmoMSC will only attach a subscriber after successful |
|
|
|
|
authentication. Note that the 3G authentication keys are also used on 2G when |
|
|
|
|
the MS indicates UMTS AKA capability, in which case the full UMTS style mutual |
|
|
|
|
authentication may indeed take place on 2G (GERAN). |
|
|
|
|
|
|
|
|
|
On 2G, if no authentication keys are present in the HLR for a given subscriber, |
|
|
|
|
OsmoMSC will attach the subscriber _without_ authentication. Subscribers that |
|
|
|
|
lack authentication keys can always be rejected with this setting: |
|
|
|
|
|
|
|
|
|
---- |
|
|
|
|
network |
|
|
|
|
authentication required |
|
|
|
|
---- |
|
|
|
|
|
|
|
|
|
==== Authentication on 3G |
|
|
|
|
|
|
|
|
|
3G (UTRAN) always requires authentication (a.k.a. Integrity Protection) by |
|
|
|
|
specification, and hence authentication keys must be present in the HLR for a |
|
|
|
|
subscriber to be able to attach on 3G. |
|
|
|
|
|
|
|
|
|
OsmoMSC always indicates UIA1 and UIA2 as permitted Integrity Protection |
|
|
|
|
algorithms on 3G. |
|
|
|
|
|
|
|
|
|
=== Ciphering |
|
|
|
|
|
|
|
|
|
To enable ciphering on the radio link, authentication must take place first: |
|
|
|
|
the Kc resulting from authentication is the key used for ciphering. Hence, all |
|
|
|
|
subscribers must have authentication tokens available in the HLR for ciphering. |
|
|
|
|
the Kc resulting from authentication is the key used for ciphering. Hence, to |
|
|
|
|
be able to use ciphering, a subscriber must have authentication tokens |
|
|
|
|
available in the HLR. |
|
|
|
|
|
|
|
|
|
==== Ciphering on 2G |
|
|
|
|
|
|
|
|
|
The MS, BTS and MSC must agree on a ciphering algorithm to use. |
|
|
|
|
|
|
|
|
|
- The MS sends its supported ciphering algorithms via Classmark IEs during |
|
|
|
|
Location Updating. |
|
|
|
|
- Typically the BSC needs to know which A5 ciphers are supported by connected |
|
|
|
|
BTSes. |
|
|
|
|
BTSes, see the `network / encryption a5` configuration item for OsmoBSC |
|
|
|
|
<<vty-ref-osmobsc>>. |
|
|
|
|
- Finally, OsmoMSC may impose that specific A5 ciphers shall not be considered. |
|
|
|
|
|
|
|
|
|
It is the responsibility of the BSC to then pick an A5 cipher that satisfies |
|
|
|
@ -143,12 +167,28 @@ network |
|
|
|
|
+ |
|
|
|
|
---- |
|
|
|
|
network |
|
|
|
|
encryption a5 3 |
|
|
|
|
encryption a5 1 3 |
|
|
|
|
---- |
|
|
|
|
|
|
|
|
|
- Never use A5/2: it is an "export grade cipher" and has been deprecated for |
|
|
|
|
its low ciphering strength. |
|
|
|
|
|
|
|
|
|
NOTE: At the time of writing, OsmoMSC supports setting only a single A5 cipher, |
|
|
|
|
while it should be able to allow a set of ciphers. This is subject to ongoing |
|
|
|
|
development. |
|
|
|
|
- To allow either no encryption or any of A5/1 or A5/3 based on the presence of |
|
|
|
|
authentication keys and abilities of the MS, SIM and BSC configuration, it is |
|
|
|
|
recommended to enable all ciphers in OsmoMSC. The highest available A5 cipher |
|
|
|
|
will be used; the order in which the A5 options are configured does not |
|
|
|
|
affect the choice. |
|
|
|
|
+ |
|
|
|
|
---- |
|
|
|
|
network |
|
|
|
|
encryption a5 0 1 3 |
|
|
|
|
---- |
|
|
|
|
|
|
|
|
|
==== Ciphering on 3G |
|
|
|
|
|
|
|
|
|
While authentication is always required on 3G, ciphering is optional. |
|
|
|
|
|
|
|
|
|
So far OsmoMSC lacks explicit configuration for ciphering on 3G. As an interim |
|
|
|
|
solution, ciphering is always enabled on 3G. |
|
|
|
|
|
|
|
|
|
OsmoMSC indicates UEA1 and UEA2 as permitted encryption algorithms on 3G. |
|
|
|
|