Content for TS 33.180 Word version: 17.8.0

1… 4… 4.3.4 4.3.5 5… 5.1.3 5.1.4… 5.2… 5.2.3 5.2.4 5.2.5 5.2.6… 5.3… 5.4… 6… 7… 7.3… 8… 9… 9.4… 10… A… B… C… D… E… F… J… L…

5.1 User authentication and authorization 5.1.1 General 5.1.2 User authentication
...

5 Common mission critical security framework p. 26

5.1 User authentication and authorization p. 26

5.1.1 General p. 26

The generic steps for MCX user authentication and authorisation is shown in Figure 5.1.1-1.

Copy of original 3GPP image for 3GPP TS 33.180, Fig. 5.1.1-1: MCX authentication and authorisation

Figure 5.1.1-1: MCX authentication and authorisation
(⇒ copy of original 3GPP image)

At UE power-on, the MCX UE performs EPS UE authentication as specified in TS 33.401 or 5GS UE authentication as specified in TS 33.501, depending on the system. The MCX UE then performs the following steps to complete authentication of the user, authorisation of the user, MCX service registration, and identity binding between signalling layer identities and the MC service ID(s).

Step A.

MCX user authentication.

Step B.

SIP Registration and Authentication.

Step C.

MCX Service Authorization.

These procedures are described in more detail in subsequent clauses.

Steps A and B may be performed in either order or in parallel. For scenarios where this order has an impact on the identity bindings between signalling layer identities and the MC service ID(s), a re-registration (Step B) to the SIP Core may be performed to update the registered signalling layer identity.

If an MCX UE completes SIP registration in Step B prior to performing MCX user authentication in Step A and MCX user service authorization as part of Step C, the MCX UE shall be able to enter a 'limited service' state. In this limited state, where the MCX user is not yet authorized with the MCX service, the MCX UE shall be able to use limited MCX services (e.g. an anonymous MCX emergency communication). The MCX Server is informed of the registration of the MC UE with the SIP core though Step B-2.

Additionally, an HTTP-1 authentication mechanism is used.

5.1.2 User authentication p. 27

5.1.2.1 Identity management functional model p. 27

The mission critical Identity Management functional model is shown in Figure 5.1.2.1-1 and consists of the identity management server located in the MCX common services core and the identity management client located in the MCX UE. The IdM server and the IdM client in the MCX UE establish the foundation for MCX user authentication and user authorization.

Note that use of the term "IdM client" in this document is generically used to represent any identity management service endpoint within an MC UE that communicates with the IdM Server (authorization endpoint or token endpoint) over the CSC-1 reference point for MC identity management services. It does not imply any specific client implementation of the client-side identity management service.

The CSC-1 reference point, between the IdM client in the UE and the Identity Management server, provides the interface for user authentication. CSC-1 is a direct HTTP interface between the IdM client in the UE and the IdM server and shall support OpenID Connect 1.0 ([19], [20] and [21]).

The OpenID Connect profile for MCX shall be implemented as defined in Annex B. MCX user authentication, MCX user service authorization, OpenID Connect 1.0, and the OpenID Connect profile for MCX shall form the basis of the identity management architecture.

In alignment with the OpenID Connect 1.0 [21] and OAuth 2.0 standards [19] and [20], CSC-1 shall consist of two identity management interfaces; the authorization endpoint and the token endpoint. These endpoints are separate and independent from each other, requiring separate and independent IP addressing. The authorization endpoint server and the token endpoint server may be collectively referred to as the IdM server in this document.

The HTTP connection between the Identity Management client and the Identity management server shall be protected using HTTPS.

Copy of original 3GPP image for 3GPP TS 33.180, Fig. 5.1.2.1-1: Functional Model for MC Identity Management

Figure 5.1.2.1-1: Functional Model for MC Identity Management
(⇒ copy of original 3GPP image)

To support MCX user authentication, the IdM server (IdMS) shall be provisioned with the user's MC ID and MC service IDs (the MC service ID may be the same as the MC ID). A mapping between the MC ID and MC service ID(s) shall be created and maintained in the IdMS. When an MCX user wishes to authenticate with the MCX system, the MC ID and credentials are provided via the UE IdM client to the IdMS (note that the primary authentication method used to obtain the MC ID and credentials is out of scope of the present document). The IdMS receives and verifies the MC ID and credentials, and if valid returns an ID token, refresh token, and access token to the UE IdM client specific to the credentials. The MCX client learns the user's MC service ID(s) from the ID token. Table 5.1.2.1-1 shows the MCX tokens and their usage.

Table 5.1.2.1-1: MC tokens

