Etsi stylesheet (V 0)

7.3 Mission Critical Security Enhancements (eMCSec) (Rel-15)

S3-180038 LS on Removal of 'over LTE' limitation from Mission Critical Specifications

Type: LS in For: (not specified)
Original outgoing LS: -, to -, cc -
Source: S1- 174542

Decision: The document was noted.



S3-180043 LS on end-to-end encryption for mission critical communications between LMR users and 3GPP MC users

Type: LS in For: (not specified)
Original outgoing LS: -, to -, cc -
Source: S6-171838

Decision: The document was noted.



S3-180332 [eMCSEC] Adding Integrity Key for KMS communications

Type: CR For: Agreement
33.180 v15.0.0 CR0051 Cat: B (Rel-15)
Source: NCSC

Decision: The document was agreed.



S3-180160 [eMCSec] 33180 R15 Interworking SeGy clarification

Type: CR For: Agreement
33.180 v15.0.0 CR0048 Cat: F (Rel-15)
Source: Motorola Solutions UK Ltd.

Abstract:

Clarify SeGy functionality when used in an IWF.

Decision: The document was revised to S3-180386.



S3-180386 [eMCSec] 33180 R15 Interworking SeGy clarification

Type: CR For: Agreement
33.180 v15.0.0 CR0048 rev 1 Cat: F (Rel-15)
Source: Motorola Solutions UK Ltd.

(Replaces S3-180160)

Decision: The document was agreed.



S3-180153 [eMCSec] 33180 R15 IWF security

Type: CR For: Agreement
33.180 v15.0.0 CR0044 Cat: F (Rel-15)
Source: Motorola Solutions UK Ltd.

Abstract:

Add security for IWF-1, IWF-2 and IWF-3 interfaces.

Decision: The document was merged.



S3-180229 Document showing the changes to SeGy functionality

Type: discussion For: Discussion
Source: NCSC

Decision: The document was noted.



S3-180228 [eMCSEC] Security Gateway clause update and move to annex

Type: CR For: Agreement
33.180 v15.0.0 CR0050 Cat: B (Rel-15)
Source: NCSC

Decision: The document was merged.



S3-180226 [eMCSEC] Notifying the use of Security Gateways

Type: CR For: Agreement
33.180 v15.0.0 CR0049 Cat: B (Rel-15)
Source: NCSC

Decision: The document was agreed.



S3-180227 [eMCSEC] LS to SA6 on Security Gateway notification

Type: LS out For: Approval
to SA6
Source: NCSC

Decision: The document was revised to S3-180387.



S3-180387 [eMCSEC] LS to SA6 on Security Gateway notification

Type: LS out For: Approval
to SA6
Source: NCSC

(Replaces S3-180227)

Decision: The document was approved.



S3-180156 [eMCSec] 33.180 R15 Interworking media and signaling

Type: CR For: Agreement
33.180 v15.0.0 CR0045 Cat: F (Rel-15)
Source: Motorola Solutions UK Ltd.

Abstract:

Add interworking media and signaling protection for MCPTT and MCData.

Decision: The document was revised to S3-180376.



S3-180376 [eMCSec] 33.180 R15 Interworking media and signaling

Type: CR For: Agreement
33.180 v15.0.0 CR0045 rev 1 Cat: F (Rel-15)
Source: Motorola Solutions UK Ltd.

(Replaces S3-180156)

Decision: The document was agreed.



S3-180158 [eMCSec] 33180 R15 Interworking key mgmt (InterSD)

Type: CR For: Agreement
33.180 v15.0.0 CR0046 Cat: F (Rel-15)
Source: Motorola Solutions UK Ltd.

Abstract:

Add the InterSD agreed method for interworking end-to-end key management.

Decision: The document was revised to S3-180413.



S3-180413 [eMCSec] 33180 R15 Interworking key mgmt (InterSD)

Type: CR For: Agreement
33.180 v15.0.0 CR0046 rev 1 Cat: F (Rel-15)
Source: Motorola Solutions UK Ltd.

(Replaces S3-180158)

Decision: The document was agreed.



S3-180159 [eMCSec] 33180 R15 Interworking key mgmt (MCData)

