Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)
updates
- rfc-3261 — SIP: Session Initiation Protocol
Extracted elements (28)
Encrypted JWTs are required for access tokens in SIP requests because RFC 6749 mandates TLS protection for tokens in transit, but SIP uses intermediary proxies and TLS only provides hop-to-hop protection — meaning an intermediary proxy could otherwise read the token.
OAuth 2.0 and OpenID Connect are used to enable single sign-on for SIP, allowing users to authenticate once and gain access to both SIP and non-SIP services. The detailed OAuth2 procedure for obtaining tokens is intentionally left out of scope.
The authz_server parameter value is restricted to an https URI (not http) to ensure confidentiality and integrity of the AS address communicated in the challenge, preventing redirection to attacker-controlled authorization servers.
If a REGISTER request with a Bearer token fails, the UAC may be able to successfully retry using non-Bearer credentials if multiple schemes were challenged, following standard SIP retry procedures.
If an access token is a reference token (opaque string), the registrar MAY perform OAuth 2.0 token introspection (RFC 7662) via HTTP POST to obtain metadata and claims. If a structured JWT, the registrar validates locally per RFC 7519.
This document updates RFC 3261 to specify that when a UAC receives a 401/407 response with multiple WWW-Authenticate/Proxy-Authenticate header fields using different authentication schemes for the same realm, the UAC provides credentials for one scheme it supports based on local policy.
A UAC MAY include an access token used for another binding with the same AOR in a REGISTER request, and MAY include an access token used for another dialog or stand-alone request if the target is the same.
If a proxy chooses to challenge a request and is willing to accept an access token, it MUST include a Proxy-Authenticate header field indicating a 'Bearer' scheme with an https URI to the AS. When validating, the proxy MUST successfully validate credentials from at least one Proxy-Authorization header field for its realm.
If a UAS/registrar chooses to challenge a request and is willing to accept an access token as a credential, it MUST include a WWW-Authenticate header field indicating a 'Bearer' scheme and including an AS address encoded as an https URI.
It is RECOMMENDED that the registrar include a scope in the 401 response to indicate the minimum scope needed to register and access basic services, when the registrar can provide access to different levels of services.
SIP endpoints that support this document MUST use encrypted JWTs for encoding and protecting access tokens when they are included in SIP requests, unless some other mechanism is used to guarantee that only authorized SIP endpoints have access to the access token.
The UAC MUST check the AS URL received in a 401/407 response against a list of trusted ASs configured on the UAC in order to prevent several classes of possible vulnerabilities when a client blindly attempts to use any provided AS.
When a UAS or registrar receives a SIP request containing an Authorization header field with an access token, it MUST validate the access token using procedures associated with the token type. For expired tokens it MUST reply with a 401 response; if validation fails it MUST also reply with 401.
When a UAS/registrar receives a request that fails to contain acceptable authorization credentials, it SHOULD challenge the request by sending a 401 (Unauthorized) response. Similarly, a proxy SHOULD challenge by sending a 407 response.
When the UAC sends a non-REGISTER request, it MUST include an Authorization header field with a 'Bearer' scheme carrying a valid access token obtained from the AS indicated in the challenge, as specified in RFC 6750.
Claims in access tokens may expose personal information about the user. The document calls for encrypting JWTs to protect privacy, but notes that careful consideration of which claims are included in tokens is important and outside this document's scope.
The operator of an SSO authentication system gains access to private information about sites and services users log into and their usage patterns. This must be disclosed in privacy policies and users should be made aware of the privacy trade-offs of SSO convenience.
The 'authz_server' parameter is added to WWW-Authenticate and Proxy-Authenticate header fields to carry an HTTPS URI pointing to the Authorization Server from which the UAC can obtain an access token.
The 'Bearer' authentication scheme for SIP is defined, enabling a UAC to present an OAuth 2.0 access token to a UAS, registrar, or proxy as credentials instead of using the Digest scheme.
The 'error' parameter in WWW-Authenticate/Proxy-Authenticate indicates the reason for an authentication failure, with possible values of 'invalid_token' or 'invalid_scope' as defined in RFC 6749.
The 'scope' parameter in WWW-Authenticate/Proxy-Authenticate indicates to the UAC the minimum scope that must be associated with the access token to obtain service; values are space-delimited case-sensitive strings as defined in RFC 6749.
Three token types are used: an Access Token (presented to SIP server for service access), a Refresh Token (presented to AS to refresh a stale access token), and an ID Token (returned by an OpenID Provider, structured as a JWT containing user identity claims).
Three new parameters — authz_server, error, and scope — are registered in the 'Header Field Parameters and Parameter Values' subregistry of the SIP Parameters registry for the WWW-Authenticate header field.
Access tokens MUST be protected so only authorized SIP servers can access them. SIP endpoints MUST use encrypted JWTs unless another mechanism provides equivalent protection, because TLS alone is insufficient due to SIP intermediary proxies.
Single Sign-On creates a single point of compromise with much broader impact than per-service credentials. An attacker who compromises the SSO account can access all linked services. Mitigations include long passphrases, multi-factor authentication, and using native platform browsers (RFC 8252).
The UAC MUST validate the AS URL from a 401/407 response against a configured trusted-AS list. Blindly contacting any advertised AS enables attackers to redirect authentication to a malicious AS and harvest credentials.
UAC authentication flow: (1) send request without credentials → receive 401/407 with Bearer challenge → (2) obtain tokens from AS → (3) retry request with Authorization: Bearer <token>. If token is rejected (new 401/407), return to step 2. If AS address is preconfigured, step 1 is skipped.
The WWW-Authenticate Bearer challenge syntax extends RFC 3261's 'challenge' parameter: 'Bearer' LWS bearer-cln *(COMMA bearer-cln), where bearer-cln includes realm, scope-param, authz-server-param (an https-URI), error-param, and auth-param.