Summary of 5GS_PH1-Sec at SA3#102e

SBA | | |
S3-210102 | Optional registration of NF Service Consumer to NRF | Nokia, Nokia Shanghai Bell, Huawei, HiSilicon | Not pursued
S3-210103 | Optional registration of NF Service Consumer to NRF | Nokia, Nokia Shanghai Bell, Huawei, HiSilicon | Not pursued
S3-210104 | Optional registration of NF Service Consumer to NRF | Nokia, Nokia Shanghai Bell, Huawei, HiSilicon | Not pursued
S3-210413 | OAuth 2.0 client registration and NF Service registration | Ericsson | noted

S3-210238

Correction to the access token storage in NF service consumer

Huawei, HiSilicon

CMCC object R15
Nokia object

S3-210239 | Correction to the access token storage in NF service consumer | Huawei, HiSilicon | R1 Nokia ok?
S3-210240 | Correction to the access token storage in NF service consumer | Huawei, HiSilicon | R1 Nokia ok?
S3-210385 | Adding the security requirement with encBlockIndex in Rel15 | Huawei, HiSilicon, Nokia, Nokia Shanghai Bell | CMCC object R15
S3-210386 | Mirror Adding the security requirement with encBlockIndex in Rel16 | Huawei, HiSilicon, Nokia, Nokia Shanghai Bell | R1 agreed
S3-210387 | Mirror Adding the security requirement with encBlockIndex in Rel17 | Huawei, HiSilicon, Nokia, Nokia Shanghai Bell | R1 agreed

S3-210382

Align the JSON format on encryption IE with CT4 in Rel15

Huawei, HiSilicon, Nokia, Nokia Shanghai Bell

R2 agreed
(fix references)

S3-210383

Align the JSON format on encryption IE with CT4 in Rel16

Huawei, HiSilicon, Nokia, Nokia Shanghai Bell

R1 agreed
(change marks need fixing)

S3-210384

Mirror: align the JSON format on encryption IE with CT4 in Rel17

Huawei, HiSilicon, Nokia, Nokia Shanghai Bell

R1 agreed
(change marks need fixing)

S3-210395 | Clarification on PLMN ID verification in Rel15 | Huawei, HiSilicon | Not pursued
S3-210396 | Clarification on PLMN ID verification in Rel16 | Huawei, HiSilicon | Not pursued
S3-210545 | resolving ed note on protection policy mismatch | NTT DOCOMO INC. | R1 agreed

S3-210074

Error code details - Resolving ed note in 13.2.2.6

Nokia, Nokia Shanghai Bell

R2 agreed
(coversheet update to make mirror)

S3-210075

Error code details - Resolving ed note in 13.2.2.6

Nokia, Nokia Shanghai Bell

R2 agreed 
(coversheet update to make mirror of 545)

S3-210551 | resolving ed note on protection policy mismatch | NTT DOCOMO INC. | Merged in 074
S3-210552 | resolving ed note on protection policy mismatch | NTT DOCOMO INC. | Merged in 075
Mobility | | |
S3-210397 | Discussion paper on TAU reject issue during MME handover | Huawei, HiSilicon | noted
S3-210398 | LS on TAU reject issue during MME handover | Huawei, HiSilicon | noted
Editorial | | |
S3-210339 | Typo correction in clause 6.9.9.4 | Xidian University | Not pursued
S3-210532 | Typo correction in clause 6.9.4.4 | Xidian University | agreed
S3-210550 | Typo correction in clause 6.9.4.4 | | agreed
IETF | | |

S3-210515

Updated proposal to introduce draft-ietf-emu-rfc5448bis to TS 33.501  Ericsson

Ericsson

Noted
Chair to initiate organizing a joint conference call with appropriate IETF WG
Rapporteur can then arrange date etc. 
SA3 will send an LS to IETF WG from May meeting, if consensus

Details

SBA
S3-210102          Optional registration of NF Service Consumer to NRF     Nokia, Nokia Shanghai Bell, Huawei, HiSilicon
Ericsson: Summary: Proposal to not pursue this CR (and its mirrors)
Thanks Anja/Nokia for working on this issue, as you see from Ericsson’s S3-210413 we also see the problem that consumers only register when they happen to also be producers. However, as also indicated in S3-210413, the problem goes a bit further. We think the main question is how NF consumers register as OAuth 2.0 clients to the authorization server (NRF). So we believe this topic needs further discussion and the problem is not yet addressed by the changes proposed in this CR. More specifically, even if the consumer happens to be a producer and uses NF service registration, it would not meet the requirements of OAuth 2.0 client registration. For consumers that are not producers, the CR does not provide a solution.
We are happy to continue the discussion on how to solve the issue.
If I understand it correctly, disagreement with 102 also implies disagreement with the mirrors, i.e. S3-210103 and S3-210104.
CMCC: I would like to raise a general challenge to each documents referring R-15 in AI#4.1. Is it related to FASMO issue? 
I propose to not pursue this contribution. I don’t believe it is FASMO issue. Without this contribution, there is an issue but no harm for operation..
This comment is only for R-15 document. Mirrors are not related.
Mavenir: Mavenir agrees with Ericsson.
Nokia: Re-check the situation, maybe from R16 onwards
During the Tuesday CET lunch call we looked at another option for resolution.
We said that the paragraph on registration of NF service consumer to NRF could be removed. The whole paragraph is just creating confusion because we have OAuth client registration and NF service registration, The text seems to mix both – see 413. I will provide a revision to -103 and -104 to check the water.
Mavenir: Please check Mavenir position and proposal on S3-210103 thread.

S3-210103          Optional registration of NF Service Consumer to NRF     Nokia, Nokia Shanghai Bell, Huawei, HiSilicon
cf. 102
Nokia: -r1 uploaded
During the Tuesday CET lunch call we looked at another option for resolution of 102/103/104.
We said that the paragraph on registration of NF service consumer to NRF could be removed. The whole paragraph is just creating confusion because we have OAuth client registration and NF service registration, The text seems to mix both – see 413. 
I provide this revision to check on your opinions.
Mavenir: The proposal is not acceptable. I do not know what we are trying to solve by removing the paragraph.
If removing the paragraph is justifiable, then why not removing the next one:
“OAuth 2.0 resource server (NF Service Producer) registration with the OAuth 2.0 authorization server (NRF)
The NF Service registration procedure, as defined in clause 4.17.1 of TS 23.502 [8], shall be used to register the OAuth 2.0 resource server (NF Service Producer) with the OAuth 2.0 Authorization server (NRF). The NF Service Producer, as part of its NF profile, may include "additional scope" information related to the allowed service operations and resources per NF Service Consumer type.
“
What is the difference?
I suggest the following way forward.
The following text:
“OAuth 2.0 client (NF Service Consumer) registration with the OAuth 2.0 authorization server (NRF)
The NF Service registration procedure, as defined in clause 4.17.1 of TS 23.502 [8], shall be used to register the OAuth 2.0 client (NF Service Consumer) with the OAuth 2.0 Authorization server (NRF), as described in clause 2.0 of RFC 6749 [43]. The client id, used during OAuth 2.0 registration, shall be the NF Instance Id of the NF.
“
SHOULD be updated as follows:
“
OAuth 2.0 client (NF Service Consumer) registration with the OAuth 2.0 authorization server (NRF)
As described in RFC 6749 [43], the OAuth 2.0 client (NF Service Consumer) shall register with the OAuth 2.0 Authorization server (NRF).
The NF Service registration procedure, as defined in clause 4.17.1 of TS 23.502 [8], shall be used to register the OAuth 2.0 client (NF Service Consumer) with the OAuth 2.0 Authorization server (NRF), The client id, used during OAuth 2.0 client registration, shall be the NF Instance Id of the NF.
“
r2 based on the original S3-210103 is on the Draft folder.
If acceptable, please add Mavenir as a cosigner.
Ericsson: Summary: disagrees with r2, proposes updates to r1
Ericsson’s concrete proposal for a way forward is based on r1, but instead of removing the whole text on OAuth 2.0 client registration, the title could stay and the text below could be replaced by a note “OAuth 2.0 client (NF Service Consumer) registration with the OAuth 2.0 authorization server (NRF) is not specified in this document and left to implementation.” Nokia’s proposal to make the changes from Rel-16 onwards sounds reasonable.
Regarding r2, it is basically identical to the original text, so if that is the way forward it would be better to just not make any changes at all.
Generally, it seems that opinions are diverging quite much on this topic and it looks like we may not reach agreement during this meeting. So maybe a conf call between the meetings would be helpful?
Regarding Mavenir’s question why not the producer registration should be removed: This text actually contains an important detail, namely that the producer can indicate in its profile the "additional scope" information related to the allowed service operations and resources per NF Service Consumer type that the producer allows. This is an extension of existing Rel-15 behavior which however only is specified in stage-3, not stage-2. According to Rel-15 onwards of TS 29.510, the producer can indicate in its profile information about which e.g. type and NSSAI of consumers it allows.  
Huawei: Huawei is fine with both the original version or r1.
R2 is not acceptable.
We prefer to use the original version.
“may” would be helpful for the cases that NFc could use to register as client to the NRF.
Keeping the flexibility would be better.
Nokia: -r3 uploaded based on -r1 and Ericsson proposal.
I think, this would be a good way forward.
Mavenir: @Ericsson There are two things that we need to capture.
 1.	OAuth2.0 Registration:
