Change in ...osmo-msc[master]: manual: adjust and fix auth and ciph docs

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

neels gerrit-no-reply at lists.osmocom.org
Thu Aug 1 16:23:43 UTC 2019


neels has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-msc/+/15021


Change subject: manual: adjust and fix auth and ciph docs
......................................................................

manual: adjust and fix auth and ciph docs

Change-Id: Iffe159d4c0e0e9439f8719e0ddd28f06d4c80d9f
---
M doc/manuals/chapters/net.adoc
1 file changed, 54 insertions(+), 14 deletions(-)



  git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/21/15021/1

diff --git a/doc/manuals/chapters/net.adoc b/doc/manuals/chapters/net.adoc
index 06be4ba..aa0a2f3 100644
--- a/doc/manuals/chapters/net.adoc
+++ b/doc/manuals/chapters/net.adoc
@@ -101,32 +101,56 @@
 
 === 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 compatibility, 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
- 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.

-- 
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/15021
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: Iffe159d4c0e0e9439f8719e0ddd28f06d4c80d9f
Gerrit-Change-Number: 15021
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr at sysmocom.de>
Gerrit-MessageType: newchange
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190801/087679f6/attachment.htm>


More information about the gerrit-log mailing list