Type: CR For: Agreement
33.180 v15.0.0 CR0047 Cat: F (Rel-15)
Source: Motorola Solutions UK Ltd.

Abstract:

Add the MCData agreed method for interworking end-to-end key management.

Decision: The document was withdrawn.



S3-180163 New WID for MONASTERY security

Type: WID new For: Agreement
Source: Motorola Solutions UK Ltd.

Abstract:

WID to add mission critical security for MONASTERY features.

Discussion:

It was commented whether it was possible to add a new objective in the existing WID instead of a new WID.

MCC commented that for tracking-in-3GPP purposes and given that it was a new topic, it was better to have a separate WID.

It was pointed out that this was a Rel-15 WID, so the work would be brought for the next Bis meeting as well.

Decision: The document was revised to S3-180385.



S3-180385 New WID for MONASTERY security

Type: WID new For: Agreement
Source: Motorola Solutions UK Ltd.

(Replaces S3-180163)

Decision: The document was agreed.



S3-180427 Changes to TS 33.180 from SA3#90

Type: other For: Information
Source: NCSC

Decision: The document was noted.

7.4 Northbound APIs Security for SCEF - SCS/AS Interworking (NAPS_Sec) (Rel-15)

S3-180157 Authorization of SCS/AS to send requests for the 3GPP Network Entity

Type: CR For: Approval
33.187 v14.1.0 CR0011 Cat: B (Rel-15)
Source: Huawei, Hisilicon

Discussion:

ORANGE: we cannot adapt to all types of third party networks. You are proposing an authorization mechanism here, not a security procedure.

ORANGE wasn't convinced why it is for multiple authorization mechanisms. Keep only the first sentence. We need an authorization mechanism, but which one is not clear.

It was clarified that this was a contribution to the draft CR from the previous meeting, so the type had to be changed to "other".

It was asked to be minuted that OATH is a good candidate for this.

There was no consensus on this so Huawei decided not to pursue this.

Decision: The document was not pursued.



S3-180459 Exception Sheet NAPS-Sec

Type: WI exception request For: Agreement
Source: Huawei

Decision: The document was withdrawn.

7.5 Security Aspects of Common API Framework for 3GPP Northbound APIs (CAPIF_Sec) (Rel-15)

S3-180207 Scope of CAPIF security

Type: pCR For: Approval
33.122 v0.0.0 Source: Huawei, Hisilicon, China Mobile

(Replaces S3-180142)

Discussion:

NEC commented that the scope here was too short and needed more wording.

The Vice Chair proposed to accept this and bring more proposals for the next meeting.

Decision: The document was approved.



S3-180307 CAPIF Security requirements

Type: pCR For: Approval
33.122 v0.0.0 Source: Samsung, Motorola Solutions

Decision: The document was revised to S3-180392.



S3-180392 CAPIF Security requirements

Type: pCR For: Approval
33.122 v0.0.0 Source: Samsung, Motorola Solutions,China Unico,Huawei,China Mobile, HiSilicon

(Replaces S3-180307)

Decision: The document was approved.



S3-180224 Security requirements on the CAPIF-4 reference point

Type: pCR For: Approval
33.122 v0.0.0 Source: China Mobile, Huawei

Decision: The document was merged.



S3-180191 Key issue on topology hiding of the service

Type: pCR For: (not specified)
33.122 v0.0.0 Source: China Unicom, China Mobile

Decision: The document was merged.



S3-180192 ey issue on secure communication between functions in CAPIF

Type: pCR For: (not specified)
33.122 v0.0.0 Source: China Unicom, China Mobile

Decision: The document was merged.



S3-180144 Additional security requirements for 3rd party API provider

Type: pCR For: Approval
33.122 v0.0.0 Source: Huawei, Hisilicon

Decision: The document was merged.



S3-180208 Security requirements on CAPIF entities

Type: pCR For: Approval
33.122 v0.0.0 Source: Huawei, Hisilicon, China Mobile

(Replaces S3-180143)

Decision: The document was merged.



S3-180309 Security procedure for CAPIF-1e reference point

Type: pCR For: Approval
33.122 v0.0.0 Source: Samsung

Decision: The document was approved.



