SA3 kindly asks CT1 to specify the functional change corresponding to S3-110526, S3-110527 and S3-110528 in TS 24.301 for Rel-8, Rel-9 and Rel-10.
C1-111659
LS on Maximum number of IKEv2 security associations (S3-110531)
SA3
To
Reply LS in C1-111967
=============== extract from LS ==========
At SA3 #63 a contribution was presented which proposed to remove the limit of maximum number of IKEv2 SAs per APN from one UE in case of tunnel authentication in TS 33.234 (I-WLAN) and TS 33.402 (Non-3GPP access to EPC), see attached S3-110480. The reason for removing the limit is that the underlying fraud case, where a USIM/UICC is re-used by several devices in WLAN UE split scenario in order to access 3GPP network, is no longer considered to be practically valid. This is because the limit can be circumvented by a modern mobile phone (or e.g. laptop) which can act as NAT and WLAN AP and thereby offer its PDN connection to be used by other devices connected to it.
Due to the above reasons it was discussed in SA3 to remove the limit from their specifications. However, it was commented in the meeting that there can be other than security reasons, e.g. load controlling, for limiting the maximum number of IKEv2 SAs from one UE. Therefore SA3 would like to ask advice from SA2 and CT1 on the following questions:
Whether there is a limit for maximum number of IKEv2 SAs from one UE per APN (or W-APN in case of I-WLAN) for non-security reasons? Especially is there such limit per (e)PDG?
Whether there is a limit for maximum number of IKEv2 SAs from one UE to different APNs (or W-APN in case of I-WLAN) for non-security reasons?
Whether such limit(s) should be specified in 3GPP specifications, e.g. in SA2 specifications, or if they are left out of standardization?
The relation of IKEv2 SAs and PDN connections was also discussed. The current SA2 TS 23.402 gives the understanding that in case of multiple PDN connections from a UE to the same APN, an IKEv2 SA is established for each PDN connection for that APN. In SA3 view this is not needed for security reasons since one IKEv2 SA per APN would be enough and IPsec child SAs could be created for the PDN connections. It was also commented in the meeting that QoS differentiation could be provided also with IPsec child SAs.
Therefore SA3 would like to ask SA2 and CT1:
Is the understanding correct that in case of multiple PDN connections from a UE to the same APN, an IKEv2 SA is established for each PDN connection? Does this also apply toW-APN in case of I-WLAN?
If this is the case, what are the reasons for establishing an IKEv2 SA for each PDN connection?
C1-111660
LS on Security context mismatch in UMTS and GSM (S3-110544)
SA3
To
Reply LS in C1-111972
========== extract from LS ============
There are many cases in UTRAN and GERAN where there may be a mismatch between the UE and the network w.r.t. the keys used for integrity protection (when applicable) and ciphering. For example, assume the UE runs a Location Area Update procedure that includes an AKA and a TMSI re-allocation procedure and where there is a change of MSCs. If the connection between the UE and the network breaks between the successful AKA procedure and the TMSI re-allocation procedure, the keys stored on the SIM or USIM will differ from the keys stored in the network. Similarly, in case an SRVCC handover fails after the handover-complete sent from the target BSS/RNS to the target MSC, but before the TMSI re-allocation procedure, there will be different keys stored in the USIM or SIM and compared to what is stored in the network. There are similar cases in the pure packet switched domain.
A result of such mismatch is that for UTRAN, the security mode control procedure will fail since the UE will discard the security mode command (and retransmissions thereof) sent by the network due to failing MAC-I. In GERAN, there is no integrity protection, so the security mode command will be accepted by the UE. However, the security mode complete response from the UE to the network will be ciphered using the incorrect key, so the network will not be able to decrypt it correctly. In either case, a mismatch of keys will cause abnormal conditions for the security mode control procedure. Mismatches will possibly also create problems in other situations.
SA3 assumes that the stage 3 specifications provide sufficient detail to be able to implement a way to recover from abnormal situations like these. However, SA3 would like to request clarification on the following:
