Protection of initial NAS message

[acetcom]

Hi @aligungr

Today, I've updated open5gs to protect an initial NAS message. The protection method can be found in the standard document below.

• TS33.501, Ch 6.4.6. Protection of initial NAS message
• TS24.501. Ch 4.4.6. Protection of initial NAS signalling messages

As shown in the pcap below, the UE in UERANSIM contains non-cleartext IEs in Registration request message. Therefore, Open5GS sends a Registration reject message.

registration_open5gs.pcapng.tar.gz

Both UERANSIM and Open5GS used the latest github source code. You can refer to https://github.com/open5gs/open5gs/issues/958 for more detailed.

Thank you so much for your great work! Sukchan

[aligungr]

Hi @acetcom

Thanks for reporting this, (I accidentally closed this issue :D)

I'll fix this soon Regards

[aligungr]

@acetcom

I've implemented protection of initial NAS messages. And temporarily pushed it to dev-initial_nas_protection branch.

For the very first registration (while UE does not have a NAS security context yet), everything seems nice and it works. However for Service Request and Mobility Updating Registration I had some error.

---

I performed some tests and detected some errors in 2 scenario. Perhaps we can find the issue together. These errors should be caused by either UERANSIM or Open5GS (or maybe both).

---

Scenario 1

1. Start the core network ./build/tests/app/5gc
2. Start the gNB ./nr-gnb -c ../config/open5gs-gnb.yaml
3. Start the UE sudo ./nr-ue -c ../config/open5gs-ue.yaml
4. Wait for registration and PDU session establishment to be successfully completed
5. Run ./nr-cli UERANSIM-gnb-901-70-1 -e "ue-release 1" to request from network to release NAS connection for the UE
6. AMF will send UE Context Release. Now wait for RRC connection to be released. Then UE switches to state CM-IDLE
7. Run ping -I uesimtun0 google.com to trigger an uplink data, now UE will send Service Request since it has no RRC connection
8. UE establishes RRC connection again and sends Service Request, but Open5gs says Error: Unknown message type (0x2f) or not implemented to this message. (Actually it's a part of MAC field in the security protected nas message contained in the NAS message container)

I'm attaching log and PCAP files. scenario1.zip

---

Scenario 2

1. Modify UERANSIM or Open5GS to send T3512 value in 5-10 seconds for example. (We'll try to send periodic registration for testing)
2. Then start core network, gNB, and UE again. Wait for registration and PDU session establishment to be successfully completed again. T3512 expires 5-10 seconds after, UE will send periodic registration. And it seems that, this time NAS message container does not cause an error like Scenario 1.
3. However this time AMF starts another authentication procedure. However it sends the same ngKSI value as before and the UE rejects the Authentication Request with cause "ngKSI already in use")

I'm also attaching log and PCAP files. scenario2.zip

---

I think the first case may be caused by the following: UE sends the NAS message container ciphered, but perhaps AMF expects it as plain NAS message. And for the seconds case, it may be even unrelated to NAS protection.

Regards Ali

[acetcom]

@aligungr

Regarding scenario-1, you used security header in NAS container.

I hope that you can find the difference between packet number 7(Security mode complete + Registration request) and number 17(Service Request + Service Request).

1. Packet number 7 Security mode complete (Security protected NAS 5GS message + Plain NAS 5GS message) + Registration request(Plain NAS 5GS message)
2. Packet number 17 Service Request (Security protected NAS 5GS message + Plain NAS 5GS message) + Service Request (Security protected NAS 5GS message + Plain NAS 5GS message)

You need to remove Security protected NAS 5GS message in NAS Container in Service Request.

Refer to the following TS24.501 standard.

9.11.3.33. NAS message container
The purpose of the NAS message container IE is to encapsulate a plain 5GS NAS REGISTRATION
REQUEST or SERVICE REQUEST message, or to encapsulate non-cleartext IEs of a CONTROL
PLANE SERVICE REQUEST message.

I'll review Senarios 2 soon.

Thanks a lot! Sukchan

[aligungr]

Thanks for the review @acetcom

I didn't fully understand the your last suggestion. Do you meaned,

• NAS container should be removed completely in Service Request message, or
• Container should be there, but its content should be unciphered (plain),

---

And the difference between packet 7 and 17 is; for Security Mode Complete, the container is unciphered, but for the Service Request the container is ciphered.

Actually UE intentionally behaves in this way. Because I think, NAS message container in Security Mode Complete should contain plain NAS message. However the NAS containers in Registration Request and Service Request (unlike Security Mode Complete) may or may not contain ciphered NAS message.

In other words, NAS message container IEs in the messages:

• Security Mode Complete: Always unciphered
• Registration/Service Request: If UE has a current NAS security context, then it is ciphered, otherwise unciphered

Perhaps I misunderstand the spec, but here some references:

From 24.501, 4.4.6

"If the UE has a valid 5G NAS security context .. the UE includes the entire REGISTRATION REQUEST or SERVICE REQUEST message .. in the NAS message container IE and shall cipher the value part of the NAS message container IE .. The UE shall then send a REGISTRATION REQUEST or SERVICE REQUEST message containing the cleartext IEs and the NAS message container IE"

And from 33.501, 6.46

"If the UE has a NAS security context, the message sent shall contain the information given above in cleartext and the complete initial NAS message ciphered in a NAS container which is ciphered. With a NAS security context, the sent message shall also be integrity protected"

It seems strange to me, and sometimes specs are really confusing

Regards

[acetcom]

@aligungr

Yes! I read that part too as you mentioned. However, I don't think it means that the NAS container should have a security header. Plain header is enough. It is not necessary because it has already ciphered in the upper NAS layer.

And also, I reviewed all the commercial UEs PCAP shared in the open5gs community, but there was no security header in NAS container regardless of registration request, service request, and security mode complete.

Although this is a little different story, the EPS NAS message container seems a little different.

TS24.501
8.2.6.16 EPS NAS message container
The UE operating in the single-registration mode shall include this information element 
if the UE performs mobility from S1 mode to N1 mode. The content of this message container is
the complete integrity protected TRACKING AREA UPATE REQUEST message,
using EPS security context.

Therefore, there is a security header in the EPS NAS message container. I've attached the related pcap shared by https://github.com/open5gs/open5gs/issues/937. issues937.tar.gz

BTW, scenario 2 is a bug in open5gs. I modified it and put it on the main branch.

Thank you so much for sharing this! Sukchan

[aligungr]

@acetcom

I had also noticed that other UEs such as Huawei send the container unciphered. Despite the confusion, I modified the UE and made the container unciphered as you said. And for the second scenario I tested with the latest source and it works.

And therefore we fixed all the problems so far.

Thanks for the collaboration. Regards

[acetcom]

@aligungr That sounds good to me. Thank you so much for your effort.

[stevenchiu30801]

Thanks for the great discussion! I had the same question and the spec really confused me.

From TS 24.501 clause 4.4.6 Protection of initial NAS signalling messages,

b)	If the UE has a valid 5G NAS security context and the UE needs to send non-cleartext IEs in 
a REGISTRATION REQUEST or SERVICE REQUEST message, the UE includes the entire REGISTRATION REQUEST or 
SERVICE REQUEST message (i.e. containing both cleartext IEs and non-cleartext IEs) in the NAS message 
container IE and shall cipher the value part of the NAS message container IE.