S3-180312 Security Procedure for CAPIF-2e reference point

Type: pCR For: Agreement
33.122 v0.0.0 Source: Samsung

Discussion:

NEC: it is strange that there are three methods here, which seems like three options.

It was clarified that method one and two are authentication and method three is authorization/authentication.

BT: how is the method chosen/ negotiated in the fly?

Samsung: this is determined in 392.

Nokia: method three is fine but the others need some more refinement.

Huawei wasn't convinced with the authorization mechanisms for method one and two, so an editor's note was added to address this.

Decision: The document was revised to S3-180403.



S3-180403 Security Procedure for CAPIF-2e reference point

Type: pCR For: Agreement
33.122 v0.0.0 Source: Samsung

(Replaces S3-180312)

Decision: The document was approved.



S3-180314 CAPIF security within PLMN Trust Domain

Type: pCR For: Approval
33.122 v0.0.0 Source: Samsung

Discussion:

NEC: this is in a solution section and we have two requirements.

Huawei: the second line is too broad, you cannot mention that the whole TS 33.310 applies; refer to the right clause.

China commented that the first sentence wasn't clear enough and needed to be more specific about what exactly is being taken from TS 33.310. MCC agreed with this.

Decision: The document was revised to S3-180404.



S3-180404 CAPIF security within PLMN Trust Domain

Type: pCR For: Approval
33.122 v0.0.0 Source: Samsung

(Replaces S3-180314)

Decision: The document was approved.



S3-180142 Scope of CAPIF security

Type: pCR For: Approval
33.122 v0.0.0 Source: Huawei, Hisilicon

Decision: The document was revised to S3-180207.



S3-180143 Security requirements on CAPIF entities

Type: pCR For: Approval
33.122 v0.0.0 Source: Huawei, Hisilicon

Decision: The document was revised to S3-180208.



S3-180401 Draft TS 33.122

Type: draft TS For: Approval
33.122 v0.1.0 Source: Samsung

Decision: The document was approved.

7.6 Other work areas

7.6.1 SAE/LTE Security

S3-180245 Discussion on completing the LTE bidding down procedures

Type: discussion For: Discussion
Source: Qualcomm Incorporated

Decision: The document was noted.

7.6.2 IP Multimedia Subsystem (IMS) Security

S3-180325 Clarification for TCP connection reuse

Type: CR For: Agreement
33.203 v15.0.0 CR0249 Cat: F (Rel-15)
Source: Ericsson Limited

Decision: The document was revised to S3-180417.



S3-180417 Clarification for TCP connection reuse

Type: CR For: Agreement
33.203 v15.0.0 CR0249 rev 1 Cat: F (Rel-15)
Source: Ericsson Limited

(Replaces S3-180325)

Decision: The document was agreed.

7.6.3 Network Domain Security (NDS)

S3-180262 Clarification need of CMPv2 in TS 33.310

Type: discussion For: Endorsement
33.310 v.. Source: Ericsson

Discussion:

It was agreed to treat this in the Bis meeting in San Diego.

It was commented that it was needed to go back up to Rel-10.

Decision: The document was noted.

7.6.4 UTRAN Network Access Security

7.6.5 GERAN Network Access Security

7.6.6 Generic Authentication Architecture (GAA)

7.6.7 Multimedia Broadcast/Multicast Service (MBMS)

7.6.8 Security Aspects of Home(e)NodeB (H(e)NB)

7.6.9 Security Aspects related to Machine-Type Communication ((e)MTC)

S3-180029 Collection of clarifications and editorial changes to BEST TS 33.163

Type: CR For: Approval
33.163 v15.2.0 CR0003 Cat: F (Rel-15)
Source: Deutsche Telekom AG

Abstract:

Upon careful reading and reviews of the BEST TS, several problems and inconsistencies were discovered. The changes in this document attempt to fix them.

Discussion:

BEST is not part of the agenda of this meeting.

Decision: The document was postponed.

7.6.10 Security Aspects of Isolated E-UTRAN Operation for Public Safety (IOPS)

7.6.11 Security of MCPTT (MCPTT)

7.6.12 Security for Enhancements to Proximity-based Services - Extensions (eProSe-Ext-SA3)