Token Type	Consumer of the Token	Description (See Annex B for details)
ID token	UE client(s)	Contains the MC service ID for at least one authorised service (MCPTT ID, MCVideo ID, MCData ID). Also may contain other info related to the user that is useful to the client.
Access token	KMS, MCPTT server, etc. (Resource Server)	Short-lived token (definable in the IdMS) that conveys the user's identity. This token contains the MC service ID for at least one authorised service (MCPTT ID, MCVideo ID, MCData ID).
Refresh token	IdM server (Authorization Server)	Allows UE to obtain a new access token without forcing user to log in again.
Security token	Partner IdM server (Authorisation server)	Short-lived token (definable in the IdMS) that conveys the user's identity to an Identity management server in a partner MC domain. User access to services within the partner domain are based on the validation of this token.

In support of MCX user authorization, the access token(s) obtained during user authentication is used to gain MCX services for the user. MCX user service authorisation is defined in clause 5.1.3.

To support the MCX service identity functional model, the MC service ID(s) shall be:

Provisioned into the IdM database and mapped to MC IDs.
Provisioned into the KMS and mapped to identity associated keys.
Provisioned into the MCX user database and mapped to a user profile; and
Provisioned into the GMS(s) and mapped to Group IDs.

Further details of the user authorization architecture are found in clause 5.1.3.

5.1.2.2 User authentication framework p. 28

The framework utilises the CSC-1 reference point as depicted in Figure 5.1.2.2-1.

Copy of original 3GPP image for 3GPP TS 33.180, Fig. 5.1.2.2-1: MCX User Authentication Framework

Figure 5.1.2.2-1: MCX User Authentication Framework
(⇒ copy of original 3GPP image)

The User Authentication procedure in Step A of Figure 5.1.1-1 is further detailed into 3 sub steps that comprise the MCX user authentication framework:

Step A-1.

Establish a secure tunnel between the MCX UE and Identity Management (IdM) server. Subsequent steps make use of this tunnel.

Step A-2.

Perform the User Authentication Process (User proves their identity).

Step A-3.

Deliver the credential(s) that uniquely identifies the MCX user to the IdM client.

Following step A-3, the MCX client uses the credential(s) obtained from step A-3 to perform MCX user service authorization as per procedure C in Figure 5.1.1-1.

The framework supporting steps A-2 and A-3 shall be implemented using OpenID Connect 1.0 ([19], [20] and [21]).

5.1.2.3 OpenID Connect (OIDC) p. 29

5.1.2.3.1 General p. 29

Figure 5.1.2.3.1-1 describes the MCX User Authentication Framework using the OpenID Connect protocol. Specifically, it describes the steps by which an MCX user authenticates to the Identity Management server (IdMS), resulting in a set of credentials delivered to the UE uniquely identifying the MC service ID(s). The means by which these credentials are sent from the UE to the MCX services are described in clause 5.1.3. The authentication framework supports extensible user authentication solutions based on the MCX service provider policy (shown in step 3), with username/password-based user authentication as a mandatory supported method. Other user authentication methods in step 3 (e.g. biometrics, secureID, etc.) are possible but not defined here. A detailed OpenID Connect flow can be found in Annex C.

Copy of original 3GPP image for 3GPP TS 33.180, Fig. 5.1.2.3.1-1: OpenID Connect (OIDC) flow supporting MCX user authentication

Figure 5.1.2.3.1-1: OpenID Connect (OIDC) flow supporting MCX user authentication
(⇒ copy of original 3GPP image)

Step 1.

UE establishes a secure tunnel with the Identity Management server (IdMS).

Step 2.

UE sends an OpenID Connect Authentication Request to the IdMS. The request may contain an indication of authentication methods supported by the UE.

Step 3.

User Authentication is performed.

Step 4.

IdMS sends an OpenID Connect Authentication Response to the UE containing an authorization code.

Step 5.

UE sends an OpenID Connect Token Request to the IdMS, passing the authorization code.

Step 6.

IdMS sends an OpenID Connect Token Response to the UE containing an ID token and an access token (each which uniquely identify the user of the MCX service). The ID token is consumed by the UE to personalize the MCX client for the MCX user, and the access token is used by the UE to communicate the identity of the MCX user to the MCX server(s).

5.1.2.3.2 User authentication example using username/password p. 30

Figure 5.1.2.3.2-1 shows the OIDC flow when Username/Password is used as the user authentication method.

Copy of original 3GPP image for 3GPP TS 33.180, Fig. 5.1.2.3.2-1: OpenID Connect (OIDC) Example Using Username/Password

Figure 5.1.2.3.2-1: OpenID Connect (OIDC) Example Using Username/Password
(⇒ copy of original 3GPP image)