The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
updates
Extracted elements (25)
A Proxy-Require or Require option tag cannot substitute for SIPS URIs because SIPS URIs can appear in Contact, Route, Record-Route, Path, From, To, Refer-To, and other fields, as well as in human-readable forms (business cards, web pages); an option tag would only be functionally equivalent in the Request-URI.
RFC 5630 deprecates the RFC 3261 last-hop exception, which had allowed the final hop to a UAS to omit TLS when a SIPS Request-URI was used. The exception was originally justified because, before RFC 5626, many UAs lacked certificates and could not accept incoming TLS connections; RFC 5626 now provides a better solution via UA-initiated outbound connections.
SIPS provides transitive trust through compliant proxies but cannot serve as an end-to-end security guarantee equivalent to HTTPS. Because any proxy or B2BUA can bypass SIPS requirements, it is inappropriate to display a padlock or similar visual indication of end-to-end security based solely on a SIPS Request-URI.
SIPS URIs are not suitable for 'best-effort TLS'; they imply TLS-only on every hop such that if TLS cannot be established the request fails rather than being delivered insecurely. Using a plain SIP URI over TLS provides best-effort behavior instead.
The transport=tls URI parameter was deprecated in RFC 3261 Section 26.2.2 because it only applies to a single hop, conflicting with SIPS's hop-by-hop security model. It remains in the ABNF solely for backward-compatible parsing.
Retargeting from SIP to SIPS by a proxy is problematic because it creates a misleading impression that the entire path was secure when it was not; retargeting from SIPS to SIP constitutes a forbidden downgrade. Both cases can be detected by inspecting the History-Info header field.
SIP and SIPS URIs that are identical except for the scheme refer to the same resource and are treated equivalently for routing purposes. Registering with a SIPS Contact creates an implicit binding for the corresponding SIP Contact as well.
A proxy MUST NOT use the RFC 3261 last-hop exception when forwarding or retargeting a request. When a proxy receives a SIPS Request-URI, it MUST only forward or retarget to a SIPS Request-URI; if the target registered with a SIP Contact, the proxy MUST reject with 480 and SHOULD include Warning warn-code 380.
A registrar MUST consider AORs that are identical except for having SIP vs. SIPS scheme to be equivalent. A registrar MUST only accept a SIPS Contact binding if all relevant URIs (Request-URI, Contacts, Path header fields) are SIPS; otherwise it MUST reject with 400 (Bad Request).
A UA MUST NOT include both the SIPS and SIP versions of the same Contact in a single REGISTER request; it MUST use only the SIPS version. If all Contact header fields in a REGISTER are SIPS, the UAC MUST use SIPS AORs in the From and To header fields; if any Contact is non-SIPS, it MUST use SIP AORs.
A UAC MUST NOT change a SIPS URI to a SIP URI under any circumstances, including when processing directory entries, 3XX Contact header fields, or route sets.
A UAS MUST NOT change a SIPS URI to a SIP URI. If a UAS does not wish to accept SIPS requests, it MUST respond with 480 (Temporarily Unavailable) and SHOULD include a Warning header with warn-code 380 'SIPS Not Allowed'. If a UAS requires SIPS, it MUST reject SIP requests with 480 and SHOULD include warn-code 381 'SIPS Required'.
All UA, proxy, and redirect server implementations MUST NOT use the 'transport=tls' URI parameter, consistent with its deprecation in RFC 3261.
If a UA wishes to be reachable with a SIPS URI, it MUST register with a SIPS Contact header field. If it does not wish to be reached with SIPS, it MUST register with a SIP Contact header field.
If a UAS or proxy receives a request with inconsistently used URI schemes (e.g., SIPS Request-URI but SIP Contact header field), the UAS MUST reject the request with 400 (Bad Request).
If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well (reaffirming RFC 3261 Section 8.1.1.8).
Upon receiving a 416 or 480 (Temporarily Unavailable) response with Warning warn-code 380 'SIPS Not Allowed', a UAC MUST NOT re-attempt the request by automatically replacing the SIPS scheme with SIP, as this constitutes an unauthorized security downgrade.
When a derived dialog (e.g., created via REFER, Replaces, or Join) originates from a SIPS dialog, the UAC MUST NOT establish the new dialog using SIP without explicit authorization from the entities involved.
When a GRUU is assigned through registration, the registrar MUST assign both a SIP GRUU and a SIPS GRUU. The version returned MUST match the scheme of the Contact header field in the REGISTER request.
When a proxy receives a request with a SIP Request-URI and the target had registered with a SIPS Contact, the proxy MUST NOT forward to a SIPS Request-URI; it MUST replace the SIPS scheme with SIP, leaving the rest of the URI unchanged, and use TLS to forward the request to the UAS.
When a proxy sends a SIPS request and receives a 3XX response with a SIP Contact, a 416, or a 480 with warn-code 380, the proxy MUST NOT recurse on the response; it SHOULD forward the best response upstream so the UAC can take appropriate action.
When a target refresh occurs within a dialog (re-INVITE, UPDATE), both the UAC and the UAS MUST include a Contact header field with a SIPS URI if the original request used a SIPS Request-URI.
When a UAC uses a SIPS Request-URI and the route set contains any SIP URIs, the UAC MUST change those SIP URIs to SIPS URIs (by changing the scheme only) before sending the request.
Two Warning header warn-codes govern SIPS negotiation: 380 'SIPS Not Allowed' is returned when a SIPS request cannot be fulfilled because the target only accepts SIP; 381 'SIPS Required' is returned when a SIP request is rejected because the target requires SIPS.
All SIPS security guarantees rely on every proxy and B2BUA on the path being compliant. Noncompliant intermediaries can silently downgrade or forge SIPS behavior; therefore SIPS must not be presented to users as an indication of end-to-end security.