The Chair commented that finishing 5G items was a priority for the meeting and anything else would be secondary.

Qualcomm commented that LS should be considered early since RAN groups and others were having their meetings during the same week.

Vodafone: LTKUP is not complete, it should continue in Rel-16. ORANGE replied that a conclusion had been approved already.This discussion was taken to the LTKUP agenda item.

 

V2X work item is 100% completed (the Work Plan shows 90%).

 

 

786 has a reply LS proposal. Commented in 920.

 

Qualcomm: The security parameter should be integrity protected and preferably confidentiality protected. If the signalling is in the NAS is not clear that the first is achieved.

Nokia: The limitation is at AS level, not at NAS level. Qualcomm replied that the parameters should be sent to the RAN in an integrity protected way.

Vodafone: this is the best way for a good bidding down protection.

 

 

Related to tdoc 861.

 

690, 767,769,727,691 and 768 are related to this LS.

 

Postponed since this affected Rel-16.

 

Ericsson: we have work based on GBA and we have also piggibacked some other work in SA2 work.

ORANGE: we don’t need to copy their requirements in our documents, just refer them.

Interdigital's concerns had already been taken into account.

 

Interdigital: solutions limited to the SA2 study? Or we can bring more?

OPPO: we depend on the architecture design of SA2.

Ericsson: SA2 may bring other solutions, but we will work on the final agreed solution in SA2. Qualcomm supported this. The objectives should be updated with this.

Sandvine supported this work item and pointed out that it would be very useful for operators.

IDEMIA: we don’t know if there's impact on the UICC.

Qualcomm: in SA2 the UICC is not impacted and we will follow their work.

Docomo objected to implying that SA3 would study any deep packet inspection, breaking encryption procedures.

T-Mobile supported this study.

The Chair commented that it could be an issue in the SA plenary to introduce supporting companies that don't come to SA3 and advised the Rapporteur to take this into account.

 

ORANGE found the objective very solution specific and didn’t understand the use cases.

Deutsche Telekom preferred to bring this back into the next meeting and wait for SA2's progress the following week and being aligned with them.

The Chair suggested the authors to refine this for the next meeting and have offline discussions with the companies who preferred to align with SA2 activity. For this reason the study was noted.

Ericsson: the first change is confusing.Whatever applies to a PDU session applies to all DRBs serving that PDU session.

Ericsson: this will be there in all SEPPs, it won't be optional.

Deutsche Telekom: SEPP to SEPP is always in a TLS tunnel.

There was a misunderstanding in what was existing, so the CR was finally not pursued.

 

Huawei: no need for additional messages to express the failure, the original response message can be used for that.

ORANGE didn't find the requirement clear.

Given that there was no understanding of this requirement it was noted.

 

DT, Docomo supported this document. China Mobile commented that they had done a similar exercise and agreed with the proposal. They commented that VoLTE traffic will grow more and more and it should be considered.

Ericsson commented that the scope could be enlarged: privacy enhancement for example.

Vodafone proposed to have a SID brought directly in to the plenary to speed up the work.They didn't think that such a study would not be agreable at this meeting.

Qualcomm, TIM, ORANGE: let's discuss the scope of this Work Item in SA3. They had concerns of having this SID being sent directly to SA Plenary.

The Chair commented that sending the SID directly to the plenary would bring the wrong message.

TIM wasn't in favour of sending the SID to SA directly either.

Vodafone commented that they would push for an LS to SA3 in SA plenary instead but they thought that no progress in two meetings was showing a bad image.

 

 

ORANGE: our SA5 delegate believes it's a bit premature to go for this security work. Wait for SA5 to finish their architecture before starting the work in SA3.

Huawei commented that was not the input they got from their delegates in SA5.

ORANGE: SA5 has no architecture for the management. We have no architecture to work on. I suggest to have this WID presented in August.

Huawei: what they have in their TS is sufficient.

Vodafone: does this include the ME and the UE? Huawei replied that they were not included and that they would clarify this in the WID description.

ORANGE: it's about OAM interfaces, not so much about the core network.

Ericsson: the info we get from our delegates is that the part that we need to secure, will be done in Rel-16.

