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.
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.
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.
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.
Based on the above assumptions, the following features do not have to be supported:
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.
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
Bits "1" to "7" are reserved for future standardization use. Bits "1" to "7" shall be set to 0 while not yet specified for a particular use.
Bits "8" to "15" can be used for proprietary purposes. See Annex F for examples usages.
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).
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.
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.
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.
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.
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.
In order to protect the Iu and Iur interfaces as required by Annexes X.2.3 and 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.