3GPP TSG-SA WG3 Meeting #95
`Reno (USA), 6-10 May 2019
`
`Source:
`Title:
`
`Document for:
`Agenda Item:
`
`S3-191204
`revision of S3-19xabc
`
`NEC
`KAUSF desynchronization problem and solutions – updated version after conf
`call on 25 Apr.
`Endorsement
`7.1.2
`
`Decision/action requested
`1
`This discussion tdoc reflects the outcome of conf call on 25th Apr and supersedes the original discussion tdoc in S3-
`191203. It is proposed to endorse the proposals of this discussion paper
`
`2
`[1]
`
`[2]
`
`[3]
`
`[4]
`
`[5]
`
`[6]
`
`[7]
`
`[8]
`
`[9]
`
`References
`3GPP TR 33.835 Study on Authentication and Key Management for Application based on 3GPP credentials
`in 5G
`
`S3-190640 Discussion on KAUSF synchronization
`
`3GPP TS 24.501 Non-Access-Stratum (NAS) protocol for 5G System (5GS)
`
`3GPP TS 33.501 Security architecture and procedures for 5G system (v15.4.0)
`
`S3-191205, CR 0564 (TS 33.501) "Aligning the storage timing of KAUSF in 5G AKA with EAP-AKA'"
`
`S3-191206, Draft CR (TS 33.501) "Synchronization of Kausf between AUSF and UE"
`
`S3-191208, Draft CR (TS 33.501) "UDM triggered authentication"
`
`S3-191209, Draft CR (TS 33.501) "Kausf key setting in EAP-AKA'"
`
`S3-191207, Draft CR (TS 33.501) "Using Key Identifiers between AUSF and UE for UPU and SoR"
`
`[10]
`
`S3-191203, "KAUSF desynchronization problem and solutions", (discussion tdoc discussed during the conf
`call on 25 Apr. 2019)
`
`Introduction
`3
`During SA3#94AH, S3-190640 [2] was presented and discussed. The goal of that paper was to raise awareness about
`the issue of lack of synchronization between the UE and the AUSF with respect to the KAUSF. The paper was presented
`for information purposes with the goal of coming back to this issue during the SA3#95 meeting.
`
`After SA3#94AH, a disscussion paper was shared over the email reflector with a more detailed analysis and a more
`concrete proposals. Based on comments received on that paper, a renewed version is presented here.
`
`The paper that was shared over the email reflector is uploaded as S3-191203 [10]. In addition, we have uploaded one
`CR to immediately fix an issue in 5G AKA. We also provided several draft CRs to show in more detail how a
`normative solution would look. These are provided for discussion purposes.
`
`4
`
`Detailed description
`
`4.1
`
`Comments received on S3-191203
`
`Association of the KAUSF with the NAS SMC
`4.1.1
`One comment received on S3-191203 was that the KAUSF has no association with the NAS SMC. Where the NAS SMC
`activates the security context, the activation of the KAUSF does not depend on NAS SMC procedures.
`
`APPLE 1013
`
`1
`
`

`

`This means that there is no ‘state’ of the KAUSF in relation to the security context that is in use. The storage and usage of
`KAUSF therefore only depends on whether the authentication has been successful.
`
`Association of the KAUSF with access type
`4.1.2
`As per the comment on the association with the NAS SMC, the same comment also implied that the KAUSF is not
`associated with the access type. In dual registration the UE only stores one KAUSF, which is the one resulting from the
`latest authentication. When deregistering from the access type, the UE does not delete the KAUSF.
`
`Conclusions
`4.1.3
`The conclusion that should be drawn from the comments is that there is only one KAUSF stored in the UE, which is the
`result of the latest authentication. The key is not associated with the state of the security context or the access type that
`is used and is also not deleted after the UE deregisters from a particular access.
`
`Requested actions from SA3
`4.1.4
`NEC kindly requests SA3 to take the following actions:
`Requested action 1: Confirm the conclusion for the UE;
`Requested action 2: Confirm that the same conclusion holds for the AUSF.
`
`If the above are confirmed, section 4.2 details the remaining KAUSF desynchronization scenarios.
`
`4.2
`
`Remaining KAUSF desynchronization scenarios
`
`4.2.1
`
`Handover from EPC
`
`Problem
`4.1.2.1
`A UE that gets handed over from EPC to 5GC can either use a previously established security context if it operates in
`dual registration mode or use a security context mapped from the EPC one in case it operates in single registration
`mode. In the second case, the UE nor the AUSF will have access to a KAUSF to run subsequent procedures with.
`This situation can only be resolved by running a new authentication, which is under control of the serving network. Said
`differently, how long this situation will continue to exist, depends on the serving network policy.
`
`Summary and solution direction
`4.1.2.1
`For the scenario where the UE operates in single registration mode and gets handed over from EPC. Four possible
`solutions are:
`
`1) Storing the a previous KAUSF at both the UE and the AUSF, even if the UE is conntected to EPC;
`2) Mandate that the AMF always performs authentication whenever the UE gets handed over from EPC and a
`mapped security context is used;
`
`3) Allow the home network to signal the need for an authentication to refresh KAUSF. Such would be a new message
`from the UDM to the AMF signalling that an authentication for a particular SUPI should be performed upon
`which the AMF initiates authentication; and
`
`4) The UDM waits with subsequent procedures until an authentication is performed.
`
`Of the above solutions, the 1) has impact on the UE and is therefore not be backwards compatible with a UE that is
`Release-15. Solution 2) requires changes to the serving network and may induce unnecessary signalling and
`authentication even if the home network does not need to use the KAUSF. Solution 3) introduces new signalling
`between the AMF and the KAUSF and is therefore not backwards compatible with Release-15 networks, but it is
`backwards compatible with release-15 UE. The advantage of this solution, contrary to solution 2) is that it does not
`introduce unnecessary authentications because it is only used if the Home network needs it. Also, if the serving network
`is release-15, the UDM will know by discovery and can delay further procedures until a new authentication is
`performed. Solution 4) confirms the status quo and offers no advantages over the current situation.
`
`Of these solutions, solution 3) is preferred because it solves the problem in a backwards compatible manner without UE
`impact.
`
`2
`
`

`