NRF is the OAuth2.0 Authorization server and thus, TS 33.501 needs to capture the details how the OAuth2.0 client (NF Service Consumer) and the OAuth2.0 resource server (NF Service Producer) register with the OAuth2.0 server.
 2.	5GC Repository (NRF) Registration
This is applicable to the registration of all CONSUMERS with the NRF.
According to SA2 clause 4.17.1 of TS23.502, the consumer shall register with the NRF. Only the consumer.
Consumer here is any 5GC NF that consumes any of the NRF services. Please check SA2 specification for accuracy.
NOW:
Why you think the registration procedure with the 5GC Repository can be used for registering “OAuth2.0 resource server” BUT can NOT be used for registering “OAuth2.0 client”?
Can you please clarify?
Thanks!
Mavenir: Mavenir disagree and object to r3.
Please see my response to Ericsson.
Ericsson: Summary: answers to Mavenir’s comments
Thanks for your question, let me try to answer it.
To start with, in TS 23.502 clause 4.17.1, “consumer” means “consumer of the NRF registration service” = NF that offers services = NF producer. There is a Note in the same clause that clarifies it: “NOTE 1: The term "NF service consumer" in this clause refers to the consumer of the NRF services and should not be confused with the role of the NF (consumer or producer).”
This means that the NFs that use the NRF registration service usually have the role “NF producer”, not “NF consumer”. So from that point of view it makes sense that OAuth 2.0 resource servers (NF producers) register to the OAuth 2.0 Authorization server (NRF). According to my knowledge, there is no OAuth 2.0 resource server registration to the OAuth 2.0 Authorization server in the OAuth 2.0 RFCs, so this is a purely 3GPP defined procedure on top of the RFCs. So this is the explanation why OAuth 2.0 resource servers can use the NRF registration service.
Now to the question whether OAuth 2.0 clients can use the NRF registration server. We actually state in S3-210413 that NF Service registration is one possible solution for OAuth 2.0 client registration (High-level solution 2) ). It just needs a bit of extra work to make it a complete solution.
I hope that clarifies.
Nokia: hoping, this is agreeable as it is, I cleaned up in -r4 and updated to Cat F.
Mavenir: Let me try to explain. Please bear with me.
 With respect to NRF, a consumer is any 5GC NF which consumes a service of the NRF. Simple English. It even includes SCP, SEPP, the NRF itself, etc. and some 4G network functions, like HSS.
Please check TS29.510 for the NF Type that the NRF is supposed to be aware of and it is aware of that NF profile as it is registered with the NRF.
 
Here is the list for a quick reference:
    NFType:
      description: NF types known to NRF
      anyOf:
        - type: string
          enum:
            - NRF
            - UDM
            - AMF
            - SMF
            - AUSF
            - NEF
            - PCF
            - SMSF
            - NSSF
            - UDR
            - LMF
            - GMLC
            - 5G_EIR
            - SEPP
            - UPF
            - N3IWF
            - AF
            - UDSF
            - BSF
            - CHF
            - NWDAF
            - PCSCF
            - CBCF
            - HSS
            - UCMF
            - SOR_AF
            - SPAF
            - MME
            - SCSAS
            - SCEF
            - SCP
            - NSSAAF
            - ICSCF
            - SCSCF
        - type: string

Let me try one more time: What SA2 is trying to say is:
When a Network Function (whichever NF) consumes any service of the NRF, then that NF is called a consumer during the transaction of consuming the NRF service.
Example: when the AMF consumes the NRF Nnrf_NFManagement service for registration, it is considered in that transaction as a consumer to the NRF.
However, when the SMF consumes any of the AMF offered services, the AMF is considered in this case a PRODUCER.
 
That is exactly the explanation of the NOTE from SA2 below.
 
That is why SA2 in clause 4.17.1 of TS23.502 says clearly, the following:
                   4.17.1   NF service Registration

NOTE 1:     The term "NF service consumer" in this clause refers to the consumer of the NRF services and should not be confused with the role of the NF (consumer or producer).

Hope this help.
Mavenir: I completely disagree that the registration with NRF can be used for registering the OAuth2.0 resource server but not the OAuth2.0 client.
That is what the current text is trying to say and needs minor clarification.
The answer from Christine is not correct and I replied back.
Mavenir agrees to r2 and believe it is nothing but correction of the what the existing text meant to say.
Mavenir still object to all other revisions including r4.
Thanks for your consideration.
Ericsson: Summary: answers to Mavenir’s comments
Let’s try to sort this out. Currently it is not clear to me whether this is just a different understanding of terminology, or whether there is a different understanding on technical matters as well. 
The point I am trying to make is: An NF that never plans to offer any services does not need to register at the NRF. Is your point that this is not true anymore with Rel-16 where also SEPPs and SCPs can register? Or is your point that it doesn’t matter, because any NF _can_ use the NRF registration servic
Nokia: Ericsson, after all this discussion, do you agree on version 0103-r2 ?
If not, then I suggest to merge the doc into 241 for not losing the editorial change 2.
Ericsson: Summary: disagrees with r2
The reason for disagreeing with r2 is that is basically does not provide any changes to the original text, just moves text around. It is better to leave the original text as it is.
About the editorial: If I am not mistaken, there is less than an hour left to the last objection deadline and the last revision deadline has passed yesterday. I suggest not to attempt another merger at this time. Generally, let’s try to keep the meeting deadlines and give people the chance to start their well-deserved weekend in time.
Nokia: 103/104 is noted.
Dear Ericsson, we need to sleep in between 😊 and there are too many topics on the same shoulders that in a normal working day are not possible to tackle.
I hope you are not blocking 241/242 because of the weekend, which we surely all well deserve.

S3-210104          Optional registration of NF Service Consumer to NRF     Nokia, Nokia Shanghai Bell, Huawei, HiSilicon
cf. 102/103
Nokia: -r1 uploaded
During the Tuesday CET lunch call we looked at another option for resolution of 102/103/104.
We said that the paragraph on registration of NF service consumer to NRF could be removed. The whole paragraph is just creating confusion because we have OAuth client registration and NF service registration, The text seems to mix both – see 413. 
I provide this revision to check on your opinions.
Mavenir: Please check Mavenir position and proposal on S3-210103 thread.
Nokia: -r2 uploaded in alignment with 103-r3
Please see discussion in 103 thread.
Lenovo: Minor editorial: please check on the cover sheet the grammar of the reason for change and the spelling of “OAuth registionration” there 😊
cf. 104

