The NEA0 algorithm shall be implemented such that it generates a KEYSTREAM of all zeroes (see clause D.2.1). The length of the KEYSTREAM generated shall be equal to the LENGTH input parameter. The generated KEYSTREAM requires no other input parameters but the LENGTH. Apart from this, all processing performed in association with ciphering shall be exactly the same as with any of the ciphering algorithms specified in this Annex.
The NIA0 algorithm shall be implemented in such way that it shall generate a 32 bit MAC-I/NAS-MAC and XMAC-I/XNAS-MAC of all zeroes (see clause D.3.1). Replay protection shall not be activated when NIA0 is activated. All processing performed in association with integrity (except for replay protection) shall be exactly the same as with any of the integrity algorithms specified in this Annex except that the receiver does not check the received MAC.
The NIA0 shall not be used for signalling radio bearers (SRBs) except for unauthenticated emergency sessions for unauthenticated UEs in LSM.
The NIA0 shall not be used for data radio bearers (DRBs).
The input parameters to the ciphering algorithm are a 128-bit cipher key named KEY, a 32-bit COUNT, a 5-bit bearer identity BEARER, the 1-bit direction of the transmission i.e. DIRECTION, and the length of the keystream required i.e. LENGTH. The DIRECTION bit shall be 0 for uplink and 1 for downlink.
Figure D.2.1.1-1 illustrates the use of the ciphering algorithm NEA to encrypt plaintext by applying a keystream using a bit per bit binary addition of the plaintext and the keystream. The plaintext may be recovered by generating the same keystream using the same input parameters and applying a bit per bit binary addition with the ciphertext.
Based on the input parameters the algorithm generates the output keystream block KEYSTREAM which is used to encrypt the input plaintext block PLAINTEXT to produce the output ciphertext block CIPHERTEXT.
The input parameter LENGTH shall affect only the length of the KEYSTREAM BLOCK, not the actual bits in it.
The input parameters to the integrity algorithm are a 128-bit integrity key named KEY, a 32-bit COUNT, a 5-bit bearer identity called BEARER, the 1-bit direction of the transmission i.e. DIRECTION, and the message itself i.e. MESSAGE. The DIRECTION bit shall be 0 for uplink and 1 for downlink. The bit length of the MESSAGE is LENGTH.
Figure D.3.1.1-1 illustrates the use of the integrity algorithm NIA to authenticate the integrity of messages.
Based on these input parameters the sender computes a 32-bit message authentication code (MAC-I/NAS-MAC) using the integrity algorithm NIA. The message authentication code is then appended to the message when sent. For integrity protection algorithms, the receiver computes the expected message authentication code (XMAC-I/XNAS-MAC) on the message received in the same way as the sender computed its message authentication code on the message sent and verifies the data integrity of the message by comparing it to the received message authentication code, i.e. MAC-I/NAS-MAC.
For 128-NEA1 is the test data for UEA2 in TS 35.217 can be reused directly as there is an exact, one-to-one mapping between UEA2 inputs and 128-NEA1 inputs.
For 128-NIA1 is the test data for 128-EIA1 in clause C.4 of TS 33.401 can be reused directly as there is an exact, one-to-one mapping between 128-EIA1 inputs and 128-NIA1 inputs.
For 128-NEA2 is the test data for 128-EEA2 in clause C.1 of TS 33.401 can be reused directly as there is an exact, one-to-one mapping between 128-EEA2 inputs and 128-NEA2 inputs.
For 128-NIA2 is the test data for 128-EIA2 in clause C.2 of TS 33.401 can be reused directly as there is an exact, one-to-one mapping between 128-EIA2 inputs and 128-NIA2 inputs.
For 128-NEA3 is the test data for 128-EEA3 in TS 35.223 can be reused directly as there is an exact, one-to-one mapping between 128-EEA3 inputs and 128-NEA3 inputs.
For 128-NIA3 is the test data for 128-EIA3 in TS 35.223 can be reused directly as there is an exact, one-to-one mapping between 128-EIA3 inputs and 128-NIA3 inputs.
The UE in RRC_CONNECTED mode sends measurement reports to the network in accordance with the measurement configuration provided by the network. These measurement reports have security values in being useful for detection of false base stations or SUPI/5G-GUTI catchers. The network, in an implementation specific way, could choose UEs or tracking areas or duration for which the measurement reports are to be analysed for detection of false base station. The present Annex gives examples of how measurement reports from UEs could be used for detection of false base station, and some actions thereafter.
The received-signal strength and location information in measurement reports can be used to detect a false base station which attract the UEs by transmitting signal with higher power. They can also be used to detect a false base station which replays the genuine MIB/SIB without modification.
In order to detect a false base station which replays modified version of broadcast information to prevent victim UEs from switching back and forth between itself and genuine base stations (e.g. modifying neighbouring cells, cell reselection criteria, registration timers, etc. to avoid the so called ping-pong effect), information on broadcast information can be used to detect inconsistency from the deployment information.
Further, a false base station which uses inconsistent cell identifier or operates in inconsistent frequency than the deployment of the genuine base stations, can be detected respectively by using the cell identifier or the frequency information in the measurement reports.
Measurement reports collected from multiple UEs can be used to filter out incorrect reports sent by a potential rogue UE.
Upon detection of the false base station, the operator can take further actions, e.g. informing legal authorities or contacting the victim UE.
EAP-AKA' includes optional support for identity privacy mechanism that protects the privacy against passive eavesdropping. The mechanism is described in Section 4.1.1.2 of RFC 4187, and it uses pseudonyms that are delivered from the EAP server to the peer as part of an EAP-AKA exchange. The privacy mechanism described in RFC 4187 corresponds to the privacy provided by 5G-GUTI, however, assignment of 5G-GUTI is done outside the EAP framework in 5GS.
TS 33.501 assumes that the SUCI is sent outside the EAP messages, however, the peer may still receive EAP-Request/Identity or EAP-Request/AKA-Identity messages. Table F.2-1 specifies how the 5G UE shall behave when receiving such requests.
EAP-Response/AKA-Client-Error with the error code "unable to process packet"
(2)
EAP-Request/AKA-Identity
AT_FULLAUTH_REQ
EAP-Response/AKA-Identity
AT_IDENTITY=SUCI (3)
EAP-Request/AKA-Identity
AT_ANY_ID_REQ
EAP-Response/AKA-Identity
AT_IDENTITY=fast re-auth identity OR
AT_IDENTITY=SUCI (4)
RFC 3748 allows the peer to respond with abbreviated Identity Response where the peer-name portion of the NAI has been omitted. The 5G UE responds with SUCI in the same format as sent in the Registration Request, where the peer name has been encrypted.
RFC 4187 allows the peer to respond with a pseudonym (cf. 5G-GUTI) or the permanent identity (i.e. SUPI). The 5G UE follows the "conservative" policy that has been described in Section 4.1.6 of RFC 4187 (Attacks against Identity Privacy) for the pseudonym based privacy, i.e. the peer shall not reveal its permanent identity. Instead, the peer shall send the EAP-Response/AKA-Client-Error packet with the error code "unable to process packet", and the authentication exchange terminates. The peer assumes that the EAP-Request/AKA-Identity originates from an attacker that impersonates the network, and for this reason refuses to send the cleartext SUPI.
RFC 4187 allows the peer to respond with a pseudonym (cf. 5G-GUTI) or the permanent identity (i.e. SUPI). The 5G UE responds with SUCI.
RFC 4187 allows the peer to respond with a fast re-authentication identity, pseudonym (cf. 5G-GUTI) or the permanent identity (i.e. SUPI). If the 5G UE supports fast re-authentication, it responds with the fast re-authentication identity, and if the 5G UE does not support fast re-authentication, it responds with SUCI.
EAP-AKA' uses the subscriber identity (Identity) as an input to the key derivation when the key derivation function has value 1 (i.e. MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)). Section 7 of RFC 4187 describes that the Identity is taken from the EAP-Response/Identity or EAP-Response/AKA-Identity AT_IDENTITY attribute sent by the peer. This principle is not applied to the 5GS.
If the AT_KDF_INPUT parameter contains the prefix "5G:", the AT_KDF parameter has the value 1 and the authentication is not related to fast re-authentication, then the UE shall set as the Identity for key derivation. When the SUPI Type is IMSI, the Identity shall be set to IMSI as defined in clause 2.2 of TS 23.003. When the SUPI type is network specific identifier, the Identity shall be set to Network Access Identifier (NAI) as defined in clause 28.7.2 of TS 23.003. When the SUPI type is GLI, the Identity shall be set to GLI taking format of NAI as defined in clause 28.15.2 of TS 23.003. When the SUPI type is GCI, the Identity shall be set to GLI taking format of NAI as defined in clause 28.16.2 of TS 23.003. This principle applies to all full EAP-AKA' authentications, even if the UE sent SUCI in NAS protocol or if the UE sent SUCI in the respose to the EAP identity requests as described in Table F.2-1 or if no identity was sent because the network performed re-authentication. The only exception is fast re-authentication when the UE follows the key derivation as described in RFC 5448 for fast re-authentication.