Content for TS 33.102 Word version: 17.0.0
F Example uses of the proprietary part of the AMF
F.1 Support multiple authentication algorithms and keys
F.2 Changing sequence number verification parameters
F.3 Setting threshold values to restrict the lifetime of cipher and integrity keys
G Support of algorithm change features
H Usage of the AMF
I Security requirements for RNCs in exposed locations
I.1 General
I.2 Requirements for RNCs in exposed locations
I.3 Security mechanisms for interfaces with RNCs in exposed locations
J Modified AKA to avoid keystream re-use during re-synchronisations
J.1 Modified f5* function
$ Change history
F Example uses of the proprietary part of the AMF p. 71
F.1 Support multiple authentication algorithms and keys p. 71
A mechanism to support the use of multiple authentication and key agreement algorithms is useful for disaster recovery purposes. AMF may be used to indicate the algorithm and key used to generate a particular authentication vector.
The USIM keeps track of the authentication algorithm and key identifier and updates it according to the value received in an accepted network authentication token.
F.2 Changing sequence number verification parameters p. 71
This mechanism is used in conjunction with the mechanism for the verification of sequence number freshness in the USIM described in C.2.2.
The USIM shall also be able to put a limit L on the difference between SEQ MS (the highest SEQ accepted so far) and a received sequence number SEQ. A mechanism to change this parameter L dynamically is useful since the optimum for these parameters may change over time. AMF is used to indicate a new value of L to be used by the USIM.
F.3 Setting threshold values to restrict the lifetime of cipher and integrity keys p. 71
According to clause 6.4.3, the USIM contains a mechanism to limit the amount of data that is protected by an access link key set. The AMF field may be used by the operator to set or adjust this limit in the USIM. For instance, there could be two threshold values and the AMF field instructs the USIM to switch between them.
The USIM keeps track of the limit to the key set life time and updates it according to the value received in an accepted network authentication token.
G (Normative) Support of algorithm change features |R7| p. 72
UEA2 and UIA2 have been developed as back up algorithms which should be installed in RNCs as soon as possible so that they are available for use in the hopefully unlikely event that the current algorithms UEA1 and UIA1 become compromised. Therefore it is reasonable to expect that operators will have been able to upgrade all their RNCs before the new algorithms need to be enabled. Consequently, algorithm change is only required at inter-network handover.
Based on the above assumptions, the following feature shall be supported:
- Encryption/integrity algorithm change at SRNC relocation with hard inter-network handover.
- Encryption/integrity algorithm change at "UE not involved" SRNC relocation for both the DCH and FACH cases.
- Encryption/integrity algorithm change at SRNC relocation with hard intra-network handover.
H (Normative) Usage of the AMF |R8| p. 73
The 16 bits in the AMF are numbered from "0" to "15" where bit "0" is the most significant bit and bit "15" is the least significant bit (see subclause 3.4)
Bit "0" is called the "AMF separation bit". It is used for the purposes of EPS (Evolved Packet System) and is specified in
- TS 33.401 for E-UTRAN access to EPS;
- TS 33.402 for non-3GPP access to EPS;
- TS 33.501 for 5G-RAN access to 5G System.
I (Normative) Security requirements for RNCs in exposed locations |R11| p. 73
I.1 General p. 73
RNCs may be deployed at exposed locations where they run a higher risk of physical attack than RNCs in physically protected parts of the operator domain. For such deployments, RNCs adhering to the security requirements in this Annex should be used. RNCs in other deployments are not required to adhere to these requirements.
RNCs may be found in exposed locations e.g. when RNC and NB are co-located in one node (collapsed RNC / NBs).
I.2 Requirements for RNCs in exposed locations p. 73
I.2.1 Requirements for setup and configuration p. 73
Setting up and configuring RNCs in exposed locations shall be authenticated and authorized so that attackers shall not be able to modify the settings and software configurations of the RNCs in exposed locations via local or remote access.
- The support of security associations is required between the 3G core network and the RNC in an exposed location and between adjacent RNCs in exposed locations. These security association establishments shall be mutually authenticated and used for user and control plane communication between the entities. The security associations shall be realized according to Annex I.3 of the present document.
- Communication between the O&M systems and the RNC in an exposed location shall be confidentiality, integrity and replay protected from unauthorized parties. The support of security associations is required between the RNC in an exposed location and an entity in the 3G core network or in an O&M domain trusted by the operator. These security association establishments shall be mutually authenticated.
- The RNC in an exposed location shall ensure that software/data change attempts are authorized.
- The RNC in an exposed location shall use authorized data/software.
- Sensitive parts of the boot-up process shall be executed with the help of the secure environment.
- Confidentiality of software transfer towards the RNC in an exposed location shall be ensured.
- Integrity protection of software transfer towards the RNC in an exposed location shall be ensured.
I.2.2 Requirements for key management inside RNCs in exposed locations p. 74
The 3G core network provides subscriber specific session keys for the RNCs in exposed locations. RNCs in exposed locations also hold long term keys used for the purpose of authentication and security association setup on the backhaul link. Protecting all these keys is important.
- Keys stored inside an RNC in an exposed location shall never leave a secure environment within the RNC in an exposed location except when done in accordance with the present document or other 3GPP specifications.
I.2.3 Requirements for handling user plane data p. 74
An RNC in an exposed location has to cipher and decipher user plane packets between the Uu reference point and the Iu reference point and to handle integrity protection for user plane packets for the Iu reference point.
- User plane data ciphering/deciphering and integrity handling shall take place inside the secure environment where the related keys are stored.
- The transport of user data over Iu shall be integrity, confidentiality-, and replay-protected from unauthorized parties. If this is to be accomplished by cryptographic means, Annex I.3 shall be applied.
I.2.4 Requirements for handling control plane data p. 74
An RNC in an exposed location has to provide confidentiality and integrity protection for control plane packets on the Iu and Iur reference points.
- Control plane data ciphering/deciphering and integrity handling shall take place inside the secure environment where the related keys are stored.
- The transport of control plane data over Iu and Iur shall be integrity-, confidentiality- and replay-protected from unauthorized parties. If this is to be accomplished by cryptographic means, Annex I.3 shall be applied.
I.2.5 Requirements for secure environment p. 74
The secure environment is logically defined within the RNC in an exposed location and is a composition of functions for the support of sensitive operations.
- The secure environment shall support secure storage of sensitive data, e.g. long term cryptographic secrets and vital configuration data.
- The secure environment shall support the execution of sensitive functions, e.g. en-/decryption of user data and the basic steps within protocols which use long term secrets (e.g. in authentication protocols).
- Sensitive data used within the secure environment shall not be exposed to external entities.
- The secure environment shall support the execution of sensitive parts of the boot process.
- The secure environment's integrity shall be assured.
- Only authorised access shall be granted to the secure environment, i.e. to data stored and used within, and to functions executed within.
I.3 Security mechanisms for interfaces with RNCs in exposed locations p. 75
In order to protect the Iu and Iur interfaces as required by Annex X.2.3 and Annex X.2.4, it is required to implement IPsec ESP as specified and profiled by TS 33.210, with confidentiality, integrity and replay protection.
IKEv2 with certificates based authentication shall be implemented. The certificates shall be implemented according to the profile described by TS 33.310. IKEv2 shall be implemented conforming to the IKEv2 profile described in TS 33.310.
For Iu and Iur, tunnel mode IPsec is mandatory to implement. On the core network side a SEG may be used to terminate the IPsec tunnel.
Transport mode IPsec is optional for implementation on Iu and Iur.
If the sender of IPsec traffic uses DiffServ Code Points (DSCPs) to distinguish different QoS classes, either by copying DSCP from the inner IP header or directly setting the encapsulating IP header's DSCP, the resulting traffic may be reordered to the point where the receiving node's anti-replay check discards the packet. If different DSCPs are used on the encapsulating IP header, then to avoid packet discard under one IKE SA and with the same set of traffic selectors, distinct child-SAs should be established for each of the traffic classes (using the DSCPs as classifiers) as is specified in RFC 4301.
J Modified AKA to avoid keystream re-use during re-synchronisations |R17| p. 76
J.1 Modified f5* function p. 76
This A shows how the AUTS calculation could be modified in order to avoid keystream re-use during AKA re-synchronisations procedure. The f5* function given in clause 6.3.3 only has RAND as a non-key input and hence if an authentication challenge (RAND, AUTN) is replayed, then the same AK is calculated which is then used to protect different SQN MS values. This possibly leaks some bits of SQN MS as shown in Borgaonkar et al (2019) [43].
If this is a concern to an operator, then a modified f5* function using MAC-S as an additional input can be used as shown in Figure J.1-1 with the dashed line showing the change from clause 6.3.3.
Figure J.1-1: Construction of the parameter AUTS with a modified f5* function
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
When using the modified f5* function, the re-synchronisation proceeds as described in clauses 6.3.3 and 6.3.5 with the following changes:
- in clause 6.3.3, the USIM calculates AUTS = Conc(SQN MS ) || MAC S where Conc(SQN MS) = SQN MS ⊕ f5*K(RAND, MAC-S) and MAC-S is calculated as given in clause 6.3.3; and
- in clause 6.3.5, the HE/AuC retrieves SQN MS from Conc(SQN MS) by computing Conc(SQN MS) ⊕ f5*K(RAND, MAC-S).
$ Change history p. 77