`Proposal 1: Accept solution 3) that introduces a new signalling message from the UDM to the AMF to trigger an
`authentication of the UE. The solution is proposed in a companion CR S3-191208 [7].
`
`4.2.2
`
`VPLMN Not completing the authentication procedure
`
`Introduction
`4.2.2.1
`The VPLMN can abort the authentication procedure at two points:
`
`1) Right after when the challenge is received from the home network;
`
`2) Right after when the response is received from the UE.
`
`The two options are depicted in the figure below. In what follows, both options and solutions for both options are
`discussed.
`
`
`
`Figure 1: Flow for aborting authentication procedure according showing two options
`
`Option 1
`4.2.2.2
`In this option, the VPLMN asks for an authentication vector, but never sends the challenge to the UE. The steps are as
`follows:
`
`1. The assumption is that the UE is roaming and that the UE is successfully authenticated and receiving service.
`
`2. As a result of the previous step, both the UE and the AUSF in the HPLMN store the KAUSF that resulted from the
`last authentication run.
`
`3. At some point in time, the AMF (VPLMN) decides to initiate a new authentication with the UE.
`
`4. The AMF sends an identity request to the UE (optional)
`
`5. The UE responds with its identity (SUCI) to the AMF (dependent on step 4)
`
`6. After receiving the UE’s identity, the AMF sends an authentication request
`(Nausf_UEAuthentication_Authenticate Request) to the AUSF in the HPLMN, which forwards it to the UDM in
`order to initiate the authentication.
`
`NOTE: For the following steps, the exact messages depend on whether 5G AKA or EAP AKA’ is used. Therefore
`only the generic names are provided.
`
`7. After reception of a 5G AV from the UDM, the AUSF sends the challenge to the AMF/SEAF in the VPLMN.
`5G AKA: The AUSF overwrites the KAUSF after which the UE and the AUSF have a different KAUSF. (See [4],
`clause 6.1.3.2.0, step 3).
`EAP AKA’: The AUSF does not yet overwrite the KAUSF, so no problem occurs in EAP AKA’.
`
`3
`
`

`

