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.

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. If DTLS with AKMA is used, the MSGin5G Client and the MSGin5G Server establish the DTLS session following the procedures defined in Annex C of TS 33.535. When MSGin5G service is used with SEAL, the application architecture described in TS 23.554 is followed. In this case, authorization of the MSGin5G UE by the MSGin5G server is performed by validating the association between the UE service ID and UE ID (SUPI/GPSI). The UE service ID is acquired via the MSGin5G registration request, as specified in TS 23.554. The Configuration Management server or MSGin5G Configuration Function maintains association of the assigned UE service ID with the UE ID. The MSGin5G server retrieves the association from the Configuration Management server or MSGin5G Configuration Function using the UE ID received from the AAnF and verifies whether the UE service ID received in the registration request message is associated with the UE ID in the retrieved association information. For constrained UE, the GatewayUE shall perform authentication and authorization on behalf of the constrained UE with MSgin5G Server based on AKMA as specified above.

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. If DTLS with AKMA is used, the MSGin5G Client and the MSGin5G Server establish the DTLS session following the procedures defined in Annex C of TS 33.535. For the data protection over MSGin5G-3 interface between MSGin5G Server and Application Server, if the Application Server is inside the operator domain, the transport security protection on SBI interface shall be reused as specified in clause 13. If the Application Server is outside the operator domain, the Application Server shall connect to the MSGin5G Server via NEF, clause 12.3 in the present document is applicable with the Application Server taking the role of the AF. For MSGin5G-2, MSGin5G-4, MSGin5G-7 and MSGin5G-8 interfaces, TLS shall be used for transport protection unless network security is provided by other means.

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.

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.

For MSGin5G UEs in bulk, the MSGin5G Gateway UE shall perform authentication and authorization on behalf of the MSGin5G UEs behind the MSGin5G Gateway UE with MSGin5G Server based on AKMA as specified above in clause Y.2. The authentication and authorization between the MSGin5G UEs behind the MSGin5G Gateway UE and the MSGin5G Gateway UE shall be based on the security procedures of the Unicast mode 5G ProSe Direct Communication specified in TS 33.503. For Non-MSGin5G UEs bulk registration/de-registration, the Message Gateway performs the authentication and authorization on behalf of the Non-MSGin5G UE, The authentication and authorization between Message Gateway and the MSGin5G Server as specified above in clause Y.5 also applies. In some scenarios, if the Message Gateway is trusted by the MSGin5G Server, then the non-MSGin5G UEs are trusted by the MSGin5G Server after the authentication and authorization between the non-MSGin5G UE and the Message Gateway, without the need of authentication between the Message Gateway and the MSGin5G Server.