S3-210413          OAuth 2.0 client registration and NF Service registration              Ericsson
Huawei: Summary: ask for clarification.
Thanks for initiating this discussion, Please find my comments below:
1. As mentioned in this contribution, not all the cNF should register to the NRF. If OAuth 2.0 client registration is required, it means that cNF shall register into the NRF.
Would you please clarify which information is required or necessary during the client registration, NF profile, or keys used for Oauth, etc?
Currently, not all the procedures of Oauth 2.0 are adapted in SA3. We should give out the clear information required for implementation in SA3.
[(Eri)] Exactly, NF service registration is not quite adapted to be used as OAuth 2.0 client registration. So if SA3 decides to address OAuth 2.0 client registration by adapting NF service registration, then further study/work would be needed to understand exactly how to do it. Answering the questions you raised would be part of that work.  
[HW] Currently, we need to find out whether the Oauth 2.0 client registration is required or not, and which parameters are necessary. I am still not convinced that the OAuth 2.0 client registration is needed.
[(Eri2)] I believe Huawei’s earlier work about how the NRF can check the input parameters of the token request is very much related. One could actually see it as a solution proposal for OAuth 2.0 client registration, with two possible options: use NF service registration or check the values in the NF’s certificate.
[HW2] Huawei’s earlier work relies on the existing NF certificate. No new procedure is required. On the other hand, the pNF could trust the content of the certification if the certification is successfully verified. As you know we can not put all the information into the certificate. However, some important parameters could be considered, such as the NF type, NSSAI, etc. Anyway, the NSSAI is not agreed regarding the dynamic mechanism. This is clear from my side. OAuth 2.0 client registration needs further discussion.
[ERI3] Yes, agree that it is good if the NF certificate can be used, unfortunately not all kind of information is sufficiently stable to be included in the certificate, so more work is needed.  
2. For the 1^st option, Using the O&M system for client registration may have two potential method.
1) O&M configures the NRF. This may have other issues, such as the cNF may not register to the configured NRF, or the cNF may never register to the configured NRF.
2)O&M configures the cNF, then cNF registers to the NRF. It requires the cNF to register to the NRF anyway.
[(Eri)] Our understanding was that it would be 1), O&M configures the NRF. I think that choosing this solution (O&M) would essentially leave the solution unspecified. Having said that, I do not quite see the problems that you mention. The problem is to find a way to configure – if a configuration is not used, the only problem to me seems to be a slight waste of resources. Please correct me if I understood your question wrongly.
[HW] Exactly, it may be waste of resources, which depends on when to virtualization the NF. We always has to configure the cNF. If we choose 1), then we have to configure the cNF and NRF. If we choose 2), we may only need to configure the cNF. This is my general understanding. 
[(Eri2)] Yes, in your solution proposal in earlier CRs your somehow combine the client registration with the token request, and also reuse the earlier O&M provisioning of the NF’s certificate, so there is no explicit client registration message on top of that. 
[HW2] exactly. Independent procedure for oauth client registration is not required from my understanding. Maybe you can take concrete proposals in the future.
[ERI3] Yes, thanks for the concrete proposal and for clarifying your understanding, it was very helpful.
Mavenir: Summary: This is a discussion paper anyway and will be NOTED. However, some clarification is needed before moving forward
Details:
 1.	The discussion paper indicates that implicitly and explicitly that NF service Consumer is always the OAuth 2.0 client and registration for the NF service consumer is actually meant to be for the OAuth2.0 client registration.
[(Eri)] Please let me clarify. That the consumer is the OAuth 2.0 client is specified in TS 33.501. It is also currently specified in TS 33.501 that NF service registration shall be used for OAuth 2.0 client registration. The point of the discussion paper is that there is at least a little further work needed, because the NF service registration cannot be used directly as is for OAuth 2.0 client registration.
[MV] Actually we do not need any extra work. This OAuth2.0 registration is already achieved in the NF service consumer registration and we require the NRF as Authorization server to validate the NF ID as the NF ID either in its mTLS certificate in direct communication OR as in CCA in indirect communication. Thus, there is no problem at all in TS33.501 specification, every thing works just fine and we need no extra work. The problem is created by CT4 requiring access token for the NF service consumer when accessing the NRF service. SA3 identified the issue long time ago and agreed that is NOT NEEDED.
Finally, If we are interested in ensuring that our TS33.501 is complete, all what we need is to change the NOTE to normative text and communicate that to CT4.
[ERI2] Let me start by saying: By bringing this discussion paper, we are just trying to solve the problem of how the OAuth 2.0 client registers to the Authorization server. The problem has been on our backlog for a long time, and now that the discussion came up at the last meeting it seemed like a good time to finally start the discussion in SA3. Maybe it was a bad timing seeing your reaction 😊.
In my understanding, OAuth 2.0 client registration is about how the authorization server obtains the information about the client that it needs to decide whether the client is authorized to do something or not.  It is also about making sure that the client can authenticate to the authorization server, but that we (SA3) have described already (NF-NRF authentication in clause 13.3.1) or have generally currently left out of scope (certificate provisioning). So back to “how the authorization server obtains the information about the client that it needs to decide whether the client is authorized”. In current 33.501, as far as I know, this is specified in two places. One is the statement that NF service registration is used for OAuth 2.0 client registration. The other one is in the token request procedure: “The NRF may verify the input parameters (e.g., NF type) in the access token request match with the corresponding ones in the public key certificate of the NF service consumer or that in the NF profile of the NF service consumer.”
I am not aware of any statement that requires the NRF to validate the NF instance ID from the TLS certificate. There is actually no statement that requires any verification of any input parameter in the token request, although the statement that the NRF may verify the input parameters in the access token request by consulting the certificate or the profile is a good step in the right direction. What we believe is missing in Rel-16 is a more complete description of that, i.e. how the NRF knows whether a consumer is authorized or not.  
 2.	I read that as an attempt to justify that the OAuth2.0 client register with the Authorization server (NRF) and that registration could generate an access token back to the OAUTH2.0 client that can be used later on to access the NRF services (Authorization server)
[(Eri)] No, that is not the intention. The intention is to clarify how OAuth 2.0 client registration works in SBA. Hence I will skip questions 2 and 3. An NF service producer uses the NF Service registration procedure to register at the NRF.
[MV] Could you please take a look at my comment under 1 above. Hopefully we can reach an agreement and get this resolved.
 3.	If No. 2  is correct, could you please clarify my question:  what happens with the NF service Producer which is NOT an OAuth 2.0 client and needs to register its profile with the NRF?
 4.	In other words, how the NF service producer (which is not an OAuth 2.0 client) would get an access token to present to the NRF when consuming for example Nnrf_NFManagement service?
Here is my proposal:
 1.	To adopt solution number 1 and ensure that it is out of the scope of 3GPP specification.
[(Eri)] Thanks for the feedback about which is Mavenir’s preferred solution. The advantage of this solution is that the standardization impact is minimal. The disadvantage is that different vendors will have different solutions which may not be compatible.  
[MV] Actually, Mavenir does NOT see any compatibility issue in here. We all know, that operators use different vendors in their network and they ensure that all the vendors integrate with their O&M solution and everything works just fine. I picked this solution because I do not believe that anything is needed for TS33.501 specification and making out of scope will enable another way to say everything currently is addressed in TS33.501. Please see my comments under item 1 above.
 2.	Then, for accessing the NFR services, we follow the recommendation in TS33.501 where access token is NOT required or NOT needed and rely on static authorization only.
