Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  17.4.1

Top   Top   Up   Prev   None
1…   4…   5…   6…   6.1.3…   6.1.4   6.2…   6.2.2…   6.3…   6.5…   6.7…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7A.2.3…   7B…   8…   9…   10…   11…   13…   13.2.2…   13.2.4   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   I…   J…   K…   O…   P…   S…   U…   X…   Y…

 

Y (Normative)  Security aspects of the Message Service for MIoT over the 5G System (MSGin5G) |R17|Word‑p. 276

Y.1  GeneralWord‑p. 276

This Annex specifies the security aspects of Message Service for MIoT over the 5G System (MSGin5G). The general features of MSGin5G are described in TS 23.554, TS 22.262.

Y.2  Authentication and authorization between MSGin5G client and MSGin5G ServerWord‑p. 276

The Authentication and authorization between MSGin5G Client and MSGin5G Server shall be based on AKMA, which is specified in TS 33.535. Before initiating communication with MSGin5G Server, the UE needs to have performed primary authentication and registered with the 5GC, resulting in the successful generation of KAKMA and A-KID at both MSGin5G Client and the 5GC as specified in clause 6.1 of TS 33.535.
Once the UE is registered in 5GC, the MSGin5G Client in the UE and the MSGin5G Server may use TLS for authentication as specified in Annex B of TS 33.535 with the MSGin5G Server taking the role of AKMA AF.
Methods other than TLS with AKMA may be used for authentication between the MSGin5G Client and MSGin5G Server, depending on the Ua* protocols.
Up

Y.3  Transport security protection for MSGin5G interfacesWord‑p. 276

The MSGin5G-1 interface may be protected by TLS based on KAF established by AKMA as specified in TS 33.535. The MSGin5G Client and the MSGin5G Server establish the TLS session following the procedures defined in Annex B of TS 33.535.
The MSGin5G-1 interface may be protected using mechanisms other than TLS with AKMA, depending on the Ua* protocols.
For the data protection over MSGin5G-3 interface between MSGin5G Server and Application Server, the transport security protection on SBI interface shall be reused as specified in clause 13. If the Application Server supports CAPIF capability, the existing interface security protection mechanisms for CAPIF shall be reused. TLS can be used for confidentiality, integrity and replay protection.
For MSGin5G-2 and MSGin5G-4 interfaces, TLS shall be used for transport protection unless network security is provided by other means.
Up

Y.4  Authentication and Authorization between Application Server and MSGin5G ServerWord‑p. 276

The authentication and authorization between Application Server and MSGin5G is based on the transport security protection. TLS should be used as specified in TS 33.210.

Y.5  Authentication and Authorization between message Gateway and MSGin5G ServerWord‑p. 277

The authentication and authorization between Message Gateway and the MSGin5G Server can reuse the authentication and authorization between network functions in clause 13.3.2 in this document.
In direct communication, authentication between message gateway and MSGin5GServer shall use one of the following methods:
  • If the PLMN uses protection at the transport layer as described in clause 13.1, authentication provided by the transport layer protection solution shall be used for authentication between message gateway and MSGin5GServer.
  • If the PLMN does not use protection at the transport layer, authentication between message gateway and MSGin5GServer may be implicit by NDS/IP or physical security.
If the PLMN uses token-based authorization, the network shall use protection at the transport layer as described in clause 13.1.
In indirect communication scenarios, clause 13.3.2 in this document also applies.
Up

$  Change historyWord‑p. 278


Up   Top