Identity Query is the 5GMM procedure where the network asks the UE to provide a specific identity. In 5G, the network commonly requests SUCI when it cannot identify the UE from the temporary identity supplied earlier. The UE returns Identity Response containing the requested mobile identity.

It is a tiny procedure with only two messages. But when it shows up in a registration log, it usually tells you something important about the network side. The AMF did not recognize the UE, and the rest of the registration is about to change because of that.

• Why we need Identity Query ?
• Signaling Sequence
• Identity Types
• Message Structure
  • Message Contents
  • Example : Identity Request
  • Example : Identity Response
• Reference

Why we need Identity Query ?

Normally the UE does not send its permanent identity at all. It sends a 5G-GUTI, a temporary identity that the AMF assigned earlier. This protects the privacy of the user. But it also creates a problem. What if the AMF that receives the 5G-GUTI cannot map it back to a subscriber ? This happens when the AMF has lost the context, for example after a restart, or when the old AMF cannot be reached.

In that case the AMF has no way to authenticate the UE, because it does not know which subscriber to ask the UDM about. So it asks the UE directly with an IDENTITY REQUEST. In 5G, the identity requested in this situation is the SUCI. The SUCI is the SUPI in concealed form, so the permanent identity still does not travel over the air in clear, at least when a real protection scheme is used.

The same procedure is also used to get the equipment identity, the PEI. The AMF can ask for the IMEI or the IMEISV, and for some devices the MAC address or the EUI-64. A failed authentication can also trigger it. After an AUTHENTICATION FAILURE with cause #20 MAC failure, the network may ask for the SUCI to check whether the 5G-GUTI pointed to the right subscriber.

• The 5G-GUTI is the normal identity : the identity query is the fallback when the AMF cannot resolve it.
• SUCI keeps the SUPI concealed : the network gets the permanent identity without exposing it on the air interface.
• The procedure also retrieves the PEI : IMEI, IMEISV, MAC address or EUI-64, depending on the device.
• Only the network starts it : the UE has to answer whenever it is in 5GMM-CONNECTED mode.

Signaling Sequence

The procedure itself is one request and one response. The AMF starts T3570 when it sends the request and stops it when the response arrives. The table below shows the two messages, and the identity type in the request decides what comes back.

T3570 is 6 seconds in normal NR access. On each of the first four expiries the AMF retransmits the request. On the fifth expiry it aborts the identification procedure, and it also aborts any ongoing 5GMM procedure, such as the registration that needed the identity. On the UE side, a fresh SUCI starts T3519 for 60 seconds. While T3519 runs, the UE answers another SUCI request with the same stored SUCI rather than a new one.

In practice you see this procedure inside an initial registration. The following table shows that context, with the times from the Amarisoft log used in the examples below.

• T3570 is 6 seconds, with four retransmissions : the fifth expiry aborts the parent 5GMM procedure too.
• T3519 keeps the SUCI stable for 60 seconds : repeated SUCI requests in that window get the same SUCI.
• An identity query before authentication is a clue : it tells you the AMF could not use the 5G-GUTI from the registration request.

Identity Types

The request carries only one real field, the 5GS identity type. It is three bits, and it decides both what the UE sends back and whether the exchange may happen without NAS security. The following table lists the values from 24.501 Table 9.11.3.3.1.

Why is SUCI special ? It is the only identity type that may be requested and answered before NAS security is in place. 24.501 clause 4.4.4.2 lets the UE process an IDENTITY REQUEST without integrity protection only when the requested identity is SUCI. Clause 4.4.4.3 lets the AMF process the IDENTITY RESPONSE in the same case. A request for the IMEI or IMEISV has to wait until the security mode control is done. This is why the IMEISV usually arrives in the Security Mode Complete instead.

If the UE cannot encode the requested identity, for example because there is no valid USIM, it answers with the identity type No identity rather than leaving the message unanswered.

• SUCI can be exchanged without security : the AMF needs it before authentication, so it has to work unprotected.
• Other identities need security first : an IMEI or IMEISV request is only processed under an active NAS security context.
• No identity is a valid answer : it tells the network the UE could not build the requested identity.