If you agree, then SA3 does not need to do anything, we only need to inform CT4 with the agreement.
Looking for your feedback.
In addition on a separate note: In both RFCs (8705) & (7591) that you referenced I can find the following text:
RFC8705:
We should not go further than the Abstract of the RFC:
{{
Abstract
   This document describes OAuth client authentication and certificate-
   bound access and refresh tokens using mutual Transport Layer Security
   (TLS) authentication with X.509 certificates.  OAuth clients are
   provided a mechanism for authentication to the authorization server
   using mutual TLS, based on either self-signed certificates or public
   key infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual-TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.
 
“In other words, This RFC provides a mechanism that allows the resource server (NF Service Producer) the means to validate the Access Token Proof-of-Possession.
 
Would that be a reasonable proof for E/// to agree on the proof-of-possession at the Resource Server? Maybe as a starting point we agree to do that in the case of direct communication where mTLS is end-to-end.
 
Looking for your feedback.
[(Eri)] We have discussed this many times. The problem is that, for SBA, one would need to find a solution that works for both direct and indirect communication. The producer does not know whether it uses direct or indirect communication. What would the producer do if the TLS certificate of the peer and the access token do not match? Assume it is communicating with an SCP and go on?
[MV] Thanks Christina; now I understand the logic.
However, I want to ask the following question: 
Why all of us already agreed on different solutions to authenticate the NF service Consumer at NRF, for example? For direct and indirect communication?
As you know for direct communication, NRF uses mTLS with the NF Service Consumer certificate to authenticate the NF Service Consumer and its ID; WHILE for Indirect Communication, we have to come up with another mechanism, i.e., CCA. Do you see my point?
[ERI2] In my understanding, indirect communication will be the main mechanisms for deploying 5GC. So from that point of view, we should not in Rel-16 introduce something that only works in direct communication. So this is probably the main point. But to answer your question: Generally of course it is preferable to have one mechanism and not be dependent on configuration. The choice of authentication method is a fundamental decision, so it is quite possible that this would be part of vendor and customer discussions what to use and configure. A minor check of something hidden somewhere in the specifications is not a fundamental decision that would be part of vendor and customer discussions. For these minor things, we need a solution that just works independent of the deployment. Nobody wants that the network suddenly stops working because there is a check somewhere that nobody thought of when moving from direct to indirect communication. 
Thanks for your clarification.

S3-210238          Correction to the access token storage in NF service consumer              Huawei, HiSilicon
CableLabs: Thanks for the CR. 
One minor comment on the changes to 13.4.1.2.2: you may also want to move the highlighted sentence in step 4 (along with the rest texts) to step 5 (see below).
“
4.   If the authorization is successful, the access token shall be included in Nnrf_AccessToken_Get Response message to the vNRF. Otherwise it shall reply based on Oauth 2.0 error response defined in RFC 6749 [43]. The NF Service Consumer may store the received token(s). ~~Stored tokens may be re-used for accessing service(s) from NF Service Producer NF type listed in claims (scope, audience) during their validity time. The other parameters (e.g., the expiration time, allowed scope) sent by NRF in addition to the access token are described in TS 29.510~~ [68].
5.   The vNRF shall forward the Nnrf_AccessToken_Get Response or error message to the NF service consumer.  Stored tokens may be re-used for accessing service(s) from NF Service Producer NF type listed in claims (scope, audience) during their validity time. The other parameters (e.g., the expiration time, allowed scope) sent by NRF in addition to the access token are described in TS 29.510 [68].
“
Mavenir: Thanks Bo for brining in this CR. It makes lots of sense.
However, the change identified by Tao I also identified as required as the left sentence does not make any sense now and should be moved to step 5.
I placed r1 on the Draft folder.
Please take a look.
Huawei: Thanks for your check. Indeed, I agree with your changes. It makes sense to also remove the sentence just before the removed one to the step5.
Hence, I’m fine with r1.
Ericsson: Summary: proposes changes to r1
Thanks for providing this CR and revision. I have two additional minor comments that also apply to r1:
First change: Suggestion to change "NF Service Producer type"  to  "NF Instance Id or several NF Instance Id(s) of the requested NF Service Producer", as this is the procedure for specific instances of the producer, not whole NF type.
Directly after the second change, there seems to be a “Next change” or “second change” marker missing. It is present in the mirror S3-210239.
CMCC: I would like to raise a general challenge to all documents referring R-15 in AI#4.1. Is it a FASMO issue? 
I propose to not pursue this contribution. I don’t believe it is FASMO issue. Without this contribution, the network can still work well with current specification.
This comment is only for R-15 document. Mirrors are not related.
Mavenir: I agree this change is basically editorial but with technical impact.
OUR specification should not introduce text where the steps under a specific call flow does not align with the call flow. That is really bad! ☹
It is not good for SA3 for TS33.501 to have that silly mistake/inconsistency.
In other words, it is simple but it makes our specification complete.
CMCC: I’m not against the technical revision. It can be done in R-16 and/or R-17. But it is totally wrong and dangerous to modify R-15 specification casually.
If you check specifications in previous release, e.g. R-8 to R-14 in LTE ear, you can also find many inconsistency with other specs. But can we provide CRs to fix anything that we want? The answer is NO as they are frozen. 
Now R-15 is also frozen for 2 years. But many CRs are still proposed that try to introduce, modify or remove some features in name of correction. That is really bad! Let’s keep the frozen specification as frozen!
Pls note that is already indicated in agenda document, that R-15 contribution is only on essential FASMO correction. So my question is, without this contribution, will the network shut down?
Mavenir: I agree. Makes lot of sense.
Huawei: I think what’s proposed in this document can be seemed as FASMO issue. The reason is if the exact call flow is wrong, different network entities, i.e. NF consumer, NF producer will perform different procedures which will cause very serious problem of network. 
This wrong text will lead to the wrong behaviour for NF consumer as well as NF producer.
So if we can find out this problem to avoid that, I’m sure there is nothing wrong.
Even for the frozen specifications, we also will provide some changes if it’s identified.
CMCC: The argument is not convinced. 
If we looks into the details of proposed text, it added text as optional feature, e.g. “The NF Service Consumer may store … …”. Such option feature implies current solution can still work well even if the option is not exist.  So I don’t believe there is issue without those changes.
Nokia: Minpeng, I disagree.
1a or 1b need to be equally treated and this is corrected by 238.
-update proposed
We could shift the 1a text to the end and make sure, it applies to both, instead of adding new text under 1b, as follows:
After step 1a or 1b, the NF Service Consumer may store the received token(s). Stored tokens may be re-used for accessing service(s) from NF Service Producer NF type listed in claims (scope, audience) during their validity time.
CMCC: As I said on conf call, it could be done in R-16/17.
I agree with you that 1a and 1b are not equally treated, but it doesn’t cause fatal issue for network operation.
So pls keep R-15 as it is.
Nokia: I propose to close this thread and note 238. See 239 for follow up.

S3-210239          Correction to the access token storage in NF service consumer              Huawei, HiSilicon
cf. 238
Nokia:  moving the discussion from 238 to 239, since leadership is not okay with Rel-15 changes.
239 is on Rel-16 and now needs CAT F and maybe WID update as well.
Changes as [...for  238] need to be implemented.
Huawei: Thanks for your suggestion, we update this CR based on the suggestion except the one below.
We could shift the 1a text to the end and make sure, it applies to both, instead of adding new text under 1b, as follows:
After step 1a or 1b, the NF Service Consumer may store the received token(s). Stored tokens may be re-used for accessing service(s) from NF Service Producer NF type listed in claims (scope, audience) during their validity time.
[Answer]Considering for 1a, the stored tokens is used for access from NF Service Producer NF type, but for 1b, the stored tokens is used for access fromspecific instances of the producer, not whole NF type. 
Therefore, we propose define it seperately. Please check whether it is fine with you.
please find r1 in the draft folder.
Ericsson: -r1 is fine
Nokia: as proposed under -0241 thread. Please check, if some of the changes from -0241 can be merged into –0239/-0240.
Currently Mavenir is objecting -0241 and also Nokia has concerns, therefore we think, it is best to see the merge of your changes applied to 239/240.
Huawei: Thanks for your reply.
Considering the limited time and we don’t want to jeopardize the agreement we have reached in 239/240 , we prefer to discuss them separately.
In addition, for the 241/242, even the same clause 13.4.1.1.2 and 13.4.1.2.2 are involved,  but the modification is completely independent with 239/240 and some modification affect other clauses. 
Therefore, please provide your concerns on them separately.
Huawei: I think this 239 needs your confirmation for clear recording of doc status.
This r1 is updated based on your suggestions, and Ericsson and Mavenir confirmed as well.

S3-210240          Correction to the access token storage in NF service consumer              Huawei, HiSilicon
cf. 238/239
Nokia: this CR needs to be aligned with any changes done in 239, including potential change of WID.
See 238 for discussion.
Huawei: Thanks.
Please see my response under thread S3-210239. And r1 is also uploaded.  Please check whether you are fine with that
Ericsson: Thanks, r1 is fine.
Nokia: as proposed under -0241 thread. Please check, if some of the changes from -0241 can be merged into –0239/-0240.
Currently Mavenir is objecting -0241 and also Nokia has concerns, therefore we think, it is best to see the merge of your changes applied to 239/240
Huawei: Thanks for your reply.
Considering the limited time and we don’t want to jeopardize the agreement we have reached in 239/240 , we prefer to discuss them separately.
In addition, for the 241/242, even the same clause 13.4.1.1.2 and 13.4.1.2.2 are involved,  but the modification is completely independent with 239/240 and some modification affect other clauses.  
 Therefore, please provide your concerns on them separately.

 
S3-210385          Adding the security requirement with encBlockIndex in Rel15              Huawei, HiSilicon, Nokia, Nokia Shanghai Bell
CMCC: I would like to raise a general challenge to all documents referring R-15 in AI#4.1. Is it a FASMO issue? 
I propose to not pursue this contribution. I don’t believe it is FASMO issue. Without this contribution, the network can still work well with detailed procedure defined in CT4.
This comment is only for R-15 document. Mirrors are not related.
Ericsson: Summary: proposes updates (independent of release)
Thanks for providing this CR. I have some comments and suggested updates.
The first sentence in the proposed changes reads: “The sending SEPP shall discard JSON of the request messages received from the NF service consumer (via SCP) with "encBlockIndex" (regardless of the encoding used for that JSON request).”
Discard JSON: This sounds like only the JSON is discarded instead of the whole message.
NF service consumer: Should be regardless of NF consumer or producer
Request message: Should be regardless of request or response, right?
So the proposal is to reformulate: “The sending SEPP shall reject messages received from the NF (via SCP) with JSON including “encBlockIndex” (regardless of the encoding used for that JSON)”.
Similar for the second sentence: “The receiving SEPP shall reject any request in which an IPX has inserted or relocated references to encBlockIndex.”
Request: Should be regardless of request or response.
Proposal is to reformulate: “The receiving SEPP shall reject any message in which an IPX has inserted or relocated references to encBlockIndex.”
These comments are for the actual content of the CR, independent of from which release the changes are applied.
Huawei: @Christine, please find r1 in the draft folder. Thanks for your suggestion.
@Minpeng, These changes are added according to the LS S3-203522 sent from SA3 to CT4 in the previous meeting. From the security point of view, these requirements are needed. Hope the above answers could address your concern. 
Thanks
CMCC: I’m still not convinced by the argument. It can be solved in R-16 and/or R-17, rather than R-15.
Pls note that is already indicated in agenda document, that R-15 contribution is only on essential FASMO correction. So my question is, without this contribution, will the network shut down?
Huawei: For the security requirement and its mirrors, I am OK to note the Rel15 CR, and make the changes in Rel16 and Rel17 only.
Are you fine with it?
If you are OK, I will note the Rel15 CR, and update the rel16 and rel17 CR accordingly.
CMCC: It is fine for me. Thanks for your consideration.
Ericsson: Summary: minor change proposals to r1
Thanks Bo for providing r1. When checking r1 I realized another change may be needed, sorry for not pointing out earlier.
“The sending SEPP shall reject the messages received from the NF (via SCP) with JSON including "encBlockIndex" (regardless of the encoding used for that JSON request).”
(via SCP): This sounds like there is always an SCP between NF and SEPP. 
The messages: At least to me this sounds a bit like all messages shall be rejected, which is not the intention I believe 😊
Concrete proposal is to reformulate as:
“The sending SEPP shall reject messages received from the NF (directly or via SCP) with JSON including "encBlockIndex" (regardless of the encoding used for that JSON request).”
I understand that the change will be done from Rel-16 onwards, so my comments are for Rel-16 onwards. (For Rel-15, the SCP would have needed to be removed.)
Huawei: As the writer of this contribution, I would like to announce that this contribution can be noted.

@Ericsson, your comments will be addressed in the S3-210386 thread. Thanks.
Nokia: Can be noted, since Rel-15
Updates are done in 386/387

S3-210386          Mirror Adding the security requirement with encBlockIndex in Rel16    Huawei, HiSilicon, Nokia, Nokia Shanghai Bell
cf. 385
Huawei: I would like to initiate this email thread to discuss the changes in the Rel16.

@Ericsson, suggested changes are implemented in r1.
Please find it in the draft folder.
Ericsson: r1 is fine
Nokia: Fine by Nokia. Thanks for implementing.
Please check on WID code.
Huawei: Thanks. The WID code is TEI16, as it is not a mirror.
What is problem with the WID code?

S3-210387          Mirror Adding the security requirement with encBlockIndex in Rel17    Huawei, HiSilicon, Nokia, Nokia Shanghai Bell
cf. 385
Huawei: I would like to initiate this email thread to discuss the changes in the Rel17.
The changes are the same with 386r1.
Ericsson: Thanks, r1 is fine.
Nokia: thanks

S3-210382          Align the JSON format on encryption IE with CT4 in Rel15              Huawei, HiSilicon, Nokia, Nokia Shanghai Bell
CMCC: I would like to raise a general challenge to all documents referring R-15 in AI#4.1. Is it a FASMO issue? 
I propose to not pursue this contribution. I don’t believe it is FASMO issue. Without this contribution, the network can still work well with detailed procedure defined in CT4.
This comment is only for R-15 document. Mirrors are not related.
MCC: Just a comment on the cover pages: the mirrors must carry the same work item code as the original CR: 5GS_Ph1-SEC.
This way they all belong to the same package. I can change this on the cover pages if the CR are agreed without changes. Otherwise, please make the change.
Ericsson: Summary: proposes updates (independent of release)
Thanks for providing this CR. As indicated at the offline call: I understand that the intention of this CR is to revert the changes in S3-183685. However, S3-183685 contains more changes than just the figure. So I believe it would generate misalignments inside TS 33.501 if not all the changes in the earlier CR are reverted.
These comments are for the actual content of the CR, independent of from which release the changes are applied.
Huawei: Thanks for your suggested changes.
Please find r1 in the draft folder. If r1 is fine, I will update the related mirrors accordingly.
I revert changes in S3-183685 on the latest version of R15 TS33.501.
Please check.
Huawei: Thanks for your comments.
This contribution is exactly required. Because stage 2 and stage 3 on the encryption IE have different formulations. And the whole definitions are different. We in SA3 agreed to align with CT4. 
P.S. the Rel15/Rel16 implementation in the CT group will not be changed.
CMCC: Thanks for the clarification.
I agree that it is not align with CT4, but I still not convinced it should be updated for R-15. As I replied in 238 thread, we have a lot of inconsistency in historical release. But we don’t touch them as they are frozen. It should also be applied to R-15 as it is frozen for 2 years.
I’m not against the technical proposal, but please implement it in R-16 and/or R-17.
Huawei: Thanks for your reply.
This CR is really important in Rel15. Because the whole figure and procedure defined in SA3 are not align with CT4. Reader may be confused based on CT4 and SA3 procedure. The agreement in SA3 on this issue is achieved in the previous meeting.
You can assume this is FASMO issue, even though changes in CT4 is not required.
On the other hand, there is no compromised implement methods between SA3 and CT4.
Mavenir: Summary: This contribution can be approved after proposed modification.
Details: According to my stage 3 engineers, the updated example and the original one is not inline with CT4 specifications.
My proposal is to remove the example and to reference CT4 specification TS29.573 as this example is nothing but a stage 3 work and should not be captured in SA3 specification.
This way we avoid keep updating things in our specifications that do not belong to it.
Concrete proposal:
 1.	Remove the example Figure 13.2.4.2-1.
 2.	add a sentence to say the following, e.g., : “for the details of JSON representation of a reformatted HTTP message, please refer to TS29.573”
This comment is general and applicable to all Releases. If there is an objection to make any modification to Rel-15, then that can be excluded.
Ericsson: Revision r1 is fine. Revision r1 with the modifications proposed by Mavenir is also fine.
DOCOMO: Regarding your question about FASMO. The networks continue working. Only roaming between R15 networks making use of SEPPs will fail in case one SEPP implements CT4 spec, and the other implements SA3 spec. 
In my opinion that is FASMO (even though there is no R15 core network with roaming deployed at the moment). 
This kind of incompatibility doesn't also leave a good impression of the specification.
CMCC: It seems that email thread forks, so I would like to reply here to respond to DOCOMO’s question.
I have double checked this contribution, I agree with Alf’s observation about roaming case and there is no other choice to mitigate this. So I withdraw my objection on this contribution.
Mavenir: Mavenir proposal is for the original contribution and not r1.
If you are Okay with removing the Figure and replacing it with the statement and reference TS29.573, you should be okay with doing that on the original contribution too.
Just to make my position clear.
Huawei: @Mavenir,
I have no strong opinions on this point. Just to correct the misalignment statements.
Accordingly to the comments from Christine, the following statements really needs to be revised. That’s why I proposed r1 in the draft folder. If we only remove the figure and add a new statement, the following existing description will not match with the new statement in our SA3 internal.
What do you think?
Mavenir: Mavenir can live with r1 and removing the figure completely and adding the statement mentioned earlier. i.e., “
“for the details of JSON representation of a reformatted HTTP message, please refer to TS 29.573 [xx]”
Under references, we need to add the following as it is not there.
[xx]        3GP TS 29.573: "5G System; Public Land Mobile Network (PLMN) Interconnection".
Huawei: Thanks DOCoMO for the clarification.
Thanks CMCC for your comments on Rel15 CR, which remind us that changes to the frozen Rel15 and Rel16 should be very careful.
Now back to the details.
@Mavenir, I upload r2 in the draft folder, in which the figure is removed and the new statement and reference TS 29.573 are added.
If r2 is fine for us, I will update the related mirrors.
Ericsson: Thanks, r2 is fine. Minor comment that the new added reference is not shown in change marks.
Nokia: the reference will be fixed by 545.
Nokia: thanks for converging.
- Waiting for check by CT4
please note, the reference clause is not from Rel-15 version. There it stops at [72].
-545 will fix the reference anyway together with 74/75, so not sure if it needs to be doubled here. In any case, good to add a comment in the CR comment part, to be aligned with these other CRs.
Mavenir: Mavenir is fine with r2.
Nokia: -r2 okay by Nokia.
Huawei: Thanks for confirmation.
@Nokia, @Ericsson, Reference is already fixed in my owner storage. I will upload the fixed version.

S3-210383          Mirror: align the JSON format on encryption IE with CT4 in Rel16    Huawei, HiSilicon, Nokia, Nokia Shanghai Bell
cf. 382
Huawei: Please find the r1 in the draft folder.
383 is the mirror of 382. Hence all the changes 382r2 are implemented in 383r1.
Please check.
Ericsson: Thanks, r1 is fine. Same minor comments as for 382 (new added not shown as change marks).
Huawei: Thanks.
Change mark will be fixed before uploading.

S3-210384          Mirror: align the JSON format on encryption IE with CT4 in Rel17    Huawei, HiSilicon, Nokia, Nokia Shanghai Bell
cf. 382
Huawei: Please find the r1 in the draft folder.
384 is the mirror of 382. Hence all the changes 382r2 are implemented in 384r1.
Please check.
Ericsson: Thanks, r1 is fine. Same minor comments as for 382 (new added not shown as change marks).
Huawei: Thanks.
Change mark will be fixed before uploading

S3-210395          Clarification on PLMN ID verification in Rel15     Huawei, HiSilicon
Ericsson: Summary: proposal to not pursue this CR (and its mirror)
Thanks Bo for providing the CR. This topic has been discussed for several meeting now. There is work ongoing in CT4 that is relevant to this question. Therefore Ericsson proposes to wait for CT4 progress.
If I understand it correctly, disagreement with 395 also implies disagreement with the mirror, i.e. S3-210396.
Nokia: Thanks for the contribution. As I didn’t follow the relevant discussion in the previous meetings, I have a couple of questions for clarification regarding the added NOTEs:
Ÿ   NOTE X says the AUSF does not need to verify the serving network name based on the static authorization. It is not clear which element performs the static authorization as mentioned. Also, isn’t static authorization also a behavior of verifying the serving network name? 
Ÿ   NOTE Y says the SEPP can check the correctness of the serving network name with the remote PLMN ID included in the N32-f context as described in clause 5.9.3.2, on behalf of the AUSF. My understanding is that the SEPP is able to verify whether the sending SEPP is authorized to use the PLMN ID in the received N32 message, and it’s able to check the serving PLMN ID in the access token matches the remote PLMN ID in the N32 message. But I’m wondering how the SEPP could know about the expected serving network name, against which the serving/remote PLMN ID is compared. Where does the SEPP get the expected serving network name from?
Hope the above could be clarified. Thanks!
Huawei: @Ericsson. We all know that CT4 discussion focuses on the Rel17 requirement. However, the proposed two contributions would like to change the Rel15 and Rel16, to clarify the existing parameters can be used for the serving network name verification by the AUSF. Hence, SA3 and CT4 are not conflict. That’s why I propose these two contributions. I would like to know your opinions based on the above reply. From technical point of view, these changes are required.
@Nokia, Please find my reply in the below.
Ÿ   NOTE X says the AUSF does not need to verify the serving network name based on the static authorization. It is not clear which element performs the static authorization as mentioned. Also, isn’t static authorization also a behavior of verifying the serving network name? 
[Huawei] Static authorization is already adopted in the SBA topic, i.e. clause 13.3.0. It means that the authorization could be left based on its local policy. Therefore, if the AUSF and the SEAF are in the same PLMN, and the AUSF trust the SEAF, then serving network name verification can be implicitly success. Then, the verification is unnecessary.
[Nokia] Yes, I understand that static authorization was already defined in 33.501. I just hope the actors of authorization could be reflected clearly in the NOTE.  Also, as you said that the verification is implicitly done by static authorization, then “does not need to verify” is not accurate. As I said, static authorization based on local policy is also a behavior of verification.
Ÿ   NOTE Y says the SEPP can check the correctness of the serving network name with the remote PLMN ID included in the N32-f context as described in clause 5.9.3.2, on behalf of the AUSF. My understanding is that the SEPP is able to verify whether the sending SEPP is authorized to use the PLMN ID in the received N32 message, and it’s able to check the serving PLMN ID in the access token matches the remote PLMN ID in the N32 message. But I’m wondering how the SEPP could know about the expected serving network name, against which the serving/remote PLMN ID is compared. Where does the SEPP get the expected serving network name from?
[HW] there is a N32-f context established between cSEPP and pSEPP during the N32 connection establishment procedure, which including the remote PLMN ID (i.e. the cSEPP belongs, or the SEAF belongs). We can assume that the remote PLMN ID is the expected serving name. Then, the pSEPP could verify the remote PLMN ID with the serving network name.
[Nokia] I understand how the SEPP can verify the remote PLMN ID to ensure it is exactly the serving PLMN ID sending the message. But I’m wondering why we can assume that remote PLMN ID is the expected serving network name. They are two values in different formats. The format of serving network name is “Service Code : SN Id (PLMN ID)”. The SEPP can only verify half of the serving network name. If verifying SN ID is enough for the original purpose of verifying SN name, I’m wondering why people defined SN name which is different from SN ID.  And the same question applies to the non-roaming case in NOTE X.  I would appreciate if this could be clarified. Thanks!
Ericsson: Summary: tries to answer Huawei’s questions
Thanks for your comments. My point is that it is not a good idea to address Rel-15 and Rel-16 separately without knowing the solution for Rel-17. This is both for formal and technical reasons. The formal reason is that a Rel-15 CR would need to have a Rel-17 mirror, however such a Rel-17 mirror identical to the Rel-15 CR would not be acceptable. The technical reasons are that it is better to address the whole problem together, to make sure that Rel-15, Rel-16 and Rel-17 solutions are aligned and backwards compatibility between the solutions is discussed.
Regarding the technical content for Rel-15, there is the following Ericsson CR from the previous meeting:
| S3‑203144 | Verification of Serving Network Name in AUSF | Ericsson | CR | Agreement | Yes | Yes | not pursued
My understanding is that it is technically not too far from 395.
CMCC: I would like to raise a general challenge to all documents referring R-15 in AI#4.1. Is it a FASMO issue? 
I propose to not pursue this contribution. I don’t believe it is FASMO issue. No matter there is an issue, the network can work well with current specification.
This comment is only for R-15 document. Mirrors are not related.
What is more, PLMN ID verification can be seen as a behavior that AUSF shall perform. No matter it can be verified directly or indirectly. One reason that AUSF needs to do this is because AUSF will involve serving network name into the process of Kausf derivation. So it is not correct to cancel this feature on AUSF.
This comment is also applied to mirrors.
Mavenir: I agree with Ericsson. Let us wait for Release 17 fix in CT4 and then propagate that to SA3.
Huawei: The aim of this contribution is to clarify the requirement of the AUSF.
According to the following discussion, I can wait for the CT4 progress.
That is to say, this contribution can be noted.
And its mirror S3-210396 could be noted as well.
Thanks for all the discussion.

S3-210396          Clarification on PLMN ID verification in Rel16     Huawei, HiSilicon
cf. 395
 
S3-210545          resolving ed note on protection policy mismatch            NTT DOCOMO INC.
Nokia: propose to treat 545 as standalone, without mirrors, since the issue has been addressed by CT4 only from Rel-onwards.
CMCC: I would like to raise a general challenge to each documents referring R-15 in AI#4.1. Is it related to FASMO issue? 
I propose to not pursue this contribution. I don’t believe it is FASMO issue. Without this contribution, CT4 has already have detailed statement that won’t lead to mis-operation.
This comment is only for R-15 document. Mirrors are not related.
DOCOMO: How do you want to treat the editor's note, or do you propose to leave R15 33.501 in an unfinished state?
MCC: Just comments on the cover page of this CR and mirrors:
•	Revision marks on the cover page should be accepted.
•	Remove guideline comment on the date format.
•	Proposed change affects: mark Core network (?)
•	Release field should read “Rel-15” and not “R15”.
•	Clauses affected: clause 2 is missing.
DOCOMO: as Nokia suggested, there are no mirrors to this one any more, as the CT4 solution that this editor's note differ between R15 and R16.
If mirrors are required, it would mean changing the CR number and the CR type in 074 and 075. Please advise accordingly.
-r1 is available of 545 addressing your comments
And a more procedural question: can resolution of editor's notes be seen as FASMO? Otherwise the R15 editor's notes will remain for ever, giving an impression of incompleteness.
MCC: You mean a cat-F for Rel-15 only? This would raise questions on backward compatibility given that there are no mirrors. I see that editor’s note is the same for all Releases. You would keep it in Rel-16 and Rel-17 or replace it with different text? I would say that if the changes are a bit different but the nature of the change is the same (alignment with CT4) you can still justify the mirrors. I suggest to go ahead and consider them mirrors.
As for your question, it depends on the editor’s note, of course. If it was for Rel-9 you would probably get complaints, but Rel-15 is not too far behind and as you say we cannot leave open editor’s notes for years. It was left for a reason, and if it wasn’t important it shouldn’t have been added in the first place. I think we should still send it to SA and there we can see if they like it or not.
CMCC: With MCC’s guidance, I withdraw my objection on this contribution.

S3-210074          Error code details - Resolving ed note in 13.2.2.6            Nokia, Nokia Shanghai Bell
Nokia: Merge S3-210551 into this tdoc.
-r1 uploaded, taking account the updates to references in S3-210545, so, all is aligned. However, 0074 cannot be the mirror of 0545, since CT4 only started implementing related error codes in Rel-16.
Thus 0074/0075 treated as Cat F/A.
Huawei: The reference number in the second change should be [73], rather than [74].
If I am correct, the rev in the cover page should be “1”.
Nokia: -r2 uploaded correcting the reference.
Huawei: Huawei is fine with r2.
DOCOMO: depending on the outcome of the discussion on 545, we may have to update the coversheet to make 074 a mirror of 545 (as MCC suggested). I have no strong opinion on this.
Nokia: Sure. At least one easy task.
S3-210075          Error code details - Resolving ed note in 13.2.2.6            Nokia, Nokia Shanghai Bell
Nokia: -r1 uploaded, mirror of S3-210074-r1, which is  taking account the updates to references in S3-210545, so, all is aligned. However, 0074 cannot be the mirror of 0545, since CT4 only started implementing related error codes in Rel-16. 
Thus 0074/0075 treated as Cat F/A.
Huawei: The reference number in the second change should be [73], rather than [74].

S3-210551          resolving ed note on protection policy mismatch            NTT DOCOMO INC. 
Merged in 074
Nokia: Propose to merge this tdoc into S3-210074, or just note the doc. 
As already discussed offline, work on updating S3-210074, handling the same issue, but as cat F.
DOCOMO: ok to merge

S3-210552          resolving ed note on protection policy mismatch            NTT DOCOMO INC.
Merged in 075
Nokia: Propose to merge this tdoc into S3-210075, or just note the doc.
DOCOMO: ok to merge.

Mobility
S3-210397          Discussion paper on TAU reject issue during MME handover              Huawei, HiSilicon
Ericsson: Ericsson has concerns about the issue mentioned in the discussion paper. 
This problem seems to be rare. It should have happened in 4G.  The recommendation in 4G is to run a primary authentication for the MME-1 to make the mapped context native. 
For interworking with 5G we could propose the same behaviour i.e. the MME-1 runs a primary authentication to make the mapped context into native, or?.
IN the discussion paper it is stated “Observation 2: TAU will fail caused by the misalignment on the EPS security context (i.e. mapped VS native) after handover from MME1 to MME2”. Can you please elaborate why the TAU will fail at MME-2 ?
S3-210398          LS on TAU reject issue during MME handover    Huawei, HiSilicon
Ericsson: Ericsson has concerns about the issue mentioned in the discussion paper (S3-210397). I repeat the comments to this contribution as well. 
This problem seems to be rare. It should have happened in 4G.  The recommendation in 4G is to run a primary authentication for the MME-1 to make the mapped context native. 
For interworking with 5G we could propose the same behaviour i.e. the MME-1 runs a primary authentication to make the mapped context into native, or?. 
The LS says that 
When a fast moving UE attaches to 5GS, then moves to MME-1 in EPS and shortly thereafter moves to MME-2 the TAU request message sent from the UE to the MME-2 will always fail caused by the misalignment on the EPS security context, i.e. the security context stored in the UE is the mapped type, and the security context stored in the MME-2 is the native type
Can you please elaborate why the TAU will always fail at MME-2 ?
Nokia: Summary: Agree with the intent of the LS, but content needs to change.
“SA3 has discussed this issue, and identified that this issue can be easily avoided by including the TSC part indicating the mapped or native security context during the MME-1 to MME-2 reallocation as defined in clause 7.2.8.4.3 of TS 33.401. Therefore, it is required that CT4 should align with SA3 in this case. “
Above text needs reformulation. TS 33.401 7.2.8.4.3 doesn’t mention anything MME re-allocation, neither native contexts. Not sure how to align with 33.401, The solution should be left to CT4.
Ericsson: I still don’t understand in the first part of the LS, why would the TAU request message from the UE to MME-2 fails. 
… 
When a fast moving UE attaches to 5GS, then moves to MME-1 in EPS and shortly thereafter moves to MME-2 the TAU request message sent from the UE to the MME-2 will always fail caused by the misalignment on the EPS security context, i.e. the security context stored in the UE is the mapped type, and the security context stored in the MME-2 is the native type
Nokia: Actually I am surprised to see such a failure from the field, particularly when LTE have been deployed for many years. But please see the discussion in SA3#101-e on this topic, S3-203071.
I do not fully agree with the statement that TAU reject always fails, actually we are not seeing such failures in most networks !
In TS24.301 5.5.5 “If the UE has a current EPS security context, the UE shall include the eKSI (either KSIASME or KSISGSN) in the NAS Key Set Identifier IE in the TRACKING AREA UPDATE REQUEST message. Otherwise, the UE shall set the NAS Key Set Identifier IE to the value "no key is available". If the UE has a current EPS security context, the UE shall integrity protect the TRACKING AREA UPDATE REQUEST message with the current EPS security context. Otherwise the UE shall not integrity protect the TRACKING AREA UPDATE REQUEST message. The UE shall set associated GUTI in the Old GUTI IE. “ The eKSI will contain the ‘type of security context (TSC) flag’ this will indicate mapped or native contexts.
In the scenario described here, MME2 has anyway only one context, without a TSC flag. I suspect smart implementations of MME is taking this as mapped context or may be trying both mapped and native, and thus TAU succeeds. But in any case, I do not know there is any good reason in specifications to omit the TSC from MME1 to MME2.
Huawei: Thanks for all the discussion.
Let’s discuss this issue in this email thread.
Please find r1 in the draft folder with new formulation suggested by Suresh.
https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_102e/Inbox/Drafts/draft_S3-210398-r1.docx
@Ericsson I am not sure whether it is a rare case. But actually it happens in reality. We would like to solve it fundamentally, to avoid any potential serious issues in the future.

Let’s get back to the issue. I just copy the figure in the S3-210397 here for clarification.
After the handover from 5G to 4G, both UE and MME1 stores the mapped EPS security context, as this belongs to the interworking from 5G to 4G.
•	UE knows that this mapped. MME1 also knows that this is mapped according to the connection between MME1 and AMF, i.e. Sender F-TEID.
Then, if the handover happens in LTE network, i.e. from MME1 to MME2, MME1 will send eKSI without TSC part to the MME2, where the TSC is used to identify native or mapped.
•	UE still stores the mapped security context. MME2 assumes that the security context from MME1 is native, as MME1 is a native EPS NF.
•	Here is the issue. The misalignment happens between UE and MME2 after handover from MME1 and MME2.
Then, after receiving the last TAU request with eKSI from UE, where the eKSI includes the TSC part which denotes the mapped security context, then MME2 could not find any mapped security in the UE context.
In this case, the MME2 can not verify the integrity of the TAU request. The TAU procedure will always failure.
That’s why I stated that TAU request message sent from the UE to the MME-2 will always fail.
.  The recommendation in 4G is to run a primary authentication for the MME-1 to make the mapped context native.
Running a primary authentication for the MME1 is not a good choice, as we have to update the clause 9.3 of TS 33.401 to including 5G here, i.e. after a handover from GERAN or UTRAN or NG-RAN into E-UTRAN.
9.3        Recommendations on AKA at IRAT-mobility to E-UTRAN
After a handover from GERAN or UTRAN into E-UTRAN, it is strongly recommended to run an AKA and perform a key change on-the-fly of the entire key hierarchy as soon as possible after the handover if there is no native security context in E-UTRAN.
Changing the existing TS 33.401 may not be acceptable in SA3. Meanwhile, the solution is not getting this issue done forever. For example, do we need to update this clause again if 6G is coming.  
@Nokia,
Please find r1. I tried to reuse the existing formulation in the TS 33.401. And asking CT4 to make the corresponding specification.
I suspect smart implementations of MME is taking this as mapped context or may be trying both mapped and native, and thus TAU succeeds
From security point of view, this would not be the best choice, which opens a door for the MME to use either native or mapped to check. Meanwhile, this potential solutions needs further evaluation.
I check my CT4 guys. They are still able to revise their spec to kill this issue forever. You can check it also.
Hope the changes could address your concerns.
Nokia: I am fine with -r1, thanks for the update.
Huawei: Thanks for the confirmation.
Ericsson: Apologies for the late comments. 
I am not sure this issue is FASMO. Shouldn’t we indicate the issue to CT4 and ask them to fix it if it is FASMO. Now we are also proposing a solution to them. Maybe they can do the fix themselves if they see a need.
Huawei: Thanks for your reply.
Please find r2 in the draft folder with the following change:
Therefore, it is kindly request CT4 to take the above information into account, and fix the above security issue.
Considering the limited time, you can provide a concrete proposal if needed. Thanks.
Ericsson: Let’s take the issue in the next meeting because I don’t fully agree with the formulation of r2. I don’t believe it is FASMO for Rel-15 onwards and maybe CT4 also has a say in this, if they are willing to change this or not.

Editorial
S3-210339          Typo correction in clause 6.9.9.4             Xidian University
CMCC: I would like to raise a general challenge to all documents referring R-15 in AI#4.1. Is it a FASMO issue? 
I propose to not pursue this contribution. I don’t believe it is FASMO issue. Without this contribution, the network can still work well with current specification.
This comment is only for R-15 document. Mirrors are not related.

S3-210532          Typo correction in clause 6.9.4.4             Xidian University

S3-210550          Typo correction in clause 6.9.4.4             Xidian University
 
IETF
S3-210515          Updated proposal to introduce draft-ietf-emu-rfc5448bis to TS 33.501  Ericsson
Ericsson: With this email I would like to solicit comments on the contribution.
As indicated in the contribution, we have tried to take all received comments in the last meeting into account.
To recap, the planned flow of events with this internet-draft if as follows:
At SA3#102e
- SA3 companies review the internet draft and provide comments, if any
After SA3#102e 
- Authors of the internet draft implement the comments in the internet draft, if any
- Authors indicate to the IETF that the internet draft can be published as RFC
- IETF publishes the internet draft as RFC
At SA3#102e-bis
- Authors bring a CR to SA3 to change the reference to RFC 5448 to the new RFC
 Nokia: Changed missed in figures,
1) Figure 6.2.2-1: Key distribution and key derivation scheme for 5G for network nodes,
2) Figure 6.2.2-2: Key distribution and key derivation scheme for 5G for the UE,
Both figures shows RFC5448, that should change to RFC TBD?
Huawei (with Ericsson reply inline): Thanks for bringing this contribution.
In general, I agree this is a meaningful action to update the RFC documents for 3GPP reference. However, what I would like to know whether it means we have to evaluate the impacts brought by the update of the draft RFC document from now?
Ericsson: The intention is that the update of the RFC would have no impact on existing implementations which are based on RFC 5448. You are of course welcome to check that. The contribution has a link to the diff file which shows the difference between the internet draft and RFC 5448 to make the checking easier.
If we identify some impact on performance or anything else caused of the RFC, can we request the draft RFC to modify accordingly as soon as possible?
Ericsson: Yes, this is one of the intentions for SA3 to review the internet draft.
Moreover, when will the RFC become an standard specification?
Ericsson: The IETF has reviewed the internet draft and it is basically ready for publication. The authors of the internet draft have indicated to the IETF that it should not be published before SA3 is also happy with the draft. And that is the reason for our contribution. The internet draft, as well as the original RFC 5448, will be an informational RFC rather than a standards track RFC.
I just would like to avoid the backward compatibility as much as possible from Huawei point of view.
Ericsson: This is also our intention.
Ericsson: @ All
If I recall right, the following was discussed in yesterday’s SA3 conference call:
- the plan is to have a conference call between interested 3GPP and IETF participants after the SA3#102e and before the next  SA3 meeting to discuss the internet draft. Alf volunteered to arrange it. Any suggestions for a date?
- It was suggested that there should be a DL for comments on the internet draft so that any possible comments can be discussed in the conf call. A date is needed for this as well. I would suggest it to be two days before the conference call. 
- A new version of the internet draft will be produced, if needed.
- When SA3 is happy with the content of the internet draft, SA3 can send an LS to the IETF or alternatively authors of the internet draft can indicate this to the IETF
- IETF publishes the internet draft as RFC.
- a CR will be brought to an SA3 meeting (likely May) to change the reference in TS 33.501 to the new RFC.
@ Nokia
Thanks. Yes, those should refer also to the new RFC TBD.
Mavenir: What I was trying to say and our chair cut me off because of lack of time. 😊
I agree with DOCOMO proposal; however, in order to make this effort fruitful, SA3 should specify a specific date for SA3 feedback.
After that date passes, then SA3 should hold a meeting with IETF.
This mechanism will ensure that we can conclude on this by the time of the CC with IETF or a little after (i.e., IETF will have a clear indication/information what is need to finalize the publishing of this draft)
Nokia: For the call to discuss the ietf draft, next SA3 meeting has only studies in the agenda, so it may be better to have the meeting after SA3#102-e Bis(Mar1-5) and before SA3#103-e (May17-28).
DOCOMO: this email is mainly for bookkeeping:
Proposal: 
note this document 
Actions coming out of this: 
Chair to initiate organizing a joint conference call with appropriate IETF WG
Rapporteur can then arrange date etc. 
SA3 will send an LS to IETF WG from May meeting, if consensus