5.1 User authentication and authorization

33.1803GPPRelease 17Security of the Mission Critical (MC) serviceTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1.1 General

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

Figure 5.1.1-1: MCX authentication and authorisation

At UE power-on, the MCX UE performs EPS UE authentication as specified in TS 33.401 [14] or 5GS UE authentication as specified in TS 33.501 [55], 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).

– A: MCX user authentication.

– B: SIP Registration and Authentication.

– 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.

NOTE: Mechanisms for confidentiality and integrity protection (not defined in this clause) may be combined only with certain authentication procedures.

5.1.2 User authentication

5.1.2.1 Identity management functional model

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.

Figure 5.1.2.1-1: Functional Model for MC Identity Management

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

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

Figure 5.1.2.2-1: MCX User Authentication Framework

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:

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

– A-2 – Perform the User Authentication Process (User proves their identity).

– 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]).

NOTE: MCX service authorization in step C of Figure 5.1.1-1 is outside the scope of the User Authentication framework.

5.1.2.3 OpenID Connect (OIDC)

5.1.2.3.1 General

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.

Figure 5.1.2.3.1-1: OpenID Connect (OIDC) flow supporting MCX user authentication

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.

NOTE: The primary credentials for user authentication (e.g. biometrics, secureID, OTP, username/password) are based on MCX service provider policy. The method chosen by the MCX service provider is neither defined nor limited by the present document.

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

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

Figure 5.1.2.3.2-1: OpenID Connect (OIDC) Example Using Username/Password

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 3a: IdMS sends an HTML form to UE prompting the user for their username & password.

Step 3b: UE sends the username & password (as provided by the user) to the IdMS.

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.

5.1.3 MCX user service authorisation

5.1.3.1 General

This clause expands on the MCX user service authorization step shown in figure 5.1.1-1 step C.

MCX User Service Authorization is the function that validates whether or not a MCX user has the authority to access certain MCX services. In order to gain access to MCX services, the MCX client in the UE presents an access token (acquired during user authentication as described in subclause 5.1.2) to each service of interest (i.e. Key Management, MCX server, Configuration Management, Group Management, etc.). If the access token is valid, then the user is granted the use of that service. Figure 5.1.3.1-1 shows the flow for user authorization which covers key management authorization, MCX user service authorization, configuration management authorization, and group management authorization.

NOTE: All HTTP traffic between the UE and HTTP proxy, and all HTTP traffic between the UE and KMS (if not going through the HTTP proxy) is protected using HTTPS.

For key management authorization, the KM client in the UE presents an access token to the KMS over HTTP. The access token shall be scoped for key management services as defined in annex B.4.2.2. The KMS validates the access token and if successful, provides one or more sets of user specific key material back to the UE KM client based on the MC service ID(s) present in the access token (MCPTT ID, MCVideo ID and/or MCData ID). User specific key material includes identity based key information for media and signalling protection. If an interworking key management record (InterKMRec) exists and is associated to the requesting MC service ID (see clause 11.2.3), the KMS shall also provide the InterKMRec. This key management authorisation may be repeated for each KM service the user is authorised to use (MCPTT, MCVideo, MCData). In order to secure the transfer of user specific key material from the KMS to the KM client when using the TrK and InK, the KM client includes the TrK-ID and the InK-ID in the key management authorization request.

For MCPTT user service authorization, the MCPTT client in the UE presents an access token to the MCPTT server over SIP. The access token shall be scoped for MCPTT services as defined in annex B.4.2.2. The MCPTT server validates the access token and if successful, authorizes the user for full MCPTT services and sends an acknowledgement back to the MCPTT client. The MCPTT server then maps and maintains the IMPU to MCPTT ID association. The MCPTT ID to IMPU association shall only be known to the application layer. The SIP message used to convey the access token from the MCPTT client to the MCPTT server may be either a SIP REGISTER or SIP PUBLISH message.

For MCVideo service authorization, the MCVideo client in the UE presents an access token to the MCVideo server over SIP. The access token shall be scoped for MCVideo services as defined in annex B.4.2.2. The MCVideo server validates the access token and if successful, authorizes the user for full MCVideo services and sends an acknowledgement back to the MCVideo client. The MCVideo server then maps and maintains the IMPU to MCVideo ID association. The MCVideo ID to IMPU association shall only be known to the application layer. The SIP message used to convey the access token from the MCVideo client to the MCVideo server may be either a SIP REGISTER or SIP PUBLISH message.

