5 Authentication and authorization

33.1793GPPRelease 13Security of Mission Critical Push To Talk (MCPTT) over LTETS

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

5.1 General

The generic steps for MCPTT authentication is shown in figure 5.1-1.

Figure 5.1-1: MCPTT Authentication

At UE power-on, the MCPTT UE performs LTE authentication as specified in TS 33.401 [14]. The MCPTT UE then performs the following authentication procedures to successfully complete the MCPTT service registration and identity binding between signalling layer identities and the MCPTT user identities.

– A: MCPTT user authentication.

– B: SIP Registration and Authentication.

– C: MCPTT 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 MCPTT user identities, a re-registration (Step B) to the SIP Core may be performed to update the registered signalling layer identity.

If an MCPTT UE completes SIP registration in Step B prior to performing MCPTT user authentication in Step A and MCPTT user service authorization in Step C, the MCPTT UE shall be able to enter a ‘limited service’ state. In this limited state, where the MCPTT user is not authorized with the MCPTT service, the MCPTT UE shall be able to use limited MCPTT services (e.g. an anonymous MCPTT emergency call). The MCPTT Server is informed of the registration of the MCPTT 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.2 LTE access authentication and security mechanism

MCPTT UE shall perform the authentication and security mechanisms as specified in 3GPP TS 33.401 [14] for LTE network access security.

5.3 Authentication for SIP core access

This clause specifies the mutual authentication between the UE and the SIP core.

IMS AKA authentication shall be performed as specified in 3GPP TS 33.203 [6] for SIP core access. IMS AKA authentication mechanism as specified in 3GPP TS 33.203 [6] shall be performed irrespective of whether SIP core architecture is compliant with 3GPP TS 23.228 [15] or not.

Authentication related information shall be provided by SIP database that may be part of the HSS or may be part of the MCPTT service provider’s SIP database depending on the SIP core deployment scenarios specified in 3GPP TS 23.179 [2].

Implementation options and requirements on the ISIM or USIM application to support SIP core access security are specified in 3GPP TS 33.203 [6].

5.4 Authentication for HTTP-1

For authentication of the HTTP-1 reference point, one of the following authentication mechanisms shall be performed between the HTTP Client in the MCPTT UE and the HTTP server endpoint (MCPTT proxy, IdM server or KMS):

– one-way authentication of the HTTP server endpoint based on the server certificate;

– mutual authentication based on client and server certificates;

– mutual authentication based on pre-shared key.

Certificate based authentication shall follow the profiles given in 3GPP TS 33.310 [5], clauses 6.1.3a and 6.1.4a. The structure of the PKI used for the certificate is out of scope of the present document. Guidance on certificate based mutual authentication is provided in 3GPP TS 33.222 [16], annex B.

The usage of Pre-Shared Key Ciphersuites for Transport Layer Security (TLS-PSK) is specified in the TLS profile given in 3GPP TS 33.310 [5], annex E.

5.5 User authentication

5.5.1 Identity management functional model

The Identity Management functional model for MCPTT is shown in figure 5.5.1-1 and consists of the identity management server located in the MCPTT common services core and the identity management client located in the MCPTT UE. The IdM server and the IdM client in the MCPTT UE establish the foundation for MCPTT user authentication and user authorization.

The CSC-1 reference point, between the MCPTT 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 MCPTT shall be implemented as defined in annex B. MCPTT user authentication, MCPTT user authorization, OpenID Connect 1.0, and the OpenID Connect profile for MCPTT shall form the basis of the MCPTT 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.5.1-1: Functional Model for MCPTT Identity Management

To support MCPTT user authentication, the IdM server (IdMS) shall be provisioned with the user’s MC ID and MCPTT ID (the MCPTT ID may be the same as the MC ID). A mapping between the MC ID and MCPTT ID shall be created and maintained in the IdMS. When an MCPTT user wishes to authenticate with the MCPTT service, the user is directed to provide their MC ID and credentials 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 user’s MC ID and credentials, and if valid returns an id token, refresh token, and access token to the UE IdM client specific to that user. The IdM client learns the user’s MCPTT ID from the id token. Table 5.5.1-1 shows the MCPTT tokens and their usage.

Table 5.5.1-1: MCPTT tokens

Token Type	Consumer of the Token	Description (See Annex B for details)
Id token	UE client(s)	Contains MCPTT ID and whatever 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 MCPTT ID.
Refresh token	IdM server (Authorization Server)	Allows UE to obtain a new access token without forcing user to log in again.

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