Vodafone believed that this was obvious and it wasn't needed, as this could be considered as a VPN or TLS for securing it. Huawei agreed and commented that this could be written in the specification. Vodafone suggested to have a better argument in the justification.

ORANGE: let's wait for results from their meeting in June since TS 28.533 has hardly any content.They also commented that there was some risk that their work would be pushed to Rel-16.

BT: support of slices need support in the visited network as well. ORANGE didn't think this was part of SA5's work.

Vodafone: make it generic for external party and the operator.

The Chair suggested to follow closely what SA5 was doing and bring the WID together with the solutions in the SA3 August meeting for one step approval provided that their progress could allow it.

 

 

ORANGE commented that this didn’t add anything to the specification. No one seemed to see the use for this.

 

Ericsson pointed out that CT4 was working with this issue and that a reponse to the LS would be needed.

 

ORANGE: the secondary authentication credentials will stop the second UE from accessing the network with the USIM. SIM lock would also solve the issue.

Qualcomm: no requirements for the DN-AAA should be made here.

The Chair commented that IoT was not to be treated in Rel-15 as agreed for phase one.

Qualcomm: we have studied this use case for MTC and implemented it.

Interdigital: this logging is illegal in some countries.

 

 

ORANGE objected to this document.

BT supported this as long as the indications had a more proper security language.

ORANGE: the table is not correct and goes beyond the scope of slicing.

TIM didn’t support this contribution either.

This was finally noted since there was not much support for it.

 

ORANGE didn’t support having in the specification that the normative work should be done in the same release as the normative work in SA5.The last sentence should be removed.

They didn't support the second bullet either. It should state that the preferred solution is 1.1 for future normative work.

Ericsson supported not restricting the options for the normative work.

Both bullets were reworded in the revision.

 

 

ORANGE didn’t see the benefit of having an overview at all.

Ericsson: network slice as a service is an optional feature in the SA5 work, which is not implied here. The overview of key issues should be in the end of the document, not here.

ORANGE proposed to remove the entire clause 4 instead.

There was no support for this document, so it was noted.

 

ORANGE: TR 33.899 was never approved.

MCC: better refer to documents rather than working groups.

 

Huawei: This is limiting the available resources as decided by RAN.

ORANGE: not slice specific authentication but studying it feasibility of having it. Make it clear that this is not replacing primary authentication.

TIM: requirements from NGMN or we wait for requirements coming from SA1?

ORANGE: we need to see the use cases and requirements from SA1, study whether this is really needed. What are the service requirements leading us to do this study? See first what's being done in SA1.

Ericsson pointed out that there is work being done in SA2 and that could be the base for SA3's work.

 

BT: the last sentence in the solution details doesn' make much sense.

Vodafone: this is not new, it's what we can do now.

T-Mobile: CT1 has developed a solution for SoR and we need to develop the security for that sollution. This is part of that solution.

ORANGE: CT1 has proposals to change the solution during their current meeting. SA3-LI still has to reply to their LS so it's still an open solution.

ORANGE: we can work on the solution in the living document, but nothing for the TS until they have somethinf stable. Intel agreed to go for the living document.

Qualcomm: this is an existing solution, but CT1 is doing a control plane procedure that is missing from here.

 

ORANGE: remove the conclusion. Intel agreed to do this.

ORANGE: you propose another secure channel between UICC and UDM, so you need to maintain two secure channels.

Vodafone: this causes huge amounts of loading in UDM.

Qualcomm had multiple issues with the document. The solution was not complete for them.

Gemalto: it's a candidate solution that should be part of the document.

Vodafone: we agreed with CT1 not to use the auth mechanism and not to interact with the authenticate commands.

ORANGE: no need for a new requirement.

Huawei: we can make it a note.

Ericsson didn't agree with the addition in the requirement clause.

Ericsson: we see no security issues with the new key. No threat.

Qualcomm: no point with keeping the old keys.Samsung agreed.

Ericsson:The source generates a new key and gives it to the target. We are not breaking any security requirement.

This had to be taken offline.

 

Tdocs related: 860, 708,778,615.

 

NCSC: the rational doesn’t give a reason for this change.

IDEMIA didn’t agree with the reason for the change. It could be done with an applet.