For MCData user service authorization, the MCData client in the UE presents an access token to the MCData server over SIP. The access token shall be scoped for MCData services as defined in annex B.4.2.2. The MCData server validates the access token and if successful, authorizes the user for full MCData services and sends an acknowledgement back to the MCData client. The MCData server then maps and maintains the IMPU to MCData ID association. The MCData ID to IMPU association shall only be known to the application layer. The SIP message used to convey the access token from the MCData client to the MCData server may be either a SIP REGISTER or SIP PUBLISH message.

The UE can now perform configuration management authorization and download the user profile for the service(s) (MCPTT, MCVideo, MCData). Following the flow described in subclause 10.1.4.3 of 3GPP TS 23.280 [36] "MC service user obtains the MC service user profile(s) from the network", the Configuration Management (CM) client in the UE sends an access token in the user profile query to the Configuration Management server over HTTP. The access token shall be scoped for configuration management services as defined in annex B.4.2.2. The CM server receives the request and validates the access token, and if valid, the CM server uses the identity from the access token (MCPTT ID, MCVideo ID, MCData ID) to obtain the user profile from the MCX user database. The CM server then sends the user profile back to the CM client over HTTP. This configuration management authorisation may be repeated for each CM service the user is authorised to use (MCPTT, MCVideo, MCData).

Upon receiving each user profile, the Group Management (GM) client in the UE can now perform group management authorization. The GM client obtains the user’s group membership information from the user profile, and following the flow shown in clause 10.1.5.2 of 3GPP TS 23.280 [36] "Retrieve group configurations at the group management client", the Group Management (GM) client in the UE sends an access token in the Get group configuration request to the host GM server of the group membership over HTTP. The access token shall be scoped for group management services as defined in annex B.4.2.2. The GM server validates the access token, and if valid, completes the flow. As part of group management authorization, group key information is provided as per subclause 5.7 of the present document. This group management authorisation may be repeated for each GM service the user is authorised to use (MCPTT, MCVideo, MCData).

For MC UEs that support mission critical location services, authorization is accomplished by including an access token in each location message (i.e. location information report, location reporting trigger, etc.) sent by the location management client to the location management server. The access token shall be scoped for location management services as defined in annex B.4.2.2. The location management server validates the access token and (if successful) processes the message (e.g. accepts and stores the location information report). If an access token cannot be validated, local policy may dictate an action to be taken within the location management server with regards to the received location message (e.g. the local policy may require storage of the location information report as an emergency provision).

Figure 5.1.3.1-1: MCX user service authorization

The user authorization procedure in Step C of Figure 5.1.1-1 is further detailed into 5 sub steps that comprise the MCX user service authorization process:

Step C-1a: If not already done, establish a secure HTTP tunnel using HTTPS between the MCX UE and MCX proxy server. Subsequent HTTP messaging makes use of this tunnel .

Step C-1b: When required by the MCX system, establish a secure HTTP tunnel using HTTPS between the MCX KM client and the KMS. When supported, subsequent HTTP messaging between the MCX KM client and the KMS makes use of this tunnel in lieu of the tunnel set up in Step C-1a.

Step C-2: The KM client in the MCX UE presents an access token to the KMS over HTTP. The KMS authorizes the user for key management services based upon the MC service ID(s) provided and replies to the client with identity specific key information. This step may be repeated to authorise the user with additional KM services (MCPTT, MCVideo, MCData) as necessary.

Step C-3: The MCX client in the UE presents an access token to the MCX server over SIP as defined in clause 5.1.3.2 of the present document. This step may be repeated to authorise the user with additional MCX services (MCPTT, MCVideo, MCData) as necessary.

Step C-4: The CM client in the UE follows the "MCX user obtains the user profile (UE initiated)" flow from clause 10.1.4.3 of 3GPP TS 23.280 [36], presenting an access token in the Get MCX user profile request over HTTP. If the token is valid, then the CM server authorizes the user for configuration management services. Completion of this step results in the CM server providing the user’s profile to the CM client. This step may be repeated as necessary to obtain the user profile for additional services (MCPTT, MCVideo, or MCData).