`Further steps are not described.
`
`This attack can be mitigated by delaying the derivation of the KAUSF in the AUSF which only leaves option 2 as an
`attack vector.
`Proposal 2: Delay the derivation of KAUSF in the AUSF until after the RES has been received. This has the advantage
`of mitigating the attack of option 1, but also resolves inconsistent behavior between 5G AKA and EAP AKA’. By
`aligning how the two work, a solution can be found irrespective of which authentication procedure is used. It is
`proposed to defer storing the key in the AUSF in the home network after the AUSF has received the authentication
`confirmation message from the serving network. This change is proposed in a companion CR in S3-191205 [5].
`
`
`
`Option 2
`4.2.2.3
`The second way a VPLMN can abort the authentication procedure is by not forwarding the RES to the home network.
`In what follows, the terms VPLMN and HPLMN are used to indicate the network elements AMF/SEAF (VPLMN) and
`AUSF/UDM (HPLMN). The attack is depicted in the the below figure and explained in the text that follows:
`
`
`
`Figure 2: Flow for aborting authentication procedure according to option 2
`According to the following steps:
`
`1-7: Refer to figure 1.
`
`8. The AMF/SEAF forward the challenge to the UE.
`
`9. The UE verifies the validity of the challenge and if successful, may calculate the RES, the KAUSF, KSEAF, and
`KAMF. The resulting situation follows depends on which authentication method was used:
`5G AKA: The UE overwrites the KAUSF. The UE now has a KAUSFs of which is the same as the one stored at the
`AUSF. (See [4], clause 6.1.3.2.0, step 3).
`EAP AKA’: According to TS 33.501 [4] clause 6.1.3.1, step 11, the UE overwrites the KAUSF at this point in
`time. That would result in the UE having a new KAUSF, which is different from the one that is stored in the
`HPLMN. (See TS 24.501 [3] clause 5.4.1.2.2.3 and TS 33.501 [4] clause 6.1.3.1 step 10). TS 24.501 [4]
`clause 5.4.1.2.2.3 and 5.4.1.2.2.8 on the contrary, also allows that the UE calculates the KAUSF at a later point,
`namely after receiving the EAP Success message. This behaviour is also captured in NOTE 6 in TS 33.501
`[4] clause 6.1.3.1. The UE behaviour is therefore rather uncertain.
`
`10. The UE returns the the RES to the AMF/SEAF in the VPLMN.
`
`11. The VPLMN / AMF does not forward the RES to the home network. As a result, the AUSF in the home network
`does not calculate KAUSF (see [4] clause 6.1.3.1 step 10) or expires the AV (see [4] clause 6.1.4.1 step 11).
`
`The resulting situation is depicted in the figure below.
`
`4
`
`

`

`
`Figure 3: Situation after aborting authentication procedure at the VPLMN. Note that in case of EAP-AKA’ the
`keys may be desynchronized. In case of 5G AKA, there is no problem in this scenario.
`The result of aborting the procedure at the VPLMN is that the UE, if EAP AKA’ is used, may be out of sync with the
`HPLMN depending on the implementation of EAP AKA’. The specification allows the procedure of EAP AKA’ to be
`left uncompleted (e.g. during AMF change) and also allows the derivation of the KAUSF to be postponed until after the
`EAP Success message.
`Proposal 2: (same as proposal 2 above): Delay the derivation of KAUSF in the AUSF until after the RES has been
`received. This has the advantage of mitigating the attack of option 1, but also makes 5G AKA and EAP AKA’ more
`consistent. This change is proposed in a companion CR in S3-191205 [5].
`
`Residual risk
`4.2.2.4
`By aligning the 5G AKA and EAP AKA’ behaviour the possible desynchronization if the authentication procedure is
`aborted remains. During some time window the UE and the HPLMN may remain unsynchronized because the
`authentication result is not provided to the home network.
`
`The consequence of not providing the success to the home network are the following:
`5G AKA: The UE has overwritten the KAUSF and has stored a non-current security context, which the serving
`network does not have (it didn’t receive the KSEAF because it didn’t send the authentication result to the home
`network). If the UE’s DM state changes to DM_DEREGISTERED, the UE will store the non-current security
`context and mark it as current, whereas the serving network will store the current security context. Therefore, a
`new authentication will be required whenever the UE’s state changes to DM_REGISTERED. However, it may
`take a long time before this state transition happens, which means that the desynchronized state may persist for a
`long time.
`EAP AKA’: The specification is rather unclear at which point in time the UE overwrites the KAUSF (see [4] clause
`6.1.3.1, step 11). The UE and home network could therefore have the same, but also a different KAUSF. In
`addition, the UE may have created a temporary security context, which will be deleted after some time-out. The
`exact value of the time out is not specified. It’s also not clear whether the UE will still calculate the KAUSF even if
`the EAP Success message never arrives. The state is therefore uncertain.
`Requested action 3: SA3 should decide whether the resulting possible desynchronization scenario should be solved.
`
`4.2.2.5
`
`Solutions
`
`Introduction
`4.2.2.5.1
`In order to overcome the problems in the previous paragraphs, the following solutions are proposed in several separate
`CRs (numbering continues from section 4.1):
`
`4) Storing multiple KAUSFs in the UE and the AUSF and handling the deletetion and activation similar to how
`security contexts are handled. This solution eliminates the problems, but comes with a system cost.
`
`5
`
`

