authCtxId hardcoded as SUCI in the AMF

Q/A
#1

Hi,
I’m trying to integrate our product with free5gc to verify its correctness; it essentially replaces a few NFs in the core, including the AUSF, to perform authentication and authorization of UEs using standard enterprises IAM. Specifically, for 5G I’m using EAP-AKA’. However I’m hitting an issue where the free5gc AMF is ignoring the href provided by our “AUSF” as part of the UeAuthenticationCtx, and it is sending the POST request with the follow up eap-session payload to an URI which appears to be using the UE’s SUCI as the authCtxId. The line of code where this happens, if I decoded it correctly, should be this one. I would expect the authCtxId to be whatever the AUSF provided as part of the eap-session href, which - as far as I can tell from reading the standards - could be anything.

Is my interpretation correct? If so, can this be considered a bug? Naturally this has little importance for 99% of use cases, as presumably the built-in AUSF does the right thing, but if I am correct (and it is something for which you’d be willing to accept a PR) I could try to fix it, assuming it is not too complicated to do so.

Thanks in advace!

#2

Hi, @edipascale
I have reviewed the spec, and I believe we should indeed use the AuthCtxId provided in the AuthCtx by the AUSF for authentication. I will fix the issue later. Thank you very much!

#3

Related PR: https://github.com/free5gc/amf/pull/142

#4

Thanks @donald2000! I can confirm that your fix addresses the issue and I was able to progress with the authentication. However I’m currently facing another issue which I suspect might be in free5gc.

What happens is that the AMF contacts our UDM for a NUDM-SDM GET NSSAI which we handle, but the returned slice with an empty differentiator is rejected as not supported. I suspect that the AMF code looks for a perfect match with the ST/SDD pairs set in its config file; however my understanding of the standards is that an empty SDD is essentially a wildcard, i.e. any slice with the same ST should match it.
Here are the relevant AMF logs:

2024-09-16T10:27:23.465923034Z [INFO][AMF][Gmm][amf_ue_ngap_id:RU:3,AU:3(3GPP)][supi:SUPI:imsi-20893000000001] Handle InitialRegistration
2024-09-16T10:27:23.466882024Z [INFO][AMF][Gmm] RequestedNssai: &{Iei:47 Len:2 Buffer:[1 1]}
2024-09-16T10:27:23.466888468Z [INFO][AMF][Gmm][amf_ue_ngap_id:RU:3,AU:3(3GPP)][supi:SUPI:imsi-20893000000001] RequestedNssai - ServingSnssai: &{Sst:1 Sd:}, HomeSnssai: <nil>
2024-09-16T10:27:23.466892607Z [WARN][AMF][Gmm] RequestedNssai[{Sst:1 Sd:}] is not supported by AMF

Could you confirm if this is the case?
Thanks!

#5

Hi, @edipascale
I will check the specification and discuss it with others before giving you the result. However, for now, you can proceed with testing by setting the SDD as an empty value in the configuration. Thank you.

#6

After our discussion, we still believe that slices with an empty sd value and slices with a non-empty sd value should be considered as different slices.

#7

Alright, thanks for your quick reply! Your workaround allowed me to continue, in any case. I’m now having another issue on our side, where as part of the AMF-3GPP-Access-Registration we receive an empty RatType, which we do not like:

{"amfInstanceId":"cc5eb3b7-2f2c-4c29-a257-39f5ccdd77a0","imsVoPs":"HOMOGENEOUS_NON_SUPPORT","deregCallbackUri":"http://amf.free5gc.org:8000/namf-callback/v1/deregistration/imsi-20893000000001","initialRegistrationInd":true,"guami":{"plmnId":{"mcc":"208","mnc":"93"},"amfId":"cafe00"},"ratType":""}

I am double checking the standards to see if we’re wrong in our assumption, just bringing this up in case you want to check your side too.

By the way, I hope it is OK to keep reporting issues I’m facing, as a way to test interoperability with the standards - just want to reiterate that I don’t expect them to be solved at all or in any rush! If this is not considered useful or if I should report these in a different format please let me know.

Thanks,
E.

#8

You are more than welcome to continue reporting any issues you encounter, and we greatly appreciate your input. However, if the issues become unrelated to the original topic, we recommend starting a new thread. This will help us focus on each topic without mixing different discussions. Additionally, feel free to report any bugs directly on GitHub.

As for the RatType, according to TS 38413 9.2.6.1, it is supposed to be optional. If I’ve misunderstood, please let me know. Thank you again!

#9

understood, will open separate issues if I encounter any new one, thank you!

As for the RatType, I was referring to the field in the NUDM-UECM Amf3GppAccessRegistration, which according to TS 29.503 6.2.6.2.2 is mandatory. From the json above you can see that it is sent, but as an empty string, which our UDM rejects.

#10

I have already confirmed that in TS 29.503 6.2.6.2.2, RatType is indeed mandatory, and in TS 29.571, RatType is not allowed to be null. Additionally, I have found the following in TS 23.501:

For 3GPP access, the AMF determines the RAT type the UE is camping on based on the Global RAN Node IDs 
associated with the N2 interface and additionally the Tracking Area indicated by NG-RAN.

I suspect that we haven’t addressed this part. After I confirm it, I will discuss it with our team tomorrow. If it turns out to be an issue with AMF, I will work on fixing it.

1 Like