Untrusted identity (user-generated user address information)

Description

An untrusted identity, as defined in the 3GPP vocabulary, refers to user-generated user address information — that is, addressing or identity information that originates from the user equipment or user rather than being allocated, verified, or asserted by a trusted network entity. In 3GPP systems, an identity is considered trusted when it is produced or confirmed by an authoritative network function (for example, an IMS subscription identity asserted by the network during registration, or an IMSI allocated by the operator). When the addressing information is supplied by the user or terminal, the network cannot assume it is valid, unique, or bound to the claimed subscriber, and it must therefore be treated as untrusted.

The concept appears across a range of 3GPP specifications dealing with messaging services and service-specific identities. Specifications such as 24.173 (IMS multimedia telephony), 24.406 (message waiting indication), 24.416 (customized alerting tones), 24.516 (customized ringback tone) and 24.616 (service-specific identities) each manipulate user addresses and identities in the context of supplementary services. In these specifications, the distinction between network-asserted identities and user-provided addresses is critical, because service logic (such as terminating call handling, message routing, or service invocation) may depend on the claimed identity.

Architecturally, the network handles untrusted identities by applying validation and screening functions. When a request, message, or session establishment contains user-generated address information, application servers and call session control functions compare it against trusted identities held in the subscription profile (obtained, for example, via HSS queries or stored in the serving node). If the untrusted identity matches a trusted identity that the user is authorized to use, it may be accepted for presentation or supplementary-service purposes; otherwise policy rules determine whether the request is rejected, the identity is discarded, or the identity is simply not used for security-relevant decisions.

From a security standpoint, the treatment of untrusted identities is linked to anti-spoofing and identity fraud prevention. If the network accepted user-generated addresses as authoritative, a malicious user could impersonate another subscriber, redirect services, or trigger unauthorized charging. The classification of an identity as untrusted therefore drives authorization checks, presentation restrictions, and possibly operator-configurable policies in the IMS and messaging domains.

The term is also relevant in interworking scenarios where addresses arrive from external domains or legacy systems that do not have a trust relationship with the home network. In such cases, the address is treated as untrusted until it is validated, and any service that consumes it must apply appropriate filtering. This makes the notion of untrusted identity a foundational element for securing identity-dependent services in 3GPP networks.

Purpose & Motivation

The concept of an untrusted identity exists to draw a clear security boundary between identities that the network can rely on and addresses that the user merely claims. Without this distinction, any user-supplied address could be treated as valid, enabling spoofing, impersonation, and fraudulent service usage. 3GPP therefore needed a vocabulary term that captures the risk level of user-generated addressing information so that specifications can consistently define how it must be validated or ignored.

Historically, as IMS-based and messaging services grew richer in the mid-2000s, service logic increasingly depended on the identity presented in signaling messages. Network-allocated or network-verified identities (such as those in subscription credentials or in identities asserted after authentication) were always trustworthy, but the same signaling often carried user-provided addresses as well. Previous approaches lacked a consistent term to mark these as untrustworthy, which risked inconsistent implementations across supplementary services and application servers.

The term also supports interoperability and policy enforcement: it gives operators a standardized way to describe a class of information that must be screened, and it allows specifications of services such as message waiting indication or customized alerting to state explicitly when an identity must not be trusted. This in turn makes the security requirements of those services testable and implementable across vendors.