7.6.13 Enhanced Access Security for Extended Coverage GSM in relation to Cellular IoT (EASE_EC_GSM)

7.6.14 New GPRS algorithms for EASE (EASE_ALGOs_SA3)

7.6.15 Support of EAP Re-Authentication Protocol for WLAN Interworking (ERP)

7.6.16 Security Assurance Specifications (SCAS-SA3, SCAS_PGW, SCAS_eNB)

S3-180088 Collection of changes based on feedback from GSMA SECAG - CR to 33.117v1 Rel.14

Type: CR For: Agreement
33.117 v14.2.0 CR0004 Cat: F (Rel-14)
Source: Nokia

Discussion:

MCC commented that normative language cannot be used in Notes ("shall", "should"), which are just informative in nature and cannot be used for requirements and recommendations.

The content was fine but the distinction of normative/recommendation and informative text had to be worked offline.

The editor's note was removed and added to the report as action item:

"It is FFS on how details should be added to the SCAS to indicate whether requirements and associated test cases are applicable to all units or boards within a Network Product."

ACTION: It is FFS on how details should be added to the SCAS to indicate whether requirements and associated test cases are applicable to all units or boards within a Network Product.
(action on: Nokia / due by: 2018-04-14)

Decision: The document was revised to S3-180419.



S3-180419 Collection of changes based on feedback from GSMA SECAG - CR to 33.117v1 Rel.14

Type: CR For: Agreement
33.117 v14.2.0 CR0004 rev 1 Cat: F (Rel-14)
Source: Nokia

(Replaces S3-180088)

Decision: The document was agreed.



S3-180089 Collection of changes based on feedback from GSMA SECAG - CR to 33.117v1 Rel.15

Type: CR For: Agreement
33.117 v14.2.0 CR0005 Cat: A (Rel-15)
Source: Nokia

Discussion:

MCC pointed out that this CR wasn't necessary since the latest version of the spec is in Rel-14.

Decision: The document was not pursued.



S3-180090 Collection of changes based on feedback from GSMA SECAG - CR to 33.916v1 Rel.14

Type: CR For: Agreement
33.916 v14.2.0 CR0004 Cat: F (Rel-14)
Source: Nokia

Decision: The document was revised to S3-180420.



S3-180420 Collection of changes based on feedback from GSMA SECAG - CR to 33.916v1 Rel.14

Type: CR For: Agreement
33.916 v14.2.0 CR0004 rev 1 Cat: F (Rel-14)
Source: Nokia

(Replaces S3-180090)

Decision: The document was agreed.



S3-180091 Collection of changes based on feedback from GSMA SECAG - CR to 33.916v1 Rel.15

Type: CR For: Agreement
33.916 v14.2.0 CR0005 Cat: A (Rel-15)
Source: Nokia

Decision: The document was not pursued.



S3-180345 NESAS Pilot Findings and Recommendations to SA3

Type: LS in For: Information
Original outgoing LS: -, to -, cc -
Source: GSMA SECAG

Decision: The document was replied to in S3-180418.



S3-180418 Reply to: NESAS Pilot Findings and Recommendations to SA3

Type: LS out For: approval
to GSMA SECAG
Source: Nokia

Decision: The document was approved.

7.6.17 Security aspect of architecture enhancements for LTE support of V2X services (V2XLTE-Sec)

7.6.18 Security of the Mission Critical Service (MCSec)

S3-180315 LS to CT1 on Protected Payload message type

Type: LS out For: Approval
to CT1
Source: NCSC

Decision: The document was revised to S3-180388.



S3-180388 LS to CT1 on Protected Payload message type

Type: LS out For: Approval
to CT1
Source: NCSC

(Replaces S3-180315)

Decision: The document was approved.

7.6.19 Other work items

7.7 New Work Item proposals

S3-180222 New WID on GBA enhancements for Internet of Things

Type: WID new For: Agreement
Source: China Mobile, CATR, China Unicom

Discussion:

Ericsson: it should be a study first and wider in scope, considering discussions in IETF.

Qualcomm: in the objectives, which protocols other than HTTP?