Step C-5: The GM client in the UE follows the "Retrieve group configurations at the group management client" flow as shown in clause 10.1.5.2 of 3GPP TS 23.280 [36], presenting an access token in the Get group configuration request over HTTP. If the token is valid, the GMS authorizes the user for group management services. Completion of this step results in the GMS sending the user’s group policy information and group key information to the GM client. This step may be repeated to authorise the user for additional group services (MCPTT, MCVideo, MCData) as necessary.

5.1.3.2 MCX user service authorization with MCX Server

5.1.3.2.1 General

Depending on implementation, MCX user service authorization may be performed by sending the access token to the MCX server over the SIP-1 and SIP-2 reference points using either a SIP REGISTER message or a SIP PUBLISH message. Clause 5.1.3.2.2 describes how to use the SIP REGISTER message to transport the access token to the MCX server and clause 5.1.3.2.3 describes how to use the SIP PUBLISH message to transport the access token to the MCX server.

During initial SIP registration, the SIP REGISTER message shall not be delayed for lack of an access token. If an access token is not available then SIP registration shall proceed without the inclusion of the access token and the access token shall be transmitted to the MCX server as per Step C-3 in figure 5.1.3.1-1.

If an access token is available before SIP registration, or if the UE becomes de-registered and a SIP re-registration is required, the SIP REGISTER message may include the access token without requiring the user to re-authenticate.

The access token may be sent over SIP to the MCX server to re-bind an IMPU and MC service ID (MCPTT ID, MCVideo ID or MCData ID) if either have changed (e.g. IMPU is different due to SIP deregistration/SIP re-registration, or user logs out and another user logs onto the same UE).

5.1.3.2.2 Using SIP REGISTER

The use of a SIP REGISTER message to provide the access token to the MCX server is shown in figure 5.1.3.2.2-1. The inclusion of an access token in any particular SIP REGISTER message is optional.

Figure 5.1.3.2.2-1: MCX User Service Authorization using SIP REGISTER message

Step 5 of figure 5.1.3.2.2-1 shows the access token message passed to the SIP core in a SIP REGISTER. Upon successful SIP authentication, the SIP core forwards the access token to the MCX server in the third part registration request message (Step 9).

In Steps 9 through 11, the MCX server receives the third part registration request message, validates the access token, binds the IMPU and MC service ID (MCPTT ID, MCVideo ID or MCData ID) if the access token is valid, and responds to the 3^rd party registration message.

5.1.3.2.3 Using SIP PUBLISH

The use of a SIP PUBLISH message to provide the access token to the MCX server is shown in figure 5.1.3.2.3-1. The inclusion of an access token in any particular SIP PUBLISH message is optional.

Figure 5.1.3.2.3-1: MCX User Service Authorization using SIP PUBLISH message

As shown in Step 1 of figure 5.1.3.2.3-1, the SIP PUBLISH message carries the access token through the SIP core to the MCX server.

In Steps 2 and 3, the MCX server receives the SIP PUBLISH message, validates the access token, binds the IMPU and MC service ID (MCPTT ID, MCVideo ID or MCData ID) if the access token is valid, and responds to the SIP PUBLISH message.

5.1.4 Inter-domain MC user service authorization

5.1.4.1 General

When a MC User requires service authorisation to a service that is located in a different Identity Management Domain, coordination between the identity management services of the primary Identity Management Domain and the partner Identity Management Domain is required. For example, a MC User from Identity Management Domain A may be a member of a group that is home to Identity Management Domain B within the same system or an MC user may migrate from their primary MC domain to a partner MC domain.

While inter-domain user service authorisation is not used for authorising users to services across interconnected MC systems (MC clients always connect directly to MC servers in their primary system with interconnection services provided via MC server to MC server communications), inter-domain user service authorisation shall be used for authorising migration of MC users.

This sub-clause shall be used for authenticating and authorizing a user that is home to Identity Management Domain A with a group service that is located in Identity Management Domain B or when a user from Identity Management Domain A migrates to a MC domain within Identity Management Domain B..

5.1.4.2 Inter-domain identity management functional model

The inter-domain identity management functional model is shown in Figure 5.1.4.2-1.

Figure 5.1.4.2-1: Functional Model for Inter-Domain Identity Management

In Figure 5.1.4.2-1, the IdMS located in the primary Identity Management Domain (MC Domain A) is the home identity management server for the user. The partner IdMS is located in a second Identity Management Domain (MC Domain B) and provides identity mangement services for the primary user when authorising to partner group services or when the MC user is attempting to migrate.