Vodafone: CT6 created a new PDU function over the top incorrectly, by misunderstanding SA3 text in this spec. We need a file where we can use existing SIMs.

 

 

It was clarified that SBA security work for Rel-15 would finish by the end of the current meeting.

Ericsson queried on the timescales of this SID. Deutsche Telekom commented that work could continue in the next meetings given that this was a study item.

KPN was worried that the content of the living document wasn't proper for a TR. Clarification would require quite some time. The Chair commented that it could be decided later to drop the TR or refine it properly.

It was asked to be minuted that the TR wouldn't become a mere container for diverse solutions.

It was agreed to send it for information for SA#80.

 

 

On proposal 4,Vodafone: it would be useful to log and detect these received messages in order to find out who the sender was. After that the message is discarded.

DT wanted to have proposal 4 as a requirement in TS 33.501. Ericsson commented that SA3 needed to be more precise with the anti-spoofing mechanisms. ORANGE supported to have anti-spoofing protection mentioned in the specification.

Juniper: why not having it for a future SCAS for SEPP?

 

 

Overlapping with 752.

 

Qualcomm didn't agree with deleting the editor's note. It would affect the deregistration of UEs when there is a multiple connection.

Ericsson also had an issue with deleting the editor's note, but didn’t agree with Qualcomm's proposal. Qualcomm proposed to reword the editor's note to describe better the problem.

It was agreed to minute the description of the problem rather than adding another editor's note.

 

Juniper: policy per NF in 4.3.6.4? That would be complex. KPN agreed: One policy per NF service would be better.

Huawei didn’t agree with 4.3.6.6.  

Ericsson: we usually don’t specify failure cases or if we do, we need to specify what happens afterwards.

ORANGE: why does the UPF need to be notified?

Ericsson: to release resources, but this is not in our scope.

The last change was kept in 2038 which was merged in the CR in 2037.

 

Docomo: TLS 1.3 we cannot influence. We are not doing any traffic engineering for OAM interfaces (traffic prioritzation, for example).

The suggestions were endorsed, but it was decided not to send an LS to SA2.

 

 

Ericsson: it seems cumbersome. Better to use authenticated encryption all the time.

 

Ericsson,Nokia: it's not clarifying anything here.

Vodafone objected to having "shall" in here. This is a box that deconceals the SUPI. If using mobile encryption, the rest of the sentence is correct.

This was finally reworded in the revision.

 

Qualcomm didn’t agree with this CR.Authentication shouldn’t trigger the storage.

 

Two options to choose from in 753 and 783.

This was taken offline (although it seemed that most companies wanted 783).

Nokia and Huawei didn’t agree with step 12 of the figure. This was removed.

 

Huawei: MAC verified only by the HPLMN. If the routing info is changed this will be erroneous.

Qualcomm: this doesn’t bring any benefit.

 

 

Qualcomm: the figure displays too much and it's hard to read.

The content will be added to 996.

Ericsson agreed with the changes but suggested to make it more generic instead of adding the values here.

Some part willl go to 981 and some part will go to 982.

Ericsson: Partial cyphering mechanism. How important is this for Rel-15? Better to postpone it for Rel-16. In CT1 the partial cyphering mechanism will be treated in Rel-16.

Qualcomm: initial registration, I cannot use the upper parameters.

Nokia: better to introduce it earlier, Rel-15, and use it.

KPN and Deutsche Telekom supported Qualcomm.

This was finally noted.

 

 

 

Ericsson: we need to wait for CT1's reply to the LS before removing this Editor's note.

 

Related to tdoc 883.

 

Huawei: we need corrections in other places.

Where these needed to be corrected in other places was taken offline.

 

MCC commented that the note had normative language. The "needs to be" was reworded and the second sentence removed.

Ericsson: How does the UE know about the length?

Qualcomm: it's in the IE, as defined by CT1.

 

 

 

First change merged in 2042, Second change merged into tdoc 929.

 

Revised content is in S3-182004.

 

Ericsson: you may configure directly in the SEPP, not in another node.

Nokia, Docomo agreed with Ericsson.

 

There were several issues with the CR cover page that needed to be taken care of. The CR didn’t display the whole clause where the change was happening either.

DT: Validating the message itself and doing a cross check is different from what Huawei proposes.

 