The Chair commented that the overall opinion seemed that the work should start with a study item first.

ORANGE: include 5G in the scope, e.g. SSO in 5G.

Nokia: there is no time to have a new study item given the workload with 5G.

Vodafone expressed their concerns on study items taking out time for 5G items.

BT suggested to handle every normative item in 5G as a priority before heading for study item work.

The Chair pointed out that prioritization will serve that purpose and that contributions can be always accepted as a 3GPP working procedure.

Gemalto: some study items are essential for future normative work,

ORANGE: this should be decided each meeting, not as a general rule.

The Chair decided to use prioritization in the next meetings. Vodafone wanted their objection recorded if this issue was commented in SA plenary; they preferred to have study items delayed until August.

Ericsson asked to delay this study item for the next meeting in order to have internal discussions about it. There may be several studies in here.

There was no agreement and the document was noted and expected to come back for the meeting SA3#91.

Decision: The document was noted.



S3-180381 New SID on GBA enhancements

Type: SID new For: Agreement
Source: China Mobile, CATR, China Unicom

Decision: The document was withdrawn.



S3-180335 New WID for 5G SCAS

Type: WID new For: Agreement
Source: Huawei, Hisilicon,Ericsson

(Replaces S3-180334)

Discussion:

BT: HSS/UDM is a critical element and it should be considered as well.

DT:Consider SBA as well?

China Mobile: we have concerns about the network functions, they could be virtualised. Study the virtualisation of network functions first.

Huawei commented that the work item should focus on the physical elements and focus on the virtualised aspects in a study item.

NTT-Docomo supported the first two objectives.

Alex (BT): assume that the network will be partly virtualised at least even in early stages.

Nokia preferred a study item, but the consensus was to make it as a work item.

Decision: The document was revised to S3-180383.



S3-180383 New WID for 5G SCAS

Type: WID new For: Agreement
Source: Huawei, Hisilicon,Ericsson

(Replaces S3-180335)

Discussion:

Vodafone commented that there isn’t much time to deal with this and that 5G should have preference.

Decision: The document was agreed.

7.8 Documents on joint meeting with SA6 regarding eMCSec

S3-180382 Presentation for Joint SA3/SA6 meeting

Type: other For: Presentation
Source: NCSC

Discussion:

Slide 4: SA6 agreed to the assumptions.

InterSD vs SDS: who makes the decision? SA3 or SA6?

Motorola solutions: InterSD would seem easier for SA6 according to some informal discussions we've had.

Motorola Solutions (SA3): we are OK with this in SA3.

It was noted that the InterSD message must be identifiable. SA6 will take care of the documentation and flows of these messages.

IWF to the client security would be work for SA3. There are no new reference points so we would use existing ones.

It was agreed that service independence aspects should be added.

Slide 8: Discreet listening/viewing

One SA6 opinion was that this should be considered inRel-16. This was agreed.

Police of Netherlands: collection and storage? this is real time.

Peter (NCSC): it's SA6 who decides how and when this data is stored.

Slide 9: Temporary group call/user regroup

SA6 recognises the problem and it needs to be discussed further. Downstream groups face the same issue.

T-Dek (SA6): There are two models: Group ID pre-allocated before the group is formed. SA3 mechanisms are based on this model. Temporary group call is based on the case when the Group ID is not pre-allocated, that is part of the SA1 requirements. It's not appropriate to discard this for the security. We need to enhance the procedure, it's not complete. This is SA6 perspective.

The SA6 Chair commented that it will be decided whether this will go to Rel-15 or Rel-16.

Alan (SA6): it's a deployment decision whether they want to use an unsecure call.

Adrian (SA6) supported that. It's an operational deployment choice.

Peter (NCSC): the media security is mandatory in 3GPP. It's a requirement that wouldn't be applied in this case.

The Chair (SA3) commented that this could be enhanced in Rel-16 but SA6.

Motorola (SA6): It was also commented from an SA6 delegate that cat-F CRs could be brought to enhance this.

Firstnet (SA6): we are ok with having it in Rel-16.

Decision: The document was noted.



S3-180402 LMR interworking key management summary


Type: other For: Presentation
Source: Harris Corporation

Decision: The document was noted.