Authenticated Identity Management in the Session Initiation Protocol (SIP)
obsoletes
- rfc-4474 — Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)
updated by
- rfc-8946 — Personal Assertion Token (PASSporT) Extension for Diverted Calls
Extracted elements (32)
RFC 4474 is obsoleted because it failed to handle telephone numbers as identifiers despite their dominance in SIP deployments, and because it signed over SIP header fields that intermediaries in existing deployments commonly alter. This specification realigns the signature format with PASSporT (RFC 8225) and addresses the STIR threat model (RFC 7375).
The authentication service is commonly implemented at a proxy rather than at each UA because UAs may be numerous (phones, PCs, PDAs) and synchronizing keying material across multiple devices is prohibitively complex. Centralizing signing at the proxy trades end-to-end security properties for deployment practicality.
This specification contains no backwards-compatibility provisions with RFC 4474. RFC 4474 deployments are believed to be nonexistent. A hypothetical RFC 4474-compliant verifier receiving an RFC 8224 Identity header would likely respond with 436, since there is no separate Identity-Info header field.
A verification service MUST ignore an Identity header field whose 'ppt' parameter value is present but not supported. If Identity is required by local policy but no usable header exists (absent or all ppt values unsupported), a 428 'Use Identity Header' response MUST be sent.
All implementations MUST support the PASSporT mandatory signing algorithms. Currently the single mandatory-to-support algorithm is 'ES256' (ECDSA P-256), as defined in RFC 7519.
An authentication service MUST NOT add an Identity header field if it does not have authority over the identity in question. If not authoritative, it SHOULD process and forward the request normally unless local policy dictates blocking.
Authentication and verification services MUST follow defined procedures to determine whether the user portion of a SIP URI constitutes a telephone number (e.g., via 'user=phone' parameter, tel URI, or '+' prefix), directing further processing to either telephone canonicalization (Section 8.3) or URI normalization (Section 8.5).
Dereferencing the URI in the 'info' parameter of the Identity header field MUST be supported by all verification service implementations as the baseline means of credential acquisition. Verifiers SHOULD discover credentials this way unless they have an implementation-specific alternative.
If an authentication service receives a 438 response after sending the compact form of PASSporT, it SHOULD retry the request with the full form. Implementations SHOULD NOT retry the request more than once.
If the SIP request contains an SDP body with one or more 'a=fingerprint' attributes, the PASSporT payload 'mky' key MUST appear with the algorithm(s) and value(s) of those fingerprint attributes.
Implementations MUST support receiving multiple Identity header fields in a single request for future compatibility. If at least one Identity header field is valid and from a trusted source, relying parties may use it for authorization regardless of other invalid or untrusted Identity headers present.
SIP and SIPS URIs must be normalized to canonical form 'sip:user@host' before inclusion in PASSporT claims, discarding all uri-parameters, escaped headers, passwords, and port numbers. Implementations MUST perform case normalization (lowercase scheme, user, host) and percent-encoding normalization per RFC 3986 Section 6.2.2.
Telephone number canonicalization MUST drop any '+', dashes, parentheses, and other non-numeric characters except '#' and '*'. Implementations SHOULD then convert the number to E.164 format by adding a country code if necessary, resulting in an ASCII string of digits, '#', and '*' only.
The authentication service MUST add a Date header field to requests that do not have one and MUST ensure any pre-existing Date header is accurate. If the Date header differs by more than one minute from the authentication service's current time, the service SHOULD reject the request. A maximum discrepancy of sixty seconds is RECOMMENDED.
The authentication service MUST authenticate the originator of the request before adding an Identity header. Authentication may be performed via Digest authentication at a proxy, or by UA-specific means such as physical access.
The 'info' parameter MUST contain a URI that dereferences to the public key of the authentication service's credential. For common cases, this URI SHOULD be dereferenceable by any entity on the public Internet; in constrained environments, a private service MAY be used.
The PASSporT header JSON object MUST contain: 'typ' set to 'passport', 'alg' mirroring the Identity header alg parameter (defaulting to 'ES256'), and 'x5u' equivalent to the URI in the 'info' parameter. If a PASSporT extension is in use, 'ppt' MUST be present and mirror the Identity header 'ppt' parameter.
The PASSporT payload 'iat' key MUST appear. The authentication service SHOULD set it to the SIP Date header value encoded as UNIX time, but MAY use its own clock, in which case the full form of PASSporT is REQUIRED. The authentication service MUST NOT generate a PASSporT if the Date header is outside local freshness policy (sixty seconds is RECOMMENDED).
The PASSporT payload 'orig' object MUST be populated with a 'tn' element for telephone number identities (canonicalized per Section 8.3) or a 'uri' element for SIP AoR identities. The 'dest' array MUST similarly be populated with 'tn' or 'uri' elements derived from the To header field.
The verifier MUST validate the signature in the Identity header over the reconstructed PASSporT object. The verifier must also check Date header freshness against local policy (sixty seconds RECOMMENDED) and ensure the Date falls within the credential's validity period.
Use of the compact PASSporT form in the Identity header is RECOMMENDED to reduce message size. However, the full form is mandatory when optional PASSporT extensions (ppt) are included, and the compact form MUST NOT be used when optional claims are present in the PASSporT payload.
When the full form of PASSporT is present, the verification service MUST NOT treat the 'orig' value as the originating identity of the call. The originating identity is always derived from the SIP signaling (From header per Section 6.2 Step 2); using the PASSporT 'orig' directly would enable cut-and-paste attacks.
Anonymous SIP URIs (e.g., sip:[email protected]) are fully compatible with the Identity mechanism; authentication services can sign them to assert 'authenticated but anonymous' identity. However, the domain 'anonymous.invalid' cannot be used by authentication services because no credential authority can exist for that domain.
Using the full form of PASSporT in conjunction with the P-Asserted-Identity header is NOT RECOMMENDED outside trust domains, because the canonical 'orig' claim may disclose network or user information not otherwise present in the SIP request. If P-Asserted-Identity is stripped at a trust boundary, the PASSporT must be converted to compact form to avoid leakage.
Four failure response codes apply to Identity header validation: 428 'Use Identity Header' (required but absent/unsupported ppt), 436 'Bad Identity Info' (cannot acquire credentials from 'info' URI), 437 'Unsupported Credential' (credential acquired but not trusted or algorithm unsupported), and 438 'Invalid Identity Header' (no valid PASSporT found). A 403 'Stale Date' may be sent for freshness failures.
The Identity header field consolidates Identity-Info from RFC 4474 into a single header with 'info', 'alg', and optional 'ppt' (PASSporT Type) parameters. Unlike RFC 4474, the Identity header field may appear more than once in a single SIP request. The signed-identity-digest contains a base64-encoded PASSporT (full or compact form).
IANA created two new registries: 'Identity-Info Parameters' (for Identity header field parameters such as 'info', 'alg', 'ppt') and 'Identity-Info Algorithm Parameter Values' (for 'alg' values such as 'ES256'), both with RFC Required change policy.
IANA registered the revised Identity header field for SIP (replacing the RFC 4474 definition) and deprecated the Identity-Info header field. The Identity header field is now defined in this document (RFC 8224).
IANA updated four SIP response codes: 428 'Use Identity Header', 436 'Bad Identity Info', 437 (renamed from 'Unsupported Certificate' to 'Unsupported Credential'), and 438 'Invalid Identity Header'. All now reference RFC 8224.
An adversary positioned as an intermediary could maliciously remove Identity header fields from a request. TLS on the last hop helps protect against this; verification services should implement per-domain or per-user policies that require Identity headers and reject requests lacking them when appropriate.
The signature covers the From header (originator identity), Date header (anti-replay), To header (destination), and SDP 'a=fingerprint' media keys (DTLS binding). These collectively prevent impersonation attacks, cut-and-paste/replay attacks, and media key substitution described in the STIR threat model (RFC 7375).
The signature does not protect the display-name portion of the From header field; only the addr-spec (URI) is covered. Attackers can set an arbitrary display-name even when the Identity header is valid, so relying parties MUST NOT rely solely on display-names for user-visible identity.