To support the MCPTT identity functional model, the MCPTT ID 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 MCPTT user database and mapped to the user profile; and

– Provisioned into the GMS and mapped to Group IDs.

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

5.5.2 User authentication framework

The framework utilises the MCPTT CSC-1 reference point as depicted in Figure 5.5.2-1:.

Figure 5.5.2-1: MCPTT User Authentication Framework

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

– A-1 – Establish a secure tunnel between the MCPTT 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, that uniquely identifies the MCPTT user, to the MCPTT client.

Following step A-3, the MCPTT client uses the credential(s) obtained from step A-3 to perform MCPTT service authorization as per procedure C in figure 5.1-1.

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

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

5.5.3 OpenID Connect (OIDC)

5.5.3.1 General

Figure 5.5.3.1-1 describes the MCPTT User Authentication Framework using the OpenID Connect protocol. Specifically, it describes the steps by which an MCPTT user authenticates to the Identity Management server (IdMS), resulting in a set of credentials delivered to the UE uniquely identifying the MCPTT user’s identity. The means by which these credentials are sent from the UE to the MCPTT services are out of scope of this authentication framework. The authentication framework supports extensible user authentication solutions based on MCPTT 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.5.3.1-1: OpenID Connect (OIDC) flow supporting MCPTT 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 MCPTT service provider policy. The method chosen by the MCPTT service provider is not 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 MCPTT service). The id_token is consumed by the UE to personalize the MCPTT client for the MCPTT user, and the access_token is used by the UE to communicate the identity of the MCPTT user to the MCPTT server(s).

5.5.3.2 User authentication example using Username/Password

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

Figure 5.5.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.6 MCPTT user authorization

5.6.1 General

This clause expands on the MCPTT User Service Authorization step shown in figure 5.1-1 step C.

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

NOTE: All HTTP traffic between the UE and KMS, and all HTTP traffic between the UE and 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 KMS validates the access token and if successful, provides user specific key material back to the UE KM client based on the MCPTT ID of the user. This includes identity based key information used for media and signalling protection.

For user service authorization, the MCPTT client in the UE presents an access token to the MCPTT server over SIP. 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.

The UE can now perform configuration management authorization and download the user profile. Following the flow described in subclause 10.1.4.2 of 3GPP TS 23.179 [2] "MCPTT user obtains the user profile (UE initiated)", 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 CM server receives the request and validates the access token, and if valid, the CM server uses the MCPTT ID to obtain the user profile from the MCPTT user database. The CM server then sends the user profile back to the CM client over HTTP.

Upon receiving the user’s 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’s profile, and following the flow shown in clause 10.1.5.2 of 3GPP TS 23.179 [2] "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 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 7.3.2 of the present document.

Figure 5.6.1-1: MCPTT user authorization

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

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

Step C-2: The KMS client in the UE presents an access token to the KMS over HTTP. The KMS authorizes the user for key management services and replies to the client with identity specific key information.

Step C-3: The MCPTT client in the UE presents an access token to the MCPTT server over SIP as defined in clause 5.6.2 of the present document.

Step C-4: The CM client in the UE follows the "MCPTT user obtains the user profile (UE initiated)" flow from clause 10.1.4.2 of 3GPP TS 23.179 [2], presenting an access token in the Get MCPTT 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.

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.2 of 3GPP TS 23.179 [2], presenting an access token in the Get group configuration request over HTTP. If the token is valid, the CM server 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.

5.6.2 MCPTT user service authorization with MCPTT Server

5.6.2.0 General

Depending on implementation, MCPTT user service authorization may be performed by sending the access token to the MCPTT server over the SIP-1 and SIP-2 reference points using either a SIP REGISTER message or a SIP PUBLISH message. Clause 5.6.2.1 describes how to use the SIP REGISTER message to transport the access token to the MCPTT server and clause 5.6.2.2 describes how to use the SIP PUBLISH message to transport the access token to the MCPTT 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 MCPTT server as per Step C-3 in figure 5.6.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 MCPTT server to re-bind an IMPU and MCPTT 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.6.2.1 Using SIP REGISTER

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

Figure 5.6.2.1-1: MCPTT User Service Authorization using SIP REGISTER message

Step 5 of figure 5.6.2.1-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 MCPTT server in the third part registration request message (Step 9).

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

5.6.2.2 Using SIP PUBLISH

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

Figure 5.6.2.2-1: MCPTT User Service Authorization using SIP PUBLISH message

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

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