Also, in the same clause,

When the UE sends a REGISTRATION REQUEST or SERVICE REQUEST message that includes a NAS message 
container IE, the UE shall set the security header type of the initial NAS message to "integrity protected".

In my realization, when the UE has a valid security context and needs to send non-cleartext IEs, it shall include the non-cleartext IEs in the NAS message container IE and cipher it, and the upper NAS layer (Registration/Service Request message) shall only be integrity protected.

I agree with the idea that UE could simply protect the upper NAS layer with both ciphering and integrity. But I'm not familiar with this and maybe some security contexts required for deciphering is different from the current value.

I would really appreciate if you could clear my confusion or point out any my misunderstanding to the spec.

Regards

[stevenchiu30801]

Also, the spec conflicts with itself in TS 24.501 clause 9.11.3.33 NAS message container, mentioned in previous discussion, where NAS message container shall be "plain" NAS message.

The purpose of the NAS message container IE is to encapsulate a plain 5GS NAS message.

I would say it is fine if current UEs in use have the same implementation (plain NAS message container) and we are good to follow it. But I wonder if there is any consideration from point of 3GPP view and I suppose there is.

[nathalie21005]

Hi @aligungr ,

I was trying to implement scenario 1 but I did not get many commands in the UE, only the deregister. I am using UERANSIM with free5gc but I did not find the ue-release command, is there any work around to have this command?

Start the core network free5gc Start the gNB ./nr-gnb -c ../config/free5gc-gnb.yaml Start the UE sudo ./nr-ue -c ../config/free5gc-ue.yaml Wait for registration and PDU session establishment to be successfully completed Run ./nr-cli UERANSIM-gnb-208-93-1

Thank you

[aligungr]

@nathalie21005 Strange error. Which version are you using?

[nathalie21005]

Hi @aligungr, The version of the UERANSIM is v3.1.4 and the free5gc is from September 2021.

Thank you for your support.

[aligungr]

@nathalie21005 Could you please retry with the latest version? (v3.2.6)

[nathalie21005]

Thank @aligungr I can see the rest of the commands for the UE thanks for your help

[nathalie21005]

Hi @aligungr,

I got ps-event instead or ue is it correct?

Because I tried to execute ps-release with pdu session id, I got pdu session release but nothing related to RRC which the connection is still connected not idle to send a ping.

Thank you

[aligungr]

Hi @nathalie21005

Not really. There are indeed different.

"ue-release" command is executed by gNodeB, but not UE. So please look for gNodeB commands. You should see "ue-release" command there.

Best.

[nathalie21005]

Hi @aligungr thank you, it's working. I have another question about the UERANSIM. Can we use UERANSIM to simulate different UE activities like handover, roaming, sending sms, offloading a task, etc.? if not, if this something that will be added in the future?

Thank you again

[aligungr]

@nathalie21005

These features you mentioned are not present in the software, currently. And there is no plan to implement in the near future. (Because I could not allocate the necessary time)

BR

[Vineet112-tech]

@aligungr - Please lend your support to the request i.e - https://github.com/aligungr/UERANSIM/issues/586. I appreciate your kind assistance.

Thanks br//Vineet