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 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.

The present Annex describes the 3GPP 5G profile for EAP-AKA' described in RFC 5448, and RFC 4187.

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.

1. 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.
2. 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.
3. 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.
4. 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.