The CSC-1 reference point between the UE IdM client and the partner IdM server endpoints shall be a direct connection and shall be protected with HTTPS (TLS).

The primary IdMS certificate(s) used to validate the user credentials at the partner IdMS are provisioned into the partner IdMS using an out of band mechanism beyond the scope of this document.

As defined in Clause 5.1.2 an access token is required for user service authorisation. The same principle applies for inter-domain user service authorisation, in that the MC client must present a valid access token issued from the partner IdMS in MC Domain B for authorisation to services located in MC Domain B.

The inter-domain identity management procedure shall be triggered when an MC client, after performing user service authorisation within the primary Identity Management Domain, determines that the user is a member of a group service that is located in a partner IdMS domain (as indicated in the user profile).

Additionally, the inter-domain identity management procedure shall be triggered when a user attempts to migrate from their primary MC system to a partner MC system.

In order for the MC client to obtain the MC Domain B authorisation access token(s), the token exchange procedure with the primary IdM service (MC Domain A) shall be used to obtain a security token that identifies the user to the partner IdM service. This security token shall be specific to the partner IdM service and signed by the primary IdM service per IETF RFC 7515 [35]. Upon validation of the security token, the partner IdM service shall provide the access token(s) to the MC client specifically scoped for that user. The access token(s) shall provide the user with authorisation to the service(s) in the partner Identity Management Domain (MC Domain B) which may include services related to migration.

Figure 5.1.4.2-2 shows the token exchange and authentication procedure.

Figure 5.1.4.2-2: Token exchange procedure

The token exchange profile for accessing the partner identity management service (steps 1-5 in Figure 5.1.4.2-2) shall consist of [45] and [46] and shall be profiled as defined in Annex B.7.

NOTE: A specific and independent security token is required for each partner identity management domain.

Within a single MC System with interconnected MC domains, once the MC client obtains the access token specific to the partner group service(s) (step 5 in Figure 5.1.4.2-2), the MC client shall follow the user service authorisation procedure defined in clause 5.1.3 to access the group service(s) within the partner domain.

For migration of an MC user from their primary MC domain to a partner MC domain, once the MC client obtains the access token specific to the partner MC system (step 5 in Figure 5.1.4.2-2), the MC client shall follow the user service authorisation procedure defined in clause 5.1.5.

The token exchange procedure shall be repeated for each partner identity management domain where the MC client requires access and authorisation to group service(s) within that partner MC domain or when the user migrates from their primary MC system to a partner MC system.

Annex C.2 shows the detailed flow for inter-domain MC user service authorization using the OAuth 2.0 token exchange procedure.

5.1.5 MC user migration service authentication and authorisation

When an MC user migrates from their primary MC domain to a partner MC domain, MC user migration service authentication and MC user migration service authorisation shall be carried out prior to the migrated MC user receiving services at the partner MC domain.

Figure 5.1.5-1 shows the MC user migration service authentication and authorisation procedure.

Figure 5.1.5-1 Service authorization for migration to partner MC system

1-5. MC user migration service authentication shall be the inter-domain identity management steps 1-5 in Figure 5.1.4.2-2 of clause 5.1.4.2.

6. Upon receiving a successful Token Response message, the MC client shall initiate the ‘Service authorisation for migrating to a partner MC system’ procedure as shown in Figure 5.1.5-2.

7. Following successful execution of step 6, service authorisation to services in the migration partner MC system shall be performed as defined in clause 5.1.3.

Figure 5.1.5-2 shows the ‘Service authorisation for migrating to a partner MC system’ procedure. Details of this procedure can be found in clause 10.6.3 of 23.280 [36].

Figure 5.1.5-2 Service authorization for migration to partner MC system

1. The ‘Migration service authorization request’ message is sent by the MC service client to the partner MC service server and includes the access token obtained in step 5 of Figure 5.1.5-1.

2. The partner MC service server performs an initial authorization check to verify that the MC service user is permitted to migrate to the partner MC system. This step includes validation of the access token received in step 1 and shall be performed as defined in Annex B.11.

3-11. These steps are as defined in clause 10.6.3 of 23.280 [36].

NOTE: An access token is neither required nor provided in steps 3-11.