Message Structure

Identity Request contains the requested identity type. Identity Response contains the mobile identity itself, such as SUCI, 5G-GUTI, IMEI, or IMEISV depending on what the network requested.

Message Contents

Both messages are as small as a 5GMM message can be. Each one has a single mandatory IE after the header, and neither has any optional IE. The following table shows the two side by side.

The response reuses the 5GS mobile identity IE, the same IE that the registration request uses for the 5G-GUTI or SUCI. So a decoder shows the same structure in both messages, and only the identity type inside it changes.

Example : Identity Request

The following example is based on an Amarisoft MME log where the AMF requests SUCI. The whole decoded NAS message is shown below. Notice first that the security header is 0, plain, because the AMF has no security context it can use for this UE.

Decoded NAS message from an Amarisoft log. Field values are from a live capture, not from the specification.

04:09:33.961 [NAS] DL 0064 5GMM: Identity request
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x0 (Plain 5GS NAS message, not security protected)
        Message type = 0x5b (Identity request)
        Identity type = 0x1 (SUCI)

The request is plain, and it asks for the SUCI. This is the one combination the UE is allowed to process without integrity protection. If the AMF had asked for the IMEI in a plain message, the UE would not have processed it.

Example : Identity Response

The following example is based on the matching Identity Response in the same Amarisoft MME log. The whole decoded NAS message is shown below. Compare its security header with the request above, because the two do not match.

Decoded NAS message from an Amarisoft log. Field values are from a live capture, not from the specification.

04:09:33.981 [NAS] UL 0064 5GMM: Identity response
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x1 (Integrity protected)
        Auth code = 0xef602896
        Sequence number = 0x09
        Protocol discriminator = 0x7e (5GS Mobility Management)
        Security header = 0x0 (Plain 5GS NAS message, not security protected)
        Message type = 0x5c (Identity response)
        Mobile identity:
          SUCI
            SUPI format = 0 (IMSI)
            MCC = 001
            MNC = 01 
            Routing indicator = 0
            Protection sheme id = 0 (Null scheme)
            Home network public key identifier = 0
            MSIN = 0123456789

There are a couple of points that I want you to notice here. First, the response is integrity protected, with sequence number 9, even though the request was plain. The UE still has its own current security context from an earlier registration, so it protects the message with it. My understanding is that the AMF no longer had a matching context, which is why it asked for the identity in the first place. 24.501 clause 4.4.4.3 covers this case. Before the secure exchange is established, the AMF processes an IDENTITY RESPONSE with SUCI, even when its MAC fails the integrity check.

Second, look at the protection scheme. It is 0, the null scheme. With the null scheme the SUCI is not concealed at all, and the MSIN 0123456789 appears in clear. So this is a test SIM in a test network. A commercial SIM would normally use Profile A or Profile B, and then the MSIN part appears only as an encrypted scheme output.

This exchange also explains the rest of the same log. The Security Mode Command 60 ms later creates a new context, ngKSI 3, and sets RINMR. The AMF could not verify the original registration request under the old context, so it asks for it again under the new one.

• A plain request with a protected response is possible : the UE protects with its own current context, even when the AMF has lost it.
• Null scheme means the SUPI is in clear : MCC 001, MNC 01 and MSIN 0123456789 together form the IMSI.
• The identity query explains the later RINMR : the AMF had no usable context, so the security mode control had to start fresh.

Reference

The procedure, the timers, the identity type coding, the integrity rules and the message contents on this page were checked against 24.501.

• 24.501 : Non-Access-Stratum (NAS) protocol for 5G System (5GS). The identification procedure in clause 5.4.3, the integrity checking rules in clauses 4.4.4.2 and 4.4.4.3, the message contents in clause 8.2, the 5GS identity type in Table 9.11.3.3.1 and the T3570 and T3519 timer tables. The version read was v20.1.0 (Release 20).
• 33.501 : Security architecture and procedures for 5G system. Named by 24.501 for the SUCI generation. Not read directly for this page.
• Registration, Authentication and Security Mode Setup : the procedures around the identity query in the same log.