Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.401  Word version:  17.3.0

Top   Top   Up   Prev   Next
1…   4   5…   6…   6.2…   7…   7.2.5…   7.2.8   7.2.9…   7.3…   8…   9…   10…   11…   15…   A…   B…   C…   C.1.6   C.2…   C.2.7   C.2.8   C.3…   C.4.7   D…   E…   E.2…   E.3…   F…   G…   H…   I…   K…

 

I (Normative)  Hash functions |R14|p. 164

I.1  Generalp. 164

This Annex describes how to form the inputs of non-keyed hash calculations using the KDF described in TS 33.220.

I.2  HASHMME and HASHUEp. 164

When the MME and UE shall derive HASHMME and HASHUE respectively using the following parameters as input to the KDF given in TS 33.220.
  • S = Unprotected ATTACH Request or TAU Request message,
  • Key = 256-bit string of all 0s
HASHMME or HASHUE are the 64 least significant bits of the 256 bits of the KDF output.

I.3Void

J (Normative)  Restricted Local Operator Services (RLOS) |R16|p. 165

J.1  Restricted Local Operator Services (RLOS)p. 165

J.1.1  Generalp. 165

Restricted Local Operator Services (RLOS) is an optional feature supported in certain countries and is specified in TS 23.401. RLOS is always initiated by the UE based on explicit request from the user. Access to RLOS may be allowed for UEs in limited service state by the serving network depending on local regulation and operator policy. Allowing access to RLOS for UEs in limited service state means that there is no network authentication and in such a case further security checks need to be performed by the UE to address the potential security threats due to this lack of network authentication (i.e., EPS AKA).
This Annex is not applicable for UEs accessing RLOS after performing successful EPS AKA authentication as they follow the security procedures specified in the main body of this specification.
Up

J.1.2  Algorithm negotiation for unauthenticated UEs in LSMp. 165

UEs that are in limited service mode (LSM) and that cannot be authenticated by the MME (for whatever reason) may still be allowed to establish RLOS calls by sending the RLOS attach request message as specified in TS 23.401.
It shall be possible to configure the MME to allow unauthenticated UEs in LSM to establish bearers for RLOS calls or not. If an MME is configured to allow unauthenticated UEs in LSM to establish bearers for an RLOS call, the MME shall for the NAS protocol use EIA0 and EEA0 as the integrity and ciphering algorithm respectively.
If the MME allows an unauthenticated UE in LSM to establish bearers for RLOS calls after it has received the RLOS attach request message from the UE, the MME shall:
  • Select EIA0 and EEA0, regardless of the supported algorithms announced previously by the UE as the NAS algorithms and signal this to the UE via the NAS security mode command procedure when activating the EPS NAS security context.
  • Set the UE EPS security capabilities to only contain EIA0 and EEA0 when sending these to the eNB in the following messages:
    • S1 UE INITIAL CONTEXT SETUP
    • S1 UE CONTEXT MODIFICATION REQUEST
    • S1 HANDOVER REQUEST
If the UE has initiated an RLOS connection, the UE may accept the use of EIA0 for NAS and RRC signalling protection. The UE shall also support the mitigations given in clause J.1.3 to reduce the impact of a lack of network authentication for RLOS connections.
Up

J.1.3  Additional UE behaviour for RLOS connectionsp. 165

If the UE is in LSM and wishes to initiate an RLOS connection, the ME shall perform the following checks before initiating the RLOS attach procedure with the network:
  1. The ME shall enforce access control on applications that are authorized to trigger establishment of RLOS connection. Applications on the ME that are not explicitly authorized shall not be allowed to trigger the initiation of RLOS connection.
  2. A user confirmation shall be requested before the ME initiates RLOS connection. As part of the user confirmation, the user shall be notified of the security risk due to the lack of network authentication.
  3. The ME shall maintain a white list of MCCs where RLOS is supported (i.e., by preconfiguring the white list either at the time of ME manufacturing or hardcoding). The ME shall check that the MCC of the network name that advertises RLOS service is present in the white list before initiating the RLOS connection.
  4. If a USIM is present, the ME shall check that the MCC part of the IMSI configured in the USIM is present in the white list of MCCs on the ME before initiating the RLOS connection.
If the above checks are successful, the ME shall initiate the RLOS attach procedure. If any one of the above checks fail, then the ME shall not initiate the RLOS attach procedure.
Up

J.2  Recommendations for RLOSp. 166

Allowing RLOS connections to the network for UEs that are in LSM means that there is no network authentication. This means that it is not possible to protect the NAS and AS traffic. RLOS services should be protected by implementing application layer security mechanisms. Such application layer security mechanisms are dependent on the RLOS service and are outside the scope of this document.

J.3  MCC whitelist for RLOSp. 166

The whitelist for RLOS shall be: MCC = 310, MCC = 311, MCC= 312, MCC=313, MCC=314, MCC=315 and MCC = 316.

Up   Top   ToC