Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)
obsoleted by
- rfc-8224 — Authenticated Identity Management in the Session Initiation Protocol (SIP)
Extracted elements (30)
End-user certificates are neither practical nor affordable for SIP devices, so the mechanism delegates identity signing to an intermediary authentication service (typically a proxy server) that holds the domain's private key. This avoids requiring each phone, PC, laptop, or PDA to manage its own certificate and synchronize keying material across multiple devices.
The scope is intentionally limited to SIP requests; providing identity assurance for SIP responses is described as more complicated and deferred to future work. The mechanism is designed to be opportunistically deployable without requiring changes to SIP UA behavior.
UACs SHOULD prefer placing telephone numbers as the username portion of SIP or SIPS URIs in the From header (e.g., 'sip:+[email protected];user=phone') rather than bare TEL URIs, because bare TEL URIs make it unclear which domain is the appropriate signatory for the identity.
When a domain deploys an authentication service on a subordinate host (e.g., RFC 3263 SRV delegation from 'example.com' to 'sip.example.com'), the subordinate host MUST be supplied with the private key for the parent domain's certificate. This mirrors the inbound TLS certificate requirement and makes DNS-based virtual hosting unsecurable when domain admins are unwilling to share keys.
A verifier MUST evaluate domain name correspondence between the From header domain and the signing certificate's subject by following RFC 2818, Section 3.1, substituting the SIP domain for the HTTP server hostname. Self-signed certificates are strongly RECOMMENDED against unless prior key exchange has justified trust.
All implementations MUST support the 'rsa-sha1' algorithm: sign the digest-string with sha1WithRSAEncryption (RFC 3370) and base64-encode the result (RFC 3548). A 1024-bit or longer RSA key MUST be used. New algorithm values MUST be defined in Standards Track RFCs.
Authentication services MUST add a Date header field to SIP requests if one is not already present, and MUST add a Content-Length header field if one is not already present, to assist verifiers in accurately reconstructing the signed content.
If an Identity header is absent and required by local policy, a verifier MUST send 428 'Use Identity Header'. If the Identity-Info URI cannot be dereferenced, a 436 'Bad Identity-Info' MUST be returned. If the certificate cannot be validated, a 437 'Unsupported Certificate' MUST be returned. If the signature is invalid, a 438 'Invalid Identity Header' MUST be returned.
If the authentication service is not responsible for the identity in the From header field, it SHOULD process and forward the request normally but MUST NOT add an Identity header. For retargeting cases, if the From domain is not under the authentication service's authority, no Identity header is added.
Proxy servers MUST NOT remove or modify an existing Identity or Identity-Info header in a request. A proxy may optionally validate the Identity header before making a forwarding decision.
The authentication service MUST determine whether the sender is authorized to claim the identity in the From header field by authenticating them, e.g., via Digest challenge (407) or by having the UA provision the domain's private key. Authorization of the From username is a matter of local policy.
The authentication service SHOULD ensure any preexisting Date header is accurate within a RECOMMENDED maximum discrepancy of ten minutes; if the Date differs by more than ten minutes it SHOULD reject the request. The authentication service MUST verify the Date falls within the validity period of its certificate.
The Identity-Info header's absoluteURI MUST dereference to the authentication service's certificate. All implementations MUST support HTTP and HTTPS URIs; such URIs MUST follow RFC 2585 conventions and return 'application/pkix-cert'. Identity and Identity-Info MUST NOT appear in CANCEL.
Verifiers MUST NOT deem valid a request with a Date header more than 3600 seconds old. Verifiers MUST record Call-IDs from valid Identity-signed requests and remember them for at least the duration of one Date interval (commonly 3600 seconds) to detect replay attacks.
The mechanism is compatible with RFC 3323 privacy: anonymous URIs like 'sip:[email protected]' can be signed by an authentication service. However, domains like 'anonymous.invalid' cannot be signed because no certificate authority can exist for them. Privacy services MUST NOT remove the Identity header when a 'id' priv-value appears in a Privacy header.
The RFC 3323 'header' privacy level requests altering the Contact header, but Contact is protected by the Identity signature. Privacy services therefore cannot be applied after authentication services without causing an integrity violation.
The 428 'Use Identity Header' response code is sent by a verifier when a request lacks an Identity header but one is required by local policy, signaling the sender to re-send with an Identity header.
The 436 'Bad Identity-Info' response code is sent when the Identity-Info URI scheme is unsupported or the designated resource is unavailable. The 437 'Unsupported Certificate' response code is sent when the referenced certificate cannot be validated (self-signed, unknown CA, expired, or revoked).
The 438 'Invalid Identity Header' response code is sent when the Identity signature does not correspond to the digest-string reconstructed by the verifier from the request headers.
The authentication service role can be instantiated by a proxy server or user agent. Any entity instantiating this role MUST possess the private key of a domain certificate and MUST be capable of authenticating SIP users that can register in that domain.
IANA created two new registries for the Identity-Info header: one for parameter names (prepopulated with 'alg') and one for 'alg' parameter values (prepopulated with 'rsa-sha1'). New entries in both registries may only be defined in Standards Track RFCs.
This document registers two new SIP header fields ('Identity', compact form 'y'; 'Identity-Info', compact form 'n') in the SIP parameters header sub-registry, and registers four new SIP response codes: 428 'Use Identity Header', 436 'Bad Identity-Info', 437 'Unsupported Certificate', 438 'Invalid Identity Header'.
A direct TLS connection from the UAC to the authentication service is RECOMMENDED to prevent a rogue server from impersonating an authentication service and collecting shared secrets. Without TLS, a prior intermediary could modify headers or the body before the authentication service signs the request.
The 'alg' parameter in Identity-Info is not covered by the digest-string, allowing a man-in-the-middle to modify it. However, since only one algorithm ('rsa-sha1') is defined, there is currently no weaker algorithm to bid down to; 'alg' exists for forward-compatibility in case the current algorithm needs replacement.
The digest-string covers From, To, Call-ID, CSeq, Date, Contact, and message body. To prevents cut-and-paste attacks targeting a different user and SIPS downgrade attacks; Date+Call-ID together provide replay protection (Call-ID as nonce within the Date window; stale Date outside it); CSeq prevents method substitution attacks; Contact ties the Identity to a particular UA instance.
The display-name in the From header is not signed because display-names are not unique identifiers and enrollment practices cannot reliably bind them. An authentication service MAY enforce display-name policy and return 403 if policy is violated, but this is not mandatory.
The Via header is intentionally not covered by the signature because an attacker can always insert a new Via header after the authentication service's hop, making signature coverage ineffective. The best-known practice for securing Via is the use of SIPS.
The verifier performs four ordered steps: (1) acquire and validate the domain certificate from Identity-Info URI per RFC 3280; (2) verify the signer is authoritative for the From header domain; (3) reconstruct and verify the Identity signature; (4) validate Date, Contact, and Call-ID headers including freshness and certificate validity period. Failure at each step triggers a specific 4xx response.
The digest-string is formed by concatenating, separated by '|': From addr-spec, To addr-spec, Call-ID, CSeq digit and method (single SP), Date (canonicalized capitalization), Contact addr-spec (empty if absent), and message-body. CSeq leading zeros MUST be stripped; Date weekday and month MUST capitalize first letter only.
The Identity header carries a base64-encoded signed digest: `Identity = "Identity" HCOLON signed-identity-digest` where `signed-identity-digest = LDQUOT 32LHEX RDQUOT`. The Identity-Info header carries `LAQUOT absoluteURI RAQUOT` followed by optional parameters including a mandatory `alg` token.