`

`5) Adding a KAUSF key setting in Release-16 by using the AT_RESULT_IND and the AT_NOTIFICATION so that
`the UE and the AUSF can agree on the AUSF. This solution is backwards compatible.
`
`6) Including a key identifier in procedures that use KAUSF.
`These solutions can be considered independent of each other. Solution 4) is a redesign of how KAUSF is handled and
`tries to fix the issue in a generic way. Solution 5) only aims at fixing the unclarity in the EAP AKA’ behaviour and
`finally, solution 6) provides detection capability for out of sync scenarios.
`
`Improved KAUSF handling
`4.2.2.5.2
`This solution has the following components:
`
`- The UE is changed so that it stores any KAUSF associated with every security context it has, so for all non-current
`and current security contexts associated with 3GPP and non-3GPP accesses that the UE is registered to.
`
`- The AUSF mirrors the UEs behaviour and stores the KAUSFs associated with the latest two authentications per
`PLMN ID and Access Type.
`
`- The procedures involving KAUSF include an identifier to KAUSF that allows the UE and the AUSF to select the
`correct KAUSF from storage and apply this KAUSF in subsequent procedures.
`This solution effectively mitigates all of the descynchronization errors because multiple KAUSFs are available and the
`subsequent procedures include an identifier that allow the UE and the AUSF to select the corresponding KAUSF or detect
`the lack of the presence of a particular KAUSF.
`The drawback of such a solution is that it impacts the UE, the AUSF, and the signalling for SoR and UPU. The exact
`impact depends on whether SA3 confirms that the UE and AUSF behaviour is as specified in clause 4.1. Whether and
`how backwards compatibility with Release-15 UE and AUSF can be achieved is to be studied.
`Proposal 3: This proposal is captured in draft CR S3-191206 [6]. SA3 is kindly requested to discuss this CR and
`consider the system impacts.
`
`Fixing EAP AKA’ and KAUSF setting in Release 16
`4.2.2.5.3
`EAP AKA’ has an optional setting which can be used to indicate whether a protected success code is required. In order
`to do so, the AUSF can set the AT_RESULT_IND in the authentication request. If the UE receives this and supports
`protected success message, it can also set the AT_RESULT_IND in the reply. If the AUSF receives the
`AT_RESULT_IND, it will have to send a AT_NOTIFICATION message with the result of the authentication (success,
`reject, etc.). Upon reception of the AT_NOTIFICATION, the UE will respond with a AT_NOTIFICATION as well
`which indicates to the AUSF that the UE has received the AT_NOTIFICATION. If everything was successful, the
`AUSF can now send the EAP_Success message.
`
`In Release-15, the support of the AT_RESULT_IND is optional as it is in RFC 4186 and if it is supported, there is no
`particular action that the UE will do after receving the AT_NOTIFICATION message. As such, performing the
`AT_NOTIFICATION procedure between a Release 15 and Release 15 UE has no adverse effect.
`
`
`Figure 4: EAP-AKA’ when using the AT_RESULT_IND (AT_RES) and AT_NOTIFICATION in the procedure
`
`6
`
`

`

`In detail, this solution would work as follows (conforming to figure 4):
`
`1) The SN sends an authentication request message to the AUSF
`
`2) The AUSF in the HN responds with an EAP message including the authentication challenge and sets the
`AT_RESULT_IND (indicated by AT_RES in the figure) in this message.
`
`3) The SEAF/AMF forwards the EAP message to the UE
`
`4) The UE will after verifying the AUTN and calculating the RES respond with the RES in an EAP message. In
`this EAP message it will set the AT_RESULT_IND (indicated by AT_RES in the figure) if it supports the
`AT_NOTIFICATION procedure. Now the UE will wait for the AT_NOTIFICATION message before
`calculating the KAUSF.
`
`5) The EAP message is forwarded by the SEAF/AMF to the AUSF
`
`6) The AUSF checks for the AT_RESULT_IND and if set, will respond with a AT_NOTIFICATION message
`signalling to the UE the result of the authentication. At this point in time, the KAUSF could also be calculated if
`the result was successful.
`
`7) The SEAF/AMF transparently forwards the EAP message from the AUSF to the UE.
`
`8) After receiving the AT_NOTIFICATION message, the UE will calculate the KAUSF (if the authentication was
`successful) and overwrite any existing KAUSF.
`
`9) The UE will respond with an AT_NOTIFICATION message.
`
`10) The SEAF/AMF transparently forwards the EAP message from the UE to the AUSF.
`
`11) The AUSF will receive the AT_NOTIFICATION message that confirms that the UE has calculated the KAUSF.
`And the the AUSF stores the KAUSF.
`
`12) The AUSF will respond with an EAP Success message to the SEAF/AMF which may or may not forward the
`message to the UE.
`
`Note that it is for futher study whether the KAUSF should be stored after step 6 or at step 11.
`The setting of the AT_RESULT_IND can also be made optional depending on:
`
`-
`
`In the AUSF, it could be set only if the AUSF needs the KAUSF for subsequent procedures. If the AUSF doesn’t
`store the KAUSF, it can choose not to set the bit.
`- Also, the UE could not set it in response to receiving one if it does not support storing of the KAUSF. Similarly, if
`the UE doesn’t receive the bit, it can opt not to store KAUSF.
`
`The advantage of this solution is that it provides confirmation between a Release-16 UE and a Release 16 AUSF that
`the KAUSF can be used. In case of a Release-15 UE and a Release-16 AUSF, the Release-15 UE behaviour remains
`undefined, however, it does not break the protocol or require updates. In case of a Release-16 UE and a Release-15
`AUSF, it’s up to the implementation and the operator whether AT_RESULT_IND is used. If used, the Release-16 UE
`will treat it as a Release-16 AUSF and will store the KAUSF. If not used, nothing changes.
`Proposal 4: Accept this solution for Release-16. It removes the undefined behaviour of the UE and allows for explicit
`key setting of the KAUSF without breaking Release-15. This change is captured in S3-191209 [8].
`
`Using a key identifier in subsequent procedures
`4.2.2.5.4
`As part of the original NEC proposal, the use of key identifiers in subsequent procedures that rely on KAUSF was
`discussed. The advantage of such a solution where the key identifiers are added to the SoR and UPU procedures is that
`it allows for detection of a key that went out of sync. The disadvantage of this solution is that it requires changes in the
`container that is sent from the AUSF to the UE. It’s currently not clear whether such changes can be made in a
`backwards compatible way. Because it involves changes outside the scope of SA3, it is proposed that an LS is sent to
`CT1 with the question whether such a change is possible without impacting Release-15 UEs that receive a Release-16
`UPU or SoR.
`
`In order to clarify how NEC sees the solution, a draft CR is provided. It is adviced to attach the draft CR in the LS to
`CT1 to clarify our intensions.
`Proposal 5: Send an LS to CT1 with the question on whether such a change is possible in a backwards compatible
`manner. The change itself is captured in draft CR S3-191207 [9].
`
`7
`
`

`

`Conclusion
`4.3
`In this contribution, we discussed a number of KAUSF desynchronization scenarios and mitigating measures.
`
`Concrete Proposal
`5
`The concrete proposals are as follows:
`
`1) Introduce new signalling that allows the UDM in the home network to trigger an authentication between the
`AMF and the UE. This proposal is captured in a CR in S3-191208 [7].
`
`2) Change TS 33.501 [4] text on 5G AKA such that the KAUSF is only stored at the AUSF in the home network after
`the authentication confirmation from the UE has been received. Concretely this involves moving the sentence
`about storing the KAUSF from step 3 to step 11 in 5G AKA. This proposal is captured in a CR in S3-191205 [5]
`
`3) Improve the KAUSF handling in the AUSF and the UE by keeping state of the KAUSF and introducing key
`identifiers in all related signalling. This change is captured in CR S3-191206 [6].
`
`4) Introduce the usage of AT_RESULT_IND in EAP-AKA’ so that the home network and the UE can set the
`KAUSF using this method. This is captured in CR S3-191209 [8].
`
`5) Require that a key identifier is added to procedures that involve KAUSF so that key refresh can be detected. This is
`captured in S3-191207 [9].
`
`8
`
`