ORANGE clarified that there is no reference to the ETSI SSP work, only this Editor's note.

Qualcomm wanted to be minuted that SSP should be added as a solution when it's ready from ETSI SCP and complies with the 33.501 security requirements.

ORANGE commented that this would come later in a proper CR that had to be discussed. They wanted to mention the release in the minutes.

Ericsson: SA plenary said that SSP is release independent.

ORANGE: it cannot be included in Rel-15 since it will be over in June.

Vodafone: it will be a new feature, it will require updates in CT6 specs and it will have to go to the next release for this reason.

There was disagreement whether to mention the Release in the minutes when deleting the editor's note, so the CR had to be taken offline.

Eventually the decision was to remove the editor's note and have minuted:

 

 

 

 

 

 

 

DT: it needs more details.

Ericsson: in the app layer solution we are introducing what Huawei wants.Nokia agreed.

Companies were fine with the requirement introduced in this CR.

 

KPN: the solution needs more work, it's a bit thin.

Juniper commented that the document needed some language check.

KPN: this is describing authenticated and integrity messages that need a standard to describe how they are dropped. I don’t agree with this.

Nokia didn’t support this either.

 

 

 

Juniper and ORANGE didn’t agree with the second issue:it would bring DoS attacks.

Docomo: an authorization failure wouldn't be a bad thing.

Nokia: if there's an error during service discovery, then it is out of our scope but in CT4's scope.

This was eventually noted.

 

NCSC: this is very normative and it is bringing assumptions we haven’t agreed on.

Qualcomm didn't find this needed at all. ORANGE supported Qualcomm.

Vodafone: not written in the same style as the other items in the same clause. It's all normative when the other clauses deal with coexistence.

The Chair commented that Huawei would need some offline explanations to the companies who didn’t support this contributed, hence this was noted.

 

 

China Mobile didn’t agree with having draft versions of RFCs being mandated here. The Chair clarified that SA3 usually works with draft RFCs and this is watched over as a normal 3GPP process.

ORANGE: this draft is pretty stable in IETF.

It was commented that this CR should not be implemented if the exception sheet for 33.501 was approved in the plenary. In case that the exception wasn't approved the CR could be brought later as cat-F.

817 was converted into a draftCR in 937. Its contents were agreed and moved there.

 

 

ORANGE: do we need a reply from CT4 only or also from SA2? Ericsson clarifed that CT4's response was enough.

Second requirement and Note stay.

 

MCC commented that it wasn't possible to change the title and content to something completely different. It was suggested to add it as a new sub-clause. Also, that it was better to mention "shall be done as in RFCxx" instead of "shall be implemented as in RFCxx".

 

ORANGE: bringing security gateways back? They didn’t agree with having this possiblity.

Huawei had some issues with this CR since it was giving some implementation proposals that had incomplete scenarios. They commented that requirements from other clauses were repeated here. All different deployment issues needed to be evaluated here.

Ericsson pointed out that protection in F1 needed to be finished this meeting.

 

TIM: what's the advantage here of adding this new option when it is said that Ipsec is better?

Ericsson: if IPSEC is used. It is optional to use it.

ORANGE: we may need to modify TS 33.210.

 

The Chair asked the room if companies thought that there was a need for an exception sheet:

ORANGE, KPN, Vodafone supported this.

Qualcomm: RAN groups will not complete dual connectivity until September so we may have to continue working on it.

The general feeling was that an exception sheet was needed in order to complete SBA. The Chair asked to be very precise with the reasons for having this exception agreed in the plenary. Everything else should be frozen and topics that need to be completed needed to be precised.

Nokia commented that SA3 didn’t know if dual connectivity work was needed so it was better not to mention it.

BT clarified that the late drop referred to ASN.1 and not to very late 5G features, so SA3 should not use this for the exception.

It was agreed to have an exception sheet only for the SBA topic.Ericsson pointed out that not all SBA was open so it should be detailed what issues in SBA security were needed.

The Chair asked if there was any understanding of issues in RAN that may impact SA3. Ericsson commented that dual connectivity was work in progress and that they could bring cat-F CRs to address this in SA3. The Chair commented that he would mention this issue in his report and that the SA Chair would mention it as well in TSG RAN.